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

[Luigi Iannone <[e-mail]>]

Dino,

my answers inline.

> On 18 Dec 2017, at 19:06, Dino Farinacci <[e-mail]> wrote:
> 
>> 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.

AFAIR there was only consensus in having two documents.
I can live with two documents, but the content has to be clear. At this stage I do not consider its content clear enough.


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

Doesn’t make sense to me. That is not a reason. 
That information can be available in another document and still be used by LISP-GPE, VxLAN, or any other data plane.

> 
> Short is not necessarily good if the document is incomplete.

Agreed, but long does not mean complete either.


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

OK, but a reader will just think the order is random. Can you add text elaborating the rationale of the order?


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

Why not in the introduction or somewhere else? 
Why put a sentence that states what LISP is in the definition of term section? 
Such a sentence fits better in the introduction.


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

Those two point would have more emphasis somewhere else. 
Where they are now they break the flow and do not provide details.

You can actually put them at the end of section 1 as normal sentences. We then add a reference to LCAF and state that this document describes procedures only for EID that are IPv4 or IPv6 addresses.

Incidentally, the end of the 1 section is also a good place to put the sentences about dynamic tunnelling. 


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

The  bullet is just not accurate. Look at the LISP-Beta and you realise that that statement does not hold.


[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.
> 
> Can you be more specific please.

In the ITR part we put as last bullet the first part of the original paragraph:

 	- The Explicit Congestion Notification ('ECN’), namely bits  6 and 7 of both the IPv4 and  IPv6 headers, requires special treatment
 	  in order to avoid discarding indications of congestion [RFC3168].  An ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
	  header to the outer header.  Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header.


In the ETR part we put as last bullet the second part of the original paragraph:

	- The Explicit Congestion Notification ('ECN’), namely bits  6 and 7 of both the IPv4 and  IPv6 headers, requires special treatment
 	  in order to avoid discarding indications of congestion [RFC3168].  If the 'ECN' field contains a congestion indication codepoint (the
 	  value is '11', the Congestion Experienced (CE) codepoint), then ETR/PETR  decapsulation MUST copy the 2-bit 'ECN' field from
        the stripped outer header to the surviving inner header that is used to forward the  packet beyond the ETR.  



that’s it 

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

https://www.ietf.org/proceedings/96/minutes/minutes-96-lisp


> And Albert and I were in sync and thought you had agreed (or maybe you stopped disagreeing until now).

Great, now you need to sync with the group, hence, this discussion.


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

I am trying to make this  a high quality document. I really don’t want that the document comes back from the IESG because this would delay publication a lot.
Besides, this is a specification document, independent from the implementationS. If anybody wants to tighten somehow control and data planes, they are free to go that way.

What we need here is to put some text in 6833bis, and replace it here with the sentence “Other control plane based reachability mechanism can be found in [6833bis]”

In 6833bis we do the opposite, we add the text cut from 6830bis and add “Other data plane based reachability mechanism can be found in [6830bis]”



[snip]

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

To me was not clear, let me try to reword.
The link between control and data planes is the LISP cache and some events that may trigger specific operations.
If those operations are data-plane they stay here. 
It those operations are control-plane they go in 6833bis.
 

[snip]


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

Not sure I am following here. The initial intent was two have two documents.

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

Again, IETF 96th. Yes, I proposed at the mic to move the text in 6833bis, only objection to this was you on the SMR mechanism.
Other then the SMR point we draw a clear line.

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

Any comment here?


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

Can you elaborate better your rationale? 

The data-plane can trigger control plane messages but you do not allocate the types here. 
That is done (rightfully) elsewhere. So, following the same policy, 4342 has to go 6833bis.

Thanks again

Ciao

L.

> 
> Dino
> 
> <rfcdiff-rfc6830bis.html><draft-ietf-lisp-rfc6830bis-08.txt>
> 
> 
>