Huawei Technologies

Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China c.l@huawei.com

Huawei Technologies

Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China zengguanming@huawei.com

Routing Area SPRING Working Group This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing.

Segment routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node by inserting an ordered list of instructions, called segments. When segment routing is deployed on the IPv6 data plane, it is called SRv6 . For support of SR, a new routing header called Segment Routing Header (SRH), containing a list of segments, optional TLVs and other information, has been defined in . Currently, when TLVs are carried in an SRH, they are ignored by the nodes by default, unless there are some local policies on nodes to enable the SRH TLV processing . When a node is configured to process a TLV, it needs to examine all the SRH TLVs for processing a single TLV (TLVs except HMAC in SRH MAY appear in any order), which is inefficient. Furthermore, in order to deploy a new service, network operators need to configure multiple nodes along the path to support SRH TLVs processing, which is complicated. Also, it is not easy to dynamically adjustment the local policy for meeting dynamic service requirements. However, SRv6 does not have the compability to program the rules of SRH TLVs processing on the ingress node currently. In summary, network operator are not able to program the SRH TLV processing rules on the ingress node to process specific TLVs on specific segment endpoint nodes for some packets dynamically. This document proposes a mechanism to program the SRH TLVs processing rules explicitly and dynamically on the ingress node. In this mechanism, there is no need to configure nodal local policy to support SRH TLV processing. It can be used for the following use cases: Service Function Chaining (SFC): In SFC, SRH TLVs like Firewall related TLVs may only be processed on some specific nodes instead of all the nodes along the path. Smart In-situ OAM (IOAM): In IOAM, the IOAM metadata will be collected by all the nodes along the path. However, in the most cases, only the metadatda on some nodes are important for OAM, while the others are redundant or irrelevant. For example, congestion may occur only on some nodes, not all nodes. In addition, congestion may occur on link A at the last moment and may occur on link B at the next moment. To implement smarter and more efficient IOAM, the scope of IOAM metadata collection needs to be dynamically adjusted (without modifying the segment list) based on the result of IOAM measurement to reduce unnecessary IOAM information collection.

This document makes use of the terms defined in , and the reader is assumed to be familiar with that terminology. This document introduces the following terms: TPI: TLV Processing Indicator

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.

This document defines a new flavor in SRv6 to indicate the SRv6 endpoint node to process SRH TLVs. Also, this document defines an SRH TLV processing rule TLV in SRH to describe how to process the TLV on SRv6 endpoint nodes.

Currently, SRv6 endpoint nodes will ignore the SRH TLV if there is no local policy to enable processing. When receives an SRv6 packet, in order to explicitly indicate to process SRH TLVs, a TLV Processing Indicator (TPI) Flavor is defined in this document. By default, the node should ignore the SRH TLV. With TPI flavor, SRH TLV processing can be triggered by TPI flavor SID without local configuration. When a TPI flavor SID is processed at an SRv6 node, the node MUST process the SRH TLVs. Otherwise, the SRH TLVs SHOULD be ignored by default or processed based on the local policies as per .

