<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-idr-sr-policy-safi-13" number="9830" ipr="trust200902" updates="9012"> consensus="true" updates="9012" obsoletes="" submissionType="IETF" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" tocDepth="3" version="3">

  <front>
    <title abbrev="Segment Routing Policies in BGP">Advertising Segment
    Routing Policies in BGP</title>
    <seriesInfo name="RFC" value="9830"/>
    <author fullname="Stefano Previdi" initials="S." surname="Previdi">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country>IT</country>
          <country>Italy</country>
        </postal>
        <email>stefano@previdi.net</email>
      </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <city>Brussels</city>

          <region/>

          <code/>

          <country>BE</country>
          <country>Belgium</country>
        </postal>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Paul Mattes" initials="P." surname="Mattes">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>WA</region>
          <code>98052</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>pamattes@microsoft.com</email>
      </address>
    </author>
    <author fullname="Dhanendra Jain" initials="D." surname="Jain">
      <organization>Google</organization>
      <address>
        <email>dhanendra.ietf@gmail.com</email>
      </address>
    </author>

    <date/>
    <date month="July" year="2025"/>
    <area>RTG</area>
    <workgroup>idr</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>A Segment Routing (SR) Policy is an ordered list of segments (also
      referred to as instructions) "instructions") that define a source-routed policy. An SR
      Policy consists of one or more candidate paths, each comprising one or
      more segment lists. A headend can be provisioned with these candidate
      paths using various mechanisms, mechanisms such as CLI, NETCONF, PCEP, Command-Line Interface (CLI), Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP.</t>
      <t>This document specifies how BGP can be used to distribute SR Policy
      candidate paths. It introduces a BGP SAFI for advertising a candidate
      path of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation
      Attribute to signal information related to these candidate paths.</t>
      <t>Furthermore, this document updates RFC9012 RFC 9012 by extending the Color
      Extended Community to support additional steering modes over SR
      Policy.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="INTRO" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Segment Routing (SR) <xref target="RFC8402"/> target="RFC8402" format="default"/> allows a headend node
      to steer a packet flow along a specific path. Intermediate per-path
      states are eliminated thanks to source routing.</t>
      <t>The headend node is said to steer a flow into an SR Policy <xref
      target="RFC9256"/>.</t> target="RFC9256" format="default"/>.</t>
      <t>The packets steered into an SR Policy carry an ordered list of
      segments associated with that SR Policy.</t>
      <t><xref target="RFC9256"/> target="RFC9256" format="default"/> further details the concepts of SR Policy
      and steering into an SR Policy. These apply equally to the SR-MPLS and
      Segment Routing for IPv6 (SRv6) data-plane data plane instantiations of Segment
      Routing using SR-MPLS and SRv6 Segment Identifiers (SIDs) as described
      in <xref target="RFC8402"/>. target="RFC8402" format="default"/>. <xref target="RFC8660"/> target="RFC8660" format="default"/> describes the
      representation and processing of this ordered list of segments as an
      MPLS label stack for SR-MPLS. While <xref target="RFC8754"/> target="RFC8754" format="default"/> and <xref
      target="RFC8986"/> target="RFC8986" format="default"/> describe the same for SRv6 with the use of the
      Segment Routing Header (SRH).</t>
      <t>The functionality related to SR Policy related functionality described in <xref
      target="RFC9256"/> target="RFC9256" format="default"/> can be conceptually viewed as being incorporated in
      an SR Policy Module (SRPM). Following The following is a reminder of the high-level
      functionality of SRPM: <list style="symbols"> </t>
      <ul spacing="normal">
        <li>
          <t>Learning multiple candidate paths (CP) (CPs) for an SR Policy via
          various mechanisms (CLI, NETCONF, PCEP, or BGP).</t>
        </li>
        <li>
          <t>Selection of the best candidate path for an SR Policy.</t>
        </li>
        <li>
          <t>Associating a Binding SID (BSID) to the selected candidate path
          of an SR Policy.</t>
        </li>
        <li>
          <t>Installation of the selected candidate path and its BSID in the
          forwarding plane.</t>
        </list></t>
        </li>
      </ul>
      <t>This document specifies the use of BGP to distribute one or more of
      the candidate paths of an SR Policy to the headend of that policy. SR Policy. The
      document describes the functionality provided by BGP and, as
      appropriate, provides references for the functionality functionality, which is outside
      the scope of BGP (i.e. (i.e., resides within SRPM on the headend node).</t>
      <t>This document specifies a way of representing SR Policy candidate
      paths in BGP UPDATE messages. BGP can then be used to propagate the SR
      Policy candidate paths to the headend nodes in a network. The usual BGP
      rules for BGP propagation and best-path selection are used. At the
      headend of a specific policy, this will result in one or more candidate
      paths being installed into the "BGP table". These paths are then passed
      to the SRPM. The SRPM may compare them to candidate paths learned via
      other mechanisms and will choose one or more paths to be installed in
      the data plane. BGP itself does not install SR Policy candidate paths
      into the data plane.</t>
      <t>This document introduces a BGP subsequent address family Subsequent Address Family Identifier (SAFI) for
      IPv4 and IPv6 address families. In UPDATE messages of those AFI/SAFIs,
      the Network Layer Reachability Information (NLRI) identifies an SR
      Policy Candidate Path while the attributes encode the segment lists and
      other details of that SR Policy Candidate Path.</t>

      <t>While
      <t>While, for simplicity simplicity, the text in this document states that BGP
      advertises an SR Policy, it is to be understood that BGP advertises a
      candidate path of an SR policy and that this SR Policy might have
      several other candidate paths provided via BGP (via an NLRI with a
      different distinguisher as defined in <xref target="SRPOLICYSAFI"/>), target="SRPOLICYSAFI" format="default"/>),
      PCEP, NETCONF, or local policy configuration.</t>
      <t>Typically, a an SR Policy Controller <xref target="RFC9256"/> target="RFC9256" format="default"/> defines
      the set of policies and advertises them to policy headend routers
      (typically ingress routers). These policy advertisements use the BGP
      extensions defined in this document. In most cases, the policy
      advertisement is tailored for a specific policy headend; consequently,
      it may be transmitted over a direct BGP session (i.e., without
      intermediate BGP hops) to that headend and is not propagated any
      further. In such cases, the policy advertisements will not traverse any
      Route Reflector (RR, <xref target="RFC4456"/>) (RR) (see <xref
      target="PROPAGATE"/>).</t> target="RFC4456" format="default"/> and <xref target="PROPAGATE" format="default"/>).</t>

<!--[rfced] Should "itself" be "themselves"?  If neither of the
     following capture your intended meaning, please rephrase.

Original:
   Alternatively, a BGP egress router may advertise SR Policies that
   represent paths terminating on itself.

Perhaps A:
   Alternatively, a BGP egress router may advertise SR Policies that
   represent paths terminating on themselves.

Perhaps B:
   Alternatively, a BGP egress router may advertise SR Policies that
   represent paths that terminate on it.

-->

      <t>Alternatively, a BGP egress router may advertise SR Policies that
      represent paths terminating on itself. In such cases, the router can
      send these policies directly to each headend over a dedicated BGP
      session, without necessitating any further propagation of the
      policy.</t>
      <t>In some situations, it is undesirable for a controller or BGP egress
      router to have a BGP session to each policy headend. In these
      situations, BGP Route Reflectors may be used to propagate the
      advertisements. In certain other deployments, it may be necessary for
      the advertisement to propagate through a sequence of one or more ASes Autonomous Systems (ASes)
      within an SR Domain (refer to <xref target="Security"/> target="Security" format="default"/> for the
      associated security considerations). To make this possible, an attribute
      needs to be attached to the advertisement that enables a BGP speaker to
      determine whether it is intended to be a headend for the advertised
      policy. This is done by attaching one or more Route Target Extended
      Communities to the advertisement <xref target="RFC4360"/>.</t> target="RFC4360" format="default"/>.</t>
      <t>The BGP extensions for the advertisement of SR Policies include
      following components: <list style="symbols"> </t>
      <ul spacing="normal">
        <li>
          <t>A Subsequent Address Family Identifier (SAFI) whose NLRIs
          identifies
          identify an SR Policy candidate path.</t>
        </li>
        <li>
          <t>A Tunnel Type identifier for SR Policy, Policy and a set of sub-TLVs to
          be inserted into the Tunnel Encapsulation Attribute (as defined in
          <xref target="RFC9012"/>) target="RFC9012" format="default"/>) specifying segment lists of the SR Policy
          candidate path, path as well as other information about the SR
          Policy.</t>
        </li>
        <li>
          <t>One or more IPv4 address-specific format route target extended
          community (<xref target="RFC4360"/>) target="RFC4360" format="default"/>) attached to the SR Policy
          Candidate Path advertisement and that indicates the intended headend
          of such an SR Policy Candidate Path advertisement.</t>
        </list></t>
        </li>
      </ul>
      <t>The SR Policy SAFI route updates utilize the Tunnel Encapsulation
      Attribute to signal an SR Policy, which itself functions as a tunnel.
      This usage differs notably from the approach described in <xref
      target="RFC9012"/>, target="RFC9012" format="default"/>, where the Tunnel Encapsulation Attribute is
      associated with a BGP route update (e.g., for Internet or VPN routes) to
      specify the tunnel used for forwarding traffic. This document does not
      modify or supersede the usage of the Tunnel Encapsulation Attribute for
      existing AFI/SAFIs AFIs/SAFIs as defined in <xref target="RFC9012"/>. target="RFC9012" format="default"/>. Details
      regarding the processing of the Tunnel Encapsulation Attribute for the
      SR Policy SAFI are provided in Sections <xref target="ENCAPSATTR"/> target="ENCAPSATTR" format="counter"/> and <xref
      target="ENDCOLOR"/>.</t> target="ENDCOLOR" format="counter"/>.</t>
      <t>The northbound advertisement of the operational state of the SR
      Policy Candidate Paths as part of BGP-LS BGP - Link State (BGP-LS) <xref target="RFC9552"/> target="RFC9552" format="default"/>
      topology information is specified in <xref
      target="I-D.ietf-idr-bgp-ls-sr-policy"/>.</t> target="I-D.ietf-idr-bgp-ls-sr-policy" format="default"/>.</t>
      <t>The signaling of Dynamic and Composite Candidate Paths (sections 5.2 (Sections
      <xref target="RFC9256" sectionFormat="bare" section="5.2"/> and 5.3 respectively <xref
      target="RFC9256" sectionFormat="bare" section="5.3"/>, respectively, of
      <xref target="RFC9256"/>) target="RFC9256" format="default"/>) is outside the scope of this
      document.</t>
      <t>The Color Extended Community (as defined in <xref target="RFC9012"/>) target="RFC9012"
      format="default"/>) is used to steer traffic into an SR Policy, as
      described in section 8.8
      of <xref target="RFC9256"/>. The target="RFC9256" sectionFormat="of"
      section="8.8"/>. <xref target="EXTCOLOR"/> target="EXTCOLOR" format="default"/> of this
      document updates <xref target="RFC9012"/> target="RFC9012" format="default"/> with
      modifications to the format of the Flags field of the Color Extended
      Community by using the two leftmost bits of that field.</t>
      <section title="Requirements Language">
        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="ENCODING" title="SR numbered="true" toc="default">
      <name>SR Policy Encoding"> Encoding</name>
      <section anchor="SRPOLICYSAFI" title="SR numbered="true" toc="default">
        <name>SR Policy SAFI and NLRI">
        <t>A NLRI</name>
        <t>The SR Policy SAFI with
        code point 73 is introduced in this document: the SR Policy SAFI with
        codepoint 73. document. The AFI used MUST <bcp14>MUST</bcp14> be IPv4(1) or IPv6(2).</t>
        <t>The SR Policy SAFI uses the NLRI format defined as follows: <figure
            align="center"> </t>

<figure>
  <name>SR Policy SAFI Format</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
+------------------+
|  NLRI Length     | 1 octet
+------------------+
|  Distinguisher   | 4 octets
+------------------+
|  Policy Color    | 4 octets
+------------------+
|  Endpoint        | 4 or 16 octets
+------------------+

Figure 1: SR Policy SAFI Format

where:
]]></artwork>
          </figure><list style="symbols">
            <t>NLRI Length: 1
	</figure>

	<t>Where:</t>
        <dl spacing="normal">
          <dt>NLRI Length:</dt><dd>1 octet indicating the length expressed in bits as
          defined in <xref target="RFC4760"/>. target="RFC4760" format="default"/>. When AFI = 1 1,
          the value MUST <bcp14>MUST</bcp14> be 96 and 96; when AFI = 2 2, the value MUST
          <bcp14>MUST</bcp14> be 192.</t>

            <t>Distinguisher: 4-octet 192.</dd>

<!--[rfced] The following sentence is long and difficult to parse.  In
     particular, what is being made unique?  How may we rephrase?

Original:
The distinguisher has no semantic value and is solely used by the SR
Policy originator to make unique (from an NLRI perspective) both for
multiple candidate paths of the same SR Policy as well as candidate
paths of different SR Policies (i.e. with different segment lists)
with the same Color and Endpoint but meant for different headends.

