looks good to me thanks ! On Thu, Mar 05, 2015 at 07:36:27AM +0000, [email protected] wrote: | Hi, | | I updated the draft section in this way, I used MAY for per AF and per MPLS control plane. I think "MAY" is better as it may fit everyone's point of view (it's not strong and permit optional support). | Let me know your thoughts asap please. I would like to post the draft before cut off. | | | An implementation of LFA SHOULD allow its activation with the | following criteria: | | o Per routing context: VRF, virtual/logical router, global routing | table, ... | | o Per interface | | o Per protocol instance, topology, area | | o Per prefixes: prefix protection SHOULD have a better priority | compared to interface protection. This means that if a specific | prefix must be protected due to a configuration request, LFA must | be computed and installed for this prefix even if the primary | outgoing interface is not configured for protection. | | An implementation of LFA MAY allow its activation with the following | criteria: | | o Per address-family: ipv4 unicast, ipv6 unicast | | o Per MPLS control plane: for MPLS control planes that inherit | routing decision from the IGP routing protocol, MPLS dataplane may | be protected by LFA. The implementation may allow operator to | control this inheritance of protection from the IP prefix to the | MPLS label bound to this prefix. The protection inheritance will | concern : IP to MPLS, MPLS to MPLS, and MPLS to IP entries. As | example, LDP and segment-routing extensions for ISIS and OSPF are | control plane eligible to this inheritance of protection. | | -----Original Message----- | From: rtgwg [mailto:[email protected]] On Behalf Of Hannes Gredler | Sent: Tuesday, February 24, 2015 18:30 | To: Martin Horneffer | Cc: [email protected] | Subject: Re: LFA manageability : per AF config => feedback required | | martin, | | can you describe what are the pain points of FRR protecting | *all* your traffic (IPv4/IPv6/labeled/unlabeled) ? | | why would you want your traffic not being protected ? | | /hannes | | On Tue, Feb 24, 2015 at 05:54:44PM +0100, Martin Horneffer wrote: | | Hello everyone, | | | | I really do see a good use-case for turning on IP-FRR protection for | | just one address family, and it does not have anything to do with | | making IPv6 customer better or worse than IPv4 customer traffic. | | | | Consider the IP/MPLS network I have today. Several address families | | are active in the backbone, but all customer traffic is carried in | | MPLS packets guided by IPv4-signalled LDP. This holds for ANY customer | | traffic, whether it is public IPv4, public IPv6, VPNs in IPv4 or IPv6 | | or L2-VPNs. Unlabeled | | IPv4 traffic also exists in the same backbone, but only for routing | | protocols themselves, and/or network management. Thus there is no need | | to protect this unlabeled IPv4 traffic in the same way as the customer | | MPLS traffic. | | | | In the future, I might activate IPv6 in the backbone and introduce | | more and more routing and management protocols with IPv6. Still no | | need to protect IPv6. Eventually I might shift LDP (or SR) from IPv4 | | controlled to IPv6 controlled. What was IPv6-over-IPv4-controlled-MPLS | | becomes plain IPv6-labeled traffic then, and IPv4-labeled traffic will | | become IPv4-over-IPv6-controlled-MPLS. At THAT point in time it | | becomes important to protect the IPv6 controlled MPLS traffic, and | | thus the IPv6 address family in the IGP, but no earlier. | | | | So please do not mix up control traffic and customer traffic, internal | | routing and customer routes. Thank you. | | | | Best regards, Martin | | | | | | Am 24.02.15 um 16:02 schrieb Hannes Gredler: | | >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 | | | | ############################################## | | | | # Mail Account for technical purposes only | | | | ############################################## | | | | _______________________________________________ | | rtgwg mailing list | | [email protected] | | https://www.ietf.org/mailman/listinfo/rtgwg | | _______________________________________________ | rtgwg mailing list | [email protected] | https://www.ietf.org/mailman/listinfo/rtgwg | | _________________________________________________________________________________________________________________________ | | 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
