]> Compressed SRv6 Segment List Encoding China Mobile
China chengweiqiang@chinamobile.com
Cisco Systems, Inc.
Belgium cf@cisco.com
Huawei Technologies
China lizhenbin@huawei.com
Orange
France bruno.decraene@orange.com
Cisco Systems, Inc.
France fclad.ietf@gmail.com
General SPRING Internet-Draft This document specifies new flavors for the Segment Routing (SR) segment endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists.
Introduction The Segment Routing (SR) architecture and SR for IPv6 (SRv6) are defined in . SRv6 Network Programming defines a framework to build a network program with topological and service segments (also referred to by their Segment Identifier (SID)) carried in a Segment Routing header (SRH) . The SPRING working group has observed that some use cases, such as strict path TE, may require long segment lists and that steering packets over such long segment lists using the SRv6 dataplane requires a large SRH. This document specifies new flavors to the SR segment endpoint behaviors defined in that enable a compressed encoding of the SRv6 segment list. The flavors defined in this document leverage the SRv6 data plane defined in and , and are compatible with the SRv6 control plane extensions for IS-IS , OSPF , and BGP .
Terminology This document leverages the terms defined in , , and . The reader is assumed to be familiar with this terminology. This document introduces the following new terms: Locator-Block: The most significant bits of a SID locator that represent the SRv6 SID block. The Locator-Block is referred to as "B" in Section 3.1 of . Locator-Node: The least significant bits of a SID locator that identify the SR segment endpoint node instantiating the SID. The Locator-Node is referred to as "N" in Section 3.1 of . Compressed-SID (C-SID): A compressed encoding of a SID. The C-SID includes the Locator-Node and Function bits of the SID being compressed. C-SID container: A 128-bit container holding a list of one or more C-SIDs. C-SID sequence: A group of one or more consecutive segment list entries carrying the common Locator-Block and at least one C-SID container. Uncompressed SID sequence: A group of one or more uncompressed SIDs in a segment list. Compressed segment list encoding: A segment list encoding that reduces the packet header length thanks to one or more C-SID sequences. A compressed segment list encoding may also contain any number of uncompressed SID sequences. In this document, the length of each constituent part of a SID is referred to as follows. LBL is the Locator-Block length of the SID. LNL is the Locator-Node length of the SID. FL is the Function length of the SID. AL is the Argument length of the SID. In addition, LNFL is the sum of the Locator-Node length and the Function length of the SID. It is also referred to as the C-SID length.
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 when, and only when, they appear in all capitals, as shown here.
Basic Concepts In an SR domain, all SRv6 SIDs instantiated from the same Locator-Block share the same most significant bits. In addition, when the combined length of the SRv6 SID Locator, Function, and Argument is smaller than 128 bits, the least significant bits of the SID are padded with zeros. The compressed segment list encoding decreases the packet header length by avoiding the repetition of the same Locator-Block and reducing the use of padding bits. The compressed segment list encoding is fully compatible with and builds upon the mechanisms specified in and . The compressed encoding is achieved by combining a compressed segment list encoding logic on the SR source node () with new flavors of the base SRv6 segment endpoint behaviors that decode this compressed encoding (). A segment list can be encoded in the packet header using any combination of compressed and uncompressed sequences. The C-SID sequences leverage the flavors defined in this document, while the uncompressed sequences use behaviors and flavors defined in other documents, such as . An SR source node constructs and compresses the SID-list depending on the capabilities of each SR segment endpoint node that the packet should traverse, as well as its own compression capabilities. The compressed segment list encoding works with any Locator-Block allocation. For example, each routing domain within the SR domain can be allocated a /48 Locator-Block from a global IPv6 block available to the operator, or from a prefix allocated to SRv6 SIDs as discussed in Section 5 of .
SR Segment Endpoint Flavors This section defines two SR segment endpoint flavors, NEXT-C-SID and REPLACE-C-SID, for the End, End.X, End.T, End.B6.Encaps, End.B6.Encaps.Red, and End.BM behaviors of . This section also defines a REPLACE-C-SID flavor for the End.DX6, End.DX4, End.DT6, End.DT4, End.DT46, End.DX2, End.DX2V, End.DT2U, and End.DT2M behaviors of . A counterpart NEXT-C-SID flavor is not defined for these SIDs because they can be included within a C-SID sequence that uses the NEXT-C-SID flavor without any modification of the procedure defined in . Future documents may extend the applicability of the NEXT-C-SID and REPLACE-C-SID flavors to other SR segment endpoint behaviors. The use of these flavors, either individually or in combination, enables the compressed segment list encoding. The NEXT-C-SID flavor and the REPLACE-C-SID flavor both leverage the SID Argument to determine the next segment to be processed, but employ different segment list compression schemes. With the NEXT-C-SID flavor, each C-SID container is a fully formed SRv6 SID with the common Locator-Block for all the C-SIDs in the C-SID container, a Locator-Node and Function that are those of the first C-SID, and an Argument carrying the subsequent C-SIDs. With the REPLACE-C-SID flavor, only the first element in a C-SID sequence is a fully formed SRv6 SID. It has the common Locator-Block for all the C-SIDs in the C-SID sequence, and a Locator-Node and Function that are those of the first C-SID. The remaining elements in the C-SID sequence are C-SID containers carrying the subsequent C-SIDs without the Locator-Block. The SIDs of both flavors can co-exist in the same SR domain, on the same SR segment endpoint node, and even in the same segment list. However, it is RECOMMENDED, for ease of operation, that a single compressed encoding flavor be used in a given routing domain. In a multi-domain deployment, different flavors MAY be used in different routing domains of the SR domain. In the remainder of this document, the term "a SID of this document" refers to any End, End.X, End.T, End.B6.Encaps, End.B6.Encaps.Red, or End.BM SID with the NEXT-C-SID or the REPLACE-C-SID flavor, and with any combination of PSP, USP, and USD flavor, or any End.DX6, End.DX4, End.DT6, End.DT4, End.DT46, End.DX2, End.DX2V, End.DT2U, or End.DT2M with the REPLACE-C-SID flavor. All the SIDs introduced in this document are listed in . In the remainder of this document, the terms "NEXT-C-SID flavor SID" and "REPLACE-C-SID flavor SID" refer to any SID of this document with the NEXT-C-SID flavor and with the REPLACE-C-SID flavor, respectively.
NEXT-C-SID Flavor A C-SID sequence using the NEXT-C-SID flavor comprises one or more C-SID containers. Each C-SID container is a fully formed 128-bit SID. It carries a Locator-Block followed by a series of C-SIDs. The Locator-Node and Function of the C-SID container are those of the first C-SID, and its Argument is the contiguous series of subsequent C-SIDs. The second C-SID is encoded in the most significant bits of the C-SID container Argument, the third C-SID is encoded in the bits of the Argument that immediately follow the second C-SID, and so on. When all C-SIDs have the same length, a C-SID container can carry up to K C-SIDs, where K is computed as floor((128-LBL)/LNFL). Each C-SID container for NEXT-C-SID is independent, such that contiguous C-SID containers in a C-SID sequence can be considered as separate C-SID sequences. The last C-SID in the C-SID sequence is not required to have the NEXT-C-SID flavor. It can be bound to any behavior and flavor(s), including the REPLACE-C-SID flavor, as long as it meets the conditions defined in . The structure of a SID with the NEXT-C-SID flavor is shown in . The same structure is also that of a C-SID container carrying NEXT-C-SID SIDs.
< LNFL > <------------- AL -------------> ]]>
An implementation SHOULD support a 32-bit Locator-Block length (LBL) and a 16-bit C-SID length (LNFL) for NEXT-C-SID flavor SIDs, and MAY support any other Locator-Block and C-SID length. A deployment SHOULD use a consistent Locator-Block length and C-SID length for all SIDs of the SR domain. The Argument length (AL) for NEXT-C-SID flavor SIDs is equal to 128-LBL-LNFL. When processing an IPv6 packet that matches a FIB entry locally instantiated as a SID with the NEXT-C-SID flavor, the SR segment endpoint node applies the procedure specified in the one following subsection that corresponds to the SID behavior. If the SID also has the PSP, USP, or USD flavor, the procedure is modified as described in . An SR segment endpoint node instantiating a SID with the NEXT-C-SID flavor MUST accept any Argument value for that SID. At high level, for any SID with the NEXT-C-SID flavor, the SR segment endpoint node determines the next SID of the SID list as follows. If the Argument value of the active SID is non-zero, the SR segment endpoint node constructs the next SID from the active SID by copying the entire SID Argument value to the bits that immediately follow the Locator-Block, thus overwriting the active SID Locator-Node and Function with those of the next C-SID, and filling the least significant LNFL bits of the Argument with zeros. If the Argument value is 0, the SR segment endpoint node instead copies the next 128-bit Segment List entry from the SRH to the Destination Address field of the IPv6 header.
End with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the NEXT-C-SID flavor, the procedure described in Section 4.1 of is executed with the following modifications. The below pseudocode is inserted between lines S01 and S02 of the SRH processing in Section 4.1 of . In addition, this pseudocode is executed before processing any extension header that is not an SRH, a Hop-by-Hop header or a Destination Option header, or before processing the upper-layer header, whichever comes first.
A rendering of the complete pseudocode is provided in .
End.X with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.X SID with the NEXT-C-SID flavor, the procedure described in Section 4.2 of is executed with the following modifications. The pseudocode in of this document is modified by replacing line N08 as shown below.
The resulting pseudocode is inserted between lines S01 and S02 of the SRH processing in Section 4.1 of after applying the modification described in Section 4.2 of . In addition, this pseudocode is executed before processing any extension header that is not an SRH, a Hop-by-Hop header or a Destination Option header, or before processing the upper-layer header, whichever comes first.
End.T with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.T SID with the NEXT-C-SID flavor, the procedure described in Section 4.3 of is executed with the following modifications. The pseudocode in of this document is modified by replacing line N08 as shown below.
The resulting pseudocode is inserted between lines S01 and S02 of the SRH processing in Section 4.1 of after applying the modification described in Section 4.3 of . In addition, this pseudocode is executed before processing any extension header that is not an SRH, a Hop-by-Hop header or a Destination Option header, or before processing the upper-layer header, whichever comes first.
End.B6.Encaps with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.B6.Encaps SID with the NEXT-C-SID flavor, the procedure described in Section 4.13 of is executed with the following modifications. The pseudocode in of this document is modified by replacing line N08 as shown below.
The resulting pseudocode is inserted between lines S01 and S02 of the SRH processing in Section 4.1 of after applying the modification described in Section 4.13 of . In addition, this pseudocode is executed before processing any extension header that is not an SRH, a Hop-by-Hop header or a Destination Option header, or before processing the upper-layer header, whichever comes first. Similar to the base End.B6.Encaps SID defined in Section 4.13 of , the NEXT-C-SID flavor variant updates the Destination Address field of the inner IPv6 header to the next SID in the original segment list before encapsulating the packet with the segment list of SR Policy B. At the endpoint of SR Policy B, the encapsulation is removed and the inner packet is forwarded towards the exposed destination address, which already contains the next SID in the original segment list.
End.B6.Encaps.Red with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.B6.Encaps.Red SID with the NEXT-C-SID flavor, the procedure described in Section 4.14 of is executed with the same modifications as in of this document.
End.BM with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.BM SID with the NEXT-C-SID flavor, the procedure described in Section 4.15 of is executed with the following modifications. The pseudocode in of this document is modified by replacing line N08 as shown below.
The resulting pseudocode is inserted between lines S01 and S02 of the SRH processing in Section 4.1 of after applying the modification described in Section 4.15 of . In addition, this pseudocode is executed before processing any extension header that is not an SRH, a Hop-by-Hop header or a Destination Option header, or before processing the upper-layer header, whichever comes first.
Combination with PSP, USP and USD flavors PSP: The PSP flavor defined in Section 4.16.1 of is unchanged when combined with the NEXT-C-SID flavor. USP: The USP flavor defined in Section 4.16.2 of is unchanged when combined with the NEXT-C-SID flavor. USD: The USP flavor defined in Section 4.16.3 of is unchanged when combined with the NEXT-C-SID flavor.
REPLACE-C-SID Flavor A C-SID sequence using the REPLACE-C-SID flavor starts with a C-SID container in fully formed 128-bit SID format. The Locator-Block of this SID is the common Locator-Block for all the C-SIDs in the C-SID sequence, its Locator-Node and Function are those of the first C-SID, and its Argument carries the index of the current C-SID in the current C-SID container. The Argument value is initially 0. When more segments are present in the segment list, the C-SID sequence continues with one or more C-SID containers in packed format carrying the subsequent C-SIDs in the sequence. Each container in packed format is a 128-bit Segment List entry split into K "positions" of LNFL bits, where K is computed as floor(128/LNFL). If LNFL does not divide into 128 perfectly, a zero pad is added in the least significant bits of the C-SID container to fill the bits left over. The second C-SID in the C-SID sequence is encoded in the least significant bit position of the first C-SID container in packed format (position K-1), the third C-SID is encoded in position K-2, and so on. The last C-SID in the C-SID sequence is not required to have the REPLACE-C-SID flavor. It can be bound to any behavior and flavor(s), including the NEXT-C-SID flavor, as long as it meets the conditions defined in . The structure of a SID with the REPLACE-C-SID flavor is shown in . The same structure is also that of the C-SID container for REPLACE-C-SID in fully formed 128-bit SID format.
<---- LNFL ----> <--------- AL ----------> ]]>
The structure of a C-SID container for REPLACE-C-SID in packed format is shown in .
<---- LNFL ----> <---- LNFL ----> <---- LNFL ----> ]]>
The RECOMMENDED Locator-Block lengths (LBL) for REPLACE-C-SID flavor SIDs are 48, 56, 64, 72, or 80 bits, depending on the needs of the operator. The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths (LNFL). A C-SID length of 32-bit is RECOMMENDED. Any other Locator-Block and C-SID length selection is possible, but may lead to suboptimal C-SID encoding in the C-SID containers (e.g., presence of padding bits). The Argument length (AL) for REPLACE-C-SID flavor SIDs is equal to 128-LBL-LNFL. The index value is encoded in the least significant X bits of the Argument, where X is computed as ceil(log_2(128/LNFL)). When processing an IPv6 packet that matches a FIB entry locally instantiated as a SID with the REPLACE-C-SID flavor, the SR segment endpoint node applies the procedure specified in the one following subsection that corresponds to the SID behavior. If the SID also has the PSP, USP, or USD flavor, the procedure is modified as described in . At high level, at the start of a C-SID sequence using the REPLACE-C-SID flavor, the first C-SID container in fully formed 128-bit SID format is copied to the Destination Address of the IPv6 header. Then, for any SID with the REPLACE-C-SID flavor, the SR segment endpoint node determines the next SID of the SID list as follows. When an SRH is present, the SR segment endpoint node decrements the index value in the Argument of the active SID if the index value is not 0 or, if it is 0, decrements the Segments Left value in the SRH and sets the index value in the Argument of the active SID to K-1. The updated index value indicates the position of the next C-SID within the C-SID container in packed format at the "Segment List" index "Segments Left" in the SRH. The SR segment endpoint node then constructs the next SID by copying this next C-SID to the bits that immediately follow the Locator-Block in the Destination Address field of the IPv6 header, thus overwriting the active SID Locator-Node and Function with those of the next C-SID. If no SRH is present, the SR segment endpoint node ignores the index value in the SID Argument (except End.DT2M, see ) and processes the upper-layer header as per . The C-SID sequence ends with a last C-SID in the last C-SID container that does not have the REPLACE-C-SID flavor, or with the special C-SID value 0, or when reaching the end of the segment list, whichever comes first.
End with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the REPLACE-C-SID flavor, the SRH processing described in Section 4.1 of is executed with the following modifications. Line S02 of SRH processing in Section 4.1 of is replaced as follows.
Lines S09 to S15 are replaced by the following pseudo code.
max_LE) or (Segments Left > Last Entry)) { R03. Send an ICMP Parameter Problem to the Source Address, Code 0 (Erroneous header field encountered), Pointer set to the Segments Left field, interrupt packet processing and discard the packet. R04. } R05. Decrement DA.Arg.Index by 1. R06. If (Segment List[Segments Left][DA.Arg.Index] == 0) { R07. Decrement Segments Left by 1. R08. Decrement IPv6 Hop Limit by 1. R09. Update IPv6 DA with Segment List[Segments Left] R10. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination. R11. } R12. } Else { R13. If((Last Entry > max_LE) or (Segments Left > Last Entry+1)){ R14. Send an ICMP Parameter Problem to the Source Address, Code 0 (Erroneous header field encountered), Pointer set to the Segments Left field, interrupt packet processing and discard the packet. R15. } R16. Decrement Segments Left by 1. R17. Set DA.Arg.Index to (floor(128/LNFL) - 1). R18. } R19. Decrement IPv6 Hop Limit by 1. R20. Write Segment List[Segments Left][DA.Arg.Index] into the bits [LBL..LBL+LNFL-1] of the Destination Address of the IPv6 header. R21. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination. ]]>
The upper-layer header processing described in Section 4.1.1 of is unchanged. A rendering of the complete pseudocode is provided in .
End.X with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.X SID with the REPLACE-C-SID flavor, the procedure described in Section 4.2 of is executed with the following modifications. The pseudocode in of this document is modified by replacing line R10 and R21 as shown below.
The SRH processing in Section 4.2 of is replaced with the resulting pseudocode. The upper-layer header processing is unchanged.
End.T with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.T SID with the REPLACE-C-SID flavor, the procedure described in Section 4.3 of is executed with the following modifications. The pseudocode in of this document is modified by replacing line R10 and R21 as shown below.
The SRH processing in Section 4.3 of is replaced with the resulting pseudocode. The upper-layer header processing is unchanged.
End.B6.Encaps with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.B6.Encaps SID with the REPLACE-C-SID flavor, the procedure described in Section 4.13 of is executed with the following modifications. The pseudocode in of this document is modified by replacing line R10 and R21 as shown below.
The SRH processing in Section 4.13 of is replaced with the resulting pseudocode. The upper-layer header processing is unchanged.
End.B6.Encaps.Red with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.B6.Encaps.Red SID with the REPLACE-C-SID flavor, the procedure described in Section 4.14 of is executed with the same modifications as in of this document.
End.BM with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.BM SID with the REPLACE-C-SID flavor, the procedure described in Section 4.15 of is executed with the following modifications. The pseudocode in of this document is modified by replacing line R10 and R21 as shown below.
The SRH processing in Section 4.15 of is replaced with the resulting pseudocode. The upper-layer header processing is unchanged.
End.DX and End.DT with REPLACE-C-SID New behaviors of End.DX6, End.DX4, End.DT6, End.DT4, End.DT46, End.DX2, End.DX2V, End.DT2U, or End.DT2M with REPLACE-C-SID flavor are also defined in this draft. These new behaviors can be used to indicate the capability of compression of Node and SID, which are required in path computation and compressed SID list encoding. When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.DX6, End.DX4, End.DT6, End.DT4, End.DT46, End.DX2, End.DX2V, End.DT2U or End.DT2M SID with the REPLACE-C-SID flavor, the procedures described in are executed. For End.DT2M with REPLACE-C-SID flavor, when it is used as an uncompressed 128-bit SID, the Arg.FE2 is a 16-bit value located in the significant bits of the Argument. When it is used as a C-SID, the Arg.FE2 of the SID is carried in the end of the C-SID sequence. For 16-bit compression, Arg.FE2 is carried in the last 16-bits of the C-SID sequence. For 32-bit compression, Arg.FE2 is carried in the least significant 16 bits of the last 32-bits of the C-SID sequence. When the END.DT2M C-SID and its Argument cannot be included in the last container, the SID MUST NOT be compressed and MUST be encoded as a 128-bit uncompressed END.DT2M SID. When processing an IPv6 packet that matches a FIB entry locally instantiated as an END.DT2M with REPLACE-C-SID flavor, the node can obtain the Arg.FE2 from the DA.Argument if DA.Arg.Index is zero, or from the container if DA.Arg.Index is non zero.
Combination with PSP, USP, and USD flavors PSP: When combined with the REPLACE-C-SID flavor, the additional PSP flavor instructions defined in Section 4.16.1.2 of are inserted after line R09 and R20 of the pseudocode in , and the first line of the inserted instructions after R20 is modified as follows.
USP: When combined with the REPLACE-C-SID flavor, the line S03 of the pseudocode in are substituted by the USP flavor instructions S03.1 to S03.4 defined in Section 4.16.2 of . Note that S03 is shown in the complete pseudocode in . USD: The USD flavor defined in Section 4.16.3 of is unchanged when combined with the REPLACE-C-SID flavor.
C-SID Allocation The C-SID value of 0 is RESERVED. It is used to indicate the end of a C-SID container. In order to efficiently manage the C-SID numbering space, it may be beneficial to divide it into two non-overlapping sub-spaces: a Global Identifiers Block (GIB) and a Local Identifiers Block (LIB). The GIB is the pool of C-SID values available for global allocation. The LIB is the pool of C-SID values available for local allocation. C-SID values that are allocated from the GIB have a global semantic within the Locator-Block, while those that are allocated from the LIB have a local semantic on an SR segment endpoint node and within the scope of the Locator-Block. The concept of LIB is applicable to SRv6 and specifically to its NEXT-C-SID and REPLACE-C-SID flavors. The shorter the C-SID, the more benefit the LIB brings. The opportunity to use these sub-spaces, their size, and their C-SID allocation policy depends on the C-SID length relative to the size of the network (e.g., number of nodes, links, service routes). Some guidelines for a typical deployment scenario are provided in the below subsections.
Global C-SID A global C-SID is a C-SID allocated from the GIB. A global C-SID identifies a segment defined at the Locator-Block level. The tuple (Locator-Block, C-SID) identifies the same segment across all nodes of the SR domain. A typical example is a prefix segment bound to the End behavior. A node can have multiple global C-SIDs under the same Locator-Block (e.g., one per IGP flexible algorithm ()). Multiple nodes may share the same global C-SID (e.g., anycast).
Local C-SID A local C-SID is a C-SID allocated from the LIB. A local C-SID identifies a segment defined at the node level and within the scope of a particular Locator-Block. The tuple (Locator-Block, C-SID) identifies a different segment on each node of the SR domain. A typical example is a non-routed Adjacency segment bound to the End.X behavior. Let N1 and N2 be two different physical nodes of the SR domain and I a local C-SID value, N1 may allocate value I to SID S1 and N2 may allocate the same value I to SID S2.
GIB/LIB Usage GIB and LIB usage is a local implementation and/or configuration decision, however, some guidelines for determining usage for specific SID behaviors and recommendations are provided. The GIB number space is shared among all segment endpoint nodes using SRv6 locators under a Block space. The more SIDs assigned from this space, per node, the faster it is exhausted. Therefore its use is prioritized for global segments, such as SIDs that identify a node. The LIB number space is unique per node. Each node is able to fully utilize the entire LIB number space without consideration of assignments at other nodes. Therefore its use is prioritized for local segments, such as SIDs that identify services (of which there may be many) at nodes, cross-connects, or adjacencies. While a longer C-SID length permits more flexibility in which SID behaviors may be assigned from the GIB, it also reduces the compression efficiency. Given the previous Locator-Block and C-SID length recommendations, the following GIB/LIB usage is RECOMMENDED: NEXT-C-SID: GIB: End LIB: End.X, End.T, End.DT4/6/46/2U/2M, End.DX4/6/2/2V (including large-scale pseudowire), End.B6.Encaps, End.B6.Encaps.Red, End.BM REPLACE-C-SID: GIB: End, End.X, End.T, End.DT4/6/46/2U/2M, End.DX4/6/2/2V, End.B6.Encaps, End.B6.Encaps.Red, End.BM LIB: End.DX2/2V for large-scale pseudowire Any other allocation is possible but may lead to a suboptimal use of the C-SID numbering space.
Recommended Installation of C-SIDs in FIB An SR segment endpoint node instantiating a NEXT-C-SID or REPLACE-C-SID flavor SID SHOULD install the corresponding FIB entry to match only the Locator and Function parts of the SID (i.e., with a prefix length of LBL + LNL + FL). Any other mean of identifying a locally instantiated SID is possible as long as it is compliant with Section 4.3 of and accepts all valid Argument values for the SID. In addition, an SR segment endpoint node instantiating NEXT-C-SID flavor SIDs from both GIB and LIB MAY install combined "Global + Local" FIB entries to match a sequence of global and local C-SIDs in a single LPM lookup. For example, let us consider an SR segment endpoint node 10 instantiating the following two NEXT-C-SID flavor SIDs according to the C-SID length, Locator-Block length, and GIB/LIB recommendations in this section. 2001:db8:b1:10:: bound to the End behavior with the NEXT-C-SID flavor is instantiated from GIB with Locator-Block length (LBL) = 48 (Locator-Block value 0x20010db800b1), Locator-Node length (LNL) = 16 (Locator-Node value 0x0010), Function length (FL) = 0, and Argument length (AL) = 64. 2001:db8:b1:f123:: bound to the End.X behavior for its local IGP adjacency 123 with the NEXT-C-SID flavor is instantiated from LIB with Locator-Block length (LBL) = 48 (Locator-Block value 0x20010db800b1), Locator-Node length (LNL) = 0, Function length (FL) = 16 (Function value 0xf123), and Argument length (AL) = 64. For SID 2001:db8:b1:10::, Node 10 would install the FIB entry 2001:db8:b1:10::/64 bound the End SID with the NEXT-C-SID flavor. For SID 2001:db8:b1:f123::, Node 10 would install the FIB entry 2001:db8:b1:f123::/64 bound the End.X SID for adjacency 123 with the NEXT-C-SID flavor. In addition, Node 10 may also install the combined FIB entry 2001:db8:b1:10:f123::/80 bound the End.X SID for adjacency 123 with the NEXT-C-SID flavor. As another example, let us consider an SR segment endpoint node 20 instantiating the following two REPLACE-C-SID flavor SIDs according to the C-SID length, Locator-Block length, and GIB/LIB recommendations in this section. 2001:db8:b2:20:1:: from GIB with Locator-Block length (LBL) = 48, Locator-Node length (LNL) = 16, Function length (FL) = 16, Argument length (AL) = 48, and bound to the End behavior with the REPLACE-C-SID flavor. 2001:db8:b2:20:123:: from GIB with Locator-Block length (LBL) = 48, Locator-Node length (LNL) = 16, Function length (FL) = 16, Argument length (AL) = 48, and bound to the End.X behavior for its local IGP adjacency 123 with the REPLACE-C-SID flavor. For SID 2001:db8:b2:20:1::, Node 20 would install the FIB entry 2001:db8:b2:20:1::/80 bound the End SID with the REPLACE-C-SID flavor. For SID 2001:db8:b2:20:123::, Node 20 would install the FIB entry 2001:db8:b2:20:123::/80 bound the End.X SID for adjacency 123 with the REPLACE-C-SID flavor.
SR Source Node
Segment Validation An SR source node MUST validate all SIDs defined in this document that it uses as part of a segment list, regardless of whether the segment list is explicitly configured, locally computed, or advertised by a controller (e.g., via BGP or PCEP ). A SID of this document is valid if it is associated with a valid SID structure. The structure of a SID is valid if all the following conditions are met. The Locator-Block length is not 0. The sum of the Locator-Node length and Function length is not 0. The Argument length is equal to 128-LBL-LNL-FL. An SR source node MUST NOT include an invalid SID in a segment list. If an explicitly configured or advertised segment list (e.g., from a controller) contains an invalid SID, the segment list MUST be declared invalid (). discusses how the SIDs of this document and their structure can be advertised to the SR source node through various control plane protocols.
Segment List Compression An SR source node MAY compress a segment list when it includes NEXT-C-SID and/or REPLACE-C-SID flavor SIDs in order to reduce the packet header length. The segment list that the SR source node pushes onto the packet MUST comply with the rules in and and result in a path equivalent to the original segment list. If an SR source node chooses to compress the segment list, one method is described below for illustrative purposes. Any other method producing a compressed segment list of equal or shorter length than the uncompressed segment list is compliant. This method walks the uncompressed segment list and compresses each series of consecutive NEXT-C-SID flavor SIDs and each series of consecutive REPLACE-C-SID flavor SIDs. When the compression method encounters a series of one or more consecutive compressible NEXT-C-SID flavor SIDs, it compresses the series as follows. A SID with the NEXT-C-SID flavor is compressible if its structure is known to the SR source node and its Argument value is 0.
When the compression method encounters a series of REPLACE-C-SID flavor SIDs of the same C-SID length in the uncompressed segment list, it compresses the series as per the following high-level pseudo code. A compression checking function ComCheck(F, S) is defined to check if two SIDs F and S share the same SID structure and Locator-Block value, and if S has either no Argument or an Argument with value 0. If the check passes, then ComCheck(F,S) returns true.
In all remaining cases (i.e., when the compression method encounters a SID in the uncompressed segment list that is not handled by any of the previous subroutines), it pushes this SID as is onto the compressed segment list. Regardless of how a compressed segment list is produced, it is encoded in the IPv6 header and optional SRH as described in Section 4.1 and 4.1.1 of . The text is reproduced below for reference.
A source node steers a packet into an SR Policy. If the SR Policy results in a Segment List containing a single segment, and there is no need to add information to the SRH flag or add TLV; the DA is set to the single Segment List entry, and the SRH MAY be omitted. When needed, the SRH is created as follows: The Next Header and Hdr Ext Len fields are set as specified in [RFC8200]. The Routing Type field is set to 4. The DA of the packet is set with the value of the first segment. The first element of the SRH Segment List is the ultimate segment. The second element is the penultimate segment, and so on. The Segments Left field is set to n-1, where n is the number of elements in the SR Policy. The Last Entry field is set to n-1, where n is the number of elements in the SR Policy. TLVs (including HMAC) may be set according to their specification. The packet is forwarded toward the packet's Destination Address (the first segment). When a source does not require the entire SID list to be preserved in the SRH, a reduced SRH may be used. A reduced SRH does not contain the first segment of the related SR Policy (the first segment is the one already in the DA of the IPv6 header), and the Last Entry field is set to n-2, where n is the number of elements in the SR Policy.
Rules for segment lists containing NEXT-C-SID flavor SIDs If a Destination Option header would follow an SRH with a segment list of more than one segment compressed as a single NEXT-C-SID container, the SR source node MUST NOT omit the SRH. When the last Segment List entry (index 0) in the SRH is a C-SID container representing more than one segment, the PSP operation is performed at the segment preceding the first segment of this C-SID container in the segment list. If the PSP behavior should instead be performed at the penultimate segment along the path, the SR source node MUST NOT compress the ultimate segment of the segment list into a C-SID container. If a Destination Option header would follow an SRH with a last Segment List entry being a NEXT-C-SID container representing more than one segment, the SR source node MUST ensure that the PSP operation is not performed before the penultimate SR segment endpoint node along the path.
Rules for segment lists containing REPLACE-C-SID flavor SIDs All SIDs compressed in a REPLACE-C-SID sequence MUST share the same Locator-Block and the same compression scheme. All SIDs except the last one in a C-SID sequence for REPLACE-C-SID MUST have the REPLACE-C-SID flavor. If the last C-SID container is fully filled (i.e., the last C-SID is at position 0 in the C-SID container) and the last SID in the C-SID sequence is not the last segment in the segment list, the last SID in the C-SID sequence MUST NOT have the REPLACE-C-SID flavor. When a REPLACE-C-SID flavor C-SID is present as the last SID in a container that is not the last Segment List entry (index 0) in the SRH, the next element in the segment list MUST be a REPLACE-C-SID container in packed format carrying at least one C-SID. The SR source node determines the compression scheme of REPLACE-C-SID flavor SIDs as follows. When receiving a SID advertisement for a REPLACE-C-SID flavor SID with LNL=16, FL=0, AL=128-LBL-NL-FL, and the value of the Argument is all 0, the SR source node marks both the SID and its locator as using 16-bit compression. All other SIDs allocated from this locator with LNL=16, FL=16, AL=128-LBL-NL-FL, and the value of the Argument is all 0 are also marked as using 16-bit compression. When receiving a SID advertisement for a REPLACE-C-SID flavor SID with LNFL=32, AL=128-LBL-NL-FL, and the value of the Argument is all 0, the SR source node marks both the SID and its locator as using 32-bit compression.
Inter Routing Domains with the End.XPS behavior The End.XPS behavior described in this section is OPTIONAL. Some SRv6 traffic may need to cross multiple routing domains, such as different Autonomous Systems (ASes) or different routing areas within an SR domain. Different routing domains may use different addressing schema and Locator-Blocks. This section defines an optional solution and SID behavior allowing for the use of different Locator-Blocks between routing domains. The solution requires a new SID behavior, called "Endpoint with cross-connect to an array of layer-3 adjacencies and SRv6 Prefix Swap" (End.XPS for short) allowing for this transition of Locator-Block between two routing domains. End.XPS is a variant of End.X, performing both "End.X Layer-3 Cross-Connect" and the translation of the Locator-Block between the two routing domains. The processing takes as an additional parameter the prefix B2/m corresponding to the Locator-Block in the second domain. This parameter is a property of the (received) SID and is given as a result of the lookup on the IPv6 destination address which identifies the SRv6 SID and its properties. The End.XPS behavior is compatible with the NEXT-C-SID and REPLACE-C-SID flavors described in this document. When a router R receives a packet whose IPv6 DA matches a local End.XPS SID with the NEXT-C-SID flavor, that is associated with a set J of one or more Layer-3 adjacencies and the Locator-Block B2/m of the neighbor routing domain, R processes the packet as follows.
When a router R receives a packet whose IPv6 DA matches a local End.XPS SID with the REPLACE-C-SID flavor, that is associated with a set J of one or more Layer-3 adjacencies and the Locator-Block B2/m of the neighbor routing domain, R processes the packet as follows.
Control Plane This document does not require any new extensions to routing protocols. Section 8 of provides an overview of the control plane protocols used for signaling of the SRv6 SIDs introduced by that document. The SRv6 SIDs introduced by this document are advertised using the same SRv6 extensions for various routing protocols, such as IS-IS OSPFv3 BGP , , , PCEP The SR segment endpoint node MUST set the SID Argument bits to 0 when advertising a locally instantiated SID of this document in the routing protocol (e.g., IS-IS , OSPF , or BGP-LS ). Signaling the SRv6 SID Structure is REQUIRED for all the SIDs introduced in this document. It is used by an SR source node to compress a segment list as described in . The node initiating the SID advertisement MUST set the length values in the SRv6 SID Structure to match the format of the SID on the SR segment endpoint node. For example, for a SID of this document instantiated from a /48 SRv6 SID block and a /64 Locator, and having a 16-bit Function, the SRv6 SID Structure advertisement carries the following values. Locator-Block length: 48 Locator-Node length: 16 Function length: 16 Argument length: 48 (= 128-48-16-16) A local C-SID MAY be advertised in the control plane individually and/or in combination with a global C-SID instantiated on the same SR segment endpoint node, with the End behavior, and the same Locator-Block and flavor as the local C-SID. A combined global and local C-SID is advertised as follows. The SID Locator-Block is that shared by the global and local C-SIDs The SID Locator-Node is that of global C-SID The SID Function is that of the local C-SID The SID Argument length is equal to 128-LBL-LNL-FL and the SID Argument value is 0 All other attributes of the SID (e.g., endpoint behavior or algorithm) are those of the local C-SID The local C-SID combined advertisement is needed in particular for control plane protocols mandating that the SID is a subnet of a locator advertised in the same protocol (e.g., Sec. 8 of and Sec. 9 of for advertising Adjacency SIDs in IS-IS and OSPFv3, respectively). For a segment list computed by a controller and signaled to an SR source node (e.g., via BGP or PCEP ), the controller provides the ordered segment list comprising the uncompressed SIDs, with their respective behavior and structure, to the SR source node. The SR source node may then compress the segment list as described in .
Operational Considerations
Pinging a SID An SR source node may ping an SRv6 SID by sending an ICMPv6 echo request packet destined to the SRv6 SID, with or without a segment list, as illustrated in Appendix A.1.2 of . When pinging a SID of this document without a segment list, the SR source node places the SID in the destination address of the ICMPv6 echo request and MUST set the Argument of the SID to 0. The Argument value 0 allows the SID SR segment endpoint node () to identify itself as the ultimate destination of the packet and process the ICMPv6 payload. If the SR source node sets a non-zero Argument value, the SR segment endpoint node would instead attempt to determine the next destination of the packet. When pinging a SID of this document via a segment list, the SR source node MUST construct the IPv6 packet as described in and compute the ICMPv6 checksum using the IPv6 destination address as it is expected to appear at the ultimate destination of the packet.
ICMP Error Processing When an IPv6 node encounters an error while processing a packet, it may report that error by sending an IPv6 error message to the packet source with an enclosed copy of the invoking packet. For the source of an invoking packet to process the ICMP error message, the ultimate destination address of the IPv6 header may be required. Section 5.4 of defines the logic that an SR source node follows to determine the ultimate destination of an invoking packet containing an SRH. For an SR source node that supports the compressed segment list encoding defined in this document, the logic to determine the ultimate destination is generalized as follows. If the destination address of the invoking IPv6 packet matches a known SRv6 SID, modify the invoking IPv6 packet by applying the SID behavior associated with the matched SRv6 SID; Repeat until the application of the SID behavior would result in the processing of the upper-layer header. The destination address of the resulting IPv6 packet may be used as the ultimate destination of the invoking IPv6 packet. Since the SR source node that needs to determine the ultimate destination is the same node that originally built the segment list in the invoking packet, it is able to perform this operation for all the SIDs in the packet.
Illustrations Illustrations for the functionalities defined in this document are provided in .
Deployment Model Section 5 of defines the intra-SR-domain deployment model and associated security procedures. The same deployment model applies to the SIDs defined in this document.
Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". This section is provided in compliance with the SPRING working group policies ().
Cisco Systems Cisco Systems reported the following implementations of the SR segment endpoint node NEXT-C-SID flavor () and the SR source node efficient SID-list encoding () for NEXT-C-SID flavor SIDs. These are used as part of its SRv6 TI-LFA, micro-loop avoidance, and traffic engineering functionalities. Cisco NCS 540 Series routers running IOS XR 7.3.x or above Cisco NCS 560 Series routers running IOS XR 7.6.x or above Cisco NCS 5500 Series routers running IOS XR 7.3.x or above Cisco NCS 5700 Series routers running IOS XR 7.5.x or above Cisco 8000 Series routers running IOS XR 7.5.x or above Cisco ASR 9000 Series routers running IOS XR 7.5.x or above At the time of this report, all the implementations listed above are in production and follow the specification in the latest version of this document, including all the "MUST" and "SHOULD" clauses for the NEXT-C-SID flavor. This report was last updated on January 11, 2023.
Huawei Technologies Huawei Technologies reported the following implementations of the SR segment endpoint node REPLACE-C-SID flavor (). These are used as part of its SRv6 TI-LFA, micro-loop avoidance, and traffic engineering functionalities. Huawei ATN8XX,ATN910C,ATN980B routers running VRPV800R021C00 or above. Huawei CX600-M2 routers running VRPV800R021C00 or above. Huawei NE40E,ME60-X1X2,ME60-X3X8X16 routers running VRPV800R021C00 or above. Huawei NE5000E,NE9000 routers running VRPV800R021C00 or above. Huawei NCE-IP Controller running V1R21C00 or above. At the time of this report, all the implementations listed above are in production and follow the specification in the latest version of this document, including all the "MUST" and "SHOULD" clauses for the REPLACE-C-SID flavor. This report was last updated on January 11, 2023.
Nokia Nokia reported the following implementations () of the SR segment endpoint node NEXT-C-SID flavor (). These are used as part of its shortest path forwarding (in algorithm 0 and Flex-Algo), remote and TI-LFA repair tunnel, and Traffic Engineering functionalities. Nokia 7950 XRS 20/20e routers running SROS Release 22.10 or above Nokia 7750 SR-12e routers running SROS Release 22.10 or above Nokia 7750 SR-7/12 routers running SROS Release 22.10 or above Nokia 7750 SR-7s/14s routers running SROS Release 22.10 or above Nokia 7750 SR-1/1s/2s routers running SROS Release 22.10 or above At the time of this report, all the implementations listed above are in production and follow the specification in the latest version of this document, including all the "MUST" and "SHOULD" clauses for the NEXT-C-SID flavor. This report was last updated on February 3, 2023.
Arrcus Arrcus reported the following implementations of the SR segment endpoint node NEXT-C-SID flavor (). These are used as part of its SRv6 shortest path forwarding (in algorithm 0 and Flex-Algo), TI-LFA, micro-loop avoidance and Traffic Engineering functionalities. Arrcus running on Ufi Space routers S9510-28DC, S9710-76D, S9600-30DX and S9700-23D with ArcOS v5.2.1 or above Arrcus running n Ufi Space routers S9600-72XC and S9700-53DX with ArcOS v5.1.1D or above Arrcus running on Quanta router IXA and IXAE with ArcOS v5.1.1D or above At the time of this report, all the implementations listed above are in production and follow the specification in the latest version of this document, including all the "MUST" and "SHOULD" clauses for the NEXT-C-SID flavor. This report was last updated on March 11, 2023.
Juniper Networks Juniper Networks reported the following implementations of the SR segment endpoint node NEXT-C-SID flavor (). These are used as part of its SRv6 shortest path forwarding (in algorithm 0 and Flex-Algo), TI-LFA, micro-loop avoidance, and Traffic Engineering functionalities. Juniper release 23.3 onwards supports this functionality. At the time of this report, all the implementations listed above are in development and follow the specification in the latest version of this document, including all the "MUST" and "SHOULD" clauses for the NEXT-C-SID flavor. This report was last updated on May 30, 2023.
Marvell Marvell reported support in the Marvell Prestera Packet Processor for the SR segment endpoint node NEXT-C-SID flavor () and REPLACE-C-SID flavor (). This report was last updated on February 15, 2023.
Broadcom Broadcom reported the following implementations of the SR segment endpoint node NEXT-C-SID flavor () and REPLACE-C-SID flavor (). These are used as part of its SRv6 TI-LFA, micro-loop avoidance, and traffic engineering functionalities. All implementation of the following list is in general availability for customers using BCM SDK 6.5.26 or above. 88850 (Jericho2c+) series 88690 (Jericho2) series 88800 (Jericho2c) series 88480 (Qunran2a) series 88280 (Qunran2u) series 88295 (Qunran2n) series 88830 (Jericho2x) series At the time of this report, all the implementations listed above are in production and follow the specification in the latest version of this document, including all the "MUST" and "SHOULD" clauses for the NEXT-C-SID and REPLACE-C-SID flavors. For 78900 (Tomahawk) series-related support, please contact the Broadcom team. This report was last updated on February 21, 2023.
ZTE Corporation ZTE Corporation reported the following implementations of the SR segment endpoint node REPLACE-C-SID flavor (). These are used as part of its SRv6 TI-LFA, micro-loop avoidance, and traffic engineering functionalities. ZTE M6000-18S(BRAS), M6000-8S Plus(BRAS) routers running V5.00.10.09 or above. ZTE M6000-18S(SR), M6000-8S Plus(SR) routers running V5.00.10.80 or above. ZTE T8000-18 routers running V5.00.10.07 or above. This report was last updated on March 29, 2023.
New H3C Technologies New H3C Technologies reported the following implementations of the SR segment endpoint node REPLACE-C-SID flavor (). These are used as part of its SRv6 TI-LFA, micro-loop avoidance, and traffic engineering functionalities. H3C CR16000-F, SR8800-X routers running Version 7.1.075 or above. H3C CR18000, CR19000 routers running Version 7.1.071 or above. This report was last updated on March 29, 2023.
Ruijie Network Ruijie Network reported the following implementations of the SR segment endpoint node REPLACE-C-SID flavor (). These are used as part of its SRv6 TI-LFA, micro-loop avoidance, and traffic engineering functionalities. RUIJIE RG-N8018-R, RG-N8010-R routers running N8000-R_RGOS 12.8(3)B0801 or above. This report was last updated on March 29, 2023.
Open Source The authors found the following open source implementations of the SR segment endpoint node NEXT-C-SID flavor (). The Linux kernel, version 6.1 The Software for Open Networking in the Cloud (SONiC), version 202212 , and Switch Abstraction Interface (SAI), version 1.9.0 The Vector Packet Processor (VPP), version 20.05 A generic P4 implementation The authors found the following open source implementations of the SR segment endpoint node REPLACE-C-SID flavor (). ONOS and P4 Programmable Switch based Open SRv6 Project This section was last updated on January 11, 2023.
Interoperability Reports
Bell Canada / Ciena 2023 Bell Canada is currently evaluating interoperability between Ciena and Cisco implementations of the NEXT-C-SID flavor defined in this document. Further information will be added to this section when the evaluation is complete.
EANTC 2023 In April 2023, the European Advanced Networking Test Center (EANTC) successfully validated multiple implementations of SRv6 NEXT-C-SID flavor (a.k.a., SRv6 uSID) . The participating vendors included Arista, Arrcus, Cisco, Huawei, Juniper, Keysight, Nokia, and Spirent.
China Mobile 2020 In November 2020, China Mobile successfully validated multiple interoperable implementations of the NEXT-C-SID and REPLACE-C-SID flavors defined in this document. This testing covered two different implementations of the SRv6 endpoint flavors defined in this document: Hardware implementation in Cisco ASR 9000 running IOS XR Software implementation in Cisco IOS XRv9000 virtual appliance Hardware implementation in Huawei NE40E and NE5000E running VRP The interoperability testing consisted of a packet flow sent by an SR source node N0 via an SR traffic engineering policy with a segment list <S1, S2, S3, S4, S5, S6, S7>, where S1..S7 are SIDs instantiated on SR segment endpoint nodes N1..N7, respectively.
N0 is a generic packet generator. N1, N2, and N3 are Huawei routers. N4, N5, and N6 are Cisco routers. N7 is a generic traffic generator acting as a packet receiver. The SR source node N0 steers the packets onto the SR policy by setting the IPv6 destination address and creating an SRH (as described in Section 4.1 of ) using a compressed segment list encoding. The length of the compressed segment list encoding varies for each scenario. All SR segment endpoint nodes execute a variant of the End behavior: regular End behavior (as defined in Section 4.1 of ), End behavior with NEXT-C-SID flavor, and End behavior with REPLACE-C-SID flavor. The variant being used at each segment endpoint varies for each scenario. The interoperability was validated for the following scenarios: Scenario 1: S1 and S2 are associated with the End behavior with the REPLACE-C-SID flavor S3 is associated with the regular End behavior (no flavor) S4, S5, and S6 are associated with the End behavior with the NEXT-C-SID flavor The SR source node imposes a compressed segment list encoding of 3 SIDs. Scenario 2: S1, S2..., S6 are associated with the End behavior with the NEXT-C-SID flavor The SR source node imposes a compressed segment list encoding of 2 SIDs. Scenario 3: S1, S2..., S6 are associated with the End behavior with the REPLACE-C-SID flavor The SR source node imposes a compressed segment list encoding of 3 SIDs.
Security Considerations The security requirements and mechanisms described in and also apply to this document. This document does not introduce any new security considerations.
IANA Considerations
SRv6 Endpoint Behaviors This I-D. requests the IANA to update the reference of the following registrations from the "SRv6 Endpoint Behaviors" registry under the top-level "Segment Routing" registry-group (https://www.iana.org/assignments/segment-routing/) with the RFC number of this document once it is published, and transfer change control to the IETF. Value Description Reference 43 End with NEXT-CSID This I-D. 44 End with NEXT-CSID & PSP This I-D. 45 End with NEXT-CSID & USP This I-D. 46 End with NEXT-CSID, PSP & USP This I-D. 47 End with NEXT-CSID & USD This I-D. 48 End with NEXT-CSID, PSP & USD This I-D. 49 End with NEXT-CSID, USP & USD This I-D. 50 End with NEXT-CSID, PSP, USP & USD This I-D. 52 End.X with NEXT-CSID This I-D. 53 End.X with NEXT-CSID & PSP This I-D. 54 End.X with NEXT-CSID & USP This I-D. 55 End.X with NEXT-CSID, PSP & USP This I-D. 56 End.X with NEXT-CSID & USD This I-D. 57 End.X with NEXT-CSID, PSP & USD This I-D. 58 End.X with NEXT-CSID, USP & USD This I-D. 59 End.X with NEXT-CSID, PSP, USP & USD This I-D. 85 End.T with NEXT-CSID This I-D. 86 End.T with NEXT-CSID & PSP This I-D. 87 End.T with NEXT-CSID & USP This I-D. 88 End.T with NEXT-CSID, PSP & USP This I-D. 89 End.T with NEXT-CSID & USD This I-D. 90 End.T with NEXT-CSID, PSP & USD This I-D. 91 End.T with NEXT-CSID, USP & USD This I-D. 92 End.T with NEXT-CSID, PSP, USP & USD This I-D. 93 End.B6.Encaps with NEXT-CSID This I-D. 94 End.B6.Encaps.Red with NEXT-CSID This I-D. 95 End.BM with NEXT-CSID This I-D. 101 End with REPLACE-CSID This I-D. 102 End with REPLACE-CSID & PSP This I-D. 103 End with REPLACE-CSID & USP This I-D. 104 End with REPLACE-CSID, PSP & USP This I-D. 105 End.X with REPLACE-CSID This I-D. 106 End.X with REPLACE-CSID & PSP This I-D. 107 End.X with REPLACE-CSID & USP This I-D. 108 End.X with REPLACE-CSID, PSP & USP This I-D. 109 End.T with REPLACE-CSID This I-D. 110 End.T with REPLACE-CSID & PSP This I-D. 111 End.T with REPLACE-CSID & USP This I-D. 112 End.T with REPLACE-CSID, PSP & USP This I-D. 114 End.B6.Encaps with REPLACE-CSID This I-D. 115 End.BM with REPLACE-CSID This I-D. 116 End.DX6 with REPLACE-CSID This I-D. 117 End.DX4 with REPLACE-CSID This I-D. 118 End.DT6 with REPLACE-CSID This I-D. 119 End.DT4 with REPLACE-CSID This I-D. 120 End.DT46 with REPLACE-CSID This I-D. 121 End.DX2 with REPLACE-CSID This I-D. 122 End.DX2V with REPLACE-CSID This I-D. 123 End.DT2U with REPLACE-CSID This I-D. 124 End.DT2M with REPLACE-CSID This I-D. 127 End.B6.Encaps.Red with REPLACE-CSID This I-D. 128 End with REPLACE-CSID & USD This I-D. 129 End with REPLACE-CSID, PSP & USD This I-D. 130 End with REPLACE-CSID, USP & USD This I-D. 131 End with REPLACE-CSID, PSP, USP & USD This I-D. 132 End.X with REPLACE-CSID & USD This I-D. 133 End.X with REPLACE-CSID, PSP & USD This I-D. 134 End.X with REPLACE-CSID, USP & USD This I-D. 135 End.X with REPLACE-CSID, PSP, USP & USD This I-D. 136 End.T with REPLACE-CSID & USD This I-D. 137 End.T with REPLACE-CSID, PSP & USD This I-D. 138 End.T with REPLACE-CSID, USP & USD This I-D. 139 End.T with REPLACE-CSID, PSP, USP & USD This I-D.
Acknowledgements The authors would like to thank Kamran Raza, Xing Jiang, YuanChao Su, Han Li, Yisong Liu, Martin Vigoureux, and Joel Halpern for their insightful feedback and suggestions. The authors would also like to thank Andrew Alston, Linda Dunbar, and Adrian Farrel for their thorough review of this document.
&RFC8402; &RFC8754; &RFC8986; &RFC9256; &RFC9259; &RFC9350; &RFC2119; &RFC8174; &RFC7942; &RFC9252; &RFC9352; &I-D.ietf-6man-sids; &I-D.ietf-lsr-ospfv3-srv6-extensions; &I-D.ietf-idr-bgpls-srv6-ext; &I-D.ietf-idr-bgp-ls-sr-policy; &I-D.ietf-idr-segment-routing-te-policy; &I-D.ietf-pce-segment-routing-ipv6; &I-D.clad-spring-srv6-srh-compression-illus; SPRING chairs email on the adoption of draft-filsfilscheng-spring-srv6-srh-compression-02 SPRING chairs email on working group process SPRING Working Group Policies SPRING Working Group Chairs Segment Routing Configuration Guide for Cisco NCS 540 Series Routers Cisco Systems Segment Routing Configuration Guide for Cisco NCS 560 Series Routers Cisco Systems Segment Routing Configuration Guide for Cisco NCS 5500 Series Routers Cisco Systems Segment Routing Configuration Guide for Cisco NCS 5700 Series Routers Cisco Systems Segment Routing Configuration Guide for Cisco 8000 Series Routers Cisco Systems Segment Routing Configuration Guide for Cisco ASR 9000 Series Routers Cisco Systems Segment Routing and PCE User Guide Nokia Add NEXT-C-SID support for SRv6 End behavior SONiC uSID Added new behaviors to support uSID instruction Srv6 cli reference FD.io SRv6 uSID (micro SID) implementation on P4 Stratum CMCC G-SRv6 Project Open Networking Foundation Open SRv6 Project Multi-Vendor MPLS SDN Interoperability Test Report European Advanced Networking Test Center (EANTC)
Open Issues This section was added as requested by the SPRING chair in . Issues raised during and after the adoption call for this draft are tracked in an issue tracker. The remainder of this section identifies the most significant open issues, from the adoption call, for the working group to keep track of. As a reminder to those reading this section, this document is a work in progress, and subject to change by the working group. As noted at the front of this document, "It is inappropriate to use Internet-Drafts as reference material" Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective. As reminded in the conclusion of the adoption call, this document is subject to the policy announced by the SPRING chairs in . In particular, this means that this document can not go to WG last call until 6man completes handling of an Internet Draft that deals with the relationship of C-SIDs to RFC 4291. It is hoped and expected that said resolution will be a WG last call and document approval in 6man of a document providing for the way that C-SIDs use the IPv6 destination address field.
Complete pseudocodes The content of this section is purely informative rendering of the pseudocodes of with the modifications in this document. This rendering may not be used as a reference.
End with NEXT-C-SID When processing the SRH of a packet matching a FIB entry locally instantiated as an End SID with the NEXT-C-SID flavor:
max_LE) or (Segments Left > Last Entry+1)) { S10. Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S11. } S12. Decrement IPv6 Hop Limit by 1. S13. Decrement Segments Left by 1. S14. Update IPv6 DA with Segment List[Segments Left]. S15. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination. ]]>
Before processing the Upper-Layer header or any IPv6 extension header other than Hop-by-Hop or Destination Option of a packet matching a FIB entry locally instantiated as an End SID with the NEXT-C-SID flavor:
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End SID with the NEXT-C-SID flavor:
End with REPLACE-C-SID When processing the SRH of a packet matching a FIB entry locally instantiated as an End SID with the REPLACE-C-SID flavor:
max_LE) or (Segments Left > Last Entry)) { R03. Send an ICMP Parameter Problem to the Source Address, Code 0 (Erroneous header field encountered), Pointer set to the Segments Left field, interrupt packet processing and discard the packet. R04. } R05. Decrement DA.Arg.Index by 1. R06. If (Segment List[Segments Left][DA.Arg.Index] == 0) { R07. Decrement Segments Left by 1. R08. Decrement IPv6 Hop Limit by 1. R09. Update IPv6 DA with Segment List[Segments Left] R10. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination. R11. } R12. } Else { R13. If((Last Entry > max_LE) or (Segments Left > Last Entry+1)){ R14. Send an ICMP Parameter Problem to the Source Address, Code 0 (Erroneous header field encountered), Pointer set to the Segments Left field, interrupt packet processing and discard the packet. R15. } R16. Decrement Segments Left by 1. R17. Set DA.Arg.Index to (128/LNFL - 1). R18. } R19. Decrement IPv6 Hop Limit by 1. R20. Write Segment List[Segments Left][DA.Arg.Index] into the bits [LBL..LBL+LNFL-1] of the Destination Address of the IPv6 header. R21. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination. S16. } ]]>
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End SID with the REPLACE-C-SID flavor:
Contributors ZTE Corporation
China liu.aihua@zte.com.cn
Alibaba
USA d.cai@alibaba-inc.com
Cisco Systems, Inc.
Canada ddukes@cisco.com
Futurewei Technologies Ltd.
USA james.n.guichard@futurewei.com
Huawei Technologies
China c.l@huawei.com
NTT Network Innovations
USA robert@raszuk.net
Cisco Systems, Inc.
India ketant.ietf@gmail.com
Bell Canada
Canada daniel.voyer@bell.ca
Broadcom
Israel shay.zadok@broadcom.com