< draft-hegde-spring-node-protection-for-sr-te-paths-04.txt   draft-hegde-spring-node-protection-for-sr-te-paths-05.txt >
Routing area S. Hegde Routing area S. Hegde
Internet-Draft C. Bowers Internet-Draft C. Bowers
Intended status: Informational Juniper Networks Inc. Intended status: Informational Juniper Networks Inc.
Expires: April 20, 2019 S. Litkowski Expires: January 6, 2020 S. Litkowski
Orange Orange
X. Xu X. Xu
Alibaba Inc. Alibaba Inc.
F. Xu F. Xu
Tencent Tencent
October 17, 2018 July 5, 2019
Node Protection for SR-TE Paths Node Protection for SR-TE Paths
draft-hegde-spring-node-protection-for-sr-te-paths-04 draft-hegde-spring-node-protection-for-sr-te-paths-05
Abstract Abstract
Segment routing supports the creation of explicit paths using Segment routing supports the creation of explicit paths using
adjacency-sids, node-sids, and binding-sids. It is important to adjacency-sids, node-sids, and binding-sids. It is important to
provide fast reroute (FRR) mechanisms to respond to failures of links provide fast reroute (FRR) mechanisms to respond to failures of links
and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A
point of local repair (PLR) can provide FRR protection against the point of local repair (PLR) can provide FRR protection against the
failure of a link in an SR-TE path by examining only the first (top) failure of a link in an SR-TE path by examining only the first (top)
label in the SR label stack. In order to protect against the failure label in the SR label stack. In order to protect against the failure
of a node, a PLR may need to examine the second label in the stack as of a node, a PLR may need to examine the second label in the stack as
well in order to determine SR-TE path beyond the failed node. This well, in order to determine SR-TE path beyond the failed node. This
document specifies how a PLR can use the first and second label in document specifies how a PLR can use the first and second label in
the label stack describing an SR-TE path to provide protection the label stack describing an SR-TE path to provide protection
against node failures. against node failures.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 20, 2019. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 36 skipping to change at page 2, line 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Node Failures Along SR-TE Paths . . . . . . . . . . . . . . . 3 2. Node Failures Along SR-TE Paths . . . . . . . . . . . . . . . 3
2.1. Node protection for node-sid explicit paths . . . . . . . 3 2.1. Node protection for node-sid explicit paths . . . . . . . 3
2.2. Node-Protection for Anycast-SIDs . . . . . . . . . . . . 4 2.2. Node-Protection for Anycast-SIDs . . . . . . . . . . . . 4
2.3. Node-protection for adj-sid explicit paths . . . . . . . 5 2.3. Node-protection for adj-sid explicit paths . . . . . . . 5
3. Detailed Solution using Context Tables . . . . . . . . . . . 6 3. Detailed Solution using Context Tables . . . . . . . . . . . 6
3.1. Building Context Tables . . . . . . . . . . . . . . . . . 6 3.1. Building Context Tables . . . . . . . . . . . . . . . . . 6
3.2. Node protection for node SIDs . . . . . . . . . . . . . . 7 3.2. Node protection for node SIDs . . . . . . . . . . . . . . 7
3.3. Node protection for adjacency SIDs . . . . . . . . . . . 8 3.3. Node protection for adjacency SIDs . . . . . . . . . . . 8
3.4. Node protection for edge nodes . . . . . . . . . . . . . 9 3.4. Node protection for edge nodes . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Hold timers for Node-SID/Prefix-SIDs and Adjacency-SIDs . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Optimization Considerations . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
It is possible for a routing device to completely go out of service It is possible for a routing device to completely go out of service
abruptly due to power failure, hardware failure or software crashes. abruptly due to power failure, hardware failure or software crashes.
Node protection is an important property of the Fast Reroute Node protection is an important property of the Fast Reroute
mechanism. It provides protection against a node failure by mechanism. It provides protection against a node failure by
rerouting traffic around the failed node. For example, the rerouting traffic around the failed node. For example, the
mechanisms described in Loop Free Alternates ([RFC5286]), Remote Loop mechanisms described in Loop Free Alternates ([RFC5286]), Remote Loop
Free Alternates ([RFC8102]), and Free Alternates ([RFC8102]), and
skipping to change at page 5, line 10 skipping to change at page 5, line 10
[1100, 1005];. The top label (1100) corresponds to the anycast SID [1100, 1005];. The top label (1100) corresponds to the anycast SID
advertised by both R8 and R9. In the absence of a failure, the advertised by both R8 and R9. In the absence of a failure, the
packet sent by R1 with this label stack will follow the path from packet sent by R1 with this label stack will follow the path from
R1->R5 along R1->R7->R8->R4->R5. R1->R5 along R1->R7->R8->R4->R5.
If R7 is performing a per-prefix LFA calculation [RFC5286], then R7 If R7 is performing a per-prefix LFA calculation [RFC5286], then R7
will install a backup next-hop to R9 for this anycast SID, protecting will install a backup next-hop to R9 for this anycast SID, protecting
against the failure of the primary next-hop to R8. This backup path against the failure of the primary next-hop to R8. This backup path
does not pass through R8, so it is would not be affected by a does not pass through R8, so it is would not be affected by a
complete failure of node R8. As illustrated by this example, for complete failure of node R8. As illustrated by this example, for
some topologies node-protecting SR-TE paths can constructed through some topologies node-protecting SR-TE paths can be constructed
the use of anycast SIDs, as opposed to the mechanism described in through the use of anycast SIDs, as opposed to the mechanism
this document. described in this document.
2.3. Node-protection for adj-sid explicit paths 2.3. Node-protection for adj-sid explicit paths
Adj-sid: Adj-sid:
R3-R8:9044 R3-R8:9044
Node Node Node Node Node Node Node Node Node Node
sid:1 sid:2 sid:3 sid:4 sid:5 sid:1 sid:2 sid:3 sid:4 sid:5
+----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+
| R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 |
skipping to change at page 10, line 5 skipping to change at page 10, line 5
label in the label stack is understood in the IGP domain. When the label in the label stack is understood in the IGP domain. When the
provider edge routers exchange service labels via BGP or some other provider edge routers exchange service labels via BGP or some other
non-IGP mechanism the bottom label is not understood in the IGP non-IGP mechanism the bottom label is not understood in the IGP
domain. domain.
The egress node protection mechanisms described in the draft The egress node protection mechanisms described in the draft
[I-D.ietf-mpls-egress-protection-framework] is applicable to this [I-D.ietf-mpls-egress-protection-framework] is applicable to this
usecase and no additional changes will be required for SR based usecase and no additional changes will be required for SR based
networks networks
4. Security Considerations 4. Hold timers for Node-SID/Prefix-SIDs and Adjacency-SIDs
TBD SR-TE paths may be computed by a controller or by the head-end
router. When there is a node failure in the network, the controller
or head-end router has to learn about the failure, recompute the
label stacks of any affected SR-TE paths, and get the new label
stacks programmed into the forwarding plane of the head-end router.
This process may be slow compared to the speed with which routers in
the network react to the event. After learning about a node failure,
the non-PLR routers in the network will no longer be able to compute
a path to reach the failed node. If no special precautions are
taken, these non-PLR routers will remove the forwarding entries
corresponding the Node-SID and Prefix-SIDs advertised by the failed
node. If the head-end router is still sending traffic with that
Node-sid/prefix-sid in the stack, traffic can be blackholed at a non-
PLR router. In this case, the node-protection FRR mechanisms do not
bring full benefit.
5. IANA Considerations In order to solve the above problem, hold timers are recommended.
The hold-timer corresponds to the maximum time that a combination of
controller and head-end router or a head-end router alone takes to
compute and install label stacks corresponding to a new SR-TE paths
in the event of a node failure. The hold times should be applied to
forwarding entries for Node-SIDs and Prefix-SIDs that are advertised
by single node in the network. If the Node-SID or Prefix-SID becomes
unreachable, the event and resulting forwarding changes should not
communicated to the forwarding planes on all configured routers
(including PLRs for the failed node) until the hold-timer expires.
The traffic will follow continue to follow the previous path and get
FRR protection on the PLR.
6. Acknowledgments A route corresponding to a global adjacency SID advertised by a node
that becomes unreachable should also be left in the forwarding table
for the duration of the hold-timer.
The node-protecting backup forwarding entry on the PLR corresponding
to the local adjacency-SID from the PLR to the failed node should
also be left in the forwarding table for the duration of the hold-
timer.
5. Optimization Considerations
The solution described in this document requires that a PLR build a
context table for each neighbor for which node-protection is desired.
The context table for each protected neighbor needs to contain route
entries for all of the prefix-SIDs in the network, as well as the
route entries corresponding to the adjacency SIDs advertised by the
protected neighbor. This may result in considerable additional
memory consumption. It is possible to take advantage of an
optimization that allows the PLR to avoid creating context-tables
when all of the nodes in the network advertise the same SRGB and all
adjacency SIDs in the network are advertised as global adjacency
SIDs. In this case, all labels in the stack representing an SR-TE
path are globally unique. Protection for node failure cases in such
a deployment can be achieved by doing a lookup of the first label and
potentially a second lookup of the second label using a common route
table with primary and backup entries for all prefix-SIDs as well as
for all of the global adj-SIDs.
The primary route entries for global adj-SIDs not advertised by the
PLR will be the shortest path to the node advertising the global adj-
SID. The backup route entries for these global adj-SIDs will
generally correspond to the node-protecting backup path to the node
advertising the global adj-SID. However, for a global adj-SID
advertised by the direct neighbor of the PLR the node-protecting
backup route entry will correspond to the backup path to the node on
the far end of the adj-SID.
With the common route table constructed in this manner, when the PLR
receives a packet whose first label is a global adj-SID advertised by
the failed neighbor of the PLR, the lookup of the first label will
produce the correct backup path directly. When the PLR receives a
packet whose first label is the node-SID of the failed neighbor, or
an adj-SID advertised by the PLR corresponding to the failed
neighbor, the route entry will instruct the PLR to lookup the second
label using the common route table. Finally, when the PLR receives a
packet whose first label is a global adj-SID or a node-SID advertised
by a node which is neither the PLR nor the failed neighbor, then the
usual link-protecting backup path will be produced based on a lookup
of the first label only.
6. Security Considerations
The procedures described in this document will in most common cases
be deployed inside a single ownership IGP domain. No new security
risks are exposed due to the procedures described in this document.
The security procedures applicable to IGP protocols will provide the
desired protection.
7. IANA Considerations
8. Acknowledgments
The authors would like to thank Peter Psenak and Bruno Decreane for The authors would like to thank Peter Psenak and Bruno Decreane for
their review and suggestions. their review and suggestions.
7. References 9. References
7.1. Normative References 9.1. Normative References
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>. <https://www.rfc-editor.org/info/rfc5286>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008, RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>. <https://www.rfc-editor.org/info/rfc5331>.
7.2. Informative References 9.2. Informative References
[I-D.bashandy-rtgwg-segment-routing-ti-lfa] [I-D.bashandy-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
Camarillo, "Topology Independent Fast Reroute using Camarillo, "Topology Independent Fast Reroute using
Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- Segment Routing", draft-bashandy-rtgwg-segment-routing-ti-
lfa-05 (work in progress), October 2018. lfa-05 (work in progress), October 2018.
[I-D.ietf-mpls-egress-protection-framework] [I-D.ietf-mpls-egress-protection-framework]
Shen, Y., Jeganathan, J., Decraene, B., Gredler, H., Shen, Y., Jeganathan, J., Decraene, B., Gredler, H.,
Michel, C., Chen, H., and Y. Jiang, "MPLS Egress Michel, C., and H. Chen, "MPLS Egress Protection
Protection Framework", draft-ietf-mpls-egress-protection- Framework", draft-ietf-mpls-egress-protection-framework-06
framework-02 (work in progress), July 2018. (work in progress), June 2019.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018. in progress), January 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
 End of changes. 16 change blocks. 
26 lines changed or deleted 113 lines changed or added

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