> On May 6, 2024, at 10:54 AM, Dino Farinacci <[email protected]> wrote: > > Copying the WG. I have submitted -16 to make things more clear to reflect > your comments. Here is the diff. > > Dino >
<<< text/html; x-unix-mode=0644; name="draft-ietf-lisp-te-15.diff.html": Unrecognized >>>
> > >> On May 6, 2024, at 5:26 AM, Luigi Iannone <[email protected]> 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 <[email protected]> wrote: >>> >>> Going private. >>> >>>> On May 3, 2024, at 4:41 AM, Luigi Iannone <[email protected]> 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 <[email protected]> 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. >> >> >
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
