<?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="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-geng-spring-sr-enhanced-detnet-01"
     ipr="trust200902">
  <front>
    <title abbrev="draft-xxx-spring-sr-enhanced-detnet-00">Segment Routing for
    Enhanced DetNet</title>

    <author fullname="Xuesong Geng" initials="X." surname="Geng">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>gengxuesong@huawei.com</email>
      </address>
    </author>

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

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

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

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

    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

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

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

    <date day="13" month="March" year="2023"/>

    <abstract>
      <t>One of the goals of DetNet is to provide bounded end-to-end latency
      for critical flows. This document defines how to leverage Segment
      Routing(SR) and Segment Routing over IPv6 (SRv6) to implement bounded
      latency. Specifically, new SRv6 SID function is used to specify bounded
      latency information for a packet. When forwarding devices along the path
      follow the instructions carried in the packet, the bounded latency is
      achieved by different implementations based on bounded latency
      information.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Deterministic Networking(DetNet) provides a capability to carry
      specified data flows with extremely low data loss rates and bounded
      latency within a network domain. DetNet is enabled by a group of
      technologies, such as resource allocation, service protection and
      explicit routes (<xref target="RFC8655"/>).</t>

      <t>Segment Routing(SR) leverages the source routing paradigm. A ingress
      node steers a packet through an ordered list of instructions, called
      "segments". When SR is used over the MPLS data plane, SIDs are an MPLS
      label or an index into an MPLS label space (either SRGB or SRLB).</t>

      <t>SR can also be applied over IPv6 data plane using Routing Extension
      Header(SRH). Besides routing, the segment of SRv6 can indicate functions
      which are executed locally in the node where they are defined. SRv6
      network programming makes it convenient to add sophisticated operations
      in the network. (<xref target="RFC8402"/>)</t>

      <t>DetNet data plane is enhanced to facilitate DetNet transit nodes to
      support end-to-end bounded latency transmission. <xref
      target="I-D.yzz-detnet-enhanced-data-plane"/> introduces an unified data
      plane feild for bounded latency, which is called Bounded Latency
      Information(BLI) BLIis designed to cope with a variety of
      queuing/scheduling/shaping mechanisms in a uniform format in the data
      plane.</t>

      <t>This document describes how to implement DetNet with SR or SRv6. It
      can provide : 1. Source routing, which can steer the DetNet flows go
      through the network according to an explicit route with allocated
      resource by segment list in SRH; 2. Network programming, which can give
      packet instructions in every node along the path to guarantee bounded
      latency. DetNet SR MPLS/SRv6 data plane extensions for enhanced DetNet
      are defined in this document.</t>

      <t/>
    </section>

    <section title="Terminology and Conventions">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in [RFC2119].</t>

      <section title="Terminology">
        <t>Terminologies for DetNet go along with the definition in <xref
        target="RFC8655"/>. Other terminologies are defined as follows:</t>

        <t><list style="symbols">
            <t>NH: The IPv6 next-header field.</t>

            <t>SID: A Segment Identifier which represents a specific segment
            in a segment routing domain(<xref target="RFC8402"/>).</t>

            <t>SRH: The Segment Routing Header (<xref target="RFC8754"/>).</t>
          </list></t>
      </section>

      <section title="Conventions">
        <t>Conventions in the document are defined as follows:<list
            style="symbols">
            <t>NH=SRH means that NH is 43 with routing type 4.</t>

            <t>A SID list is represented as &lt;S1, S2, S3&gt; where S1 is the
            first SID to visit, S2 is the second SID to visit and S3 is the
            last SID to visit along the SR path.</t>

            <t>SRH[SL] represents the SID pointed by the SL field, that is the
            SLth SID in the Segment List.</t>

            <t>(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:<list
                style="empty">
                <t>IPv6 header with source and destination addresses SA and DA
                respectively, and next-header SRH, with SID list &lt;S1, S2,
                S3&gt; with SegmentsLeft = SL</t>

                <t>The payload of the packet is not represented</t>

                <t>(S3, S2, S1; SL) represents the same SID list as &lt;S1,
                S2, S3&gt;, but encoded in the SRH format where the rightmost
                SID in the SRH is the first SID and the leftmost SID in the
                SRH is the last SID</t>
              </list></t>
          </list></t>
      </section>
    </section>

    <section title="SRv6 for Enhanced DetNet">
      <t>To guarantee the end-to-end bounded latency transmission in DetNet
      network, bounded latency information is required to be conveyed inband
      with the service data to facilitate the queuing algorithm performed on
      the DetNet transit nodes. When the bounded latency information is used
      in DetNet IP data plane or DetNet MPLS data plane, it is carried in
      IP/UDP or MPLS encapsulations. When the bounded latency information is
      used in TSN over IP/MPLS data plane, the information used in TSN
      networks is transparently transmitted IP/ UDP or MPLS encapsulations.
      Note that, which queuing mechanism is used is a local choice determined
      by DetNet transit nodes. It is not necessary to be explicitly indicated
      in packets.</t>

      <t>When an SRv6 SID is in the Destination Address field of an IPv6
      header of a packet, it is routed through transit nodes in an IPv6
      network as an IPv6 address. SRv6 SID consists of LOC:FUNCT:ARG, where a
      locator (LOC) is encoded in the L most significant bits of the SID,
      followed by F bits of function (FUNCT) and A bits of arguments (ARG),
      which is defined in (<xref target="RFC8986"/>).</t>

      <t>Bounded Latency Information (BLI) is defined in <xref
      target="I-D.yzz-detnet-enhanced-data-plane"/> to guide forwarding in
      network device, which could be initiated in SRv6 data plane. With the
      characteristics of Segment Routing, the bounded latency information
      could be coupled with explicit path to provide latency guarantee in each
      node/ adjacency indicated by the segment list.</t>

      <t>Bounded Latency Information is indicated by the allocated SID at each
      node along the path without maintaining per-flow states at the
      intermediate and egress nodes. Hence, it naturally supports flow
      aggregation, and that allows DetNet to support large number of DetNet
      flows and scale to large networks.</t>

      <t>As defined in <xref target="I-D.yzz-detnet-enhanced-data-plane"/>, 8
      or more Bounded Latency Information Types (BLI Type) are introduced to
      differentiate the types of BLIs, based on the required information of
      queuing/scheduling/shaping mechanisms to guarantee bounded latency.
      Bounded Latency Information Value (BLI Value) is a specified value of a
      specific type of BLI to provide guidance for packet processing with the
      meaning of a particular BLI type. The pair &lt;BLI Type, BLI Value&gt;
      information should be indicated by SRv6 data plane.</t>

      <t>The "Endpoint with L3 cross-connect" behavior ("End.X" for short) is
      a variant of the End behavior. It is the SRv6 instantiation of an
      Adj-SID (<xref target="RFC8402"/>), and its main use is for
      traffic-engineering policies.</t>

      <t>Two new variations of End.X SID are defined for DetNet bounded
      latency, which are called End.X.BL and End.X.BLI respectively, and
      bounded latency information can be defined as functions or arguments in
      the new types of SID.</t>

      <t>Editors Notes: Another option to implement this is to define new
      flavors. This method will be considered when not only End.X could be
      combined with BLI.</t>

      <t/>

      <section title="End.X.BL: Forwarding the packet with bounded latency guarantee">
        <t>This document defines End.X.BL, which is used to identify Bounded
        Latency Information for Enhanced DetNet. End.X.BL a variation of
        End.X.</t>

        <t>End.X.BL SID has two meanings: 1) to identify an interface/link,
        just like the adjacency SID; 2) to identify the pair &lt;BLI Type and
        BLI Value&gt; information on the interface/link to guarantee bounded
        latency. So different End.X.BL SIDs could be allocated to the same
        interface/link in order to indicated different pairs &lt;BLI Type, BLI
        Value&gt;.</t>

        <t>The SRv6 encapsulation with End.X.BL SIDs is shown as follows:</t>

        <t><figure>
            <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 |  Segment Left |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Last Entry  |     Flags     |              Tag              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Segment List[0]                          | 
 |                    which is End.X.BL SID                      | 
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              ...                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                      Segment List[n]                          |
 |                    which is End.X.BL SID                      |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Optional TLVS                        |
 |                              ...                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t>When N receives a packet destined to S and S is a local End.X.BL
        SID, N does the following:</t>

        <t><figure>
            <artwork><![CDATA[   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
   S10.      Send an ICMP Parameter Problem to the Source Address
                with Code 0 (Erroneous header field encountered)
                and Pointer set to the Segments Left field,
                interrupt packet processing, and discard the packet.

   S11.   }
   S12.   Decrement IPv6 Hop Limit by 1
   S13.   Decrement Segments Left by 1
   S14.   Update IPv6 DA with Segment List[Segments Left]
   S15.   Submit the packet to the IPv6 module for transmission
             to the new destination via a L3 adjacency indicated by the 
             End.X.BL SID
   S16.   Send the packet out using <BLI Type, BLI Value> indicated by the 
             End.X.BL SID with the corresponding bounded latency guarantee 
             mechanism  
   S17. }
]]></artwork>
          </figure></t>

        <t/>

        <t/>
      </section>

      <section title="End.X.BLI: Forward the packet with bounded latency guarantee though BLI ">
        <t>The "Endpoint with forwarding the packet with bounded latency
        guarantee by BLI" behavior ("End.X.BLI" for short) is a variant of the
        End behavior.</t>

        <t>End.X.BLI SID has two meanings: 1) to identify an interface/link,
        just like the adjacency SID; 2)to identify the BLI Type to guarantee
        bounded latency. So different End.X.BLI could be allocated to the same
        interface/link in order to indicated different types of BLIs. The BLI
        Value corresponding to the End.X.BLI SID is carried explicitly in the
        SRv6 packet header.</t>

        <t>There are 3 possible options for carrying variable BLI Value
        associated with the End.X.BLI SID, including: <list style="symbols">
            <t>Option1: Arguments in End.X.BLI SID</t>

            <t>Option2: SRH TLV for BLI used together with End.X.BLI SID</t>

            <t>Option3: New options in DoH before SRH together with End.X.BLI
            SID</t>
          </list></t>

        <section title="BLI in Arguments of End.X.BLI SID">
          <t>The behavior also takes an argument: "Arg.BLI". This argument
          provides a local BLI Value information for bounded latency
          guarantee. The SRH with End.X.BLI SIDs is showed as follows:</t>

          <t><figure>
              <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 |  Segment Left |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Last Entry  |     Flags     |              Tag              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
   |                  Location & Function                          | 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+End.X.BLI
   |               Bounded Latency Information                     |SID
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      Segment List[n]                          |
   |                     which is End.X.BLI SID                    |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Optional TLVS                        |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>where</t>

          <t><list style="symbols">
              <t>Location&amp;Function: the most significant bits that are
              used for routing and function indication;</t>

              <t>Bounded Latency Information : the least significant bits,
              which is defined <xref
              target="I-D.yzz-detnet-enhanced-data-plane"/>.</t>
            </list></t>

          <t>When N receives a packet destined to S and S is a local End.X.BLI
          SID, N does the following:</t>

          <t><figure>
              <artwork><![CDATA[   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
   S10.      Send an ICMP Parameter Problem to the Source Address
                with Code 0 (Erroneous header field encountered)
                and Pointer set to the Segments Left field,
                interrupt packet processing, and discard the packet.

   S11.   }
   S12.   Decrement IPv6 Hop Limit by 1
   S13.   Decrement Segments Left by 1
   S14.   Update IPv6 DA with Segment List[Segments Left]
   S15.   Submit the packet to the IPv6 module for transmission
             to the new destination via a L3 adjacency  indicated by the
             End.X.BLI SID
   S16.   Send the packet out using BLI Type indicated by the 
             End.X.BLI SID and BLI Value carried in the argument
             with the corresponding bounded latency guarantee mechanism  
   S17. }

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

        <section title="BLI in TLV of SRH">
          <t>Optional TLV defined in SRH could also be extended for BLI, which
          is used together with End.X.BLI.</t>

          <section title="BLI List TLV">
            <t>When all or part of the nodes/adjacencies in the explicit path
            indicated by the segment list request different BLI values
            corresponding to the End.X.BLI SID to guarantee bounded latency, a
            BLI List TLV is defined. The SRH with End.X.BLI SIDs is showed as
            follows:</t>

            <t><figure>
                <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 |  Segment Left |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Last Entry  |     Flags     |              Tag              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      Segment List[n]                          |
      |                     which is End.X.BLI SID                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            ...                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      Segment List[1]                          |
      |                     which is End.X.BLI SID                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type(TBD1)  |    Length     |    BLI Left   |   RESERVED    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        BLI List [m]                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             ...                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        BLI List [1]                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                              
]]></artwork>
              </figure></t>

            <t>The Type field is 8 bits in length, and the value is TBD1.</t>

            <t>The Length field is 8 bits in length and its value is variable,
            which depends on the length of BLI list.</t>

            <t>BLI Left: 8-bit unsigned integer. Number of BLI remaining,
            i.e., number of explicitly listed intermediate nodes still to be
            visited before reaching the final destination.</t>

            <t>BLI List[0..m]: 32-bit unsigned integer, representing the nth
            BLI in the BLI list.</t>

            <t>The BLI in the BLI list corresponds to the Segment in the
            Segment List one by one. The length of BLI List depends on the
            number of End.X.BLI in the segment list.</t>

            <t>When N receives a packet destined to S and S is a local
            End.X.BLI SID, N does the following:</t>

            <t><figure>
                <artwork><![CDATA[   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
   S10.      Send an ICMP Parameter Problem to the Source Address
                with Code 0 (Erroneous header field encountered)
                and Pointer set to the Segments Left field,
                interrupt packet processing, and discard the packet.

   S11.   }
   S12.   Decrement IPv6 Hop Limit by 1
   S13.   Decrement Segments Left by 1
   S14.   Update IPv6 DA with Segment List[Segments Left]
   S15.   Submit the packet to the IPv6 module for transmission
             to the new destination via a L3 adjacency
   S16.   Send the packet out using BLI Type indicated by the
             End.X.BLI SID and BLI Value carried by BLI List[BLI Left]
             in SRH TLV and BLI Left--
             with the corresponding bounded latency guarantee mechanism  
   S17. }

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

          <section title="Shared BLI TLV">
            <t>When all the nodes/adjacencies in the explicit path indicated
            by the segment list request the same BLI value to guarantee
            bounded latency, the Shared BLI TLV is defined. The SRH with
            End.X.BLI SIDs is showed as follows:</t>

            <t><figure>
                <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 |  Segment Left |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Last Entry  |     Flags     |              Tag              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      Segment List[n]                          |
      |                     which is End.X.BLI SID                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            ...                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      Segment List[1]                          |
      |                     which is End.X.BLI SID                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type(TBD2)  |    Length     |              RESERVED         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Shared BLI                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t>The Type field is 8 bits in length, and the value is TBD2.</t>

            <t>The Length field is 8 bits in length and its value is variable,
            which depends on the length of BLI list.</t>

            <t>The Shared BLI field is 32 bits in length and corresponds to
            definition of BLI in <xref
            target="I-D.yzz-detnet-enhanced-data-plane"/>.</t>

            <t>When N receives a packet destined to S and S is a local
            End.X.BLI SID, N does the following:</t>

            <t><figure>
                <artwork><![CDATA[   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
   S10.      Send an ICMP Parameter Problem to the Source Address
                with Code 0 (Erroneous header field encountered)
                and Pointer set to the Segments Left field,
                interrupt packet processing, and discard the packet.

   S11.   }
   S12.   Decrement IPv6 Hop Limit by 1
   S13.   Decrement Segments Left by 1
   S14.   Update IPv6 DA with Segment List[Segments Left]
   S15.   Submit the packet to the IPv6 module for transmission
             to the new destination via a L3 adjacency
   S16.   Send the packet out using BLI Type indicated by the 
             End.X.BLI SID and BLI Value indicated by Shared BLI TLV
             with the corresponding bounded latency guarantee mechanism  
   S17. }

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

          <section title="BLI Options in DOH before SRH">
            <t>According to <xref target="RFC8200"/>, BLI could also be
            defined through DOH before SRH for the specified segment. For the
            case of BLI List, considering that the location of DOH is before
            SRH, it is not recommended to be defined in DoH, because it will
            affect the processing efficiency of Segment in SRH. For Shared BLI
            TLV, it can be carried by the DOH Option. In order for the
            consistency, this document recommends to use the SRH TLV to carry
            both information.</t>

            <t/>
          </section>
        </section>
      </section>
    </section>

    <section title="SR MPLS for Enhanced DetNet ">
      <t>For SR MPLS data plane, this document defines a new segment that is
      called a BLI Segment, which is used to identify Bounded Latency
      Information for Enhanced DetNet just like End.BL SID. A BLI Segment is
      an adjacency segment and allocated from the Segment Routing Local Block
      (SRLB)<xref target="RFC8402"/>. BLI Segment indicateds &lt;BLI Type, BLI
      Value&gt; of an interface/link. So different BLI segments could be
      allocated to the same interface/link in order to indicated different
      pairs &lt;BLI Type, BLI Value&gt;.</t>

      <t>Editors Notes: SR MPLS extension with meta data which is still under
      discussion will be defined based on the progress of MPLS DT. The
      possible definition of MPLS segment associated with the variable BLI
      values like the SRv6 End.X.BLI will be defined in the future
      version.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>The following codepoints are defined in this document in Segment
      Routing Header TLVs registry:</t>

      <t><figure>
          <artwork><![CDATA[          +---------+--------------------------+---------------+
          | Value   | Description              | Reference     |
          +=========+==========================+===============+
          | TBD1    |  BLI List TLV            | This document |
          +---------+--------------------------+---------------+
          | TBD2    |  Shared BLI TLV          | This document |
          +---------+--------------------------+---------------+

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

      <t/>

      <t/>
    </section>

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-detnet-bounded-latency'?>

      <?rfc ?>

      <?rfc include='reference.I-D.yzz-detnet-enhanced-data-plane'?>
    </references>
  </back>
</rfc>
