Re: [lisp] 6830bis Review (PLEASE COMMENTS)

[Luigi Iannone <[e-mail]>]

Dino,

thanks for the hard work. 
my replies inline (trimmed the points we agree or have been clarified by your answers).


@ALL:   this is not a private discussion between me and Dino and I invite all of you to chime in and provide an opinion.

There one clear point here:  This document is not about data-plane, is data-plane + fragmented information that does not belong here. 
The document can be shorter and to the point. There are a lot of OAM information that does not belong to the data-plane.


> On 17 Dec 2017, at 22:37, Dino Farinacci <[e-mail]> wrote:
> 
>> Detailed comments inline.
> 
> Thanks for your comments. A diff and txt file are enclosed at the bottom.
> 
>> p.s. @Dino: sorry this is 07 version because I started with that version.
> 
> No worries.
> 
>> the wording “data-plane protocol” sounds awkward to me. I think would be better to put "data-plane operations” or even better “data-plane specifications”
>> Best solution: just drop it. This document describes the data plane of LISP.  
>> 
>> 
>>> for the Locator/ID
>>>  Separation Protocol (LISP).  LISP defines two namespaces, End-point
>>>  Identifiers (EIDs) that identify end-hosts and Routing Locators
>>>  (RLOCs) that identify network attachment points.  With this, LISP
>>>  effectively separates control from data, and allows routers to create
>>>  overlay networks.  LISP-capable routers exchange encapsulated packets
>>>  according to EID-to-RLOC mappings stored in a local map-cache.  The
>>>  map-cache is populated by the LISP Control-Plane protocol
>>> 
>> Same as above for the "control-plane protocol”
> 
> These are well-known terms across the industry. I would prefer to not change them. Plus they made it through the experimental RFC-set without opposition.

It is redundant because the “P” in LISP that does mean “protocol”. But this is an english nit. I can live with the current wording.


> 
>>> 
>>> 3.  Definition of Terms
>>> 
>> 
>> What is the order of the Terms?
>> 
>> It is not alphabetical and not logical (at least I cannot se it).
> 
> Originally it was suppose to be logical. I will double check to make sure the terms are introduced in an obvious sequence. If I can avoid forward-references, I will do so.
> 

I guess this is still on your to do list. 


[snip]
> 
>>>  Re-encapsulating Tunneling in RTRs:   Re-encapsulating Tunneling
>>> 
>> RTR have never been defined.
> 
> It is being defined right here. I’ll read word it.
> 

If you define it the text should read like:

RTR: Re-encapsulating Tunnel Router…….


>>>  Recursive Tunneling:   Recursive Tunneling occurs when a packet has
>>>     more than one LISP IP header.  Additional layers of tunneling MAY
>>>     be employed to implement Traffic Engineering or other re-routing
>>>     as needed.  When this is done, an additional "outer" LISP header
>>>     is added, and the original RLOCs are preserved in the "inner"
>>>     header.  
>>> 
>> Do not think the following sentence is really necessary.
>> 
>> 
>> 
>>> Any references to tunnels in this specification refer to
>>>     dynamic encapsulating tunnels; they are never statically
>>>     configured.
> 
> Well many have said that LISP tunnels are not like traditional tunnels. Traditional tunnels are configured and provisioned. Where LISP tunnels are dynamic and used on demand. I would like the sectiond to stay.

You can move this sentence in the intro or where it make sense to you. In the Definition of terms is just lost.

[snip]
> 
>>>  Server-side:  Server-side is a term used in this document to indicate
>>>     that a connection initiation attempt is being accepted for a
>>>     destination EID.  
>>> 
>> 
>> 
>> 
>> Rest of the paragraph not needed here. (it is specified in the operation part of the document)
>> 
>>> The ETR(s) at the destination LISP site may be
>>>     the first to send Map-Replies to the source site initiating the
>>>     connection.  The ETR(s) at this destination site can obtain
>>>     mappings by gleaning information from Map-Requests, Data-Probes,
>>>     or encapsulated packets.
> 
> Okay, reworded though.

Still not needed. And you added “MAY” which is pointless. Please delete. The procedures are described elsewhere in the document. 



> 
>>>  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 think it should be kept in. I feel it adds value.

You break the operational flow by opening a different point describing what is what. It makes the overall procedure unclear.


> 
>>>  o  EID-Prefixes are likely to be hierarchically assigned in a manner
>>>     that is optimized for administrative convenience and to facilitate
>>>     scaling of the EID-to-RLOC mapping database.  The hierarchy is
>>>     based on an address allocation hierarchy that is independent of
>>>     the network topology.
>>> 
>> Drop the last bullet it is about scalability.
> 
> Right, but still important to mention. Many of the benefits of LISP aren’t always obvious. So we have to point them out.

Dino, this has to go away. This is NOT the control-plane advertisement document. This is the LISP control-plane, that’s all.
This was agreed upon at the time of rechartering.

