Subject: Re: [lisp] I-D Action: draft-ietf-lisp-ddt-05.txt

From: Luigi Iannone <[email-masked]>
Date: Mon, 2 May 2016 10:36:30 +0200

> On 29 Apr 2016, at 23:18, Dino Farinacci <[email-masked]> wrote:
> 
> So how about this as a proposal. The DDT doc refers to 32-bits for the control-plane and RFC 6830 refers to 24-bits in the data-plane and the LCAF document explains how to map the 32 into 24 and what the benefit is?
> 
> So I’m asking and offering to update the LCAF document to reflect this. Agree?
> 

Sounds good to me. I just would like to see a ref to LCAF in the DDT document, so that we have a pointer toward were the 32 to 24 bits conversion is described.

ciao

L.

> Dino
> 
>> The change was consequence of the following comment that I made to the authors as shepherd:
>> 
>>>> Instance ID:
>>>> ————————
>>>> 
>>>> This document define the IID as a 32 bit field, how does it work with the 24 bit IID defined in RFC6830?
>>>> I would suggest that either you provide discussion on the above point or you refine the IID as 24 bit.
>>> 
>> 
>> The main point being: how do we shrink the 32bits IID in the 24bits field of the LISP header?
>> 
>> As for the explanation of Dino in this thread, the best thing is to leave 32 as value, but I would like to see an explicit explanation on how to go from 32bits  to 24 bits, referencing the LCAF document. It is just a clarification sentence to add.
>> 
>> ciao
>> 
>> L.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 27 Apr 2016, at 22:47, jmh.direct <[email-masked]> wrote:
>>> 
>>> Authors, was there a working group request for, or review of, this change?
>>> 
>>> Yours,
>>> Joel
>>> 
>>> 
>>> 
>>> Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
>>> -------- Original message --------
>>> From: Dino Farinacci <[email-masked]>
>>> Date: 4/27/2016 4:44 PM (GMT-05:00)
>>> To: "Joel M. Halpern" <[email-masked]>
>>> Cc: Anton Smirnov <[email-masked]>, [email-masked]
>>> Subject: Re: [lisp] I-D Action: draft-ietf-lisp-ddt-05.txt
>>> 
>>> On Apr 27, 2016, at 1:36 PM, Joel M. Halpern <[email-masked]> wrote:
>>>> 
>>>> I am a bit confused.  I suspect other working group members are as well.
>>>> The DDT document completed WG last call some time ago, and was waiting for some final edits, which were I believe just done.
>>>> The LCAF document has completed last call.
>>> 
>>> Well I lost track of the DDT document status.
>>> 
>>>> Dino, which document are you requesting be modified?  What modification are you asking for?
>>> 
>>> I am requesting a single change (in 2 places, see below). A change back from 24-bits to 32-bits describing the instance-ID. I don’t know why the change was done during this late stage in the draft. To me, that is a huge change.
>>> 
>>>> Or have I got it backwards, and Anton is asking for a modification?  As I said, I got lost.
>>> 
>>> I reviewed the changes in -05 and noticed this:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> And the change should not have happened since our intention at the very begninning was to have 2**32 VPNs.
>>> 
>>> There was no justification for this change and it happened very late in the process.
>>> 
>>> Dino
>>> 
>>>> 
>>>> Yours,
>>>> Joel
>>>> 
>>>> On 4/27/16 4:25 PM, Dino Farinacci wrote:
>>>>> Can you make the change so we can try to advance the document to last call?
>>>>> 
>>>>> Dino
>>>>> 
>>>>>> On Apr 27, 2016, at 1:23 PM, Anton Smirnov <[email-masked]> wrote:
>>>>>> 
>>>>>> we will consider this input for the next doc revision.
>>>>>> 
>>>>>> Anton
>>>>>> 
>>>>>> 
>>>>>>> On 04/27/2016 07:06 PM, Dino Farinacci wrote:
>>>>>>> 
>>>>>>>> Hi Dino,
>>>>>>>> since XEID prefix is not seen anywhere on the wire these words should not be viewed as normative; more like guidance for implementers. For DDT specification itself it is not important if IID is 24-bit, 32-bit or any other bit length. DDT relies on other control plane specifications (notably LCAF draft) to specify how IID looks like and how it is propagated in control messages.
>>>>>>> 
>>>>>>> If that is the case, why is the length included in the text then? I disagree though, the length is critically important because it conveys the maximum number of VPNs, per mapping system, that can be supported.
>>>>>>> 
>>>>>>>> LCAF draft currently depicts 32-bit space to store IID on the figure but then goes on saying:
>>>>>>>> 
>>>>>>>>> Instance ID:  the low-order 24-bits that can go into a LISP data
>>>>>>>>>    header when the I-bit is set.  See [RFC6830] for details.
>>>>>>> 
>>>>>>> Right, because that is the only way to fit 32-bits into 24. ;-)
>>>>>>> 
>>>>>>>> So IMO the ambiguity comes from the LCAF document. draft-ietf-lisp-lcaf should be more specific on IID length. Furthermore, if LCAF draft explicitly defined IID to be 32-bits then it should discuss what to do with excess bits in case of LISP encapsulation.
>>>>>>> 
>>>>>>> No, this is not true. And you might not have the history of DDT. But we put 32-bits in the DDT document and then had the encoding in the LCAF document reflect that.
>>>>>>> 
>>>>>>>> If DDT draft progresses before LCAF draft then it is more correct to be compatible with existing RFCs in saying that IID is a 24-bit value. DDT doc does not look like a proper place to redefine IID length from 24-bit to 32-bits.
>>>>>>> 
>>>>>>> The LCAF draft just ended last call and is going to IESG.
>>>>>>> 
>>>>>>>> If you strongly disagree with above then to unblock DDT spec from LCAF ambiguity we may remove explicit mention of IID bit length from DDT spec and put something like "IID as defined by the LCAF draft”.
>>>>>>> 
>>>>>>> You can’t remove it. You have to make it 32-bits otherwise you created an inconsistency that is (1) not needed and (2) for no good reason.
>>>>>>> 
>>>>>>> I suggest you leave that text alone and keep it at 32-bits.
>>>>>>> 
>>>>>>> Dino
>>>>>>> 
>>>>>>>> 
>>>>>>>> Anton
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 04/25/2016 09:49 PM, Dino Farinacci wrote:
>>>>>>>>> Authors, this change:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Is actually incorrect (change change is from 32 to 24). We have 32-bit
>>>>>>>>> Instance-ID encodings in the LCAF Instance ID Type and want to support
>>>>>>>>> that length in the control-plane EVEN THOUGH the data-plane can only
>>>>>>>>> hold 24-bits.
>>>>>>>>> 
>>>>>>>>> Meaning, if you use different mapping systems, you can actually reuse
>>>>>>>>> instance-IDs. This reuse was part of our initial intention.
>>>>>>>>> 
>>>>>>>>> Dino
>>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> lisp mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>> 
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 May 2016 10:10:43 -0700

