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

Re: [RRG] On the Transitionability of LISP



Hi Robin,

Please see below.

There are two more promising options, as far as I know, for LISP
(other than adopting "anycast ITRs in the core" - and there's no
reason I know of why this couldn't be adopted):

1 - 20.0.0.0/20 is still advertised in BGP, by a single border
    router of some network L.  This router is an ITR.

2 - 20.0.0.0/20 is still advertised in BGP, by a single border
    router of some network L.  This router is a not an ITR.

In the former case, all packets sent from any network in the world
to any address in 20.0.0.0/20 will either find their way to an ITR
in their originating network, or will be sent out of the border
router (from a non-LISP-upgraded network) and arrive at the ITR,
where they will be tunneled to wherever they should go.  The
problems with this are mainly the possibility of longer path
lengths.  If the sender is in Düsseldorf, the ITR is in Japan and
the ETR is in  Cologne, then the path length is terribly
sub-optimal.  There are also single-point of failure problems due to
all hosts in non-upgraded networks relying on this one ITR for their
connectivity to the LISP-mapped hosts using the 20.0.0.0/20 addresses.

However, in principle, it should work.

I think I would handle this differently. Prior to withdrawing 20.0.0.0/20 there should be a reasonable number of ITRs in SP environments. At that point it makes sense for those to at least locally propagate a NOEXPORT route along the lines of 20.0.0.0/8. One could go further and say that it should be a 0.0.0.0/1 and 128.0.0.0/1. At that point you can have multiple ITRs doing this for redundancy's sake, and you're doing it with very few routes. Maybe 200-300 at most.

Eliot

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