Re: [lisp] Meanign of R bit

[jnc at mercury.lcs.mit.edu (Noel Chiappa)]

    > From: "Joel M. Halpern" <jmh at joelhalpern.com>

    > 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