Subject: Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-01.txt

From: Dino Farinacci <[email-masked]>
Date: Mon, 3 Apr 2017 14:13:35 -0700

Enclosed are the diff files for both bis documents revision -02. These are comments we received during IETF week. We won’t submit until the commentors are okay with changes and at the same time wait for more comments to come in. We’ll wait 1 week to post.

Thanks,
Albert/Dino

> On Mar 31, 2017, at 2:33 PM, Dino Farinacci <[email-masked]> wrote:
> 
>> Hello,
>> 
>> Please find hereby some commentes about 6830bis:
> 
> Thanks for your comments Damien. See my responses inline. I have trimmed a lot of text to keep the email short. I have included only the text where you have commmented.
> 
>>> Abstract
>>> 
>>>   This document describes the Locator/ID Separation Protocol (LISP)
>>>   data-plane encapsulation protocol.
>>> 
>> DSA: /This document describes the data-plane protocol of the Locator/ID Separation Protocol (LISP)./
> 
> I will make the change.
> 
>>>   9.  Routing Locator Selection . . . . . . . . . . . . . . . . . .  23
>>>   10. Routing Locator Reachability  . . . . . . . . . . . . . . . .  24
>> DSA: what about creating a specific document for reachability? something like liveness problem?
> 
> Here are the reasons:
> 
> (1) We don’t want to have too many documents for someone to read to get the full picture of the LISP data-plane and control-plane. 
> 
> (2) We have broken it up where another data-plane has sufficient information to use the LISP control-plane in one document. If that data-plane wants to use the some data-plane features of LISP, they go examine RFC6830bis for it.
> 
> (3) It would be a very short document and we would have to add boilerplate, abstract, and introduction (with a definition section) which would be completely redundant with these two documents.
> 
>> 
>>>     10.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . .  27
>>>     10.2.  RLOC-Probing Algorithm . . . . . . . . . . . . . . . . .  28
>>>   11. EID Reachability within a LISP Site . . . . . . . . . . . . .  29
>> DSA: what about creating a specific document for reachability? something like liveness problem?
> 
> Same comment as above.
> 
>>>   12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . .  29
>>>   13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . .  30
>>>     13.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . .  31
>>>     13.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . .  32
>> DSA: Move to 33bis
> 
> Here are the reasons why we have not done this:
> 
> (1) We polled the working group in Chicago and there wasn’t any support for moving it.
> (2) Since the SMR is originated by an data-plane node (the ETR), it should be part of the data-plane document.
> (3) There will be alternatives to let a querier of the mapping system know about changes to a mapping. We are anticipating pub/sub solutions that are data-plane independent.
> 
>>>     13.3.  Database Map-Versioning  . . . . . . . . . . . . . . . .  33
>>>   14. Multicast Considerations  . . . . . . . . . . . . . . . . . .  34
>>>   15. Router Performance Considerations . . . . . . . . . . . . . .  35
>>>   16. Mobility Considerations . . . . . . . . . . . . . . . . . . .  36
>>>     16.1.  Slow Mobility  . . . . . . . . . . . . . . . . . . . . .  36
>>>     16.2.  Fast Mobility  . . . . . . . . . . . . . . . . . . . . .  36
>>>     16.3.  LISP Mobile Node Mobility  . . . . . . . . . . . . . . .  37
>>>   17. LISP xTR Placement and Encapsulation Methods  . . . . . . . .  37
>> DSA: What about moving that to a RFC7215bis?
> 
> Here are two reasons:
> 
> (1) We have decided that the network elements, in their purest form are introduced in this data-plane document and that more specific deployment scenarios belong in RFC7215.
> 
> (2) We don’t want this separation effort to create even more documents.
> 
>>> 1.  Introduction
>>> 
>>>   This document describes the Locator/Identifier Separation Protocol
>>>   (LISP). LISP is an encapsulation protocol built around the
>>>   fundamental idea of separating the topological location of a network
>>>   attachment point from the node's identity [CHIAPPA].  As a result
>>>   LISP creates two namespaces: Endpoint Identifiers (EIDs), that are
>>>   used to identify end-hosts (e.g., nodes or Virtual Machines) and
>>>   routable Routing Locators (RLOCs), used to identify network
>>>   attachment points.  LISP then defines functions for mapping between
>>>   the two numbering spaces
>> 
>> DSA: you talk about namespaces before, then numbering spaces, clarify/unify 
> 
> Will fix. Thanks.
> 
>>>   and for encapsulating traffic originated by
>>>   devices using non-routable EIDs for transport across a network
>>>   infrastructure that routes and forwards using RLOCs.
>>> 
>>>   LISP is an overlay protocol that separates control from data-plane,
>>>   this document specifies the data-plane, 
>> DSA: i.e.,
> 
> Can correct.
> 
>>> how LISP-capable routers
>>>   (Tunnel Routers) exchange packets by encapsulating them to the
>>>   appropriate location.  Tunnel routers are equipped with a cache,
>>>   called map-cache, that contains EID-to-RLOC mappings.  The map-cache
>>>   is populated using the LISP Control-Plane protocol
>>>   [I-D.ietf-lisp-rfc6833bis].
>> DSA: maybe write explicitly to see 33bis to have an example on how to populate them.
> 
> Well it is up to the querier to decide how to populate. For instance, a lig client that doesn’t even have a map-cache is a querier, it decides to do the lookup and simply print the Map-Reply results on a screen or UI.
> 
>>>   Creation of LISP was initially motivated by discussions during the
>>>   IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
>>>   October 2006 (see [RFC4984])
>>> 
>>>   This document specifies the LISP data-plane encapsulation and other
>>>   xTR functionality 
>> DSA: xTR never introduced before this, need to be explained.
> 
> Will fix.
> 
>>> 5.  LISP Encapsulation Details
>>> 
>>>   Since additional tunnel headers are prepended, the packet becomes
>>>   larger and can exceed the MTU of any link traversed from the ITR to
>>>   the ETR.  It is RECOMMENDED in IPv4 that packets do not get
>>>   fragmented as they are encapsulated by the ITR.  Instead, the packet
>>>   is dropped and an ICMP Too Big message is returned to the source.
>> DSA: Too Big is only for v6, no? in v4 it is fragmentation needed
> 
> Well the exact phrasing in RFC 792 is:
> 
> 
> 
> So I will change it to “fragmentation needed”.
> 
>>>  3.  When a packet is received by the ITR from a source inside of the
>>>       site and the size of the packet is greater than the effective MTU
>>>       stored with the Map-Cache entry associated with the destination
>>>       EID the packet is for, the ITR will send an ICMP Too Big message
>> DSA: same as above: Fragmentation Needed in IPv4
> 
> Will do same as above.
> 
>>>  RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
>>>   reachable when the R-bit for the Locator record is set to 1.  When
>>>   the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the
>>>   RLOC.  Neither the information contained in a Map-Reply nor that
>>>   stored in the mapping database system provides reachability
>>>   information for RLOCs.  Note that reachability is not part of the
>>>   mapping system and is determined using one or more of the Routing
>>>   Locator reachability algorithms described in the next section.
>>> 
>>> 10.  Routing Locator Reachability
>> DSA: what about creating a specific document for reachability? something like liveness problem?
> 
> Same reasons as for SMRs. See above comment.
> 
>>>   Continued research and testing will attempt to characterize the
>>>   tradeoffs of failure detection times versus message overhead.
>>> 
>>> 11.  EID Reachability within a LISP Site
>>> 
>> DSA: what about creating a specific document for reachability? something like liveness problem?
> 
> Same as for RLOC-reachability and SMRs.
> 
>>> 13.1.  Clock Sweep
>>> 
>>> 
>> DSA: maybe we could deprecate this feature (I don't see a reason to be in the specs, it is an implementation feature, isn't it?)
> 
> We should NOT depercate this feature. It is a way of timing out entries and important for map-cache management. And that is certainly something ITR specific and hence belongs in the data-plane document.
> 
>> 
>>> 13.2.  Solicit-Map-Request (SMR)
>>> 
>> DSA: why isn't SMR in 33bis? This stricly control-plane
> 
> See comment above.
> 
>>> 17.  LISP xTR Placement and Encapsulation Methods
>>> 
>> DSA: What about moving the entire Sec.17 to a RFC7215bis and just replace by a short paragraph referencing this bis?
> 
> See comment above why not to.
> 
>>>  Number values are in the range of 0 to 65535.  The allocation of
>>>   values is on a first come first served basis.
>>> 
>> 
>> That’s all for now :-)
> 
> Thanks again.
> 
> Dino
>

