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. Thanks, Acee > >/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%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
