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%2Fclicvoice.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%2Fclicvoice.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
