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
