hi stewart, i am not much in favor of 'lets try if we can bring-up TLDP, and if not lets pick another PQ' strategy, mainly because it may create cross dependencies.
today the typical R-LFA flow between IGP and LSP is like this: 1. IGP determines PQ set 2. IGP installs IP-FRR routes and gives LDP a hint which PQ IP address shall be used for a given IP-FRR backup route 3. LDP tries to bring up T-LDP to the PQ set 4. LDP has learned PQ set LDP database(s) and sets the backup nexthop for its MPLS tunnel and MPLS transit routes accordingly now if we need to add the PQ pruning logic it becomes like this: 1. IGP determines PQ set 2. IGP installs IP-FRR routes and gives LDP a hint which PQ IP address shall be used for a given IP-FRR backup route 3. LDP tries to bring up T-LDP to the PQ set 4. timeout for bringing up T-LDP to PQ set 5. prune 'unwilling' PQ neighbor, goto 1 now my question: what event *removes* the unwilling PQ neighbor from the PQ prune list, ever? - even if the PQ neighbor has been reconfigured and it would now accept T-LDP sessions, the calculating router would never try to establish a T-LDP session after the PQ is on the prune list. and periodical fallback is not a good solution either, right ;-) to avoid the above i'd like to see simple protocol extensions to the IGPs of a node willing or not willing to accept T-LDP sessions and avoid the cross-dependencies. /hannes On Oct 8, 2013, at 11:37 AM, Stewart Bryant wrote: [ … ] > On 08/10/2013 08:06, [email protected] wrote: [ .. ] >> [SLI] Some nodes are not accepting any TLDP session at all and you cannot >> configure them to do it … > So if the nodes to not accept the TLDP they you have a number of > alternatives: > > 1) Take it on the chin (it is FRR not convergence) > 2) Replace the nodes with nodes that do > 3) Modify the nodes to accept the TLDP > 4) Get all other nodes to advertise the capability and address > 5) Test the candidate nodes as part of the selection process _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
