Subject: Re: [lisp] 6830bis Review

From: Luigi Iannone <[email-masked]>
Date: Tue, 9 Jan 2018 16:04:04 +0100

HI Albert,

thanks for your reply. 

My comments inline. (trimming what is OK for me)

Luigi

> On 27 Dec 2017, at 02:48, Albert Cabellos <[email-masked] <mailto:[email-masked]>> wrote:
> 

[snip]
> >
> >
> >   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
> >      IPv6) value used in the source and destination address fields of
> >      the first (most inner) LISP header of a packet.  The host obtains
> >      a destination EID the same way it obtains a destination address
> >      today, for example, through a Domain Name System (DNS) [RFC1034]
> >      lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
> >      The source EID is obtained via existing mechanisms used to set a
> >      host's "local" IP address.  An EID used on the public Internet
> >      must have the same properties as any other IP address used in that
> >      manner; this means, among other things, that it must be globally
> >      unique.  An EID is allocated to a host from an EID-Prefix block
> >      associated with the site where the host is located.  An EID can be
> >      used by a host to refer to other hosts.  Note that EID blocks MAY
> >      be assigned in a hierarchical manner, independent of the network
> >      topology, to facilitate scaling of the mapping database.  In
> >      addition, an EID block assigned to a site may have site-local
> >      structure (subnetting) for routing within the site; this structure
> >      is not visible to the global routing system.  In theory, the bit
> >      string that represents an EID for one device can represent an RLOC
> >      for a different device.  As the architecture is realized, if a
> >      given bit string is both an RLOC and an EID, it must refer to the
> >      same entity in both cases.
> >
> >
> > Is the above sentence really necessary?
> >
> 
> Agreed, why not simplify the definitions. They are written from the ‘Internet scalability mindset’, why not say that an EID is an address of the overlay and an RLOC an address of the overlay. This change may require further changes on the document so I am not 100% sure if this is a good idea.

For clarification I was just referring to the sentence:

 " As the architecture is realized, if a given bit string is both an RLOC and an EID, it must refer to the same entity in both cases.” 

I am wondering if such constrain is really necessary. If namespaces are well scoped there is no need for this. 

[snip]

About the following:

> 
> >
> >   o  EIDs are typically IP addresses assigned to hosts.
> >
> >   o  Other types of EID are supported by LISP, see [RFC8060] for
> >      further information.
> >
> > I would put the last two bullets in the definition of EID. It simplifies the story here.
> >
> >
> 
> I suggest to leave them here, I don´t think that readers start from the ‘Definition of terms’, these are relevant concepts to understand LISP.

Good point about de definition of terms. What really bothers me is the bullet organisation. What can be done is to merge these two bullets with the previous one. 

> 
> >
> > The description of the encap/decap operation lacks of clarity concerning how to deal with
> > ECN bits and DSCP .
> >
> > 1. I think that the text should make explicitly the difference between DSCP and ECN fields.
> >
> > 2. How to deal with ECN should be part of the description of the  encap/decap not a paragraph apart.
> >    This basically means that half of the last paragraph should be a bullet of the ITR/PITR encapsulation
> >    and the other half  in the ETR/PETR operation.
> 
> 
> Agreed, what about this (please comment):
> 
>    When doing ITR/PITR encapsulation:
> 
>     o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
>     o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header DSCP field ('Traffic Class' field, in the case of IPv6) considering the exception listed below.
>    o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header.
> 
> When doing ETR/PETR decapsulation:
> 
>    o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header.  Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycles.  This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site.
>    o  The inner-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header DSCP field ('Traffic Class' field, in the case of IPv6) considering the exception listed below.
>    o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR.  These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints.
> 
> Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1.
> 
> Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration.  See Section 18.3 for TTL exception handling for traceroute packets.
> 

Text looks very good to me.

> 
> >
> > Large part of this section is about control plane issues and as such should be put in 6833bis.
> >
> > What this section should state is that priority and weight are used to select the RLOC to use.
> > Only exception is gleaning where we have one single RLOC and we do not know neither priority nor weight.
> >
> > All the other operational discussion goes elsewhere, but not in this document.
> >
> 
> Agree, I suggest moving it to 6833bis. What to leave in 6830bis is less obvious, maybe something like (not final, just a couple of ideas):
> 
> The data-plane must follow the state stored in the map-cache to encapsulate and decapsulate packets. The map-cache is populated using a control-plane, such as [6833bis]. ETRs encapsulate packets following the Priorities and Weights stored in the map-cache.
> 

Yes, this is what I meant.

> Actually we should merge this section with 'Routing Locator Hashing'
> 
> 

