Hi Dino,
Thanks for the update.
My comments inline.
> On 6 May 2024, at 19:54, Dino Farinacci <farina...@gmail.com> 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 <g...@gigix.net> 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 <farina...@gmail.com> wrote:
>>>
>>> Going private.
>>>
>>>> On May 3, 2024, at 4:41 AM, Luigi Iannone <g...@gigix.net> 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 <farina...@gmail.com> 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.
Let’s deal with this later.
>>>
>>>>
>>>>>> 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.
The text still assumes that an ELP must be returned.
Just replace the words:
“which returns a ELP-based locator record for a path to RTR 'y', and
encapsulates packets…"
With
“assuming it returns an ELP-based locator record for a path to RTR 'y',
it encapsulates packets…"
>>>
>>>>
>>>>>> 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 new text clarifies the use case. Thanks.
>>>
>>>>
>>>>>
>>>>>> 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).
I think a unique term makes more sense, but this is not a blocking point.
>>>
>>>>
>>>> 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.
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.
>>> 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.
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?
Ciao
L.
>>>
>>>> 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.
>>
>>
>
_______________________________________________
lisp mailing list -- lisp@ietf.org
To unsubscribe send an email to lisp-le...@ietf.org
