Hi Stephane, Looks good. How do you plan to express this in YANG model you have been working on?
Thanks! Regards, Jeff > On Mar 5, 2015, at 8:36 AM, "[email protected]" > <[email protected]> wrote: > > Hi, > > I updated the draft section in this way, I used MAY for per AF and per MPLS > control plane. I think "MAY" is better as it may fit everyone's point of view > (it's not strong and permit optional support). > Let me know your thoughts asap please. I would like to post the draft before > cut off. > > > An implementation of LFA SHOULD allow its activation with the > following criteria: > > o Per routing context: VRF, virtual/logical router, global routing > table, ... > > o Per interface > > o Per protocol instance, topology, area > > o Per prefixes: prefix protection SHOULD have a better priority > compared to interface protection. This means that if a specific > prefix must be protected due to a configuration request, LFA must > be computed and installed for this prefix even if the primary > outgoing interface is not configured for protection. > > An implementation of LFA MAY allow its activation with the following > criteria: > > o Per address-family: ipv4 unicast, ipv6 unicast > > o Per MPLS control plane: for MPLS control planes that inherit > routing decision from the IGP routing protocol, MPLS dataplane may > be protected by LFA. The implementation may allow operator to > control this inheritance of protection from the IP prefix to the > MPLS label bound to this prefix. The protection inheritance will > concern : IP to MPLS, MPLS to MPLS, and MPLS to IP entries. As > example, LDP and segment-routing extensions for ISIS and OSPF are > control plane eligible to this inheritance of protection. > > -----Original Message----- > From: rtgwg [mailto:[email protected]] On Behalf Of Hannes Gredler > Sent: Tuesday, February 24, 2015 18:30 > To: Martin Horneffer > Cc: [email protected] > Subject: Re: LFA manageability : per AF config => feedback required > > martin, > > can you describe what are the pain points of FRR protecting > *all* your traffic (IPv4/IPv6/labeled/unlabeled) ? > > why would you want your traffic not being protected ? > > /hannes > > On Tue, Feb 24, 2015 at 05:54:44PM +0100, Martin Horneffer wrote: > | Hello everyone, > | > | I really do see a good use-case for turning on IP-FRR protection for > | just one address family, and it does not have anything to do with > | making IPv6 customer better or worse than IPv4 customer traffic. > | > | Consider the IP/MPLS network I have today. Several address families > | are active in the backbone, but all customer traffic is carried in > | MPLS packets guided by IPv4-signalled LDP. This holds for ANY customer > | traffic, whether it is public IPv4, public IPv6, VPNs in IPv4 or IPv6 > | or L2-VPNs. Unlabeled > | IPv4 traffic also exists in the same backbone, but only for routing > | protocols themselves, and/or network management. Thus there is no need > | to protect this unlabeled IPv4 traffic in the same way as the customer > | MPLS traffic. > | > | In the future, I might activate IPv6 in the backbone and introduce > | more and more routing and management protocols with IPv6. Still no > | need to protect IPv6. Eventually I might shift LDP (or SR) from IPv4 > | controlled to IPv6 controlled. What was IPv6-over-IPv4-controlled-MPLS > | becomes plain IPv6-labeled traffic then, and IPv4-labeled traffic will > | become IPv4-over-IPv6-controlled-MPLS. At THAT point in time it > | becomes important to protect the IPv6 controlled MPLS traffic, and > | thus the IPv6 address family in the IGP, but no earlier. > | > | So please do not mix up control traffic and customer traffic, internal > | routing and customer routes. Thank you. > | > | Best regards, Martin > | > | > | Am 24.02.15 um 16:02 schrieb Hannes Gredler: > | >On Mon, Feb 23, 2015 at 03:55:32PM +0000, Les Ginsberg (ginsberg) wrote: > | >| I can imagine cases in which the per AF enabling might make sense > (e.g. > | >| when the network associated w one address family is deemed > non-critical). > | > > | > > | >HG> as it is unlikely that operators will tun off IPv4 protection, > | > may i have a ask that you repeat that quote above in the 6man > | > meeting ;-) ? - effectifely you're saying "IPv6 may be considered > | > as less critical", and therefore we SHOULD provide a knob > | > to turn protection off. > | > > | >| > | >| > | >| Section 5.1 is a SHOULD - as is most of the document. It is therefore > a > | >| suggestion as to what an implementation should provide. If a given > | >| implementer thinks this is either too onerous or not useful they can > omit > | >| it w/o being in violation. But I see no reason to eliminate this - > and in > | >| actual practice I would expect the cost of supporting such a knob to > be > | >| low cost. It is hard for me to see this as controversial. > | >| > | >| > | >| > | >| Les > | >| > | >| > | >| > | >| > | >| > | >| From: [email protected] > [mailto:[email protected]] > | >| Sent: Sunday, February 22, 2015 11:10 PM > | >| To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura; > | >| [email protected] > | >| Subject: RE: LFA manageability : per AF config => feedback > | >| required > | >| > | >| > | >| > | >| [Les:] I think your point here is that the LFA calculation is AF > | >| independent within a given topology - but resources are consumed > | >| independent of how many computations are required- giving an operator > the > | >| ability to determine which prefixes are most critical seems useful. > That > | >| could be per AF or per prefix. > | >| > | >| > | >| > | >| [SLI] Agree but is the "resource saving" point strong enough to > mandate > | >| per AF activation ? > | >| > | >| > | >| > | >| From: Les Ginsberg (ginsberg) [[1]mailto:[email protected]] > | >| Sent: Monday, February 23, 2015 05:01 > | >| To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF; > | >| [2][email protected] > | >| Subject: RE: LFA manageability : per AF config => feedback > | >| required > | >| > | >| > | >| > | >| Pushpassis - > | >| > | >| > | >| > | >| From: rtgwg [[3]mailto:[email protected]] On Behalf Of Pushpasis > | >| Sarkar > | >| Sent: Friday, February 20, 2015 3:28 AM > | >| To: Jeff Tantsura; [4][email protected]; [5][email protected] > | >| Subject: Re: LFA manageability : per AF config => feedback > | >| required > | >| > | >| > | >| > | >| HI Jeff et al, > | >| > | >| > | >| > | >| I can think of a reason to have a knob per-level(or per-area) or per > ISIS > | >| topology(note in ISIS a topology in ISIS always corresponds to a > single > | >| AF,) > | >| > | >| > | >| > | >| [Les:] This is a common mistake to make. If one simply uses RFC 5308, > then > | >| IPv6 prefixes can be advertised in the same topology as IPv4 (MTID > #0) - > | >| and there are implementations which support this. More generally, > from the > | >| protocol's POV a given topology can support any combinations of > address > | >| families. It is only a convention because of the reserved MTIDs > specified > | >| in RFC 5120 that certain MTIDs are "IPv6 only". But if one looks at > the > | >| protocol capabilities such a restriction does not exist in general. > | >| > | >| > | >| > | >| Interestingly you contradicted yourself below. J > | >| > | >| But I did want to set the record straight on this point - hopefully > we are > | >| in agreement. > | >| > | >| > | >| > | >| and per realm and topology in OSPF. But I cannot think of a reason of > why > | >| within the same topology we need another set of knobs for each AF. > Here, > | >| by AF I understand IPV4 or IPv6. > | >| > | >| > | >| > | >| When both IPV4 and IPV6 are part of the same IGP topology, there is > only > | >| one set of backup computations needed to protect both IPV4 and IPv6 > | >| traffic. > | >| > | >| > | >| > | >| Also I cannot think of any motivation for an operator to turn on > | >| protection on only one AF and does not want to turn on for the other > even > | >| if both AFs has been deployed for normal forwarding. > | >| > | >| > | >| > | >| [Les:] I think your point here is that the LFA calculation is AF > | >| independent within a given topology - but resources are consumed > | >| independent of how many computations are required- giving an operator > the > | >| ability to determine which prefixes are most critical seems useful. > That > | >| could be per AF or per prefix. > | >| > | >| > | >| > | >| Les > | >| > | >| > | >| > | >| Thanks > | >| > | >| -Pushpasis > | >| > | >| > | >| > | >| From: Jeff Tantsura <[6][email protected]> > | >| Date: Friday, February 20, 2015 at 12:59 PM > | >| To: "[7][email protected]" > <[8][email protected]>, > | >| "[9][email protected]" <[10][email protected]> > | >| Subject: Re: LFA manageability : per AF config => feedback > | >| required > | >| > | >| > | >| > | >| Hi Stephane, > | >| > | >| > | >| > | >| /chair hat off > | >| > | >| > | >| > | >| IMO in disjoined topologies one should have flexibility to > enable/disable > | >| LFA as per AF. > | >| > | >| > | >| > | >| > | >| > | >| Cheers, > | >| > | >| Jeff > | >| > | >| > | >| > | >| From: "[11][email protected]" > | >| <[12][email protected]> > | >| Date: Thursday, February 19, 2015 at 11:21 PM > | >| To: "[13][email protected]" <[14][email protected]> > | >| Subject: LFA manageability : per AF config => feedback required > | >| > | >| > | >| > | >| Hi Folks, > | >| > | >| > | >| > | >| As you know, LFA manageability draft is in final phasis ... > | >| > | >| The current document states per AF granularity activation as a > SHOULD. > | >| > | >| " > | >| > | >| [15]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 ! > | >| > | >| > | >| > | >| > | >| > | >| [16]Orange logo > | >| > | >| > | >| > | >| Stephane Litkowski > | >| Network Architect > | >| Orange/SCE/EQUANT/IBNF/ENDD/NDE > | >| > | >| Orange Expert Future Networks > | >| > | >| phone: [17]+33 2 23 28 49 83 > | >| mobile: [18]+33 6 37 86 97 52 > | >| [19][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. > | >| > | >| > | >| ___________________________________________________________________ > | >| ______________________________________________________ > | >| > | >| > | >| > | >| 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. > | >| > | >| References > | >| > | >| Visible links > | >| 1. mailto:[email protected] > | >| 2. mailto:[email protected] > | >| 3. mailto:[email protected] > | >| 4. mailto:[email protected] > | >| 5. mailto:[email protected] > | >| 6. mailto:[email protected] > | >| 7. mailto:[email protected] > | >| 8. mailto:[email protected] > | >| 9. mailto:[email protected] > | >| 10. mailto:[email protected] > | >| 11. mailto:[email protected] > | >| 12. mailto:[email protected] > | >| 13. mailto:[email protected] > | >| 14. mailto:[email protected] > | >| 15. > https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1 > | >| 16. http://www.orange.com/ > | >| 17. > 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 > | >| 18. > 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 > | >| 19. mailto:[email protected] > | > > | > > | > > | >| _______________________________________________ > | >| rtgwg mailing list > | >| [email protected] > | >| https://www.ietf.org/mailman/listinfo/rtgwg > | > > | >_______________________________________________ > | >rtgwg mailing list > | >[email protected] > | >https://www.ietf.org/mailman/listinfo/rtgwg > | > | ############################################## > | > | # Mail Account for technical purposes only > | > | ############################################## > | > | _______________________________________________ > | 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
