I understand everything in your message, but I still don't think it isnecessary or advisable to allocate a "research bit" in the LISP header.
I actually agree.
Dino has proposed defining _three_ new bits to support experimentation with alternate LISP header field values: the L-bit (which indicates if the locator status field contains locator status), the N-bit (which indicates if the nonce field contains a nonce), and the r-bit which (as of his latest round of edits) indicates nothing all to implementations of the -04 specification.
Right, we wanted to give some flexibility to the research folks. But I agree we shouldn't document something without clear meaning.
So I have an idea inspired by your email Margaret:(1) Leave the N and L bit settings as defined in -04. They are used as "field-enable" bits. (2) Don't have an R-bit since we cannot define how to use it or how to ignore it.
(3) The E-bit is still used for echo-noncing.Now when the research guys want to use the Nonce and Loc-Status-Bits fields for a new use, all they have to do is set N and L to 0. Implementations which are spec compliant use the N and L fields when the "field-enable" bits are set. Otherwise, they just decap the packet and don't use those fields.
How does that sound? Dino
Personally, I find the way the LISP header is defined in Dino's proposed -04 document to be very awkward and inefficient, as it uses 3bits to support one additional (not defined in -04) format. The complexdependencies between the three bits results in most of the combinations of those bits being invalid/meaningless, and implementations will have to know what to do with those combinations if they are received. If we anticipate that there could be more than one meaning attributed to the bits in the LISP header, I think that it would be preferrable to move to a 3-bit "format" field that indicates the format of the other 61 bits. My proposed header (which I believe accomodates the needs you've described below) would look like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Form | LISP Header Fields... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LISP Header Fields (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Form: The format of the LISP header fields in this header. This document defines three formats: 0 (000) -- No fields. Remainder of LISP header should be sent as zero and ignored on receipt. 1 (001) -- Nonce present format (see below). 2 (010) -- Locator status bits present format (see below). The value 7 (111) is reserved allow extension of the format field. ETRs that receive a LISP packet with an unrecognized format should treat that packet as though it had a format value of 0 (000). The ETR should ignore the LISP header fields, and process the packet normally. [Note: Do we need a format where both the Nonce bits and the locator status bits are present at the same time? If so, why?] The remainder of the bits in the LISP header are formatted as indicated in the format field. Nonce Present Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Form | rsvd bits |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce (32-bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Form: LISP header format, as described above. E: (As in Dino's -04 proposal) Nonce: (As in Dino's -04 proposal) [Note: If this nonce is determined to be security sensitive and needs to be longer than 32-bits, we could expand it to 60 bits by moving the E bit to the beginning and using the rest of the LISP header as a nonce.] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Form | rsvd bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Form: LISP header format, as described above. Locator Status Bits: (As in Dino's -04 proposal) [Note: Similar to above, if we determine that more than 32 Locator Status Bits would be preferred, we could use the rsvd bits, as well.] If we adopt my proposal, Luigi (or someone else) could write a specification that defines a new format for these bits without the need to set aside a per-proposal "R-bit" for that purpose. Since implementations of this proposal would ignore unknown formats, it isn't necessary for us to allocate the new format value in this document, as only the nodes that understand the new format need to know the format value. My proposal allows us to define up to 5 additional LISP header formats using the same number of bits that Dino's current proposal uses to support one additional format. Margaret On Sep 2, 2009, at 6:54 PM, Noel Chiappa wrote:From: Sam Hartman <hartmans-ietf at mit.edu>I'm not following the reasoning or discussion that lead from where I think we were in Stockholm to a conclusion that map versioning needs research but the other mechanisms do not.The problem is that we're operating in something of a vacuum,operational-data-wise. (Apologies in advance to the degree that any of the following is teaching of egg-sucking... And I also apologize in advance if I have mis-understood anything I've heard from various collaborators, so if Iget something wrong, 'just shoot me'... :-)We have what everyone feels has the _potential_ to be a problem - i.e. outdated mappings. There are also a bunch of ideas on various different mechanisms to tackle that problem, each of which has plusses and minusses(complexity, operational overhead, etc). In the particular case of mapping-versioning, piggybacking it onuser-data-trafffic has some big advantages (e.g. no extra packet traffic), but from an _implementation_ point of view, in one of our main testbeds (Dino's), my understanding is that it has a big downside, which is that getting the data plane to do anything control-oriented is really hard. (I got the impression that doing echo-noncing for reachabilty detection wasfairly painful, for instance.)Which of course shouldn't weigh too heavily on a design decision (ask me sometime about the variable length IP addresses in IPv3, and the number of pointer registers available in TENEX at interrupt time - you can guess where that story goes :-( - unless it's a _typical_ kind of problem for high-end router boxes (i.e. piggybacking control operations on user-data traffic),which I get the sense it might be.Still, when you add to that the concept that a versioning-type solution (I personally prefer checksums to versions, but that's an engineering detail) can be incrementally added later, I think that's _part_ of why that one isstill 'on the back burner'.The thing is that without more real-world data on i) how big a problem outdated mappings are, ii) how expensive various solutions are, iii) how well those solutions work, etc we're kind of shooting in the dark without a night-scope. This is also a case where I'm not sure simulation would even help much, since it depends a lot on other things which we also don't have alot of data on, e.g. how often mappings will be changed.Yeah, people have an 'engineering sense' for a lot of this, but intuition is not a 100.000% substitute for actual experience. And when you add in the fact that it's something we can add later without too much pain, I think that's the thinking behind a position of 'let's add these mechanisms, and study thatother one some more'. Noel _______________________________________________ lisp mailing list lisp at ietf.org https://www.ietf.org/mailman/listinfo/lisp_______________________________________________ lisp mailing list lisp at ietf.org https://www.ietf.org/mailman/listinfo/lisp
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.