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

[Dino Farinacci <[e-mail]>]

> Dino,
> 
> thanks for the hard work. 

I am trying to make it less harder than it needs to be. New diff and text file enclosed.

> my replies inline (trimmed the points we agree or have been clarified by your answers).

Thanks for that.

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

It is about not losing important information we decided 10 years ago to keep in because otherwise, we’d have to sprinkle it across documents. And WE DID decide to NOT create a third document.

> The document can be shorter and to the point. There are a lot of OAM information that does not belong to the data-plane.

The OAM information is necessary for the data-plane. And if LISP-GPE, VXLAN, or any other data plane wants to use their own OAM or use the LISP control-plane differently, it needs to be documented in their data-planes. Hence, why this information is there.

Short is not necessarily good if the document is incomplete. And I think the effort we have put in over the last couple of years finds the right balance.

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

I thought the order was fine so I didn’t change it.

>> 
>>>>  Re-encapsulating Tunneling in RTRs:   Re-encapsulating Tunneling
>>>> 
>>> RTR have never been defined.e
>> 
>> 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…….

Changed.

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

I added it as the first definition in the Definition of Terms section.

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

Sentence removed.

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

It was put there because someone commented on it. You have to tell me why you think it breaks flow. We discuss how end-systems send to EIDs. We say what EIDs are and how they are assigned to hosts. And then we move to RLOCs. It is pretty plan, simple, and straight-forward.

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

Sorry disagree. You have to mention some control-plane. And not the definition of it but how its used by this data-plane.

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

Changed for both IPv4 and IPv6. And referenced only 2474. 1349 is replaced by 2474 and 6864 discusses the ID field that is not what is being commented on here.

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

Can you be more specific please.

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

Please point it out. We have taken every input from the WG. And Albert and I were in sync and thought you had agreed (or maybe you stopped disagreeing until now).

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

You are trying to draw a hard wall between the data-plane and control-plane. In the real world that is not how protocols are deployed.

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

I put a reference to the Security Consideration section that talks about LSB vulnerabiliies as well as has the refernece to the LISP threats RFC.

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

It is not controlling the control-plane, it is using it. Did my example of an API not make that clear?

This example:

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



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

Sorry, no, the data-plane manages the map-cache, its own data structure. The data-plane uses messages to manage that map-cache, and those messages are defined in the control-plane spec.

> It’s like routing, the data plane can detect a link outage but is the control plane that will do 

Well that is not true. The OS infrastructure detects a link failure. The IP forwaring engine does not (and I know I implemented at least 6 different data-planes over the years).

> the rest. Said differently, you can detect a link failure with IP but is IGP that will find an alternative route.

Why would IP detect a link failre for AppleTalk (another network layer protocol). And AppleTalk doesn’t do it for itself either. Not a good example.

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

The effort was continuing. And we created options with further study. Both Albert and I did that further study and the drafts reflect the decisions. There were no WG objections other than from you which we had thought we convinced.

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

Sorry a data-plane component uses it. Why split it up when we can have this in one place.

Dino