Hi Anton, As I replied to Jeff, in case of disjoint topologies, we are no more related to per AF activation but more to a per topology activation which is different.
Regarding the "per-prefix" control, this is also proposed in the draft. Per-AF was added in order to have a simple mechanism to exclude a family of prefixes (sort of subset of per prefix). Best Regards, Stephane -----Original Message----- From: Anton Smirnov [mailto:[email protected]] Sent: Friday, February 20, 2015 10:17 To: LITKOWSKI Stephane SCE/IBNF; [email protected] Subject: Re: LFA manageability : per AF config => feedback required 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%2Fclic > voice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefau > lt%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%2Fclic > voice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefau > lt%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 > _________________________________________________________________________________________________________________________ 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
