[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 - 126.96.36.199/20 is still advertised in BGP, by a single border
router of some network L. This router is an ITR.
2 - 188.8.131.52/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 184.108.40.206/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 220.127.116.11/20 addresses.
However, in principle, it should work.
I think I would handle this differently. Prior to withdrawing
18.104.22.168/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 22.214.171.124/8. One
could go further and say that it should be a 0.0.0.0/1 and 126.96.36.199/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 email@example.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