On Thu, Mar 05, 2015 at 02:39:00PM +0000, Acee Lindem (acee) wrote: | | | On 2/24/15, 11:00 AM, "Hannes Gredler" <[email protected]> wrote: | | >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 ? | | One use case would be is that you are using IPv6 for business critical | services that require IP FRR protection. IPv4 is being used for in-band | network management and no protection is necessary.
again, arguing about the "usefulness" "not necessary". - what practical harm does it do ? | >| 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%2Fclicvoic | >>e | >| | >>.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26roo | >>t | >| >service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 | >| >| 26. | >| | >>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoic | >>e | >| | >>.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26roo | >>t | >| >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
