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%2Fclicvoic
e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26ro
otservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
| >| 18.
https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoic
e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26ro
otservice%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
