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

[Dino Farinacci <[e-mail]>]

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.

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

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

It doesn’t matter to me. I’ll alphabetize it.

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

LISP is just not a tunnel.

> Such a sentence fits better in the introduction.

There is plenty of introductory information and examples of LISP tunnels in the introduction.

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

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

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

I removed Tunneling from the Definition of Terms and added a sentence to the Intro per your request.

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

Will remove it.

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

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.

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

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

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.

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

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

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

Dino