> On May 2, 2016, at 1:36 AM, Luigi Iannone <[email-masked]> wrote:
> 
> 

How about this change? Please ack DDT authors and then supply a reference to draft-ietf-lisp-lcaf-13.

Once I get an ack, I’ll submit this post-last-call draft update.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 2 May 2016 14:42:48 -0400

I have a problem.  I was hoping to stay out of this.

But the proposed description does not work.

Since xTRs form overlapping sets, I don't see any way to assign IDs to 
Instances such that any given xTR does not need see the upper 8 bits of 
the instance-ID it receives.

If the argument were that we want future flexibility, so we are 
supporting 32 bits in the control plane, I could see it.  But as 
written, I would not know what to do in an Etr or ITR if I had an 
Instance ID with the upper bits set?  Do I truncate on send, and compare 
only the lower 24 bits upon receipt?  Once we start needing the upper 
byte, I don't see how that could work very long.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 May 2016 12:16:15 -0700

> I have a problem.  I was hoping to stay out of this.

Glad you joined in.

> But the proposed description does not work.

Well we can improve on it.

> Since xTRs form overlapping sets, I don't see any way to assign IDs to Instances such that any given xTR does not need see the upper 8 bits of the instance-ID it receives.

Well the lisp-vpn document could explain in more detail. We had one, it expired, and I think its going to refreshed soon. I’ll contact the authors.

> If the argument were that we want future flexibility, so we are supporting 32 bits in the control plane, I could see it.  But as written, I would not know what to do in an Etr or ITR if I had an Instance ID with the upper bits set?  Do I truncate on send, and compare only the lower 24 bits upon receipt?  Once we start needing the upper byte, I don't see how that could work very long.

Here is an example.

Say a network administrator wants to configure instance-IDs 0x800000ff and 0x000000ff each on different interfaces. Much like VRFs can be configured. This xTR *could* encap with this configuration but cannot decap. So let’s go through each direction:

