On Dec 13, 2012, at 4:13 PM, Peter Psenak wrote: > Hannes, > > On 13.12.2012 15:57, Hannes Gredler wrote: >> >> On Dec 13, 2012, at 3:31 PM, Peter Psenak wrote: >> >>> Hannes, >>> >>> On 13.12.2012 15:21, Hannes Gredler wrote: >>>> >>>> On Dec 13, 2012, at 12:43 PM, Stewart Bryant wrote: >>>> >>>> [ … ] >>>> >>>>>> can we say that the PQ node address used for targeted LDP session is >>>>>> selected in following order of preference: >>>>>> >>>>>> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ >>>>>> node itself >>>>>> >>>>>> 2. Highest /32 address advertised by PQ node in it's Router LSA >>>>> Why do we need (2). What do we do if an interface cycles? >>>>> >>>>> Surely the most we should say is that we SHOULD establish a TLDP session >>>>> with the >>>>> OSPF router-id, if it is advertised as /32 prefix by the PQ node itself, >>>>> else any >>>>> other IP address for the node may be used. >>>> >>>> other implementations may not be willing to accept T-LDP sessions on >>>> non-loopback >>>> adresses. >>> >>> how do you suggest to distinguish between /32 belonging to the loopback >>> from /32 belonging to other interface types? >> >> for OSPF traffic engineering deployments: >> - if a /32 stub route advertisement of a type-1 LSA matches the TE router >> address TLV in the type-10 LSA > > are we only allowed to advertise loopbacks in the TE TLV?
remember, in lieu of explicit signaling the purpose of this is finding the "most likely" transport IP for the T-LDP session. Those are heuristics and as such imperfect. If i can cover a high percentile of the deployed base, then i usually can convince operators to fix their broken configs where the router-id/TE-router-ID does not match the routable transport loopback IP. >> >> for OSPF non-traffic engineering deployments: >> - if a /32 stub route advertisement of a type-1 LSA matches the router-id >> in the LS header > > does not work if the router-id is not advertised by the node as a stub-link, > which is a valid case. perfect, so lets declare this a "broken" configuration for automated T-LDP bringup w/o explicit signaling. i do sense some discomfort with the suggested heuristics - should be go down and spin off dedicated drafts for OSPF and IS-IS to explicitly advertise the transport IP address ? >> >> for IS-IS traffic-engineering deployments: >> - if a /32 reported in any IP Reach TLVs (128,135, 235) matches the >> TE-router ID TLV 134 >> >> for non IS-IS traffic-engineering deployments: >> - if a /32 reported in any IP Reach TLVs (128,135, 235) matches the >> - IP interface address TLV 132 (and this is the only IP interface address >> TLV advertisement) >> >> >> >> > > > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