[snip]
> 
>>> 5.1.  LISP IPv4-in-IPv4 Header Format
>>> 
>>>       0                   1                   2                   3
>>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    / |Version|  IHL  |Type of Service|          Total Length         |
>>>   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> 
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    /  |Version|  IHL   |DSCP      |ECN|          Total Length         |
>>   /   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> The correct IPv4 Header is with DSCP and ECN. Please update below as well.
> 
> I am not sure we should change this. We are referencing the RFC791 so good to be consistent.

Go on the data tracker: https://tools.ietf.org/html/rfc791 <https://tools.ietf.org/html/rfc791>

You will read that 791 has been updated by RFC 1349, RFC 2474, and RFC 6864. You have to refer to these documents.
Please update.


> 
>>> 5.2.  LISP IPv6-in-IPv6 Header Format
>>> 
>>>       0                   1                   2                   3
>>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    / |Version| Traffic Class |           Flow Label                  |
>>>   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> 
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    / |Version| DSCP      |ECN|           Flow Label                  |
>>   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> The correct IPv6 Header is with DSCP and ECN. Please update below as well.
> 
> As comment as above.

As for my answer above.

[snip]


>> 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.
> 
> We went through this with a lot of people for RFC6830. It took many months to resolve. I dare not touch this text.

You have just to move it up and separate it in two bullets. No changes needed.


> 
>>> 9.  Routing Locator Selection
>>> 
>> 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.
> 
> We have already decided (a year ago) not to move this because its the data-plane that needs to know about locator reachability so it knows which locators to use.

Please check the minutes of past meetings (as I did), the only unclear point was SMR, everything else was agreed to be moved out. 



> 
>>> 10.  Routing Locator Reachability
>>> 
>>>  Several mechanisms for determining RLOC reachability are currently
>>>  defined:
>>> 
>> There exists data-plane based reachability mechanisms and control plane reachability mechanisms.
>> We have to keep here only the data plane based mechanism and move the other in 6833bis.
>> 
>> We need to keep: 1, 6, Echo-Nonce, 
>> 
>> We need to move: 2, 3, 4, 5,  RLOC-Probing
> 
> Again, we already had this debate. The decision was made and agreed upon. We shouldn’t open this up again.

Exactly, it has been decided, hence control plane things go in the control plane document. (or OAM)




> 
>>>  When an ETR decapsulates a packet, it will check for any change in
>>>  the 'Locator-Status-Bits' field.  When a bit goes from 1 to 0, the
>>>  ETR, if acting also as an ITR, will refrain from encapsulating
>>>  packets to an RLOC that is indicated as down.  It will only resume
>>>  using that RLOC if the corresponding Locator-Status-Bit returns to a
>>>  value of 1.  Locator-Status-Bits are associated with a Locator-Set
>>>  per EID-Prefix.  Therefore, when a Locator becomes unreachable, the
>>>  Locator-Status-Bit that corresponds to that Locator's position in the
>>>  list returned by the last Map-Reply will be set to zero for that
>>>  particular EID-Prefix.
>>> 
>> We need to cite the threats document because of the security issues of LSB.
> 
> We reference it in the Security Considerations section. Don’t you think its good enough. Otherwise, we’ll have to reference it in every situation that the threats document covers.

One thing is the threats an other is a feature that you cannot use in public deployments. 
Somewhere in this document we must state that LSB cannot be used in public deployments. Choose where. 



> 
>>>  When ITRs at the site are not deployed in CE routers, the IGP can
>>>  still be used to determine the reachability of Locators, provided
>>>  they are injected into the IGP.  This is typically done when a /32
>>>  address is configured on a loopback interface.
>>> 
>> The above paragraph has to move to 6833bis.
> 
> Disagree.

The WG decided differently.

> 
>>>  When ITRs receive ICMP Network Unreachable or Host Unreachable
>>>  messages as a method to determine unreachability, they will refrain
>>>  from using Locators that are described in Locator lists of Map-
>>>  Replies.  However, using this approach is unreliable because many
>>>  network operators turn off generation of ICMP Destination Unreachable
>>>  messages.
>>> 
>>> 
>> The above paragraph has to move to 6833bis.
> 
> Disagree.

The WG decided differently.



> 
>>>  If an ITR does receive an ICMP Network Unreachable or Host
>>>  Unreachable message, it MAY originate its own ICMP Destination
>>>  Unreachable message destined for the host that originated the data
>>>  packet the ITR encapsulated.
>>> 
>>> 
>> The above paragraph has to move to 6833bis.
> 
> Disagree.

The WG decided differently.



> 
>>>  Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a
>>>  locator address from a Locator-Set in a mapping entry matches a
>>>  prefix.  If it does not find one and BGP is running in the Default-
>>>  Free Zone (DFZ), it can decide to not use the Locator even though the
>>>  Locator-Status-Bits indicate that the Locator is up.  In this case,
>>>  the path from the ITR to the ETR that is assigned the Locator is not
>>>  available.  More details are in [I-D.meyer-loc-id-implications].
>>> 
>>> 
>> The above paragraph has to move to 6833bis.
> 
> Disagree.

