Internet-Draft Generalized Arguments July 2022
Li, et al. Expires 12 January 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-lm-spring-srv6-generalized-arguments-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Li
Huawei Technologies
J. Mao
Huawei Technologies
C. Li
Huawei Technologies

Generalized Arguments of SRv6 Segment

Abstract

This 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.

Status of This Memo

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 12 January 2023.

Table of Contents

1. Introduction

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.

2. 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 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminologies

SRv6: Segment Routing over IPv6

4. Problem Statement and Requirements

With the development of SRv6, several kinds of SRv6 Arguments for the SRv6 End SID and End.X SID emerge[I-D.ietf-spring-srv6-srh-compression], 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[I-D.ietf-6man-enhanced-vpn-vtn-id], IOAM[RFC9197], Alternate Marking[I-D.ietf-6man-ipv6-alt-mark][I-D.fz-spring-srv6-alt-mark], APN6[I-D.li-apn-ipv6-encap][I-D.li-apn-header], DetNet[I-D.pthubert-detnet-ipv6-hbh], 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.

5. Generalized Arguments

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.

5.1. Method A

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.

5.2. Method B

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).

MSB:
    0
    0 1 2 3 4 5 6 7 ...
   +-+-+-+-+-+------------------------------------
   |A|B|C|D|E|  the instructions of feature A~E
   +-+-+-+-+-+------------------------------------

LSB:
   ------------------------------------+-+-+-+-+-+
      the instructions of feature A~E  |A|B|C|D|E|
   ------------------------------------+-+-+-+-+-+

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.

5.3. Consideration of SRv6 C-SID Compression

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.

MSB:
    0
    0 1 2 3 4 5 6 7 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------------------------------
   |C-SID1 |C-SID2 |C-SIDn |A|B|C|D|E|  the instructions of feature A~E
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------------------------------

LSB:
   +-+-+-+-+-+-+-+-+-+-+-+-+-----------------------------------+-+-+-+-+-+
   |C-SID1 |C-SID2 |C-SIDn |  the instructions of feature A~E  |A|B|C|D|E|
   +-+-+-+-+-+-+-+-+-+-+-+-+-----------------------------------+-+-+-+-+-+

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.

6. Flavor for Generalized Arguments

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:

Method A:
S01. If (some NEXT-C-SIDs are encoded in the Generalized Arguments) {
S02.     Left shift the C-SIDs by the length of one C-SID
S03. }
S04. Load the relative template
S05. Parse the Generalized Arguments as per section 4.1
S06. For each parsed feature {
S07.     Perform actions according to the parsed instructions
         as per the specifications of that feature
S08. }

Method B:
S01. If (some NEXT-C-SIDs are encoded in the Generalized Arguments) {
S02.     Left shift the C-SIDs by the length of one C-SID
S03. }
S04. For each bit in the bitmap {
S05.     If (the bit == 1) {
S06.         Parse the instructions of the feature from the Generalized
             Arguments as per section 4.2
S07.         Perform actions according to the parsed instructions
             as per the specifications of that feature
S08.     }
S09. }

7. IANA Considerations

TBD

8. Security Considerations

TBD

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References

[I-D.fz-spring-srv6-alt-mark]
Fioccola, G., Zhou, T., and M. Cociglio, "Segment Routing Header encapsulation for Alternate Marking Method", Work in Progress, Internet-Draft, draft-fz-spring-srv6-alt-mark-02, , <https://www.ietf.org/archive/id/draft-fz-spring-srv6-alt-mark-02.txt>.
[I-D.ietf-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, "Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension Header", Work in Progress, Internet-Draft, draft-ietf-6man-enhanced-vpn-vtn-id-00, , <https://www.ietf.org/archive/id/draft-ietf-6man-enhanced-vpn-vtn-id-00.txt>.
[I-D.ietf-6man-ipv6-alt-mark]
Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate Marking Method", Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-alt-mark-16, , <https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-alt-mark-16.txt>.
[I-D.ietf-spring-srv6-srh-compression]
Cheng, W., Filsfils, C., Li, Z., Decraene, B., Cai, D., Voyer, D., Clad, F., Zadok, S., Guichard, J. N., Aihua, L., Raszuk, R., and C. Li, "Compressed SRv6 Segment List Encoding in SRH", Work in Progress, Internet-Draft, draft-ietf-spring-srv6-srh-compression-01, , <https://www.ietf.org/archive/id/draft-ietf-spring-srv6-srh-compression-01.txt>.
[I-D.li-apn-header]
Li, Z., Peng, S., and S. Zhang, "Application-aware Networking (APN) Header", Work in Progress, Internet-Draft, draft-li-apn-header-02, , <https://www.ietf.org/archive/id/draft-li-apn-header-02.txt>.
[I-D.li-apn-ipv6-encap]
Li, Z., Peng, S., and C. Xie, "Application-aware IPv6 Networking (APN6) Encapsulation", Work in Progress, Internet-Draft, draft-li-apn-ipv6-encap-05, , <https://www.ietf.org/archive/id/draft-li-apn-ipv6-encap-05.txt>.
[I-D.pthubert-detnet-ipv6-hbh]
Thubert, P. and F. Yang, "IPv6 Options for DetNet", Work in Progress, Internet-Draft, draft-pthubert-detnet-ipv6-hbh-07, , <https://www.ietf.org/archive/id/draft-pthubert-detnet-ipv6-hbh-07.txt>.
[RFC3272]
Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10.17487/RFC3272, , <https://www.rfc-editor.org/info/rfc3272>.
[RFC8754]
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <https://www.rfc-editor.org/info/rfc8754>.
[RFC8986]
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://www.rfc-editor.org/info/rfc8986>.
[RFC9197]
Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, , <https://www.rfc-editor.org/info/rfc9197>.

Authors' Addresses

Zhenbin Li
Huawei Technologies
Beijing
100095
China
Jianwei Mao
Huawei Technologies
Beijing
100095
China
Cheng Li
Huawei Technologies
Beijing
100095
China