-->

          <dt>Distinguisher:</dt><dd>4-octet value uniquely identifying the policy in
          the context of &lt;color, endpoint&gt; tuple. The distinguisher has
          no semantic value and is solely used by the SR Policy originator to
          make unique (from an NLRI perspective) both for multiple candidate
          paths of the same SR Policy as well as candidate paths of different
          SR Policies (i.e. (i.e., with different segment lists) with the same Color
          and Endpoint but meant for different headends. The distinguisher is
          the discriminator of the SR Policy candidate path as specified in section 2.5 of
          <xref
            target="RFC9256"/>.</t>

            <t>Policy Color: 4 target="RFC9256" sectionFormat="of" section="2.5"/>.</dd>
          <dt>Policy Color:</dt><dd>4 octets that carry an unsigned non-zero integer
          value indicating the color of the SR Policy as specified in
            section 2.1 of <xref target="RFC9256"/>.
          target="RFC9256" sectionFormat="of" section="2.1"/>. The color is
          used to match the color of the destination prefixes to steer traffic
          into the SR Policy as specified in section 8 of <xref
            target="RFC9256"/>.</t>

            <t>Endpoint: target="RFC9256"
          sectionFormat="of" section="8"/>.</dd>
          <dt>Endpoint:</dt><dd>a value that identifies the endpoint of a policy. The
          Endpoint may represent a single node or a set of nodes (e.g., an
          anycast address). The Endpoint is an IPv4 (4-octet) address or an
          IPv6 (16-octet) address according to the AFI of the NLRI. The
          address can be either a unicast or an unspecified address (0.0.0.0
          for IPv4, :: for IPv6), known as a null endpoint, endpoint as specified in
            section 2.1 of
          <xref target="RFC9256"/>.</t>
          </list></t> target="RFC9256" sectionFormat="of" section="2.1"/>.</dd>
        </dl>

        <t>The color and endpoint are used to automate the steering of BGP
        service routes on an SR Policy as described in section 8 of <xref
        target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="8"/>.</t>
        <t>The NLRI containing an SR Policy candidate path is carried in a BGP
        UPDATE message <xref target="RFC4271"/> target="RFC4271" format="default"/> using BGP multi-protocol multiprotocol
        extensions <xref target="RFC4760"/> target="RFC4760" format="default"/> with an AFI of 1 or 2 (IPv4 or
        IPv6) and with a SAFI of 73. The fault management and error handling
        in the encoding of the NLRI is are specified in <xref
        target="ERROR"/>.</t> target="ERROR" format="default"/>.</t>
        <t>An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI
        attribute with the SR Policy SAFI MUST <bcp14>MUST</bcp14> also carry the BGP mandatory
        attributes. In addition, the BGP update message MAY <bcp14>MAY</bcp14> also contain any
        of the BGP optional attributes.</t>
        <t>The next-hop network address field in SR Policy SAFI (73) updates
        may be either a 4-octet IPv4 address or a 16-octet IPv6 address,
        independent of the SR Policy AFI. The length field of the next-hop
        address specifies the next-hop address family. If the next-hop length
        is 4, then the next-hop is an IPv4 address; if address. If the next-hop length is
        16, then it is a global IPv6 address; if address.  If the next-hop length is 32,
        then it has a global IPv6 address followed by a link-local IPv6
        address. The setting of the next-hop field and its attendant
        processing is governed by standard BGP procedures as described in
        section 3 of
        <xref target="RFC4760"/> target="RFC4760" sectionFormat="of" section="3"/> and section 3 of <xref
        target="RFC2545"/>.</t> target="RFC2545" sectionFormat="of" section="3"/>.</t>
        <t>It is important to note that at any BGP speaker receiving BGP
        updates with SR Policy NLRIs, the SRPM processes only the best path as
        per the BGP best-path selection algorithm. In other words, this
        document leverages the existing BGP propagation and best-path
        selection rules. Details of the procedures are described in <xref
        target="OPERATIONS"/>.</t> target="OPERATIONS" format="default"/>.</t>
        <t>It has to be noted that if several candidate paths of the same SR
        Policy (endpoint, color) are signaled via BGP to a headend, then it is
        RECOMMENDED
        <bcp14>RECOMMENDED</bcp14> that each NLRI uses use a different distinguisher. If BGP has
        installed into the BGP table two advertisements whose respective NLRIs
        have the same color and endpoint, but different distinguishers, both
        advertisements are passed to the SRPM as different candidate paths
        along with their respective originator information (i.e., ASN Autonomous System Number (ASN) and BGP
        Router-ID) as described in section 2.4 of <xref target="RFC9256"/>. target="RFC9256" sectionFormat="of" section="2.4"/>.
        The ASN would be the ASN of the origin and the BGP Router-ID is
        determined in the following order:<list style="symbols"> order:</t>
        <ul spacing="normal">
          <li>
            <t>From the Route Origin Community <xref target="RFC4360"/> target="RFC4360" format="default"/> if
            present and carrying an IP Address, or</t>
          </li>
          <li>

<!-- [rfced] We note that [RFC4456] uses the term "ORIGINATOR_ID"
     rather than "Originator ID". Please review and let us know if any
     updates are necessary. -->
            <t>As the BGP Originator ID <xref target="RFC4456"/> target="RFC4456" format="default"/> if present,
            or</t>
          </li>
          <li>
            <t>As the BGP Router-ID of the peer from which the update was
            received as a last resort.</t>
          </list></t>

        <t>The Section 2.9 of <xref target="RFC9256"/>
          </li>
        </ul>
        <t><xref target="RFC9256" sectionFormat="of" section="2.9"/> specifies the selection
        of the active candidate path of the SR Policy by the SRPM based on the
        information provided to it by BGP.</t>
      </section>
      <section anchor="ENCAPSATTR"
               title="SR numbered="true" toc="default">
        <name>SR Policy and Tunnel Encapsulation Attribute"> Attribute</name>

        <t>The content of the SR Policy Candidate Path is encoded in the
        Tunnel Encapsulation Attribute defined in <xref target="RFC9012"/> target="RFC9012" format="default"/>
        using a Tunnel-Type called SR Policy Type the "SR Policy" type with codepoint code point 15. The use
        of the SR Policy Tunnel-type is applicable only for the AFI/SAFI pairs of
        (1/73, 2/73). This document specifies the use of the Tunnel
        Encapsulation Attribute with the SR Policy Tunnel-Type and the use of
        any other Tunnel-Type with the SR Policy SAFI MUST <bcp14>MUST</bcp14> be considered
        malformed and handled by the "Treat-as-Withdraw" "treat-as-withdraw" strategy <xref
        target="RFC7606"/>.</t> target="RFC7606" format="default"/>.</t>
        <t>The SR Policy Encoding structure is as follows: <figure
            align="center"> </t>

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

Figure 2:
]]></artwork>
	</figure>

	<t>Where:</t>
        <ul spacing="normal">
	  <li>
            <t>The SR Policy Encoding

where:]]></artwork>
          </figure><list style="symbols">
            <t>SR Policy SAFI NLRI is defined in <xref
            target="SRPOLICYSAFI"/>.</t>

            <t>Tunnel target="SRPOLICYSAFI" format="default"/>.</t>
          </li>
          <li>
            <t>The Tunnel Encapsulation Attribute is defined in <xref
            target="RFC9012"/>.</t>

            <t>Tunnel-Type target="RFC9012" format="default"/>.</t>
          </li>
          <li>
            <t>The Tunnel-Type is set to 15.</t>
          </li>
          <li>
            <t>Preference, Binding SID, Priority, Policy Name, Policy
            Candidate Path Name, ENLP, Segment-List, Weight, and Segment
            sub-TLVs are defined in <xref target="SRPOLICYTLV"/>.</t> target="SRPOLICYTLV" format="default"/>.</t>
          </li>
          <li>
            <t>Additional sub-TLVs may be defined in the future.</t>
          </list></t>
          </li>
        </ul>

        <t>A Tunnel Encapsulation Attribute MUST NOT <bcp14>MUST NOT</bcp14> contain more than one TLV
        of type "SR Policy"; such updates MUST <bcp14>MUST</bcp14> be considered malformed and
        handled by the "Treat-as-Withdraw" "treat-as-withdraw" strategy <xref
        target="RFC7606"/>.</t> target="RFC7606" format="default"/>.</t>
        <t>BGP does not need to perform the validation of the tunnel (i.e., SR
        Policy) itself as indicated in section 6 of <xref target="RFC9012"/>. target="RFC9012" sectionFormat="of" section="6"/>.
        The validation of the SR Policy information that is advertised using
        the sub-TLVs specified in <xref target="SRPOLICYTLV"/> target="SRPOLICYTLV" format="default"/> is performed by
        the SRPM.</t>
      </section>
      <section anchor="ENDCOLOR"
               title="Applicability numbered="true" toc="default">
        <name>Applicability of Tunnel Encapsulation Attribute Sub-TLVs"> Sub-TLVs</name>
        <t>The Tunnel Egress Endpoint and Color sub-TLVs of the Tunnel
        Encapsulation Attribute, as defined in <xref target="RFC9012"/>, target="RFC9012" format="default"/>, are
        not utilized for SR Policy encodings. Consequently, their values are
        not relevant within the context of the SR Policy SAFI NLRI. If these
        sub-TLVs are present, a BGP speaker MUST <bcp14>MUST</bcp14> ignore them and MAY <bcp14>MAY</bcp14> remove
        them from the Tunnel Encapsulation Attribute during propagation.</t>
        <t>Similarly, any other sub-TLVs, including those specified in <xref
        target="RFC9012"/>, target="RFC9012" format="default"/>, that do not have explicitly defined applicability
        to the SR Policy SAFI MUST <bcp14>MUST</bcp14> be ignored by the BGP speaker and MAY <bcp14>MAY</bcp14> be
        removed from the Tunnel Encapsulation Attribute during
        propagation.</t>
      </section>
      <section anchor="SRPOLICYTLV" title="SR numbered="true" toc="default">
        <name>SR Policy Sub-TLVs"> Sub-TLVs</name>
        <t>This section specifies the sub-TLVs defined for encoding the
        information about the SR Policy Candidate Path.</t>
        <t>Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority,
        Policy Name, Policy Candidate Path Name, and Explicit NULL Label
        Policy are all optional sub-TLVs introduced for the BGP Tunnel
        Encapsulation Attribute <xref target="RFC9012"/> target="RFC9012" format="default"/> being defined in this
        section.</t>
        <t>Weight and Segment are sub-TLVs of the Segment-List sub-TLV
        mentioned above.</t>
        <t>An early draft version of this document included only the Binding SID
        sub-TLV that could be used for both SR-MPLS and SRv6 Binding SIDs. The
        SRv6 Binding SID TLV was introduced in later versions to support the
        advertisement of additional SRv6 capabilities without affecting
        backward compatibility for early implementations.</t>
        <t>The fault management and error handling in the encoding of the
        sub-TLVs defined in this section are specified in <xref
        target="ERROR"/>. target="ERROR" format="default"/>. For the TLVs/sub-TLVs that are specified as single
        instance, only the first instance of that TLV/sub-TLV is used and used: the
        other instances MUST <bcp14>MUST</bcp14> be ignored and MUST NOT <bcp14>MUST NOT</bcp14> considered to be
        malformed.</t>
        <t>None of the sub-TLVs defined in the following sub-sections subsections have any
        effect on the BGP best-path selection or propagation procedures. These
        sub-TLVs are not used by the BGP path selection process and are
        instead passed on to SRPM as SR Policy Candidate Path information for
        further processing as described in section 2 of <xref
        target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="2"/>.</t>
        <t>The use of SR Policy Sub-TLVs is applicable only for the AFI/SAFI
        pairs of (1/73, 2/73). Future documents may extend their applicability
        to other AFI/SAFI.</t>
        <section anchor="PREFTLV" title="Preference Sub-TLV"> numbered="true" toc="default">
          <name>Preference Sub-TLV</name>
          <t>The Preference sub-TLV is used to carry the Preference of an SR
          Policy candidate path. The contents of this sub-TLV are used by the
          SRPM as described in section 2.7 of <xref target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="2.7"/>.</t>
          <t>The Preference sub-TLV is OPTIONAL and <bcp14>OPTIONAL</bcp14>; it MUST NOT <bcp14>MUST NOT</bcp14> appear more
          than once in the SR Policy encoding.</t>
          <t>The Preference sub-TLV has the following format: <figure
              align="center"> </t>

	  <figure>
	    <name>Preference Sub-TLV</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Preference (4 octets)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Preference sub-TLV

where:
]]></artwork>
            </figure><list style="symbols">
              <t>Type: 12</t>

              <t>Length: Specifies
	  </figure>

	  <t>Where:</t>
          <dl spacing="normal">

              <dt>Type:</dt><dd>12</dd>

            <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
              including Type and Length fields) in terms of octets. The value
              MUST
              <bcp14>MUST</bcp14> be 6.</t>

              <t>Flags: 1 6.</dd>

              <dt>Flags:</dt><dd>1 octet of flags. No flags are defined in this
              document. The Flags field MUST <bcp14>MUST</bcp14> be set to zero on transmission
              and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

              <t>RESERVED: 1 receipt.</dd>

              <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST <bcp14>MUST</bcp14> be set to
              zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

              <t>Preference: a receipt.</dd>

              <dt>Preference:</dt><dd>a 4-octet value indicating the Preference of the
              SR Policy Candidate Path as described in section 2.7 of <xref
              target="RFC9256"/>.</t>
            </list></t> target="RFC9256" sectionFormat="of" section="2.7"/>.</dd>

          </dl>

        </section>
        <section anchor="BINDINGSIDTLV" title="Binding numbered="true" toc="default">
          <name>Binding SID Sub-TLV"> Sub-TLV</name>
          <t>The Binding SID sub-TLV is used to signal the binding SID related BSID-related
          information of the SR Policy candidate path. The contents of this
          sub-TLV are used by the SRPM as described in section 6 in <xref
          target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="6"/>.</t>
          <t>The Binding SID sub-TLV is OPTIONAL and <bcp14>OPTIONAL</bcp14>; it MUST NOT <bcp14>MUST NOT</bcp14> appear more
          than once in the SR Policy encoding.</t>
          <t>When the Binding SID sub-TLV is used to signal an SRv6 SID, the
          selection of the corresponding SRv6 Endpoint Behavior <xref
          target="RFC8986"/> target="RFC8986" format="default"/> to be instantiated is determined by the headend
          node. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the SRv6 Binding SID sub-TLV, as
          defined in Section 2.4.3, <xref target="SRV6BINDINGSIDTLV" format="default"/>, be used when signaling an SRv6 Binding SID
          for an SR Policy candidate path. The support for the use of this
          Binding SID sub-TLV for the signaling of an SRv6 Binding SID is retained
          primarily for backward compatibility with implementations that
          followed early draft versions of this document that had not defined the
          SRv6 Binding SID sub-TLV.</t>
          <t>The Binding SID sub-TLV has the following format: <figure
              align="center"> </t>

	  <figure>
	    <name>Binding SID Sub-TLV</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Binding SID (variable, optional)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Binding SID sub-TLV

