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

[Dino Farinacci <dino@cisco.com>]

> After reading the ALT draft:

Thanks for commenting on the draft Iljitsch. See my responses inline.

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

It is actually the most optimal. One reason is that they are static  
tunnels and dynamic tunnels like LISP tunnels are.

There is no MTU problem with GRE, it is just like another interface on  
a router so MTU discovery can work over it.

> 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

That is a feature as well. Because you want to forward to the directly  
connected next-hop which is the other end of the tunnel.

> decapsulate the tunneled packet and then reencapsualte it. The  
> situation where

So what. Why is this a problem?

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

The ITR only needs to know about the tunnel endpoint it is eBGPing  
over. And that is configured.

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

No you don't need this. It already happens automatically. You want to  
update the next-hop so forwarding knows which tunnel interface to send  
the Data Probe over.

> 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

You can aggregate at any LISP-ALT router.

> handle automatic aggregation, and even manual aggregation works  
> quite badly

We are doing manual aggregation.

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

Yes, so. Machinery that is in many routers already.

> 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

You could use "ip access-group" command on the GRE tunnel. So you  
*could* prohibit it.

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

Would you rather drop the packets and send a Map-Request through the  
LISP-ALT topology?

Dino


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