On Mon, Feb 23, 2015 at 03:55:32PM +0000, Les Ginsberg (ginsberg) wrote:
| 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).
HG> as it is unlikely that operators will tun off IPv4 protection,
may i have a ask that you repeat that quote above in the 6man
meeting ;-) ? - effectifely you're saying "IPv6 may be considered
as less critical", and therefore we SHOULD provide a knob
to turn protection off.
|
|
| 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: [email protected] [mailto:[email protected]]
| Sent: Sunday, February 22, 2015 11:10 PM
| To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura;
| [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) [[1]mailto:[email protected]]
| Sent: Monday, February 23, 2015 05:01
| To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF;
| [2][email protected]
| Subject: RE: LFA manageability : per AF config => feedback required
|
|
|
| Pushpassis -
|
|
|
| From: rtgwg [[3]mailto:[email protected]] On Behalf Of Pushpasis
| Sarkar
| Sent: Friday, February 20, 2015 3:28 AM
| To: Jeff Tantsura; [4][email protected]; [5][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 <[6][email protected]>
| Date: Friday, February 20, 2015 at 12:59 PM
| To: "[7][email protected]" <[8][email protected]>,
| "[9][email protected]" <[10][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: "[11][email protected]"
| <[12][email protected]>
| Date: Thursday, February 19, 2015 at 11:21 PM
| To: "[13][email protected]" <[14][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.
|
| "
|
| [15]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 !
|
|
|
|
|
| [16]Orange logo
|
|
|
| Stephane Litkowski
| Network Architect
| Orange/SCE/EQUANT/IBNF/ENDD/NDE
|
| Orange Expert Future Networks
|
| phone: [17]+33 2 23 28 49 83
| mobile: [18]+33 6 37 86 97 52
| [19][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.
https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1
| 16. http://www.orange.com/
| 17.
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
| 18.
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
| 19. 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
