Hi Iljitsch, First, thanks for your comments regarding NERD both now and in the IST-RING meeting. Based on those comments and some from others I intend to update the NERD draft with a bit more theory of operation, as to what you do with a NERD once you have it. This also validates Tony's comments to me that we shouldn't send an unstable experimental draft to the RFC Editor ;-) Second, let me remind people what was said in the RRG meeting. The general intent of most folks is to first focus on LISP-ALT. I would hence encourage you to devote some thought to ALT, now that you've done so with NERD ;-)
Now please see below. Iljitsch van Beijnum wrote: > After Eliot's presentation today, I started thinking that LISP-NERD > could benefit greatly from something like the shim6 REAP reachability > evaluation mechanism. However, with shim6 we have the limitation that > we have no bits to play with for datapackets belonging to sessions > that haven't encountered any failures. Not so with NERD: here we have > additional bits in every packet. I'm assuming that we can use a few of > those for reachability and MTU detection. It would work like this: Please note that the LISP architecture at present assumes that we will survive the tunnel overhead. We do have the general problem of MTUs that all tunneling schemes have. People differ over just how important this is to solve. Fred would probably argue "very" while Dino has argued "not that much". My own opinion is that over time getting to 1536 isn't that hard. The bigger problem is getting ABOVE 1536 pre-LISP (or anything else) encapsulation. Then you really do need real end to end MTU discovery, IMHO. > > A LISP-NERD ITR chooses an ETR/locator and assumes it's reachable. It > sets a "please respond" code point in the NERD header and starts a timer. s/NERD header/LISP header. There is only one LISP packet format. NERD is merely a way to schmere the data across the globe. > The ETR receiving the packet sees the "please respond" message and > sends back info to the originating ITR that could encompass current > locator preference information (for traffic engineering), the up/down > status of other ETRs, the maximum packet size the ETR is prepared to > receive, possibly (if the ETR supports reassembly) the maximum packet > size the ETR is prepared to reassemble from fragments. The ETR really only has its interface MTU. It doesn't look a whole lot different than any other router. Again, I think this is a general tunneling problem, and not something that is specific to LISP. I do think the problem is worth considering in LISP's context, but we should be thinking in more general terms when it comes to solutions (e.g, L2TP, IPSEC, IP over HTTP, etc., etc.). Again, thanks for your comments. Eliot -- to unsubscribe send a message to [EMAIL PROTECTED] 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
