Re: [lisp] #16: map versioning resolution

[Luigi Iannone <luigi at net.t-labs.tu-berlin.de>]

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
> lisp at ietf.org
> https://www.ietf.org/mailman/listinfo/lisp