> On 7 May 2024, at 16:36, Dino Farinacci <farina...@gmail.com> 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 -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
