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

[Dino Farinacci <[e-mail]>]

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