I think is a good idea.

[snip]
> > 13.  Changing the Contents of EID-to-RLOC Mappings
> >
> >
> > This is a control plane issue, as such it has to go in 6833bis, with two exception:
> > The very first paragraph stetting the problem, and the versioning subsection, because it is a data-plane mechanism.
> >
> > All of the rest 6833bis
> >
> > Actually I remember a suggestion about putting operations issues like this in an OAM document which would be a good idea.
> >
> >
> 
> So you are suggesting that the LISP control-plane does not define any mechanism to update EID-to-RLOC mappings? 
> 

Not exactly. Control-plane should discuss how to change the mappings, but things like clock sweep is just management not a control plane mechanism, as such it does not really needs to be standardised because there are no interoperability issues, hence it make really sense  to put it elsewhere.

Thanks

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 9 Jan 2018 16:05:03 +0100

Hi,

On 27 Dec 2017, at 05:13, Dino Farinacci <[email-masked]> wrote:

[snip]
> I had planned to take Luigi’s suggestion. I did not want to rewrite this section. It was carefully written by David Black with consolation from the ECN experts. I do not want to lose this technical text.

The text proposed by Albert is very close to the original and has exactly the same content, just expressed in an clearer way. No loss here.
I will ask David to review the text again.

The current text in section 5.3 is still not correct because it talks about “type of service” and “ECN”. 

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 9 Jan 2018 09:54:59 -0800

Guys, please look at the latest changes instead of hashing the same arguments. 

This is what I am going to do. I am going to submit the myriad of changes already agreed to and then we can open up comments again for -08. I have been holding these diffs for a few weeks now and have received little commentary on the latest changes. So if your points have not been addressed, state them again AFTER reading the changes to -08.

The diff of the changes are included yet again.

Dino

> On Jan 9, 2018, at 7:04 AM, Luigi Iannone <[email-masked]> wrote:
> 
> 
> HI Albert,
> 
> thanks for your reply. 
> 
>> On 27 Dec 2017, at 02:48, Albert Cabellos <[email-masked]> wrote:
>> 
> 
> [snip]
>> >
>> >
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 10 Jan 2018 11:03:17 +0100

Dino,

> On 9 Jan 2018, at 18:54, Dino Farinacci <[email-masked]> wrote:
> 

I find this request unfair. 
I spent quite a bit of time reviewing and discussing this document, now you just try to wash all out by requesting comments on -08.

Please let's continue discussing on the open issues so to find a solution.

Thanks

Luigi

> <rfcdiff-rfc6830bis.html>
>

---

From: Damien Saucez <[email-masked]>
Date: Wed, 10 Jan 2018 14:32:25 +0100

Hello Dino,

Thanks for the efforts.

The propositions in -08 are fine but are addressing only minor
details. As long as the structure of the document is not
fundamentally re-worked the document will remain poor and
barely readable for who doesn’t know LISP yet.

I already clearly gave my comments about all this, I don’t need
to repeat myself.

Regards,

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Jan 2018 09:26:38 -0800

From my perspective on the situation:

(1) I made changes exactly to text that was requested.
(2) I sometimes modify what the text that was requested.
(3) I disgree with some text so don’t include it.
(4) I have made many sub-revisions of -08.
(5) Comments are coming in throughout the review period and I don’t know what revision you have read and what you have not read. I don’t know if your comments are old or based on one of the revisions. Because I see comments that I addressed but its not clear to me you know that (or at least you have not told me).
(6) The changes in (1) and (2) have not been confirmed or denied by commenters. So I don’t know if what I changed has been accepted.
(7) Adding text to something that has changed won’t go in properly. So referencing some offered text in a previous email can’t be just inserted.

So -08 has been submitted. I don’t know what are the outstanding issues at this point. So I need commenters to be specific. This is what I suggest:

(1) List the open issues by commenting on the latest submitted -08.
(2) Include text from the -08 draft and your comments follow with suggested text.

Let’s use that as a base to comment and discuss further. I can’t read your minds so I need more of your help. So please put more effort into it.

Thanks in advance for your support,
Dino

> On Jan 10, 2018, at 2:03 AM, Luigi Iannone <[email-masked]> wrote:
> 
> Dino,
>

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Thu, 11 Jan 2018 15:21:34 +0100

Adding my two cents to this discussion, in the hope that it helps with
the convergence.

My original hope with the reorganization of the RFCs was to be able to
use the LISP control-plane with a non-LISP data-plane. Putting aside
the discussion of what goes where, and with some pragmatism in mind, I
think we're close to that with the current 6833bis. The major
roadblock for me is the lack of SMR in that document, and I think this
aligns with the view of others in the list.

