Subject: Re: [RRG] draft-farinacci-lisp-05

From: Dino Farinacci <[email-masked]>
Date: Sun, 23 Dec 2007 23:17:52 -0800

> On 19 dec 2007, at 6:20, Dino Farinacci wrote:
>
>>> There is no version field in the LISP header. There should be. At  
>>> least a few "set to zero on send, ignore on receive" bits that can  
>>> be used for extensions without bumping the version number is also  
>>> a good idea.
>
>> We decided to use control-plane type codes.
>
> Unless I missed something, this means you can never make backwards- 
> incompatible changes to the LISP header without running the old and  
> new versions on different RLOCs.

We can for control packets. But no, we can't for data packets. We  
didn't see this as a problem for GRE, when we defined it in the early  
90s. I don't see it as a problem here right now.

>>> "In order to eliminate the need for a mapping lookup in the  
>>> reverse direction, the ETR gleans RLOC information from the LISP  
>>> header."
>
>>> I find this undesirable because this way, the behavior of the  
>>> system can be different depending on which end initiated the  
>>> communication. Trusting information supplied directly by the other  
>>> end is also problematic security-wise. I would much prefer it if  
>>> both ends did an independent mapping lookup.
>
>> We stated this because there was a requirement from big content  
>> providers. I will loosen the  language and say "MAY glean".
>
> This is one of the big problems with GSE: if someone contacts you  
> with EID=windowsupdate.com and RLOC=l33th4x0r, and you trust this  
> relationship, an attacker gets to redirect traffic for that EID to a  
> random place. This is especially bad when the attacker can set up  
> this state just as you're about to set up an outgoing connection to  
> that EID, because then they get to intercept your outgoing traffic.

Understand.

>>> "LISP Locator Reach Bits: in the LISP header are set by an ITR to  
>>> indicate to an ETR the reachability of the Locators in the source  
>>> site."
>
>>> I wonder how useful this is in practice. First of all, having 32  
>>> RLOCs is way too many.
>
>> We have received feedback that it may not be enough.  ;-)
>
> As the LISP related documents that I've read are light on failure  
> detection and repair, it's hard to say anything definitive, but with  
> 32 ITRs and 32 ETRs TCP has probably long since given up when you  
> get around to learning that it's ITR 31 that can talk to ETR 31 but  
> the other 1023 combinations don't work.

I find it very unlikely that all xTRs would be down.

> I'd be interested in learning the rationale behind that feedback,  
> though.

Will add.

> [xTRs in ISP networks or (also) in end-user sites]
>
>> As I said at the IETF, for a CE deployment of xTRs, the most common  
>> failure points in the network, which affects connectivity to the  
>> site, is the CE router going down, the CE-to-PE link going down, or  
>> the PE router going down. Other failures are rerouted in the core  
>> based on richness of connectivity or are damped out due to  
>> aggregation.
>
> That's what the big ISPs tell us. Myself, I haven't had too much  
> trouble with my last kilometers, so my experiences may not be  
> representative, but I can tell you that routing failurs and  
> brownouts DO happen and anyone who cares enough about their  
> connectivity to be multihomed, wants to be protected against that,  
> too. Especially having a single ETR go down or function incorrectly  
> (claiming incorrect (un)reachability for other ETRs serving the same  
> EID) and then being unreachable or having severely degraded  
> reachability would be highly unacceptable to any multihomer that  
> I've ever known.

Right and encapsulating a packet isn't going to change it. And you  
can't depend on LISP to solve a core routing failure.

>> In these cases, the loc-reach-bits are extremely effective and gets  
>> the new status information to the other sites at data-plane rates.
>
> Only if the return traffic uses the ITR for the forward traffic as  
> its ETR, which makes sense in your view. However, this is a good  
> example of a more general tendency in LISP to commit to a narrow  
> mode of operation rather than to make the whole thing more open so  
> it's easy to change the protocol later for the IETF and to make  
> different deployment tradeoffs for operators.

All xTRs from source-site to destination-site (and vice versus) will  
most likely use all xTRs so traffic will be flowing out and in all  
them. That's the whole point in doing multi-homing. We want to do it  
*better* and better means active-active and not active-backup, which  
is slow converging.

