RTGWG F. Yang Internet-Draft X. Zhang Intended status: Standards Track China Mobile Expires: April 23, 2024 C. Lin Y. Qiu New H3C Technologies October 21, 2023 Reliability Framework for SRv6 Service Function Chaining draft-yang-rtgwg-srv6-sfc-reliability-framework-00 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 23, 2024. Copyright Notice Copyright (c) 2023 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 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 Yang, et al. Expires April, 2024 [Page 1] Internet-Draft Reliability Framework for SFC October 2023 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document describes the framework for protection of service function chains in source routing networks. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 1.2. Terminology...............................................3 2. Background Requirements........................................4 3. SFC Reliability Protection Mechanisms..........................5 3.1. SF Dual-homed Connection Protection Method................5 3.1.1. Static SR Proxy......................................5 3.1.2. Dynamic SR Proxy.....................................7 3.1.3. Masquerading SR Proxy................................9 3.1.4. SRv6-aware SF.......................................11 3.2. SF Bypass Protection Method..............................12 3.2.1. Static SR Proxy.....................................12 3.2.2. Dynamic SR Proxy....................................13 3.2.3. Masquerading SR Proxy...............................14 3.2.4. SRv6-aware SF.......................................15 3.3. SFF Direct forwarding Method.............................16 4. Changes in SR Proxy Behavior..................................16 5. IANA Considerations...........................................18 5.1. SRv6 Endpoint behavior...................................18 5.2. SRv6 Endpoint Flavor.....................................18 6. Security Considerations.......................................18 7. References....................................................19 7.1. Normative References.....................................19 7.2. Informative References...................................19 8. Acknowledgments...............................................19 Authors' Addresses...............................................20 1. Introduction Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. SR can be instantiated on the MPLS data plane (MPLS-SR) and the IPv6 data plane (SRv6). On the MPLS-SR data plane, a segment is encoded as an MPLS label, and an ordered list of segments is encoded as a stack of labels. On the SRv6 data plane, a segment is encoded as an IPv6 address (SRv6 Yang, et al. Expires April, 2024 [Page 2] Internet-Draft Reliability Framework for SFC October 2023 SID) [RFC8986], and an ordered list of segments is encoded as an ordered list of SRv6 SIDs in the SR header (SRH) [RFC8754]. The ingress node steers packets into a specific path according to the ordered list of segments (SR Policy) as defined in [RFC9256]. Service Function Chaining (SFC) defines an ordered set of service functions and subsequent "steering" of traffic through them. The architecture of SFC is defined in [RFC7665]. This document describes the common failure scenarios and protection mechanisms of service function chains in SR networks. Then implementation recommendations for protection of service function chains are proposed. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology The terms in this document are defined in [RFC7665], [RFC8459], [RFC8986] and [I-D.ietf-spring-sr-service-programming]. The following lists widely used terms in this document. MPLS-SR: Segment Routing over MPLS SRv6: Segment Routing over IPv6 CF: Classifier NSH: Network Service Header SF: Service Function SFF: Service Function Forwarder SFC: Service Function Chaining SR: Segment Routing Yang, et al. Expires April, 2024 [Page 3] Internet-Draft Reliability Framework for SFC October 2023 2. Background Requirements In SRv6 networks, programming of forwarding paths can be achieved through the combination of SIDs. If the programming paths sequentially pass through the specified SF, SFC is achieved, which is the main idea of stateless SRv6 SFC solution. The architecture of the Stateless SRv6 SFC solution is shown in Figure 1, which includes the following key components: * SRv6-aware SF: SF nodes that support SRv6 can be directly connected to SFF. * SRv6-unaware SF: SF nodes that do not support SRv6 need to deploy an SRv6 proxy between SFF and SRv6-unaware SF to complete the processing of SRv6 packets. * SRv6 Proxy: The proxy for SRv6, which forwards packets from the SRv6 network to the SRv6 unaware SF and returns them from the SRv6-unaware SF to the SRv6 network. +------------+ |SRv6-unaware| | SF1 | +-----+------+ | +-----+------+ | +---+----+ | +------------+ | | SR | | | SRv6-aware | | | Proxy | | | SF2 | | +---+----+ | +-----+------+ | | | | +--------+ +------------+ | +---+----+ | +---+---+ +------+ | Source +--+ Classifier +--+-+ SFF1 +-+---+ SFF2 +--+ Dest | +--------+ +------------+ | +--------+ | +-------+ +------+ +------------+ Figure 1 The SRv6 proxy caches the mapping relationship between SRH and the virtual interface connecting SF, which is used to recover SRv6 packets based on the virtual interface when packets return from SF. Currently, during the deployment of SFC, we have encountered some reliability issues with SF. Taking the simple networking model in Figure 2 as an example, once the routing between SFF and SF is unreachable, packets that need to be processed by the service node SF will be discarded upon arrival at SFF. The packet cannot be further forwarded or processed by the service node. Yang, et al. Expires April, 2024 [Page 4] Internet-Draft Reliability Framework for SFC October 2023 ,-----. ,-----. ,' User `. ,' User `. ( Network ) +--------+ ( Network ) `. ,' | SF | `. ,' `--+--' +----+---+ `--+--' | | | +-----+------+ +----+---+ +-----------+ +----+-----+ | Ingress A +--+ SFF +--+ SRv6 Node +--+ Egress | |(Classifier)| | B | | C | | D | +------------+ +--------+ +-----------+ +----------+ Figure 2 In order to improve the reliability of SFC, we propose the following three reliability protection mechanisms: * SF dual-homed connection protection method * SF bypass protection method * SFF direct forwarding method 3. SFC Reliability Protection Mechanisms 3.1. SF Dual-homed Connection Protection Method SF dual-homed connection refers to the connection of an service function node dual-homed to two primary and backup SFFs. When the primary SFF cannot reach SF, the service switches to the backup SFF for processing. The following describes the working process of SF dual-homed connection protection mechanism based on SF's SRv6 capabilities and SRv6 Proxy behavior. 3.1.1. Static SR Proxy As shown in Figure 3, SFF1 and SFF2 are two Service Function Forwarders that are backed up to each other, and SF is connected to both SFF 1 and SFF 2. Yang, et al. Expires April, 2024 [Page 5] Internet-Draft Reliability Framework for SFC October 2023 Primary End.AS SID=X1 Backup End.AS SID=X2 SRH SID list(E2,E1,D,X1) +-------+ +-----+ | SFF1 +-----+ SF | |(SID=B)| +-----+ +-------+ / +------------+ / \ / | Ingress | / \ / |(Classifier)| X | (SID=A) | \ / \ +------------+ \ / \ +------------+ +-------+ \+-------+ | Egress | | SFF2 +-----+ Node D+-----+ (SID=E1) | |(SID=C)| |(SID=D)| |(DT4 SID=E2)| +-------+ +-------+ +------------+ Primary End.AS SID=X1 Backup End.AS SID=X2 SRH SID list(E2,E1,D,X1) Figure 3 Firstly, configure SFF 1 and SFF 2 as follows: * Configure the mapping relationship cache entries for the same SRH and interface connecting SF on two SFFs. * Two SFFs use the same Locator segment to assign their respective End.AS SID (anycast address). * Two SFFs with the same configuration as the primary End.AS SID and Backup End.AS SID. Both specify SFF1 as the primary and SFF2 as the backup. Normally, the message is forwarded along the path Ingress->SFF1->SF->SFF1->NodeD->Egress. After receiving the message, SFF1 matches it to the local End.AS SID based on the destination address X1 of the message. SFF1 performs the processing of End.AS behavior, decapsulates the message, removes the IPv6 header and SRH, and sends the original message to SF through the interface corresponding to the service SID. When SFF1 detects that the route from SFF1 to SF is unreachable, SFF1 adds IPv6 headers and SRH to the message based on the configured backup SFF. Among them, the SID list in SRH contains the End.AS SID X2 of the backup SFF and the End SID C of the backup SFF2. The destination address of the IPv6 header is C. SFF1 searches the routing table and forwards the encapsulated message to SFF2. Yang, et al. Expires April, 2024 [Page 6] Internet-Draft Reliability Framework for SFC October 2023 After receiving the message, if the route from SFF2 to SF is reachable, the message will be processed according to the static SR proxy forwarding process. If the route from SFF2 to SF is unreachable, it is considered that both the primary and backup SFFs are unable to process and the message is discarded. The encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in Figure 4. Ingress->SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +-----------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=X1 | | DA=C | | DA=D | | DA=E1 | +------------+ +-----------+ +------------+ +------------+ |SRH: | |SRH: | |SRH: | |SRH: | | SL=3, | | SL=1, | | SL=2, | | SL=1, | |(E2,E1,D,X1)| | (X2,C) | |(E2,E1,D,X1)| |(E2,E1,D,X1)| +------------+ +-----------+ +------------+ +------------+ | Payload | | Payload | | Payload | | Payload | +------------+ +-----------+ +------------+ +------------+ Figure 4 3.1.2. Dynamic SR Proxy Compared to static SR Proxy, dynamic SR Proxy increase the ability for dynamic learning. The mapping relationship cache between SRH and the interface connecting SF is dynamically generated based on the SRH of the messages received by SFF. After enabling SF dual-homed connection protection function, when the primary SFF senses that it is not reachable to the SF, the IPv6 encapsulation and SRH are not removed. Instead, an additional IPv6 packet header is added outside the IPv6 header, and the original SRv6 header of the message is sent as a payload to the backup SFF. As shown in Figure 5, SFF1 and SFF2 are two Service Function Forwarders that are backed up to each other, and SF is connected to both SFF 1 and SFF 2. Firstly, configure SFF 1 and SFF 2 as follows: * Configure the mapping relationship cache entries for the same SRH and interface connecting SF on two SFFs. * Two SFFs use the same Locator segment to assign their respective End.AD SID (anycast address). Yang, et al. Expires April, 2024 [Page 7] Internet-Draft Reliability Framework for SFC October 2023 * Two SFFs with the same configuration as the primary End.AD SID and Backup End.AD SID. Both specify SFF1 as the primary and SFF2 as the backup. Primary End.AD SID=X1 Backup End.AD SID=X2 SRH SID list(E2,E1,D,X1) +-------+ +-----+ | SFF1 +-----+ SF | |(SID=B)| +-----+ +-------+ / +------------+ / \ / | Ingress | / \ / |(Classifier)| X | (SID=A) | \ / \ +------------+ \ / \ +------------+ +-------+ \+-------+ | Egress | | SFF2 +-----+ Node D+-----+ (SID=E1) | |(SID=C)| |(SID=D)| |(DT4 SID=E2)| +-------+ +-------+ +------------+ Primary End.AD SID=X1 Backup End.AD SID=X2 SRH SID list(E2,E1,D,X1) Figure 5 Normally, the message is forwarded along the path Ingress->SFF1->SF->SFF1->NodeD->Egress. After receiving the message, SFF1 matches it to the local End.AD SID based on the destination address X1 of the message. SFF1 performs the processing of End.AD behavior, decapsulates the message, removes the IPv6 header and SRH, and sends the original message to SF through the interface corresponding to the service SID. At the same time, SFF1 records the mapping relationship cache between SRH and the interface connecting SF, in order to recover the SRH based on the virtual interface when the message returns from SF. When SFF1 detects that the route from SFF1 to SF is unreachable, SFF1 does not remove the existing IPv6 header and SRH, and adds another SRv6 encapsulation to the message based on the configured backup SFF SID. Among them, the SRH SID list of the outer IPv6 header contains SFF2's End.AD SID X2 and End SID C. The destination address of the IPv6 header is C. SFF1 searches the routing table and forwards the encapsulated message to SFF2. After the message arrives at SFF2, it is matched to the local End.AD SID based on the destination address X2. SFF2 executes the End.AD Yang, et al. Expires April, 2024 [Page 8] Internet-Draft Reliability Framework for SFC October 2023 behavior processing of X2, removes the outermost IPv6 header and SRH, and restores the inner IPv6 packet. Therefore, the DA of IPv6 packets is X1, and the End.AD SID will be matched again on SFF2. SFF2 executes the End.AD behavior again, decapsulates the IPv6 encapsulation of the packet, removes the IPv6 header and SRH, and sends the original message to SF through the virtual interface connecting to SF. SFF2 also needs to record the mapping relationship between SRH and the interface connecting SF, which is used to recover the SRv6 encapsulation of messages returned from SF. If the route from SFF2 to SF is unreachable, it is considered that both the primary and backup SFFs are unable to process and the message is discarded. The encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in Figure 6. Ingress->SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=X1 | | DA=C | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | |SRH: | |SRH: | |SRH: | | SL=3, | | SL=1, | | SL=2, | | SL=1, | |(E2,E1,D,X1)| | (X2,C) | |(E2,E1,D,X1)| |(E2,E1,D,X1)| +------------+ +------------+ +------------+ +------------+ | Payload | |IPv6 Hdr: | | Payload | | Payload | +------------+ | DA=D | +------------+ +------------+ +------------+ |SRH: | | SL=2, | |(E2,E1,D,X1)| +------------+ | Payload | +------------+ Figure 6 3.1.3. Masquerading SR Proxy SFC masquerading proxy is suitable for scenarios where SF can recognize SRv6 packets but does not support processing SRH. Before forwarding the message to the SF, the masquerading SR proxy first updates SID[0] of Segment list to DA, and then directly forwards the SRv6 message to SF. After SF completes the service processing, it does not process the SRv6 SRH and forwards the message back to SFF. Yang, et al. Expires April, 2024 [Page 9] Internet-Draft Reliability Framework for SFC October 2023 After receiving the message returned from SF, SFF updates DA to SID[SL] of Segment list and continues forwarding. Because the SRH has always been carried in the message without modification, SFF does not need to reseal the SRH after receiving the message returned from SF, and can directly use the SRH inside the message. In the scenario of using masquerading SR proxy, after enabling SF dual-homed connection protection function, when the primary SFF senses that the route with SF is unreachable, the primary SFF does not remove the IPv6 header and SRH, and adds an additional SRv6 header to send the original IPv6 packet as a payload to the backup SFF. Taking Figure 7 as an example, the detailed protection processing process is as follows. Primary End.AM SID=X1 Backup End.AM SID=X2 SRH SID list(E2,E1,D,X1) +-------+ +-----+ | SFF1 +-----+ SF | |(SID=B)| +-----+ +-------+ / +------------+ / \ / | Ingress | / \ / |(Classifier)| X | (SID=A) | \ / \ +------------+ \ / \ +------------+ +-------+ \+-------+ | Egress | | SFF2 +-----+ Node D+---+ (SID=E1) | |(SID=C)| |(SID=D)| |(DT4 SID=E2)| +-------+ +-------+ +------------+ Primary End.AM SID=X1 Backup End.AM SID=X2 SRH SID list(E2,E1,D,X1) Figure 7 Configure SFF 1 and SFF 2 as follows: * Configure the mapping relationship cache entries for the same SRH and interface connecting SF on two SFFs. * Two SFFs use the same Locator segment to assign their respective End.AM SID (anycast address). Yang, et al. Expires April, 2024 [Page 10] Internet-Draft Reliability Framework for SFC October 2023 * Two SFFs with the same configuration as the primary End.AM SID and Backup End.AM SID. Both specify SFF1 as the primary and SFF2 as the backup. Normally, the message is forwarded along the path Ingress->SFF1->SF->SFF1->NodeD->Egress. After receiving the message, SFF1 matches it to the local End.AM SID based on DA X1 of the message. SFF1 performs the processing of the End.AM behavior, changing DA to SID[0] of Segment list, and then sending the message to SF through the interface connecting to SF. When SFF1 detects that the route from SFF1 to SF is unreachable, SFF1 changes the DA of the IPv6 header to the backup SFF's End.AM SID X2, and the SRH remains unchanged. SFF1 searches the routing table and forwards the encapsulated message to SFF2. After the message arrives at SFF2, SFF2 matches the local End.AM SID based on DA. SFF2 processes packets according to the forwarding process of the masquerading SR proxy and executes the backup End.AM behavior processing, changing DA to SID[0] of the Segment list, and then sending the message to SF through the interface connecting to SF. If the route from SFF2 to SF is unreachable, it is considered that both the primary and backup SFFs are unable to process and the message is discarded. The encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in Figure 8. Ingress->SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=X1 | | DA=X2 | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | |SRH: | |SRH: | |SRH: | | SL=3, | | SL=2, | | SL=2, | | SL=1, | |(E2,E1,D,X1)| |(E2,E1,D,X1)| |(E2,E1,D,X1)| |(E2,E1,D,X1)| +------------+ +------------+ +------------+ +------------+ | Payload | | Payload | | Payload | | Payload | +------------+ +------------+ +------------+ +------------+ Figure 8 3.1.4. SRv6-aware SF SF, which supports SRv6 functionality, serves as an SRv6 endpoint node and is arranged on the path of SRv6 Policy forwarding. Its reliability protection mechanism is identical to that of SRv6 Yang, et al. Expires April, 2024 [Page 11] Internet-Draft Reliability Framework for SFC October 2023 endpoint nodes, and no special handling is required in the SF dual- homed connection protection mechanism. 3.2. SF Bypass Protection Method SF Bypass protection refers to the process of bypassing the faulty SF of a service function node and continuing to send messages to other SF for processing. The following describes the working processes of the SF bypass protection method based on SF's SRv6 capability and SRv6 Proxy's behavior. 3.2.1. Static SR Proxy As shown in Figure 9, there is a bypass protection service function node SF2 for SF1 in the SFC network. SF1 is connected to SFF1 with a single-homed connection, and the Bypass protection service node SF2 is connected to SFF2 with a single-homed connection. In order to implement the SF bypass protection function, it is necessary to enable the bypass function on SFF 1 and configure the End.AS SID of the SFF connected to the bypass SF. +------+ +------------+ +-----+ | SF | | Egress | | SF1 | |bypass| | (SID=E1) +-+ +--+--+ +---+--+ |(DT4 SID=E2)| | | | +------------+ | +------------+ | | | | Ingress | +--+---+ +---+--+ +-------+ | |(Classifier)+---+ SFF1 +--------+ SFF2 +-------+ Node +---+ | (SID=A) | +------+ +------+ |(SID=D)| +------------+ End.AS SID=B End.AS SID=C +-------+ Bypass End.AS SID=C SRH SID list(E2,E1,D,B) SRH SID list(E2,E1,D,B) Figure 9 When SFF1 detects that it is not reachable from SFF1 to SF, SFF1 decapsulates the message, removes the IPv6 header and SRH, and re encapsulates the IPv6 header accordingly. The DA is filled with the End.AS SID of SFF2 connected to bypass SF. SFF1 looks up the routing table and forwards the encapsulated message to SFF2. After receiving the message, SFF2 processes it according to the normal SRv6 SFC static proxy forwarding process. If the route from SFF2 to SF is also unreachable, discard the message. The encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in Figure 10. Yang, et al. Expires April, 2024 [Page 12] Internet-Draft Reliability Framework for SFC October 2023 Ingress->SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=B | | DA=C | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | | Payload | |SRH: | |SRH: | | SL=3, | +------------+ | SL=2, | | SL=1, | |(E2,E1,D,B) | |(E2,E1,D,B) | |(E2,E1,D,B)| +------------+ +------------+ +------------+ | Payload | | Payload | | Payload | +------------+ +------------+ +------------+ Figure 10 3.2.2. Dynamic SR Proxy Because the dynamic SR proxy needs to dynamically generate a mapping relationship cache with the virtual interface connecting to SF based on the SRH of the message, after enabling SF bypass protection function, when the primary SFF senses that the route with SF is unreachable, it cannot remove IPv6 encapsulation and SRH. Instead, an new IPv6 header needs to be added outside the IPv6 header, and the original IPv6 packet is sent as a payload to the SFF connecting to the bypass SF. +------+ +------------+ +-----+ | SF | | Egress | | SF1 | |bypass| | (SID=E1) +-+ +--+--+ +---+--+ |(DT4 SID=E2)| | | | +------------+ | +------------+ | | | | Ingress | +--+---+ +---+--+ +-------+ | |(Classifier)+---+ SFF1 +--------+ SFF2 +-------+ Node +---+ | (SID=A) | +------+ +------+ |(SID=D)| +------------+ End.AD SID=B End.AD SID=C +-------+ Bypass End.AD SID=C Figure 11 As shown in Figure 11, there is a Bypass protection service Function SF2 for SF1. SF1 is connected to SFF1 with a single-homed connection, and the bypass protection function SF2 is connected to SFF2 with a single-homed connection. Enable the SF bypass protection function on SFF1 and specify the bypass End.AD SID is SFF2's End.AD SID. Normally, the message is forwarded along the path Ingress->SFF1->SF1->SFF1->NodeD->Egress. After receiving the message, SFF1 matches it to the local End.AD SID based on the DA. SFF1 performs the processing of the End.AD behavior, decapsulates Yang, et al. Expires April, 2024 [Page 13] Internet-Draft Reliability Framework for SFC October 2023 the message, removes the original IPv6 header and SRH, and sends the original message to SF1 through the virtual interface connecting SF1. At the same time, SFF1 records the mapping relationship cache between SRH and the interface connecting SF1. When SFF1 detects that the route from SFF1 to SF1 is unreachable, SFF1 does not modify the existing SRH and only changes the IPv6 DA of the message to bypass SFF2's End.AD SID C. SFF1 looks up the routing table and forwards the encapsulated message to SFF2. After the message arrives at SFF2, it is matched to the local End.AD SID based on the DA. SFF2 performs End.AD behavior processing, removes the outer IPv6 header and SRH, sends the original message to SF2 through the virtual interface connecting bypass SF2, and records the mapping relationship cache between SRH and the virtual interface connecting SF2. If SFF 2 to SF2 are unreachable, discard the message. The encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in Figure 12. Ingress->SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=B | | DA=C | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | |SRH: | |SRH: | |SRH: | | SL=3, | | SL=2, | | SL=2, | | SL=1, | |(E2,E1,D,B) | |(E2,E1,D,B) | |(E2,E1,D,B) | |(E2,E1,D,B) | +------------+ +------------+ +------------+ +------------+ | Payload | | Payload | | Payload | | Payload | +------------+ +------------+ +------------+ +------------+ Figure 12 3.2.3. Masquerading SR Proxy The SF bypass protection mechanism of the masquerading SR proxy is basically the same as the bypass protection processing of the dynamic SR proxy, except that the SID of the bypass SFF needs to be with End.AM behavior. Yang, et al. Expires April, 2024 [Page 14] Internet-Draft Reliability Framework for SFC October 2023 +------+ +------------+ +-----+ | SF | | Egress | | SF1 | |bypass| | (SID=E1) +-+ +--+--+ +---+--+ |(DT4 SID=E2)| | | | +------------+ | +------------+ | | | | Ingress | +--+---+ +---+--+ +-------+ | |(Classifier)+---+ SFF1 +--------+ SFF2 +-------+ Node +---+ | (SID=A) | +------+ +------+ |(SID=D)| +------------+ End.AM SID=B End.AM SID=C +-------+ Bypass End.AM SID=C Figure 13 As shown in Figure 13, when SFF1 detects that it is unreachable from SFF1 to SF1, SFF1 does not modify the existing SRH and only changes the DA to SFF's End.AM SID C. SFF1 looks up the routing table and forwards the encapsulated message to SFF2. After the message arrives at SFF2, it is matched to the local End.AM SID based on the DA. SFF2 processes messages according to the forwarding process of the masquerading SR proxy, executes End.AM behavior processing, changes DA to SID[0]of Segment list, and sends the message to SF through the interface connecting to SF. If SFF 2 to SF2 are unreachable, discard the message. The encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in Figure 12. Ingress->SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=B | | DA=C | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | |SRH: | |SRH: | |SRH: | | SL=3, | | SL=2, | | SL=2, | | SL=1, | |(E2,E1,D,B) | |(E2,E1,D,B) | |(E2,E1,D,B) | |(E2,E1,D,B) | +------------+ +------------+ +------------+ +------------+ | Payload | | Payload | | Payload | | Payload | +------------+ +------------+ +------------+ +------------+ Figure 14 3.2.4. SRv6-aware SF SF, which supports SRv6 functionality, serves as an SRv6 endpoint node and is arranged on the path of SRv6 Policy forwarding. Its reliability protection mechanism is identical to that of SRv6 endpoint nodes, and there is no need to add special processing in the SF bypass protection mechanism. Yang, et al. Expires April, 2024 [Page 15] Internet-Draft Reliability Framework for SFC October 2023 3.3. SFF Direct forwarding Method The SFF direct forwarding method is applied to scenarios where backup SFF and bypass SFF are not deployed for SR Proxy. As shown in Figure 15, when SFF1 senses an SF fault or the route to SF is unreachable, it skips the service function processing and directly forwards packets that have not been processed by SF to downstream nodes. +-----+ | SF | +--+--+ | +------------+ | +------------+ | Ingress | +--+---+ +-------+ | Egress | |(Classifier)+---+ SFF1 +----+ Node +----+ (SID=D1) | | (SID=A) | +------+ |(SID=C)| |(DT4 SID=D2)| +------------+ Proxy SID=B +-------+ +------------+ Figure 15 When SFF1 senses that SF is unreachable, it does not remove the IPv6 header, changes the destination address of the message to the SID indicated by SRH segment left, looks up the routing table, and forwards the message. 4. Changes in SR Proxy Behavior In the SFF direct forwarding method, when SR Proxy is processing local End.AS, End.AD, and End.AM SIDs, if it is unreachable to SF, the message cannot be discarded. Instead, the destination address of the message should be changed to the SID indicated by SRH segment left, and the routing table should be searched to continue forwarding the message. Among the reliability methods described in Chapter 3, there are also differences in the processing of SR Proxy SIDs on backup SFF compared to the normal End.AS, End.AD, and End.AM SID behaviors defined in [I-D.ietf-spring-sr-service-programming]. * Static SR Proxy In the Bypass protection method, the backup static SR proxy receives only the IPv6 header and payload, without the SRH extension header, and does not need to handle SRH. * Dynamic SR Proxy Yang, et al. Expires April, 2024 [Page 16] Internet-Draft Reliability Framework for SFC October 2023 After receiving an IPv6 packet from the main SFF, the backup dynamic SR proxy does not verify the consistency between DA and SRH SegmentList[SL], nor does it modify the SRH field (such as SL). In the SF dual-homed connection protection method, when the backup dynamic SR proxy receives a message with two layers of IPv6 header encapsulation forwarded by the primary SFF, it needs to remove the two layers of IPv6 encapsulation and generate the mapping relationship cache entries between the SID list and the virtual interface based on the SRH Segment list in the second layer of IPv6 header. * Masquerading SR Proxy After receiving an IPv6 packet from the main SFF, the backup masquerading SR proxy does not verify the consistency between DA and SRH SegmentList[SL], nor does it modify the SRH field (such as SL). There are three options for implementing the above functions: * Option 1: Add configuration on SR proxy. The SFC reliability protection methods proposed in this document only need to be processed locally on the SFF node, and can be configured on the SR proxy to distinguish whether the End.AS, End.AD, and End.AM SIDs on the backup SFF perform the above special processing. * Option 2: Define new behavior for SR proxy SIDs Define new behavior for SR proxy SIDs for backup, bypass, and direct forwarding, corresponding to the End.AS, End.AD, and End.AM SIDs in the primary SFF. When sending messages from the primary SFF to the backup SFF, use an SR proxy SID with backup or bypass behavior. * Option 3: Define new flavors for End.AS, End.AD, and End.AM SIDs to indicate that additional SFF reliability processing is required when DA is these SIDs. When sending messages from the primary SFF to the backup SFF, use an SR proxy SID with a backup or bypass flavor. Yang, et al. Expires April, 2024 [Page 17] Internet-Draft Reliability Framework for SFC October 2023 5. IANA Considerations 5.1. SRv6 Endpoint behavior This document requests the IANA to allocate, within the "SRv6 Endpoint Behaviors" sub-registry belonging to the top-level "Segment-routing with IPv6 dataplane (SRv6) Parameters" registry, the following allocations: Value Description Reference -------------------------------------------------------------- TBA1-1 End.ASBAK - Backup static proxy [This.ID] TBA1-2 End.ADBAK - Backup dynamic proxy [This.ID] TBA1-3 End.AMBAK - Backup masquerading proxy [This.ID] TBA1-4 End.ASBP - Bypass static proxy [This.ID] TBA1-5 End.ADBP - Bypass dynamic proxy [This.ID] TBA1-6 End.AMBP - Bypass masquerading proxy [This.ID] TBA1-7 End.ASDRT - Direct forwarding static proxy [This.ID] TBA1-8 End.ADDRT - Direct forwarding [This.ID] dynamic proxy TBA1-9 End.AMDRT - Direct forwarding [This.ID] masquerading proxy 5.2. SRv6 Endpoint Flavor This document requests IANA to allocate the following codepoints for PSD flavor behaviors within the "SRv6 Endpoint Behaviors" registry in the "Segment Routing registry group. +-------+--------+----------------------------+-----------+ | Value | Hex | Endpoint behavior | Reference | +-------+--------+----------------------------+-----------+ | TBA | TBA | End.AS with BAK | [This.ID] | | TBA | TBA | End.AD with BAK | [This.ID] | | TBA | TBA | End.AM with BAK | [This.ID] | | TBA | TBA | End.AS with BYPS | [This.ID] | | TBA | TBA | End.AD with BYPS | [This.ID] | | TBA | TBA | End.AM with BYPS | [This.ID] | | TBA | TBA | End.AS with DFWD | [This.ID] | | TBA | TBA | End.AD with DFWD | [This.ID] | | TBA | TBA | End.AM with DFWD | [This.ID] | +-------+--------+----------------------------+-----------+ 6. Security Considerations The security requirements and mechanisms described in [RFC8402], [RFC8754] and [RFC8986] also apply to this document. Yang, et al. Expires April, 2024 [Page 18] Internet-Draft Reliability Framework for SFC October 2023 This document does not introduce any new security vulnerabilities. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6(IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [I-D.ietf-spring-sr-service-programming] Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, Internet-Draft, draft-ietf-spring-sr-service-programming-08, 21 August 2023, . 7.2. Informative References TBD 8. Acknowledgments The authors would like to thank the following for their valuable contributions of this document: TBD Yang, et al. Expires April, 2024 [Page 19] Internet-Draft Reliability Framework for SFC October 2023 Authors' Addresses Feng Yang China Mobile Beijing China Email: yangfeng@chinamobile.com Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Yuanxiang Qiu New H3C Technologies Email: qiuyuanxiang@h3c.com Xiaoqiu Zhang China Mobile Beijing China Email: zhangxiaoqiu@chinamobile.com Yang, et al. Expires April, 2024 [Page 20]