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

[Dino Farinacci <[e-mail]>]

> On May 6, 2024, at 10:54 AM, Dino Farinacci <[e-mail]> wrote:
> 
> Copying the WG. I have submitted -16 to make things more clear to reflect your comments. Here is the diff.
> 
> Dino
> 

> 
> 
>> On May 6, 2024, at 5:26 AM, Luigi Iannone <[e-mail]> wrote:
>> 
>> Dino,
>> 
>> The document is WG document and the WG has a say. 
>> Please post your reply to the mailing list. I will reply there.
>> 
>> At least we make the WG aware of how we work to move the document forward. ;-)
>> 
>> Ciao
>> 
>> L.
>> 
>>> On 4 May 2024, at 01:32, Dino Farinacci <[e-mail]> wrote:
>>> 
>>> Going private.
>>> 
>>>> On May 3, 2024, at 4:41 AM, Luigi Iannone <[e-mail]> wrote:
>>>> 
>>>> Dino,
>>>> 
>>>> Let’s go step by step.
>>>> 
>>>> Let’s postpone the text relocation and focus first on the other concerns I have.
>>> 
>>> Good.
>>> 
>>>> On 2 May 2024, at 22:29, Dino Farinacci <[e-mail]> wrote:
>>>>> 
>>>>> Luigi, see the diff file for most of your comments. I still cannot follow your move suggestions. Just moving text around away from where they are, are going to lose points I intended. You need to be crystal clear what text needs to move where and be precise why you think so. I feel the text doesn't need moving. So if you think it does you need to make compelling reasons without destroying the flow and meaning I have intended.
>>>>> 
>>>>> I made all the changes you requested in this diff file. I have comments for what I didn't change (I didn't comment on the move text since I did above).
>>>>> 
>>>>>> Dino, you correct text mixes specifications and use cases. By concentrating the specifications in one section (namely section 5) you will improve readability and clarity of the document.
>>>>> 
>>>>> No it doesn't. You are using the term use-cases in a high level sense. We are discuss functionality and why the ELP is needed.
>>>> 
>>>> No Dino. You are mixing examples and procedures, hence my suggestion to move around some text. But we will deal with this later.  
>>> 
>>> I am presenting the material as I see fit to make it understandable.
>>> 
>>>> 
>>>>>> What really request is a mapping, which may or may not be an ELP.
>>>>>> What happens if it receives a negative map-reply?
>>>>> 
>>>>> It follows the procedures of RFC9301. And we don't need to state this everywhere. We are assuming the reader knows how LISP works at a high level.
>>>> 
>>>> So your text is wrong because it states "requests the ELP for RTR ‘y’”. You request a mapping and act upon what you receive, you do not request an ELP for ‘y’.
>>> 
>>> I will fix this to be more clear.
>>> 
>>>> 
>>>>>> You mean that this second lookup can be done on a mapping system that is different from the one who delivered the initial ELP, right?
>>>>>> If yes, can you state so?
>>>>> 
>>>>> It means the ELP entry is an EID, so to get the RLOC for that EID, you do another lookup. It gives another level of indirection within an ELP.
>>>> 
>>>> The sentence I referring to is:  This can be done when using a public or private mapping database.  
>>>> 
>>>> Why are you introducing this distinction between public and private?
>>> 
>>> Because the recursion can be done with a private database. Its a useful feature.
>>> 
>>>> 
>>>>> 
>>>>>> The document uses a mix of “seid” and “S-EID”, choose one.
>>>>> 
>>>>> 
>>>>> On purpose. The seid and deid are used in the forwarding examples. The (S-EID) is only in the multicast section.
>>>> 
>>>> But you do not explain de difference. Either uniform them or explain. As it is now is just confusing.
>>> 
>>> 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).
>>> 
>>>> 
>>>> Comments on the diff:
>>>> 
>>>> The example in figure 2, with your latest changes makes even less sense, since you are now using an ELP to make the packet go through exatly the same path as in figure 1. Looks useless.
>>> 
>>> No it clarifies that the B—->C link could be down or congested and the only underlay path in the diagram is what you see. That is intended. If you don't use B and C, you can't get encap'ed packes from ITR to X.
>>> 
>>>> The sentence about provisioning system is still obscure. The LISP control plane is defined in RFC 9301. You are suggesting to use something else to register mappings, which is defined nowhere. So unless you want to define such a provisioning system please delete the sentence.
>>> 
>>> I am not removing it. So tell me what you want to write. OpenDaylight has a provisioning system and it was used to program the mapping system with ELPs.
>>> 
>>>> Once we converge on these issues we will discuss about moving text around.
>>> 
>>> So from exchange I only have one change to make.
>>> 
>>> Dino
>>> 
>>>> 
>>>> CIao
>>>> 
>>>> L.
>> 
>> 
>