> From: Margaret Wasserman <mrw at sandstorm.net>
> I still don't think it is necessary or advisable to allocate a
> "research bit" in the LISP header.
Slight mental whiplash here, because the message you'e replying to is about
the decision not to include the _mechanism_ in this go-round, but that's not
important...
On the R-bit, I think that whether we document it or not, it won't make a big
difference, _provided_ we specify clearly and exactly what to do when a
packet with that bit set arrives - which is to process it, ignoring the bit.
The _behaviour_ I do feel is important to specify, because it allows us to
incrementally deploy a new control mechanism piggy-backed on user-data
traffic _in an interoperable manner_.
> defining _three_ new bits to support experimentation with alternate
> LISP header field values: the L-bit ... the N-bit
I see these bits not principally for "support[ing] experimentation", as for
supporting future _interoperable_ deployment of new control functions
piggybacked on user-data traffic - a capability which I view as critical.
Without bits which affirmatively say 'this field contains this defined
function', we can't borrow that field to perform some _other_ function which
we will potentially discover we need; at least, in a way which won't
potentially confuse already-deployed boxes.
> I find the way the LISP header is defined ... to be very awkward and
> inefficient, as it uses 3 bits to support one additional .. format.
We have two fields (24-bit and 32-bit), which we wish to affirmatively
control (as above) independently. One of those fields has two potential
functions (sent nonce, echoed nonce). That pretty much requires three bits:
one for each field to say if it's in use, and one for the one field which has
two uses, to say which use it is in the current packet.
> The complex dependencies between the three bits results in most of the
> combinations of those bits being invalid/meaningless
Not really. Here's a quick table:
L N E
0 0 0 No Locator-Status bits, no nonce (of either kind)
0 0 1 Not allowed
0 1 0 No Locator-Status bits, sent nonce
0 1 1 No Locator-Status bits, echoed nonce
1 0 0 Valid Locator-Status bits, no nonce (of either kind)
1 0 1 Not allowed
1 1 0 Valid Locator-Status bits, sent nonce
1 1 1 Valid Locator-Status bits, echoed nonce
Only two out of eight are invalid. And the ones with 'no LSB' or 'no nonce'
are not useless, because those might occur in the future if we deploy a new
piggybacked control function which needs to use one of those fields to carry
its data.
> implementations will have to know what to do with those combinations if
> they are received.
Yes, but it's simple enough to do, either in hardware or software. There are
two completely separate functions, each controlled by one bit, and the second
function has two modes, 'sent' and 'echoed', again controlled by one bit.
> 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.
This doesn't have the 'interoperable evolution' attribute that I identified
as very important - i.e. the ability for unmodified boxes to keep performing
_existing_ functions on packets which may also contain some new stuff they
don't understand. With this 3-bit field, if a box sees one which has a new
value which it doesn't understand, there is nothing it can do with it except
toss it.
Yes, we could have some sort of mechanism for an ITR to find out what modes a
given ETR supports, so it would only send values the ETR would understand,
but I don't see that the extra complexity of that buys us that much, over
the proposed flags bits.
> 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.
For one, technically your thing uses 4 bits, because the E bit counts. I
mean, the existing format could have carved the E bit out of the 24-bit
field, in which case it would only use '2' bits.... I don't see that as worth
doing, though, because we still have a number of spare flag bits for various
future uses, and the 'not allowed' {N=0;E=1} value serves a dual function as
a handy 'escape' to a new format, contained entirely in the first byte.
For another, and more importantly, your format does not allow doing both
Locator-Status _and_ Nonce in a single packet. That means there has to be
extra logic _in the control plane_ (which is a PITA - separate part of the
box in most routers, and perhaps entirely hardware in high-end boxes) to
decide which user-data packets are going to carry the LS function and which
the Nonce function, etc, etc.
Noel
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.