I believe that with the addition of SMR, 6833bis will have all the
required pieces to put together a viable LISP deployment (using a
non-LISP data-plane) without having to look into 6830bis. Sure, there
would be some mechanisms (e.g. RLOC probing) that would not be
available using only 6833bis, but I could live without those. In
addition, we could work on adding some extra explanation to the
introduction of 6833bis so a non-familiar reader could make use of
LISP without looking into 6830bis.

I think these two things (i.e. move SMR and extend 6833bis intro)
would minimize the changes required on the current documents and would
allow us to reach some rough consensus to make progress with the docs.
What do you guys think?

Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 11 Jan 2018 09:50:02 -0800

Thanks Alberto for your comments. Here is how I break up items in the control-plane and the data-plane. 

Control-Plane (6833bis document):

(1) The definition of control-plane messages. These are already documented in 6833bis.
(2) What components make up the control-plane that are not also in the data-plane. That is Map-Servers, Map-Resovers, LISP-ALT nodes, LISP-DDT nodes. These are already documented in 6833bis.

Data-Plane (6830bis document):

(1) What is required to move packets. Which includes the encapsulation format and the database-mappings and map-cache xTRs use. These are already documented in RFC6830bis.
(2) The components that make up the data-plane. That is ITRs, ETRs, PxTRs, and RTRs.
(3) And the elements of operation that the components in (2) use. So RLOC-probing and SMRs are explained in RFC6830bis because the components in (2) use. They are using control-plane messages obviously but those messages are defined in 6833bis.

Note that ETRs send SMRs, note ITRs and PITR send RLOC-probes. These messages are not sent by any control-plane components. Another data-plane can be defined to do its own OAM or map version updating and use the messages defined in 6833bis to do that. But they could also might “let me try to use the same map-cache mechanisms as LISP but use a different encapsulation format”. In this case, an implementor or deployer would read 6830bis.

Having said that, people don’t create walls between getting information so if they want to do their own data-plane they can still read 6830bis.

Another point about SMRs, the entire section talks about what ITRs and ETRs do. And these devices are data-plane components. Putting this section in 6833bis would possibly surprise a reader implementing another data-plane. For instance, a VXLAN data-plane reader would say “what is an ITR and ETR? I have VTEPs”. Another point about SMRs, they can be data driven. This happens when an ITR encapsulates to an ETR where the EID is no longer residing. That ETR, could respond with a SMR to the ITR to inform it that it has out of date mappings. This is all data-plane driven. Wouldn’t make logical sense to put it in 6833bis.

Anyways, that is the way I look at it,
Dino

