rtgwg Working Group W. Cheng
Internet-Draft W.Jiang
Intended status: Standards Track China Mobile
Expires: April 27, 2023 C. Lin
New H3C Technologies
Z. Hu
Huawei Technologies
Y. Qiu
New H3C Technologies
October 24, 2022
SRv6 Egress Protection in Multi-homed scenario
draft-cheng-rtgwg-srv6-multihome-egress-protection-02
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 27 2023.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Cheng, et al. Expire April, 2023 [Page 1]
Internet-Draft Multi-homed SRv6 Egress Protection October 2022
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This document describes a SRv6 egress node protection mechanism in
multi-homed scenarios.
Table of Contents
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Multi-homed SRv6 Egress Protection Mechanism ................ 3
3.1. Procedure on the Ingress Endpoint ...................... 4
3.2. Procedure on the Penultimate Endpoint .................. 5
4. Multi-homed SRv6 Egress Protection Example .................. 7
5. IANA Considerations ......................................... 9
6. Security Considerations ..................................... 9
7. References ................................................. 10
7.1. Normative References .................................. 10
7.2. Informative References ................................ 11
8. Acknowledgments ............................................ 11
Authors' Addresses ............................................ 11
1. Introduction
The fast protection of a transit node of a Segment Routing (SR) path
or tunnel is described in [I-D.ietf-rtgwg-segment-routing-ti-lfa]
and [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8400]
specifies the fast protection of egress node(s) of an MPLS TE LSP
tunnel including P2P TE LSP tunnel and P2MP TE LSP tunnel in details.
However, these documents do not discuss the fast protection of the
egress node of a Segment Routing for IPv6 (SRv6) path or tunnel.
[I-D.ietf-rtgwg-srv6-egress-protection] proposes mirror protection
mechanism and presents protocol extensions for the fast protection
of the egress node of a SRv6 path or tunnel. However, the mechanism
provided in this document is relatively complex. It is necessary to
configure the Mirror SID for the protected egress node on the backup
egress node. The mirror relationship needs to be distributed through
IGP and BGP protocols to automatically create mapping entries.
Cheng, et al. Expires April, 2023 [Page 2]
Internet-Draft Multi-homed SRv6 Egress Protection October 2022
This document introduces a simplified protection mechanism of the
egress node of a SRv6 path. Only expanding the data plane can
perform fast path switching in case of egress node failure.
2. Terminology
The following terminologies are used in this document.
SR: Segment Routing
SRv6: SR for IPv6
SRH: Segment Routing Header
SID: Segment Identifier
CE: Customer Edge
PE: Provider Edge
VPN: Virtual Private Network
PSD: Penultimate Segment Decapsulation
3. Multi-homed SRv6 Egress Protection Mechanism
This section describes the mechanism of SRv6 path egress protection
in multi-homed scenarios and the extension of SRH extension header.
Figure 1 is used to explain the multi-homed egress node protection
mechanism.
Cheng, et al. Expires April, 2023 [Page 3]
Internet-Draft Multi-homed SRv6 Egress Protection October 2022
Locator: A3:1::/64
VPN SID: A3:1::B100
+---+ *** +---+ *** +---+ *** +---+ +---+
|PE1|-----| P1|-----| P2|-----|PE3|---|CE2|
+---+ +---+ +---+ +---+ +---+
/ | | | | \ /
+---+/ | | | | \ /
|CE1| | | | | X
+---+\ | | | | / \
\ | | | | / \
+---+ +---+ +---+ +---+ +---+
|PE2|-----| P3|-----| P4|-----|PE4|---|CE3|
+---+ +---+ +---+ +---+ +---+
Locator: A4:1::/64
VPN SID: A4:1::B100
PE3 Egress
PE4 Backup Egress
CEx Customer Edge
Px Non-Provider Edge
*** SR Path
Figure 1
3.1. Procedure on the Ingress Endpoint
In the CE multi-homed or double-homed scenario, the ingress node
learns the multi-homed or double-homed route of CE through the
routing protocol, and then determines the optimal path and
suboptimal path according to the routing optimization strategy. The
egress node on the optimal path acts as the primary egress, and the
SID of the primary egress node is used as the primary SID. The
egress node on the suboptimal path acts as the backup egress, and
the SID of the backup egress node is used as the backup SID.
On the path forwarded based on SRv6 TE policy, when the ingress node
encapsulates the SRH extension header, judge whether the primary VPN
SID of the egress node (PE1) has a backup SID. If yes, insert the
backup SID into the position of Segment List[0]. The format of SRH
extension header filling is shown in the following Figure 2.
Cheng, et al. Expires April, 2023 [Page 4]
Internet-Draft Multi-homed SRv6 Egress Protection October 2022
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | SL = n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry=n | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Backup SID (Segment List[0],128 bits IPv6 value) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Primary SID (Segment List[1], 128 bits IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[n] (128 bits IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional Type Length Value objects (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
3.2. Procedure on the Penultimate Endpoint
Normally, the traffic is forwarded along the path P1->P2->PE3->CE2.
When the primary egress node PE3 receives a packet whose IPv6 DA is
a local SID, PE3 removes the outer packet header with all its
extension headers and submits the packet to the egress FIB lookup
for transmission to the new destination. However, because Segment
Cheng, et al. Expires April, 2023 [Page 5]
Internet-Draft Multi-homed SRv6 Egress Protection October 2022
List[0] carries the backup SID, according to [RFC8986], the primary
egress node PE3 will not perform SRv6 decapsulation.
In order to indicate the SRv6 penultimate segment decapsulation
processing, define PSD(Penultimate Segment Decapsulation) Flavor.
SR Segment Endpoint nodes receive the IPv6 packet with the
Destination Address field of the IPv6 header equal to its SID
address.
A penultimate SRv6 Segment Endpoint node is one that, as part of the
SID processing, copies the last SID from the SRH into the IPv6
Destination Address and decrements the Segments Left value from one
to zero.
When a node receives an SID with PSD Flavor, it indicates to remove
the outer encapsulation of the packet, and forward the packet
according to the exposed packet.
The PSD operation only takes place at a penultimate SR Segment
Endpoint node and does not happen at any transit node. When a SID of
PSD flavor is processed at a transit node, the PSD behavior is not
performed as described in the pseudocode below since Segments Left
would not be 1 or 0.
PSD Flavor can apply to End.DT4, End.DT6, End.DT46, End.DX4, End.DX6,
End.DX2, End.DX2V and End.DX2M. The SIDs can be advertised via
routing protocol.
The SRH processing of the End.DT4, End.DT6, End.DT46, End.DX4,
End.DX6, End.DX2, End.DX2V and End.DX2M behaviors defined in
[RFC8986] are modified; the instructions S02 are substituted by the
following one:
S02. If ((Segments Left != 0) && (Segments Left != 1)) {
Normally, the traffic is forwarded along the path P1->P2->PE3->CE2.
When PE3 receives a packet whose IPv6 DA is S and S is a local PSD-
flavored SID, PE3 removes the outer packet header with all its
extension headers and submits the packet to the egress FIB lookup
for transmission to the new destination.
When primary egress node (PE3) fails, P2 finds out that the PE3's
SID is unreachable. Then, P2 sequentially looks up the Segment List
after the current unreachable SID and finds the first reachable
downstream nodes. The specific operations are as follows:
Cheng, et al. Expires April, 2023 [Page 6]
Internet-Draft Multi-homed SRv6 Egress Protection October 2022
P2 decreases SL by 1 and then modifies the destination address of
the packet to Segment List[SL]. Because Segment List[0] is the
backup SID, if the backup egress node (PE4) is reachable, P2 sends
the modified packet to PE4. In this way, P2 provides fast protection
for the egress failure and greatly shortens the cut-off time.
After receiving the packet, as long as any of the following cases is
met, the penultimate endpoint acting as the repair node can provide
fast protection against the failure of the egress node.
Case 1: When the destination address of the received packet is the
local END.X SID, the outgoing interface is down.
Case 2: When the destination address of the received packet is the
local END SID, the FIB is looked up for the updated DA with
Segment List[SL] and the SL is reduced.
The detailed processing to be performed by the penultimate node is
as follows:
IF SL = 1 THEN
SL decreases by 1 and becomes 0;
Update the IPv6 DA with Segment List[0];
FIB lookup on the updated DA;
Forward the packet according to the matched entry;
When the packet arrives at PE4, PE4 removes the outer IPv6 header,
and forwards the original packet.
After the route convergence is completed, the ingress node (PE1)
will reselect the forwarding path for the traffic to VPN, and switch
the path (P1->P3->P4->PE4->CE2) to the CE to the egress node (PE4).
After that, P2 no longer needs to forward the packet with the
destination address of PE3's PSD-flavored SID.
4. Multi-homed SRv6 Egress Protection Example
Figure 3 shows an example of protecting egress PE3 of a SRv6 TE path,
which is from ingress PE1 to egress PE3.
Cheng, et al. Expires April, 2023 [Page 7]
Internet-Draft Multi-homed SRv6 Egress Protection October 2022
A0:1::1 A1:1::1 A2:1::A100 A3:1::B100
+---+ *** +---+ **** +---+ **** +---+ +---+
|PE1|-----| P1|------| P2|------|PE3|---|CE2|
+---+ +---+ +---+ +---+ +---+
/ | | |& | \ /
+---+/ | | |& | \ /
|CE1| | | |& | X
+---+\ | | |& | / \
\ | | |& | / \
+---+ +---+ +---+ &&&& +---+ +---+
|PE2|-----| P3|------| P4|------|PE4|---|CE3|
+---+ +---+ +---+ +---+ +---+
A4:1::B100
PE3 Egress
PE4 Backup Egress
CEx Customer Edge
Px Non-Provider Edge
*** SR Path
&&& backup Path
Figure 3
In this document, a SID list is represented as <S1, S2, S3> where S1
is the first SID to visit, S2 is the second SID to visit and S3 is
the last SID to visit along the SRv6 path.
In Figure 3, Both CE2 and CE3 are dual homed to PE3 and PE4. PE1 has
a locator A0:1::/64. P1 has a locator A1:1::/64. P2 has a locator
A2:1::/64 and END.X SID A2:1::A100. PE3 has a locator A3:1::/64 and
a VPN SID A3:1::B100 with PSD-flavored behavior. PE4 has a locator
A4:1::/64 and VPN SID A4:1::B100. The traffic from CE1 to CE2 is
forwarded along the path PE1->P1->P2->PE3. After the configuration,
PE1 determines that PE3's backup SID is PE4's VPN SID through the
routing optimization strategy of BGP.
When PE1 receives the packet from CE1 to CE2, PE1 encapsulates the
packet with IPv6 header. The segment list in SRH is designed as <
A1:1::1, A2:1::A100, A3:1::B100, A4:1::B100>. The SL is set to 3.
In normal operations, When P2 receives a packet destined to END.X
SID A2:1::A100, it decreases SL by 1 and forwards the packet with
source A0:1::1 and destination PE3's VPN SID A3:1::B100 from the
link between P2 and PE3 according to END.X SID. The SL of the packet
sent to PE3 is 1. When the packet arrives at PE3, the destination
address A3:1::B100 matches PE3's PSD-flavored SID. PE3 as the
penultimate endpoint performs decapsulation and forwarding
processing. The specific operations of PE3 are as follows:
1) Remove the outer packet header and all its extension headers.
Cheng, et al. Expires April, 2023 [Page 8]
Internet-Draft Multi-homed SRv6 Egress Protection October 2022
2) Look up the FIB table according to the destination address of the
original packet.
3) Send the packet to CE2 according to the FIB entry.
After PE3 fails, P2 receives the packet to be sent to PE3's VPN SID
A3:1::B100. After decreasing SL P2 finds that the outgoing interface
is down. P2 continues to decrease SL by 1 and obtains the next
reachable SID of PE4's SID from the segment list. The SL changes to
0. P2 changes the destination address of the packet with the backup
SID of Segment List[0] and sends the modified packet to A4:1::B100.
When PE4 receives the modified packet, it decapsulates the packet
and forwards the decapsulated packet by executing END.DT6 behavior
for an END.DT6 SID instance.
5. IANA Considerations
This document requests IANA to allocate the following codepoints for
PSD flavor behaviors within the "SRv6 Endpoint Behaviors" sub-
registry under the top-level "Segment Routing Parameters" registry.
+-------+--------+----------------------------+-----------+
| Value | Hex | Endpoint behavior | Reference |
+-------+--------+----------------------------+-----------+
| 140 | 0x008C | End.DX6 with PSD | [This.ID] |
| 141 | 0x008D | End.DX4 with PSD | [This.ID] |
| 142 | 0x008E | End.DT6 with PSD | [This.ID] |
| 143 | 0x008F | End.DT4 with PSD | [This.ID] |
| 144 | 0x0090 | End.DT46 with PSD | [This.ID] |
| 145 | 0x0091 | End.DX2 with PSD | [This.ID] |
| 146 | 0x0092 | End.DX2V with PSD | [This.ID] |
| 147 | 0x0093 | End.DT2U with PSD | [This.ID] |
| 148 | 0x0094 | End.DT2M with PSD | [This.ID] |
+-------+--------+----------------------------+-----------+
Table 1: IETF - SRv6 Endpoint Behaviors
6. Security Considerations
[RFC8754] defines the notion of an SR domain and use of SRH within
the SR domain. The use of egress protection mechanism described in
this document is restricted to an SR domain. Procedures for securing
an SR domain are defined the section 5.1 and section 7 of [RFC8754].
This document does not impose any additional security challenges to
be considered beyond security threats described in [RFC8754],
[RFC8679] and [RFC8986].
Cheng, et al. Expires April, 2023 [Page 9]
Internet-Draft Multi-homed SRv6 Egress Protection October 2022
7. References
7.1. Normative References
[I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A.,
Filsfils, C., Francois, P., Decraene, B., and D. Voyer,
"Topology Independent Fast Reroute using Segment Routing",
Work in Progress, Internet-Draft, draft-ietf-rtgwg-
segment-routing-ti-lfa-08, 21 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-rtgwg-segment-
routing-ti-lfa-08.txt>.
[I-D.hu-spring-segment-routing-proxy-forwarding] Hu, Z., Chen, H.,
Yao, J., Bowers, C., Yongqing, and Yisong, "SR-TE Path
Midpoint Restoration", Work in Progress, Internet-Draft,
draft-hu-spring-segment-routing-proxy-forwarding-20, 18
August 2022, <https://www.ietf.org/archive/id/draft-hu-
spring-segment-routing-proxy-forwarding-19.txt>.
[I-D.ietf-rtgwg-srv6-egress-protection] Hu, Z., Chen, H., Chen, H.,
Wu, P., Toy, M., Cao, C., He T., Liu, L., Liu, X., "SRv6
Path Egress Protection", Work in Progress, Internet-Draft,
draft-ietf-rtgwg-srv6-egress-protection-07, 22 September
2022, < https://www.ietf.org/archive/id/draft-ietf-rtgwg-
srv6-egress-protection-05.txt>
[RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang,
"Extensions to RSVP-TE for Label Switched Path (LSP)
Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June
2018, <https://www.rfc-editor.org/info/rfc8400>.
[RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H.,
Michel, C., and H. Chen, "MPLS Egress Protection
Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019,
<https://www.rfc-editor.org/info/rfc8679>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing
Header(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, DOI
10.17487/RFC8986, February 2021, <https://www.rfc-
editor.org/info/rfc8986>.
Cheng, et al. Expires April, 2023 [Page 10]
Internet-Draft Multi-homed SRv6 Egress Protection October 2022
7.2. Informative References
TBD
8. Acknowledgments
The authors would like to thank the following for their valuable
contributions of this document:
Yisong Liu
China Mobile
Authors' Addresses
Weiqiang Cheng
China Mobile
Email: chengweiqiang@chinamobile.com
Wenying Jiang
China Mobile
Email: jiangwenying@chinamobile.com
Changwang Lin
New H3C Technologies
Email: linchangwang.04414@h3c.com
Zhibo Hu
Huawei Technologies
Email: huzhibo@huawei.com
Yuanxiang Qiu
New H3C Technologies
Email: qiuyuanxiang@h3c.com
Cheng, et al. Expires April, 2023 [Page 11]