| Internet-Draft | vSID: SRv6 variable length SID | March 2022 |
| Decraene, et al. | Expires 8 September 2022 | [Page] |
This document proposes an extension to Segment Routing IPv6 (SRv6) Network Programming to allow for SRv6 Segment Identifier (SID) of smaller variable length. The use of smaller SRv6 SID reduces the size the SRv6 Header (SRH). This reduces the overhead for both the traffic volume and the network processor. It is a straightforward extension to the SRv6 Network Programming model and its SRH encapsulation.¶
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 8 September 2022.¶
Copyright (c) 2022 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Segment Routing (SR) architecture is defined RFC 8402 [RFC8402].¶
IPv6 Segment Routing Header (SRH) is defined RFC 8754 [RFC8754].¶
SRv6 Network Programming is defined RFC 8986 [RFC8986].¶
The reader is expected to be familiar with the three above documents which define Segment Routing over the IPv6 data-plane (SRv6).¶
SRv6 is flexible and powerful, but in some uses cases, when a large number of SIDs are required, the size of the SRH/SID may be seen as too large both for some dataplane processors and traffic overhead.¶
The goal of this document is to propose a solution which reduces the size of the SRv6 header when a high number of SIDs is required with minimal changes to the SRv6 architecture, signaling, SRH and data plane processing.¶
This document extends SRH and SRv6 Network Programming to allow for SIDs of variable length, from 1 up to 128 bits. In a way, this is a generalization of SRv6 for any (v)SID length, where 128-bits SIDs is a special case.¶
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 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
In a nutshell, SRv6 variable length SIDs (SRv6 vSIDs) proposes to:¶
In other words, 128-bits SRv6 SIDs are kept unchanged for signaling, configuration and SR policies. In the data plane, this proposal compresses the encoding of SRv6 SIDs in the SRH by not encoding the SRv6 vSIDs prefixes which are redundant across vSIDs.¶
The use of the destination address in the IPv6 header is unchanged. The IPv6 destination address still contains the current/next 128-bits SRv6 SID. As a consequence, the IPv6 destination address already indicates the SRv6 vSID prefix and there is no extend the SRH to carry it.¶
In a way, this is similar to SR-MPLS RFC 8660 [RFC8660]:¶
One difference compared to SR-MPLS is that lowest bits of the SRv6 vSID prefix are zero which allows for an easier operation in the data plane. Indeed,the addition of the vSID may be replaced by a copy of the vSID bits. Another difference is that the motivation to offset to a zero base index/vSID is different.¶
Except for the Segment List using (shorter) vSIDs, the format of the SRH is unchanged. The length of the vSIDs is defined to be 128 bits minus the length of the vSIDs prefix. It is variable but its length does not need to be encoded in the SRH header. Indeed the vSIDs length only needs to be known by the SR Segment Endpoint Node processing it. As per section 4.3 of RFC 8754 [RFC8754], the SR node identifies its local SID by performing a longest-prefix-match lookup on the packet IPv6 destination address. This identifies the SID and its properties, such as the SR endpoint behavior but also the length of the vSIDs.¶
An SRv6 vSID deployment choose one length 'L' of vSIDs and an associated SRv6 vSIDs prefix.¶
0 (bits) vSIDs 128
Length
+--------------------------------------------------------------+
| SRv6 SID |
+--------------------------------------------------------------+
+--------------------------------------------------------------+
| SRv6 vSIDs prefix | vSID |
+--------------------------------------------------------------+
An SRv6 vSID deployment may use multiple SRv6 vSIDs prefixes. Each prefix may have its own vSIDs length.¶
As per section 3.1 of RFC 8986 [RFC8986], an SRv6 SID can be represented as 'B:N:FUNCT:ARG'. Where 'B' is the SRv6 SID prefix, N is the identifier of the parent node N, FUNCT is the function of the SID of length 128-S.¶
For SRv6 vSIDs, the SRv6 prefix is 'B' of length LB as advertised in the SRv6 SID Structure Sub-Sub-TLV defined in [I-D.ietf-lsr-isis-srv6-extensions]. The vSID length for vSIDs of this block is computed as 128 - LB. The vSID includes 'N:FUNCT:ARG'.¶
In order to simplify implementations, the length of the vSIDs MUST be a multiple of 8-bits, up to 128 bits included, in order to provide octet alignment in the SRH Segment List. However this specifications is written to work for any bit granularity from 1 to 128 bits. This allows for a future document to define a new profile with a higher granularity (e.g. 1 bit, 4 bits, 16 bits, or an integer fraction 128-bits) depending on hardware capabilities and flexibility requirements. To allow some implementations to be further simplified, a specific profile 'Profile-32' is created restricting the vSID length to be 32-bits.¶
As per section 2 of RFC 8754 [RFC8754], the Segment Routing Header (SRH) is defined as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[0] (128 bits IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
...
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[n] (128 bits IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When vSIDs are used, there are encoded in the Segment List of the Segment Routing Header (SRH).¶
vSIDs are encoded back to back using their native length. There is no padding between SIDs and there is no specific alignment of the SID.¶
In a SRH, all vSIDs MUST have the same vSIDs length 'L' and the same SRv6 vSIDs prefix.¶
If the Segment List[n] does not end on a octet boundary, then padding bits MUST be added up to the next octet boundary. Those padding bits MUST be set to 0 when sent and ignored on receipt.¶
TLVs starts on next octet boundary.¶
As defined in RFC 8754 [RFC8754], padding TLVs are used to pad the SRH to a multiple of 8 octets. As vSIDs may be of any size, not necessarily a multiple of 8 octets, the support of padding TLVs are REQUIRED.¶
The fields 'Segments Left' and 'Last Entry" keep their meaning but refers to vSIDs of length L.¶
The following diagram illustrates an example of SRH with vSIDs of sixteen bits:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Entry | Flags | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment List[0] | Segment List[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment List[n] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // // Optional Type Length Value objects (variable) // // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section defines a flavor for Endpoint behaviors. It defined below using the "End" Endpoint behavior but is applicable to all SID behaviors.¶
The processing takes as an argument the length L of the vSIDs. This length L is a property of the vSID and is given as a result of the lookup on the IPv6 destination address which identifies the SRv6 SID and its properties. The properties include the Endpoint behavior and the length L of the vSIDs.¶
When N receives a packet whose IPv6 DA is S and S is a local vSID of length L, the lines S08 and S14 of the End processing which were, as per section 4.1 of RFC 8986 [RFC8986]:¶
S08. max_LE = (Hdr Ext Len / 2) - 1¶
[...]¶
S14. Update IPv6 DA with Segment List[Segments Left]¶
are replaced by the following:¶
S08. max_LE = (Hdr Ext Len * 64 / L) - 1¶
[...]¶
S14. Copy Segment List[Segments Left] from the SRH to the L lowest order bits of the destination address of the IPv6 header.¶
Note: S14. Taking into consideration that the Segment List is a list of vSIDs of length L bits¶
SRv6 vSID is believed to have the following benefits:¶
Flexible SID length, to accommodate for various deployment models, network sizes, SRv6 usages.¶
This section illustrates the usage of SRv6 vSIDs through two examples. The first example uses global segments with a vSIDs locator been globally routable. The second example uses local segments only with a vSIDs locator commom to all SR end nodes hence not been able to locate a specific SR end node. Global and local segments are defined as per RFC 8402 [RFC8402] section 2.¶
In this example vSIDs are used for global SIDs and are used alone without 128-bits SRv6 SIDs.¶
The SR domain has the following characteristics:¶
Some metrics of this SR domain:¶
If SRv6 vSIDs only identifies local segments, with no needs for global segments, there is no need for a global route toward a node hence the 'N' may have a size of zero. This may be interesting for a deployment using both 128-bits SRv6 SIDs and very short SRv6 vSIDs. Such SRv6 vSIDs could be used when a strictly routed path is needed and encoded as a list of adjacency SIDs. Given that the number of local adjacency SIDs is independent of the size of the SR domain, and typically below 255, one could use 8-bits vSIDs which would allow encoding 16 vSIDs within a single 128-bits SRv6 SID hence provides a very effective SRH compression.¶
In this example vSIDs are used only for local SIDs, such as adjacency SIDs. vSIDs are used in complement with 128-bits SRv6 SIDs.¶
The SR domain has the following caracteristics:¶
Some metrics of this SR domain:¶
One SR Endpoint node may need a larger vSIDs space. This may especially be the case when at the same time:¶
This section defines two solutions to increase the vSIDs length on a node requiring a vSIDs space larger than other nodes.¶
In order to increase the vSIDs length on a node, a simple option is to allocate multiple locators of a larger locator to this node, within the SRv6 vSIDs prefix. As per RFC 8986 [RFC8986], a locator may be represented as B:N where B is the SRv6 SID block (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the identifier of the parent node instantiating the SID. Following this format, multiple node identifiers Ns may be allocated to a node. Allocating 'k' identifiers increase the vSIDs space of that node by 'k'.¶
When an SR Endpoint node needs more SIDs than allowed by the vSIDs Length, it MAY combine two (resp. N) vSIDs of length L to effectively benefit from a vSID of length 2*L (resp. N*L). This is a local choice of this SR Endpoint. Nothing specific is required in the SRH which only contains those 2 (resp. N) SIDs instead of a single one.¶
Note that when two vSIDs are combined, the first vSID may be seen as having the role of a "Context SID" identifying a context specific SID space/table, with the second SID been looked up in this context specific table. This is similar to the Context-Specific Label space defined in the section 3 of RFC 5331 [RFC5331].¶
This section defines the extension to SRv6 Network Programming allowing for a SID behavior "End.DT6" to be encoded with 'k' vSID. This is equally applicable to others SID behaviors.¶
The processing takes as an argument the vSIDs length 'L', and the number of vSIDs 'k'. 'L' and 'k' are a property of the vSID and are given as a result of the lookup of the IPv6 destination address which identifies the SRv6 SID and its properties. The properties include the Endpoint behavior, the length L of the vSIDs and the number 'k' of vSIDs used to encode this behavior in the SRH.¶
When N receives a packet destined to S and S is a local End.DT6 SID encoded with 'k' vSIDs, N does the following processing:¶
When N receives a packet whose IPv6 DA is S and S is a local End.DT6 vSID of length L and encoded with 'k' vSIDs the line S02 of the End.DT6 processing which was, as per section 4.6 of RFC 8986 [RFC8986]:¶
S02. If (Segments Left != 0) {¶
is replaced by the following:¶
S02. If (Segments Left != k - 1) {¶
When processing the Upper-layer header of a packet, the lines S04-S05 which were:¶
S04. Remove the outer IPv6 Header with all its extension headers¶
S05. Set the packet's associated FIB table to T¶
are replaced by the following:¶
S04a. Read the k-1 next vSIDs¶
S04b. Remove the outer IPv6 Header with all its extension headers¶
S05. Set the packet's associated FIB table to the one identified by the concatenation of the k-1 next vSIDs¶
Some SRv6 traffic may need to cross multiple routing domains, such as differents Autonomous Systems (ASes) or different routing areas. Different routing domains may use different addressing schema making it difficult to find a common SRv6 vSIDs prefix.¶
This section defines an optional solution and SID behavior allowing for the use of different SRv6 vSIDs prefixes between routing domains.¶
The solution requires a new SID behavior, called "Endpoint with cross-connect to an array of layer-3 adjacencies and SRv6 vSIDs Prefix Swap" (End.XvPS for short) allowing for this transition of SRv6 vSIDs prefix between two routing domains.¶
End.XvPS is a variant of End.X, performing both "End.X Layer-3 Cross-Connect" and the translation of the SRv6 vSIDs prefix between the two routing domains.¶
The processing takes as an argument the vSIDs length L and the prefix P2 of the SRv6 vSIDs prefix in the second domain. Those two parameters are a property of the (received) vSID and are given as a result of the lookup on the IPv6 destination address which identifies the SRv6 SID and its properties.¶
When N receives a packet whose IPv6 DA is S and S is a End.XvPS SID behavior, with a local vSID length L, and a remote/next SRv6 vSIDs prefix P2, the line S14 of the End processing which was, as per section 4.1 of RFC 8986 [RFC8986]:¶
S14. Update IPv6 DA with Segment List[Segments Left]¶
is replaced by the following:¶
S14. Copy Segment List[Segments Left] from the SRH to the L lowest order bits of the destination address of the IPv6 header and copy the SRv6 vSIDs prefix P2 to the 128-L highest order bits of the destination address.¶
Note: the way the SRv6 vSIDs prefix P2 of the next routing domain is known is out of scope of this document. As examples, they could be learnt via configuration or using a signaling protocol either with the peer domain of with a central controler (e.g. PCE).¶
When End.XvPS SID behavior is used, the restriction on the SRH is relaxed and becomes: in a SRH, all vSID MUST have the same vSID length 'L' and within a routing domain, the same SRv6 vSID prefix.Between routing domaines, separated with the End.XvPS behavior, SRv6 vSID prefixes may be different.¶
The NSIDs flavors is a variant of the End, End.X and End.XvPS behaviors.¶
The NSIDs flavors copy N vVSID from the SRH to the IPv6 destination address.¶
When N receives a packet whose IPv6 DA is S and S is a NSIDs flavor, with a local vSID length L, and a local paramater N, the lines S09, S13 and S14 of the End processing which was, as per section 4.1 of RFC 8986 [RFC8986]:¶
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {¶
S13. Decrement Segments Left by 1¶
S14. Update IPv6 DA with Segment List[Segments Left]¶
are replaced by the following:¶
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) or (Segments Left < = N){¶
S13. Decrement Segments Left by N¶
S14. Copy N Segments List[Segments Left+N-1]...List[Segments Left] from the SRH to the N*L lowest order bits of the destination address of the IPv6 header.¶
Note that if N=128/L, a complete IPv6 address is copied. This is useful when the next SR node is an SRv6 PE requiring its 128-bits SIDs in the IPv6 destination address. This is also useful for inter domain scenarios where both domains use unrelated address spaces and hence use two different SRv6 vSIDs prefixes.¶
This document does not change the security considerations of SRv6. Please refers to RFC 8402 [RFC8402], RFC 8754 [RFC8754] and RFC 8986 [RFC8986] for existing security consideration.¶
This document has been inspired by the work of the SPRING WG and in particular the work done in [I-D.filsfils-spring-net-pgm-extension-srv6-usid] and [I-D.li-spring-compressed-srv6-np]. The authors would like to acknowledge the authors of these two documents.¶
The authors would like to thank Joel Halpern and Francois Clad for their review and comments.¶