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

[Iljitsch van Beijnum <iljitsch@muada.com>]

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