Re: [RRG] Consequences of no renumbering...

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Scott Brim <swb@employees.org>

    > I don't think there is ever more than one routing plane.

Well, then there's a problem (although perhaps it's just a terminology issue,
and you mean something different to me from 'a routing plane'). Let me
explain...

With a M+E system in place, the system contains 3 kinds of IPvN addresses.
One set I'll label Ad - old style 'addresses' (to use Ran's suggested
terminology), which have dual location and identity semantics. Another set is
Ae - the EIDs; and the final set is Al - locators/RLOC's.

(To touch on the point of 'what does "routing plane" mean', to me a routing
<thing> which produces paths to an entirely disjoint set of destinations from
those handled by another <thing> is a different plane - even if it uses the
same protocol/code. A routing plane is, after all, nothing but a giant
distributed computation to select paths to a set of destinations. This has
nothing to do what what protocol/algorithm is being used - it's more
fundamental than that.)

Anyway, if we only have a single routing plane (in the sense in which I am
using it), then all routers in the 'core' (i.e. anything other than stub
areas of the network) will have to contain complete sets of Aj, Ae and Al in
the routing tables - in part because they could see packets with any of them
in the destination field, and must be able to correctly forward the packet
towards the appropriate destination.

In other words, deployment of M+E will be of absolutely no help in
controlling the _routing_ overhead - in fact, it will worsen it. Yes, it
might help with sites which want to switch ISP's and/or multihome - but so
will PI. So, without separate routing planes, M+E buys nothing, and will
never happen. M+E will only happen if we can use it to reduce the routing
overhead in the significant parts of the core.


One way in which this could happen is if we have two routing planes, Pe - an
"end-end" plane, which contains paths to Ad and Ae; and Pl - which contains
only locators/RLOC's. (This requires proxy mapping of the entire 'address'
space Ad - if we don't do that, the second plane has to contain Ad and Al.)

The 'converted core' runs Pl, and is _entirely_ surrounded by mapping boxes,
and packets with destination addresses in Ad and Ae are _never allowed in to
that part of the core_ - they have to be M+E'd into Al before they can be
forwarded. The 'uncoverted' part of the core runs Pe.

There are all sorts of ugly practical problems associated with actually
deploying such a system (e.g. the need to map from Al back to Ae at the edge
of the 'converted core'), but I'll stop here before this gets too long and
complicated.


    > I think the conceptual key is asymmetry in scope. As things are now,
    > routing/forwarding scope is global.

Exactly - but unless you are prepared to guarantee that packets with
destination address Ax never appears in a part of the network, you can't drop
the route to Ax in that part of the network.

I don't think such a requirement can be met in an ad-hoc way, not with a
large system - it has to be systemic.

    > As a site splits off and adopts map-n-encap, the rest of the Internet
    > is removed from its routing/forwarding scope, so that in order for a
    > packet to be forwarded to it a new adaptation mechanism (map-n-encap)
    > must be invoked ... but everything in the global Internet is still
    > directly reachable by it.

But if it's not a stub (as mentioned at the start), it cannot forward packets
in the 'right' direction without that larger routing table.

Look, there's a 1:1 mapping (to overload a term, sigh) between _non-stub
areas of the connectivity graph in which non-mapped addresses *can* appear_
and _non-stub areas of the connectivity graph in which non-mapped *routes*
*must* appear_.

So unless one is prepared to guarantee that packets with non-mapped addresses
_cannot_ appear in part of the network, then one cannot drop the requirement
for non-mapped _routes_ in that part of the network.

    > At the adaptation points (xTRs) there is a new routing mechanism to
    > allow adapation between different routing/forwarding *scopes*, but only
    > one routing plane and only one routing mechanism.

I don't care if it is the same protocol or not - that's a level of technical
detail which is irrelevant to level at which I'm trying to think about the
problem - which is entirely in terms of _sets of IPvN addresses_, etc (as
outlined above).

    > BGP is also used for discovering mapping authorities in LISP+ALT, but
    > that's a completely different use of a routing protocol -- it's in
    > support of the Internet's control plane (mapping), not the Internet's
    > data plane.

Well, routing (path selection) is part of the control plane too, but I take
your point - in ALT, BGP is not being used to select paths.

	Noel

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg