So everyone agrees and vocabulary is clear - one MAY implement it per AF, please speak up if there’s still unclarity.
Thanks! Cheers, Jeff -----Original Message----- From: Pushpasis Sarkar <[email protected]> Date: Sunday, March 8, 2015 at 10:16 PM To: "Les Ginsberg (ginsberg)" <[email protected]>, Martin Horneffer <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: LFA manageability : per AF config => feedback required >Hi Les, > >Likewise our interest is.. As long it is NOT made Mandatory we are fine. >So we are okay here.. I was just clarifying to few things for Martin.. > >See you in Dallas :) > >Thanks and Regards, >-Pushpasis > >On 3/9/15, 9:26 AM, "Les Ginsberg (ginsberg)" <[email protected]> wrote: > >>draft-ietf-rtgwg-lfa-manageability-07 said "SHOULD" regarding supporting >>per AF enablement. >> >>draft-ietf-rtgwg-lfa-manageability-08 has changed that to a MAY. >> >>In either case an implementation is NOT required to implement this >>support, so Pushpasis/Hannes - if you don’t want to implement this - then >>don't. >> >>I have zero interest in trying to convince everyone that they MUST >>implement per AF enablement. My only interest is in making sure that it >>is not forbidden - and since the draft specifically allows this I am >>satisfied. >>Let's move on please. >> >> Les >> >>> -----Original Message----- >>> From: rtgwg [mailto:[email protected]] On Behalf Of Pushpasis >>>Sarkar >>> Sent: Thursday, March 05, 2015 7:28 PM >>> To: Martin Horneffer; Hannes Gredler >>> Cc: [email protected] >>> Subject: Re: LFA manageability : per AF config => feedback required >>> >>> Hi Martin, >>> >>> I totally agree with the intentions I get from your reply here. I >>>absolutely >>> support your idea of consuming as less forwarding resource as possible. >>> But >>> I also think the intentions will not be met with this kind of Œper AF¹ >>>knob, >>> simply because we won¹t save any forwarding resources (or even CPU >>> resources) >>> if we deploy both AFs under single topology but enable protection for >>>only >>> one. >>> So essentially the knob is kind of NO-OP other than not providing >>>protection >>> for one of the AF. >>> >>> Thanks >>> -Pushpasis >>> >>> On 3/5/15, 9:53 PM, "Martin Horneffer" <[email protected]> wrote: >>> >>> >Hello Hannes, >>> > >>> >sorry for the late response, the flu kept me offline for quite a >>>while. >>> > >>> >But sure I can describe my feelings about this. (Pain is about >>> >feelings, isn't it?) >>> > >>> > >>> >Basically I have learnt during the last decade, that the IGP is better >>> >kept clean and neat. This is particularly valid for large networks >>>with >>> >many different services and strict requirements in terms of >>>availabiliy. >>> >Especially when it comes to forwarding ressources, it's better to >>> >consume as little ressources as neccessary, so that the those >>> >forwarding entries that really matter perform best. >>> > >>> >One example ist fast IGP convergence: The less FIB entries you have, >>> >the faster the FIB download works and the faster the IGP convergence >>>is. >>> > >>> >Another one ist ECMP vs. IP-FRR. One of our vendors implemented IP-FRR >>> >in a way that consumes certain ressources that are also used for ECMP. >>> >Some time after we activated LFA in a certain part of our network, >>> >operations came back to me saying that now one of 16 available ECMP >>> >paths was suddenly empty. It turned out that LFA took away one ECMP >>> >slot and noone had warned me before. >>> > >>> > >>> >Of course, I don't know how your exact implementation of LFA for IPv6 >>> >in ISIS will behave and whether any of the ressources it consumes >>>would >>> >actually be critical in my network. >>> > >>> >But all in all I'd consider it best to design a network with as little >>> >consumption of forwardings ressources as possible. And if one address >>> >family in my IGP would only be used for iBGP, SNMP and ssh, why should >>> >I protect it with LFA? >>> > >>> > >>> >Best regards, Martin >>> > >>> > >>> >Am 24.02.15 um 18:29 schrieb Hannes Gredler: >>> >> 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#sect >>> >>ion >>> >>-5.1 >>> >> | >| 16. http://www.orange.com/ >>> >> | >| 17. >>> >>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclic >>> v >>> >>oic >>> >>e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefaul >>> t%2 >>> >>6ro >>> >>otservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%2 >>> 0 >>> >> | >| 18. >>> >>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclic >>> v >>> >>oic >>> >>e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefaul >>> t%2 >>> >>6ro >>> >>otservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%2 >>> 0 >>> >> | >| 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 >>> > >>> >############################################## >>> > >>> ># 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
