Subject: Re: [lisp] #16: map versioning resolution

From: [email-masked] (Noel Chiappa)
Date: Thu, 3 Sep 2009 11:21:00 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > 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

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 3 Sep 2009 11:54:51 -0400

> packet with that bit set arrives - which is to process it, ignoring  

That is exactly what the current LISP spec says to do with all of the  
reserved
flags -- ignore them on receipt.
> two uses, to say which use it is in the current packet.

Actually, those aren't the three bits I was talking about.  Dino's -04  
proposal
actually has _four_ bits defined.  The E-bit is used to request nonce  
echoing.
The L, N and R bits are the ones that define what the fields in the  
packet mean.

I don't believe we have established that _we_ want to affirmatively  
and separately
control whether those two fields are present.  Dino's proposal tries  
to do that, but
that is all new to me.  I don't think we had discussed the need for  
bits to indicate
whether each of these fields is present on the list, and I don't know  
why it is
necessary to control them separately.  I also don't know why you  
couldn't use
part of the locator-status field to indicate whether it is there,  
since it would never
be remotely useful to send an indication that all of the locators are  
down, would
it?

> 1 1 1 Valid Locator-Status bits, echoed nonce

As I indicated above, you aren't talking about the same three bits that
I'm talking about.  Also, you seem to be confused about the purpose
of the E-bit, which is to request that the other side echo the nonce  
that
is in this packet, not to indicate that the nonce in this packet is  
echoed.

> piggybacked control function which needs to use one of those fields  

The three bits I'm talking about are the R, L and N bits, all of which  
control
which fields are in the packet.  The combinations of these bits are:

R L N

0 0 0 - Not "research", no locator-status, no nonce
0 0 1 - Not "research", no locator-status, nonce is present
0 1 0 - Not "research", locator-status is present, no nonce
0 1 1 - Not "research", locator-status is present, nonce is present
1 0 0 - "Research", no locator-status, no nonce
1 0 1 - Invalid
1 1 0 - Invalid
1 1 1 - Invalid

The first four are fine, and the behavior in all of these cases is  
defined in Dino's -04 proposal.

For the last four, we've wasted an entire bit to give us one other  
choice...    And, nodes that implement the -04 proposal will
do _exactly_ the same thing in that situation (ignore the r-bit,  
process the packet), as they would do if we didn't define the
r-bit in the LISP specification at all.  So, why waste an entire bit  
for this?
> value which it doesn't understand, there is nothing it can do with  

Could you do me a favor and actually _read_ the text that I provided  
before
rejecting it?

My proposal explicitly states that ETRs that receive formats they don't
understand should treat them like 0 (000), ignore the LISP header bits,
and process the packet as normal.  That is _exactly_ the type of
"interoperability evolution" that you have identified as important.
> For one, technically your thing uses 4 bits, because the E bit counts.

The E bit is in both places...  My proposal replaces three bits in  
Dino's proposal
(the R, N and L bits) with three bits.  They both have an E-bit, too.

> Locator-Status _and_ Nonce in a single packet.

It could, if we define a fourth format for that cases.

> That means there has to be

The existence of the separate L and N bits in Dino's proposal already
implies that you want this logic -- you don't need it, because it  
would be
perfectly fine never to send either.  You _do_ need logic to _notice_  
when
you have been asked to echo a nonce and send that nonce in the
return packet.

In general, I don't understand what nonce echoing gets us that
couldn't be more simply and cleanly accomplished via the control
plane, but presumably someone sees a use for it.

In fact, I'd be quite sympathetic to an argument that the current LISP
header functionality doesn't warrant an extra 64 bits in every data
packet, and we should drop the LISP header altogether...

If we are going to keep the LISP header, though, I hope we can avoid
creating a rat's-nest-like set of interdependent flag fields.

Margaret