Stewart, Hannes I agree that a simple IGP extension is the best solution but to ensure backward compatibility with legacy node that will never support this extension, there is still a need of tie breaker.
Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future tél. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 [email protected] -----Message d'origine----- De : Stewart Bryant [mailto:[email protected]] Envoyé : mercredi 9 octobre 2013 19:06 À : Hannes Gredler Cc : LITKOWSKI Stephane DTF/DERX; [email protected]; rogeriomariano; [email protected] Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt On 09/10/2013 10:10, Hannes Gredler wrote: > 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. I agree, this is my preferred approach because it is certain to work. Let me see if I can craft some text. Stewart > > /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 > > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