---

From: Damien Saucez <[email-masked]>
Date: Mon, 3 Apr 2017 23:40:13 +0200

Hello,

> On 31 mars 2017, at 23:33, Dino Farinacci <[email-masked]> wrote:
> 
>> Hello,
>> 
Who is we? The WG or the authors?

What is the difference between reading 50 pages in 2 documents or 50 pages well structured in 3 documents? People willing to have just a brief understanding of LISP may not be interested in knowing the liveness check techniques. On the other hand, many people know LISP but don’t know how liveness checks are performed, they would thus probably enjoy more a specific document that talk about that instead of having to decipher a large document that talks about everything.

> (2) We have broken it up where another data-plane has sufficient information to use the LISP control-plane in one document. If that data-plane wants to use the some data-plane features of LISP, the…
I am not sure I get it. For me liveness is a control-plane matter that may potentially use the data-plane. Also there are many possible solutions and that would be worth explaining the rational of each one, their pros and cons and in what environment to use them, hence the proposition of a separate document that can explain clearly that. 
>> DSA: what about creating a specific document for reachability? something like liveness problem?

Same answer as above.
> (1) We polled the working group in Chicago and there wasn’t any support for moving it.

Neither to keep it!

> (2) Since the SMR is originated by an data-plane node (the ETR), it should be part of the data-plane document.

