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
