On Tue, Feb 24, 2015 at 03:35:11PM +0000, Acee Lindem (acee) wrote: | 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).
my point is that controlling LFA on a per-topology basis makes perfect sense. (as per your example above (non-congruent topologies), to save some number crunching). what does not make sense is: consider we've deployed IPv4/IPv6 in the default topology (integrated IS-IS model) - to turn off LFA for V6 routes. you have done already the number crunching, so why would you want to make IPv6 routes a second class citizen here ? - can you highlight the use-case here ? /hannes | 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
