Re: [OSPF] [Isis-wg] 答复: 答复: [sunset4] IPv6 router IDs

[Uma Chunduri <[e-mail]>]

Hi Acee,
In-line [Uma]:

>I can see these -
>1.  RLFA TLDP session without having to worry a PQ node supports TE or
>not

I don't think this is a good use case. You need to have an the AF topology in order to compute the remote LFA. Also, you may inherit remote LFA targets for external and prefixes from other areas but you will never compute remote LFA targets in other areas (at least not with today's algorithms).

[Uma]: It doesn't have to be a different area. Take a simplest case of one area or an L2 domain; after having computed all the PQ nodes in that area/domain if the PQ node doesn't support TE and doesn't advertise router ID (TLV 134) which IP address you would pick for TLDP session ?  You can't reliably know from the advertised prefixes from the node that it is hosted by  the node if router ID is not emitted by the node (as it doesn't support TE).

>2. Orchestration software on a controller or an application which is
>having access to
>   the topology database of the network may determine the node IP
>address without having to go through the hoops (to determine if it's
>redistributed or leaked etc..)
>   with this TLV.

Can you be more precise? If the orchestration application is going to orchestrate across multiple areas, I would hope it would have visibility to the topologies of these areas.

[Uma]: Even for a same area or domain having a node advertise it's loopback as router ID  without relation any relation to TE (supported or not) is a benefit in this case.
The ability of  an application on a controller to know this easily is a huge advantage.
Also there could be multiple loopback and each for different purposes. For e.g. a PCE on a controller with  https://tools.ietf.org/html/draft-ietf-pce-pceps can know PCC address
with a firewall port/IP opened on the router for TLS connection.  It would be great this can happen easily and automatically.

--
Uma C.