Hannes - wrt your review - are you happy with the changes, have the authors addressed your comments?
Thanks! Regards, Jeff > On Mar 8, 2015, at 8:56 PM, 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