No really a valid argument. Map-Requests, map-reply, map-notify … are originated by data-plane nodes, it doesn’t mean that map-request must be in data-plane, actually they are in the control-plane document already now.

For me SMR is really a control-plane matter. It is an element to permit the control of the content of the EID-to-RLOC cache and it is optional, the data-plane can work without this feature at all. Also in terms of implementation, the SMR is clearly implemented in the slow path as all exchanges involved in it are constituted of control-plane type packets.

> (1) We have decided that the network elements, in their purest form are introduced in this data-plane document and that more specific deployment scenarios belong in RFC7215.
Who is we? The WG or the authors?

The title of RFC7215 is " Network Element Deployment Considerations”, that seems to fit pretty well Sec. 17.

> (2) We don’t want this separation effort to create even more documents.
Who is we? The WG or the authors?

This is not creating new document, it is reorganization among documents. 7215 is about deployments, it thus makes sense to put everything related to deployment in it, so one that want to know anything about deployment will focus on this document.

> Well it is up to the querier to decide how to populate. For instance, a lig client that doesn’t even have a map-cache is a querier, it decides to do the lookup and simply print the Map-Reply result…

right, so what about changing to:

Tunnel routers are equipped with a cache,
  called map-cache, that contains EID-to-RLOC mappings.  The map-cache
  _CAN be_ populated using the LISP Control-Plane protocol
  [I-D.ietf-lisp-rfc6833bis].

> Same reasons as for SMRs. See above comment.

Same answer as for SMRs.
> Same as for RLOC-reachability and SMRs.

Same answer then.
> We should NOT depercate this feature. It is a way of timing out entries and important for map-cache management. And that is certainly something ITR specific and hence belongs in the data-plane docu…

I agree that deprecated is not the right word. For me it is an implementation detail, hence not needed to be document in the specs but of course it can be implemented.

See comment above.

> See comment above why not to.

See comment above why it would make sense to move.
>>>   values is on a first come first served basis.

