On 18 Jun 2010, at 07:39 , Paul Jakma wrote: > On Fri, 18 Jun 2010, RJ Atkinson wrote: >> First, recall that ILNP session state is >> generally short-lived anyway. > > Doesn't it have to be at least as long as the session state of ULPs? > Or at least, kept refreshed for that length?
Hmm. The ILNP state could change very frequently, especially for a mobile node or a node of a mobile network. So it is pretty easy to imagine TCP session state being much longer lived than the ILNP session cache information. (In fact, one possible way to implement the ILNP session cache would be to add that data to the Transport Control Block information already in many BSD systems. I don't suggest that is optimal, but it is an example of an approach that probably could be made to work.) > Ok, that's the kind of info I'm after. I know it's obvious to you, > but you could point me toward where in the drafts this is described? draft-rja-ilnp-intro-03, Sections 3 & 4 would be good starting places. Nearly all of the ILNP papers talk about mobility, so they would also be useful. (Mobile IP seems a quite dynamic topic area, with myriad new optional extensions being proposed regularly.) > E.g. it'd be useful in this to see the ILNP state machine described > succintly, in one place, with perhaps a diagramme. (If that already > exists, apologies, I'd appreciate a pointer). Off the top of my head, I don't think that ILNP even has a finite state machine, whether implicit or formal. ILNP is not nearly so complex as TCP with TCP's 3-way handshake and so forth. Instead ILNP is a datagram protocol, just like IP. Perhaps I need to go edit any uses of the phrase session state to instead say session cache information, in the interest of readability and clarity ? The ILNP session cache is more similar to an ARP/ND cache than to TCP session state held in a Transport Control Block, especially if one is considering TCP with SACK support (which I'm told is now commonplace). Perhaps the authentication-related processing descriptions created the confusion that ILNP has a FSM ? (I don't think I can remove discussion of authentication, as authentication is really important, but if that's the source of confusion, then I would want to try to edit text.) ILNP cares about authenticating updates to that session cache for the same reasons that (some) folks care about authenticating IPv6 ND, or are concerned about the lack of authentication in ARP. As the existing I-Ds discuss, the main difference from IP is that for an ILNP session, the initiator includes the Nonce destination option in its initial packets, and the responder (if one exists, after all ILNP also supports unidirectional communications) would similarly include a Nonce destination option in its initial response packets. It isn't obvious to me that any of that involves creating a finite state machine, formally or otherwise. I would urge folks NOT to think of ILNP as having a finite state machine, because I suspect it would impede one's understanding, rather than advance one's understanding. In any event, I'm not inclined to over-specify ILNP at this early stage in its development and specification. Kindly recall that the RFC-793 TCP specification (1981) did not include much detail on essentials like congestion avoidance and control. Those came years later (Van's ACM paper in 1988, then RFC-1122 in October 1989) after there was more operational experience with the TCP protocol. As of today, ILNP isn't a standards-track proposal being worked upon within the IETF, but instead an IRTF Routing RG proposal that I hope to have published as an Experimental RFC. For any networking protocol, both implementation and experimentation ought to be important parts of the development and specification process. At least the LISP folks seem to agree with this, and they seem to be going along quite well. I don't think ILNP is an exception to this well-worn, but quite correct, principle of protocol design. IMHO, what ILNP really needs at this point is some (freely distributable) running code. Cisco's funding for non-Cisco work on LISP has been a real boost to their LISP effort, by providing more feedback through implementation and experimentation. (I don't work for a big or rich company, so I'm not in a position to fund any ILNP work.) Now, as I've said all along, I am trying to make the ILNP I-Ds more readable and more accessible. So if anyone has concrete suggestions about existing text that is confusing, or about critical topics that aren't covered, or about the current document organisation, I'm very interested in hearing that. (Revised I-Ds have been submitted and should appear online in the next few days.) > I'm still trying to understand the exact details of ILNP, > so I don't think I can make suggestions for changes. Not to worry, there will be lots of chances to update and refine specifications before anything is in any danger of going onto the standards track. Thanks very much for the thoughtful feedback. Yours, Ran _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
