[lisp] Re: Review draft-ietf-lisp-te

[Dino Farinacci <[e-mail]>]

> 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