< draft-hu-spring-segment-routing-proxy-forwarding-18.txt   draft-hu-spring-segment-routing-proxy-forwarding-19.txt >
Network Working Group Z. Hu Network Working Group Z. Hu
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track H. Chen Intended status: Standards Track H. Chen
Expires: 1 September 2022 Futurewei Expires: 13 October 2022 Futurewei
J. Yao J. Yao
Huawei Technologies Huawei Technologies
C. Bowers C. Bowers
Juniper Networks Juniper Networks
Y. Zhu Y. Zhu
China Telecom China Telecom
Y. Liu Y. Liu
China Mobile China Mobile
28 February 2022 11 April 2022
SR-TE Path Midpoint Restoration SR-TE Path Midpoint Restoration
draft-hu-spring-segment-routing-proxy-forwarding-18 draft-hu-spring-segment-routing-proxy-forwarding-19
Abstract Abstract
Segment Routing Traffic Engineering (SR-TE) supports explicit paths Segment Routing Traffic Engineering (SR-TE) supports explicit paths
using segment lists containing adjacency-SIDs, node-SIDs and binding- using segment lists containing adjacency-SIDs, node-SIDs and binding-
SIDs. The current SR FRR such as TI-LFA provides fast re-route SIDs. The current SR FRR such as TI-LFA provides fast re-route
protection for the failure of a node along a SR-TE path by the direct protection for the failure of a node along a SR-TE path by the direct
neighbor or say point of local repair (PLR) to the failure. However, neighbor or say point of local repair (PLR) to the failure. However,
once the IGP converges, the SR FRR is no longer sufficient to forward once the IGP converges, the SR FRR is no longer sufficient to forward
traffic of the path around the failure, since the non-neighbors of traffic of the path around the failure, since the non-neighbors of
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 1 September 2022. This Internet-Draft will expire on 13 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Proxy Forwarding . . . . . . . . . . . . . . . . . . . . . . 4 2. Proxy Forwarding . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Extensions for Proxy Forwarding . . . . . . . . . . 4 3. Protocol Extensions/Re-uses for Proxy Forwarding . . . . . . 4
3.1. Advertising Proxy Forwarding . . . . . . . . . . . . . . 4 3.1. Advertising Binding Segment . . . . . . . . . . . . . . . 4
3.2. Advertising Binding Segment . . . . . . . . . . . . . . . 5 3.2. Advertising Proxy Forwarding . . . . . . . . . . . . . . 5
4. Proxy Forwarding Example . . . . . . . . . . . . . . . . . . 6 4. Proxy Forwarding Example . . . . . . . . . . . . . . . . . . 6
4.1. Advertising Proxy Forwarding . . . . . . . . . . . . . . 8 4.1. Advertising Proxy Forwarding . . . . . . . . . . . . . . 8
4.2. Building Proxy Forwarding Table . . . . . . . . . . . . . 8 4.2. Building Proxy Forwarding Table . . . . . . . . . . . . . 8
4.3. Proxy Forwarding for Binding Segment . . . . . . . . . . 9 4.3. Proxy Forwarding for Binding Segment . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Proxy Forwarding for Adjacency and Node Segment . . 11 Appendix A. Proxy Forwarding for Adjacency and Node Segment . . 11
A.1. Next Segment is an Adjacency Segment . . . . . . . . . . 11 A.1. Next Segment is an Adjacency Segment . . . . . . . . . . 11
A.2. Next Segment is a Node Segment . . . . . . . . . . . . . 12 A.2. Next Segment is a Node Segment . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Segment Routing Traffic Engineering (SR-TE) is a technology that Segment Routing Traffic Engineering (SR-TE) is a technology that
implements traffic engineering using a segment list. SR-TE supports implements traffic engineering using a segment list. SR-TE supports
the creation of explicit paths using adjacency-SIDs, node-SIDs, the creation of explicit paths using adjacency-SIDs, node-SIDs,
skipping to change at page 4, line 22 skipping to change at page 4, line 22
capability from the neighbors of a failed node will send traffic capability from the neighbors of a failed node will send traffic
using the node-SID of the failed node to the nearest Proxy Forwarder using the node-SID of the failed node to the nearest Proxy Forwarder
after the IGP converges on the event of the failure. after the IGP converges on the event of the failure.
Once the affected traffic reaches a Proxy Forwarder, it sends the Once the affected traffic reaches a Proxy Forwarder, it sends the
traffic on the post-failure shortest path to the node immediately traffic on the post-failure shortest path to the node immediately
following the failed node in the segment list. following the failed node in the segment list.
For a binding segment of a possible failed node, the node advertises For a binding segment of a possible failed node, the node advertises
the information about the binding segment, including the binding SID the information about the binding segment, including the binding SID
and the list of SIDs associated with the binding SID, to its direct and the list of SIDs/segments associated with the binding SID, to its
neighbors only. Note that the information is not advertised in the direct neighbors only. Note that the information is not advertised
network domain. in the network domain.
After the node fails and the IGP converges on the failure, the After the node fails and the IGP converges on the failure, the
traffic with the binding SID of the failed node will reach its traffic with the binding SID of the failed node will reach its
neighbor having SR Proxy Forwarding capability. Once receiving the neighbor having SR Proxy Forwarding capability. Once receiving the
traffic, the neighbor swaps the binding SID with the list of SIDs traffic, the neighbor swaps the binding SID with the list of SIDs/
associated with the binding SID and sends the traffic along the post- segments associated with the binding SID and sends the traffic along
failure shortest path to the first node in the segment list. the post-failure shortest path to the first node in the segment list.
3. Protocol Extensions for Proxy Forwarding 3. Protocol Extensions/Re-uses for Proxy Forwarding
This section describes the semantic of protocol extensions/re-use for This section describes the semantic of protocol extensions/re-uses
advertising the SR proxy forwarding capability of a node in a network for advertising the information about each binding segment (including
domain and the information about each binding segment (including its its binding SID and the list of SIDs/segments associated with the
binding SID and the list of SIDs associated) of a node to its direct binding SID) of a node to its direct neighbors and the SR proxy
forwarding capability of a node in a network domain.
3.1. Advertising Binding Segment
For a binding segment (or binding for short) on a node A, which
consists of a binding SID and a list of SIDs/segments, node A
advertises an LS containing the binding (i.e., the binding SID and
the list of the SIDs/segments) in a binding segment TLV. The LS is
advertised only to each of the node A's neighboring nodes. For
OSPFv2, the LS is a opaque LSA of LS type 9 (i.e., a link local scope
LSA). For IS-IS, the TLV is advertised in Circuit Scoped Link State
PDUs (CS-LSP) [RFC7356].
Alternatively, when a protocol (such as PCE or BGP running on a
controller) supports sending a binding on a node A to A, this
protocol may be extended to send the binding with node A to A's
neighbors if the controller knows the neighbors and there are
protocol (PCE or BGP) sessions between the controller and the
neighbors. neighbors.
3.1. Advertising Proxy Forwarding Note: how to send bindings of node A to A's neighbors via which
protocol is out of the scope of this document.
3.2. Advertising Proxy Forwarding
When a node P is able to do SR proxy forwarding for its neighboring When a node P is able to do SR proxy forwarding for its neighboring
nodes for protecting the failures of these nodes, P advertises its SR nodes for protecting the failures of these nodes, P advertises its SR
proxy forwarding capability for these nodes. The mirror SID proxy forwarding capability for these nodes. The mirror SID
[RFC8402][RFC8667] for a node N (Neighbor of P) advertised by P [RFC8402] for a node N (Neighbor of P) advertised by P using IS-IS
indicates the capability of P for N. extensions [RFC8667] indicates the capability of P for N.
For a node X in the network, it learns the prefix/node SID of node N, For a node X in the network, it learns the prefix/node SID of node N,
which is originated and advertised by node N. It creates a proxy which is originated and advertised by node N. It creates a proxy
prefix/node SID of node N for node P if node P is capable of doing SR prefix/node SID of node N for node P if node P is capable of doing SR
proxy forwarding for node N. The proxy prefix/node SID of node N for proxy forwarding for node N. The proxy prefix/node SID of node N for
node P is a copy of the prefix/node SID of node N originated by node node P is a copy of the prefix/node SID of node N originated by node
N, but stored under (or say, associated with) node P. The route to N, but stored under (or say, associated with) node P. The route to
the proxy prefix/node SID is through proxy forwarding capable nodes. the proxy prefix/node SID is through proxy forwarding capable nodes.
In normal operations, node X prefers to use the prefix/node SID of In normal operations, node X prefers to use the prefix/node SID of
skipping to change at page 5, line 23 skipping to change at page 5, line 46
traffic towards its final destination without going through node N. traffic towards its final destination without going through node N.
Note that the behaviors of normal IP forwarding and routing Note that the behaviors of normal IP forwarding and routing
convergences in a network are not changed at all by the SR proxy convergences in a network are not changed at all by the SR proxy
forwarding. For example, the next hop used by BGP is an IP address forwarding. For example, the next hop used by BGP is an IP address
(or prefix). The IGP and BGP converge in normal ways for changes in (or prefix). The IGP and BGP converge in normal ways for changes in
the network. The packet with its IP destination to this next hop is the network. The packet with its IP destination to this next hop is
forwarded according to the IP forwarding table (FIB) derived from IGP forwarded according to the IP forwarding table (FIB) derived from IGP
and BGP routes. and BGP routes.
Alternatively, P advertises its capability in its LS. For OSPF, P Similar to IS-IS [RFC8667], OSPF should be extended for advertising
advertises its information opaque LSA with one bit (called PF bit) mirror SID to indicate the capability. Note that OSPF extensions is
set to one indicating that P has the capability for all its out of the scope of this document.
neighbors. For IS-IS, P advertises its LSP with PF bit.
If node P can not do a SR proxy forwarding for all its neighboring
nodes, but for some of them, then it advertises the node SID of each
of the nodes as a proxy node SID, indicating that it is able to do
proxy forwarding for the node SID.
3.2. Advertising Binding Segment
For a binding segment (or binding for short) on a node A, which
consists of a binding SID and a list of segments, node A advertises
an LS containing the binding (i.e., the binding SID and the list of
the segments) in a binding segment TLV. The LS is advertised only to
each of the node A's neighboring nodes. For OSPFv2, the LS is a
opaque LSA of LS type 9 (i.e., a link local scope LSA). For IS-IS,
the TLV is advertised in Circuit Scoped Link State PDUs (CS-LSP)
[RFC7356].
Alternatively, when a protocol (such as PCE or BGP running on a
controller) supports sending a binding on a node A to A, this
protocol may be extended to send the binding with node A to A's
neighbors if the controller knows the neighbors and there are
protocol (PCE or BGP) sessions between the controller and the
neighbors.
4. Proxy Forwarding Example 4. Proxy Forwarding Example
This section illustrates the proxy forwarding for a binding SID This section illustrates the proxy forwarding for a binding SID
through an example. The proxy forwarding for a node SID and an through an example. The proxy forwarding for a node SID and an
adjacency SID can refer to adjacency SID can refer to
[I-D.ietf-spring-segment-protection-sr-te-paths] or Appendix. [I-D.ietf-spring-segment-protection-sr-te-paths] or Appendix.
Figure 1 is an example network topology used to illustrate the proxy Figure 1 is an example network topology used to illustrate the proxy
forwarding mechanism for a binding SID. Each node N has SRGB = forwarding mechanism for a binding SID. Each node N has SRGB =
[N000-N999]. RT1 is an ingress node of SR domain. RT3 is a failure [N000-N999]. RT1 is an ingress node of SR domain. RT3 is a failure
skipping to change at page 10, line 21 skipping to change at page 10, line 21
two types of behaviors in data plane when a node in a network fails. two types of behaviors in data plane when a node in a network fails.
One is that for a node, which is a upstream (except for the direct One is that for a node, which is a upstream (except for the direct
upstream) node of the failed node along a SR-TE path, it continues to upstream) node of the failed node along a SR-TE path, it continues to
send the traffic to the failed node along the SR-TE path for an send the traffic to the failed node along the SR-TE path for an
extended period of time. The other is that for a node, which is the extended period of time. The other is that for a node, which is the
direct upstream node of the failed node, it fast re-routes the direct upstream node of the failed node, it fast re-routes the
traffic around the failed node to the direct downstream node of the traffic around the failed node to the direct downstream node of the
failed node along the SR-TE path. These behaviors are internal to a failed node along the SR-TE path. These behaviors are internal to a
network and should not cause extra security issues. network and should not cause extra security issues.
6. IANA Considerations 6. Acknowledgements
7. Acknowledgements
The authors would like to thank Peter Psenak, Acee Lindem, Les The authors would like to thank Peter Psenak, Acee Lindem, Les
Ginsberg, Bruno Decraene and Jeff Tantsura for their comments to this Ginsberg, Bruno Decraene and Jeff Tantsura for their comments to this
work. work.
8. References 7. References
8.1. Normative References 7.1. Normative References
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356, Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014, DOI 10.17487/RFC7356, September 2014,
<https://www.rfc-editor.org/info/rfc7356>. <https://www.rfc-editor.org/info/rfc7356>.
skipping to change at page 11, line 11 skipping to change at page 11, line 11
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667, Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019, DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>. <https://www.rfc-editor.org/info/rfc8667>.
8.2. Informative References 7.2. Informative References
[I-D.ietf-rtgwg-segment-routing-ti-lfa] [I-D.ietf-rtgwg-segment-routing-ti-lfa]
Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress, Reroute using Segment Routing", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
08, 21 January 2022, <https://www.ietf.org/archive/id/ 08, 21 January 2022, <https://www.ietf.org/archive/id/
draft-ietf-rtgwg-segment-routing-ti-lfa-08.txt>. draft-ietf-rtgwg-segment-routing-ti-lfa-08.txt>.
[I-D.ietf-spring-segment-protection-sr-te-paths] [I-D.ietf-spring-segment-protection-sr-te-paths]
Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu,
"Segment Protection for SR-TE Paths", Work in Progress, "Segment Protection for SR-TE Paths", Work in Progress,
Internet-Draft, draft-ietf-spring-segment-protection-sr- Internet-Draft, draft-ietf-spring-segment-protection-sr-
te-paths-02, 21 January 2022, te-paths-03, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-spring- <https://www.ietf.org/archive/id/draft-ietf-spring-
segment-protection-sr-te-paths-02.txt>. segment-protection-sr-te-paths-03.txt>.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", Work in P. Mattes, "Segment Routing Policy Architecture", Work in
Progress, Internet-Draft, draft-ietf-spring-segment- Progress, Internet-Draft, draft-ietf-spring-segment-
routing-policy-18, 17 February 2022, routing-policy-22, 22 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-spring- <https://www.ietf.org/archive/id/draft-ietf-spring-
segment-routing-policy-18.txt>. segment-routing-policy-22.txt>.
Appendix A. Proxy Forwarding for Adjacency and Node Segment Appendix A. Proxy Forwarding for Adjacency and Node Segment
This Section shows through example how a proxy node forward traffic This Section shows through example how a proxy node forward traffic
to the destination node when a node fails and the next segment of to the destination node when a node fails and the next segment of
label stack is an adjacency-SID or node-SID. label stack is an adjacency-SID or node-SID.
A.1. Next Segment is an Adjacency Segment A.1. Next Segment is an Adjacency Segment
As shown in Figure 1, Label Stack 3 {10012, 20023, 30034, 40045} uses As shown in Figure 1, Label Stack 3 {10012, 20023, 30034, 40045} uses
 End of changes. 21 change blocks. 
63 lines changed or deleted 57 lines changed or added

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