Hi Noel,
I understand everything in your message, but I still don't think it is
necessary or advisable to allocate a "research bit" in the LISP header.
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.
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 3
bits to support one additional (not defined in -04) format. The complex
dependencies 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 thatgetting 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 problemoutdated mappings are, ii) how expensive various solutions are, iii) how wellthose solutions work, etc we're kind of shooting in the dark without anight-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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.