where:
]]></artwork>
            </figure><list style="symbols">
              <t>Type: 13</t>

              <t>Length: Specifies
</figure>
	  <t>Where:</t>
          <dl spacing="normal">
              <dt>Type:</dt><dd>13</dd>
              <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
              including Type and Length fields) in terms of octets. The value
              MUST
              <bcp14>MUST</bcp14> be one of: 18 when a SRv6 BSID is present, 6 when a an SR-MPLS
              BSID is present, or 2 when no BSID is present.</t>

              <t>Flags: 1 present.</dd>
              <dt>Flags:</dt><dd><t>1 octet of flags. The following flags are defined in
              the registry "SR Policy Binding SID Flags" as described in <xref
              target="IANABSIDFLAGS"/>: <figure align="center"> target="IANABSIDFLAGS" format="default"/>:</t>

<figure>
  <name>SR Policy Binding SID Flags</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|I|           |
+-+-+-+-+-+-+-+-+

Figure 5: SR Policy Binding SID Flags
]]></artwork>
                </figure>where:<list>
                  <t>S-Flag: This flag
</figure>
              <t>Where:</t>
              <ul spacing="normal">

                  <li>The S-Flag encodes the "Specified-BSID-only" "Specified-BSID-Only"
                  behavior. It is used by SRPM as described in section 6.2.3
                  in <xref target="RFC9256"/>.</t>

                  <t>I-Flag: This flag
                  target="RFC9256" sectionFormat="of" section="6.2.3"/>.</li>
                  <li>The I-Flag encodes the "Drop Upon Invalid"
                  behavior. It is used by SRPM as described in section 8.2 in <xref target="RFC9256"/>
                  target="RFC9256" sectionFormat="of" section="8.2"/> to
                  define a specific SR Policy forwarding behavior. The flag
                  indicates that the SR Policy is to perform the "drop upon
                  invalid" behavior when no valid candidate path (CP) is
                  available for this SR Policy. In this situation, the CP with
                  the highest preference amongst those with the "drop upon
                  invalid" config is made active to drop traffic steered over
                  the SR Policy.</t>

                  <t>The Policy.</li>

                  <li>The unassigned bits in the Flag octet MUST <bcp14>MUST</bcp14> be set to zero
                  upon transmission and MUST <bcp14>MUST</bcp14> be ignored upon receipt.</t>
                </list></t>

              <t>RESERVED: 1 receipt.
                </li>
              </ul></dd>

              <dt>RESERVED:</dt><dd>1 octet of reserved bits. MUST <bcp14>MUST</bcp14> be set to zero on
              transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

              <t>Binding SID: If receipt.
            </dd>

              <dt>Binding SID:</dt><dd><t>If the length is 2, then no Binding SID is
              present. If the length is 6 6, then the Binding SID is encoded in 4
              octets using the format below. Traffic Class (TC), S, and TTL
              (Total of 12 bits) are RESERVED and MUST <bcp14>MUST</bcp14> be set to zero and MUST <bcp14>MUST</bcp14>
              be ignored. ignored.</t>

<figure>
                  <artwork><![CDATA[
  <name>Binding SID Label Encoding</name>
              <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Label                        | TC  |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: Binding SID Label Encoding
]]></artwork>
                </figure>The
</figure>
              <t>The Label field is validated by the SRPM, SRPM but MUST
              NOT <bcp14>MUST
              NOT</bcp14> contain the reserved MPLS label values (0-15). If the length
              is 18 18, then the Binding SID contains a 16-octet SRv6 SID.</t>
            </list></t>
            </dd>
          </dl>
        </section>
        <section anchor="SRV6BINDINGSIDTLV" title="SRv6 numbered="true" toc="default">
          <name>SRv6 Binding SID Sub-TLV"> Sub-TLV</name>
          <t>The SRv6 Binding SID sub-TLV is used to signal the SRv6 Binding
          SID related information of an SR Policy candidate path. It enables
          the specification of the SRv6 Endpoint Behavior <xref
          target="RFC8986"/>
          target="RFC8986" format="default"/> to be instantiated on the
          headend node. The contents of this sub-TLV are used by the SRPM as
          described in
          section 6 in <xref target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of"
          section="6"/>.</t>
          <t>The SRv6 Binding SID sub-TLV is OPTIONAL. <bcp14>OPTIONAL</bcp14>. More than one SRv6
          Binding SID sub-TLVs MAY sub-TLV <bcp14>MAY</bcp14> be signaled in the same SR Policy encoding
          to indicate one or more SRv6 SIDs, each with potentially different
          SRv6 Endpoint Behaviors to be instantiated.</t>
          <t>The SRv6 Binding SID sub-TLV has the following format: <figure
              align="center"> format:</t>

<figure>
  <name>SRv6 Binding SID Sub-TLV</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 SRv6 Binding SID (16 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//     SRv6 Endpoint Behavior and SID Structure (optional)     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: SRv6 Binding SID sub-TLV

where:
]]></artwork>
            </figure><list style="symbols">
              <t>Type: 20</t>

              <t>Length: Specifies
</figure>

	  <t>Where:</t>
          <dl spacing="normal">

              <dt>Type:</dt><dd>20</dd>

              <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
              including Type and Length fields) in terms of octets. The value
              MUST
              <bcp14>MUST</bcp14> be 26 when the SRv6 Endpoint Behavior and SID Structure is
              present else
              present; else, it MUST <bcp14>MUST</bcp14> be 18.</t>

              <t>Flags: 1 18.</dd>

              <dt>Flags:</dt><dd><t>1 octet of flags. The following flags are defined in
              the registry "SR Policy SRv6 Binding SID Flags" as described in
              <xref target="IANASRV6BSIDFLAGS"/>: <figure align="center"> target="IANASRV6BSIDFLAGS" format="default"/>:</t>

<figure>
  <name>SR Policy SRv6 Binding SID Flags</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|I|B|         |
+-+-+-+-+-+-+-+-+

Figure 8: SR Policy SRv6 Binding SID Flags
]]></artwork>
</figure> where:<list>
                  <t>S-Flag: This flag
              <t>Where:</t>
              <ul spacing="normal">
                  <li>The S-Flag encodes the "Specified-BSID-only" "Specified-BSID-Only"
                  behavior. It is used by SRPM as described
                  in section 6.2.3
                  in <xref target="RFC9256"/>.</t>

                  <t>I-Flag: This flag target="RFC9256" sectionFormat="of" section="6.2.3"/>.</li>

                  <li>The I-Flag encodes the "Drop Upon Invalid"
                  behavior. It is used by SRPM as described in section 8.2 in
                  <xref target="RFC9256"/>.</t>

                  <t>B-Flag: This flag, target="RFC9256" sectionFormat="of" section="8.2"/>.</li>

                  <li>The B-Flag, when set, indicates the presence of
                  the SRv6 "SRv6 Endpoint Behavior and &amp; SID Structure Structure" encoding
                  specified in <xref target="BEHAVIORSTRUCT"/>.</t>

                  <t>The target="BEHAVIORSTRUCT" format="default"/>.</li>

                  <li>The unassigned bits in the Flag octet MUST <bcp14>MUST</bcp14> be set to zero
                  upon transmission and MUST <bcp14>MUST</bcp14> be ignored upon receipt.</t>
                </list></t>

              <t>RESERVED: 1 receipt.</li>

              </ul></dd>

              <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST <bcp14>MUST</bcp14> be set to
              zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

              <t>SRv6 receipt.</dd>

              <dt>SRv6 Binding SID: Contains SID:</dt><dd>Contains a 16-octet SRv6 SID. The value 0
              MAY
              <bcp14>MAY</bcp14> be used when the controller wants to indicate the desired
              SRv6 Endpoint Behavior, SID Structure, or flags without
              specifying the BSID.</t>

              <t>SRv6 BSID.</dd>

              <dt>SRv6 Endpoint Behavior and SID Structure: Optional, Structure:</dt><dd>Optional, as
              defined in <xref target="BEHAVIORSTRUCT"/>. target="BEHAVIORSTRUCT" format="default"/>. The SRv6 Endpoint
              Behavior and SID Structure MUST NOT <bcp14>MUST NOT</bcp14> be included when the SRv6
              SID has not been included.</t>
            </list></t> included.</dd>

          </dl>
        </section>
        <section anchor="SLTLV" title="Segment numbered="true" toc="default">
          <name>Segment List Sub-TLV "> Sub-TLV</name>
          <t>The Segment List sub-TLV encodes a single explicit path towards
          the endpoint as described in section 5.1 of <xref
          target="RFC9256"/>. target="RFC9256"
          sectionFormat="of" section="5.1"/>. The Segment List sub-TLV
          includes the elements of the paths (i.e., segments) as well as an
          optional Weight sub-TLV.</t>
          <t>The Segment List sub-TLV may exceed 255 bytes in length due to a
          large number of segments. A 2-octet length is thus required.
          According to section 2 of <xref target="RFC9012"/>, target="RFC9012" sectionFormat="of" section="2"/>, the sub-TLV type
          defines the size of the length field. Therefore, for the Segment
          List sub-TLV, a code point of 128 or higher is used.</t>
          <t>The Segment List sub-TLV is OPTIONAL <bcp14>OPTIONAL</bcp14> and MAY <bcp14>MAY</bcp14> appear multiple
          times in the SR Policy encoding. The ordering of Segment List
          sub-TLVs does not matter since each sub-TLV encodes a Segment
          List.</t>
          <t>The Segment List sub-TLV contains zero or more Segment sub-TLVs
          and MAY <bcp14>MAY</bcp14> contain a Weight sub-TLV.</t>
          <t>The Segment List sub-TLV has the following format: <figure
              align="center"> </t>

<figure>
  <name>Segment List Sub-TLV</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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            |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                           sub-TLVs                          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Segment List sub-TLV

where:]]></artwork>
            </figure><list style="symbols">
              <t>Type: 128.</t>

              <t>Length: the
]]></artwork>
</figure>

<t>Where:</t>
          <dl spacing="normal">

              <dt>Type:</dt><dd>128</dd>

              <dt>Length:</dt><dd>The total length (not including the Type and Length
              fields) of the sub-TLVs encoded within the Segment List sub-TLV
              in terms of octets.</t>

              <t>RESERVED: 1 octets.</dd>

              <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST <bcp14>MUST</bcp14> be set to
              zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

              <t>sub-TLVs receipt.</dd>

              <dt>sub-TLVs currently defined: <list> </dt><dd>
              <ul spacing="normal">
                <li>
                  <t>An optional single Weight sub-TLV.</t> sub-TLV</t>
                </li>
                <li>
                  <t>Zero or more Segment sub-TLVs.</t>
                </list></t>
            </list></t> sub-TLVs</t>
                </li>
              </ul>
            </dd>
          </dl>

          <t>Validation of an explicit path encoded by the Segment List
          sub-TLV is beyond the scope of BGP and performed by the SRPM as
          described in section 5 of <xref target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="5"/>.</t>
          <section anchor="WEIGHTTLV" title="Weight Sub-TLV"> numbered="true" toc="default">
            <name>Weight Sub-TLV</name>
            <t>The Weight sub-TLV specifies the weight associated with a given
            segment list. The contents of this sub-TLV are used only by the
            SRPM as described in section 2.11 of <xref target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="2.11"/>.</t>
            <t>The Weight sub-TLV is OPTIONAL and <bcp14>OPTIONAL</bcp14>; it MUST NOT <bcp14>MUST NOT</bcp14> appear more than
            once inside the Segment List sub-TLV.</t>
            <t>The Weight sub-TLV has the following format: <figure
                align="center"> </t>

<figure>
  <name>Weight Sub-TLV</name>
            <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Weight                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: Weight sub-TLV

where:]]></artwork>
              </figure></t>

            <t><list style="symbols">
                <t>Type: 9.</t>

                <t>Length: Specifies
]]></artwork>
	    </figure>

	    <t>Where:</t>
            <dl spacing="normal">

                <dt>Type:</dt><dd>9</dd>

                <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
                including Type and Length fields) in terms of octets. The
                value MUST <bcp14>MUST</bcp14> be 6.</t>

                <t>Flags: 1 6.</dd>

                <dt>Flags:</dt><dd>1 octet of flags. No flags are defined in this
                document. The Flags field MUST <bcp14>MUST</bcp14> be set to zero on transmission
                and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

                <t>RESERVED: 1 receipt.
              </dd>

                <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST <bcp14>MUST</bcp14> be set
                to zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

                <t>Weight: receipt.</dd>

<!--[rfced] Please review the following for how "4 octets" connects to
     the rest of the sentence (perhaps text is missing as we generally
     see "octets of foo" in previous descriptions)?

Original:

 Weight: 4 octets an unsigned integer value indicating the weight
      associated with a segment list...

