Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-01.txt

[Damien Saucez <[e-mail]>]

Hello,

> On 4 avr. 2017, at 02:46, Dino Farinacci <[e-mail]> wrote:
> 
> 
>>>> DSA: what about creating a specific document for reachability? something like liveness problem?
>>> 
>>> Here are the reasons:
>>> 
>>> (1) We don’t want to have too many documents for someone to read to get the full picture of the LISP data-plane and control-plane. 
>>> 
>> Who is we? The WG or the authors?
> 
> The initial people who started out this effort. That is, Albert, Luigi, you, and me.
> 

As far as I am concerned, I never asked to minimize the number of documents. Instead, I proposed/am proposing to have documents that answer clear questions.

>> What is the difference between reading 50 pages in 2 documents or 50 pages well structured in 3 documents? 
> 
> It is more convenient to have things in one place. 

If the question answered by the document is clear yes, otherwise, better have different document, each answering a clear question.

Another option that creating specific document would be to restructure 6830bis so to have one big section on liveness instead of having 
sections here and there talking about it. For example, merging 10 and 11 into one general section about reachability, and explain as an introduction
of this section that LISP changes the way we can see the reachability and that we have to consider both RLOC and EID reachability.

> 
>> People willing to have just a brief understanding of LISP may not be interested in knowing the liveness 
> 
> They can get a brief understanding from draft-ietf-lisp-introduction, which is already a separate document. Remember a few years ago, we thought it was worth while having an introduction to the architecture and protocols outside of the main specs. So we already have many specs.
> 
see above

>> check techniques. On the other hand, many people know LISP but don’t know how liveness checks are performed, they would thus probably enjoy more a specific document that talk about that instead of having to decipher a large document that talks about everything.
> 
> If there are too many pieces, and a person that DOES want detail, will then not go to all the documents and can miss that. We already have 14 RFCs and I think the modularity we have is a fine balance.

see above.
> 
>>> (2) We have broken it up where another data-plane has sufficient information to use the LISP control-plane in one document. If that data-plane wants to use the some data-plane features of LISP, they go examine RFC6830bis for it.
>> I am not sure I get it. For me liveness is a control-plane matter that may potentially use the data-plane. 
> 
> Echo-noncing is also a liveness mechanism. But since its defined part of the encapsulation header, it needs to be in the data-plane document. RLOC-probing is performed at non-forwarding time but it interacts with RLOC-probing, that is if nonces have been echoed, RLOC-probes may be suppressed. And only the data-plane cares about liveness since it cares about encapsulating to RLOCs that are reachable.
> 

and that is probably a design mistake of LISP where we mix control and data plane features inside the data-plane. It may look like an optimization but at the end it makes the implementation much more complex and blurs the design of the solution.

I would be interested to see how much echo-nonce is used in real deployments. In VxLAN that is very similar to LISP, there is no such mismatch and it does not seem to prevent it to work pretty well.

>> Also there are many possible solutions and that would be worth explaining the rational of each one, their pros and cons and in what environment to use them, hence the proposition of a separate document that can explain clearly that. 
> 
> Again, if I was registering EID ‘damien’ with RLOC <gps-coordinates>, I would not care about using RLOC-probing because the RLOC is on attached to the Internet and you can’t encapsulate to it. So again, this is a data-plane function only.

see above.
> 
>>> (2) Since the SMR is originated by an data-plane node (the ETR), it should be part of the data-plane document.
>> 
>> No really a valid argument. Map-Requests, map-reply, map-notify … are originated by data-plane nodes, it doesn’t mean that map-request must be in data-plane, actually they are in the control-plane document already now.
> 
> Well we originally had those control-plane messages in one place. But we were forced to split it up. So we can’t have both. And all those message types you illustrate are originated by non data-plane nodes all the time. 
Map-Request are used for RLOC probing and SMR and they explicitly appear in this data-plane document as data-plane features and now you say Map-Requests are not data-plane. So finally we agree that they should be in control-plane document as they are control-plane elements!
> 
>> For me SMR is really a control-plane matter. It is an element to permit the control of the content of the EID-to-RLOC cache and it is optional, the data-plane can work without this feature at all. Also in terms 
> 
> It cannot work without this feature. If an RLOC-set changes, and if the ITR doesn’t support this, it encapsulates packets to either black holes or to the wrong place.
> 

It can work without SMR as much as a xTR can work without Map-Request. Dealing with changes of mappings is a control-plane problem, so SMR is a control-plane problem.

>>> (1) We have decided that the network elements, in their purest form are introduced in this data-plane document and that more specific deployment scenarios belong in RFC7215.
>>> 
>> Who is we? The WG or the authors?
> 
> Albert and I prposed this at the working group in Berlin and Seoul.

As we already have intro that gives the general discussion and 7215 that discusses about the deployments, why having it also in 30bis?

> 
>>> Well it is up to the querier to decide how to populate. For instance, a lig client that doesn’t even have a map-cache is a querier, it decides to do the lookup and simply print the Map-Reply results on a screen or UI.
>> 
>> right, so what about changing to:
>> 
>> Tunnel routers are equipped with a cache,
>> called map-cache, that contains EID-to-RLOC mappings.  The map-cache
>> _CAN be_ populated using the LISP Control-Plane protocol
>> [I-D.ietf-lisp-rfc6833bis].
> 
> That language is already there. Is it not? 
ok.
> 
>>>> DSA: maybe we could deprecate this feature (I don't see a reason to be in the specs, it is an implementation feature, isn't it?)
>>> 
>>> We should NOT depercate this feature. It is a way of timing out entries and important for map-cache management. And that is certainly something ITR specific and hence belongs in the data-plane document.
>> 
>> I agree that deprecated is not the right word. For me it is an implementation detail, hence not needed to be document in the specs but of course it can be implemented.
> 
> Clock sweep is still recommended by vendors. And it should. 

I agree that clock sweep may be interesting (though I am not really sure that in practice it is of real use as it is finally very slow and not flexible, but maybe you have a deployment case where clock sweep is used and without it it would not have been possible to do something). I still believe that Clock sweep is something related to deployments and constructor recommendations. For me it is not really part of the protocol, just a way to play with mappings. Anyway, compared to the rest, this is really a detail.

Thanks,

Damien Saucez 

> 
> Dino
>