draft-ietf-rtgwg-lfa-manageability-04.txt   draft-ietf-rtgwg-lfa-manageability-05.txt 
Routing Area Working Group S. Litkowski Routing Area Working Group S. Litkowski
Internet-Draft B. Decraene Internet-Draft B. Decraene
Intended status: Standards Track Orange Intended status: Standards Track Orange
Expires: February 12, 2015 C. Filsfils Expires: July 10, 2015 C. Filsfils
K. Raza K. Raza
Cisco Systems Cisco Systems
M. Horneffer M. Horneffer
Deutsche Telekom Deutsche Telekom
P. Sarkar P. Sarkar
Juniper Networks Juniper Networks
August 11, 2014 January 6, 2015
Operational management of Loop Free Alternates Operational management of Loop Free Alternates
draft-ietf-rtgwg-lfa-manageability-04 draft-ietf-rtgwg-lfa-manageability-05
Abstract Abstract
Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast
ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic
(and MPLS LDP traffic by extension). Following first deployment (and MPLS LDP traffic by extension). Following first deployment
experiences, this document provides operational feedback on LFA, experiences, this document provides operational feedback on LFA,
highlights some limitations, and proposes a set of refinements to highlights some limitations, and proposes a set of refinements to
address those limitations. It also proposes required management address those limitations. It also proposes required management
specifications. specifications.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2015. This Internet-Draft will expire on July 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 8 skipping to change at page 3, line 8
6.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 17 6.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 17
6.3. Required local information . . . . . . . . . . . . . . . 18 6.3. Required local information . . . . . . . . . . . . . . . 18
6.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 19 6.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 19
6.5. LFA and network planning . . . . . . . . . . . . . . . . 19 6.5. LFA and network planning . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Following the first deployments of Loop Free Alternates (LFA), this Following the first deployments of Loop Free Alternates (LFA), this
document provides feedback to the community about the management of document provides feedback to the community about the management of
LFA. LFA.
Section 2 provides real uses cases illustrating some limitations Section 2 provides real uses cases illustrating some limitations
and suboptimal behavior. and suboptimal behavior.
skipping to change at page 17, line 50 skipping to change at page 17, line 50
interface, IGP interface, BFD session ... Especially testing or interface, IGP interface, BFD session ... Especially testing or
troubleshooting FRR requires to perform the manual shutdown on the troubleshooting FRR requires to perform the manual shutdown on the
remote end of the link as generally a local shutdown would not remote end of the link as generally a local shutdown would not
trigger FRR. trigger FRR.
To enhance such situation, an implementation SHOULD support To enhance such situation, an implementation SHOULD support
triggering/activating LFA Fast Reroute for a given link when a manual triggering/activating LFA Fast Reroute for a given link when a manual
shutdown is done on a component that currently supports FRR shutdown is done on a component that currently supports FRR
activation. activation.
An implementation MAY also support FRR activation for a specific
interface or a specific prefix on a primary next-hop interface and
revert without any action on any running component of the node (links
or protocols). In this use case, the FRR activation time need to be
controlled by a timer in case the operator forgot to revert traffic
on primary path. When the timer expires, the traffic is
automatically reverted to the primary path. This will make easier
tests of fast-reroute path and then revert back to the primary path
without causing a global network convergence.
For example : For example :
o if an implementation supports FRR activation upon BFD session down o if an implementation supports FRR activation upon BFD session down
event, this implementation SHOULD support FRR activation when a event, this implementation SHOULD support FRR activation when a
manual shutdown is done on the BFD session. But if an manual shutdown is done on the BFD session. But if an
implementation does not support FRR activation on BFD session implementation does not support FRR activation on BFD session
down, there is no need for this implementation to support FRR down, there is no need for this implementation to support FRR
activation on manual shutdown of BFD session. activation on manual shutdown of BFD session.
o if an implementation supports FRR activation on physical link down o if an implementation supports FRR activation on physical link down
event (e.g. Rx laser Off detection, or error threshold raised event (e.g. Rx laser Off detection, or error threshold raised
...), this implementation SHOULD support FRR activation when a ...), this implementation SHOULD support FRR activation when a
manual shutdown at physical interface is done. But if an manual shutdown at physical interface is done. But if an
implementation does not support FRR activation on physical link implementation does not support FRR activation on physical link
down event, there is no need for this implementation to support down event, there is no need for this implementation to support
FRR activation on manual physical link shutdown. FRR activation on manual physical link shutdown.
o A CLI command may permit to switch from primary path to FRR path
for testing FRR path for a specific. There is no impact on
controlplane, only dataplane of the local node could be changed.
A similar command may permit to switch back traffic from FRR path
to primary path.
6.3. Required local information 6.3. Required local information
LFA introduction requires some enhancement in standard routing LFA introduction requires some enhancement in standard routing
information provided by implementations. Moreover, due to the non information provided by implementations. Moreover, due to the non
100% coverage, coverage informations is also required. 100% coverage, coverage informations is also required.
Hence an implementation : Hence an implementation :
o MUST be able to display, for every prefixes, the primary nexthop o MUST be able to display, for every prefixes, the primary nexthop
as well as the alternate nexthop information. as well as the alternate nexthop information.
skipping to change at page 20, line 46 skipping to change at page 21, line 11
Intermediate System (IS-IS) Extensions in Support of Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC Generalized Multi-Protocol Label Switching (GMPLS)", RFC
4205, October 2005. 4205, October 2005.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008. Reroute: Loop-Free Alternates", RFC 5286, September 2008.
11.2. Informative References 11.2. Informative References
[I-D.ietf-rtgwg-remote-lfa] [I-D.ietf-rtgwg-remote-lfa]
Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-06 So, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-09 (work
(work in progress), May 2014. in progress), December 2014.
[I-D.litkowski-rtgwg-lfa-rsvpte-cooperation] [I-D.litkowski-rtgwg-lfa-rsvpte-cooperation]
Litkowski, S., Decraene, B., Filsfils, C., and K. Raza, Litkowski, S., Decraene, B., Filsfils, C., and K. Raza,
"Interactions between LFA and RSVP-TE", draft-litkowski- "Interactions between LFA and RSVP-TE", draft-litkowski-
rtgwg-lfa-rsvpte-cooperation-02 (work in progress), August rtgwg-lfa-rsvpte-cooperation-02 (work in progress), August
2013. 2013.
[I-D.psarkar-isis-node-admin-tag] [I-D.psarkar-isis-node-admin-tag]
psarkar@juniper.net, p., Gredler, H., Hegde, S., psarkar@juniper.net, p., Gredler, H., Hegde, S.,
Litkowski, S., Decraene, B., Li, Z., and H. Raghuveer, Litkowski, S., Decraene, B., Li, Z., and H. Raghuveer,
"Advertising Per-node Admin Tags in IS-IS", draft-psarkar- "Advertising Per-node Admin Tags in IS-IS", draft-psarkar-
isis-node-admin-tag-02 (work in progress), July 2014. isis-node-admin-tag-03 (work in progress), October 2014.
[I-D.psarkar-rtgwg-rlfa-node-protection] [I-D.psarkar-rtgwg-rlfa-node-protection]
psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers, psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers,
C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node
Protection and Manageability", draft-psarkar-rtgwg-rlfa- Protection and Manageability", draft-psarkar-rtgwg-rlfa-
node-protection-05 (work in progress), June 2014. node-protection-05 (work in progress), June 2014.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630, September
2003. 2003.
 End of changes. 10 change blocks. 
10 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/