I¹m not sure why allowing the flexibility of per-AF configuration for the ISIS dual-stack case has become such a lighting rod for contention. However, you reminded me that I need to respond with a use case. Acee
On 3/5/15, 3:07 AM, "Jeff Tantsura" <[email protected]> wrote: >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%2Fclicvoic >>e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26ro >>otservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 >> | >| 18. >>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoic >>e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26ro >>otservice%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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