(1) When a packet arrives on interface 0x800000ff, the ITR knows what map-cache to use based on the 32-bit instance-ID. If there is a cache miss, it can do a 32-bit lookup and the mapping system will certainly return RLOCs for the given EID being requested (the extended EID as defined in the DDT spec).

(2) Let’s say the RLOCs go to ETRs that are configured with instance-ID 0x800000ff. So when packets arrive at this ETR, the data header indicates 0x0000ff. The ETR has no problem finding the correct routing table for 0x0000FF (it is the same as 0x800000FF). That is there are two names for the table.

(3) Let’s say the RLOCs that are returned for an EID lookup for 0x000000FF (which is unique from 0x800000ff in the  mapping system) for another ETR. And that ETR is configured with only the instance ID 0x000000ff (just like the ETR in (2)). Here there is no problem. And encapsulated packets to 0x0000ff go to to the ETR for decap and delivery.

(4) If the ITR in (1) is also an ETR and gets encapsulated packets for 0x0000ff, it has some choices:

    (a) Don’t allow this to happen and disallow the configuration so the xTR in (1) looks like 
       the xTRs in (2) and (3).
    (b) Check both tables for an EID match. And use the one that matches. This assumes globally
       unique addresses so the EID is in either one or the other table but not both.
    (c) Do a source RLOC lookup where the xTR can register what instance-IDs it supports so you can get
       the other 8 bits.

This needs to be explained in a use-case document on the usage of assigning instance-IDs. The LCAF spec needs to resist putting these details in there, but just describe the encoding and the format of messages.

Comments?

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 2 May 2016 16:05:08 -0400

I would like to at least see a sentence indicating that if a 
configuration of egress processing needs instance IDs that differ on the 
upper 8 bits, they need separate ETR instances.

Using the incoming RLOC is risky at best, and probably will fail in 
real-world circumstances.

I think there needs to be some explanation in the LCAF draft.  The more 
verbose explanation can be in the VPN draft.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 May 2016 13:19:38 -0700

> I would like to at least see a sentence indicating that if a configuration of egress processing needs instance IDs that differ on the upper 8 bits, they need separate ETR instances.

See the new change below. I assume what you mean by “separate ETR instances”, that if the high order bits are the same, the ETR should be configure with a unique 24-bits. Please confirm.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 2 May 2016 16:22:45 -0400

I can live with that here.  I think the text in the VPN draft is going 
to be "interesting".

Yours,
Joel

On 5/2/16 4:19 PM, Dino Farinacci wrote:
>> configuration of egress processing needs instance IDs that differ on
>> the upper 8 bits, they need separate ETR instances.
>
> See the new change below. I assume what you mean by “separate ETR
> instances”, that if the high order bits are the same, the ETR should be
> configure with a unique 24-bits. Please confirm.
>
> Dino
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 May 2016 13:27:19 -0700

I’ll remember to comment and possibly show an example with ascii art.

Dino

> On May 2, 2016, at 1:22 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> I can live with that here.  I think the text in the VPN draft is going to be "interesting".
> 
> Yours,
> Joel
>

---

From: "Vina Ermagan (vermagan)" <[email-masked]>
Date: Mon, 2 May 2016 21:29:25 +0000

This seems fine to me, including the changes suggested by Joel. We¹ll
change the text in DDT to 32 bits for IID and referencing LCAF for more
details, in the next revision.

Best,
Vina

On 5/2/16, 10:10 AM, "lisp on behalf of Dino Farinacci"
<[email-masked] on behalf of [email-masked]> wrote:

>>> So how about this as a proposal. The DDT doc refers to 32-bits for the
>>>control-plane and RFC 6830 refers to 24-bits in the data-plane and the
>>>LCAF document explains how to map the 32 into 24 and what the benefit
>>>is?
>>> 
>>> So I¹m asking and offering to update the LCAF document to reflect
>>>this. Agree?
>>> 
>> 
>> Sounds good to me. I just would like to see a ref to LCAF in the DDT
>>document, so that we have a pointer toward were the 32 to 24 bits
>>conversion is described.
>
>Once I get an ack, I¹ll submit this post-last-call draft update.
>
>Dino
>

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 3 May 2016 10:40:57 +0200

Hello,

I am fine with the latest text proposed by Dino. Just a small question, should that “must” be actually a “MUST” as for RFC2119??

ciao

Luigi

> On 02 May 2016, at 23:29, Vina Ermagan (vermagan) <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 3 May 2016 05:10:21 -0700

I will change and submit today. 

Dino

> On May 3, 2016, at 1:40 AM, Luigi Iannone <[email-masked]> wrote:
> 
> Hello,
>