-->

                <dt>Weight:</dt><dd>4 octets an unsigned integer value indicating the
                weight associated with a segment list as described in section
                2.11 of
                <xref target="RFC9256"/>. target="RFC9256" sectionFormat="of" section="2.11"/>. A weight value of zero is
                invalid.</t>
              </list></t>
                invalid.</dd>

            </dl>
          </section>
          <section anchor="SEGMENTTLV" title="Segment Sub-TLVs"> numbered="true" toc="default">
            <name>Segment Sub-TLVs</name>
            <t>A Segment sub-TLV describes a single segment in a segment list
            (i.e., a single element of the explicit path). One or more Segment
            sub-TLVs constitute an explicit path of the SR Policy candidate
            path. The contents of these sub-TLVs are used only by the SRPM as
            described in section 4 in <xref target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="4"/>.</t>
            <t>The Segment sub-TLVs are OPTIONAL <bcp14>OPTIONAL</bcp14> and MAY <bcp14>MAY</bcp14> appear multiple times
            in the Segment List sub-TLV.</t>

            <t>Section 4 of <xref target="RFC9256"/>
            <t><xref target="RFC9256" sectionFormat="of" section="4"/> defines several Segment
            Types:<figure align="center">
                <artwork align="left"><![CDATA[Type  A: SR-MPLS Label
Type  B: SRv6 SID
Type  C: IPv4
            Types:</t>
<dl>

<dt>Type A:</dt><dd>SR-MPLS Label</dd>
<dt>Type B:</dt><dd>SRv6 SID</dd>
<dt>Type C:</dt><dd>IPv4 Prefix with optional SR Algorithm
Type  D: IPv6 Algorithm</dd>
<dt>Type D:</dt><dd>IPv6 Global Prefix with optional SR Algorithm for SR-MPLS
Type  E: IPv4 SR-MPLS</dd>
<dt>Type E:</dt><dd>IPv4 Prefix with Local Interface ID
Type  F: IPv4 ID</dd>
<dt>Type F:</dt><dd>IPv4 Addresses for link endpoints as Local, Remote pair
Type  G: IPv6 pair</dd>
<dt>Type G:</dt><dd>IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SR-MPLS
Type  H: IPv6 SR-MPLS</dd>
<dt>Type H:</dt><dd>IPv6 Addresses for link endpoints as Local, Remote pair for SR-MPLS
Type  I: IPv6 SR-MPLS</dd>
<dt>Type I:</dt><dd>IPv6 Global Prefix with optional SR Algorithm for SRv6
Type  J: IPv6 SRv6</dd>
<dt>Type J:</dt><dd>IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SRv6
Type  K: IPv6 SRv6</dd>
<dt>Type K:</dt><dd>IPv6 Addresses for link endpoints as Local, Remote pair for SRv6

]]></artwork>
              </figure></t> SRv6</dd>
</dl>

            <t>The following sub-sections subsections specify the sub-TLVs used for
            Segment Types A and B. The other segment types are specified in
            <xref target="I-D.ietf-idr-bgp-sr-segtypes-ext"/>. target="RFC9831" format="default"/>. As specified in
            section 5.1 of
            <xref target="RFC9256"/>, target="RFC9256"  sectionFormat="of" section="5.1"/>, a mix of SR-MPLS and SRv6
            segments make the segment-list invalid.</t>
            <section anchor="TYPEA" title="Segment numbered="true" toc="default">
              <name>Segment Type A"> A</name>
              <t>The Type A Segment Sub-TLV sub-TLV encodes a single SR-MPLS SID. The
              format is as follows and is used to encode MPLS Label fields as
              specified in <xref target="RFC3032"/> target="RFC3032" format="default"/> and <xref target="RFC5462"/>.:
              <figure align="center"> target="RFC5462" format="default"/>:
              </t>

<figure>
  <name>Type A Segment Sub-TLV</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Label                        | TC  |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: Type A Segment sub-TLV

where:]]></artwork>
                </figure><list style="symbols">
                  <t>Type: 1.</t>

                  <t>Length: Specifies
]]></artwork>
</figure>

	      <t>Where:</t>
              <dl spacing="normal">

                  <dt>Type:</dt><dd>1</dd>

                  <dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
                  not including Type and Length fields) in terms of octets.
                  The value MUST <bcp14>MUST</bcp14> be 6.</t>

                  <t>Flags: 1 6.</dd>

                  <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
                  target="SEGMENTFLAGS"/>.</t>

                  <t>RESERVED: 1 target="SEGMENTFLAGS" format="default"/>.</dd>

                  <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST <bcp14>MUST</bcp14> be
                  set to zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on
                  receipt.</t>

                  <t>Label: 20
                  receipt.</dd>

                  <dt>Label:</dt><dd>20 bits of label value.</t>

                  <t>TC: 3 value.</dd>
                  <dt>TC:</dt><dd>3 bits of traffic class.</t>

                  <t>S: 1 class.</dd>

                  <dt>S:</dt><dd>1 bit of bottom-of-stack.</t>

                  <t>TTL: 1 bottom-of-stack.</dd>

                  <dt>TTL:</dt><dd>1 octet of TTL.</t>
                </list></t> TTL.</dd>

              </dl>
              <t>The following applies to the Type-1 Segment sub-TLV:<list
                  style="symbols"> sub-TLV:</t>
              <ul spacing="normal">
                <li>
                  <t>The S bit MUST <bcp14>MUST</bcp14> be zero upon transmission and MUST <bcp14>MUST</bcp14> be
                  ignored upon reception.</t>
                </li>
                <li>
                  <t>If the originator wants the receiver to choose the TC
                  value, it sets the TC field to zero.</t>
                </li>
                <li>
                  <t>If the originator wants the receiver to choose the TTL
                  value, it sets the TTL field to 255.</t>
                </li>
                <li>
                  <t>If the originator wants to recommend a value for these
                  fields, it puts those values in the TC and/or TTL
                  fields.</t>
                </li>
                <li>
                  <t>The receiver MAY <bcp14>MAY</bcp14> override the originator's values for
                  these fields. This would be determined by local policy at
                  the receiver. One possible policy would be to override the
                  fields only if the fields have the default values specified
                  above.</t>
                </list></t>
                </li>
              </ul>
            </section>
            <section anchor="TYPEB" title="Segment numbered="true" toc="default">
              <name>Segment Type B"> B</name>
              <t>The Type B Segment Sub-TLV encodes a single SRv6 SID. The
              format is as follows: <figure align="center"> </t>

<figure>
<name>Type B Segment Sub-TLV</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                       SRv6 SID (16 octets)                  //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//           SRv6 Endpoint Behavior and SID Structure          //
//                    (optional, 8 octets)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: Type B Segment sub-TLV

where:]]></artwork>
                </figure><list style="symbols">
                  <t>Type: 13.</t>

                  <t>Length: Specifies
]]></artwork>
</figure>

<t>Where:</t>
              <dl spacing="normal">

                  <dt>Type:</dt><dd>13</dd>

                  <dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
                  not including Type and Length fields) in terms of octets.
                  The value MUST <bcp14>MUST</bcp14> be 26 when the SRv6 Endpoint Behavior and SID
                  Structure is present else present; else, it MUST <bcp14>MUST</bcp14> be 18.</t>

                  <t>Flags: 1 18.
                </dd>

                  <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
                  target="SEGMENTFLAGS"/>.</t>

                  <t>RESERVED: 1 target="SEGMENTFLAGS" format="default"/>.</dd>

                  <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST <bcp14>MUST</bcp14> be
                  set to zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on
                  receipt.</t>

                  <t>SRv6 SID: 16
                  receipt.</dd>

                  <dt>SRv6 SID:</dt><dd>16 octets of IPv6 address.</t>

                  <t>SRv6 address.</dd>

                  <dt>SRv6 Endpoint Behavior and SID Structure: Optional, Structure:</dt><dd>Optional, as
                  defined in <xref target="BEHAVIORSTRUCT"/>. target="BEHAVIORSTRUCT" format="default"/>. The SRv6
                  Endpoint Behavior and SID Structure MUST NOT <bcp14>MUST NOT</bcp14> be included
                  when the SRv6 SID has not been included.</t>
                </list></t> included.</dd>

              </dl>
              <t>The Sub-TLV code point 2 defined for the advertisement of
              Segment Type B in the earlier draft versions of this document has been
              deprecated to avoid backward compatibility issues.</t>
            </section>
            <section anchor="SEGMENTFLAGS" title="SR numbered="true" toc="default">
              <name>SR Policy Segment Flags"> Flags</name>
              <t>The Segment Types sub-TLVs described above may contain the
              following SR Policy Segment Flags in their "Flags" field. Also
              refer to <xref target="IANASIDFLAGS"/>: <figure align="center"> target="IANASIDFLAGS" format="default"/>: </t>

<figure>
  <name>SR Policy Segment Flags</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|   |B|       |
+-+-+-+-+-+-+-+-+

Figure 22: SR Policy Segment Flags
]]></artwork>
</figure> where:<list>
                  <t>V-Flag: This flag, when
              <t>Where:</t>
              <ul spacing="normal">

                  <li> When the V-Flag is set, it is used by SRPM for "SID
                  verification" as described in Section 5.1 of <xref
                  target="RFC9256"/>.</t>

                  <t>B-Flag: This flag, when target="RFC9256" sectionFormat="of" section="5.1"/>.</li>

                  <li>When the B-Flag is set, it indicates the presence of
                  the SRv6 "SRv6 Endpoint Behavior and &amp; SID Structure Structure" encoding
                  specified in <xref target="BEHAVIORSTRUCT"/>.</t>

                  <t>The target="BEHAVIORSTRUCT" format="default"/>.</li>

                  <li>The unassigned bits in the Flag octet MUST <bcp14>MUST</bcp14> be set to zero
                  upon transmission and MUST <bcp14>MUST</bcp14> be ignored upon receipt.</t>
                </list></t> receipt.</li>

              </ul>

              <t>The following applies to the Segment Flags:<list
                  style="symbols">
                  <t>V-Flag Flags:</t>

              <ul spacing="normal">
                <li>
                  V-Flag applies to all Segment Types.</t>

                  <t>B-Flag Types.
                </li>
                <li>
                  B-Flag applies to Segment Type B. If B-Flag appears with
                  Segment Type A A, it MUST <bcp14>MUST</bcp14> be ignored.</t>
                </list></t> ignored.
                </li>
              </ul>
            </section>
            <section anchor="BEHAVIORSTRUCT"
                     title="SRv6 numbered="true" toc="default">
              <name>SRv6 SID Endpoint Behavior and Structure"> Structure</name>
              <t>The Segment Types sub-TLVs described above MAY <bcp14>MAY</bcp14> contain the
              SRv6 Endpoint Behavior and SID Structure <xref
              target="RFC8986"/> target="RFC8986" format="default"/> encoding as described below: <figure
                  align="center"> </t>

