<?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-ietf-idr-bgp-ls-sr-policy-path-segment-07"
     ipr="trust200902">
  <front>
    <title abbrev="Path ID and Bi-directional Path in BGP-LS">SR Policies
    Extensions for Path Segment and Bidirectional Path in BGP-LS</title>

    <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>c.l@huawei.com</email>

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

    <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="Yongqing Zhu" initials="Y." surname="Zhu">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>109 West Zhongshan Ave</street>

          <city>Guangzhou</city>

          <region/>

          <code/>

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

        <phone/>

        <facsimile/>

        <email>zhuyq8@chinatelecom.cn</email>

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

    <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

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

        <phone/>

        <facsimile/>

        <email>chengweiqiang@chinamobile.com</email>

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

    <author fullname="Ketan Talaulikar" initials="K." surname=" Talaulikar">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>ketant.ietf@gmail.com</email>

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

    <date day="28" month="August" year="2024"/>

    <area>Routing Area</area>

    <workgroup>Interdomain Routing Working Group</workgroup>

    <abstract>
      <t>This document specifies the way of collecting configuration and
      states of SR policies carrying Path Segment and bidirectional path
      information by using BPG-LS. Such information can be used by external
      conponents for many use cases such as performance measurement, path
      re-optimization and end-to-end protection.</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>Segment routing (SR) <xref target="RFC8402"/> is a source routing
      paradigm that allows the ingress node steers packets into a specific
      path according to the Segment Routing Policy <xref
      target="RFC9256"/>.</t>

      <t>However, the SR Policies defined in <xref target="RFC9256"/> only
      supports unidirectional SR paths and there is no path ID in a Segment
      List to identify an SR path. For identifying an SR path and supporting
      bidirectional path <xref target="RFC9545"/>, new policies carrying Path
      Segment and bidirectional path information are defined in <xref
      target="I-D.ietf-idr-sr-policy-path-segment"/>, as well as the
      extensions to BGP to distribute new SR policies. The Path Segment can be
      a Path Segment in SR-MPLS <xref target="RFC9545"/> and SRv6 <xref
      target="I-D.ietf-spring-srv6-path-segment"/>, or other IDs that can
      identify a path.</t>

      <t>In many network scenarios, the configuration and state of each TE
      Policy is required by a controller which allows the network operator to
      optimize several functions and operations through the use of a
      controller aware of both topology and state information <xref
      target="I-D.ietf-idr-bgp-ls-te-path"/>.</t>

      <t>To collect the TE Policy information that is locally available in a
      router, <xref target="I-D.ietf-idr-bgp-ls-te-path"/> describes a new
      mechanism by using BGP-LS update messages.</t>

      <t>Based on the mechanism defined in <xref
      target="I-D.ietf-idr-bgp-ls-te-path"/>, this document describes a
      mechanism to distribute configuration and states of the new SR policies
      defined in <xref target="I-D.ietf-idr-sr-policy-path-segment"/> to
      external components using BGP-LS.</t>
    </section>

    <section title="Terminology">
      <t>This memo makes use of the terms defined in <xref target="RFC8402"/>
      and <xref target="I-D.ietf-idr-bgp-ls-te-path"/>.</t>
    </section>

    <section title="Carrying SR Path Sub-TLVs in BGP-LS">
      <t>A mechanism to collect states of SR Policies via BGP-LS is proposed
      by <xref target="I-D.ietf-idr-bgp-ls-te-path"/>. The characteristics of
      an SR policy can be described by a TE Policy State TLV, which is carried
      in the optional non-transitive BGP Attribute "LINK_STATE Attribute"
      defined in <xref target="RFC7752"/>. The TE Policy State TLV contains
      several sub-TLVs such as SR TE Policy sub-TLVs.</t>

      <t/>

      <t><xref target="I-D.ietf-idr-sr-policy-path-segment"/> defines the BGP
      extensions for Path Segment. The encoding is shown below.</t>

      <t><figure>
          <artwork align="left"><![CDATA[
   SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
   Attributes:
      Tunnel Encaps Attribute (23)
         Tunnel Type: SR Policy
             Binding SID
             Preference
             Priority
             Policy Name
             Explicit NULL Label Policy (ENLP)
             Segment List
                 Weight
                 Path Segment
                 Segment
                 Segment
                 ...
             Segment List
                 Weight
                 Path Segment
                 Segment
                 Segment
                 ...
             ...

        Figure 1. Path Segment in SR policy
]]></artwork>
        </figure></t>

      <t>Also, <xref target="I-D.ietf-idr-sr-policy-path-segment"/> defines SR
      policy extensions for bidirectional SR path, the encoding is shown
      below:</t>

      <t><figure>
          <artwork align="left"><![CDATA[    SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
        Attributes: Tunnel Encaps Attribute (23)
        Tunnel Type: SR Policy
            Binding SID
            Preference
            Priority
            Policy Name
            Explicit NULL Label Policy (ENLP)
            Segment List 
                Weight
                Path Segment 
                Segment
                Segment
                ...
                Reverse Segment List
                    Weight
                    Path Segment 
                    Segment
                    Segment
                    ...

          Figure 2. SR policy for Bidirectional path
]]></artwork>
        </figure></t>

      <t/>

      <t>In order to collect configuration and states of unidirectional and
      bidirectional SR policies defined in <xref
      target="I-D.ietf-idr-sr-policy-path-segment"/>, this document defines
      new sub-TLVs in SR TE Policy sub-TLVs.</t>

      <t/>

      <section title="SR Path Segment Sub-TLV">
        <t>This section defines the SR Path Segment sub-TLV to describe a Path
        Segment, and it can be included in the Segment List sub-TLV as defined
        in <xref target="I-D.ietf-idr-bgp-ls-te-path"/> . An SR Path Segment
        sub-TLV can be associated with an SR path specified by a Segment List
        sub-TLV. Multiple Path Segment MAY be included in a Segment List for
        different use cases. When all the SID Lists within a candidate path
        share the same Path Segment ID, the Path Segment can be used to
        collect the aggregated information of the candidate path. The format
        of Path Segment TLV is shown below.</t>

        <t><figure>
            <artwork align="center"><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Type           |             Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Flag           |             Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Path Segment ID (4 or 16 octets)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //   Sub-TLVs (variable)                                       //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 3. Path Segment sub-TLV
]]></artwork>
          </figure></t>

        <t>Where,</t>

        <t><list style="symbols">
            <t>Type: to be assigned by IANA.</t>

            <t>Length: the total length of the value field not including Type
            and Length fields.</t>

            <t>Flags: 2 octet field that indicates attribute and status of the
            Path Segment. The following bit positions are defined. Other bits
            SHOULD be cleared by originator and MUST be ignored by
            receiver.</t>
          </list></t>

        <t><figure>
            <artwork align="left"><![CDATA[       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |D|B| |L|                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>Where:</t>

        <t><list style="symbols">
            <t><list style="symbols">
                <t>D-Flag : Indicates the dataplane for the BSIDs, it is set
                when Path Segment ID is a 16-octet SRv6 SID unset when the
                Path Segment ID is a 4-octet SR/MPLS label value.</t>

                <t>B-Flag: This flag, when set, indicates the presence of the
                SRv6 Endpoint Behavior and SID Structure encoding specified in
                <xref target="RFC9514"/>. It MUST be ignored when D-flag is
                unset. They indicate the SRv6 Endpoint behavior and SID
                structure for the Path Segment ID value in the TLV.</t>

                <t>L-Flag: Local flag. Set when the Path Segment has local
                significance on an SR node.</t>
              </list></t>
          </list><list style="symbols">
            <t>RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST
            be ignored by receiver.</t>

            <t>Path Segment ID: It indicates the Path Segment ID value based
            on the status flags.</t>
          </list></t>

        <t>The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure
        TLV (1252) defined in <xref target="RFC9514"/> are used as sub-TLVs of
        the SR Path Segment Sub-TLV to optionally indicate the SRv6 Endpoint
        behavior and SID structure for the Binding SID value in the TLV when
        the Path Segment is an SRv6 Path Segment.</t>

        <t/>
      </section>

      <section title="Reverse Segment List Sub-TLV">
        <t>In some scenarios like mobile backhaul transport network, there are
        requirements to support bidirectional path. In SR, a bidirectional
        path can be represented as a binding of two unidirectional SR paths
        <xref target="RFC9545"/>. An SR policy carrying SR bidirectional path
        information is expressed in Figure 2. <xref
        target="I-D.ietf-idr-sr-policy-path-segment"/> defines a new sub-TLV
        to describe a reversed SR path of an SID list.</t>

        <t/>

        <t>This section defines a Reverse Segment List sub-TLV to specify a
        reverse SR path associated with the path specified by the Segment
        List, and it reuses the format of SR Segment List TLV defined in <xref
        target="I-D.ietf-idr-bgp-ls-te-path"/>:</t>

        <t><figure>
            <artwork align="center"><![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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Flags            |           RESERVED            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MTID              |   Algorithm   |    RESERVED   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Weight (4 octets)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   sub-TLVs (variable)                                        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 5. Reverse Segment List Sub-TLV

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

        <t>All fields, except the type are defined in <xref
        target="I-D.ietf-idr-bgp-ls-te-path"/>, and this TLV reuses it
        directly. The Type of this TLV is TBA.</t>

        <t>The SR Segment sub-TLV <xref target="I-D.ietf-idr-bgp-ls-te-path"/>
        MUST be included as an ordered set of sub-TLVs within the SR Segment
        List TLV when the SID-List is not empty. A SID-List may be empty in
        certain cases (e.g. for a dynamic path) where the headend has not yet
        performed the computation and hence not derived the segments required
        for the path; in such cases, the SR Segment List TLV SHOULD NOT
        include any SR Segment sub-TLVs <xref
        target="I-D.ietf-idr-bgp-ls-te-path"/>.</t>

        <t>Note: currently, only one reverse SID list is supported, so the
        weight field CAN be ignored when processing. However, multiple reverse
        SID list MAY be supported in the future, and the use case of
        supporting this still need to be discussed.</t>

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

    <section title="Operations">
      <t>The operations procedures of <xref target="RFC7752"/> can apply to
      this document.</t>

      <t>Typically but not limited to, the uni/bidirectional SR policies
      carrying path identification information can be distributed by the
      ingress node.</t>

      <t>Generally, BGP-LS is used for collecting link states and
      synchronizing with the external component. The consumer of the
      uni/bidirectional SR policies carrying path identification information
      is not BGP LS process by itself, and it can be any applications such as
      performance measurement <xref target="I-D.ietf-spring-stamp-srpm"/> and
      path re-coputation or re-optimization, etc. The operation of sending
      information to other precesses is out of scope of this document.</t>
    </section>

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

      <section title="BGP-LS TLVs">
        <t>IANA maintains a registry called "Border Gateway Protocol - Link
        State (BGP-LS) Parameters" with a sub-registry called "Node Anchor,
        Link Descriptor and Link Attribute TLVs". The following TLV codepoints
        are suggested (for early allocation by IANA):</t>

        <t><figure>
            <artwork><![CDATA[          Codepoint   Description                           Reference
          -------------------------------------------------------------
          TBA        Path Segment sub-TLV                  This document
          TBA        Reverse Segment List sub-TLV          This document

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

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

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

    <section title="Contributors">
      <t><figure>
          <artwork><![CDATA[
   Mach(Guoyi) Chen
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: Mach.chen@huawei.com


   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: jie.dong@huawei.com


   James N Guichard
   Futurewei Technologies
   2330 Central Express Way
   Santa Clara
   USA

   Email: james.n.guichard@futurewei.com


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

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Many thanks to Shraddha Hedge for her detailed review and
      professional comments.</t>

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

  <back>
    <references title="Normative References">
      <?rfc ?>

      <?rfc ?>

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

      <?rfc include='reference.I-D.ietf-idr-bgp-ls-te-path'?>

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

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

      <?rfc include='reference.I-D.ietf-spring-srv6-path-segment'?>

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

      <?rfc include="reference.RFC.7752"?>

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

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-spring-stamp-srpm'?>

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

      <?rfc ?>

      <?rfc ?>

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