Hi Hannes, You are right, maybe the text should be clarified. To be honest, this text part is old and I took a shortcut and mixing two things :)
First thing is really a per AF activation (ipv4 unicast, ipv6 unicast ...). The second is do I need to protect "LDP routes" that are inheriting some IGP properties or do I consider that LDP is protected by something else (RSVP-TE :) ). Best regards, Stephane -----Original Message----- From: Hannes Gredler [mailto:[email protected]] Sent: Friday, February 20, 2015 10:27 To: Anton Smirnov Cc: LITKOWSKI Stephane SCE/IBNF; [email protected] Subject: Re: LFA manageability : per AF config => feedback required hi anton, et al, there is one more quirk to this: i have never heard of _LDP_ adress families: | > o Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast, | > LDP IPv6 unicast ... | > so we're referring to something which does not exist - please see latest IANA registry: http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml /hannes On Fri, Feb 20, 2015 at 10:17:03AM +0100, Anton Smirnov wrote: | Hi Stephane, | I think concern of "alternate nexthops consume resources in the | forwarding plane" is generally a valid one. But if you want to solve | *this* problem then solution is to give to operator great flexibility | to select set of prefixes which are allowed to have protection and | this flexibility should go beyond of just per-AF selection. | | Per-context selection would actually solve different problem - CPU | resources needed to compute LFAs (which are spent per-topology | independent of number of nexthops which end up being protected). | | So IMO per-AF granularity might be useful (especially in disjoint | topologies) but reason given in the draft does not connect with the | solution. | | Anton | | | On 02/20/2015 08:21 AM, [email protected] wrote: | >Hi Folks, | > | >As you know, LFA manageability draft is in final phasis … | > | >The current document states per AF granularity activation as a SHOULD. | > | >“ | > | > | > 5.1 | > <https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1>. | > LFA enabling/disabling scope | > | > | > | > | > | > The granularity of LFA activation should be controlled (as | > alternate | > | > nexthop consume memory in forwarding plane). | > | > | > | > An implementation of LFA SHOULD allow its activation with the | > | > following criteria: | > | > | > | > o Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 | > unicast, | > | > LDP IPv6 unicast ... | > | > | > | > o Per routing context : VRF, virtual/logical router, global | > routing | > | > table, ... | > | > | > | >“ | > | >In the framework of ISIS/OSPF yang modelization, we are challenging | >this statement, do we really need to force implementation to support | >this “per AF” granularity ? | > | >Please provide as soon as possible your feedback on this and also | >provide clear drivers to support or not per AF activation of LFA. | > | >Thanks for your help ! | > | >Orange logo <http://www.orange.com/> | > | >*Stephane Litkowski * | >Network Architect | >Orange/SCE/EQUANT/IBNF/ENDD/NDE | > | >Orange Expert Future Networks | > | >phone: +33 2 23 28 49 83 | ><https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fcli | >cvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddef | >ault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> | >mobile: +33 6 37 86 97 52 | ><https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fcli | >cvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddef | >ault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> | >[email protected] <mailto:[email protected]> | > | >_____________________________________________________________________ | >____________________________________________________ | > | >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 | > | | _______________________________________________ | rtgwg mailing list | [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
