[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] On the Transitionability of LISP
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 - 188.8.131.52/20 is still advertised in BGP, by a single border
router of some network L. This router is an ITR.
2 - 184.108.40.206/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 220.127.116.11/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 18.104.22.168/20 addresses.
However, in principle, it should work.
I think I would handle this differently. Prior to withdrawing
22.214.171.124/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 126.96.36.199/8. One
could go further and say that it should be a 0.0.0.0/1 and 188.8.131.52/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.
to unsubscribe send a message to firstname.lastname@example.org 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