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

[Damien Saucez <[e-mail]>]

Hello,

> On 31 mars 2017, at 23:33, Dino Farinacci <[e-mail]> 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. 
> 
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, they go examine RFC6830bis for it.
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. 
> 
> (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.

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

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.

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



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

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

> 
>>>   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:
> 
> <PastedGraphic-9.png>
> 
> <PastedGraphic-10.png>
> 
> 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.

Same answer as for SMRs.
> 
>>>   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.

Same answer then.
> 
>>> 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.

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.

> 
>> 
>>> 13.2.  Solicit-Map-Request (SMR)
>>> 
>> DSA: why isn't SMR in 33bis? This stricly control-plane
> 
> See comment above.
> 
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.

See comment above why it would make sense to move.
> 
>>>  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.

Thanks

Damien Saucez 
> 
> Dino
>