Subject: [lisp] Comments to draft-ietf-lisp-introduction-04.txt

From: Dino Farinacci <[email-masked]>
Date: Mon, 28 Jul 2014 09:24:30 -0700

See my comments inline. The draft text comes first and is indented and my comments follow. I included only draft text that I have comments on. Thanks.

> 1.  Prefatory Note

This section should be titled "Introduction".

>    {{Suggestion by editors: Remove all the sections before "LISP
>    Overview" and write a straight-to-the-point introduction}}

Agree.

>    {{Suggestion by editors: The draft should focus on describing the
>    LISP architecture and avoid comparing loc/id split architectures with
>    other approaches}}

Agree.

>    This document is the first of a pair which, together, form what one
>    would think of as the 'architecture document' for LISP (the
>    'Location-Identity Separation Protocol').  Much of what would

If you do a good job, I am not sure you really need a pair of documents.

>    normally be in an architecture document (e.g. the architectural
>    design principles used in LISP, and the design considerations behind
>    various components and aspects of the LISP system) is in the second
>    document, the 'Architectural Perspective on LISP' document.
>    [I-D.ietf-lisp-perspective]

What is the plan for this document?

>    This 'Architectural Introduction' document is primarily intended for
>    those who are unfamiliar with LISP, and want to start learning about
>    it.  It is intended primarily for those working on LISP, but those
>    working with LISP, and more generally anyone who wants to know more
>    about LISP, may also find this document useful.

Agree on the intent.

>    This document is intended to both be easy to follow and it is
>    structured as a series of phases, each covering the entire system,
>    but with ever-increasing detail.  Reading only the first part of the
>    document will give a good high-level view of the system; reading the
>    complete document should provide a fairly detailed understanding of
>    the entire system.

Agree.

>    People who just want to get an idea of how LISP works might only read
>    the first part; they can stop reading either just before, or just
>    after Section 9.  People who are going to go on and read the protocol
>    specifications (perhaps to implement LISP) should read the entire
>    document.
> 
>    This document is a descriptive document, not a protocol
>    specification.  Should it differ in any detail from any of the LISP
>    protocol specification documents, they take precedence for the actual
>    operation of the protocol.

Make sure we capture this in the next rev.

> 3.  Initial Glossary

I think you should refer to the various documents for a glossary of terms. This was also Fabio's comment.

I also think this document should list the other RFCs that are related to the design and then a list of Internet Drafts that might be added to the working group charters in the future. A one-stop shop to finding all documents in one place is really very reader friendly.

> 5.  Deployment Philosophy
> 
>    {{Suggestion by editors: Remove the entire section, it can be
>    summarized by the last paragraph.  Furthermore the arguments used in
>    this sections are hard to follow since LISP has not been described
>    yet.}}

Agree.

> 5.1.  Economics
> 
>    {{Suggestion by editors: Remove this section, this has not been
>    discussed by the WG}}

Agree.

> 
> 5.2.  Maximize Re-use of Existing Mechanism
> 
>    {{Suggestion by editors: Remove/Summarize the entire section, the
>    arguments used in this section are hard to follow since LISP has not
>    been described yet.}}

Agree.

> 6.1.  Basic Approach
> 
>    {{Suggestion by editors: Merge this section with the previous one
>    (LISP Overview)}}

Agree.

> 6.2.  Basic Functionality
> 
>    {{Suggestion by editors: Rewrite this section: It is using non-
>    standard terminology to refer to standard LISP concepts ('enhance'
>    instead of encapsulate) It is using subjective terms (e.g., 'near'
>    the source) It is missing key LISP aspects such as that RLOC packets
>    are forwarded in the RLOC space }}

Agree.

> 6.5.  Security in LISP
> 
>    {{Suggestion by editors: Rewrite this section: (first 3 paragraphs)
>    It contains a general discussion as well as strong statements that
>    are not supported by any WG document.  (last 3 paragraphs) It
>    enumerates the security mechanisms specified in LISP but does not
>    describe them.}}

Agree. You should talk about 3 types of security:

(1) Data-Plane security and what the current goals are.
(2) Control-Plane security is what LISP-SEC solves.
(3) Mapping database security where one example is LISP-DDT-SEC.

> 
> 7.  Initial Applications
> 
>    {{Suggested by editors: Move this section after section 8, the
>    applications should not be described before LISP has been fully
>    described.

Agree.

>    {{Suggested by Noel: Reorder the whole section in popularity order?}}

Describe the architecture and protocol first, and then describe the use-cases so they can refer to terms and concepts previously mentioned.

> 
> 7.1.  Provider Independence
> 
>    Provider independence (i.e. the ability to easily change one's
>    Internet Service Provider) is a good example of the utility of
>    separating location and identity.

Since LISP has evolved so much, it turns out to be more of a mobility and overlay solution than a solution to solving the routing table problem, even though it does when deployed. So when discussing and describing EIDs and RLOCs, just note at that time that EIDs are provider independent and RLOCs are provider dependent.

> 
> 7.2.  Multi-Homing
> 
>    {{Suggested by editors: This section should be extended, it is
>    unclear the benefits that LISP brings to multihoming (.e.g, traffic
>    engineering, decoupled multihoming from the data-plane).

I think when you talk about RLOCs, you should indicate there is an RLOC-set that can contain multiple RLOC addresses. That is the ideal time to say you get multihoming out of LISP.

> 7.3.  Traffic Engineering
> 
>    {{Suggestion by editors: Merge this section with the previous one, TE
>    is not practical without multihoming}}

Well I think when you define and talk about ITRs and ETRs, and their interworking counter-parts PITRs and PETRs, that the mention of RTRs is a good place to introduce the concept. Then you can say how RTRs can do TE, even if they are reached via multiple RLOCs in an RLOC-set.

> 
> 7.4.  Routing
> 
>    {{Suggestion by editors: Remove this section, LISP is not a routing
>    protocol.}}

Agree 100%. LISP is an overlay and it depends on the routing system that it runs over. Nothing else should be stated. How LISP uses the underlay to get more efficient paths is what could be listed in the use-case section when RLOC selection, Segment Routing, and OAM may be mentioned.

> 7.5.  Mobility
> 
>    {{Suggestion by editors: Remove this section, mobility is not in
>    charter.}}

Mobility from a host perspective is not in the charter. And putting LISP-MN in hosts is not in the charter but general IP address (i.e. EID mobility is). We have a considerable amount of text in RFC 6830 that talks about mobility. And furthermore, since multi-homing is in the charter, when one changes  an RLOC address to connect to a new provider, that is, in effect, a mobility event.

> 7.7.  Virtual Private Networks
> 
>    {{Suggestion by editors: Remove this section, not covered by any WG
>    document}}

Put it in a use-case section that briefly describes it. And when you describe EIDs, indicate that an EID can be multiple-tuple hence a {IID, EID} is used for the VPN use-case.

> 7.8.  Local Uses
> 
>    {{Suggestion by editors: Remove this section.  The section contains a
>    general discussion about the applicability of LISP in intra-domain
>    scenarios, however it does not describe any specific application.}}

Agree.

> 
>    {{Preceeding paragraphs should probably get moved up into VPN
>    section?}}

Yes, agree.

> 8.  Major Functional Subsystems
> 
>    {{Suggestion by editors: This section should appear before since it
>    describes key aspects of LISP (e.g., LISP decoupled control and data-
>    plane).}}

Agree.

> 8.1.  Data Plane - xTRs Overview
> 
>    {{Suggestion by editors: Extend this section, it misses key LISP
>    data-plane aspects, such as the map-cache.}}

Yes, agree.

> 8.1.1.  Mapping Cache Performance
> 
>    {{Suggestion by editors: Push this section further in the document,
>    the cache performance is not a "Major LISP subsystem"}}

Agree.

> 8.2.  Control Plane - Mapping System Overview
> 
>    {{Suggestion by editors: Rewrite: Replace EID block terminology
>    (along with its description) with the very common term "prefix".
>    Describe Map-Request/Map-Reply LISP signaling messages.}}

Agree.

> 8.2.1.  Mapping System Organization
> 
>    {{Suggestion by editors: Rewrite: Describe key Mapping System
>    components: Map-Server/Map-Resolver}}

And describe how the mapping system is modular and any mapping database transport system can be plugged in. And then describe the various ones we considered in the past. To list them: DNS, DHTs, ALT, Emacs, Nerd, and DDT. It gives the reader the knowledge that we had many approaches to this.

> 8.2.2.  Interface to the Mapping System
> 
>    {{Suggestion by editors: has been rewritten: This section should
>    appear earlier since it describes key LISP components (Map-Request/
>    Map-Reply/Map-Server/Map-Resolver}}

Agree.

> 8.2.3.  Indexing Sub-system
> 
>    {{suggestion by editor: rename the section to "DDT"}}

We have to be careful here because ALT is in RFC stages and DDT is not even a working group document yet. We know the future is DDT, but the future will also have other/newer approaches as well.

> 9.1.  An Ordinary Packet's Processing
> 
>    {{Suggestion by editors: This section should be earlier in the
>    document structure, examples are important -particularly for
>    engineers- to explain how systems work}}

Yes, I have done 100s of LISP presentations and describing the packet flow first, assuming the map-cache is populated, is must easier for people to understand. Then next, present what happens when the map-cache is not populated, and then describe the interface to the mapping system, and then how the mapping transport system connects map-resolvers and map-servers together.

> 9.2.  A Mapping Cache Miss
> 
>    {{Suggestion by editors: (same as previous section)}}

Yes, my comment from above applies here too.

>    If a host sends a packet, and it gets to the ITR, and the ITR
>    determines that it does not yet have a mapping cache entry which
>    covers that destination EID, then additional processing ensues; it
>    has to look up the mapping in the mapping system (as previously
>    described in Section 6.2).
> 
>    The overall processing is shown below, in Figure 2:
> 
>                   -----            -----
>                  |     |    3     |     |
>    Map Resolver  |     | -------> |     |  Map Server
>                  |     |          |     |
>                   -----            -----
>                     ^                |
>    Key:             |                |
>                     |                |
>    -- = Control     |                |
>    == = Data        |                |
>                  2  |       5        |  4
>                     |      ---       |
>    Host A           |    /     \     |            Host B
>                     |  |_       \    V
>     -----          -----          \ -----          -----
>    |     |   1    |     |    6     |     |   7    |     |
>    |     | =====> | ITR | =======> | ETR | =====> |     |
>    |     |        |     |          |     |        |     |
>     -----          -----            -----          -----
> 
>                 Figure 2: Packet flow with missing mapping

I like this picture (came from UPC originally anyways). This should be very close to up front in the document. A picture says a 1000 words.

> 10.  Part II
> 
>    {{comment from editors: is that the role of an introductory document
>    to enter in such level of details and discuss (mostly) all fields of
>    the protocol? }}

It absolutely should not be. If we do this, the document set will be inconsistent and in contradiction. This document should not repeat any details that are in other documents. Especially since those documents are very more detailed than what this intro document should be.

> 11.  Design Approach
> 
>    {{Suggestion by editors: Remove this section, it does not describe/
>    discuss anything relevant, it is only providing a reference to
>    another non-WG document.}}

Agre.

> 12.  xTRs
> 
>    As mentioned above (in Section 8.1), xTRs are the essential LISP data
>    plane elements.  This section explores some advanced topics related
>    to xTRs.
> 
>    {{Suggestion by editors: remove next paragraph, brings nothing)}}
> 
>    Careful rules have been specified for both TTL and ECN [RFC3168] to
>    ensure that passage through xTRs does not interfere with the
>    operation of these mechanisms.  In addition, care has been taken to
>    ensure that traceroute works when xTRs are involved.

We need to colapse the coarse information that is here into the previous section. No details. One document that flows well and is short is what will win. Otherwise, this will be just another IETF document people can't read and digest.

> 12.3.  Header Control Channel
> 
>    {{Suggestion by editors: Rewrite this section to improve readability,
>    use standard terminology (e.g., Cache Coherence/Reachability instead
>    of "Header Control Channel").  Split the mechanisms depending on its
>    goal (cache coherence/reachability) and describe them under the same
>    context.}}

Agree.

> 12.3.3.  Instances
> 
>    {{Suggestion by editors: Move and extend this section: - Instance ID
>    is not a cache-coherence/reachability algorithm.  Describe where and
>    what is the Instance ID field Explain its applications}}

Agree.

> 12.4.  Probing
> 
>    RLOC-Probing is a mechanism method that an ITR can use to determine
>    with that an ETR is up and reachable from the ITR.  As a side-
>    benefit, it gives RTT estimates.
> 
>    To probe the reachability of an RLOC, an ITR sends a specially marked
>    Map-Request directly to the ETR it wishes information about; that ETR
>    sends back a specially marked Map-Reply.  A Map-Request message and a
>    Map-Reply message are used, rather than a special probing control-
>    message pair, because as a side-benefit the ITR can discover if the
>    mapping has been updated since it cached it.
> 
>    {{Suggestion from editors: remove the following sentence as it is not
>    motivated by strong arguments}} The probing mechanism is rather
>    heavy-weight and expensive (compared to mechanisms like the Echo-
>    Nonce), since it costs a control message from each side, so it should
>    only be used sparingly.

Agree.

> 12.5.  Mapping Lifetimes and Timeouts
> 
>    {{Suggestion by editors: Remove this section, TTL is a simple well-
>    known concept, we suggest to include a sentence (and hence remove
>    this section) in the control-plane section stating that mappings
>    include a TTL.

Agree.

> 12.6.  Mapping Gleaning in ETRs
> 
>    {{Suggestion by editors: Remove this section, gleaning is discouraged
>    since it rises many security concerns.}}

Agree 100%.

> 12.8.  Security of Mapping Lookups
> 
>    {{Suggestion from editors: would remove all what is related to
>    security and instead put a small summary in the security section and
>    reference the threats document}}

Since security is work in progress (and the documents that are stable have not really been tested throuoghly in practice) the description of security in LISP must be high-level.

> 13.  The Mapping System
> 
>    {{Suggestion by editors: This section is somewhat redundant with
>    respect to section 8.2, we suggest to move this section to Part I
>    since it provides some missing details.}}

Agree.

> 13.1.1.  Map-Request Messages
> 
>    {{Suggestion from editors: should come much earlier as it is an
>    essential message in LISP}}

Agree and the only aspect of Map-Request, Map-Register, Map-Reply, Map-Referral, and Map-Notify messages should be what is being conveyed and to where. The details of encoding is way too detailed.

The goal of this document is be be able to change details and add use-cases to LISP without having to change the document. We should at least strive for that if reality doesn't play it out that way.

> 13.1.2.  Map-Reply Messages
> 
>    {{Suggestion from editors: should come much earlier as it is an
>    essential message in LISP}}

Yes, same comment as right above.

> 13.1.3.  Map-Register and Map-Notify Messages
> 
>    {{Suggestion by editors: As noted by the author add a paragraph
>    describing how a xTR de-registers an EID-to-RLOC mapping.}}

Yes!

>    {{Suggestion by editors: add a small paragraph to explain what Map-
>    Registers are used for}}

Yes, same comment as right above. I think you can summarizing all control-plane messages in one section. One section, with one paragraph per message type.

> 
> 13.2.  The DDT Indexing Sub-system
> 
>    {{Suggestion from the editors: this section does not add any
>    fundamental value to the DDT overview section, propose to remove it
>    to only keep the overview; too much details that should not appear in
>    an intro document}}

Agree.

> 13.3.  Reliability via Replication
> 
>    {{Suggestion by editors: Remove this section, describes operational
>    practices/policies of the DDT infrastructure, this is beyond the
>    scope of this document.}}

Agree.

> 13.4.  Security of the DDT Indexing Sub-system
> 
>    {{Suggestion by editors: Remove this section, provides unnecessary
>    details of DDT.}}

Agree.

> 13.5.  Extended Capabilities
> 
>    {{Suggestion by editors: Remove this section, not discussed in any WG
>    document.}}

Agree.

> 13.6.  Performance of the Mapping System

This is an intro document, not an analysis document. This section should be removed IMO.

> 14.  Multicast Support in LISP
> 
>    {{Suggestion by editors: Rewrite this section, it provides too many
>    details.  Reduce it to a brief description of LISP Multicast}}

Agree 100%. It should simply be stated that multicast packets can be encapsulated in multicast and unicast RLOCs with any combination of underlay signaling, overlay signaling, or no signaling. And that Replication Engineering is necessary to optmize paths and minimize head-end replication in the unicast RLOC case.

> 14.2.  Initial Multicast Support in LISP
> 
>    {{Suggestion by editors: remove this paragraph}}

Ack.

> 15.  Deployment Issues and Mechanisms
> 
>    {{Suggestion by editors: Remove this section, provides unnecessary
>    details.  Add a reference to the deployment RFC.}}

Agree.

> 15.2.1.  Proxy LISP Routers
> 
>    {{Suggestion by editors: Move this section to Part I.  PxTRs are an
>    important aspect of LISP and as such, should be described before.
>    Furthermore simplify it, it currently contains too many details plus
>    an additional discussion on the impact of PITR that is out of the
>    scope of the document.}}

Agree. Where you first introduce the concept of PITRs and PETRs that is where you mention a little more about interworking.

> 15.2.2.  LISP-NAT
> 
>    {{Suggestion by editors: Remove this section, LISP-NAT is not a WG
>    document neither an inter-networking mechanisms.}}

I agree. It is a suggestion in the interworking spec but the deployment spec does not recommend to use it so PxTRs is what we should focus on.

> 15.3.  Use Through NAT Devices
> 
>    {{Suggestion by editors: Remove this section, LISP-NAT is not a WG
>    document neither an inter-networking mechanisms.}}

This is meant to describe NAT-traversal not LISP-NAT for interworking. I think the problem is important to solve but just explain what I said above about how RLOCs can be private or public and the Map-Servers can teach the xTRs what their global RLOC addresses are.

> 15.4.  LISP and Core Internet Routing
> 
>    {{Suggestion by editors: Remove this section, this is already
>    explained in lisp-deployment}}

Agree.

> 16.  Fault Discovery/Handling
> 
>    {{Suggestion by editors: Remove this section, although this section
>    helps understanding how many of the LISP mechanisms work
>    (particularly the ones described in section 12) it provides an
>    unnecessary level of (operational) detail.  This level of
>    understanding should be achieved reading the main LISP spec. }}

Agree.

> 16.3.  Erroneous Mappings
> 
>    {{Suggestion by editors: this section brings nothing, remove it}}

Agree.

> 
>    Again, this should not happen, but a good system should deal with it.
>    However, in practise, should this happen, it will produce one of the
>    prior two cases (the wrong ETR, or something that is not an ETR), and
>    will be handled as described there.
> 
> 16.4.  Verifying ETR Liveness
> 
>    The ITR, like all packet switches, needs to detect, and react, when
>    its neighbour ceases operation.  As LISP traffic is effectively
>    always uni-directional (from ITR to ETR), this could be somewhat
>    problematic.
> 
>    Solving a related problem, "neighbour ETR" "reachability" below)
>    subsumes handling this fault mode, however.
> 
>    {{Suggestion by editors: remove next paragraph }}

Put reachability in one section when you talk about overlay/underlay interaction.

> 17.  Acknowledgments
> 
>    This document was initiated by Noel Chiappa, and much of the core
>    philosophy came from him.  We acknowledge the important contributions
>    he has made to this work and thank him for his past efforts.

This section should also thank the RRG from the IRTF as well as the LISP WG from the IETF.

> Appendix A.  Glossary/Definition of Terms
> 
>    {{Suggestion by editors: remove and use those from RFCs instead }}

Agree.

> Appendix B.  Other Appendices
> 
> B.1.  A Brief History of Location/Identity Separation

This section should be removed or shortened quite a bit. And it should be part of the intro if shortened. But it needs to be short, if added to the top of the document.

> B.2.  A Brief History of the LISP Project
> 
>    {{Suggestion by editors: remove that makes no sense in this document
>    }}

Agree. This can be moved to the LISP wiki.

> B.4.  The ALT Mapping Indexing Sub-system

This should not be in an appendix. It should be in the section that describes the indexing system in general and give some examples of a few of them. Pointers to drafts are imperative IMO.

> B.5.  Early NAT Support

I think the description of NAT-traversal should be integrated with the description of RLOCs. And just note how LISP can work behind NATs and how an xTR will distinguish a private RLOC from a public RLOC.

That's all for now. Looking forward to the next revision.

Thanks,
Dino

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 28 Jul 2014 23:23:16 +0200

Hi Dino

I´ve noted all the comments for which we both agree, please see my
comments below:

> See my comments inline. The draft text comes first and is indented and my comments follow. I included only draft text that I have comments on. Thanks.

[snip]

> What is the plan for this document?

This is a non-WG document and I suggest not to cite it.

[snip]

> Well I think when you define and talk about ITRs and ETRs, and their interworking counter-parts PITRs and PETRs, that the mention of RTRs is a good place to introduce the concept. Then you can say…

lisp-te is not part of the WG and I suggest to stick to WG items. We
can include them in the use-cases appendix.

> Agree 100%. LISP is an overlay and it depends on the routing system that it runs over. Nothing else should be stated. How LISP uses the underlay to get more efficient paths is what could be listed…

Ok, I also think that it makes sense to add them in the use-cases.

> Mobility from a host perspective is not in the charter. And putting LISP-MN in hosts is not in the charter but general IP address (i.e. EID mobility is). We have a considerable amount of text in RF…

Good point! We´ll indeed mention it.

[snip]

> We have to be careful here because ALT is in RFC stages and DDT is not even a working group document yet. We know the future is DDT, but the future will also have other/newer approaches as well.

DDT is an expired WG document
(https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/).

[snip]

> This is meant to describe NAT-traversal not LISP-NAT for interworking. I think the problem is important to solve but just explain what I said above about how RLOCs can be private or public and the…

You mean section 8.4 of RFC6830?

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 28 Jul 2014 14:28:06 -0700

> This is a non-WG document and I suggest not to cite it.

Okay. I can agree with that.

> can include them in the use-cases appendix.

RTRs are defined in RFC 6830. We need to mention them. We can say RTRs are used in future use-cases (even though they are already being used), such as TE, NAT-traversal, scaling mapping changes, etc.

> (https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/).

Darrel is working on getting it resubmitted.

> You mean section 8.4 of RFC6830?

Yes.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Jul 2014 17:37:57 -0400

I have no problem with removing the citation of perspective, as that is 
probably stalled and likely to be dropped if we do a good job on intro.

But please, do not claim it is a non-WG document.  It was adopted by the WG.

Yours,
Joel

> Okay. I can agree with that.
...

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 28 Jul 2014 22:13:10 +0000

> (https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/).

And the authors/editors are working to refresh it now, and want to progress the document.

-Darrel

---

From: Albert Cabellos <[email-masked]>
Date: Tue, 29 Jul 2014 01:10:46 +0200

Hi Dino

Please see below:

> RTRs are defined in RFC 6830. We need to mention them. We can say RTRs are used in future use-cases (even though they are already being used), such as TE, NAT-traversal, scaling mapping changes, et…

True, I forgot, I´ll include them.

Albert