Subject: Re: [lisp] #16: map versioning resolution

From: Luigi Iannone <[email-masked]>
Date: Wed, 2 Sep 2009 12:57:05 +0200

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 2 Sep 2009 12:08:12 -0700

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:

> The basic idea is to have a bit that allows to overload two fields  
> of the LISP header: Nonce and Loc-bits.
>
> 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.
> About Joel's concern on the case R=1 and L and N any combination  
> that is not 00:
>
> On the other hand, I do not think that this introduces any  
> additional security issue. (spoofing is always possible whatever  
> header we define)
>
>
> Now, since it is not possible to know the real meaning of the fields  
> I would suggest to silently drop the packet, because:
>
> About the issue of just making it a reserved bit, I do not see why  
> we should do that.
> different way rather then going again over the document) but as far  
> as I remember it was clear (to me at least).

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Sep 2009 15:22:57 -0400

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
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Sep 2009 15:33:26 -0400

>>>>> "Luigi" == Luigi Iannone <[email-masked]> 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.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 2 Sep 2009 12:41:21 -0700

> Everything works if we say nothing about that relationship.

Okay, so how about this text:

    R: this is the Research bit.  This bit is reserved and it's usage is
       not documented in this specification.

    L: this is the Locator-Status-Bits field enabled bit.  When this bit
       is set to 1, the Locator-Status-Bits in the second 32-bits of the
       LISP header are in use.

    N: this is the nonce-present bit.  When this bit is set to 1, the
       low-order 24-bits of the first 32-bits of the LISP header  
contains
       a Nonce.  See section Section 6.3.1 for details.

    E: this is the echo-nonce-request bit.  When this bit is set to 1,
       the N bit must be 1 and the R bit must be 0.  This bit should be
       ignored and has no meaning when the N bit is set to 0.  See
       section Section 6.3.1 for details.

No other reference to relationships of R, L, and N bit.

Converged?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 2 Sep 2009 13:04:51 -0700

> The other one is specified in your draft; it's turned on by setting

The one in Luigi's draft is going to be researched.  ;-)

> Darrel (unclear who) was going to propose some hybrid mechanism.

And the mechanisms are:

(1) SMR-based Map-Requesting (the control plane you refer to above).
(2) RLOC-probing (when in use you get map-updates at the frequency of  
the poll interval, also control
     plane).
(3) Use short TTLs.

And the ETR doesn't have to keep multiple locator-sets and required to  
do versioning. It always sends Map-Replies for the latest it has.

> document, one specified in a non-WG document.  One of them is

This is the sort of thing where part of LISP is doing engineering and  
other ideas are still in research.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 2 Sep 2009 14:29:25 -0700

I am sorry, it was a typo. I didn't remove it. I will remove the  
sentence that references the R-bit.

Dino

On Sep 2, 2009, at 1:51 PM, Joel M. Halpern wrote:

> Still (slightly) confused.  Why reference the R bit in the E bit  
> description?  The other two look great.  I understand why the E and  
> N interaction is specified, and appreciate it.
> Joel
>
> Dino Farinacci wrote:

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Sep 2009 16:27:33 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    >> document, one specified in a non-WG document.  One of them is

    Dino> This is the sort of thing where part of LISP is doing
    Dino> engineering and other ideas are still in research.

Right.  However, as far as I can tell, the WG hasn't come to the
conclusion that map versioning needs additional research.  When it was
presented to us, it was presented at least as far as I could tell as
an idea we should integrate into our specs.  I'm not following the
reasoning or discussion that lead from where I think we were in
Stockholm to a conclusion that map versioning needs research but the
other mechanisms do not.  If Luigi has been convinced of that, it will
certainly go a long way to convincing me as an individual, but I'm
suspecting we won't get there as a WG without someone actually
explaining the reasoning on the list and others agreeing with it on
the list.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 2 Sep 2009 14:45:43 -0700

>   Dino> Okay, so how about this text:
>
>    Dino>    R: this is the Research bit.  This bit is reserved and
>    Dino> it's usage is not documented in this specification.
>
> Doesn't work because it fails to specify what you do if you get a
> packet with this bit set.
>
> How about: The X bit provides an experimental [RFC 3692] flag for the
> LISP header. If a ETR receives a packet with this bit set and has not
> been explicitly configured to participate in an experiment, then [pick
> from group a].  As described in [RFC 3692], this bit can only be set
> when an implementation is configured to participate in an experiment.
>
> Group A:
>
> * drop the packet
> * decapsulate and process the inner packet but ignore the LISP header
>
> I don't actually support this option, preferring that if we're going
> to have a version field it be at least two bits wide.  Howevver I
> think it would be reasonable for the WG to decide on a one-bit version
> field and if the WG did so, I think the above text is consistent with
> how such things are handled in the rest of the IETF.

How about this text:

    R: this is the Research bit.  This bit is reserved and its usage is
       not documented in this specification.  If an implementation does
       not participate in the research experiment, the bit can be  
ignored
       by an ETR and accepted for packet decapsulation.

Folks, this doesn't have to be perfect at this point. We can rev  
future drafts. We need to capture the changes in a posted document. I  
am not trying to rush things, but I want to be practical too.

This is an experimental protocol. We don't need to cross Is and dot Ts  
at this point. We need to get the specification written so we can  
implement and learn from our experiments. And we need interoperable  
implementations, so we need to get this out.

Please don't take this the wrong way. Many seem to not like my email  
language so I am actually trying to be delicate here.

Thanks in advance,
Dino

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Sep 2009 16:53:09 -0400

>> 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.

Group A:

* drop the packet

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Sep 2009 16:51:44 -0400

Still (slightly) confused.  Why reference the R bit in the E bit 
description?  The other two look great.  I understand why the E and N 
interaction is specified, and appreciate it.
Joel

Dino Farinacci wrote:
>       low-order 24-bits of the first 32-bits of the LISP header contains

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 8 Sep 2009 18:28:24 +0200

I am catching up with mails..

On Sep 2, 2009, at 22:27 , Sam Hartman wrote:

> conclusion that map versioning needs additional research.

But experimentation yes and this is an experimental WG.

>  When it was
> an idea we should integrate into our specs.

Yes, but we never converged on the packet header format, and going up  
to 12 byte is not an option...

>  I'm not following the

The reasoning is very simple.
Mail discussion (off mailinglist) has pointed out that in fact we  
never need both "Version Numbers" and "Loc Status Bits" at the same  
time in the header thus it is possible to overload the 4 bytes  
allocated to the "Loc Status Bits". Hence the L bit and R bit came up.

Ok, may R-bit must not be described in draft-ietf-lisp, but I still  
think is a nice an clever solution.

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 8 Sep 2009 18:29:54 +0200

On Sep 2, 2009, at 21:33 , Sam Hartman wrote:

> document, one specified in a non-WG document.

Not yet a WG-document ;-)

>  One of them is

What you consider optional I consider incrementally deployable...

Luigi

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Sep 2009 15:58:52 -0400

Do you want the WG to consider adopting your map versioning draft?
If so, are we ready to consider that now or do you want to consider it when you've refined things more?

If you want to refine things more, what refinements do you want to make?

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 9 Sep 2009 10:54:49 +0200

> it when you've refined things more?

The draft has to be updated before going for any call.

> If you want to refine things more, what refinements do you want to  

Mainly specifying how to use the R-bit and how compatibility can be  
assured with the main spec.

All things that have been more or less already discussed, just need to  
be written down.

Luigi