<figure>
  <name>SRv6 SID Endpoint Behavior and Structure</name>
              <artwork align="left"><![CDATA[+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ align="left" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Endpoint Behavior       |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    LB Length  |  LN Length    | Fun. Length   |  Arg. Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 23: SRv6 SID Endpoint Behavior and Structure
]]></artwork>
</figure> where:<list>
                  <t>Endpoint Behavior: 2
              <t>Where:</t>
              <dl spacing="normal">

                  <dt>Endpoint Behavior:</dt><dd>2 octets. It carries the SRv6 Endpoint
                  Behavior code point for this SRv6 SID as defined in section
                  10.2 of <xref target="RFC8986"/>.
                  target="RFC8986" sectionFormat="of" section="10.2"/>. When
                  set with the value 0xFFFF (i.e., Opaque), the choice of SRv6
                  Endpoint Behavior is left to the headend.</t>

                  <t>Reserved: 2 headend.</dd>

                  <dt>Reserved:</dt><dd>2 octets of reserved bits. This field MUST <bcp14>MUST</bcp14> be
                  set to zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on
                  receipt.</t>

                  <t>Locator
                  receipt.</dd>

                  <dt>Locator Block Length: 1 Length:</dt><dd>1 octet. SRv6 SID Locator Block
                  length in bits.</t>

                  <t>Locator bits.</dd>

                  <dt>Locator Node Length: 1 Length:</dt><dd>1 octet. SRv6 SID Locator Node
                  length in bits.</t>

                  <t>Function Length: 1 bits.</dd>

                  <dt>Function Length:</dt><dd>1 octet. SRv6 SID Function length in
                  bits.</t>

                  <t>Argument Length: 1
                  bits.</dd>

                  <dt>Argument Length:</dt><dd>1 octet. SRv6 SID Arguments length in
                  bits.</t>
                </list></t>
                  bits.</dd>

              </dl>

              <t>The total of the locator block, locator node, function, and
              argument lengths MUST <bcp14>MUST</bcp14> be less than or equal to 128.</t>
            </section>
          </section>
        </section>
        <section anchor="ENLPTLV" title="Explicit numbered="true" toc="default">
          <name>Explicit NULL Label Policy Sub-TLV"> Sub-TLV</name>
          <t>To steer an unlabeled IP packet into an SR policy for the MPLS
          data plane, it is necessary to push a label stack of one or more
          labels on that packet.</t>
          <t>The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate
          whether an Explicit NULL Label <xref target="RFC3032"/> target="RFC3032" format="default"/> must be
          pushed on an unlabeled IP packet before any other labels.</t>
          <t>If an ENLP Sub-TLV is not present, the decision of whether to
          push an Explicit NULL label on a given packet is a matter of local
          configuration.</t>
          <t>The ENLP sub-TLV is OPTIONAL and <bcp14>OPTIONAL</bcp14>; it MUST NOT <bcp14>MUST NOT</bcp14> appear more than
          once in the SR Policy encoding.</t>
          <t>The contents of this sub-TLV are used by the SRPM as described in
          section 4.1 of
          <xref target="RFC9256"/>.</t>

          <figure align="center">
            <artwork><![CDATA[0 target="RFC9256" sectionFormat="of" section="4.1"/>.</t>

<figure>
  <name>ELNP Sub-TLV</name>
          <artwork name="" type="" align="left" alt=""><![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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ENLP      |
+-+-+-+-+-+-+-+-+

Figure 24: ELNP sub-TLV
]]></artwork>
</figure>

          <t>Where:<list>
              <t>Type: 14.</t>

              <t>Length: Specifies
          <t>Where:</t>
          <dl spacing="normal">

              <dt>Type:</dt><dd>14</dd>

              <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
              including Type and Length fields) in terms of octets. The value
              MUST
              <bcp14>MUST</bcp14> be 3.</t>

              <t>Flags: 1 3.</dd>

              <dt>Flags:</dt><dd>1 octet of flags. No flags are defined in this
              document. The Flags field MUST <bcp14>MUST</bcp14> be set to zero on transmission
              and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

              <t>RESERVED: 1 receipt.</dd>

              <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST <bcp14>MUST</bcp14> be set to
              zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

              <t>ENLP receipt.</dd>

              <dt>ENLP (Explicit NULL Label Policy): Indicates Policy):</dt><dd><t>Indicates whether Explicit
              NULL labels are to be pushed on unlabeled IP packets that are
              being steered into a given SR policy. The following values have
              been currently defined for this field:<list>
                  <t>1: Push field:</t>

              <dl spacing="normal" indent="6">

                  <dt>1:</dt><dd>Push an IPv4 Explicit NULL label on an unlabeled IPv4
                  packet,
                  packet but do not push an IPv6 Explicit NULL label on an
                  unlabeled IPv6 packet.</t>

                  <t>2: Push packet.</dd>

                  <dt>2:</dt><dd>Push an IPv6 Explicit NULL label on an unlabeled IPv6
                  packet,
                  packet but do not push an IPv4 Explicit NULL label on an
                  unlabeled IPv4 packet.</t>

                  <t>3: Push packet.</dd>

                  <dt>3:</dt><dd>Push an IPv4 Explicit NULL label on an unlabeled IPv4
                  packet,
                  packet and push an IPv6 Explicit NULL label on an unlabeled
                  IPv6 packet.</t>

                  <t>4: Do packet.</dd>

                  <dt>4:</dt><dd>Do not push an Explicit NULL label.</t>
                </list>This label.</dd></dl>

              <t>This field can have one of the values as specified in <xref target="IANAENLP"/>.
              target="IANAENLP" format="default"/>. The ENLP unassigned values
              may be used for future extensions. Implementations adhering to
              this document MUST <bcp14>MUST</bcp14> ignore the ENLP Sub-TLV with
              unrecognized values (viz. other than 1 through 4). The behavior
              signaled in this Sub-TLV MAY <bcp14>MAY</bcp14> be overridden by
              local configuration by the network operator based on their
              deployment requirements. The section 4.1
              of <xref target="RFC9256"/> target="RFC9256"
              sectionFormat="of" section="4.1"/> describes the behavior on the
              headend for the handling of the explicit null label.</t>
            </list></t> label.</t></dd>

          </dl>
        </section>
        <section anchor="POLICYPRIORITY" title="Policy numbered="true" toc="default">
          <name>Policy Priority Sub-TLV"> Sub-TLV</name>
          <t>An operator MAY <bcp14>MAY</bcp14> set the Policy Priority sub-TLV to indicate the
          order in which the SR policies are re-computed recomputed upon topological
          change. The contents of this sub-TLV are used by the SRPM as
          described in section 2.12 of <xref target="RFC9256"/>.</t> target="RFC9256"  sectionFormat="of" section="2.12"/>.</t>
          <t>The Priority sub-TLV is OPTIONAL and <bcp14>OPTIONAL</bcp14>; it MUST NOT <bcp14>MUST NOT</bcp14> appear more than
          once in the SR Policy encoding.</t>
          <t>The Priority sub-TLV has the following format:</t>

          <figure align="center">
            <artwork><![CDATA[0

<figure>
  <name>Priority Sub-TLV</name>
          <artwork name="" type="" align="left" alt=""><![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      |  Priority     |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 25: Priority sub-TLV
]]></artwork>
</figure>

          <t>Where:<list>
              <t>Type: 15</t>

              <t>Length: Specifies
          <t>Where:</t>
          <dl spacing="normal">

              <dt>Type:</dt><dd>15</dd>

              <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
              including Type and Length fields) in terms of octets.The octets.  The value
              MUST
              <bcp14>MUST</bcp14> be 2.</t>

              <t>Priority: a 2.</dd>

              <dt>Priority:</dt><dd>A 1-octet value indicating the priority as
              specified in section 2.12 of <xref target="RFC9256"/>.</t>

              <t>RESERVED: 1 target="RFC9256" sectionFormat="of" section="2.12"/>.</dd>

              <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST <bcp14>MUST</bcp14> be set to
              zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>
            </list></t> receipt.</dd>

          </dl>
        </section>
        <section anchor="POLICYCPNAME"
                 title="Policy numbered="true" toc="default">
          <name>Policy Candidate Path Name Sub-TLV"> Sub-TLV</name>
          <t>An operator MAY <bcp14>MAY</bcp14> set the Policy Candidate Path Name sub-TLV to
          attach a symbolic name to the SR Policy candidate path.</t>
          <t>Usage of the Policy Candidate Path Name sub-TLV is described in
          section 2.6 of
          <xref target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="2.6"/>.</t>
          <t>The Policy Candidate Path Name sub-TLV may exceed 255 bytes in
          length due to a long name. A 2-octet length is thus required.
          According to section 2 of <xref target="RFC9012"/>, target="RFC9012" sectionFormat="of" section="2"/>, the sub-TLV type
          defines the size of the length field. Therefore, for the Policy
          Candidate Path Name sub-TLV sub-TLV, a code point of 128 or higher is
          used.</t>
          <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the size of the symbolic name for the
          candidate path is be limited to 255 bytes. Implementations MAY <bcp14>MAY</bcp14> choose
          to truncate long names to 255 bytes when signaling via BGP.</t>
          <t>The Policy Candidate Path Name sub-TLV is OPTIONAL and <bcp14>OPTIONAL</bcp14>; it MUST
          NOT <bcp14>MUST
          NOT</bcp14> appear more than once in the SR Policy encoding.</t>
          <t>The Policy Candidate Path Name sub-TLV has the following format:</t>

          <figure align="center">
            <artwork><![CDATA[0

<figure>
  <name>Policy Candidate Path Name Sub-TLV</name>
          <artwork name="" type="" align="left" alt=""><![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                      |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//              Policy Candidate Path Name                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 26: Policy Candidate Path Name sub-TLV
]]></artwork>
</figure>

          <t>Where:<list>
              <t>Type: 129.</t>

              <t>Length: Specifies
          <t>Where:</t>
          <dl spacing="normal">

              <dt>Type:</dt><dd>129</dd>

              <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
              including Type and Length fields) in terms of octets. The value
              is variable.</t>

              <t>RESERVED: 1 variable.</dd>

              <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST <bcp14>MUST</bcp14> be set to
              zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

              <t>Policy receipt.</dd>

              <dt>Policy Candidate Path Name: Symbolic Name:</dt><dd>Symbolic name for the SR Policy
              candidate path without a NULL terminator with encoding as
              specified in section 2.6 of <xref target="RFC9256"/>.</t>
            </list></t> target="RFC9256" sectionFormat="of" section="2.6"/>.</dd>

          </dl>
        </section>
        <section anchor="POLICYNAME" title="Policy numbered="true" toc="default">
          <name>Policy Name Sub-TLV"> Sub-TLV</name>
          <t>An operator MAY <bcp14>MAY</bcp14> set the Policy Name sub-TLV to associate a
          symbolic name with the SR Policy for which the candidate path is
          being advertised via the SR Policy NLRI.</t>
          <t>Usage of the Policy Name sub-TLV is described in section 2.1 of <xref
          target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="2.1"/>.</t>
          <t>The Policy Name sub-TLV may exceed 255 bytes in length due to a
          long policy name. A 2-octet length is thus required. According to
          section 2 of
          <xref target="RFC9012"/>, target="RFC9012" sectionFormat="of" section="2"/>, the sub-TLV
          type defines the size of the length field. Therefore, for the Policy
          Name sub-TLV sub-TLV, a code point of 128 or higher is used.</t>
          <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the size of the symbolic name for the SR
          Policy is be limited to 255 bytes. Implementations MAY <bcp14>MAY</bcp14> choose to
          truncate long names to 255 bytes when signaling via BGP.</t>
          <t>The Policy Name sub-TLV is OPTIONAL and <bcp14>OPTIONAL</bcp14>; it MUST NOT <bcp14>MUST NOT</bcp14> appear more
          than once in the SR Policy encoding.</t>
          <t>The Policy Name sub-TLV has the following format:</t>

          <figure align="center">
            <artwork><![CDATA[0

<figure>
  <name>Policy Name Sub-TLV</name>
          <artwork name="" type="" align="left" alt=""><![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                      |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                        Policy Name                          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 27: Policy Name sub-TLV
]]></artwork>
</figure>

          <t>Where:<list>
              <t>Type: 130</t>

              <t>Length: Specifies
          <t>Where:</t>
          <dl spacing="normal">

              <dt>Type:</dt><dd>130</dd>

              <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
              including Type and Length fields) in terms of octets. The value
              is variable.</t>

              <t>RESERVED: 1 variable.</dd>

              <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST <bcp14>MUST</bcp14> be set to
              zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

              <t>Policy Name: Symbolic receipt.</dd>

              <dt>Policy Name:</dt><dd>Symbolic name for the SR Policy without a NULL
              terminator with encoding as specified in section 2.1 of <xref
              target="RFC9256"/>.</t>
            </list></t> target="RFC9256" sectionFormat="of" section="2.1"/>.</dd>

          </dl>

        </section>
      </section>
    </section>
    <section anchor="EXTCOLOR" title="Color numbered="true" toc="default">
      <name>Color Extended Community"> Community</name>
      <t>The Color Extended Community <xref target="RFC9012"/> target="RFC9012" format="default"/> is used to
      steer traffic corresponding to BGP routes into an SR Policy with
      matching color value. The Color Extended Community MAY <bcp14>MAY</bcp14> be carried in any
      BGP UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
      Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128
      (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70
      (Ethernet VPN, usually known as EVPN). Use of the Color Extended
      Community in BGP UPDATE messages of other AFI/SAFIs is not covered by
      <xref target="RFC9012"/> and target="RFC9012" format="default"/>; hence, it is hence outside the scope of this document
      as well.</t>
      <t>Two bits from the Flags field of the Color Extended Community are
      used as follows to support the requirements of Color-Only steering as
      specified in Section 8.8 of <xref target="RFC9256"/>: <figure
          align="center">
          <artwork><![CDATA[ target="RFC9256" sectionFormat="of" section="8.8"/>: </t>

<figure>
  <name>Color Extended Community Flags</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
                     1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C O|        Unassigned         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 28: Color Extended Community Flags
]]></artwork>
        </figure>The CO
</figure>

      <t>The C and O bits together form the Color-Only Type field field, which
      indicates the various matching criteria between the BGP NH and the SR Policy
      endpoint in addition to the matching of the color value. Following The following types
      are defined:<list style="symbols">
          <t>Type defined:</t>
      <dl spacing="normal">

          <dt>Type 0 (bits 00): Specific 00):</dt><dd>Specific Endpoint Match: Match. Request a match for the
          endpoint that is the BGP NH</t>

          <t>Type NH.</dd>

          <dt>Type 1 (bits 01): Specific 01):</dt><dd>Specific or Null Endpoint Match: Match. Request a match
          for either the endpoint that is the BGP NH or a null endpoint (e.g.,
          like
          a default gateway)</t>

          <t>Type gateway).</dd>

          <dt>Type 2 (bits 10): Specific, 10):</dt><dd>Specific, Null, or Any Endpoint Match: Match. Request
          a match for either the endpoint that is the BGP NH or with a null or
          any endpoint</t>

          <t>Type endpoint.</dd>

          <dt>Type 3 (bits 11): reserved 11):</dt><dd>Reserved for future use and SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used.
          Upon reception, an implementation MUST <bcp14>MUST</bcp14> treat it like Type 0.</t>
        </list></t> 0.</dd>

      </dl>
      <t>The details of the SR Policy steering mechanisms based on these
      Color-Only types are specified in section 8.8 of <xref
      target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="8.8"/>.</t>
      <t>One or more Color Extended Communities MAY <bcp14>MAY</bcp14> be
      associated with a BGP route update. Sections 8.4.1, 8.5.1, <xref target="RFC9256"
      sectionFormat="bare" section="8.4.1"/>, <xref target="RFC9256"
      sectionFormat="bare" section="8.5.1"/>, and 8.8.2 <xref target="RFC9256"
      sectionFormat="bare" section="8.8.2"/> of <xref
      target="RFC9256"/> target="RFC9256"
      format="default"/> specify the steering behaviors over SR Policies when
      multiple Color Extended Communities are associated with a BGP route.</t>
    </section>
    <section anchor="OPERATIONS" title="SR numbered="true" toc="default">
      <name>SR Policy Operations"> Operations</name>
      <t>As mentioned in <xref target="INTRO"/>, target="INTRO" format="default"/>, BGP is not the actual
      consumer of an SR Policy NLRI. BGP is in charge of the origination and
      propagation of the SR Policy NLRI NLRI, but its installation and use are
      outside the scope of BGP. The details of SR Policy installation and use
      are specified in <xref target="RFC9256"/>.</t> target="RFC9256" format="default"/>.</t>
      <section anchor="CONFIG" title="Advertisement numbered="true" toc="default">
        <name>Advertisement of SR Policies"> Policies</name>
        <t>Typically, but not limited to, an SR Policy is computed by a
        controller or a path computation engine Path Computation Engine (PCE) and originated by a BGP
        speaker on its behalf.</t>
        <t>Multiple SR Policy NLRIs may be present with the same &lt;color,
        endpoint&gt; tuple but with different distinguishers when these SR
        policies are intended for different headends.</t>
        <t>The distinguisher of each SR Policy NLRI prevents undesired BGP
        route selection among these SR Policy NLRIs and allows their
        propagation across route reflectors <xref target="RFC4456"/>.</t> target="RFC4456" format="default"/>.</t>
        <t>Moreover, one or more route targets SHOULD <bcp14>SHOULD</bcp14> be attached to the
        advertisement, where each route target identifies one or more intended
        headends for the advertised SR Policy update.</t>
        <t>If no route target is attached to the SR Policy NLRI, then it is
        assumed that the originator sends the SR Policy update directly (e.g.,
        through a BGP session) to the intended receiver. In such a case, the
        NO_ADVERTISE community <xref target="RFC1997"/> MUST target="RFC1997" format="default"/> <bcp14>MUST</bcp14> be attached to
        the SR Policy update (see further details in <xref
        target="PROPAGATE"/>).</t> target="PROPAGATE" format="default"/>).</t>
      </section>
      <section anchor="RECEPT" title="Reception numbered="true" toc="default">
        <name>Reception of an SR Policy NLRI"> NLRI</name>
        <t>On reception of an SR Policy NLRI, a BGP speaker first determines
        if it is valid as described in <xref target="ACCEPT"/> and then target="ACCEPT"
        format="default"/>; then, the BGP speaker performs the decision process for
        selection of the best route (Section
        9.1 of <xref target="RFC4271"/>). (<xref target="RFC4271" sectionFormat="of"
        section="9.1"/>). The key difference from the base BGP decision
        process is that BGP does not download the selected best routes of the SR
        Policy SAFI into the forwarding and instead forwarding; instead, it considers them "usable"
        for passing on to the SRPM for further processing as described in
        <xref target="USABLE"/>. target="USABLE" format="default"/>. The selected best route is
        "propagated" (Section 9.1.3 of <xref target="RFC4271"/>) (<xref target="RFC4271" sectionFormat="of"
        section="9.1.3"/>) as described in <xref target="PROPAGATE"/> target="PROPAGATE"
        format="default"/>, irrespective of its "usability" by the local
        router.</t>
        <section anchor="ACCEPT" title="Validation numbered="true" toc="default">
          <name>Validation of an SR Policy NLRI"> NLRI</name>
          <t>When a BGP speaker receives an SR Policy NLRI from a neighbor neighbor, it
          MUST
          <bcp14>MUST</bcp14> first perform validation based on the following rules in
          addition to the validation described in <xref target="ERROR"/>:
          <list style="symbols"> target="ERROR" format="default"/>:
          </t>
          <ul spacing="normal">
            <li>
              <t>The SR Policy NLRI MUST <bcp14>MUST</bcp14> include a distinguisher, color, and
              endpoint field which that implies that the length of the NLRI MUST <bcp14>MUST</bcp14> be
              either 12 or 24 octets (depending on the address family of the
              endpoint).</t>
            </li>
            <li>
              <t>The SR Policy update MUST <bcp14>MUST</bcp14> have either the NO_ADVERTISE
              community or
              community, at least one route target extended community in
              IPv4-address format format, or both. If a router supporting this
              specification receives an SR Policy update with no route target
              extended communities and no NO_ADVERTISE community, the update
              MUST
              <bcp14>MUST</bcp14> be considered as to be malformed.</t>
            </li>
            <li>
              <t>The Tunnel Encapsulation Attribute MUST <bcp14>MUST</bcp14> be attached to the
              BGP Update and MUST <bcp14>MUST</bcp14> have a Tunnel Type TLV set to SR Policy
              (codepoint
              (code point is 15).</t>
            </list></t>
            </li>
          </ul>
          <t>A router that receives an SR Policy update that is not valid
          according to these criteria MUST <bcp14>MUST</bcp14> treat the update as malformed malformed, and
          the SR Policy candidate path MUST NOT <bcp14>MUST NOT</bcp14> be passed to the SRPM.</t>
        </section>
        <section anchor="USABLE"
                 title="Eligibility numbered="true" toc="default">
          <name>Eligibility for Local Use of an SR Policy NLRI"> NLRI</name>
          <t>An SR Policy NLRI update without any that does not have a route target extended
          community but having does have the NO_ADVERTISE community is considered
          usable.</t>
          <t>If one or more route targets are present, then at least one route
          target MUST <bcp14>MUST</bcp14> match the BGP Identifier of the receiver for the update
          to be considered usable. The BGP Identifier is defined in <xref
          target="RFC4271"/> target="RFC4271" format="default"/> as a 4-octet IPv4 address and is updated by <xref
          target="RFC6286"/> target="RFC6286" format="default"/> as a 4-octet, unsigned, non-zero integer.
          Therefore, the route target extended community MUST <bcp14>MUST</bcp14> be of the same
          format.</t>

<!--[rfced] Please clarify "it" in the following text:

Original:

   If one or more route targets are present and none matches the local
   BGP Identifier, then, while the SR Policy NLRI is valid, it is not
   usable on the receiver node.

Perhaps:

   If one or more route targets are present, and none matches the
   local BGP Identifier, then, while the SR Policy NLRI is valid, the
   route targets are not usable on the receiver node.
-->

          <t>If one or more route targets are present and none matches the
          local BGP Identifier, then, while the SR Policy NLRI is valid, it is
          not usable on the receiver node.</t>
          <t>When the SR Policy tunnel type includes any sub-TLV that is
          unrecognized or unsupported, the update SHOULD NOT <bcp14>SHOULD NOT</bcp14> be considered
          usable. An implementation MAY <bcp14>MAY</bcp14> provide an option for ignoring
          unsupported sub-TLVs.</t>
          <t>Once BGP on the receiving node has determined that the SR Policy
          NLRI is usable, it passes the SR Policy candidate path to the SRPM.
          Note that, along with the candidate path details, BGP also passes
          the originator information for breaking ties in the candidate path
          selection process as described in section 2.4 of <xref
          target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="2.4"/>.</t>
          <t>When an update for an SR Policy NLRI results in its becoming
          unusable, BGP MUST <bcp14>MUST</bcp14> delete its corresponding SR Policy candidate path
          from the SRPM.</t>
          <t>The SRPM applies the rules defined in section 2 of <xref
          target="RFC9256"/> target="RFC9256"
          sectionFormat="of" section="2"/> to determine whether the SR Policy
          candidate path is valid and to select the active candidate path for
          a given SR Policy.</t>
        </section>
        <section anchor="PROPAGATE" title="Propagation numbered="true" toc="default">
          <name>Propagation of an SR Policy"> Policy</name>
          <t>SR Policy NLRIs that have the NO_ADVERTISE community attached to
          them MUST NOT <bcp14>MUST NOT</bcp14> be propagated.</t>
          <t>By default, a BGP node receiving an SR Policy NLRI MUST NOT <bcp14>MUST NOT</bcp14>
          propagate it to any EBGP External BGP (EBGP) neighbor. An implementation MAY <bcp14>MAY</bcp14> provide an
          explicit configuration to override this and enable the propagation
          of valid SR Policy NLRIs to specific EBGP neighbors where the SR
          domain comprises multiple-ASes multiple ASes within a single service provider
          domain (see <xref target="Security"/> target="Security" format="default"/> for details).</t>
          <t>A BGP node advertises a received SR Policy NLRI to its IBGP Internal BGP (IBGP)
          neighbors according to normal IBGP propagation rules.</t>
          <t>By default, a BGP node receiving an SR Policy NLRI SHOULD NOT <bcp14>SHOULD NOT</bcp14>
          remove the route target extended community before propagation. An
          implementation MAY <bcp14>MAY</bcp14> provide support for configuration to filter
          and/or remove the route target extended community before
          propagation.</t>
          <t>A BGP node MUST NOT <bcp14>MUST NOT</bcp14> alter the SR Policy information carried in
          the Tunnel Encapsulation Attribute during propagation.</t>
        </section>
      </section>
    </section>
    <section anchor="ERROR" title="Error numbered="true" toc="default">
      <name>Error Handling and Fault Management"> Management</name>
      <t>This section describes the error handling error-handling actions, as described in
      <xref target="RFC7606"/>, target="RFC7606" format="default"/>, that are to be performed for the handling of
      the BGP update messages for the BGP SR Policy SAFI.</t>
      <t>A BGP Speaker MUST speaker <bcp14>MUST</bcp14> perform the following syntactic validation of the
      SR Policy NLRI to determine if it is malformed. This includes the
      validation of the length of each NLRI and the total length of the
      MP_REACH_NLRI and MP_UNREACH_NLRI attributes. It also includes the
      validation of the consistency of the NLRI length with the AFI and the
      endpoint address as specified in <xref target="SRPOLICYSAFI"/>.</t> target="SRPOLICYSAFI" format="default"/>.</t>
      <t>When the error determined allows for the router to skip the malformed
      NLRI(s) and continue the processing of the rest of the update message,
      then it MUST <bcp14>MUST</bcp14> handle such malformed NLRIs as 'Treat-as-withdraw'. 'treat-as-withdraw'. In
      other cases, where the error in the NLRI encoding results in the
      inability to process the BGP update message (e.g. length related (e.g., length-related
      encoding errors), then the router SHOULD <bcp14>SHOULD</bcp14> handle such malformed NLRIs as
      'AFI/SAFI disable'
      "AFI/SAFI disable" when other AFI/SAFI AFIs/SAFIs besides SR Policy are being
      advertised over the same session. Alternately, the router MUST <bcp14>MUST</bcp14> perform
      'session reset'
      "session reset" when the session is only being used for SR Policy or
      when it 'AFI/SAFI disable' a "AFI/SAFI disable" action is not possible.</t>
      <t>The validation of the TLVs/sub-TLVs introduced in this document and
      defined in their respective sub-sections subsections of <xref target="SRPOLICYTLV"/>
      MUST target="SRPOLICYTLV" format="default"/>
      <bcp14>MUST</bcp14> be performed to determine if they are malformed or invalid. The
      validation of the Tunnel Encapsulation Attribute itself and the other
      TLVs/sub-TLVs specified in Section 13 of <xref target="RFC9012"/> MUST target="RFC9012" sectionFormat="of" section="13"/> <bcp14>MUST</bcp14>
      be done as described in that document. In case of any error detected,
      either at the attribute or its TLV/sub-TLV level, the
      "treat-as-withdraw" strategy MUST <bcp14>MUST</bcp14> be applied. This is because an SR
      Policy update without a valid Tunnel Encapsulation Attribute (comprising (comprised
      of all valid TLVs/sub-TLVs) is not usable.</t>
      <t>An SR Policy update that is determined not to be not valid, and therefore
      malformed, valid (and, therefore,
      malformed) based on the rules described in <xref target="ACCEPT"/> MUST target="ACCEPT" format="default"/> <bcp14>MUST</bcp14> be
      handled by the "treat-as-withdraw" strategy.</t>
      <t>The validation of the individual fields of the TLVs/sub-TLVs defined
      in <xref target="SRPOLICYTLV"/> target="SRPOLICYTLV" format="default"/> are beyond the scope of BGP as they are
      handled by the SRPM as described in the individual TLV/sub-TLV
      sub-sections.
      subsections. A BGP implementation MUST NOT <bcp14>MUST NOT</bcp14> perform semantic
      verification of such fields nor consider the SR Policy update to be
      invalid or not usable based on such validation.</t>
      <t>An implementation SHOULD <bcp14>SHOULD</bcp14> log any errors found during the above
      validation for further analysis.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

<!--[rfced] We note that the IANA Considerations section (Section 6)
     starts with a summary of all of the actions that follow in the
     subsections.  We had a few questions/comments related to this use:

a) Note that we have consolidated mentions of the registry group names
in the introductory text for each type of action in order to reduce
redundancy.  Please review these changes and let us know any
objections.

b) To further reduce redundancy, might it be agreeable to delete the
registry group names from the subsections that follow?  They were used
inconsistently in the original, and the reader would be able to find
that information in Section 6 itself if desired.

c) Would you like to add section pointers to the corresponding
subsections where the actions are further described?

