Subject: Re: [lisp] Meanign of R bit

From: [email-masked] (Noel Chiappa)
Date: Tue, 1 Sep 2009 11:53:04 -0400 (EDT)

> From: "Joel M. Halpern" <[email-masked]>

    > how can we know that it should never be set with N and L, but not know
    > what it means?

Look at it as a bit which says 'the meaning of some header fields can be
time-shared to another use'. Clearly, in that case, it makes sense to say
'bits which indicate that those fields are being used to contain _other_
values cannot be set'.

I forget which bits are which (and I'm too lazy to look at the spec :-),
so I don't recall if it prohibits other use of only the 32-bit field, or
of the 32-bit _and_ the 24-bit field. To the extent that it's a true
general-purpose 'research' bit, it makes sense to allow it to use both of
those fields (and therefore disallow setting of _any/all_ bits which
indicate use of those fields).

    > It seems both simpler and more versatile to simpler declare the R bit
    > to be reserved. And to remove all the comments about N or L not being
    > set with R.

The problem with that is that if we want to eventually (and interoperably)
morph the R bit into an actual functional bit (e.g. for checking for outdated
mappings), to do that in an _interoperable_ way we need a tiny bit of
specification about how 'vanilla' ETRs will treat it, so we can design an
interoperable deployment strategy.

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Sep 2009 12:15:12 -0400

There is a classic interoperability issue with extension bits and their 
interaction with existing fields.

But, given the path you are on, I don't see the problem.
Suppose we reserve the R bit.
And suppose that when it gets defined, we agree that it should never be 
set along with the N (24 bit nonce) or L (32 bit locator reachability) bits.

Then no one who correctly uses the bits will set them that way.
And anyone who understands the R bit will understand it is an error if 
those bits are set.  Anyone who receives a correctly formed packet with 
a set R bit, who does not understand the R bit, will simply ignore that 
bit.  They will also observe the unset N and L bits, and ignore whatever 
value is in the corresponding fields.
The only problem would be if someone sent a packet with the R bit set, 
incorrectly set the N or L bits, and sent it to a receiver who did not 
understand the R bit.  That receiver would not understand that this was 
an error.
So far, declaring it reserved has almost the same effect as the 
definition you have in place, except in detecting a complex error case.

The difference is if, when we go to use the bits, we decide that one (or 
both) of the N and L bits & fields should retain their existing meaning. 
  Under the current textual definition, that is prohibited.  If we 
instead simply declare that the bit is reserved, then when we get to 
working it out, we can decide what the rules for the N and L bits should 
bit (preserving their existing meanings.)

It seems very strange to define things in such a way that we can not 
make choices that may well prove useful.  (I can imagine R bit uses that 
want to keep one or the other of N and L.  I can also imagine uses which 
don't.)

The other alternative is to treat the R bit as a version flag, and 
declare that anyone receiving a message with the R bit set should just 
ignore the message.  Dino said that was not the goal.  And it seems we 
have other ways of achieving that goal, so I would prefer not to go there.

Yours,
Joel

Noel Chiappa wrote:
...

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Sep 2009 12:44:08 -0400

I'd like to ask for the r-bit discussion to take a break until we here
a response to my query on #16 from the map versioning authors.  As far
as I can tell this facility was introduced as part of a compromise for
the map versioning discussion.  I want to get an answer to my
questions to those folks before we go forward more into the details of
the r-bit.

I think it is safe to say that we will not be done with the r-bit
discussion in time for a September 4 deadline.