Re: [lisp] #16: map versioning resolution

["Joel M. Halpern" <[e-mail]>]

I do not see why, based on this note, this document should mandate 
anything about the relationship of the N and L bits to the R bit.
Everything works if we say nothing about that relationship.

(Sorry, I guess I do not understand eithe ryours or Luigi's reasoning 
for defining a relationship between defined bits and undefined bits.)

Just treat the R bit the way we do all reserved bits.  (Until redefined 
by some other document, the bit MUST be set to zero on transmission, and 
the value in that bit position MUST be ignored upon reception.)

Then, wherever we define the R bit, we can describe what is bits may be 
set along with the R bit.  And we can specify what error checks and 
error behaviors a node which understands the R bit will apply.

To do otherwise is to fold into this document decisions about the usage 
of the R bit that belong in some other document.  In a way that can not 
be reviewed, since there is no meaning.
Please explain what harm is done by following the usual IETF protocol 
definition practice in this case.  (I have already attempted to explain 
what harm I believe is done by not doing so, and why I do not see any 
harm in doing so.)

Yours,
Joel

Dino Farinacci wrote:
> Based on this response, I propose no changes to the spec. Any objections?
> 
> Dino
> 
> On Sep 2, 2009, at 3:57 AM, Luigi Iannone wrote:
> 
>>
>> On Aug 27, 2009, at 16:56 , Sam Hartman wrote:
>>
>>>
>>>
>>> The chair would like to ask the authors of
>>> draft-iannone-lisp-mapping-versioning-00 and others involved in the
>>> discussion to comment on Dino's proposed changes for
>>> draft-ietf-lisp-04.
>>>
>>> In particular, do you prefer his proposal to your original proposal?
>>
>> Yes
>>
>>> If so, why?
>>
>> Interoperability.
>>
>> Let me try to explain the idea  about the R-bit (and hopefully 
>> addressing Joel's concerns).
>>
>> The basic idea is to have a bit that allows to overload two fields of 
>> the LISP header: Nonce and Loc-bits.
>>
>> In this way, when R = 1 we can put version numbers in the overloaded 
>> fields.
>>
>> Concerning draft-iannone-lisp-versioning-00, will update it
>> in order to respect bit's position of the new header and to be 
>> coherent with draft-ietf-lisp-04.
>>
>> Having said that, we have also to keep in mind interoperability with 
>> boxes that do not support the R-bit.
>> Those boxes will ignore the R bit, thus making mandatory that when R=1 
>> then N and L must be 0 allows to safely make the ETR ignore the 
>> overloaded fields.
>> Doing otherwise would lead to totally incompatible headers and 
>> implementations. We really do not need that.
>>
>> About Joel's concern on the case R=1 and L and N any combination that 
>> is not 00:
>>
>> For boxes that do not understand R bit:
>> These boxes will ignore the R-bit and behave normally with the other 
>> two bits (and consecutive actions).
>>
>> I do not see any harm here. What if the R bit is set due to an error 
>> on the wire? This can always happen, even with other reserved flags.
>> On the other hand, I do not think that this introduces any additional 
>> security issue. (spoofing is always possible whatever header we define)
>>
>>
>> For boxes that understand the R-bit:
>> Let me start by saying that this issue should not be tackled IMHO in 
>> draft-ietf-lisp-04. I think it belongs to documents that define the 
>> meaning of the overloaded fields (draft-iannone-lisp-versioning).
>>
>> Now, since it is not possible to know the real meaning of the fields I 
>> would suggest to silently drop the packet, because:
>>
>> - If it is the result of an error on the wire, this is so rare that 
>> dropping a packet once in a while causes no harm.
>>
>> - If it is someone sending ill formed packets, thus playing with the 
>> rules, we do not need to consider it.
>>
>>
>> At the end, I do not think that we need any error message, as 
>> suggested by Joel.
>>
>> About the issue of just making it a reserved bit, I do not see why we 
>> should do that.
>> I do not remember by heart the wording in draft-ietf-lisp-04 
>> (apologies I am on holiday and would like to spend my last days in a 
>> different way rather then going again over the document) but as far as 
>> I remember it was clear (to me at least).
>> The document clearly state that the R bit is used for research 
>> purposes and how to deal with the N and L bits.
>> It is not in the scope of that document to describe in details the 
>> content of the overloaded fields, but just to assure that there is 
>> interoperability.
>> In this way, different "flavours" of lisp can still talk to each 
>> other. Making the bit reserved could open the door to problems (as 
>> Noel suggested in one of his mails) that later on packet with the R 
>> bit set will be just dropped.
>>
>> Hope this clarifies things.
>>
>> Luigi
>>
>>
>>
>>>
>>> Comments from others on this issue would also be very useful.
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
>