<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-li-spring-compressed-srv6-np-02"
     ipr="trust200902" updates="">
  <front>
    <title abbrev="Compressed SRv6 NP">Compressed SRv6 Network
    Programming</title>

    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>lizhenbin@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Cheng Li" initials="C." surname="Li">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>chengli13@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Chongfeng Xie" initials="C." surname="Xie">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>China Telecom Information Science&amp;Technology Innovation
          park, Beiqijia Town,Changping District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>xiechf.bri@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Kihoon LEE" initials="K." surname="LEE">
      <organization>LG U+</organization>

      <address>
        <postal>
          <street>71, Magokjungang 8-ro, Gangseo-gu</street>

          <city>Seoul</city>

          <region/>

          <code/>

          <country>Republic of Korea</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>soho8416@lguplus.co.kr</email>

        <uri/>
      </address>
    </author>

    <author fullname="Hui Tian" initials="H." surname="Tian">
      <organization>CAICT</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>tianhui@caict.ac.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Feng Zhao" initials="F." surname="Zhao">
      <organization>CAICT</organization>

      <address>
        <postal>
          <street>Beijing</street>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhaofeng@caict.ac.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="James N Guichard" initials="J." surname="Guichard">
      <organization>Futurewei Technologies</organization>

      <address>
        <postal>
          <street>2330 Central Express Way</street>

          <city>Santa Clara</city>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>james.n.guichard@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Cong Li" initials="C." surname="Li">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>China Telecom Information Science&amp;Technology Innovation
          park, Beiqijia Town,Changping District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>licong.bri@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Shuping Peng" initials="S." surname="Peng">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>pengshuping@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date day="25" month="February" year="2020"/>

    <area>Routing Area</area>

    <workgroup>SPRING Working Group</workgroup>

    <abstract>
      <t>Segment Routing can be applied to the IPv6 data plane by leveraging a
      new type of Routing Extension Header, called Segment Routing Header
      (SRH). However, the overhead introduced by SRH may be a challenge for
      existing hardware, which may influence on the forwarding performance and
      the payload efficiency.</t>

      <t>This document defines a compressed SRv6 network programming mechanism
      in order to reduce the overhead of SRv6 by introducing the Compressed
      Segment Identifier (C-SID) and the Compressed SRH (C-SRH). The C-SRH can
      be a new Routing Header or an enhancement of SRH.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Segment routing (SR) <xref target="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.</t>

      <t>When segment routing is deployed on the IPv6 data plane, it is called
      SRv6 <xref target="I-D.ietf-6man-segment-routing-header"/>.An SRv6
      Segment ID (SID) is a 128-bit value, and it can be represented as
      LOC:FUNCT where LOC is the L most significant bits and FUNCT is the
      128-L least significant bits <xref
      target="I-D.ietf-spring-srv6-network-programming"/>. L is called the
      locator length and is flexible. Each network operator is free to use the
      locator length it chooses. The LOC part of the SID is routable and leads
      to the node which instantiates that SID.</t>

      <t>For support of SR, a new routing header called Segment Routing Header
      (SRH), which contains a list of SIDs and other information, has been
      defined in <xref target="I-D.ietf-6man-segment-routing-header"/>. In use
      cases like Traffic Engineering, an ordered SID List with multiple SIDs
      is inserted into the SRH to steer packets along an explicit path.</t>

      <t>However, the overhead of SIDs (16 bytes per SID) may be a challenge
      for existing hardware processing, as the size of the SRH may affect the
      forwarding performance. When the packet is small, the payload efficiency
      is not ideal due to the large overhead of the SRH. When the packet is
      large, the overhead of the SRH may cause the packet to be dropped due to
      PMTU <xref target="RFC8200"/>.</t>

      <t>This document defines a compressed SRv6 network programming mechanism
      in order to reduce the overhead of SRv6 by introducing the Compressed
      Segment Identifier (C-SID) and the Compressed SRH (C-SRH). The C-SRH can
      be a new Routing Header or an enhancement of SRH, in either case,
      compatibility with the existing SRH is maintained.</t>
    </section>

    <section title="Terminology">
      <t>This document makes use of the terms defined in <xref
      target="I-D.ietf-6man-segment-routing-header"/>, <xref
      target="RFC8402"/> and <xref target="RFC8200"/>, and the reader is
      assumed to be familiar with that terminology. This document introduces
      the following new terms:</t>

      <t>C-SRH: Compressed Segment Routing Header</t>

      <t>C-SID: Compressed Segment Identifier</t>

      <t>C-Tag: Compressed Tag</t>

      <section title="Requirements Language">
        <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
    </section>

    <section anchor="c-srh" title="Compressed SID (C-SID)">
      <t>This document defines a Compressed SID (C-SID) to carry the last 16 -
      N bytes of the original SRv6 SID, where N is the length of the common
      prefix among SIDs in the SID list. N is calculated by comparing the
      difference of each SID with other SIDs on the SID list.</t>

      <t>The common prefix part contains the common part of all Locators in
      the SID list, while the C-SID contains the different part, if any, of
      all Locators and the Function ID of an SRv6 SID. Generally, in an SRv6
      domain, the common prefix can be the SRv6 SID block as per <xref
      target="I-D.ietf-spring-srv6-network-programming"/>, and the C-SID
      consists of the Node ID and Function ID.</t>

      <t>The IPv6 DA contains a 128-bits (16 Bytes) SRv6 SID, and it can be
      separated into two parts: the common prefix among all SIDs, and the
      current C-SID on the SID list.</t>

      <t><figure>
          <artwork><![CDATA[ 
  0                                         N                16 bytes
  +--------------------------------------------------------------+
  |                Common Prefix            |        C-SID       | 
  +--------------------------------------------------------------+
  |<----------------- Locator ------------------->|<-FunctionID->|
                                            |<--->|
                                               | 
                                     Different part of Locator     
  
                    Figure 1. C-SID in IPv6 DA

]]></artwork>
        </figure></t>

      <t>In this way, the common prefix is carried by the IPv6 DA only, and
      the SIDs in the SID list will not carry the common prefix, but only the
      last 16 - N bytes of the original SRv6 SID.</t>

      <t>Therefore, this document does not define any new SRv6 segment
      types.</t>

      <t/>

      <t>Editor's Note: A C-SID can be a fixed length value, such as 32 bits,
      and actually authors suggest 32 bits.</t>

      <t>Also, the C-SID does not have to be the last part of SRv6 SID. An
      SRv6 SID may contains three parts: Common prefix, C-SID and argument. By
      default, the argument is 0, and it is treated as padding. The format is
      shown in Figure 2. </t>

      <t>In this case, operators can allocate a appropriate length common
      prefix for their networks.</t>

      <t>For example, the Common Prefix is A::/48, the C-SID is a 32 bits
      value, and the argument can be 48 bits zero, then only the 80
      bits(Common prefix + C-SID) are used for routing, and only the C-SIDs
      will be carried in the SRH and updated to DA.</t>

      <t><figure>
          <artwork><![CDATA[ 
  0         Variable Length            32 bits                128 bits
  +--------------------------------------------------------------+
  |             Common Prefix   |  C-SID         | Argument      |
  +--------------------------------------------------------------+
  |<-------- Locator ---------------->|<-FuctID->|<---Argument-->|
                                |<--->|
                                   | 
                        Different part of Locator     
  
                Figure 2. 32 bits C-SID in IPv6 DA

]]></artwork>
        </figure></t>

      <t/>
    </section>

    <section title="Compressed Segment Routing Header (C-SRH)">
      <t/>

      <t>In order to carry the C-SID, this document defines the Compressed
      Segment Routing Header (C-SRH).</t>

      <t>The C-SRH can be a new Routing Header (with new Routing Type (TBD))
      or an enhancement of the SRH (Note: the latter is preferred in this
      document).</t>

      <t>The C-SRH provides a more efficient encoding mechanism for SRv6, and
      is compatible with the existing SRv6 architecture.</t>

      <t/>

      <t><figure align="center">
          <artwork><![CDATA[
     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   |E|      Flag   | C-Tag |           Tag         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Segment List[0](16 or 16 - C-Tag bytes)            |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Segment List[1](16 - C-Tag bytes)                |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Segment List[n](16 - C-Tag bytes)                |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Optional Padding to align with 64 bits Boundary  ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                                                             //
    //         Optional Type Length Value objects (variable)       //
    //                                                             //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3. Compressed Segment Routing Header

]]></artwork>
        </figure></t>

      <t>where:</t>

      <t><list style="symbols">
          <t>Next Header: Defined in <xref target="RFC8200"/></t>

          <t>Hdr Ext Len: Defined in <xref target="RFC8200"/></t>

          <t>Routing Type: 4 when C-SRH is an enhancement of SRH, or new type
          (TBD) when C-SRH is a new Routing Header.</t>

          <t>Segments Left: Defined in <xref target="RFC8200"/></t>

          <t>Last Entry: contains the index (zero based), in the Segment List,
          of the last element of the Segment List.</t>

          <t>Flags: <figure>
              <artwork><![CDATA[    0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |E|U U U U U U U|
    +-+-+-+-+-+-+-+-+

    U: Unused and for future use.  MUST be 0 on transmission and
    ignored on receipt.

    E: Exclude flag, set when the last SID is excluded in compression.

        1: the last SID is excluded in compression, and it is a 16 
           bytes (128 bits) value 

        0: the last SID is included in compression, and it is a 
           16 - C-Tag bytes value

]]></artwork>
            </figure></t>
        </list></t>

      <t><list style="symbols">
          <t>C-Tag: 4-bit unsigned integer to indicate the length of the
          common prefix. Therefore, the length of the C-SID in C-SRH is 16 -
          C-Tag bytes except the last segment if and only if the E-flag is
          set. When the C-Tag is 0, the length of C-SIDs in C-SRH is 16 bytes,
          which is compatible with the existing SRH <xref
          target="I-D.ietf-6man-segment-routing-header"/>.</t>

          <t>Tag: 12 bits value to tag a packet as part of a class or group of
          packets, e.g., packets sharing the same set of properties as per
          <xref target="I-D.ietf-6man-segment-routing-header"/>.</t>

          <t>Segment List[0]: 16 bytes (128 bits ) IPv6 address when E-flag is
          set, and last 16 - C-Tag bytes of SID when E-flag is unset.</t>

          <t>Segment List[n]: a compressed SRv6 SID, which is the last 16 -
          C-Tag bytes value of the original nth SRv6 SID. The Segment List is
          encoded starting from the last segment of the SR Policy, i.e., the
          first element of the segment list (Segment List [0]) contains the
          last segment of the SR Policy, the second element contains the
          penultimate segment of the SR Policy and so on.</t>

          <t>Type Length Value (TLV) are described in <xref
          target="I-D.ietf-6man-segment-routing-header"/>.</t>
        </list>In some use cases, the last SID may be a normal SID, which has
      a different prefix against all other SIDs, so it can be excluded in
      C-SID generation for better compression.</t>

      <t>The E-flag indicates whether the last SID is excluded in compression.
      When E-flag is set, Segment List[0] will carry the original SID,
      otherwise, it carries the compressed SID, i.e. the last 16 - C-Tag bytes
      of the original Segment List[0].</t>

      <t>Padding is needed after the SID List[Last entry] to align with 64
      bits.</t>

      <t/>

      <t>Editor's Note: The authors had consided that there are some
      mechanisms to indicate compression, authors would like to have the
      comments from the working group, to see which option is the best, so
      welcome to send your comments.</t>

      <t><list style="numbers">
          <t>Option 1: Compression Tag: C-tag in SRH<list style="symbols">
              <t>Compression tag indicates the length of Common prefix
              explicitly.</t>

              <t>Indicate the length of C-SID as well, if the length of C-SID
              is a well-known length value.</t>

              <t>No need to modify the control plane to distribute new type of
              SIDs.</t>

              <t>SRH is modified, some bits are needed.</t>

              <t>A SID can be used for normal SRv6 routing or Compression SRv6
              routing.</t>

              <t>New SID space for compression is optional.</t>
            </list></t>

          <t>Option 2: Compression Flag: C-flag in SRH<list style="symbols">
              <t>C-flag indicates compression, and the length of common prefix
              is learned from the control plane or configuration.</t>

              <t>Indicate the length of C-SID as well, if the length of C-SID
              is a well-known length value.</t>

              <t>Need to distribute the length of Common prefix or configure
              it in the SRv6 domain.</t>

              <t>SRH is modified, a bit in flag for indicating compression is
              needed.</t>

              <t>A SID can be used for normal SRv6 routing or Compression SRv6
              routing.</t>

              <t>New SID space for compression is optional.</t>
            </list></t>

          <t>Option 3: Compression Flavor/SID/Locator/SID Space: C Flavor/C
          Type in Control plane<list style="symbols">
              <t>New compression type of SIDs or SIDs with C flavor, they
              should be distributed via control plane, such as IGP.</t>

              <t>The format of SID should be distributed via control plane,
              such as the length of common prefix.</t>

              <t>SRH is not modified.</t>

              <t>C-SID is used for compression SRv6 routing only.</t>

              <t>New SID space for compression is required.</t>
            </list></t>
        </list></t>

      <t>The format of C-SRH of Option 2 and 3 are shown below.</t>

      <t><figure align="center">
          <artwork><![CDATA[
     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   |C|    Flag     |             Tag               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Segment List[0](N bytes)                    |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Segment List[1]   (N bytes)                 |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Segment List[n](N bytes)                    |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Optional Padding to align with 64 bits Boundary  ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                                                             //
    //         Optional Type Length Value objects (variable)       //
    //                                                             //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 4. Compressed Segment Routing Header with C-flag

     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   |        Flag   |             Tag               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Segment List[0](N bytes)                    |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Segment List[1](N bytes)                    |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Segment List[N](N bytes)                    |
    .                              ...                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Optional Padding to align with 64 bits Boundary  ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                                                             //
    //         Optional Type Length Value objects (variable)       //
    //                                                             //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 5. C-SRH without changing Common header of SRH


]]></artwork>
        </figure></t>
    </section>

    <section title="C-SRH Processing ">
      <t>The compressed SID List can be generated by the ingress node by
      comparing the SIDs to get the C-Tag value according to the length of the
      common prefix. The compressed SID List can also be generated by a
      Controller and be sent to the ingress node, and the necessary protocol
      extensions for this are outside the scope of this document. (Note: The
      former is preferred in this document)</t>

      <t>When the ingress node applies SRv6 policy to packets, a C-SRH can be
      encapsulated in a new IPv6 header (Encapsulation Mode). The first SID is
      carried along with the common prefix in the DA, and the remaining C-SIDs
      are carried in the SID List of the C-SRH. The last SID is inserted
      according to the E-flag.</t>

      <t>When an SRv6 endpoint node receives the packet, the node will follow
      the same processing procedure as with an SRH, that is, to inspect
      whether the DA is a local SID or not, if yes, then process the SID
      according to its function. Otherwise, it will perform regular IPv6
      forwarding.</t>

      <t>When the DA is a local SID, then the node will process the C-SRH and
      the C-SIDs, and the current C-SID on the segment-list will replace the
      last 16 &ndash; C-Tag bytes of the IPv6 DA.</t>

      <t>Regarding the last SID, if the E-flag is set, the entire 128 bits of
      Segment List[0] is updated to IPv6 DA. Otherwise, the C-SID will be
      updated to replace the last 16 - C-Tag bytes of IPv6 DA. After updating
      the IPv6 DA, the packet will be forwarded accordingly.</t>

      <t>The pseudo code of C-SRH processing is shown below.</t>

      <t>Editor's Note: The pseudo code will be updated when the options of
      Compression SRv6 NP are converged.</t>

      <t/>

      <t><figure>
          <artwork><![CDATA[   01. When a C-SRH is processed {
   02.   If Segments Left is equal to zero {
   03.     Proceed to process the next header in the packet,
           whose type is identified by the Next Header field in
           the Routing header.
   04.   }
   05.   Else {
   06.     If local configuration requires TLV processing {
   07.       Perform TLV processing
   08        //If E-flag is unset:
   09.       //  TLV begins at SID length + Padding Length
   10.       //  SID Length = Last Entry * (16 - C-Tag)
   11.       //  Padding Length = 8 - Last Entry * (16 - C-Tag)%8
   12.       //Else:
             //  TLV begins at SID length + Padding Length
   13.       //  SID Length = Last Entry * (16 - C-Tag) + C-Tag
   14.     If  (Segments Left is greater than (Last Entry+1)) {
   15.       Send an ICMP Parameter Problem, Code 0, message to
             the Source Address, pointing to the Segments Left
             field, and discard the packet.
   16.     }
   17.     Else {
   18.       Decrement Segments Left by 1.
   19.       if Segments Left > 0 or Segments Left = 0 and E-flag = 0:
   20.         // Update the C-SID to the DA
   21.         Copy Segment List[Segments Left] from the SRH to
               replace the last 16 - C-Tag bytes of
               destination address of the IPv6 header.
   22.       else:
   23.         // Segment Left = 0 and E-flag = 1
               // Segment List[0] is a 16 bytes value.
   24.         Copy Segment List[Segments Left] from the SRH to
               destination address of the IPv6 header.
   25.       If the IPv6 Hop Limit is less than or equal to 1 {
   26.         Send an ICMP Time Exceeded -- Hop Limit Exceeded in
               Transit message to the Source Address and discard
               the packet.
   27.       }
   28.       Else {
   29.         Decrement the Hop Limit by 1
   30.         Resubmit the packet to the IPv6 module for 
               transmission to the new destination.
   31.       }
   32.     }
   33.   }
   34. }
]]></artwork>
        </figure></t>
    </section>

    <section title="Control Plane Consideration">
      <t/>

      <t>Editor's note: Control Plane consideration will be described in
      separate drafts in the future. Note that, some extensions may be not
      needed in some Compression options.</t>

      <t>For indicating compression, the node should advertise the
      capabilities of SRv6 compression via control plane. A C-flag should be
      added in:</t>

      <t/>

      <t><list style="symbols">
          <t>SRv6 Capabilities sub-TLV in IS-IS <xref
          target="I-D.ietf-lsr-isis-srv6-extensions"/></t>

          <t>SRv6-Capabilities TLV in OSPF <xref
          target="I-D.li-ospf-ospfv3-srv6-extensions"/>,</t>

          <t>OPEN Object/PATH-SETUP-TYPE-CAPABILITIES TLV/SRv6 Capabilities
          sub-TLV in PCEP <xref
          target="I-D.ietf-pce-segment-routing-ipv6"/></t>
        </list>For distributing the C-SID in control plane, the C-flag should
      be added to the following TLV or sub-TLV in IGP/BGP/BGP-LS and PCEP.</t>

      <t><list style="symbols">
          <t>IS-IS <xref target="I-D.ietf-lsr-isis-srv6-extensions"/>:<list
              style="symbols">
              <t>SRv6 Locator TLV, when C-flag is set, the Locator Block
              length is less than 96 if the C-SID is a 32 bits value.</t>

              <t>SRv6 END.X/ LAN END.X sub-TLV</t>
            </list></t>

          <t>OSPF <xref target="I-D.li-ospf-ospfv3-srv6-extensions"/><list
              style="symbols">
              <t>SRv6 Locator TLV, when C-flag is set, the Locator Block
              length is less than 96 if the C-SID is a 32 bits value.</t>

              <t>SRv6 END.X/ LAN END.X sub-TLV , when C-flag is set, the
              Locator Block length is less than 96 if the C-SID is a 32 bits
              value.</t>
            </list></t>
        </list><list style="symbols">
          <t>BGP <xref target="I-D.ietf-bess-srv6-services"/><list
              style="symbols">
              <t>SRv6 SID Information sub-TLV, when C-flag is set, the Locator
              Block length is less than 96 if the C-SID is a 32 bits
              value.</t>
            </list></t>
        </list><list style="symbols">
          <t>BGP-LS <xref target="I-D.ietf-idr-bgpls-srv6-ext"/><list
              style="symbols">
              <t>SRv6 Link Attributes: SRv6 END.X SID TLV/LAN END.X SID TLV,
              when C-flag is set, the Locator Block length is less than 96 if
              the C-SID is a 32 bits value.</t>

              <t>SRv6 Prefix Attributes: SRv6 Locator TLV, when C-flag is set,
              the Locator Block length is less than 96 if the C-SID is a 32
              bits value.</t>

              <t>SRv6 SID Attributes: SRv6 Endpoint Function TLV, when C-flag
              is set, the Locator Block length is less than 96 if the C-SID is
              a 32 bits value.</t>

              <t>SRv6 SID Attributes: SRv6 BGP Peer Node SID TLV, when C-flag
              is set, the Locator Block length is less than 96 if the C-SID is
              a 32 bits value.</t>
            </list></t>
        </list>For distributing SRv6 Policy with compression SIDs, a C-flag
      should be added in BGP and PCEP.</t>

      <t><list style="symbols">
          <t>BGP SR Policy <xref
          target="I-D.ietf-idr-segment-routing-te-policy"/><list
              style="symbols">
              <t>SRv6 Segment List sub-TLV, when C-flag is set, the Locator
              Block length is less than 96 if the C-SID is a 32 bits value.
              Candidate path and SR Policy level's extensions will be
              described in the future revision.</t>

              <t>Segment sub-TLV, when C-flag is set, the Locator Block length
              is less than 96 if the C-SID is a 32 bits value. The entire SID
              is still carried in the SR Policy, while the C-flag will
              indicate this is a compression SID with C-SID.<list
                  style="symbols">
                  <t>Type 2: SRv6 SID</t>

                  <t>Type 9: IPv6 Node addr with opt SRv6 SID</t>

                  <t>Type 10: IPv6 addr+intf ID for Local and remote pair for
                  SRv6 with opt SID</t>
                </list></t>
            </list></t>
        </list><list style="symbols">
          <t>PCEP<list style="symbols">
              <t>PATH-SETUP-TYPE TLV <xref target="RFC8408"/>: When PST is 2,
              the the C-flag indicates the SID list of the Path should be
              Compression SID.</t>

              <t>SRv6 ERO Subobject <xref
              target="I-D.ietf-pce-segment-routing-ipv6"/></t>

              <t>SRv6 RRO Subobject <xref
              target="I-D.ietf-pce-segment-routing-ipv6"/></t>
            </list></t>
        </list></t>

      <t/>

      <t/>
    </section>

    <section title="Illustration">
      <t>This section describes a simple example to illustrate the usage of
      C-SID. Similar to <xref
      target="I-D.filsfils-spring-srv6-net-pgm-illustration"/>, in order to
      ease the reading of the example, we introduce a simple reference diagram
      and simplified SID allocations.</t>

      <t>Editor's note: the following part will be updated accordingly when
      the compression option is converged in WG.</t>

      <section title="Reference Diagram">
        <t>Nodes 1 - 8 are SRv6 enabled nodes within the network domain.</t>

        <t>Nodes CE1, CE2, and CE3 are outside the domain.</t>

        <t>CE1 and CE2 are tenants of VPN 10.</t>

        <t>Nodes 1 and 8 act as PE respectively to nodes CE1 and CE3.</t>

        <t>All the links within the domain have the same IGP metric.</t>

        <t>The IGP metric shortest-path from 1 to 8 is 1-2-7-8, while the
        latency-metric shortest-path from 1 to 8 is 1-2-3-4-5-6-7-8.</t>

        <t><figure>
            <artwork><![CDATA[
                       CE2
                          \
                           4------5
                           |      |
                     +-----3------6
                     |     |    / |
                     |     |  /   |
                     |     |/     |
     Tenant10  CE1---1-----2------7---8---CE3  Tenant10 with
                                                   IPv4 20/8
                                                                          
                 Figure 3: Reference topology


]]></artwork>
          </figure></t>
      </section>

      <section title="Compressed SRv6 Forwarding Example">
        <t>This section describes a simple example to show how efficiently
        C-SRH can reduce the overhead of SRv6.</t>

        <t>In order to ease the reading of the example, it is better to
        introduce a simplified SID allocation schema. We assume:<list
            style="symbols">
            <t>B::/112 is dedicated to the internal SRv6 SID space, which is
            the common prefix. Therefore, the C-SID is a 16-bit value.</t>

            <t>A locator expressed in 120 bits and a function expressed in 8
            bits.</t>

            <t>Node k has B::0k/120 for its local SID space. Its SIDs will be
            explicitly allocated from that block.</t>

            <t>Node k advertises B::0k/120 in its IGP.</t>

            <t>Function 01 represents the End function with PSP support.</t>

            <t>B::0k01 represents the End function with PSP support allocated
            by node K, such as B::0601 represents the End function with PSP
            support allocated by node 6.</t>

            <t>B::0810 is an END.DT4 SID initiated by node 8, which is
            associated with the VRF10.</t>
          </list></t>

        <t>In SRH based SRv6, the PE 1 encapsulates the packets from CE1 to
        CE3 in an outer IPv6 header with DA = B::0201 and SRH (B::0810,
        B::0701, B::0601, B::0501, B::0401, B::0301, B::0201; SL=6; NH=4).</t>

        <t>&lt;B::0201, B::0301, B::0401, B::0501, B::0601, B::0701,
        B::0810&gt; follows the latency-metric shortest-path. The total length
        of SRH is 8+16*7=120 bytes.</t>

        <t>In Compressed SRv6, PE 1 encapsulates the packets from CE1 to CE3
        in an outer IPv6 header with DA = B::0201 and C-SRH (0810, 0701, 0601,
        0501, 0401, 0301, 0201, SL=6; NH=4) with E-flag unset. The C-Tag is
        14, since the length of the common prefix is 112 bits. Therefore, the
        total length of C-SRH is 8 + (16-14)*7 = 22 bytes, reducing the
        encapsulation overhead by 98 bytes (81.7% less overhead than SRH) or
        87.5% reduction in SIDs overhead.</t>

        <t>The packet leaves node 1 to node 2 according to the FIB associated
        with the IPv6 DA B::0201. The packet can be presented as:</t>

        <t><figure>
            <artwork><![CDATA[    (A::1, B::0201)
    (0810, 0701, 0601, 0501, 0401, 0301, 0201, SL=6; NH=4)
    (CE1, CE3)]]></artwork>
          </figure></t>

        <t>When 2 receives the packet, 2 matches B::0201 in its "My SID Table"
        and executes the END function behavior to update the IPv6 DA. Since
        the updated SL is greater than 0, and the C-Tag is 14, then it copies
        the C-SID that is a 2 bytes value to replace the last 2 bytes of the
        IPv6 DA, and then forwards the packet according to the new IPv6 DA
        B::0301. The packet can be presented as:</t>

        <t><figure>
            <artwork><![CDATA[    (A::1, B::0301)
    (0810, 0701, 0601, 0501, 0401, 0301, 0201, SL=5; NH=4)
    (CE1, CE3)]]></artwork>
          </figure></t>

        <t>Like node 2, the nodes 3, 4, 5, and 6 perform the END function
        behavior to update the IPv6 DA with the corresponding C-SID and then
        forward the packet by looking up the IPv6 DA in their FIB accordingly.
        Therefore, the packet leaving node 6 can be presented as:</t>

        <t><figure>
            <artwork><![CDATA[    (A::1, B::0701)
    (0810, 0701, 0601, 0501, 0401, 0301, 0201, SL=1; NH=4)
    (CE1, CE3)]]></artwork>
          </figure></t>

        <t>When 7 receives the packet, 7 matches B::0701 in its "My SID Table"
        and executes the END function behavior to update the IPv6 DA. Since
        the updated SL is 0 and E-flag is unset, then it copies the C-SID that
        is a 2 bytes value to replace the last 2 bytes of the IPv6 DA. Also,
        the C-SRH is popped since the B::0701 is an END SID with PSP flavor.
        Node 7 then performs a lookup on the updated IPv6 DA B::0810 to
        forward the packet along the shortest path to node 8. The packet can
        be presented as:</t>

        <t><figure>
            <artwork><![CDATA[    (A::1, B::0810)
    (CE1, CE3)]]></artwork>
          </figure></t>

        <t>When 8 receives the packet, 8 matches B::0810 in its "My SID Table"
        and executes the END.DT4 function behavior to sends the IP packet
        (CE1, CE3) to its VPN destination.</t>

        <t>This example illustrates the procedure of C-SRH based SRv6
        forwarding, and shows that the longer the common prefix, the more the
        SRv6 overhead can be reduced. More benefits are described in section
        7.</t>
      </section>
    </section>

    <section title="Inter-domain Routing Using C-SRH">
      <t>Considering privacy and security of SRv6 domain, when SRv6 is used
      for inter-domain routing, the detailed SIDs will not be leaked between
      domains, and the Binding SID <xref target="RFC8402"/> SHOULD be used.
      The typical inter-domain using SRv6 is illustrated in Figure 4.</t>

      <t>When receiving the packet from CE1 to CE2, the Ingress node of SRv6
      domain A can generate an SRv6 packet with SID List &lt;BSID1, BSID2,
      VPN1&gt;.</t>

      <t>BSID1 is bound to an SR Policy, which contains a list of SID list in
      SRv6 Domain B, for example [B1::1, B2::1, B3::1, B4::1, B5::1].</t>

      <t>Similarly, BSID2 is bound to an SR Policy in SRv6 Domian C, for
      example [C1::1, C2::1, C3::1, C4::1, C5::1].</t>

      <t>VPN1 SID can be an END.DT4 SID associated with CE2.</t>

      <t>In this way, the SIDs should be inserted at the ingress node are
      reduced from 11 to 3.</t>

      <t/>

      <t><figure>
          <artwork><![CDATA[
                           BSID1             BSID2      VPN1
       +---------+          +---------+        +---------+
       |         |          |         |        |         |
 CE1---*---------*----------*-*-*-*-*-*--------*-*-*-*-*-*---CE2
       |         |          |         |        |         |
       +---------+          +---------+        +---------+
      SRv6 Domain A         SRv6 Domain B       SRv6 Domain C

      (A1::1,BSID1)           
      (VPN1,BSID2,BSID1)   
      (CE1, CE2)

        Figure 4.SRv6 Inter-domain Routing using BSID  

]]></artwork>
        </figure></t>

      <t>Normally, when a BSID is processed , a new IPv6 and SRH will be added
      to the packet, and the SRH carries the SID list representing the
      sub-path of this domain. C-SRH can be used to carry Compressed SID list
      within the SRv6 domain for reducing the overhead of SRv6.</t>

      <t>In this way, a Binding SID can be associated with an SR Policy, which
      contains a C-SID list to be carried by a C-SRH.</t>

      <t>Therefore, in inter-domain SRv6 routing, C-SRH can be used in each
      domain, while the SRH is used for inter-domian. In addition, if the
      common prefixs of SIDs in SRH can be compressed, C-SRH can be used for
      carring these SIDs as well.</t>
    </section>

    <section title="Benefits">
      <t/>

      <t><figure>
          <artwork><![CDATA[
1.  Seamless integration with SRv6 Network Programming

   o  No new type (Functions, such as END) of SRv6 SIDs is defined.
      A C-SID is a sub-set of an SRv6 SID.  

   o  Does not redefine the IPv6 address space nor requires any 
      specific IPv6 space.

2. Support for full set of SRv6 functionalities

   o  Full set of SRv6 functionality (BE, Loose TE and Strict TE, etc.)
      are supported without any extra route advertisements.

   o  Function ID information is maintained.

3.  Control-Plane friendly

   o  No need to make any extensions in Control-Plane to 
      advertise new type of SIDs or binding information.

   o  No indexed mapping table is required

   o  No routing extension is required.

   o  No new route advertisement is required if without new Locators

4.  Hardware-friendly

   o  Hardware has the mature capability to overwrite the IPv6 DA.

   o  Avoids any extra lookup in indexed mapping table


5.  Efficient MTU overhead

   o  C-SRH has the smallest MTU overhead among alternative solutions
      (VxLAN with SR-MPLS, CRH, uSID), when all the Segment endpoint 
      nodes information is maintained in the packet.

6.  Scalable SR TE

   o  8 C-SIDs can be carried in 128 bits when C-SID is 16 bits value

   o  16 Segment endpoint nodes (1 in DA and 16 in C-SRH including 
      the one in DA) in 40 bytes of overhead.
          o  T.Encaps with a C-SRH of 40 bytes (8 fixed + 2 * 16
             bytes)
          
          o  ALL C-SIDs are maintained in C-SRH, which can be used
             for recording the explicit routing path.
 
7.  Saving IPv6 address 

   o  Very limited IPv6 address are needed for SID space. Longer
      Common Prefix means smaller IPv6 address burning and 
      smaller overhead of SRv6.

   o  Very easy to meet the requirement of C-SRH since any operator
      or person can offer a 112/, 80/ or even 64/ prefix.
]]></artwork>
        </figure></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>

      <t/>
    </section>

    <section title="Contributors">
      <t><figure>
          <artwork><![CDATA[Zhibo Hu
Huawei Technologies
huzhibo@huawei.com

Zhongzheng Wang
Huawei Technologies
wangzhongzhen@huawei.com

Bing Liu
Huawei Technologies
remy.liubing@huawei.com

Yang Xia
Huawei Technologies
yolanda.xia@huawei.com

Jianwei Mao
Huawei Technologies
MaoJianwei@huawei.com

]]></artwork>
        </figure></t>
    </section>

    <section title="Acknowledgements ">
      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.8200'?>

      <?rfc include='reference.I-D.ietf-6man-segment-routing-header'?>

      <?rfc include='reference.RFC.8402'?>

      <?rfc include='reference.I-D.ietf-lsr-isis-srv6-extensions'
?>

      <?rfc include='reference.I-D.li-ospf-ospfv3-srv6-extensions'?>

      <?rfc include='reference.I-D.ietf-pce-segment-routing-ipv6'
?>

      <?rfc include='reference.I-D.ietf-idr-bgpls-srv6-ext'?>

      <?rfc include='reference.I-D.ietf-bess-srv6-services'
?>

      <?rfc include='reference.I-D.ietf-idr-segment-routing-te-policy'
?>

      <?rfc include='reference.RFC.8408'?>

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-spring-srv6-network-programming'?>

      <?rfc include='reference.I-D.filsfils-spring-srv6-net-pgm-illustration'?>

      <?rfc ?>
    </references>
  </back>
</rfc>