d) Please note that any changes to text that appears in any IANA
registries mentioned in this document will be communicated to IANA by
the RPC prior to publication but after the completion of AUTH48.
-->

      <t>This document uses code point allocations from the following existing
      registries:<list style="symbols">
          <t>Subsequent
      registries in the "Subsequent Address Family Identifiers (SAFI) Parameters Parameters" registry group:</t>
      <ul spacing="normal">
        <li>
          <t>The "SAFI Values" registry</t>

          <t>BGP Tunnel Encapsulation Attribute
        </li>
      </ul>
      <t>This document uses code point allocations from the following existing registries in the "Border Gateway Protocol (BGP) Tunnel Types Encapsulation" registry under
          the BGP group:</t>
      <ul spacing="normal">
        <li>
          <t>The "BGP Tunnel Encapsulation Attribute Tunnel Types" registry</t>

          <t>BGP
        </li>
        <li>
          <t>The "BGP Tunnel Encapsulation Attribute sub-TLVs registry under the
          BGP Tunnel Encapsulation Sub-TLVs" registry</t>

          <t>Color
        </li>
        <li>
          <t>The "Color Extended Community Flags registry under the BGP Tunnel
          Encapsulation Flags" registry</t>
        </list></t>
        </li>
      </ul>
      <t>This document also requests the creation of creates the following new
      registries: <list style="symbols">
          <t>SR
      registries in the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group: </t>
      <ul spacing="normal">
        <li>
          <t>The "SR Policy Segment List Sub-TLVs under the BGP Tunnel
          Encapsulation Sub-TLVs" registry</t>

          <t>SR
        </li>
        <li>
          <t>The "SR Policy Binding SID Flags under the BGP Tunnel Encapsulation Flags" registry</t>

          <t>SR
        </li>
        <li>
          <t>The "SR Policy SRv6 Binding SID Flags under the BGP Tunnel
          Encapsulation Flags" registry</t>

          <t>SR
        </li>
        <li>
          <t>The "SR Policy Segment Flags under the BGP Tunnel Encapsulation Flags" registry</t>

          <t>Color
        </li>
        <li>
          <t>The "Color Extended Community Color-Only Types Types" registry</t>
      </li></ul>
      <t>This document creates the following new registry under in the BGP
          Tunnel Encapsulation registry</t>

          <t>SR "Segment Routing" registry group:</t>
      <ul spacing="normal">
        <li>
          <t>The "SR Policy ENLP Values under the Segment Routing Values" registry</t>
        </list></t>
        </li>
      </ul>

<!--[rfced] We had a few questions regarding Section 6.1 and the BGP
     SAFI Code Point:

a) We received the following note from IANA.  We do not see mention of
this update in the IANA Considerations section of this document.
Should anything be added?

IANA's Note:
NOTE: We've also updated the associated iana-routing-types YANG module
to reflect the new description and enum variable.

Please see
https://www.iana.org/assignments/iana-routing-types

b) We don't see any mention of "BGP" in the corresponding IANA
registry. Should the title of Table 1 be updated?

Currently in the document:
Table 1: BGP SAFI Code Point

At https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml:
SR Policy SAFI

c) The title of this section is "Subsequent Address Family Identifiers
(SAFI) Parameters".  This is the title of registry group.  Subsequent
subsections in the document are titled using the subregistry.  Should
the title of Section 6.1 be updated to "SAFI Values"?

