> 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. >>>> 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). > 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. > 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). Dino _______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
