[lisp] Re: Review draft-ietf-lisp-te

[Luigi Iannone <[e-mail]>]

> On 27 May 2024, at 16:49, Dino Farinacci <[e-mail]> wrote:
> 
> I don’t see the need to fix it. And the working group doesn’t seem to care. If you can’t give me a compelling reason to fix it, I’m not going to. 
> 
> You clearly don’t understand what a network path is. It includes nodes AND links. 
> 
> Dino

Dino,

Private emails, with insulting content, will not help progress the document.

Since apparently we are not able to converge, my co-chair Padma accepted to handle this document from now on.

Please wait her review of the draft.



As a participant of the LISP WG, and with no hats on, my concerns remain unaddressed (despite proposing very detailed and easy fixes). 

Second example in  section 4 remains unclear and misleading. See: https://mailarchive.ietf.org/arch/msg/lisp/CzJjLCgCZquCPOkhv56-q3DZTRE/

The general organisation of the document can be improved.
As of now it is a bunch of use cases where for each one we see the same structure:

	Here is a cool thing you can do using LISP ELPs….  
	In order to do it you MUST do this or SHOULD do that….. 

In other words the specifications that need to be implemented are scattered all over the document. The risk is that people interested in one single use case will implement only part of the specs.

My suggestion is to move a few paragraph in one single place so to have the document organized in two main parts: A section with all the specifications; A section with all the use cases.
My first review included detailed suggestions of the few simple cut & paste to be done: https://mailarchive.ietf.org/arch/msg/lisp/3zIUevHl8ZbqfKgwjXhJ8Z-FUlA/

Ciao

L.



 

> 
>> On May 27, 2024, at 8:19 AM, Luigi Iannone <[e-mail]> wrote:
>> 
>> Hi Dino,
>> 
>> I do not see a reply to my last email.
>> Can you fix the figure of the example so that we can move forward?
>> 
>> The concerned part is:
>> 
>>>> 
>>>>> This is exactly the point. I do not see an alternate path. I see only an alternate tunnel.
>>>>> The current text is still confusing. You want "to route around the path from B to C” and to do it you route "through link B—>C”. This looks like a contradiction to me.
>>>> 
>>>> B and C have other links. Don’t you see the link between B and X. That is “another” path. 
>>> 
>>> But the figure has no “other path” in it. I added one in my first review but you did not like it.
>>> 
>>> The text:
>>> 
>>> if it is desirable to route around the path from B to C through link B-->C, 
>>> 
>>> Still look like a contradiction. Furthermore, in figure 1 you were already routing through link B—>C, so it looks like you “route around” through the very same link…..
>>> 
>>> 
>> 
>> 
>> 
>> For clarity, according to the convention you are using the figure 2 show a tunnel between X and Y but not a path. I put back my very first email with the suggested correct figure.
>> 
>>    Source site       (----------------------------)    Destination Site
>>    +--------+        (                            )         +---------+
>>    |         \       (                            )        /          |
>>    | seid     ITR ---(-> A -> B --------> C -> D -)---> ETR      deid |
>>    |         / ||    (        |           ^       )     ^^ \          |
>>    |        /  ||    (        |           |       )     ||  \         |
>>    +-------+   ||    (        v           |       )     ||   +--------+
>>                ||    (        X --------> Y       )     ||
>>                ||    (      ^^ ||       ^^ ||     )     || <>
>>                ||    (------||-||-------||-||-----)     ||
>> 	       ||           || ||       || ||
>>                ||           || ||=======|| ||           ||
>> 	       ===============    LISP    ===============
>>                  LISP Tunnel      Tunnel    LISP Tunnel
>> 
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>>> On 13 May 2024, at 13:58, Luigi Iannone <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>>> On 7 May 2024, at 16:36, Dino Farinacci <[e-mail]> wrote:
>>>> 
>>>> 
>>>>> The text still assumes that an ELP must be returned.
>>>> 
>>>> That is correct.
>>>> 
>>>>> 
>>>>> Just replace the words:
>>>>> 
>>>>>   “which returns a ELP-based locator record for a path to RTR 'y', and encapsulates packets…"
>>>> 
>>>> The example is illustrating nesting so I believe it is not needed.
>>> 
>>> I understand the example, but the text is a bit misleading because seems to suggest that lookup _must_ return an ELP. 
>>> Anyway, in the last revision is already better.  
>>> 
>>> 
>>>> 
>>>>>>>> Luigi, the terms are used in self contained sections. They are fine. S-EID is ONLY used in the multicast section because the is the convention we use to look up a multicast mapping (S-EID, G-EID).
>>>>> 
>>>>> I think a unique term makes more sense, but this is not a blocking point.
>>>> 
>>>> It is a unique term. The term S-EID is used in all the multicast drafts to describe an (S,G).
>>> 
>>> Fine.
>>> 
>>>> 
>>>>> This is exactly the point. I do not see an alternate path. I see only an alternate tunnel.
>>>>> The current text is still confusing. You want "to route around the path from B to C” and to do it you route "through link B—>C”. This looks like a contradiction to me.
>>>> 
>>>> B and C have other links. Don’t you see the link between B and X. That is “another” path.
>>> 
>>> But the figure has no “other path” in it. I added one in my first review but you did not like it.
>>> 
>>> The text:
>>> 
>>> if it is desirable to route around the path from B to C through link B-->C, 
>>> 
>>> Still look like a contradiction. Furthermore, in figure 1 you were already routing through link B—>C, so it looks like you “route around” through the very same link…..
>>> 
>>> 
>>> 
>>>> 
>>>>> The sentence remains superfluous. Of course you can do it with ODL, but this is out of the scope of the IETF and I do not see why it should be there.
>>>>> The other LISP documents never mention a provision system, so why this one has to mention it? Is there a compelling reason?
>>>> 
>>>> Because in other cases ETRs register their own RLOCs because they know them. With an ELP, a provisioning system knows the topology and can register all the addresses in the ELP.  It has a broader view. 
>>>> 
>>>> There are deployments that take an ISIS topology, compute paths offline as an SDN controller, and can build an ELP path based on policy rules (where re-encapsulation points can be placed in the network). 
>>>> 
>>> 
>>> The sentence is still superfluous. The fact that some LISP deployments use some SDN approach has no place in the document. This is a technical document for implementation of a feature, not a LISP advertisement.
>>> You can leave the sentence there if you really wish, but remains superfluous.
>>> 
>>> 
>>> Fix the example and we tackle the text.
>>> 
>>> Ciao
>>> 
>>> L.
>>> 
>>> 
>>>> Dino
>>> 
>>