-->

      <section anchor="IANASAFI"
               title="Subsequent numbered="true" toc="default">
        <name>Subsequent Address Family Identifiers (SAFI) Parameters"> Parameters</name>
        <t>This document introduces registers a SAFI code point in the "SAFI Values" registry of the "Subsequent Address
        Family Identifiers (SAFI) Parameters" that has been assigned a code
        point by IANA. The entry needs to be updated registry group as follows:<figure
            align="center">
            <artwork align="center"><![CDATA[Code Point    Description          Reference
-----------------------------------------------
   73        SR Policy SAFI       This document

     Table 1: BGP follows:</t>

	<table>
	  <name>BGP SAFI Code Point

]]></artwork>
          </figure></t> Point</name>
	  <thead>
	    <tr>
	      <th>Value</th><th>Description</th><th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>73</td><td>SR Policy SAFI</td><td>RFC 9830</td>
	    </tr>
	  </tbody>
	</table>

      </section>
      <section anchor="IANATUNNEL"
               title="BGP numbered="true" toc="default">
        <name>BGP Tunnel Encapsulation Attribute Tunnel Types"> Types</name>
        <t>This document introduces registers a Tunnel-Type code point in the registry "BGP Tunnel
        Encapsulation Attribute Tunnel Types" registry under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group.</t>

	<table>
	  <name>Tunnel Type Code Point</name>
	  <thead>
	    <tr>
	      <th>Value</th><th>Description</th><th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>15</td><td>SR Policy</td><td>RFC 9830</td>
	    </tr>
	  </tbody>
	</table>

      </section>

<!--[rfced] We had the following questions/comments regarding Section
     6.3:

a) We note that the corresponding IANA registry
(https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#tunnel-sub-tlvs)
also has been assigned a
        codepoint "Change Controller" column in which some of the code points
listed by IANA. The entry needs to be updated as follows:<figure
            align="center">
            <artwork align="center"><![CDATA[Code Point     Description            Reference
--------------------------------------------------
   15          SR Policy           This this document contain information (i.e., IETF).  Should any
mention of this be made in Table 2: 3?

b) Please review our update to the title of Table 3 and let us know
any objections.

Original:

Table 3: BGP Tunnel Type Encapsulation Attribute Code Point

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

Current:

Table 3: BGP Tunnel Encapsulation Attribute Sub-TLV Code Points
-->
      <section anchor="IANATUNNSUBTLV"
               title="BGP numbered="true" toc="default">
        <name>BGP Tunnel Encapsulation Attribute sub-TLVs"> Sub-TLVs</name>
        <t>This document defines sub-TLVs in the registry "BGP Tunnel
        Encapsulation Attribute sub-TLVs" that have been assigned code points
        by IANA as follows via Sub-TLVs" registry under the early allocation process which needs to be
        made permanent:<figure align="center">
            <artwork align="center"><![CDATA[Code Point         Description                  Reference
------------------------------------------------------------
12          Preference sub-TLV                  This document
13          Binding SID sub-TLV                 This document
14          ENLP sub-TLV                        This document
15          Priority sub-TLV                    This document
20          SRv6 Binding SID sub-TLV            This document
128         Segment "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group.</t>

<table>
  <name>BGP Tunnel Encapsulation Attribute Sub-TLV Code Points</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>12</td>
      <td>Preference sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>13</td>
      <td>Binding SID sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>14</td>
      <td>ENLP sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>15</td>
      <td>Priority sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>20</td>
      <td>SRv6 Binding SID sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>128</td>
      <td>Segment List sub-TLV                This document
129         Policy sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>129</td>
      <td>Policy Candidate Path Name sub-TLV  This document
130         Policy sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>130</td>
      <td>Policy Name sub-TLV                 This document

     Table 3: BGP Tunnel Encapsulation Attribute Code Points

]]></artwork>
          </figure></t> sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
</tbody>
</table>

      </section>
      <section anchor="IANAEXTCOM" title="Color numbered="true" toc="default">
        <name>Color Extended Community Flags"> Flags</name>
        <t>This document defines the use of 2 bits in the registry called
        "Color Extended Community Flags" registry under the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation"
        registry that have been assigned by IANA via the early allocation
        process to form the Color-Only Types field which needs to be made
        permanent:<figure align="center">
            <artwork align="center"><![CDATA[    Bit
 Position     Description                         Reference
------------------------------------------------------------------
  0-1       Color-only Types Field                This document

     Table 4: Color group.</t>

<table>
  <name>Color Extended Community Flag Bits
    ]]></artwork>
          </figure></t> Bits</name>
  <thead>
    <tr><th>Bit Position</th><th>Description</th><th>Reference</th></tr>
  </thead>
  <tbody>
    <tr><td>0-1</td><td>Color-only Types Field</td><td>RFC 9830</td></tr>
  </tbody>
</table>

      </section>
      <section anchor="IANASIDLIST" title="SR numbered="true" toc="default">
        <name>SR Policy Segment List Sub-TLVs"> Sub-TLVs</name>
        <t>This document requests the creation of creates a new registry called "SR
        Policy Segment List Sub-TLVs" under the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation"
        registry.
        registry group. The allocation registration policy of this registry is "IETF Review"
        according to
        (see <xref target="RFC8126"/>.</t>

        <t>Following target="RFC8126" format="default"/>).</t>
        <t>The following initial Sub-TLV codepoints sub-TLV code points are assigned by this
        document:<figure align="center">
            <artwork align="center"><![CDATA[Value   Description                     Reference
-----------------------------------------------------
  0    Reserved                         This document
  1
        document:</t>

<!--[rfced] We had the following questions/comments related to Table
     5:

a) Please review our update to the title to include "Sub-TLV".

Original:
Table 5: SR Policy Segment List Code Points

Current:
Table 5: SR Policy Segment List Sub-TLV Code Points

b) We note that Table 5 includes "Segment Type A sub-TLV           This document
  2    Deprecated                       This document sub-TLV".  Elsewhere
in the document, we see "Type A Segment Sub-TLV".  Further, we see
Type-1 (using a hyphen while lettered types do not).  Please review
all of these differences and let us know if/how these should be made
consistent.

c) In the document, we see points 3-8   Unassigned
  9    Weight sub-TLV                   This document
 10    Deprecated                       This document
 11    Deprecated                       This document
 12    Deprecated                       This document
 13 as "Unassigned".  At
https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#color-extended-community-flags,
we see Segment Type B sub-TLV           This C - Type H sub-TLV.  The same is true for points
14-16 (this document includes them in the 14-255 Unassigned

     Table 5: SR "Unassigned").
Please review and let us know what, if any, updates are necessary.

-->

<table>
  <name>SR Policy Segment List Sub-TLV Code Points

]]></artwork>
          </figure></t> Points</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Reserved</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Segment Type A sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Deprecated</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>3-8</td>
      <td colspan="2">Unassigned</td>
    </tr>
    <tr>
      <td>9</td>
      <td>Weight sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>10</td>
      <td>Deprecated</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>11</td>
      <td>Deprecated</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>12</td>
      <td>Deprecated</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>13</td>
      <td>Segment Type B sub-TLV</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>14-255</td>
      <td colspan="2">Unassigned</td>
    </tr>
  </tbody>
</table>

      </section>
      <section anchor="IANABSIDFLAGS" title="SR numbered="true" toc="default">
        <name>SR Policy Binding SID Flags"> Flags</name>
        <t>This document requests the creation of creates a new registry called "SR
        Policy Binding SID Flags" under the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation"
        registry.
        registry group. The allocation registration policy of this registry is "Standards Action"
        according to
        (see <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>).</t>
        <t>The following flags are defined:<figure align="center">
            <artwork align="center"><![CDATA[ Bit     Description                               Reference
-----------------------------------------------------------------
   0     Specified-BSID-Only defined:</t>

<table>
  <name>SR Policy Binding SID Flags</name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Specified-BSID-Only Flag (S-Flag)         This document
   1     Drop (S-Flag)</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Drop Upon Invalid Flag (I-Flag)           This document
 2-7     Unassigned

     Table 6: SR Policy Binding SID Flags

]]></artwork>
          </figure></t> (I-Flag)</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>2-7</td>
      <td colspan="2">Unassigned</td>
    </tr>
  </tbody>
</table>

      </section>
      <section anchor="IANASRV6BSIDFLAGS"
               title="SR numbered="true" toc="default">
        <name>SR Policy SRv6 Binding SID Flags"> Flags</name>
        <t>This document requests the creation of creates a new registry called "SR
        Policy SRv6 Binding SID Flags" under the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation"
        registry.
        registry group. The allocation registration policy of this registry is "Standards Action"
        according to
        (see <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>).</t>
        <t>The following flags are defined:<figure align="center">
            <artwork align="center"><![CDATA[ Bit     Description                               Reference
-----------------------------------------------------------------
   0     Specified-BSID-Only defined:</t>

<table>
  <name>SR Policy SRv6 Binding SID Flags</name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Specified-BSID-Only Flag (S-Flag)         This document
   1     Drop (S-Flag)</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Drop Upon Invalid Flag (I-Flag)           This document
   2     SRv6 (I-Flag)</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>2</td>
      <td>SRv6 Endpoint Behavior & &amp; SID Structure Flag (B-Flag)               This document
 3-7     Unassigned

     Table 7: SR Policy SRv6 Binding SID Flags
                                 ]]></artwork>
          </figure></t> (B-Flag)</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>3-7</td>
      <td colspan="2">Unassigned</td>
    </tr>
  </tbody>
</table>

      </section>
      <section anchor="IANASIDFLAGS" title="SR numbered="true" toc="default">
        <name>SR Policy Segment Flags"> Flags</name>
        <t>This document requests the creation of creates a new registry called "SR
        Policy Segment Flags" under the "BGP "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry. registry group.
        The allocation registration policy of this registry is "IETF Review" according to (see <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>).</t>
        <t>The following flags are defined:<figure align="center">
            <artwork align="center"><![CDATA[ Bit     Description                                Reference
------------------------------------------------------------------
   0     Segment Verification Flag (V-Flag) defined:</t>

<!--[rfced] We had the following questions/comments regarding Section
     6.8 and the corresponding IANA registry at https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#sr-policy-segment-flags:

a) This document lists Bits 1-2    Unassigned
   3     SRv6 as "Unassigned" while the IANA
registry lists entries for these values (the A-Flag and S-Flag).
Please review and let us know what, if any, updates need to be made
for consistency.

-->

<table>
  <name>SR Policy Segment Flags</name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Segment Verification Flag (V-Flag)</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>1-2</td>
      <td colspan="2">Unassigned</td>
    </tr>
    <tr>
      <td>3</td>
      <td>SRv6 Endpoint Behavior & &amp; SID Structure Flag (B-Flag)                This document
 4-7     Unassigned

     Table 8: SR Policy Segment Flags
                                ]]></artwork>
          </figure></t> (B-Flag)</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>4-7</td>
      <td colspan="2">Unassigned</td>
    </tr>
  </tbody>
</table>

      </section>
      <section anchor="IANAEXTCOMCOFIELD"
               title="Color numbered="true" toc="default">
        <name>Color Extended Community Color-Only Types"> Types</name>
        <t>This document requests the creation of creates a new registry called "Color
        Extended Community Color-Only Types" under the "BGP "Border Gateway Protocol (BGP) Tunnel
        Encapsulation" registry group for assignment of codepoints code points (values 0 through
        3) in the Color-Only Type field of the Color Extended Community Flags
        field. The allocation registration policy of this registry is "Standards Action"
        according to
        (see <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>).</t>
        <t>The following types are defined:<figure align="center">
            <artwork align="center"><![CDATA[ Type  Description                           Reference
-----------------------------------------------------------
  0    Specific defined:</t>

<table>
  <name>Color Extended Community Color-Only Types</name>
  <thead>
    <tr>
      <th>Type</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Specific Endpoint Match               This document
  1    Specific Match</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Specific or Null Endpoint Match       This document
  2    Specific, Match</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Specific, Null, or Any Endpoint Match This document
  3    Unassigned                            This document

     Table 9: Color Extended Community Color-Only Types
 ]]></artwork>
          </figure></t> Match</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Unassigned</td>
      <td>RFC 9830</td>
    </tr>
  </tbody>
</table>

      </section>
      <section anchor="IANAENLP" title="SR numbered="true" toc="default">
        <name>SR Policy ENLP Values">
        <t>Note to IANA (RFC editor to remove this before publication): The
        new registry creation request below is also present in the
        draft-ietf-pce-segment-routing-policy-cp. IANA is requested to process
        the registry creation via the first of these two documents to reach
        publication stage and the authors of the other document would update
        the IANA considerations suitably.</t>

        <t>This document requests IANA to Values</name>
        <t>IANA will maintain a new registry under the
        "Segment Routing" registry group with the allocation registration policy of
        "Standards Action" (see <xref target="RFC8126"/>. target="RFC8126" format="default"/>). The new registry is
        called "SR Policy ENLP Values" and contains the codepoints code points allocated
        to the "ENLP" field defined in <xref target="ENLPTLV"/>. target="ENLPTLV" format="default"/>. The registry
        contains the following codepoints, with initial values, to be assigned
        by IANA with code points:</t>

<!--[rfced] We had the reference set following questions/comments related to this document:<figure>
            <artwork><![CDATA[+-------+-----------------------------------+---------------+
| Section
     6.10 and its corresponding registry at:
     https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#sr-policy-enlp-values:

a) There is a slight difference in the Description of Code  |                                   |               |
| Point |  Description                      |  Reference    |
+-------+-----------------------------------+---------------+
|   0   | 0.
Please let us know if/how these may be made consistent.

This document:
Reserved (not to be used)         | This document |
|   1   | Push

IANA registry:
Reserved

-->

<table>
  <name>SR Policy ENLP Values</name>
  <thead>
    <tr>
      <th>Code Point</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Reserved (not to be used)</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Push an IPv4 Explicit NULL label  | This document |
|       | on an unlabeled IPv4 packet, packet but  |               |
|       | do not push an IPv6 Explicit NULL |               |
|       | label on an unlabeled IPv6 packet |               |
|   2   | Push packet</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Push an IPv6 Explicit NULL label  | This document |
|       | on an unlabeled IPv6 packet, packet but  |               |
|       | do not push an IPv4 Explicit NULL |               |
|       | label on an unlabeled IPv4 packet |               |
|   3   | Push packet</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Push an IPv6 Explicit NULL label  | This document |
|       | on an unlabeled IPv6 packet, packet and  |               |
|       | push an IPv4 Explicit NULL label  |               |
|       | on an unlabeled IPv4 packet       |               |
|   4   | Do packet</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>4</td>
      <td>Do not push an Explicit NULL      | This document |
|       | label                             |               |
| 5-255 | Unassigned                        |               |
+-------+-----------------------------------+---------------+

     Table 10: SR Policy ENLP Values

]]></artwork>
          </figure></t> label</td>
      <td>RFC 9830</td>
    </tr>
    <tr>
      <td>5-255</td>
      <td colspan="2">Unassigned</td>
    </tr>
  </tbody>
