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%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%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%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