The WG decided differently.

> 
>>>  Optionally, an ITR can send a Map-Request to a Locator, and if a Map-
>>>  Reply is returned, reachability of the Locator has been determined.
>>>  Obviously, sending such probes increases the number of control
>>>  messages originated by Tunnel Routers for active flows, so Locators
>>>  are assumed to be reachable when they are advertised.
>>> 
>>> 
>> The above paragraph has to move to 6833bis.
> 
> Disagree.

The WG decided differently.


> 
>>> This assumption does create a dependency: Locator unreachability is
>>>  detected by the receipt of ICMP Host Unreachable messages.  When a
>>> 
>>> 
>>> 
>>> Farinacci, et al.         Expires May 15, 2018                 [Page 26]
>>> Internet-Draft                    LISP                     November 2017
>>> 
>>> 
>>>  Locator has been determined to be unreachable, it is not used for
>>>  active traffic; this is the same as if it were listed in a Map-Reply
>>>  with Priority 255.
>>> 
>>> 
>> The above paragraph has to move to 6833bis.
> 
> Disagree.

The WG decided differently.

> 
>>>  The ITR can test the reachability of the unreachable Locator by
>>>  sending periodic Requests.  Both Requests and Replies MUST be rate-
>>>  limited.  Locator reachability testing is never done with data
>>>  packets, since that increases the risk of packet loss for end-to-end
>>>  sessions.
>>> 
>>> 
>> The above paragraph has to move to 6833bis.
> 
> Disagree.

The WG decided differently.


[snip]

>>> 10.2.  RLOC-Probing Algorithm
>>> 
>>> 
>> This whole section has to go to 6833bis.
> 
> Disagree.
> 

The WG decided differently.


[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. 
> 
> I don’t agree. We had already mentioned there is a control-plane protocol that is described in RFC6833bis and a data-plane protocol that USEs the control-plane protocol. And the usage should be here.

Not following here. Why should the data-plane control the control plane?

Changing a mapping can be triggered by data plane events but the control plane will manage.

It’s like routing, the data plane can detect a link outage but is the control plane that will do the rest. Said differently, you can detect a link failure with IP but is IGP that will find an alternative route.


> 
> Think of it as an API. There is a document that defines an API and there is a document on which API calls are used for the use-case of say a data-plane.
> 
>>> 
>>> 16.  Mobility Considerations
>>> 
>> Move it out. Mobility is equivalent to mapping change, it is a CP issue.
>> 
>> move it in an OAM document.
>> 
>> 
>>> 
>>> 
>>> 17.  LISP xTR Placement and Encapsulation Methods
>>> 
>> This ia an OAM issue and has to be moved out of the document.
> 
> Luigi, we already decided on this and you didn’t disagree when we decided.

Dino, please check the minutes. The discussion was on the excellent summary that Albert prepared.
Except for disagreement on SMR there was a decision to move everything out.

To the question: where to put it? I am not even sure that everything should go in the control plane document, hence the suggestion of the OAM  which could be just a cut and paste of these sections.



> Making changes like this to RFC6833 will be huge.

You do not have to. see my comment above.

> We have the documents separated in the current state right now that seems to work and seems to be clear.

I did not have time to go over 6833bis, but concerning 6830bis the document is not clear and it is a patchwork of data-plane, control-plane, and deployment issues.

This is not what was agreed upon when we started this effort.


> 
>> 
>>> 
>>> 19.  Security Considerations
>>> 
>>>  Security considerations for LISP are discussed in [RFC7833], in
>>>  addition [I-D.ietf-lisp-sec] provides authentication and integrity to
>>>  LISP mappings.
>>> 
>> lisp-sec is control-plane has to be referenced in 6833bis.
> 
> Yes, but if an ITR caches a coarse EID-prefix, then there is a data-plane redirection attack.
> 

My point is that lisp-sec provides control plane features, so the sentence does not bring anything to the discussion.
Please delete.


>>> 21.1.  LISP UDP Port Numbers
>>> 
>>>  The IANA registry has allocated UDP port numbers 4341 and 4342 for
>>>  lisp-data and lisp-control operation, respectively.  IANA has updated
>>>  the description for UDP ports 4341 and 4342 as follows:
>>> 
>>>      lisp-data      4341 udp    LISP Data Packets
>>>      lisp-control   4342 udp    LISP Control Packets
>>> 
>> 4342 is control-plane and MUST be requested to IANA in the 6833bis document.
> 
> We didn’t want to change the registry so we are keeping this here. Its really no big deal.

> Note the data-plane implementation will have to send to the 4342 socket so its not out of place at all for this to be in this document.
> 

4342  is control plane not data plane, any further review beyond the WG will point out this inconsistency.

Thanks 

Luigi