Hi Acee, Thanks for the feedback,
This is existing today, some vendors are not accepting remote TLDP sessions and you cannot configure them to do it ... I agree that this could be managed by policy (this is presented in ietf-lfa-manageability draft), but it sounds important to mention this potential issue in deployment considerations for rLFA. Stephane ________________________________ De : Acee Lindem [mailto:[email protected]] Envoyé : mercredi 4 septembre 2013 14:49 À : LITKOWSKI Stephane DTF/DERX Cc : [email protected]; [email protected]; [email protected] Objet : Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Hi Stephane, On Sep 4, 2013, at 4:25 AM, <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> wrote: Any feedback from the authors ? ________________________________ De : [email protected]<mailto:[email protected]> [mailto:[email protected]] De la part de [email protected]<mailto:[email protected]> Envoyé : mercredi 7 août 2013 10:51 À : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : RE: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Hi Authors and Chairs, 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 - 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. This could be controlled with local policy preventing selection of certain nodes (e.g., based on a prefix-list filtering OSPF Router-Ids). However, since the complete IGP domain is under a single administrative control, why wouldn't a node be configured to accept Targeted LDP when remote LFA is deployed? I guess it would be due to resource limitations?? I hate to see us attempt to invent machinery to handle this resource exhaustion case. Thanks, Acee * 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 - 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. Thanks, Best Regards, Stephane _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg _________________________________________________________________________________________________________________________ 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