Thanks

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 3 Apr 2017 17:46:53 -0700

> Who is we? The WG or the authors?

The initial people who started out this effort. That is, Albert, Luigi, you, and me.

> What is the difference between reading 50 pages in 2 documents or 50 pages well structured in 3 documents? 

It is more convenient to have things in one place. 

> People willing to have just a brief understanding of LISP may not be interested in knowing the liveness 

They can get a brief understanding from draft-ietf-lisp-introduction, which is already a separate document. Remember a few years ago, we thought it was worth while having an introduction to the architecture and protocols outside of the main specs. So we already have many specs.

> check techniques. On the other hand, many people know LISP but don’t know how liveness checks are performed, they would thus probably enjoy more a specific document that talk about that instead of having to decipher a large document that talks about everything.

If there are too many pieces, and a person that DOES want detail, will then not go to all the documents and can miss that. We already have 14 RFCs and I think the modularity we have is a fine balance.

> I am not sure I get it. For me liveness is a control-plane matter that may potentially use the data-plane. 

Echo-noncing is also a liveness mechanism. But since its defined part of the encapsulation header, it needs to be in the data-plane document. RLOC-probing is performed at non-forwarding time but it interacts with RLOC-probing, that is if nonces have been echoed, RLOC-probes may be suppressed. And only the data-plane cares about liveness since it cares about encapsulating to RLOCs that are reachable.

> Also there are many possible solutions and that would be worth explaining the rational of each one, their pros and cons and in what environment to use them, hence the proposition of a separate document that can explain clearly that. 

Again, if I was registering EID ‘damien’ with RLOC <gps-coordinates>, I would not care about using RLOC-probing because the RLOC is on attached to the Internet and you can’t encapsulate to it. So again, this is a data-plane function only.

> No really a valid argument. Map-Requests, map-reply, map-notify … are originated by data-plane nodes, it doesn’t mean that map-request must be in data-plane, actually they are in the control-plane…

Well we originally had those control-plane messages in one place. But we were forced to split it up. So we can’t have both. And all those message types you illustrate are originated by non data-plane nodes all the time. 

> For me SMR is really a control-plane matter. It is an element to permit the control of the content of the EID-to-RLOC cache and it is optional, the data-plane can work without this feature at all. Also in terms 

It cannot work without this feature. If an RLOC-set changes, and if the ITR doesn’t support this, it encapsulates packets to either black holes or to the wrong place.

> Who is we? The WG or the authors?

Albert and I prposed this at the working group in Berlin and Seoul.

>  [I-D.ietf-lisp-rfc6833bis].

That language is already there. Is it not? 

> I agree that deprecated is not the right word. For me it is an implementation detail, hence not needed to be document in the specs but of course it can be implemented.

Clock sweep is still recommended by vendors. And it should. 

Dino

---

From: Damien Saucez <[email-masked]>
Date: Tue, 4 Apr 2017 09:02:40 +0200

Hello,

> On 4 avr. 2017, at 02:46, Dino Farinacci <[email-masked]> wrote:
> 
> 

As far as I am concerned, I never asked to minimize the number of documents. Instead, I proposed/am proposing to have documents that answer clear questions.

> It is more convenient to have things in one place. 

If the question answered by the document is clear yes, otherwise, better have different document, each answering a clear question.

Another option that creating specific document would be to restructure 6830bis so to have one big section on liveness instead of having 
sections here and there talking about it. For example, merging 10 and 11 into one general section about reachability, and explain as an introduction
of this section that LISP changes the way we can see the reachability and that we have to consider both RLOC and EID reachability.

> They can get a brief understanding from draft-ietf-lisp-introduction, which is already a separate document. Remember a few years ago, we thought it was worth while having an introduction to the arc…
see above

> If there are too many pieces, and a person that DOES want detail, will then not go to all the documents and can miss that. We already have 14 RFCs and I think the modularity we have is a fine balan…

see above.
> Echo-noncing is also a liveness mechanism. But since its defined part of the encapsulation header, it needs to be in the data-plane document. RLOC-probing is performed at non-forwarding time but it…

