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