When an SRv6 endpoint node receives an SRv6 packet with SRH TLVs, it will process all the TLVs within the SRH, but actually only some TLVs should be processed at this node while most of the TLVs SHOULD be skipped. For example, SRH "S-class" and "D-class" TLVs are processed at Firewall node only and they SHOULD NOT be processed at other nodes along the path. In order to enhance the performance of SRH TLV processing, this section defines TLV processing Indicator (TPI) TLV to describe how to process the SRH TLVs. If the TPI TLV appears in SRH, it MUST be the first TLV for better processing efficiency. Only one TPI TLV is allowed in SRH. If multiple TPI TLVs are included, only the first TLV will be processed and the rest will be ignored. If Its format is shown below. [Editor's notes] This part may be moved to 6man draft in the future since this is an IPv6 dataplane extension.

Type: type of TPI TLV, TBA. The TLV MUST be ignored if the node does not have the capability to process the TPI TLV. Length: Length of the TPI TLV. Bitmap Length: The length of Bitmap in a TLV Processing Indicator (TPI) entry, in byte. For instance, if there are 6 TLVs (exclude TPI TLV) within the SRH, the length of Bitmap is 1 bytes. If there are 12 TLVs within the SRH (exclude TPI TLV), the length of Bitmap is 2 Bytes. TPI Left: Index of the active TPI entry in the TPI TLV. TLV Processing Indicator: A TLV Processing Indicator indicates how to process the SRH TLVs at a specific node associated with the SID in SRH[TPI.SL]. An TPI TLV can include multiple TPI entries to specify the processing rules on multiple nodes. The length of a TPI entry is variable depends on the length of the bitmap. Segment Left: Segment Left (SL) is the key of a TPI entry, which indicates the node associated with SID in SRH[TPI.SL] needs to process the SRH TLVs according to the TPI entry. When a node processes the TPI TLV, it examines the TPI entry located at TPI-List[TPI Left]. If the value of SRH.SL is equivalent with TPI-List[TPI Left].SL, the node MUST process the SRH TLVs based on the TPI entry, and decrement TPI Left by 1 if TPI Left is greater than 0. If the value of SRH.SL is not equivalent, the processing of the SRH TLVs is skipped. Bitmap: The bitmap indicates which SRH TLVs are needed to be processed on the node associated with SRH[TPI.SL]. Setting the nth bit means the (n+2)th SRH TLV is required to be processed, since the first TLV in SRH MUST be the TPI TLV and the index of the bitmap begins with 0. For instance, If the second TLV (the First TLV after the TPI TLV) in the SRH is needed to be processed on the node, the first bit (bit 0) in the bitmap is set. If the second TLV and the sixth TLV are needed to be processed, the bit 0 and bit 4 are set in the bitmap. Multiple TPI Entries are encoded after the first 32 bits in TPI TLV following the descending order of SL in TPI entries. [Editor's notes: The TPI TLV MUST be the first TLV in SRH, therefore, the HMAC TLV should be the second one, this may require to update ].

In order to easy understanding, this section describes a simple example. The topology is shown in Figure 3. For instance, an SRv6 packet is forwarded from node 1 to node 6. Therefore, <SID2, SID3, SID4, SID5, SID6> is encoded in the SRH. According to the sevice requirements, the SID3 and SID6 are TPI flavor SID, which indicate the nodes to process SRH TLVs. 4 TLVs are encoded in the SRH, TLV 1 and TLV2 will be processed at node 3, while the TLV3 and TLV 4 will be processed at node 6. Other nodes are not required to process any SRH TLVs of this packet. In the SRH TLV fields, a TPI TLV and the other 4 TLVs are encoded, and the TPI TLV is the first TLV. The value of bitmap length field is 1 since there are only 4 TLVs (TPI TLV is excluded) in the SRH. Two TPI entries are encoded after the first 32 bits in TPI TLV. The length of each TPI entry is 2 bytes, 1 byte for SL and 1 byte for the bitmap. The first TPI entry (TPI-List[0]) describes the SRH TLV processing rules on node 6, and its SL is 0. The bit 2 and bit 3 are set in its bitmap to indicate to process the TLV3 and TLV 4. The last TPI entry (TPI List[1]) describes the SRH TLV processing rules on node 3, and its SL is 3. The bit 0 and bit 1 are set in its bitmap to indicate to process the TLV1 and TLV 2.

The TPI Left is initiated as 1 at node 1, and the encoding of TPI TLV in the case is shown below.

<- Last TPI Entry -> Figure 4. Instantiation of TPI TLV at node 1 ]]>

When the packet is received at node 2, the SRH TLVs are skipped by default. When the packet is received at node 3, the SRH TLVs are processed because the SID3 is a TPI floavor SID allocated by node 3. When the node 3 processes SRH TLVs, the first TLV to be processed is the TPI TLV. Node 3 compares the TPI-List[TPI Left].SL and SRH.SL, if they are equivalent, the node 3 processes the TLV 1 and TLV 2 according to the bitmap and updates the TPI Left to be 0. When the packet is received at node 4, the SRH TLVs are skipped by default. When the packet is received at node 5, the SRH TLVs are skipped by default. When the packet is received at node 6, the SRH TLVs are processed because the SID6 is a TPI floavor SID allocated by node 6. When the node 6 processes SRH TLVs, the first TLV to be processed is the TPI TLV. Node 6 compares the TPI-List[TPI Left].SL and SRH.SL, if they are equivalent, the node 6 processes the TLV 3 and TLV 4 according to the bitmap. The TPI Left will not be updated because it is 0 already.

TBD

TBD

TBD

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Futurewei Technologies Ltd. Cisco Systems, Inc. Bell Canada Huawei Technologies Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. A clear application of the SRv6 Network Programming model consists in steering, in a stateless manner, packets through a Service Function Chain (SFC). Each Service Function (SF) is identified by a segment. Each SF can enrich its operation thanks to metadata present in the SRH. This document describes a practical use-case where the SF is a firewall and the metadata helps to drastically decrease the number of rules that need to be maintained by the operation team.

The following individuals contributed significantly to this document: Huawei Technologies

China yolanda.xia@huawei.com

Huawei Technologies

China dhruv.ietf@gmail.com

Huawei Technologies

China lizhenbin@huawei.com