> On Jan 11, 2018, at 6:21 AM, Alberto Rodriguez-Natal <[email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Jan 2018 12:56:44 -0500

Working group:

I see folks making a case for SMR being in either 6830bis or 6833bis.
It is up to the WG.
What say you?

Yours,
Joel

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 12 Jan 2018 12:01:34 +0100

> On 11 Jan 2018, at 18:50, Dino Farinacci <[email-masked]> wrote:
> 
> Another point about SMRs, the entire section talks about what ITRs and ETRs do. And these devices are data-plane components. Putting this section in 6833bis would possibly surprise a reader implementing another data-plane. For instance, a VXLAN data-plane reader would say “what is an ITR and ETR? I have VTEPs”.

This reasoning does not hold.

[dhcp164-133] ~/Desktop # grep -c ITR draft-ietf-lisp-rfc6833bis-07.txt 
65
[dhcp164-133] ~/Desktop # grep -c ETR draft-ietf-lisp-rfc6833bis-07.txt
83
[dhcp164-133] ~/Desktop # grep -c xTR draft-ietf-lisp-rfc6833bis-07.txt
20
[dhcp164-133] ~/Desktop # 

Whoever reads 6833bis has to know what an ITR and an ETR is and what it does.

L.

> Another point about SMRs, they can be data driven. This happens when an ITR encapsulates to an ETR where the EID is no longer residing. That ETR, could respond with a SMR to the ITR to inform it that it has out of date mappings. This is all data-plane driven. Wouldn’t make logical sense to put it in 6833bis.
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 12 Jan 2018 09:38:35 -0800

Let me put it even simpler for you Luigi. Say someone wants to write a client program that uses the LISP control-plane documented in 6833bis. A perfect example of this is a lig client (RFC 6835). 

If SMRs and RLOC-Probing were to be documented in 6833bis, the lig client implementor would be wondering if it needs to implement SMRs and RLOC-probes. A lig client simply looks up an EID and prints out the RLOC-records.

Conclusion, SMRs and RLOC-probes are used by xTRs to be able to run the data-plane. xTRs are data-plane components. Therefore SMRs and RLOC-probes should stay in 6830bis, the data-plane specification.

Dino

> On Jan 12, 2018, at 3:01 AM, Luigi Iannone <[email-masked]> wrote:
> 
> 
>

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 15 Jan 2018 10:53:30 +0100

> On 12 Jan 2018, at 18:38, Dino Farinacci <[email-masked]> wrote:
> 
> Conclusion, SMRs and RLOC-probes are used by xTRs to be able to run the data-plane.

SMRs and RLOC-probes are control-plane features used by xTRs to be able to run the data-plane.

As such they go in 6833bis.

L.

> xTRs are data-plane components. Therefore SMRs and RLOC-probes should stay in 6830bis, the data-plane specification.
> 
> Dino
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Jan 2018 09:55:38 -0800

> SMRs and RLOC-probes are control-plane features used by xTRs to be able to run the data-plane.

They are data-plane features that use control-plane messages. No other devices sends an RLOC-probe (or SMR) then an xTR. And the elements of operation are based on the map-cache. Any manipulation of the map-cache SHOULD NOT go in 6833bis.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Jan 2018 13:10:50 -0500

<chair hat on> Let's try to separate things.

1) The fact that the messages are used only between xTRs does not tell 
us whether it is control or data.
2) The manipulation of map-cache may well be control (for example, if we 
were using a push-based control mechanism then map-cache control would 
be largely control.

</chair hat on>

<chair hat off>
Personally, it looks to me like SMR is a control mechanism.  It is 
information to control the operation of the xTR.  It is not data plane 
behavior.  It is driven from and drives control behavior.

One could argue that RLOC-probes are more borderline in tha tthey 
themselves behave more like data packets.  Still, my own thought process 
is to think of them as control operations.

The actual argument that can be made is that the capabilities these 
provide could be provided by another mechanism when another data plane 
is used.  But the capability needs to exist.  Putting these mechanisms 
in the control plane document makes it much easier to have the 
discussion about the fact that the control plane needs these functions 
to be robust.
After all, there is no goal that these are completely separate and 
independent entities.  Even if it may turn out that with sufficient care 
the control plane can be used for other things.
</chair hat off>

<chair hat on>  (Yes, my hats are bouncing.)
I would really like to hear from other WG members about this.  It is the 
WGs document.  The chairs would prefer not to simply use their own 
judgment.  So to repeat Luigi's plea: speak up.
</chair hat on>

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Jan 2018 10:16:35 -0800

> I would really like to hear from other WG members about this.  It is the WGs document.  The chairs would prefer not to simply use their own judgment.  So to repeat Luigi's plea: speak up.
> </chair hat on>

And if there is silence, then what?

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Jan 2018 13:18:22 -0500

If there is silence, the chairs will make their best judgment on behalf 
of the working group.  That is our job.

The other choice is that we block the document until there are enough 
voices.  I would prefer not to do that.

Yours,
Joel

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Mon, 15 Jan 2018 19:32:41 +0100

On Mon, Jan 15, 2018 at 6:55 PM, Dino Farinacci <[email-masked]> wrote:
> They are data-plane features that use control-plane messages. No other devices sends an RLOC-probe (or SMR) then an xTR.

IMHO I think that the SMR should go into the control-plane document. I
believe that there are many cases (specially from an SDN point of
view) where you may want to send SMRs from entities other than xTRs.

There's already a draft [1] that proposes that SMRs can also be sent
by MSMRs. That draft is documenting what has been implemented and
running on OpenDaylight for a while now.

Furthermore, lig-lispmob [2] supports sending SMRs on demand through a
CLI without running an xTR. I've found that capability useful on many
occasions.

Alberto

[1] https://tools.ietf.org/html/draft-rodrigueznatal-lisp-ms-smr-04
[2] https://github.com/LISPmob/lig-lispmob

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Jan 2018 11:10:35 -0800

I’d be willing to make a deal.

SMRs go to 6833bis and RLOC-probes stay in 6830bis. Since RLOC-probes are connected (semantically) to echo-noncing which use bits in the LISP header.

Dino

> On Jan 15, 2018, at 10:32 AM, Alberto Rodriguez-Natal <[email-masked]> wrote:
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 15 Jan 2018 19:57:40 +0000

I also believe SMRs should be in the CP doc. I would support Dino’s  proposal below.

Regards,
Reshad.

On 2018-01-15, 2:10 PM, "lisp on behalf of Dino Farinacci" <[email-masked] on behalf of [email-masked]> wrote:

    
    Dino