> On 27 May 2024, at 16:49, Dino Farinacci <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> >>> >>>> On 7 May 2024, at 16:36, Dino Farinacci <[email protected]> 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 >>> >>
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
