Re: [lisp] #16: map versioning resolution

[Margaret Wasserman <mrw at sandstorm.net>]

On Sep 3, 2009, at 11:21 AM, Noel Chiappa wrote:
> 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.

That is exactly what the current LISP spec says to do with all of the  
reserved
flags -- ignore them on receipt.
> 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.

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?

> > 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

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.

> 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.

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?
> > 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.

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.
> > 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.

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.

> For another, and more importantly, your format does not allow doing  
> both
> 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
> 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.

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