>>>>> "Luigi" == Luigi Iannone <luigi at net.t-labs.tu-berlin.de> writes:
>> If so, why?
Luigi> Interoperability.
Luigi> Let me try to explain the idea about the R-bit (and
Luigi> hopefully addressing Joel's concerns).
Luigi> The basic idea is to have a bit that allows to overload two
Luigi> fields of the LISP header: Nonce and Loc-bits.
Luigi> In this way, when R = 1 we can put version numbers in the
Luigi> overloaded fields.
Luigi> Concerning draft-iannone-lisp-versioning-00, will update it
Luigi> in order to respect bit's position of the new header and to
Luigi> be coherent with draft-ietf-lisp-04.
Luigi> Having said that, we have also to keep in mind
Luigi> interoperability with boxes that do not support the R-bit.
Luigi> Those boxes will ignore the R bit, thus making mandatory
Luigi> that when R=1 then N and L must be 0 allows to safely make
Luigi> the ETR ignore the overloaded fields. Doing otherwise
Luigi> would lead to totally incompatible headers and
Luigi> implementations. We really do not need that.
OK. So, what you're saying is that we want to have two mechanisms for
handling map data. One works through the control plane and will be
specified in draft-ietf-lisp-lisp.
Everyone has to implement that.
The other one is specified in your draft; it's turned on by setting
the r bit.
We could potentially do something like that, although I don't think
the text in Dino's proposed changes for 04 actually accomplishes that.
However before we start discussing specific text I'd like to
understand why we want to do that.
Originally I thought you wanted everyone to implement map versioning.
The impression I get from the Stockholm minutes is that one of Dino or
Darrel (unclear who) was going to propose some hybrid mechanism.
Now, we're ending up with two mechanisms, one specified in a WG
document, one specified in a non-WG document. One of them is
optional.
I'm missing the chunk of reasoning where you decided that your
mechanism should be optional and was something only some boxes would
implement.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.