</table>

      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security mechanisms of the base BGP security model apply to the
      extensions described in this document as well. See the Security
      Considerations section of <xref target="RFC4271"/> target="RFC4271" format="default"/> for a discussion of
      BGP security. Also, refer to <xref target="RFC4272"/> target="RFC4272" format="default"/> and <xref
      target="RFC6952"/> target="RFC6952" format="default"/> for analysis of security issues for BGP.</t>

<!--[rfced] In the following, how may we update to correct the
     connection between "address families" and "SAFI"?  If our
     suggested text does not correctly capture your intent, please let
     us know how to rephrase.

Original:
BGP peering sessions for address-families other than SR Policy SAFI
may be set up to routers outside the SR domain.

Perhaps:
BGP peering sessions for address families other than those that use
the SR Policy SAFI may be set up to routers outside the SR domain.

-->

      <t>The BGP SR Policy extensions specified in this document enable
      traffic engineering and service programming use-cases use cases within an SR
      domain as described in <xref target="RFC9256"/>. target="RFC9256" format="default"/>. SR operates within a
      trusted SR domain <xref target="RFC8402"/> and target="RFC8402" format="default"/>; its security
      considerations also apply to BGP sessions when carrying SR Policy
      information. The SR Policies distributed by BGP are expected to be used
      entirely within this trusted SR domain domain, which comprises a single AS or
      multiple ASes/domains ASes / domains within a single provider network. Therefore,
      precaution is necessary to ensure that the SR Policy information
      advertised via BGP sessions is limited to nodes in a secure manner
      within this trusted SR domain. BGP peering sessions for address-families address families
      other than SR Policy SAFI may be set up to routers outside the SR
      domain. The isolation of BGP SR Policy SAFI peering sessions may be used
      to ensure that the SR Policy information is not advertised by accident
      or in error to an EBGP peering session outside the SR domain.</t>
      <t>Additionally, it may be considered a consideration that the export of SR Policy
      information, as described in this document, constitutes a risk to
      confidentiality of mission-critical or commercially sensitive
      information about the network (more specifically endpoint/node
      addresses, SR SIDs, and the SR Policies deployed). BGP peerings are not
      automatic and require configuration; thus, it is the responsibility of
      the network operator to ensure that only trusted nodes (that include
      both routers and controller applications) within the SR domain are
      configured to receive such information.</t>
    </section>
    <section anchor="Manageability" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>The specification of BGP models is an ongoing work based on <xref
      target="I-D.ietf-idr-bgp-model"/> and target="I-D.ietf-idr-bgp-model" format="default"/>; its future extensions are expected
      to cover the SR Policy SAFI. Existing BGP operational procedures also
      apply to the SAFI specified in this document. The management,
      operations, and monitoring of BGP speakers and the SR Policy SAFI
      sessions between them are not very different from other BGP sessions and
      can be managed using the same data models.</t>
      <t>The YANG data model for the operation and management of SR Policies <xref
      target="I-D.ietf-spring-sr-policy-yang"/> target="I-D.ietf-spring-sr-policy-yang" format="default"/> reports the SR Policies
      provisioned via BGP SR Policy SAFI along with their operational
      states.</t>
    </section>

  </middle>
  <back>

    <displayreference target="I-D.ietf-idr-bgp-model" to="BGP-YANG-MODEL"/>
    <displayreference target="I-D.ietf-idr-bgp-ls-sr-policy" to="SR-BGP-LS"/>
 <displayreference target="I-D.ietf-spring-sr-policy-yang" to="SR-POLICY-YANG"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1997.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2545.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6286.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"/>
<!--  draft-ietf-idr-bgp-model-18
IESG State: expired as of 2024-10-21. -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-model.xml"/>

<!--  draft-ietf-idr-bgp-ls-sr-policy-14
In queue: EDIT*R  as of 2025-06-29-->

<reference anchor="I-D.ietf-idr-bgp-ls-sr-policy" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-16">
   <front>
      <title>Advertisement of Segment Routing Policies using BGP Link-State</title>
      <author initials="S." surname="Previdi" fullname="Stefano Previdi">
         <organization>Individual</organization>
      </author>
      <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="J." surname="Dong" fullname="Jie Dong">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="H." surname="Gredler" fullname="Hannes Gredler">
         <organization>RtBrick Inc.</organization>
      </author>
      <author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
         <organization>Nvidia</organization>
      </author>
      <date month="March" day="3" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-sr-policy-16" />

</reference>

<!-- draft-ietf-spring-sr-policy-yang-04
IESG State: I-D Exists as of 03/06/25. -->

<reference anchor="I-D.ietf-spring-sr-policy-yang" target="https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-policy-yang-04">
   <front>
      <title>YANG Data Model for Segment Routing Policy</title>
      <author initials="K." surname="Raza" fullname="Syed Kamran Raza" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="T." surname="Saleh" fullname="Tarik Saleh">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="Z." surname="Shunwan" fullname="Zhuang Shunwan">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="D." surname="Voyer" fullname="Daniel Voyer">
         <organization>Bell Canada</organization>
      </author>
      <author initials="M." surname="Durrani" fullname="Muhammad Durrani">
         <organization>Equinix</organization>
      </author>
      <author initials="S." surname="Matsushima" fullname="Satoru Matsushima">
         <organization>SoftBank</organization>
      </author>
      <author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram">
         <organization>Juniper Networks</organization>
      </author>
      <date month="November" day="22" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-policy-yang-04" />

</reference>

<!--  [I-D.ietf-idr-bgp-sr-segtypes-ext]
     draft-ietf-idr-bgp-sr-segtypes-ext-07 is a companion document moving through the queue simultaneously -->

<!--[rfced] We note that this document has an Informative Reference
     entry to draft-ietf-idr-bgp-sr-segtypes-ext-07, which is moving
     through the RFC Editor queue simultaneously.

We have updated this reference entry to use its RFC-to-be form as we
assume the intent is to publish them together.

However, since this dependency is not normative, please indicate if
your preference is not to wait if
draft-ietf-idr-bgp-sr-segtypes-ext-07 has not completed AUTH48 prior
to this document (in which case, we would revert to the I-D version of
the reference entry). -->

<reference anchor="RFC9831" target="https://www.rfc-editor.org/info/rfc9831">
   <front>
      <title>Segment Routing Segment Types Extensions for BGP SR Policy</title>
      <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="S." surname="Previdi" fullname="Stefano Previdi">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="P." surname="Mattes" fullname="Paul Mattes">
         <organization>Microsoft</organization>
      </author>
      <author initials="D." surname="Jain" fullname="Dhanendra Jain">
         <organization>Google</organization>
      </author>
      <date month="July" year="2025" />
   </front>
   <seriesInfo name="RFC" value="9831" />
   <seriesInfo name='DOI' value='10.17487/RFC9831'/>

</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4456.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"/>
      </references>
    </references>

    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors of this document would like to thank Shyam Sethuram, John
      Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene,
      Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, Jakob
      Heitz, Viral Patel, Peng Shaofu, Cheng Li, Martin Vigoureux, John
      Scudder, Vincent Roca, Brian Haberman, Mohamed Boucadair, Shunwan
      Zhuang, Andrew Alston, Jeffrey <contact
      fullname="Shyam Sethuram"/>, <contact fullname="John Scudder"/>,
      <contact fullname="Przemyslaw Krol"/>, <contact fullname="Alex
id      Bogdanov"/>, <contact fullname="Nandan Saha"/>, <contact fullname="Bruno
      Decraene"/>, <contact fullname="Gurusiddesh Nidasesi"/>, <contact
      fullname="Kausik Majumdar"/>, <contact fullname="Zafar Ali"/>, <contact
      fullname="Swadesh Agarwal"/>, <contact fullname="Jakob Heitz"/>,
      <contact fullname="Viral Patel"/>, <contact fullname="Peng Shaofu"/>,
      <contact fullname="Cheng Li"/>, <contact fullname="Martin Vigoureux"/>,
      <contact fullname="John Scudder"/>, <contact fullname="Vincent Roca"/>,
      <contact fullname="Brian Haberman"/>, <contact fullname="Mohamed
      Boucadair"/>, <contact fullname="Shunwan Zhuang"/>, <contact
      fullname="Andrew Alston"/>, <contact fullname="Jeffrey (Zhaohui) Zhang, Nagendra Nainar, Rajesh
      Zhang"/>, <contact fullname="Nagendra Nainar"/>, <contact
      fullname="Rajesh Melarcode Venkateswaran, Nat Kao, Boris Hassanov, Vincent Roca, Russ
      Housley, and Dan Romascanu Venkateswaran"/>, <contact fullname="Nat
      Kao"/>, <contact fullname="Boris Hassanov"/>, <contact fullname="Vincent
      Roca"/>, <contact fullname="Russ Housley"/>, and <contact fullname="Dan
      Romascanu"/> for their comments and review of this document. The authors
      would like to thank Susan Hares <contact fullname="Susan Hares"/> for her detailed
      shepherd review that helped in improving the document.</t>
    </section>
    <section anchor="Contributors" title="Contributors">
      <figure>
        <artwork><![CDATA[Eric Rosen
Juniper Networks
US

Email: erosen@juniper.net]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Arjun Sreekantiah
Cisco Systems
US

Email: asreekan@cisco.com]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Acee Lindem
Cisco Systems
US

Email: acee@cisco.com]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Siva Sivabalan
Cisco Systems
US

Email: msiva@cisco.com]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Imtiyaz Mohammad
Arista Networks
India

Email: imtiyaz@arista.com]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Gaurav Dawra
Cisco Systems
US

Email: gdawra.ietf@gmail.com]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Peng Shaofu
ZTE Corporation
China

Email: peng.shaofu@zte.com.cn]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Steven Lin
Calix
USA

Email: steven.lin@calix.com]]></artwork>
      </figure> numbered="false" toc="default">
      <name>Contributors</name>

    <contact fullname="Eric Rosen">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>erosen@juniper.net</email>
      </address>
    </contact>

    <contact fullname="Arjun Sreekantiah">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>asreekan@cisco.com</email>
      </address>
    </contact>

    <contact fullname="Acee Lindem">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>acee@cisco.com</email>
      </address>
    </contact>

    <contact fullname="Siva Sivabalan">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>msiva@cisco.com</email>
      </address>
    </contact>

    <contact fullname="Imtiyaz Mohammad">
      <organization>Arista Networks</organization>
      <address>
        <postal>
          <country>India</country>
        </postal>
        <email>imtiyaz@arista.com</email>
      </address>
    </contact>

    <contact fullname="Gaurav Dawra">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>gdawra.ietf@gmail.com</email>
      </address>
    </contact>

    <contact fullname="Peng Shaofu">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>peng.shaofu@zte.com.cn</email>
      </address>
    </contact>

    <contact fullname="Steven Lin">
      <organization>Calix</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>steven.lin@calix.com</email>
      </address>
    </contact>

    </section>
  </middle>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include="reference.RFC.8986"?>
    </references>

    <references title="Informational References">
      <?rfc include="reference.RFC.4272"?>

      <?rfc include="reference.I-D.ietf-idr-bgp-model"?>

      <?rfc include="reference.I-D.ietf-idr-bgp-ls-sr-policy"?>

      <?rfc include="reference.I-D.ietf-spring-sr-policy-yang"?>

      <?rfc include="reference.I-D.ietf-idr-bgp-sr-segtypes-ext"?>

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

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

      <?rfc include="reference.RFC.9552"?>
    </references>

<!-- [rfced] We had the following questions/comments related to
     abbreviation use throughout the document:

a) FYI - We have added expansions for abbreviations upon first use per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

b) We will update to have the abbreviation expanded upon first use and
then use the abbreviation thereafter (per the guidance at
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev) *except when
in a sub-TLV name* for the following abbreviations unless we hear
objection.

Segment Routing (SR)
candidate path (CP)
subsequent address family (SAFI)
Route Reflectors (RR)
Binding SID (BSID)
Explicit NULL Label Policy (ENLP)

c) May we expand NH as Next Hop?

-->

<!--[rfced] We had the following questions related to terminology use
     throughout the document.

a) Should the following terms be made consistent with regard to
capitalization, hyphenation, etc.?  If so, please let us know how to
update.

SR Policy vs. SR policy vs. policy
BGP UPDATE message vs. BGP update message vs. BGP Update
Route Target Extended Community vs. route target extended community
Tunnel Type vs. Tunnel-Type vs. Tunnel-type
Flags field vs. Flag octet (singular and field vs. octet)
Color vs. color
Endpoint vs. endpoint
Length field vs. length field (and simply length)
"Drop Upon Invalid" behavior vs. "drop upon invalid" config
Segment Type vs. segment type vs. Segment Types sub-TLV (plural)
Explicit NULL Label vs. Explicit NULL label

b) We see that some field names are in double quotes.  Should this be
made uniform throughout?  If so, are quotation marks or no quotation
marks preferred?

"Flags" field vs. Flags field

-->

<!--[rfced] Please review uses of the slash character "/" in the body
     of the document and consider whether "and", "or", or "and/or"
     might be clearer for the reader. -->

<!-- [rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any changes are needed.  Updates of this
     nature typically result in more precise language, which is
     helpful for readers.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->

  </back>
</rfc>