| Internet-Draft | SRH TPP | August 2022 |
| Li, et al. | Expires 9 February 2023 | [Page] |
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.¶
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 9 February 2023.¶
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.¶
Segment routing (SR) [RFC8402] 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 [RFC8754]. 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 [RFC8754].¶
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 [RFC8754].¶
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:¶
This document makes use of the terms defined in [RFC8754], 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 [RFC2119] [RFC8174] 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 [RFC8754].¶
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 [I-D.guichard-spring-srv6-simplified-firewall] 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.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Bitmap Length | TPI Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Processing Indicator 0 (Variable Length)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Processing Indicator 1 (Variable Length)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. SRH TLV Processing Indicator TLV(Variable Length)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment Left | Bitmap ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. TLV Processing Indicator(TPI) Entry
¶
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.¶
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 [RFC8754]].¶
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.¶
TLV1, TLV2 TLV3, TLV4
1-------2--------3--------4--------5--------6
* *
Figure 3. Illustration of ESTP
* means TPI flavor SID is processed on that node.
¶
The TPI Left is initiated as 1 at node 1, and the encoding of TPI TLV in the case is shown below.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=8 |Bitmap Length=1| TPI Left=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SL=0 | |1|1| | SL=3 | |1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<- First TPI Entry -><- 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¶