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

[Luigi Iannone <[e-mail]>]

Hi Dino,

my detailed comments are inline as usual, but I was wondering if is there a strong valid reason not to move text around?

The objective of this documentation is to be accessible easily by anyone that is willing to work or implement LISP, not only to specialist. The decomposition of functionality is thus essential so people don’t have to make important effort to understand what is strictly LISP encapsulation data-plane (specific to this encapsulation method), what is operation of the system, and what is control-plane (general to any encapsulation below).
> 



> On 27 Dec 2017, at 05:54, Dino Farinacci <[e-mail] <mailto:[e-mail]>> wrote:
> 
> New update included. I have made a lot of your requested changes but still disagree with many of your points. More justification below.
> 
>>> 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.
> 
> Well you have to be specific where you think it is not clear.
> 
>> 
>>>> 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. 
> 
> It is a reason, maybe one you don’t like, but it is a reason.
> 

The point is that in the current document there is a lot of OAM text that does not belong to the data-plane. 


>> That information can be available in another document and still be used by LISP-GPE, VxLAN, or any other data plane.
> 
> But we decided on only 2 documents. And if we put data-plane usage in a control-plane document, then we are making 6833bis like 6830.
> 

We are better organising the specifications so that they are clearer and easier to read.


[snip]
> 
>>>> 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.
> 
> Unless you provide clear text where they should go, I’m not going to change it.
> 

Suggested to merge with previous bullet in the reply to Albert.

>> 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.
> 
> The intro section is taking about broad concepts. Describing EIDs and RLOC encodings is too early for it.

Is not encoding is the concept that and EID can be anything.
But if you do my previous suggestion it will work for me.


[snip]
>> 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 
> 
> I made some minor comments but do not want to undo what David Black spent effort on and got approval for. And I certainly don’t want to repeat text as you suggested above.
> 

The text provided by Albert is very good, I will ask David to review the text again to make sure nothing has been lost.


>> 
>>> 
>>>>> 
>>>>>>> 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 <https://www.ietf.org/proceedings/96/minutes/minutes-96-lisp>
> 
> All I see in the notes about RLOC-probing is this:
> 
> 	- Luigi Iannone says for him RLOC probing/Clock Sweep should be in Control
> 	Plane.
> 	- Dino Farinacci says that if people want to use LISP control plane,
> 	seeing RLOC probing in control plane document may look awkward for
> 	people not willing to use the lisp data encapsulation.
> 
> And we already know this.  ;-)

Please listen to the recording. 

> 
> That doesn’t tell me there was a decision or concensus.
> 
>>>> 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]”
> 
> Is this a new comment. Sounds like you are suggesting something new.

No. Is the same suggestion. 

Remove the text and put the sentence: “Other control plane based reachability mechanisms can be found in [6833bis]”

In 6833bis you add the ext remove from 6830bis and at the end you add “Other data plane based reachability mechanisms can be found in [6830bis]” 


> 
>>> 
>>>>>> 
>>>>>> 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.
> 
> The data-plane does echo-noncing. So that should remain in the data-plane based on your premise above. I think you’d agree with that. But RLOC-probes may be suppressed due to echo-noncing showing reachability. Do you want to put echo-noncing logic in 6833bis if you move RLOC-probing there.
> 
> That would not be a good thing.
> 
> Also, if a map-cache entry doesn’t exist, no RLOC-probes are sent. So how to do you say that in a control-plane document when there are a lot of reasons to send RLOC-probes. RLOC-probes are sent to do lisp-crypto key-exchange, that is a data-plane feature.
> 
> Please, let’s just keep it where it is and let’s move on.


As I suggested in first mail: 

We need to keep: 1, 6, Echo-Nonce, 

We need to move: 2, 3, 4, 5,  RLOC-Probing


> 
>> 
>> 
>> [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?
> 
> No comment. I think we should reference it.

Can you share your reasoning?


> 
>> 
>>>>>>> 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 registry already refers to RFC6830. What’s the point of changing this when it really is a very minor point.

Because this is a data-plane document and there is no point in defining control plane codepoints here.

thanks

Luigi


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