Hannes - It would be good if you did not attribute statements to me that I did not make. I made no statement about the importance of one address family over another. Please do not attempt to create controversy by misrepresenting what I wrote.
I do like popcorn though - so if you really are going to make some - count me in. :-) Les > -----Original Message----- > From: Hannes Gredler [mailto:[email protected]] > Sent: Tuesday, February 24, 2015 7:04 AM > To: Acee Lindem (acee) > Cc: Les Ginsberg (ginsberg); [email protected]; Pushpasis > Sarkar; Jeff Tantsura; [email protected] > Subject: Re: LFA manageability : per AF config => feedback required > > 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%2Fclicvo > ice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault > %26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083 > %20 > | 26. > https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvo > ice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault > %26rootservice%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