and that is probably a design mistake of LISP where we mix control and data plane features inside the data-plane. It may look like an optimization but at the end it makes the implementation much more complex and blurs the design of the solution.

I would be interested to see how much echo-nonce is used in real deployments. In VxLAN that is very similar to LISP, there is no such mismatch and it does not seem to prevent it to work pretty well.

> Again, if I was registering EID ‘damien’ with RLOC <gps-coordinates>, I would not care about using RLOC-probing because the RLOC is on attached to the Internet and you can’t encapsulate to it. So a…

see above.
> Well we originally had those control-plane messages in one place. But we were forced to split it up. So we can’t have both. And all those message types you illustrate are originated by non data-pla…
Map-Request are used for RLOC probing and SMR and they explicitly appear in this data-plane document as data-plane features and now you say Map-Requests are not data-plane. So finally we agree that they should be in control-plane document as they are control-plane elements!
> It cannot work without this feature. If an RLOC-set changes, and if the ITR doesn’t support this, it encapsulates packets to either black holes or to the wrong place.

It can work without SMR as much as a xTR can work without Map-Request. Dealing with changes of mappings is a control-plane problem, so SMR is a control-plane problem.

> Albert and I prposed this at the working group in Berlin and Seoul.

As we already have intro that gives the general discussion and 7215 that discusses about the deployments, why having it also in 30bis?

> That language is already there. Is it not? 
ok.
> Clock sweep is still recommended by vendors. And it should. 

I agree that clock sweep may be interesting (though I am not really sure that in practice it is of real use as it is finally very slow and not flexible, but maybe you have a deployment case where clock sweep is used and without it it would not have been possible to do something). I still believe that Clock sweep is something related to deployments and constructor recommendations. For me it is not really part of the protocol, just a way to play with mappings. Anyway, compared to the rest, this is really a detail.

Thanks,

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 4 Apr 2017 10:29:53 -0700

> of this section that LISP changes the way we can see the reachability and that we have to consider both RLOC and EID reachability.

Sections are not here and there about RLOC reachability. There is one section (section 10) that explains two mechanisms. Section 11 talks about EID reachability which is completely different than RLOC reachability because it is site side (which discusses site partitioning) rather than core side.

> Map-Request are used for RLOC probing and SMR and they explicitly appear in this data-plane document as data-plane features and now you say Map-Requests are not data-plane. So finally we agree that…

Let me make this perfectly clear. I, in the first place, never wanted to separate this document. We have a possible requirement, at best, that other data-planes may want to use the LISP control-plane and for some reason they couldn’t look in RFC6830 for it. So now we split it up, and I said in the document, we’d have to make hard calls to not make this unmanageable. 

I think what we have right now is a decent balance.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Apr 2017 23:10:55 -0400

Just a reminder as co-chair that the document, and document(s) structure 
is owned by the working group.  The original contributors intent is 
important, as they thought about ti when preparing.  But the decisions 
rests with the WG membership, not "[t]he initial people who started out 
this effort."

So I do not think saying to Damien "because we like it better" is really 
an answer.

Yours,
Joel

On 4/3/17 8:46 PM, Dino Farinacci wrote:
>>> (1) We don’t want to have too many documents for someone to read
>>> to get the full picture of the LISP data-plane and control-plane.
>>>
>>>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 7 Apr 2017 09:53:06 -0700

I gave the reasons for why the documents are in the current state. I WAS not speaking for the working group. Albert had two presentations from Berlin and Seuol about how we started out dividing the functionality into the *2* existing documents.

Dino

> On Apr 6, 2017, at 8:10 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Just a reminder as co-chair that the document, and document(s) structure is owned by the working group.  The original contributors intent is important, as they thought about ti when preparing.  But the decisions rests with the WG membership, not "[t]he initial people who started out this effort."
> 
> So I do not think saying to Damien "because we like it better" is really an answer.
> 
> Yours,
> Joel
>