[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] incrementally deployable - roundup of proposals

Thus spake "Robin Whittle" <rw@firstpr.com.au>

In on-list discussions regarding LISP incremental deployability, two
solutions have emerged - both of which I think are in principle the
same as the "anycast ITRs in the core" idea I proposed in mid June
and which became part of Ivip.

There are no doubt other aspects to incremental deployability, but
one problem which certainly needs to be solved is reachability
from non-upgraded networks.  A sending host in a network with
no ITR needs to be able to successfully send a packet to a
destination host with an address which is managed by the LISP/
eFIT-APT/Ivip/TRRP system.
I understood that to be a fundamental requirement of this work; you can't call a solution "incrementally deployable" unless upgraded sites are reachable from non-upgraded ones. Fortunately, that seems easy to tack on to any of the proposals I've read. (see below) 


The only way this is going to happen, as far as I can see, is for
the destination host's address to be part of a BGP advertised
prefix.  Otherwise, the border router of the sending host's network
will drop the packet.
It might be the sending host's upstream, but the idea is correct. If there isn't a route in the DFZ to the destination EID, and there's no ITR in the path, then the packet won't make it there. 


I think that every end-user network with a LISP-mapped address would
require continued reachability from non-upgraded networks, so the
idea of limiting the number of prefixes to 100 or so makes no sense
to me.  I imagine that any successful ITR-ETR scheme would have
hundreds to tens of thousands of address blocks, each block, on
average, containing many "micronets".
In theory, one doesn't necessarily need lots of prefixes to reach millions of micronets -- you just need all EIDs to be within a small number of aggregate prefixes. 


Dino seems to have a very firm goal with advertised prefixes - to
radically reduce their number.  My aims are more modest - to be
happy with a similar or higher number of BGP advertised prefixes
than there are at present, as long as the ITR-ETR scheme is used
in a way that many more end-user networks get multihomable and
portable address space than would be possible with the same
number of BGP advertised prefixes without the scheme.
I think asking folks to give up existing PI blocks they're using is probably a waste of effort, though we can certainly try. We could definitely ensure no new ones were assigned, though, which means the total would gradually dwindle over time. Trying to shrink the routing table is an admirable goal, but none of these proposals will make any noticeable progress since the vast majority of routes in the DFZ today are PA deaggregates. There are other folks working on solving _that_ problem. 


The addresses which Ivip manages are all part of BGP advertised
prefixes.  The idea is that there are one or more ITRs outside the
non-upgraded networks which advertise this prefix, and the packet is
forwarded to one of these, where it is tunnelled to the ETR of the
destination host.

...

I think it can be seen that Eliot arrived at an arrangement for
LISP-NERD in August which is much the same as Ivip's "anycast ITRs
in the core".

...

I think Dino accepted that a similar approach would be needed for
LISP-CONS to achieve reachability from sending hosts in networks
without ITRs:

...

Bill Herrin discussed TRRP reachability from non-upgraded networks:

 http://psg.com/lists/rrg/2007/msg00488.html

This too involves "anycast ITRs in the core" and I think address
space for each end-user network (a "micronet") being part of larger
blocks of address space, each of which remains advertised in BGP,
for as long as there needs to be reachability from non-upgraded
networks.  For Ivip, this is forever.  For TRRP and perhaps other
systems, this may not be forever.
Reading all the various proposals and archives of the discussions here, the mental model I've come up with is that there would be two types of ITRs: ITR-Cs, or ITRs with caches, and ITR-Ds, or ITRs with a full copy of the mapping database.
Eventually large end sites and ISP POPs would have ITR-Cs. If the ITR-C encountered an EID it didn't have cached, it'd (a) send a mapping request to an ITR-D, either buffering the packet to be forwarded when a response is received or dropping it, or (b) forward the packet to an ITR-D (which would make it a RETR, I suppose) and hopefully receiving a mapping response back which would enable shortcut forwarding. One could also envision multiple layers of ITR-Cs/RETRs, if that ever turns out to be necessary.
However, the initial case (and probably final case, for some parts of the 'net) is that there won't be ITR-Cs deployed and all packets would end up flowing to the (anycast) ITR-Ds. Overloading or rate-limiting (both of which seem likely, for obvious reasons) of those ITR-Ds is the only real motivation for deploying ITR-Cs, and in some cases it may not be bad enough to bother. It shouldn't be much of a problem for the first few dozen sites that deploy...
The above model seems quite compatible with most of the existing proposals, except that it may be merging LISP-NERD and LISP-CONS* into a single LISP. Ivip is the main exception, but it already has a similar anycast ITR mechanism to what I describe.
(* I'll admit to not understanding LISP-CONS very well; my eyes started glazing over when CARs and CDRs were added to ITRs and ETRs -- too many moving parts for me.) 

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking 


--
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