Hannes - I don¹t see how you can jump to this conclusion - pretty lame ;^) Having the ability to enable or disable fast reroute protection by address family by no means favors one address family over the other. There just may be deployments where protection is just not desired for both and it is not like it comes for free (since you must account for the topologies being non-congruent). Acee
On 2/24/15, 10:03 AM, "Hannes Gredler" <[email protected]> wrote: >HG> that IPv6 is less critical than IPv4 ? - > the IESG review will be a lot of fun then - i'll make some popcorn ... > >On Mon, Feb 23, 2015 at 06:26:15PM +0000, Acee Lindem (acee) wrote: >| I agree with Les. >| Acee >| From: "Les Ginsberg (ginsberg)" <[1][email protected]> >| Date: Monday, February 23, 2015 at 10:55 AM >| To: Stephane Litkowski <[2][email protected]>, Pushpasis >| Sarkar <[3][email protected]>, Jeff Tantsura >| <[4][email protected]>, Routing WG <[5][email protected]> >| Subject: RE: LFA manageability : per AF config => feedback required >| >| Stephane >| >| >| >| 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). >| >| >| >| 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: [6][email protected] >| [[7]mailto:[email protected]] >| Sent: Sunday, February 22, 2015 11:10 PM >| To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura; >| [8][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) [[9]mailto:[email protected]] >| Sent: Monday, February 23, 2015 05:01 >| To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF; >| [10][email protected] >| Subject: RE: LFA manageability : per AF config => feedback required >| >| >| >| Pushpassis - >| >| >| >| From: rtgwg [[11]mailto:[email protected]] On Behalf Of >Pushpasis >| Sarkar >| Sent: Friday, February 20, 2015 3:28 AM >| To: Jeff Tantsura; [12][email protected]; >[13][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 <[14][email protected]> >| Date: Friday, February 20, 2015 at 12:59 PM >| To: "[15][email protected]" >| <[16][email protected]>, "[17][email protected]" >| <[18][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: "[19][email protected]" >| <[20][email protected]> >| Date: Thursday, February 19, 2015 at 11:21 PM >| To: "[21][email protected]" <[22][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. >| >| ³ >| >| [23]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 ! >| >| >| >| >| >| [24]Orange logo >| >| >| >| Stephane Litkowski >| Network Architect >| Orange/SCE/EQUANT/IBNF/ENDD/NDE >| >| Orange Expert Future Networks >| >| phone: [25]+33 2 23 28 49 83 >| mobile: [26]+33 6 37 86 97 52 >| [27][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. mailto:[email protected] >| 16. mailto:[email protected] >| 17. mailto:[email protected] >| 18. mailto:[email protected] >| 19. mailto:[email protected] >| 20. mailto:[email protected] >| 21. mailto:[email protected] >| 22. mailto:[email protected] >| 23. >https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section- >5.1 >| 24. http://www.orange.com/ >| 25. >https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice >.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26root >service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 >| 26. >https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice >.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26root >service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20 >| 27. 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
