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

[RRG] draft-fuller-lisp-alt-01.txt



After reading the ALT draft:

It seems highly suboptimal to use GRE tunneling for this when LISP has its own tunneling mechanism. Why not use regular LISP encapsulation/ decapsulation? It certainly wouldn't want to solve the MTU problem twice.

Using regular eBGP has two problems: the next hop attribute and aggregation. Because in eBGP, the next hop is pretty much always updated when prefixes are propagated, this means that every LAT router on the path towards the ultimate source of the prefix must decapsulate the tunneled packet and then reencapsualte it. The situation where the ITR that needs to send the original packet knows the address of the last (first?) router in the path so the packet travels end-to-end tunneled rather than hop-by-hop tunneled would be much better. Two ways to do this: minor BGP tweak so the next hop isn't updated, or a new attribute that contains the address that the packet must be tunneled to.

However, this doesn't really solve the issue because at some point there must be aggregtion. Note though that in current BGP, we don't really know how to handle automatic aggregation, and even manual aggregation works quite badly because of the longest match first rule. A router that aggregates must be prepared to receive tunneled packets and reencapsulate them because routers that see the aggregate obviously can't see the original next hop or tunnel-to address.

Since it's not possible to prohibit ITRs from sending packets through the LAT tunnels, any router doing aggregation must be prepared to receive a decent amount of traffic. This means that aggregating routers must either be in the part of the path that is paid for by the sender of a packet or in the part of the path that's paid for by the receiver. In other words: either all tier-1 ISPs must have the full EID->LOC state distributed throughout their AS, or EIDs are still provider-dependent, as an off-path router aggregating provider independent EIDs would easily receive more traffic than what can reasonably expected to be handled by a third party with no business relationship to either the sender or the receiver.


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