Generalized Arguments of SRv6
SegmentHuawei TechnologiesBeijing100095Chinalizhenbin@huawei.comHuawei TechnologiesBeijing100095ChinaMaoJianwei@huawei.comHuawei TechnologiesBeijing100095Chinac.l@huawei.comThis document analyzes the challenges of Arguments of SRv6 SID, and
the chance of using Arguments of SRv6 SID to reduce the length of the
IPv6 extension header. According to these analysis, this document
specifies a kind of generalized and structured Arguments for SRv6 SID,
which can carry multiple Arguments parts for a SRv6 SID.This document analyzes the challenges of the Arguments of SRv6 SID,
and the chance of using Arguments of SRv6 SID to reduce the length of
the IPv6 extension header. According to these analysis, this document
specifies a kind of generalized and structured arguments for SRv6 SID,
which can carry multiple Arguments parts for a SRv6 SID.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 2119RFC
8174 when, and only when, they appear in all capitals, as shown
here.SRv6: Segment Routing over IPv6With the development of SRv6, several kinds of SRv6 Arguments for the
SRv6 End SID and End.X SID emerge, including:1. SRv6 C-SID compression (NEXT Flavor): using Arguments to carry
multiple C-SIDs.2. SRv6 C-SID compression (REPLACE Flavor): using Arguments to carry
the CL field.3. SRv6 C-SID compression (NEXT & REPLACE Flavor): using
Arguments to carry multiple C-SIDs and the CL field.In addition, some new features are created, including network
slicing, IOAM, Alternate Marking, APN6,
DetNet, etc.The instructions of these new features can be processed at:1. All nodes along a SR path: the instructions can be carried in the
IPv6 Hop-by-Hop Options header (HBH).2. Endpoints of an SR path: the ones can be carried in the IPv6
Destination Options Header (DOH) or the SRH TLV.In the second scenario, especially the second one, the usages of the
options or TLVs will cause the following two issues:1. Lengthening the packet header, and reducing the transmission
efficiency.2. Making the forwarding processing complex, affecting forwarding
performance.Besides these issues, in the SRv6 C-SID compression (NEXT Flavor)
solution, if all the C-SIDs of the SID list which should have been
encapsulated in the SRH can be put in the IPv6 destination address of
the packet, because there is no SRH or DOH before SRH any more after the
compression there will be no space for the instructions which should
have been encapsulated in the IPv6 SRH or Destination Options Header
before SRH.In order to address these challenges, a feasible solution is to use
the Arguments of the SRv6 SID to carry those instructions. Using SRv6
Arguments to do that will bring following benefits:1. Reducing the needed space of IPv6 extension header or SRH TLV, so
as to reduce the transmission overhead.2. SRv6 SID can reside in the IPv6 destination address field, so the
SRv6 Arguments can be read and processed as a part of IPv6 address, from
which the forwarding performance will benefit, because it avoids to
process the extension header or SRv6 TLV behind the IPv6 header.3. Unify and simplify the processing: the instructions of both the
SRv6 and the new features are all put in the Arguments part of SRv6 SID
or IPv6 address.In order to carry the instructions of multiple features in the SRv6
Arguments, this section defines two methods to make the SRv6 Arguments
generalized and structured to allocate spaces for the instructions.Network devices are configured a template for the purpose of
parsing the SRv6 Arguments, and the devices read and process the
content of the Arguments according to the template.The template defines what features are carried, and which bits they
are used.For example, if the length of the Arguments is z bits and the
number x, y, and z have the relationship 0<x<y<z, then the
template can define that:* The [0, x) bits carry the instructions of feature A;* The [x, y) bits carry the instructions of feature B;* The [y, z) bits carry the instructions of feature C.Define a bitmap in the Arguments, and each bit in the bitmap
indicates whether the instructions of a specific feature exist. The
correspondence of the bit and the feature, the length of the space of
Arguments to carry the instructions for the feature, and the
instructions needed to be carried for a specific feature can be
defined further in a standardization way.The bitmap can be encoded from the most significant bit (MSB) or
the least significant bit (LSB).When the bit is set (1), it indicates the instructions of the
feature exist. If the bit is reset (0), there can be two options:Option 1: it indicates the instructions of the feature don't
exist.Option 2: it indicates the instructions of the feature exist but is
invalid.Since it is required to shift the C-SID in the SRv6 SID while
applying the NEXT or NEXT & REPLACE behavior for SRv6 C-SID
compression, when method A or B is adopted, when C-SIDs are encoded in
the generalized Arguments of the SRv6 SID which is used as the IPv6
destination address, these C-SIDs MUST be placed from the most
significant bit (MSB), that is, these C-SIDs MUST immediately
following the LOC:FUNCT part of the SRv6 SID.The remaining part of the generalized Arguments following the
C-SIDs SHOULD NOT be shifted when C-SIDs part is shifted. This means
the position of the remaining part after the C-SIDs in the generalized
arguments SHOULD be fixed.This section defines a new flavor to support processing the
Generalized Arguments, named as Structured Arguments flavor.The pseudocode of the Structured Arguments flavor is as follows:TBDTBD