> I'm currently not seeing this amount of extensiblity in LISP. The  
> fact that all of this is happening in an IRTF wg and that we've had  
> numerous previous efforts before that either failed to address the  
> issue completely (IPv6) or created something that only solves part  
> of the problem (shim6, and some would argue that I'm being generous)  
> shows that closing off too many paths at this stage is probably not  
> a good idea.

How about thinking of designing a protocol that is simple to get the  
job done efficiently and incrementally. Rather than bloating it with  
gratuitous features which most likely won't be used.

We have received a lot of operational feedback from network operators  
about what they want and what they don't want. We respect their  
opinions and don't want to give them more.

>>> We did consider sending a "free cache" bit in the data plane so  
>>> sites that have cached state could time out the state and re- 
>>> request a new mapping if they needed it, but as you might guess it  
>>> would cause a request implosion to the site.
>
> This is the same argument that you used against my idea of having a  
> code point in the LISP header to signal back reachability and other  
> information on request.

Right, I wasn't for what I suggested above. I told you we considered  
it and threw it out.

> We do this by having the ITR ask the ETR to send updates of the  
> relevant information (not important what exactly that information is  
> right now) by setting a code point in the LISP header. To avoid  
> having to send back information that's already known, the ETR keeps  
> a "table version" like value. I think we only need two or three bits  
> for this. When the ITR asks for an update, it supplies the "table  
> version" of the latest information that it learned. If the table  
> version at the ETR is the same as in the ITR's request, it doesn't  
> do anything. If the table version is different, the ETR sends back  
> an update. The ITR keeps an RTT estimate and makes sure there is  
> only one request in flight per RTT so the ETR won't be sending  
> unnecessary copies of the information packets.

Let's see what the other LISP coauthors say about this. I will discuss  
it with them offline.

>>>
>>     /|    Priority   |    Weight     |R|         Loc- 
>> AFI             |
>>  Loc +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
>> +-+
>>     \|                              
>> Locator                           |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
>> +-+
>
>> But since we won't use all the AFIs that are encoded, a byte should  
>> be sufficient. Please comment if you think we should stick with 16- 
>> bits or compress all occurences of AFI to 8 bits.
>
> Aren't multiprotocol BGP AFIs 16 bits? In that case, it saves IANA  
> from creating another registry for something that they already  
> register so if 16 bits is no imposition then that would be the  
> natural choice. But if you need the bits for something else, then  
> let IANA work a bit harder for their money... Obviously, they should  
> all be the same size at least in the context of LISP.

I know, but it packs so nicely right now.

>> Well if an ITR didn't have any data to know if the destination site  
>> was LISP-capable and encapsulated the packet by copying the inner  
>> DA to the outer DA, and the site was using PA addressing, the  
>> packet would enter the destination site and travel to the host. The  
>> host would not recognize a destination port of 4341, so it would  
>> respond with a port unreachable.
>
>> But we would not do this anymore with the advent of the lisp- 
>> interworking draft.
>
> That's good, because it doesn't make much sense to me to tunnel  
> packets to destinations for which you don't know if they support the  
> tunneling, even if we ignore for a moment how you would discover the  
> non-existant RLOC in that case.

Right.

>>> So basically the use of mapping requests/replies is the only  
>>> reliable (implicit) reachability detection mechanism. However, it  
>>> is largely unspecified how ITRs should use this mechanism to  
>>> determine reachability.
>
>> That and receiving data packets from the site.
>
> Sometimes traffic only flows in one direction. Although this is rare  
> for long periods unless you count asymmetric traffic flow, it's much  
> more common for short times when a session goes from active to idle.

Yes, for maybe one flow, but if you look at all flows between the two  
sites, there are safe chances it flows bidirectionally.

>>> I guess we have had enough discussion on this.  ;-)
>
> Well, let me put it this way: I'll gladly forego more discussion in  
> lieu of more consensus. Unfortunately, most people haven't spoken  
> out in favor of an approach towards the MTU thing.

Many have spoken out to do nothing because it is really not a problem.

>>> In my opinion, it would be beneficial to remove pretty much all of  
>>> the text that doesn't pertain to actual LISP operation from this  
>>> draft, and move that which is still useful (some of it is a bit  
>>> stale after five iterations) to a new "LISP architecture" document.
>
>> Can you list what is in this document doesn't pertain to LISP  
>> operation?
>
> I have a long list of other documents that I should review at some  
> point, so I don't want to go over the LISP draft again at this time.  
> If you agree with my suggestion, just keep your eye open for text  
> that qualifies on the next iteration of the document. If you don't,  
> don't.

Will do. Thanks for you comments.

Dino

--
to unsubscribe send a message to [email-masked] 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