Subject: Re: [lisp] Meanign of R bit

From: [email-masked] (Noel Chiappa)
Date: Tue, 1 Sep 2009 14:09:22 -0400 (EDT)

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

    > So far, declaring it reserved has almost the same effect ... except in
    > detecting a complex error case.
    > The difference is if ... 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

The difference is that in your alternative scenario, while you may (see
below) have preserved a bit of flexibility for the future (i.e. being able to
have instances in which both R and one of {N,L} are set), you have done so at
the cost of making it harder to incrementally deploy in general service some
new mechanism which uses the R-bit, since in your scenario non-upgraded boxes
would (I assume) toss packets with that bit set (since it would be
'reserved'). In other words, without some sort of mechanism to agree on
whether or not an ITR/ETR pair should use the new R mechanism, you would get
packets black-holing.

And even if we did go with the original scenario, I think we could still
change the semantics (so that both, for example, R and N could be set),
without being any worse off than in your alternative scenario. That's because
we'd be in the exact same boat - old and new boxes could not interoperate
without some mechanism to make sure they are both using the new semantics.
(I.e. both would have to understand that the previously prohibited bit
setting pattern(s) was now allowed, and what it meant, and the sender would
have to know that the receiver would understand it.)

So I guess I don't see any downside to specifying it now? Or am I
misunderstanding something?

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Sep 2009 15:40:59 -0400

On Sep 1, 2009, at 2:09 PM, Noel Chiappa wrote:
> 'reserved').

Actually, the specification says that the reserved bit are set to zero  
on transmit and ignored on receipt.  So, they can be used for  
extensions that are non-harmful to existing nodes without any need to  
explicitly document those reasons on the specification unless/until we  
are ready to document what they are actually being used for.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Sep 2009 15:56:44 -0400

On Sep 1, 2009, at 3:40 PM, Margaret Wasserman wrote:
>
> Actually, the specification says that the reserved bit are set to  
> zero on transmit and ignored on receipt.  So, they can be used for  
> extensions that are non-harmful to existing nodes without any need  
> to explicitly document those reasons on the specification unless/ 
> until we are ready to document what they are actually being used for.

On re-reading, I realized that this is at least semi-incomprehensible...

The second sentence should have read:  So, the reserved flags can be  
used for extensions that are non-harmful to existing nodes.  When we  
want to try out a new extensions that isn't ready to be formally  
considered by the WG, we can do that without the need to reserve a  
specific flag in the document.  We can wait to define a new flag in  
the document until we know what that flag will be used for, and how  
nodes that send/receive that flag are supposed to behave.

In the case of the R-bit, I think it would be better to wait (leaving  
the flag reserved until we are ready to fully document it) than to  
reserve a flag without any real explanation of how it will be used.

I have the same thought about the M bit in the mapping replies.

Margaret