Hi Les, Some comments inline.
Thanks -Pushpasis From: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>> Date: Monday, February 23, 2015 at 9:30 AM To: Pushpasis Sarkar <[email protected]<mailto:[email protected]>>, Jeff Tantsura <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: LFA manageability : per AF config => feedback required Pushpassis - From: rtgwg [mailto:[email protected]] On Behalf Of Pushpasis Sarkar Sent: Friday, February 20, 2015 3:28 AM To: Jeff Tantsura; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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. [Pushpasis] The statement was made in the case where MT has been deployed. When MT is deployed, assumption is always that there is another topology configured other than MTID[0] for carrying the IPV6 topology. Isn’t it? In such cases MTID[0] still carries only IPV4 prefixes only. Right? :) One can argue that there can be a topology for just IPv4 mcast and not IPv6-ucast. But then what is the real usecase for that then? Interestingly you contradicted yourself below. :) But I did want to set the record straight on this point – hopefully we are in agreement. [Pushpasis] Actually I did not, coz by topology I meant when MT has been deployed. :) 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. [Pushpasis] Yes exactly. Even if IPV4 and IPV6 prefixes are carried in same topology I am assuming the LFA knobs being discussed here is not the same as the backup selection policy described in draft-rtgwg-lfa-manageability. Coz, what you mentioned as per-prefix/per-AF can be easily controlled by the backup-selection-policy, which should have separate configurations than one discussed on this thread. Les Thanks -Pushpasis From: Jeff Tantsura <[email protected]<mailto:[email protected]>> Date: Friday, February 20, 2015 at 12:59 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Thursday, February 19, 2015 at 11:21 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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. “ 5.1<https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-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 ! [Orange logo]<http://www.orange.com/> Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> [email protected]<mailto:[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.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
