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 Are there any other approaches? [SLI] The good approach would be to use policies to automatically prune these PQs as operators know which PQ may not to be able to accept TLDP. What algorithm do you suggest? [SLI] Do you have nothing to propose ? I know that CISCO has a working rLFA implementation , so I think you already have something to propose ... In case you don't, we could use the following approach : - Short term : use a tie breaker like (ISIS speaking) : o Use IP in TLV134 o If not existing, use IP in TLV132 if there's only one entry o If multiple entries in TLV132, use highest or lowest /32 IP listed as TLV135 Note that there is some corner cases where such algo would not work, e.g. when external /32 are advertised in ISIS using redistribution, in TLV135 you don't have the information of internal or external route and you may choose an external one. - Long term : define an IGP extension to mark prefix associated with TLDP listening. The idea is that the reader of the draft need to be aware on how the TLDP address is chosen and so may be able to adjust his LDP configs to make it working correctly. 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]<mailto:[email protected]> De : Stewart Bryant [mailto:[email protected]] Envoyé : mardi 8 octobre 2013 11:38 À : LITKOWSKI Stephane DTF/DERX Cc : Alvaro Retana (aretana); [email protected]; rogeriomariano; [email protected] Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt On 08/10/2013 08:06, [email protected]<mailto:[email protected]> wrote: Stewart, >There are clearly only two solutions to this, either permit TLDP on any likely >LSR, protected with an ACL if you wish, and accept the cases that fail as >being a minority concern, or two (and out of scope for this draft) get the >LSRs to advertise TLDP willingness in the IGP. [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 Are there any other approaches? > We can certainly discuss the issue, but I am reluctant to specify a heuristic > in an IETF draft, because then it is a specification and not a heuristic. [SLI] Ok, so just specify an algorithm to choose the IP address to use to establish the TLDP session. By doing nothing, you can fall into situations where you PLR is unable to establish a TLDP session because it's choosing the wrong IP address. What algorithm do you suggest? Stewart Thanks, 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]<mailto:[email protected]> De : Stewart Bryant [mailto:[email protected]] Envoyé : lundi 7 octobre 2013 17:56 À : LITKOWSKI Stephane DTF/DERX Cc : Alvaro Retana (aretana); [email protected]<mailto:[email protected]>; rogeriomariano; [email protected]<mailto:[email protected]> Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt On 07/10/2013 09:59, [email protected]<mailto:[email protected]> wrote: Hi Stewart, Here are some old comments you didn't provide on feedback on : "Regarding remote LFA draft, I would hope to see some points addressed in the draft before going to WGLC. - It would be good to add some simulation results about how much TLDP session are required (TX and TX+RX), this in order to make people aware on how much rLFA may impact their TLDP session scaling That is a issue for Mike to consider. - We already raised the point some months ago about possibly "interop" issues in the following cases : * PLR choose a PQ which is not able to accept TLDP session : we verified it in a lab, and we can clearly fall into such situation in a live network, leading to protection not available. There are clearly only two solutions to this, either permit TLDP on any likely LSR, protected with an ACL if you wish, and accept the cases that fail as being a minority concern, or two (and out of scope for this draft) get the LSRs to advertise TLDP willingness in the IGP. * PQ having multiple IP addresses /32 attached, so which one would be used to establish TLDP session ? Current implementations are using some heuristics and it would be good to document this We can certainly discuss the issue, but I am reluctant to specify a heuristic in an IETF draft, because then it is a specification and not a heuristic. - Current text states that rLFA is computed only when LFA are not available and our analysis pointed that this is really not a good idea as in term of manageability rLFA alternate may be better than LFA alternate. It would be good that rLFA draft points to potential manageability issues and refers to the appropriate draft. Hopefully this can be an informative ref, but we can include some simple text that notes that it is up to the implementer how they need to make a trade-off between minimum cost and minimum compute. Thanks for bringing this to my attention, hope to get some work done on this draft at the end of this week. - Stewart " Thanks Stephane 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]<mailto:[email protected]> De : [email protected]<mailto:[email protected]> [mailto:[email protected]] De la part de Stewart Bryant Envoyé : mercredi 2 octobre 2013 13:26 À : Alvaro Retana (aretana) Cc : [email protected]<mailto:[email protected]>; rogeriomariano; [email protected]<mailto:[email protected]> Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt I will try to get a new version out this week or next. I plan to put in the algorithm text, although having discussed this with Mike, our inclination is to include this as an appendix since it is not required for interoperability that you do the computation that way. I will look at the issues left unresolved and any comments posted in response to this email. I see no reason to request a slot at IETF88 unless there remain technical issues that we are unable to resolve on this list. - Stewart (as duty editor of the draft) On 01/10/2013 15:40, Alvaro Retana (aretana) wrote: On 10/1/13 10:31 AM, "rogeriomariano" <[email protected]<mailto:[email protected]>> wrote: Rogerio: Folks, Does anyone know whether the draft deal will be treated in the IETF 88? We haven't started working on the agenda yet, so it is perhaps too early to talk about whether this draft will be discussed in Vancouver or not. In the meant time, if you have comments or questions on the draft, please post them to the list. Thanks! Alvaro. _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg -- 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. -- 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. -- 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
