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

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



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