hi jeff, -08 is sane from my POV. thanks to everybody involved for making the changes;
/hannes On Mon, Mar 09, 2015 at 04:14:23AM +0000, Jeff Tantsura wrote: | 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
