<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true"
docName="draft-ietf-spring-segment-routing-policy-22" number="9256" ipr="trust200902" updates="8402"> updates="8402"
obsoletes="" xml:lang="en" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="SR Policy Architecture">Segment Routing Policy
    Architecture</title>
    <seriesInfo name="RFC" value="9256"/>

    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Pegasus Parc</street>

          <city>De
	  <extaddr>Pegasus Parc</extaddr>
	  <street>De kleetlaan 6a</city>

          <region>DIEGEM</region>

          <code>BRABANT 1831</code>

          <country>BELGIUM</country> 6a</street>
          <city>Diegem</city>

          <code>1831</code>
          <country>Belgium</country>
        </postal>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Daniel Voyer" initials="D." surname="Voyer">
      <organization>Bell Canada</organization>
      <address>
        <postal>
          <street>671 de la gauchetiere W</street>
          <city>Montreal</city>
          <region>Quebec</region>
          <code>H3B 2M8</code>
          <country>Canada</country>
        </postal>
        <email>daniel.voyer@bell.ca</email>
      </address>
    </author>
    <author fullname="Alex Bogdanov" initials="A." surname="Bogdanov">
      <organization>British Telecom</organization>
      <address>
        <email>alex.bogdanov@bt.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-6399</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>pamattes@microsoft.com</email>
      </address>
    </author>
    <date year=""/>

    <workgroup>SPRING Working Group</workgroup> year="2022" month="July" />
    <area>rtg</area>
    <workgroup>spring</workgroup>

    <keyword>Segment Routing</keyword>
    <keyword>SR Policy</keyword>
    <keyword>SR-MPLS</keyword>
    <keyword>SRv6</keyword>
    <keyword>Traffic Engineering</keyword>

    <abstract>
      <t>Segment Routing (SR) allows a node to steer a packet flow along any
      path. Intermediate per-path states are eliminated thanks to source
      routing. SR Policy is an ordered list of segments (i.e., instructions)
      that represent a source-routed policy. Packet flows are steered into a an
      SR Policy on a node where it is instantiated called a headend node. The
      packets steered into an SR Policy carry an ordered list of segments
      associated with that SR Policy.</t>
      <t>This document updates RFC8402 RFC 8402 as it details the concepts of SR Policy
      and steering into an SR Policy.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Segment Routing (SR) <xref target="RFC8402"/> target="RFC8402" format="default"/> allows a node to steer
      a packet flow along any path. The headend is a node where the
      instructions for source routing (i.e., segments) are written into the
      packet and
      packet.  It hence becomes the starting node for a specific segment
      routing path. Intermediate per-path states are eliminated thanks to
      source routing.</t>
      <t>A Segment Routing Policy (SR Policy) <xref target="RFC8402"/> target="RFC8402" format="default"/> is an
      ordered list of segments (i.e., instructions) that represent a
      source-routed policy. The headend node is said to steer a flow into a an SR
      Policy. The packets steered into an SR Policy have an ordered list of
      segments associated with that SR Policy written into them. <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
      Segment Routing over IPv6 (SRv6) with the use of the Segment Routing
      Header (SRH).</t>
      <t><xref target="RFC8402"/> target="RFC8402" format="default"/> introduces the SR Policy construct and
      provides an overview of how it is leveraged for Segment Routing
      use-cases.
      use cases. This document updates <xref target="RFC8402"/> target="RFC8402" format="default"/> to specify
      detailed concepts of SR Policy and steering packets into an SR Policy.
      It applies equally to the SR-MPLS and SRv6 instantiations of segment
      routing.</t>
      <section anchor="reqlang" 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="SR-policy" title="SR Policy"> numbered="true" toc="default">
      <name>SR Policy</name>
      <t>The general concept of SR Policy provides a framework that enables
      the instantiation of an ordered list of segments on a node for
      implementing a source routing policy for the steering of traffic for a
      specific purpose (e.g. (e.g., for a specific SLA) Service Level Agreement (SLA)) from that node.</t>
      <t>The Segment Routing architecture <xref target="RFC8402"/> target="RFC8402" format="default"/> specifies
      that any instruction can be bound to a segment. Thus, an SR Policy can
      be built using any type of Segment Identifier (SID) including those
      associated with topological or service instructions.</t>
      <t>This section defines the key aspects and constituents of an SR
      Policy.</t>

      <section anchor="SR-policy-identification"
               title="Identification numbered="true" toc="default">
        <name>Identification of an SR Policy"> Policy</name>
        <t>An SR Policy MUST <bcp14>MUST</bcp14> be identified through the tuple &lt;headend,
        color, endpoint&gt;. &lt;Headend,
        Color, Endpoint&gt;. In the context of a specific headend, an SR
        policy MUST
        Policy <bcp14>MUST</bcp14> be identified by the &lt;color, endpoint&gt; &lt;Color, Endpoint&gt; tuple.</t>
        <t>The headend is the node where the policy is
        instantiated/implemented. The headend is specified as an IPv4 or IPv6
        address and MUST <bcp14>MUST</bcp14> resolve to a unique node in the SR domain <xref
        target="RFC8402"/>.</t> target="RFC8402" format="default"/>.</t>
        <t>The endpoint indicates the destination of the policy. The endpoint
        is specified as an IPv4 or IPv6 address and SHOULD <bcp14>SHOULD</bcp14> resolve to a unique
        node in the domain. In a specific case (refer to <xref
        target="Steering-optional-bgp-color-only-steering"/>), target="Steering-optional-bgp-color-only-steering" format="default"/>), the endpoint
        can be the unspecified address (0.0.0.0 for IPv4, :: for IPv6) and in
        this case, the destination of the policy is indicated by the last
        segment in the segment list(s).</t>
        <t>The color is an unsigned non-zero 32-bit integer value that
        associates the SR Policy with an intent or objective (e.g.
        low-latency).</t> (e.g.,
        low latency).</t>

        <t>The endpoint and the color are used to automate the steering of
        service or transport routes on SR Policies (refer to <xref
        target="Steering"/>).</t> target="Steering" format="default"/>).</t>
        <t>An implementation MAY <bcp14>MAY</bcp14> allow the assignment of a symbolic name
        comprising printable ASCII <xref target="RFC0020"/> target="RFC0020" format="default"/> characters (i.e.,
        0x20 to 0x7E) to an SR Policy to serve as a user-friendly attribute
        for debugging and troubleshooting purposes. Such symbolic names may
        identify an SR Policy when the naming scheme ensures uniqueness. The
        SR Policy name MAY <bcp14>MAY</bcp14> also be signaled along with a candidate path of the
        SR Policy (refer to <xref target="SR-policy-candidate-path"/>). target="SR-policy-candidate-path" format="default"/>). An SR
        Policy MAY <bcp14>MAY</bcp14> have multiple names associated with it in the scenario
        where the headend receives different SR Policy names along with
        different candidate paths for the same SR Policy via the same or
        different sources.</t>
      </section>
      <section anchor="SR-policy-candidate-path"
               title="Candidate numbered="true" toc="default">
        <name>Candidate Path and Segment List"> List</name>
        <t>An SR Policy is associated with one or more candidate paths. A
        candidate path is the unit for signaling of an SR Policy to a headend
        via protocol extensions like the Path Computation Element (PCE)
        Communication Protocol (PCEP) <xref target="RFC8664"/> target="RFC8664" format="default"/> <xref
        target="I-D.ietf-pce-segment-routing-policy-cp"/> target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/> or BGP SR Policy
        <xref target="I-D.ietf-idr-segment-routing-te-policy"/>.</t> target="I-D.ietf-idr-segment-routing-te-policy" format="default"/>.</t>
        <t>A Segment-List segment list represents a specific source-routed path to send
        traffic from the headend to the endpoint of the corresponding SR
        policy.</t>
        Policy.</t>
        <t>A candidate path is either dynamic, explicit, or composite.</t>
        <t>An explicit candidate path is expressed as a Segment-List segment list or a set
        of Segment-Lists.</t> segment lists.</t>
        <t>A dynamic candidate path expresses an optimization objective and a
        set of constraints for a specific data plane (i.e., SR-MPLS or SRv6).
        The headend (potentially with the help of a PCE) computes a solution
        Segment-List
        segment list (or set of Segment-Lists) segment lists) that solves the optimization
        problem.</t>
        <t>If a candidate path is associated with a set of Segment-Lists, segment lists, each
        Segment-List
        segment list is associated with weight for weighted load balancing
        (refer to <xref target="SR-policy-instantiation"/> target="SR-policy-instantiation" format="default"/> for details). The
        default weight is 1.</t>
        <t>A composite candidate path acts as a container for grouping SR
        Policies. The composite candidate path construct enables the
        combination of SR Policies, each with explicit candidate paths and/or
        dynamic candidate paths with potentially different optimization
        objectives and constraints, for load-balanced steering of packet flows
        over its constituent SR Policies. The following criteria apply for
        inclusion of constituent SR Policies using a composite candidate path
        under a parent SR Policy:<list style="symbols">
            <t>the Policy:</t>
        <ul spacing="normal">
          <li>The endpoints of the constituent SR Policies and the parent SR
            Policy MUST <bcp14>MUST</bcp14> be identical</t>

            <t>The identical.</li>
          <li>The colors of each of the constituent SR Policies and the
            parent SR Policy MUST <bcp14>MUST</bcp14> be different</t>

            <t>the different.</li>
          <li>The constituent SR Policies MUST NOT <bcp14>MUST NOT</bcp14> use composite candidate
            paths</t>
          </list></t>
            paths.</li>
        </ul>
        <t>Each constituent SR Policy of a composite candidate path is
        associated with weight for load-balancing purposes (refer to <xref
        target="SR-policy-instantiation"/> target="SR-policy-instantiation" format="default"/> for details). The default weight is
        1.</t>

        <t>The <xref target="SR-policy-summary"/>
        <t><xref target="SR-policy-summary" format="default"/> illustrates an information
        model for hierarchical relationships between the SR Policy constructs
        described in this section.</t>
      </section>
      <section anchor="SR-policy-protocol-origin"
               title="Protocol-Origin numbered="true" toc="default">
        <name>Protocol-Origin of a Candidate Path"> Path</name>

	<t>A headend may be informed about a candidate path for an SR Policy
        &lt;color, endpoint&gt;
        &lt;Color, Endpoint&gt; by various means including: via configuration,
        PCEP <xref target="RFC8664"/> target="RFC8664" format="default"/> <xref
        target="I-D.ietf-pce-segment-routing-policy-cp"/> target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/>, or BGP <xref
        target="I-D.ietf-idr-segment-routing-te-policy"/>.</t> target="I-D.ietf-idr-segment-routing-te-policy" format="default"/>.</t>
        <t>Protocol-Origin of a candidate path is an 8-bit value associated
        with the mechanism or protocol used for signaling/provisioning the SR
        Policy. It helps identify the protocol/mechanism that provides or
        signals the candidate path and indicates its preference relative to
        other protocols/mechanisms.</t>
        <t>The head-end headend assigns different Protocol-Origin values to each
        source of SR Policy information. The Protocol-Origin value is used as
        a tie-breaker tiebreaker between candidate paths of equal preference, Preference, as
        described in <xref target="SR-policy-candidate-path-active"/>. target="SR-policy-candidate-path-active" format="default"/>. The
        table below specifies the RECOMMENDED <bcp14>RECOMMENDED</bcp14> default values of
        Protocol-Origin:</t>

        <texttable
        <table anchor="table_ex" title="Protocol-Origin default values">
          <ttcol align="center">Protocol-Origin</ttcol>

          <ttcol align="left">Description</ttcol>

          <c>10</c>

          <c>PCEP</c>

          <c>20</c>

          <c>BGP SR Policy</c>

          <c>30</c>

          <c>Via Configuration</c>
        </texttable> align="center">
          <name>Protocol-Origin Default Values</name>
          <thead>
            <tr>
              <th align="center">Protocol-Origin</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">10</td>
              <td align="left">PCEP</td>
            </tr>
            <tr>
              <td align="center">20</td>
              <td align="left">BGP SR Policy</td>
            </tr>
            <tr>
              <td align="center">30</td>
              <td align="left">Via Configuration</td>
            </tr>
          </tbody>
        </table>

        <t>Note that the above order is to satisfy the need for having a clear
        ordering
        ordering, and implementations MAY <bcp14>MAY</bcp14> allow modifications of these default
        values assigned to protocols on the headend along similar lines as a
        routing administrative distance. Its application in the candidate path
        selection is described in <xref
        target="SR-policy-candidate-path-active"/>.</t> target="SR-policy-candidate-path-active" format="default"/>.</t>
      </section>
      <section anchor="SR-policy-candidate-path-originator"
               title="Originator numbered="true" toc="default">
        <name>Originator of a Candidate Path">
        <t>Originator Path</name>
        <t>The Originator identifies the node which that provisioned or signaled the
        candidate path on the headend. The originator Originator is expressed in the form
        of a 160-bit numerical value formed by the concatenation of the fields
        of the tuple &lt;Autonomous System Number (ASN), node-address&gt; as
        below:</t>

        <t><list style="symbols">
            <t>Autonomous

	<dl>
	  <dt>Autonomous System Number (ASN) : represented (ASN):
	  </dt>
	  <dd>represented as a 4-byte number. If 2-byte ASNs are in use, the
	  low-order 16 bits MUST <bcp14>MUST</bcp14> be used, and the high-order
	  bits MUST <bcp14>MUST</bcp14> be set to zero.</t>

            <t>Node Address : represented 0.
	  </dd>

	  	  <dt>Node Address:
	  </dt>
	  <dd>represented as a 128-bit value. IPv4 addresses
            MUST
	  <bcp14>MUST</bcp14> be encoded in the lowest 32 bits, and the
	  high-order bits
            MUST <bcp14>MUST</bcp14> be set to zero.</t>
          </list></t> 0.
	  </dd>

</dl>

<t>Its application in the candidate path selection is described in
        <xref target="SR-policy-candidate-path-active"/>.</t> target="SR-policy-candidate-path-active" format="default"/>.</t>
        <t>When provisioning is via configuration, the ASN and node address
        MAY
        <bcp14>MAY</bcp14> be set to either the headend or the provisioning controller/node
        ASN and address. The default value is 0 for both AS and node
        address.</t>
        <t>When signaling is via PCEP, it is the IPv4 or IPv6 address of the
        PCE
        PCE, and the AS number is expected to be set to 0 by default when not
        available or known.</t>
        <t>When signaling is via BGP SR Policy, the ASN and Node Address node address are
        provided by BGP (refer to <xref
        target="I-D.ietf-idr-segment-routing-te-policy"/>) target="I-D.ietf-idr-segment-routing-te-policy" format="default"/>) on the headend.</t>
      </section>
      <section anchor="SR-policy-candidate-path-discriminator"
               title="Discriminator numbered="true" toc="default">
        <name>Discriminator of a Candidate Path"> Path</name>
        <t>The Discriminator is a 32-bit value associated with a candidate
        path that uniquely identifies it within the context of an SR Policy
        from a specific Protocol-Origin as specified below:<list
            style="symbols">
            <t>When below:</t>
        <ul spacing="normal">
          <li>When provisioning is via configuration, this is an
            implementation's configuration-model-specific a unique
          identifier for a candidate path. path; it is specific to the
          implementation's configuration model. The default value is 0.</t>

            <t>When 0.</li>
          <li>When signaling is via PCEP, the method to uniquely signal an
            individual candidate path along with its discriminator Discriminator is
            described in <xref
            target="I-D.ietf-pce-segment-routing-policy-cp"/>. target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/>. The default
            value is 0.</t>

            <t>When 0.</li>
          <li>When signaling is via BGP SR Policy, the BGP process receiving
          the route provides the distinguisher (refer to Section 2.1 of <xref target="I-D.ietf-idr-segment-routing-te-policy"/>)
          target="I-D.ietf-idr-segment-routing-te-policy"  format="default"/>) as the
            discriminator. Discriminator. Note that
          the BGP best path selection is applied before the route is supplied
          as a candidate path, so only a single candidate path for a given SR
          Policy will be seen for a given
            discriminator.</t>
          </list></t> Discriminator.</li>
        </ul>
        <t>Its application in the candidate path selection is described in
        <xref target="SR-policy-candidate-path-active"/>.</t> target="SR-policy-candidate-path-active" format="default"/>.</t>
      </section>
      <section anchor="SR-policy-candidate-path-identification"
               title="Identification numbered="true" toc="default">
        <name>Identification of a Candidate Path"> Path</name>
        <t>A candidate path is identified in the context of a single SR
        Policy.</t>
        <t>A candidate path is not shared across SR Policies.</t>
        <t>A candidate path is not identified by its Segment-List(s).</t>

        <t><list> segment list(s).</t>

	<aside>
          <t>If CP1 is a candidate path of SR Policy Pol1 and CP2 is a
            candidate path of SR Policy Pol2, then these two candidate paths
            are independent, even if they happen to have the same
            Segment-List.
            segment list. The Segment-List segment list does not identify a candidate path.
            The Segment-List segment list is an attribute of a candidate path.</t>
          </list></t> path.
	  </t>
	</aside>

        <t>The identity of a candidate path MUST <bcp14>MUST</bcp14> be uniquely established in
        the context of an SR Policy &lt;headend, color, endpoint&gt; &lt;Headend, Color, Endpoint&gt; to handle
        add, delete delete, or modify operations on them in an unambiguous manner
        regardless of their source(s).</t>

	<t>The tuple &lt;Protocol-Origin, originator, discriminator&gt; Originator, Discriminator&gt;
        uniquely identifies a candidate path.</t>
        <t>Candidate paths MAY <bcp14>MAY</bcp14> also be assigned or signaled with a symbolic
        name comprising printable ASCII <xref target="RFC0020"/> target="RFC0020" format="default"/> characters
        (i.e., 0x20 to 0x7E) to serve as a user-friendly attribute for
        debugging and troubleshooting purposes. Such symbolic names MUST NOT <bcp14>MUST NOT</bcp14>
        be considered as identifiers for a candidate path. The signaling of
        the candidate path name via BGP and PCEP is described in <xref
        target="I-D.ietf-pce-segment-routing-policy-cp"/> target="I-D.ietf-idr-segment-routing-te-policy" format="default"/> and <xref
        target="I-D.ietf-idr-segment-routing-te-policy"/> target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/>, respectively.</t>
      </section>
      <section anchor="SR-policy-candidate-path-preference"
               title="Preference numbered="true" toc="default">
        <name>Preference of a Candidate Path"> Path</name>
        <t>The preference Preference of the candidate path is used to select the best
        candidate path for an SR Policy. It is a 32-bit value where a higher
        value indicates higher preference and the default preference Preference value is
        100.</t>
        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that each candidate path of a given SR policy Policy has
        a different preference.</t> Preference.</t>
        <t>The signaling of the candidate path preference Preference via BGP and PCEP is
        described in <xref target="I-D.ietf-pce-segment-routing-policy-cp"/> target="I-D.ietf-idr-segment-routing-te-policy" format="default"/> and <xref target="I-D.ietf-idr-segment-routing-te-policy"/> target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/>,
        respectively.</t>
      </section>
      <section anchor="SR-policy-candidate-path-validity"
               title="Validity numbered="true" toc="default">
        <name>Validity of a Candidate Path"> Path</name>
        <t>A candidate path is usable when it is valid. The RECOMMEDED <bcp14>RECOMMENDED</bcp14>
        candidate path validity criterion is the validity of at least one of
        its constituent Segment-Lists. segment lists. The validation rules are specified in
        <xref target="Path-validity"/>.</t> target="Path-validity" format="default"/>.</t>
      </section>
      <section anchor="SR-policy-candidate-path-active"
               title="Active numbered="true" toc="default">

        <name>Active Candidate Path"> Path</name>
        <t>A candidate path is selected when it is valid and it is determined
        to be the best path of the SR Policy. The selected path is referred to
        as the "active path" of the SR policy Policy in this document.</t>
        <t>Whenever a new path is learned or an active path is deleted, the
        validity of an existing path changes changes, or an existing path is changed,
        the selection process MUST <bcp14>MUST</bcp14> be re-executed.</t>
        <t>The candidate path selection process operates primarily on the
        candidate path Preference. A candidate path is selected when it is
        valid and it has the highest preference Preference value among all the valid
        candidate paths of the SR Policy.</t>
        <t>In the case of multiple valid candidate paths of the same
        preference,
        Preference, the tie-breaking rules are evaluated on the identification
        tuple in the following order until only one valid best path is
        selected: <list style="numbers">
            <t>Higher </t>
        <ol spacing="normal" type="1"><li>The higher value of Protocol-Origin is selected.</t>

            <t>If selected.</li>
          <li>If specified by configuration, prefer the existing installed
            path.</t>

            <t>Lower
            path.</li>
          <li>The lower value of originator the Originator is selected.</t>

            <t>Finally, selected.</li>
          <li>Finally, the higher value of discriminator the Discriminator is selected.</t>
          </list></t> selected.</li>
        </ol>
        <t>The rules are framed with multiple protocols and sources in mind
        and hence may not follow the logic of a single protocol (e.g. (e.g., BGP best
        path selection). The motivation behind these rules are as follows:
        <list style="symbols">
            <t>The preference,
        </t>
        <ul spacing="normal">

	  <li>
The Preference, being the primary criterion, allows an operator to influence
selection across paths thus allowing provisioning of multiple path options,
e.g., CP1 is preferred as its Preference value is the highest, and if it
becomes
            invalid invalid, then fallback to CP2 with the next highest Preference value is selected,
and so on.  Since preference Preference works across protocol sources, it also enables
(where necessary) selective override of the default Protocol-Origin
preference, e.g., to prefer a path signaled via BGP SR Policy over what is
            configured.</t>

            <t>The
configured.</li>

	    <li>The Protocol-Origin allows an operator to set up a default
            selection mechanism across protocol sources, e.g., to prefer
            configured paths over paths signaled via BGP SR Policy or PCEP.</t>

            <t>The originator PCEP.</li>
          <li>The Originator allows an operator to have multiple redundant
            controllers and still maintain a deterministic behavior over which
            of them are preferred even if they are providing the same
            candidate paths for the same SR policies to the headend.</t>

            <t>The discriminator headend.</li>
          <li>The Discriminator performs the final tiebreaking tie-breaking step to ensure
            a deterministic outcome of selection regardless of the order in
            which candidate paths are signaled across multiple transport
            channels or sessions.</t>
          </list></t>

        <t>Section 4 of <xref
        target="I-D.filsfils-spring-sr-policy-considerations"/> sessions.</li>
        </ul>
        <t><xref target="I-D.filsfils-spring-sr-policy-considerations" format="default"/> provides a set
        of examples to illustrate the active candidate path selection
        rules.</t>
      </section>
      <section anchor="SR-policy-validity" title="Validity numbered="true" toc="default">
        <name>Validity of an SR Policy"> Policy</name>
        <t>An SR Policy is valid when it has at least one valid candidate
        path.</t>
      </section>
      <section anchor="SR-policy-instantiation"
               title="Instantiation numbered="true" toc="default">
        <name>Instantiation of an SR Policy in the Forwarding Plane"> Plane</name>
	<t>Generally, only valid SR policies are instantiated in the
        forwarding plane.</t>
        <t>Only the active candidate path MUST <bcp14>MUST</bcp14> be used for forwarding traffic
        that is being steered onto that policy except for certain scenarios
        such as fast-reroute fast reroute where a backup candidate path may be used as
        described in <xref target="cp-path-protection"/>.</t> target="cp-path-protection" format="default"/>.</t>
        <t>If a set of Segment-Lists segment lists is associated with the active path of the
        policy, then the steering is per-flow per flow and weighted-ECMP (W-ECMP) based
        according to the relative weight of each Segment-List.</t> segment list.</t>
        <t>The fraction of the flows associated with a given Segment-List segment list is
        w/Sw,
        w/&wj;Sw, where w is the weight of the Segment-List segment list and Sw is the sum of
        the weights of the Segment-Lists segment lists of the selected path of the SR
        Policy.</t>
        <t>When a composite candidate path is active, the fraction of flows
        steered into each constituent SR Policy is equal to the relative
        weight of each constituent SR Policy. Further load balancing load-balancing of flows
        steered into a constituent SR Policy is performed based on the weights
        of the Segment-List segment list of the active candidate path of that constituent
        SR Policy.</t>
        <t>The accuracy of the weighted load-balancing depends on the platform
        implementation.</t>
      </section>
      <section anchor="SR-policy-priority" title="Priority numbered="true" toc="default">
        <name>Priority of an SR Policy"> Policy</name>
        <t>Upon topological change, many policies could be recomputed re-computed or
        revalidated. An implementation MAY <bcp14>MAY</bcp14> provide a per-policy priority
        configuration. The operator may set this field to indicate the order
        in which the policies should be re-computed. Such a priority is
        represented by an integer in the range (0, 255) where the lowest value
        is the highest priority. The default value of priority is 128.</t>
        <t>An SR Policy may comprise multiple Candidate Paths candidate paths received from
        the same or different sources. A candidate path MAY <bcp14>MAY</bcp14> be signaled with a
        priority value. When an SR Policy has multiple candidate paths with
        distinct signaled non-default priority values and the SR Policy itself
        does not have a priority value configured, the SR Policy as a whole
        takes the lowest value (i.e., the highest priority) amongst these
        signaled priority values.</t>
      </section>
      <section anchor="SR-policy-summary" title="Summary"> numbered="true" toc="default">
        <name>Summary</name>
        <t>In summary, the information model is the following:</t>

        <t><?rfc subcompact="yes"?> <list hangIndent="50" style="hanging">
            <t
            hangText="SR policy POL1 &lt;headend
        <dl newline="false" spacing="compact" indent="0">
          <dt>SR Policy POL1</dt>
          <dd> &lt;Headend = H1, color Color = 1, endpoint Endpoint = E1&gt;"/>

            <t
            hangText="     Candidate-path CP1 &lt;protocol-origin E1&gt;
	  </dd>
          <dt>Candidate Path CP1</dt>
          <dd>&lt;Protocol-Origin = 20, originator Originator = 64511:192.0.2.1, discriminator Discriminator = 1&gt;"/>

            <t hangText="          Preference 200"/>

            <t hangText="          Priority 10"/>

            <t
            hangText=" 1&gt;
	  </dd>
          <dt>          Preference</dt>
          <dd>200
	  </dd>
          <dt>          Priority</dt>
          <dd>10
	  </dd>
          <dt>          Segment List 1 &lt;SID11...SID1i&gt;, </dt>
          <dd>&lt;SID11...SID1i&gt;, Weight W1"/>

            <t
            hangText=" W1
	  </dd>
          <dt>          Segment List 2 &lt;SID21...SID2j&gt;, </dt>
          <dd>&lt;SID21...SID2j&gt;, Weight W2"/>

            <t
            hangText="     Candidate-path W2
	  </dd>
          <dt>     Candidate Path CP2 &lt;protocol-origin </dt>
          <dd>&lt;Protocol-Origin = 20, originator Originator = 64511:192.0.2.2, discriminator Discriminator = 2&gt;"/>

            <t hangText="          Preference 100"/>

            <t hangText="          Priority 10"/>

            <t
            hangText=" 2&gt;
	  </dd>
          <dt>          Preference</dt>
          <dd>100
	  </dd>
          <dt>          Priority</dt>
          <dd>10
	  </dd>
          <dt>          Segment List 3 3</dt>
          <dd> &lt;SID31...SID3i&gt;, Weight W3"/>

            <t
            hangText=" W3
	  </dd>
          <dt>          Segment List 4 &lt;SID41...SID4j&gt;, </dt>
          <dd>&lt;SID41...SID4j&gt;, Weight W4"/>
          </list></t> W4
	  </dd>
        </dl>
        <t>The SR Policy POL1 is identified by the tuple &lt;headend, color,
        endpoint&gt;. &lt;Headend, Color,
        Endpoint&gt;. It has two candidate paths paths: CP1 and CP2. Each is
        identified by a tuple &lt;protocol-origin, originator,
        discriminator&gt; &lt;Protocol-Origin, Originator,
        Discriminator&gt; within the scope of POL1. CP1 is the active
        candidate path (it is valid and has the highest preference). Preference). The two
        Segment-Lists
        segment lists of CP1 are installed as the forwarding instantiation of
        SR policy Policy POL1. Traffic steered on POL1 is flow-based hashed on
        Segment-List
        segment list &lt;SID11...SID1i&gt; with a ratio W1/(W1+W2).</t>
        <t>The information model of SR Policy POL100 having a composite
        candidate path is the following:</t>

        <t><?rfc subcompact="yes"?> <list hangIndent="50" style="hanging">
            <t
            hangText="SR policy
        <dl newline="false" spacing="compact" indent="50">
          <dt>SR Policy POL100 &lt;headend &lt;Headend = H1, color Color = 100, endpoint Endpoint = E1&gt;"/>

            <t
            hangText="     Candidate-path E1&gt;</dt>
          <dd/>
          <dt>     Candidate Path CP1 &lt;protocol-origin &lt;Protocol-Origin = 20, originator Originator = 64511:192.0.2.1, discriminator Discriminator = 1&gt;"/>

            <t hangText=" 1&gt;</dt>
          <dd/>
          <dt>         Preference 200"/>

            <t hangText=" 200</dt>
          <dd/>
          <dt>         SR policy &lt;color Policy &lt;Color = 1&gt;, Weight W1"/>

            <t hangText=" W1</dt>
          <dd/>
          <dt>         SR policy &lt;color Policy &lt;Color = 2&gt;, Weight W2"/>
          </list></t> W2</dt>
          <dd/>
        </dl>
        <t>The constituent SR Policies POL1 and POL2 have an information model
        as described at the start of this section. They are referenced only by
        color in the composite candidate path since their headend and endpoint
        are identical to the POL100. The valid Segment-Lists segment lists of the active
        candidate path of POL1 and POL2 are installed in the forwarding.
        Traffic steered on POL100 is flow-based hashed on a per-flow basis on POL1 with a
        proportion W1/(W1+W2). Within the POL1, the flow-based hashing over
        its Segment-Lists segment lists are performed as described earlier in this
        section.</t>

      </section>
    </section>
    <section anchor="SR-database" title="Segment numbered="true" toc="default">
      <name>Segment Routing Database"> Database</name>
      <t>An SR Policy computation node (e.g. (e.g., headend or controller) maintains
      the Segment Routing Database (SR-DB). The SR-DB is a conceptual database
      to illustrate the various pieces of information and their sources that
      may help in SR Policy computation and validation. There is no specific
      requirement for an implementation to create a new database as such.</t>
      <t>An SR headend leverages the SR-DB to validate explicit candidate
      paths and compute dynamic candidate paths.</t>
      <t>The information in the SR-DB may include: <list style="symbols">
          <t>IGP </t>
      <ul spacing="compact">
        <li>IGP information (topology, IGP metrics based on IS-IS <xref
          target="RFC1195"/> target="RFC1195" format="default"/> and OSPF <xref target="RFC2328"/> target="RFC2328" format="default"/> <xref
          target="RFC5340"/>)</t>

          <t>Segment target="RFC5340" format="default"/>)</li>
        <li>Segment Routing information (such as Segment Routing Global
          Block, Segment Routing Local Block, Prefix-SIDs, Adj-SIDs, BGP
          Peering SID, SRv6 SIDs) <xref target="RFC8402"/> target="RFC8402" format="default"/> <xref
          target="RFC8986"/></t>

          <t>TE target="RFC8986" format="default"/></li>
        <li>TE Link Attributes (such as TE metric, Shared Risk Link Groups,
          attribute-flag, extended admin group) <xref target="RFC5305"/> target="RFC5305" format="default"/> <xref
          target="RFC3630"/> target="RFC3630" format="default"/> <xref target="RFC5329"/>.</t>

          <t>Extended target="RFC5329" format="default"/></li>
        <li>Extended TE Link attributes (such as latency, loss) <xref
          target="RFC8570"/> target="RFC8570" format="default"/> <xref target="RFC7471"/></t>

          <t>Inter-AS target="RFC7471" format="default"/></li>
        <li>Inter-AS Topology information <xref target="RFC9086"/>.</t>
        </list></t> target="RFC9086" format="default"/></li>
      </ul>
      <t>The attached domain topology may be learned via protocol/mechanisms
      such as IGP, BGP-LS Border Gateway Protocol - Link State (BGP-LS), or NETCONF.</t>
      <t>A non-attached (remote) domain topology may be learned via
      protocol/mechanisms such as BGP-LS or NETCONF.</t>
      <t>In some use-cases, use cases, the SR-DB may only contain the attached domain
      topology while in others, the SR-DB may contain the topology of multiple
      domains and in this case, it is multi-domain capable.</t>
      <t>The SR-DB may also contain the SR Policies instantiated in the
      network. This can be collected via BGP-LS <xref
      target="I-D.ietf-idr-te-lsp-distribution"/>
      target="I-D.ietf-idr-te-lsp-distribution" format="default"/> or PCEP
      <xref
      target="RFC8231"/>, target="RFC8231" format="default"/> (along with <xref
      target="I-D.ietf-pce-segment-routing-policy-cp"/>,
      target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/> and
      <xref
      target="I-D.ietf-pce-binding-label-sid"/>. target="I-D.ietf-pce-binding-label-sid" format="default"/>). This
      information allows to build an end-to-end policy on the basis of
      intermediate SR policies (see <xref target="Binding-SID"/> target="Binding-SID"
      format="default"/> for further details).</t>
      <t>The SR-DB may also contain the Maximum SID Depth (MSD) capability of
      nodes in the topology. This can be collected via IS-IS <xref
      target="RFC8491"/>, target="RFC8491" format="default"/>, OSPF <xref target="RFC8476"/>, target="RFC8476" format="default"/>, BGP-LS <xref
      target="RFC8814"/> target="RFC8814" format="default"/>, or PCEP <xref target="RFC8664"/>.</t> target="RFC8664" format="default"/>.</t>
      <t>The use of the SR-DB for path computation and for the validation of
      optimization objective and constraints of paths is outside the scope of
      this document. Some implementation aspects related to path computation
      are covered in <xref
      target="I-D.filsfils-spring-sr-policy-considerations"/>.</t> target="I-D.filsfils-spring-sr-policy-considerations" format="default"/>.</t>
    </section>
    <section anchor="SID-List" title="Segment Types"> numbered="true" toc="default">
      <name>Segment Types</name>
      <t>A Segment-List segment list is an ordered set of segments represented as &lt;S1,
      S2, ... Sn&gt; where S1 is the first segment.</t>
      <t>Based on the desired dataplane, data plane, either the MPLS label stack or the
      SRv6 Segment Routing Header <xref target="RFC8754"/> target="RFC8754" format="default"/> is built from the
      Segment-List.
      segment list. However, the Segment-List segment list itself can be specified using
      different segment-descriptor types and the following are currently
      defined:</t>

      <t><list hangIndent="6" style="hanging">
          <t hangText="Type
      <dl newline="true" spacing="compact" indent="6">
        <dt>Type A: SR-MPLS Label:"><vspace/>An Label:</dt>

	<dd>
          <t>An MPLS label
          corresponding to any of the segment types defined for SR-MPLS (as
          defined in <xref target="RFC8402"/> target="RFC8402" format="default"/> or other SR-MPLS specifications)
          can be used. Additionally, special purpose labels like explicit-null
          or in general any MPLS label MAY <bcp14>MAY</bcp14> also be used. E.g. For example, this type can be
          used to specify a label representation that maps to an optical
          transport path on a packet transport node. <vspace
          blankLines="1"/></t>

          <t hangText="Type </t>
          <t/>
        </dd>
        <dt>Type B: SRv6 SID:"><vspace/>An SID:</dt>
        <dd>
          <t>An IPv6 address
          corresponding to any of the SID behaviors for SRv6 (as defined in
          <xref target="RFC8986"/> target="RFC8986" format="default"/> or other SRv6 specifications) can be used.
          Optionally, the SRv6 SID behavior (as defined in <xref
          target="RFC8986"/> target="RFC8986" format="default"/> or other SRv6 specifications) and structure (as
          defined in <xref target="RFC8986"/>) MAY target="RFC8986" format="default"/>) <bcp14>MAY</bcp14> also be provided for the
          headend to perform validation of the SID when using it for building
          the Segment List.<vspace blankLines="1"/></t>

          <t
          hangText="Type segment list.</t>
          <t/>
        </dd>
        <dt>Type C: IPv4 Prefix with optional SR Algorithm:"><vspace/>In Algorithm:</dt>
        <dd>
          <t>In
          this case, the headend is required to resolve the specified IPv4
          Prefix Address to the SR-MPLS label corresponding to its Prefix SID
          segment (as defined in <xref target="RFC8402"/>). target="RFC8402" format="default"/>). The SR algorithm
          (refer to Section 3.1.1 of <xref target="RFC8402"/>) target="RFC8402" sectionFormat="of" section="3.1.1" format="default"/>) to be used MAY <bcp14>MAY</bcp14>
          also be provided. <vspace blankLines="1"/></t>

          <t
          hangText="Type </t>
          <t/>
        </dd>
        <dt>Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS:"><vspace/>In SR-MPLS:</dt>
        <dd>
          <t>In
          this case, the headend is required to resolve the specified IPv6
          Global Prefix Address to the SR-MPLS label corresponding to its
          Prefix SID segment (as defined in <xref target="RFC8402"/>). target="RFC8402" format="default"/>). The SR
          Algorithm (refer to Section 3.1.1 of <xref target="RFC8402"/>) target="RFC8402" sectionFormat="of" section="3.1.1" format="default"/>) to be
          used MAY <bcp14>MAY</bcp14> also be provided. <vspace blankLines="1"/></t>

          <t
          hangText="Type </t>
          <t/>
        </dd>
        <dt>Type E: IPv4 Prefix with Local Interface ID:"><vspace/>This ID:</dt>
        <dd>
          <t>This
          type allows for identification of an Adjacency SID or BGP Peer Adjacency
          SID (as defined in <xref target="RFC8402"/>) target="RFC8402" format="default"/>) SR-MPLS label for
          point-to-point links including IP unnumbered links. The headend is
          required to resolve the specified IPv4 Prefix Address to the Node node
          originating it and then use the Local Interface ID to identify the
          point-to-point link whose adjacency is being referred to. The Local
          Interface ID link descriptor follows semantics as specified in <xref
          target="RFC5307"/>. target="RFC5307" format="default"/>. This type can also be used to indicate
          indirection into a layer 2 interface (i.e., without IP address) like
          a representation of an optical transport path or a layer 2 Ethernet
          port or circuit at the specified node. <vspace blankLines="1"/></t>

          <t
          hangText="Type </t>
          <t/>
        </dd>
        <dt>Type F: IPv4 Addresses for link endpoints as Local, Remote pair:"><vspace/>This pair:</dt>
        <dd>
          <t>This
          type allows for identification of an Adjacency SID or BGP Peer Adjacency
          SID (as defined in <xref target="RFC8402"/>) target="RFC8402" format="default"/>) SR-MPLS label for
          links. The headend is required to resolve the specified IPv4 Local
          Address to the Node node originating it and then use the IPv4 Remote
          Address to identify the link adjacency being referred to. The Local
          and Remote Address pair link descriptors follow semantics as
          specified in <xref target="RFC7752"/>. <vspace blankLines="1"/></t>

          <t
          hangText="Type target="RFC7752" format="default"/>. </t>
          <t/>
        </dd>
        <dt>Type G: IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SR-MPLS:"><vspace/>This SR-MPLS:</dt>
        <dd>
          <t>This
          type allows for identification of an Adjacency SID or BGP Peer Adjacency
          SID (as defined in <xref target="RFC8402"/>) target="RFC8402" format="default"/>) label for links
          including those with only Link-Local IPv6 addresses. The headend is
          required to resolve the specified IPv6 Prefix Address to the Node node
          originating it and then use the Local Interface ID to identify the
          point-to-point link whose adjacency is being referred to. For other
          than point-to-point links, additionally the specific adjacency over
          the link needs to be resolved using the Remote Prefix and Interface
          ID. The Local and Remote pair of Prefix and Interface ID link
          descriptor follows semantics as specified in <xref
          target="RFC7752"/>. target="RFC7752" format="default"/>. This type can also be used to indicate
          indirection into a layer 2 interface (i.e., without IP address) like
          a representation of an optical transport path or a layer 2 Ethernet
          port or circuit at the specified node. <vspace blankLines="1"/></t>

          <t
          hangText="Type </t>
          <t/>
        </dd>
        <dt>Type H: IPv6 Addresses for link endpoints as Local, Remote pair for SR-MPLS:"><vspace/>This SR-MPLS:</dt>
        <dd>
          <t>This
          type allows for identification of an Adjacency SID or BGP Peer Adjacency
          SID (as defined in <xref target="RFC8402"/>) target="RFC8402" format="default"/>) label for links with
          Global IPv6 addresses. The headend is required to resolve the
          specified Local IPv6 Address to the Node node originating it and then use
          the Remote IPv6 Address to identify the link adjacency being
          referred to. The Local and Remote Address pair link descriptors
          follow semantics as specified in <xref target="RFC7752"/>. <vspace
          blankLines="1"/></t>

          <t
          hangText="Type target="RFC7752" format="default"/>. </t>
          <t/>
        </dd>
        <dt>Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6:"><vspace/>The SRv6:</dt>
        <dd>
          <t>The
          headend is required to resolve the specified IPv6 Global Prefix
          Address to an SRv6 SID corresponding to a Prefix SID segment (as
          defined in <xref target="RFC8402"/>), target="RFC8402" format="default"/>), such as a SID associated with
          the End behavior (as defined in <xref target="RFC8986"/>) target="RFC8986" format="default"/>) of the
          node which that is originating the prefix. The SR Algorithm (refer to
          Section 3.1.1 of
          <xref target="RFC8402"/>), target="RFC8402" sectionFormat="of" section="3.1.1" format="default"/>), the SRv6 SID behavior
          (as defined in <xref target="RFC8986"/> target="RFC8986" format="default"/> or other SRv6
          specifications)
          specifications), and structure (as defined in <xref
          target="RFC8986"/>) MAY target="RFC8986" format="default"/>) <bcp14>MAY</bcp14> also be provided.<vspace
          blankLines="1"/></t>

          <t
          hangText="Type provided.</t>
          <t/>
        </dd>
        <dt>Type J: IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SRv6:"><vspace/>This SRv6:</dt>
        <dd>
          <t>This
          type allows for identification of an SRv6 SID corresponding to an
          Adjacency SID or BGP Peer Adjacency SID (as defined in <xref
          target="RFC8402"/>), target="RFC8402" format="default"/>), such as a SID associated with the End.X
          behavior (as defined in <xref target="RFC8986"/>) target="RFC8986" format="default"/>) associated with
          link or adjacency with only Link-Local IPv6 addresses. The headend
          is required to resolve the specified IPv6 Prefix Address to the Node node
          originating it and then use the Local Interface ID to identify the
          point-to-point link whose adjacency is being referred to. For other
          than point-to-point links, additionally the specific adjacency needs
          to be resolved using the Remote Prefix and Interface ID. The Local
          and Remote pair of Prefix and Interface ID link descriptor follows
          semantics as specified in <xref target="RFC7752"/>. target="RFC7752" format="default"/>. The SR Algorithm
          (refer to Section 3.1.1 of <xref target="RFC8402"/>), target="RFC8402" sectionFormat="of" section="3.1.1" format="default"/>), the SRv6 SID
          behavior (as defined in <xref target="RFC8986"/> target="RFC8986" format="default"/> or other SRv6
          specifications)
          specifications), and structure (as defined in <xref
          target="RFC8986"/>) MAY target="RFC8986" format="default"/>) <bcp14>MAY</bcp14> also be provided.<vspace
          blankLines="1"/></t>

          <t
          hangText="Type provided.</t>
          <t/>
        </dd>
        <dt>Type K: IPv6 Addresses for link endpoints as Local, Remote pair for SRv6:"><vspace/>This SRv6:</dt>
        <dd>
          <t>This type allows for identification of an SRv6 SID corresponding to
          an Adjacency SID or BGP Peer Adjacency SID (as defined in <xref
          target="RFC8402"/>),
          target="RFC8402" format="default"/>), such as a SID associated with
          the End.X behavior (as defined in <xref target="RFC8986"/>) target="RFC8986"
          format="default"/>) associated with link or adjacency with Global
          IPv6 addresses. The headend is required to resolve the specified
          Local IPv6 Address to the Node node originating it and then use the
          Remote IPv6 Address to identify the link adjacency being referred
          to. The Local and Remote Address pair link descriptors follow
          semantics as specified in <xref
          target="RFC7752"/>. target="RFC7752"
          format="default"/>. The SR Algorithm (refer to Section 3.1.1 of <xref target="RFC8402"/>),
          target="RFC8402" sectionFormat="of" section="3.1.1"
          format="default"/>), the SRv6 SID behavior (as defined in <xref target="RFC8986"/>
          target="RFC8986" format="default"/> or other SRv6 specifications) specifications),
          and structure (as defined in <xref target="RFC8986"/>) MAY target="RFC8986"
          format="default"/>) <bcp14>MAY</bcp14> also be
          provided.<vspace blankLines="1"/></t>
        </list></t> provided.</t>
          <t/>
        </dd>
      </dl>
      <t>When the algorithm is not specified for the SID types above which
      optionally allow for it, the headend SHOULD <bcp14>SHOULD</bcp14> use the Strict Shortest Path
      algorithm if available and otherwise, it SHOULD <bcp14>SHOULD</bcp14> use the default Shortest
      Path algorithm.

      The specification of the algorithm enables the use of SIDs specific to
      the IGP Flex Algorithm <xref target="I-D.ietf-lsr-flex-algo"/> specific
      SIDs target="I-D.ietf-lsr-flex-algo"
      format="default"/> in SR Policy.</t>

      <t>For SID types C-through-K, C through K, a SID value MAY <bcp14>MAY</bcp14> also be optionally
      provided to the headend for verification purposes. <xref
      target="Path-validity-explicit"/>. target="Path-validity-explicit" format="default"/> describes the resolution and
      verification of the SIDs and Segment Lists segment lists on the headend.</t>
      <t>When building the MPLS label stack or the IPv6 Segment SRv6 SID list from the
      Segment List,
      segment list, the node instantiating the policy MUST <bcp14>MUST</bcp14> interpret the set
      of Segments as follows: <list style="symbols">
          <t>The </t>
      <ul spacing="compact">
        <li>The first Segment represents the topmost MPLS label or the first IPv6
          segment.
        SRv6 SID. It identifies the active segment the traffic will be
        directed toward along the explicit SR path.</t>

          <t>The path.</li>
        <li>The last Segment segment represents the bottommost MPLS label or the last IPv6
          segment
        SRv6 SID the traffic will be directed toward along the explicit SR
          path.</t>
        </list></t>
        path.</li>
      </ul>
      <section anchor="Explicit-Null" title="Explicit Null"> numbered="true" toc="default">
        <name>Explicit Null</name>
        <t>A Type A SID MAY <bcp14>MAY</bcp14> be any MPLS label, including special purpose
        labels.</t>

        <t>For example, assuming that the desired traffic-engineered path from
        a headend 1 to an endpoint 4 can be expressed by the Segment-List segment list
        &lt;16002, 16003, 16004&gt; where 16002, 16003 16003, and 16004 respectively 16004, respectively,
        refer to the IPv4 Prefix SIDs bound to nodes 2, 3, and 4, then IPv6
        traffic can be traffic-engineered from nodes 1 to 4 via the previously
        described path using an SR Policy with Segment-List segment list &lt;16002, 16003,
        16004, 2&gt; where the MPLS label value of 2 represents the "IPv6
        Explicit NULL Label".</t>
        <t>The penultimate node before node 4 will pop 16004 and will forward
        the frame on its directly connected interface to node 4.</t>
        <t>The endpoint receives the traffic with the top label "2" "2", which
        indicates that the payload is an IPv6 packet.</t>
        <t>When steering unlabeled IPv6 BGP destination traffic using an SR
        policy
        Policy composed of Segment-List(s) segment list(s) based on IPv4 SIDs, the Explicit
        Null Label Policy is processed as specified in <xref
        target="I-D.ietf-idr-segment-routing-te-policy"/>) Section 2.4.5. target="I-D.ietf-idr-segment-routing-te-policy"  format="default"/>. When
        an &ldquo;IPv6 "IPv6 Explicit NULL label&rdquo; label" is not present as the bottom
        label, the headend SHOULD <bcp14>SHOULD</bcp14> automatically impose one. Refer to <xref
        target="Steering"/> target="Steering" format="default"/> for more details.</t>
      </section>
    </section>
    <section anchor="Path-validity" title="Validity numbered="true" toc="default">
      <name>Validity of a Candidate Path"> Path</name>
      <section anchor="Path-validity-explicit" title="Explicit numbered="true" toc="default">
        <name>Explicit Candidate Path"> Path</name>
        <t>An explicit candidate path is associated with a Segment-List segment list or a
        set of Segment-Lists.</t> segment lists.</t>
        <t>An explicit candidate path is provisioned by the operator directly
        or via a controller.</t>
        <t>The computation/logic that leads to the choice of the Segment-List segment list
        is external to the SR Policy headend. The SR Policy headend does not
        compute the Segment-List. segment list. The SR Policy headend only confirms its
        validity.</t>
        <t>An explicit candidate path MAY <bcp14>MAY</bcp14> consist of a single explicit
        Segment-List
        segment list containing only an implicit-null label to indicate
        pop-and-forward behavior. The Binding SID (BSID) is popped and the
        traffic is forwarded based on the inner label or an IP lookup in the
        case of unlabeled IP packets. Such an explicit path can serve as a
        fallback or path of last resort for traffic being steered into an SR
        Policy using its BSID (refer to Section 8.3).</t> <xref target="Steering-Incoming-BSID"/>).</t>
        <t>A Segment-List segment list of an explicit candidate path MUST <bcp14>MUST</bcp14> be declared
        invalid when any of the following is true: <list style="symbols">
            <t>It </t>
        <ul spacing="compact">
          <li>It is empty.</t>

            <t>Its empty.</li>
          <li>Its weight is 0.</t>

            <t>It 0.</li>
          <li>It comprises a mix of SR-MPLS and SRv6 segment types.</t>

            <t>The types.</li>
          <li>The headend is unable to perform path resolution for the first
            SID into one or more outgoing interface(s) and next-hop(s).</t>

            <t>The next-hop(s).</li>
          <li>The headend is unable to perform SID resolution for any
            non-first SID of type C-through-K C through K into an MPLS label or an SRv6
            SID.</t>

            <t>The
            SID.</li>
          <li>The headend verification fails for any SID for which
            verification has been explicitly requested.</t>
          </list></t> requested.</li>
        </ul>
        <t>"Unable to perform path resolution" means that the headend has no
        path to the SID in its SR database.</t>
        <t>SID verification is performed when the headend is explicitly
        requested to verify SID(s) by the controller via the signaling
        protocol used. Implementations MAY <bcp14>MAY</bcp14> provide a local configuration
        option to enable verification on a global or per policy per-policy or per
        candidate per-candidate path basis.</t>
        <t>"Verification fails" for a SID means any of the following:<list
            style="symbols">
            <t>The following:</t>
        <ul spacing="compact">
          <li>The headend is unable to find the SID in its SR-DB</t>

            <t>The SR-DB</li>
          <li>The headend detects a mismatch between the SID value provided
            and the SID value resolved by context provided for SIDs of type
            C-through-K
            C through K in its SR-DB.</t>

            <t>The SR-DB.</li>
          <li>The headend is unable to perform SID resolution for any
            non-first SID of type C-through-K C through K into an MPLS label or an SRv6
            SID.</t>
          </list></t>
            SID.</li>
        </ul>
        <t>In multi-domain deployments, it is expected that the headend may be
        unable to verify the reachability of the SIDs in remote domains. Types
        A or B MUST <bcp14>MUST</bcp14> be used for the SIDs for which the reachability cannot be
        verified. Note that the first SID MUST <bcp14>MUST</bcp14> always be reachable regardless
        of its type.</t>
        <t>Additionally, a Segment-List MAY segment list <bcp14>MAY</bcp14> be declared invalid when both of
        the conditions below are met : <list style="symbols">
            <t>Its </t>
        <ul spacing="compact">
          <li>Its last segment is not a Prefix SID (including BGP Peer
            Node-SID) advertised by the node specified as the endpoint of the
            corresponding SR policy.</t>

            <t>Its Policy.</li>
          <li>Its last segment is not an Adjacency SID (including BGP Peer
            Adjacency SID) of any of the links present on neighbor nodes and
            that terminate on the node specified as the endpoint of the
            corresponding SR policy.</t>
          </list></t> Policy.</li>
        </ul>
        <t>An explicit candidate path is invalid as soon as it has no valid
        Segment-List.</t>
        segment list.</t>
        <t>Additionally, an explicit candidate path MAY <bcp14>MAY</bcp14> be declared invalid
        when its constituent segment lists (valid or invalid) are using
        segment types of different SR data planes.</t>
      </section>
      <section anchor="Path-validity-dynamic" title="Dynamic numbered="true" toc="default">
        <name>Dynamic Candidate Path"> Path</name>
        <t>A dynamic candidate path is specified as an optimization objective
        and a set of constraints.</t>

        <t>The headend of the policy leverages its SR database to compute a
        Segment-List
        segment list ("solution Segment-List") segment list") that solves this optimization
        problem for either the SR-MPLS or the SRv6 data-plane data plane as
        specified.</t>
        <t>The headend re-computes the solution Segment-List segment list any time the
        inputs to the problem change (e.g., topology changes).</t>
        <t>When the local computation is not possible (e.g., a policy's
        tail-end
        tail end is outside the topology known to the headend) or not desired,
        the headend may rely on an external entity. For example, a path
        computation request may be sent to a PCE supporting PCEP extensions
        specified in <xref target="RFC8664"/>.</t> target="RFC8664" format="default"/>.</t>
        <t>If no solution is found to the optimization objective and
        constraints, then the dynamic candidate path MUST <bcp14>MUST</bcp14> be declared
        invalid.</t>

        <t>Section 3 of <xref
        target="I-D.filsfils-spring-sr-policy-considerations"/>
        <t><xref target="I-D.filsfils-spring-sr-policy-considerations" format="default"/> discusses some
        of the optimization objectives and constraints that may be considered
        by a dynamic candidate path. It illustrates some of the desirable
        properties of the computation of the solution Segment-List.</t> segment list.</t>
      </section>
      <section anchor="Path-validity-composite"
               title="Composite numbered="true" toc="default">
        <name>Composite Candidate Path"> Path</name>
        <t>A composite candidate path is specified as a group of its
        constituent SR Policies.</t>
        <t>A composite candidate path is valid when it has at least one valid
        constituent SR Policy.</t>
      </section>
    </section>
    <section anchor="Binding-SID" title="Binding SID"> numbered="true" toc="default">
      <name>Binding SID</name>

      <t>The Binding SID (BSID) is fundamental to Segment Routing <xref
      target="RFC8402"/>. target="RFC8402" format="default"/>. It provides scaling, network opacity, and service
      independence. Section 6 of <xref
      target="I-D.filsfils-spring-sr-policy-considerations"/> target="I-D.filsfils-spring-sr-policy-considerations" format="default"/> illustrates some
      of these benefits. This section describes the association of BSID with
      an SR Policy.</t>
      <section anchor="Binding-SID-candidate-path"
               title="BSID numbered="true" toc="default">
        <name>BSID of a candidate path"> Candidate Path</name>
        <t>Each candidate path MAY <bcp14>MAY</bcp14> be defined with a BSID.</t>
        <t>Candidate Paths paths of the same SR policy SHOULD Policy <bcp14>SHOULD</bcp14> have the same
        BSID.</t>
        <t>Candidate Paths paths of different SR policies MUST NOT Policies <bcp14>MUST NOT</bcp14> have the same
        BSID.</t>
      </section>
      <section anchor="Binding-SID-sr-policy" title="BSID numbered="true" toc="default">
        <name>BSID of an SR Policy"> Policy</name>
        <t>The BSID of an SR Policy is the BSID of its active candidate
        path.</t>

        <t>When

	<t>
	  When the active candidate path has a specified BSID, the SR Policy
	  uses that BSID if this value (label in MPLS, IPv6 address in SRv6)
	  is available. A BSID is available (i.e., when its value is not associated
	  with any other usage: e.g. usage, e.g., a label used by some other MPLS
	  forwarding entry, entry or an SRv6 SID used in some other
        context, context (such as
	  to another SID, segment, to another SR Policy, or that it is outside the
	  range of SRv6 Locators).</t> Locators).
</t>

        <t>In the case of SR-MPLS, SRv6 BSIDs (e.g. (e.g., with the behavior End.BM
        <xref target="RFC8986"/>) MAY target="RFC8986" format="default"/>) <bcp14>MAY</bcp14> be associated with the SR Policy in
        addition to the MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs
        (e.g.
        (e.g., with different behaviors like End.B6.Encap End.B6.Encaps and End.B6.Encap.Red End.B6.Encaps.Red
        <xref target="RFC8986"/>) MAY target="RFC8986" format="default"/>) <bcp14>MAY</bcp14> be associated with the SR Policy.</t>
        <t>Optionally, instead of only checking that the BSID of the active
        path is available, a headend MAY <bcp14>MAY</bcp14> check that it is available within the
        given SID range i.e., Segment Routing Local Block (SRLB) as specified
        in <xref target="RFC8402"/>.</t> target="RFC8402" format="default"/>.</t>
        <t>When the specified BSID is not available (optionally is not in the
        SRLB), an alert message MUST <bcp14>MUST</bcp14> be generated via mechanisms like
        syslog.</t>
        <t>In the cases (as described above) where SR Policy does not have a
        BSID available, then the SR Policy MAY <bcp14>MAY</bcp14> dynamically bind a BSID to
        itself. Dynamically bound BSID SHOULD BSIDs <bcp14>SHOULD</bcp14> use an available SID outside the
        SRLB.</t>
        <t>Assuming that at time t the BSID of the SR Policy is B1, if at time
        t+dt a different candidate path becomes active and this new active
        path does not have a specified BSID or its BSID is specified but is
        not available (e.g. (e.g., it is in use by something else), then the SR
        Policy MAY <bcp14>MAY</bcp14> keep the previous BSID B1.</t>
        <t>The association of an SR Policy with a BSID thus MAY <bcp14>MAY</bcp14> change over
        the life of the SR Policy (e.g., upon active path change). Hence, the
        BSID SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used as an identification of an SR Policy.</t>
        <section anchor="Binding-SID-sr-policy-unspecified-bsid"
                 title="Frequent use-case numbered="true" toc="default">
          <name>Frequent Use Case : unspecified BSID"> Unspecified BSID</name>

          <t>All the candidate paths of the same SR Policy can have an
          unspecified BSID.</t>
          <t>In such a case, a BSID MAY <bcp14>MAY</bcp14> be dynamically bound to the SR Policy
          as soon as the first valid candidate path is received. That BSID is
          kept through the life of the SR Policy and across changes of the active
          candidate path.</t>
        </section>
        <section anchor="Binding-SID-policy-same-bsid"
                 title="Frequent use-case: all specified numbered="true" toc="default">
          <name>Frequent Use Case: All Specified to the same BSID"> Same BSID</name>
          <t>All the paths of the SR Policy can have the same specified
          BSID.</t>
        </section>
        <section anchor="Binding-SID-specified-bsid"
                 title="Specified-BSID-only"> numbered="true" toc="default">
          <name>Specified-BSID-only</name>
          <t>An implementation MAY <bcp14>MAY</bcp14> support the configuration of the
          Specified-BSID-only restrictive behavior on the headend for all SR
          Policies or individual SR Policies. Further, this restrictive
          behavior MAY <bcp14>MAY</bcp14> also be signaled on a per SR Policy per-SR-Policy basis to the
          headend.</t>
          <t>When this restrictive behavior is enabled, if the candidate path
          has an unspecified BSID or if the specified BSID is not available
          when the candidate path becomes active active, then no BSID is bound to it
          and the candidate path is considered invalid. An alert MUST <bcp14>MUST</bcp14> be
          triggered for this error via mechanisms like syslog. Other candidate
          paths MUST <bcp14>MUST</bcp14> then be evaluated for becoming the active candidate
          path.</t>
        </section>
      </section>
      <section anchor="Binding-SID-forwarding" title="Forwarding Plane"> numbered="true" toc="default">
        <name>Forwarding Plane</name>
        <t>A valid SR Policy results in the installation of a BSID-keyed entry
        in the forwarding plane with the action of steering the packets
        matching this entry to the selected path of the SR Policy.</t>
        <t>If the Specified-BSID-only restrictive behavior is enabled and the
        BSID of the active path is not available (optionally not in the SRLB),
        then the SR Policy does not install any entry indexed by a BSID in the
        forwarding plane.</t>
      </section>
      <section anchor="BSID-to-tunnel" title="Non-SR usage numbered="true" toc="default">
        <name>Non-SR Usage of Binding SID"> SID</name>
        <t>An implementation MAY <bcp14>MAY</bcp14> choose to associate a Binding SID with any
        type of interface (e.g. (e.g., a layer 3 termination of an Optical Circuit)
        or a tunnel (e.g. (e.g., IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE
        tunnel, etc). This enables the use of other non-SR enabled non-SR-enabled interfaces
        and tunnels as segments in an SR Policy Segment-List segment list without the need
        of forming routing protocol adjacencies over them.</t>
        <t>The details of this kind of usage are beyond the scope of this
        document. A specific packet-optical integration use case is described
        in <xref target="I-D.anand-spring-poi-sr"/>.</t> target="I-D.anand-spring-poi-sr" format="default"/>.</t>
      </section>

    </section>
    <section anchor="Policy-state" title="SR numbered="true" toc="default">
      <name>SR Policy State"> State</name>
      <t>The SR Policy State state is maintained on the headend to represent the
      state of the policy and its candidate paths. This is to provide an
      accurate representation of whether the SR Policy is being instantiated
      in the forwarding plane and which of its candidate paths and
      segment-list(s)
      segment list(s) are active. The SR Policy state MUST <bcp14>MUST</bcp14> also reflect the
      reason when a policy and/or its candidate path is not active due to
      validation errors or not being preferred. The operational state
      information reported for SR Policies are specified in <xref
      target="I-D.ietf-spring-sr-policy-yang"/>.</t> target="I-D.ietf-spring-sr-policy-yang" format="default"/>.</t>

      <t>The SR Policy state can be reported by the headend node via BGP-LS
      <xref target="I-D.ietf-idr-te-lsp-distribution"/> target="I-D.ietf-idr-te-lsp-distribution" format="default"/> or PCEP <xref
      target="RFC8231"/> and target="RFC8231" format="default"/> <xref
      target="I-D.ietf-pce-binding-label-sid"/>.</t> target="I-D.ietf-pce-binding-label-sid" format="default"/>.</t>
      <t>SR Policy state on the headend also includes traffic accounting
      information for the flows being steered via the policies. The details of
      the SR Policy accounting are beyond the scope of this document. The
      aspects related to the SR traffic counters and their usage in the
      broader context of traffic accounting in an SR network are covered in
      <xref target="I-D.filsfils-spring-sr-traffic-counters"/> target="I-D.filsfils-spring-sr-traffic-counters" format="default"/> and <xref
      target="I-D.ali-spring-sr-traffic-accounting"/> target="I-D.ali-spring-sr-traffic-accounting" format="default"/>, respectively.</t>
      <t>Implementations MAY <bcp14>MAY</bcp14> support an administrative state to control
      locally provisioned policies via mechanisms like CLI command-line interface (CLI) or NETCONF.</t>
    </section>

    <section anchor="Steering" title="Steering numbered="true" toc="default">
      <name>Steering into an SR Policy"> Policy</name>
      <t>A headend can steer a packet flow into a valid SR Policy in various
      ways:</t>

      <t><list style="symbols">
          <t>Incoming
      <ul spacing="compact">
        <li>Incoming packets have an active SID matching a local BSID at the
          headend.</t>

          <t>Per-destination
          headend.</li>
        <li>Per-Destination Steering: incoming packets match a BGP/Service
          route
          route, which recurses on an SR policy.</t>

          <t>Per-flow Policy.</li>
        <li>Per-Flow Steering: incoming packets match or recurse on a
          forwarding array of which some of the entries are SR Policies.</t>

          <t>Policy-based Policies.</li>
        <li>Policy-Based Steering: incoming packets match a routing policy
          that directs them on an SR policy.</t>
        </list></t> Policy.</li>
      </ul>
      <section anchor="Steering-validity" title="Validity numbered="true" toc="default">
        <name>Validity of an SR Policy"> Policy</name>
        <t>An SR Policy is invalid when all its candidate paths are invalid as
        described in Sections <xref target="Path-validity"/> target="SR-policy-validity" format="counter"/> and <xref
        target="SR-policy-validity"/>.</t> target="Path-validity" format="counter"/>.</t>
        <t>By default, upon transitioning to the invalid state, <list
            style="symbols">
            <t>an </t>
        <ul spacing="compact">
          <li>an SR Policy and its BSID are removed from the forwarding
            plane.</t>

            <t>any
            plane.</li>
          <li>any steering of a service (Pseudowire (PW)), destination
            (BGP-VPN), flow or packet on the related SR policy Policy is disabled and
            the related service, destination, flow, or packet is routed per
            the classic forwarding table (e.g. longest-match (e.g., longest match to the
            destination or the recursing next-hop).</t>
          </list></t> next-hop).</li>
        </ul>
      </section>
      <section anchor="Steering-drop" title="Drop upon invalid numbered="true" toc="default">
        <name>Drop-upon-Invalid SR Policy"> Policy</name>

        <t>An SR Policy MAY <bcp14>MAY</bcp14> be enabled for the Drop-Upon-Invalid behavior:
        <list style="symbols">
            <t>an behavior. This would entail the following:
        </t>
        <ul spacing="compact">
          <li>an invalid SR Policy and its BSID is kept in the forwarding
            plane with an action to drop.</t>

            <t>any drop.</li>
          <li>any steering of a service (PW), destination (BGP-VPN), flow flow, or
            packet on the related SR policy Policy is maintained with the action to
            drop all of this traffic.</t>
          </list>The drop-upon-invalid traffic.</li>
        </ul>
        <t>The Drop-Upon-Invalid behavior has been deployed in use-cases use cases
        where the operator wants some PW to only be transported on a path with
        specific constraints. When these constraints are no longer met, the
        operator wants the PW traffic to be dropped. Specifically, the
        operator does not want the PW to be routed according to the IGP
        shortest path to the PW endpoint.</t>
      </section>
      <section anchor="Steering-Incoming-BSID"
               title="Incoming numbered="true" toc="default">
        <name>Incoming Active SID is a BSID"> BSID</name>
        <t>Let us assume that headend H has a valid SR Policy P of
        Segment-List
        segment list &lt;S1, S2, S3&gt; and BSID B.</t>
        <t>In the case of SR-MPLS, when H receives a packet K with label stack
        &lt;B, L2, L3&gt;, H pops B and pushes &lt;S1, S2, S3&gt; and forwards
        the resulting packet according to SID S1. <list>
            <t>"Forwarding </t>
<aside>
<t>          "Forwards the resulting packet according to SID S1" means: If S1
            is an Adj-SID or a PHP-enabled prefix SID advertised by a
            neighbor, H sends the resulting packet with label stack &lt;S2,
            S3, L2, L3&gt; on the outgoing interface associated with S1; Else Else,
            H sends the resulting packet with label stack &lt;S1, S2, S3, L2,
            L3&gt; along the path of S1.</t>
          </list></t>
</aside>

        <t>In the case of SRv6, the processing is similar and follows the SR
        Policy headend behaviors as specified in section 5 of <xref
        target="RFC8986"/>.</t> target="RFC8986" sectionFormat="of" section="5" format="default"/>.</t>
        <t>H has steered the packet into the SR policy Policy P.</t>
        <t>H did not have to classify the packet. The classification was done
        by a node upstream of H (e.g., the source of the packet or an
        intermediate ingress edge node of the SR domain) and the result of
        this classification was efficiently encoded in the packet header as a
        BSID.</t>
        <t>This is another key benefit of the segment routing in general and
        the binding SID in particular: the ability to encode a classification
        and the resulting steering in the packet header to better scale and
        simplify intermediate aggregation nodes.</t>
        <t>When Drop-Upon-Invalid (refer to <xref target="Steering-drop"/>) target="Steering-drop" format="default"/>) is
        not in use, for an invalid SR Policy P, its BSID B is not in the
        forwarding plane and hence hence, the packet K is dropped by H.</t>
      </section>

      <section anchor="Steering-per-destination"
               title="Per-Destination Steering"> numbered="true" toc="default">
        <name>Per-Destination Steering</name>
        <t>This section describes how a headend applies steering of flows
        corresponding to BGP routes over SR Policy using the Color Extended
        community <xref target="RFC9012"/>.</t> target="RFC9012" format="default"/>.</t>
        <t>In the case of SR-MPLS, let us assume that headend H: <list
            style="symbols">
            <t>learns </t>
        <ul spacing="compact">
          <li>learns a BGP route R/r via next-hop N, Color Extended community
            C
            C, and VPN label V.</t>

            <t>has V.</li>
          <li>has a valid SR Policy P to (color = C, endpoint = N) of
            Segment-List
            segment list &lt;S1, S2, S3&gt; and BSID B.</t>

            <t>has B.</li>
          <li>has a BGP policy that matches on the Color Extended community C
            and allows its usage as SLA steering information.</t>
          </list></t> information.</li>
        </ul>
        <t>If all these conditions are met, H installs R/r in RIB/FIB with
        next-hop = SR Policy P of BSID B instead of via N.</t>
        <t>Indeed, H's local BGP policy and the received BGP route indicate
        that the headend should associate R/r with an SR Policy path to
        endpoint N with the SLA associated with color C. The headend,
        therefore, installs the BGP route on that policy.</t>
        <t>This can be implemented by using the BSID as a generalized next-hop
        and installing the BGP route on that generalized next-hop.</t>
        <t>When H receives a packet K with a destination matching R/r, H
        pushes the label stack &lt;S1, S2, S3, V&gt; and sends the resulting
        packet along the path to S1.</t>
        <t>Note that any SID associated with the BGP route is inserted after
        the Segment-List segment list of the SR Policy (i.e., &lt;S1, S2, S3, V&gt;).</t>
        <t>In the case of SRv6, the processing is similar and follows the SR
        Policy headend behaviors as specified in section 5 of <xref
        target="RFC8986"/>.</t> target="RFC8986" sectionFormat="of" section="5"  format="default"/>.</t>
        <t>The same behavior applies to any type of service route: any
        AFI/SAFI of BGP <xref target="RFC4760"/> target="RFC4760" format="default"/> or LISP the Locator/ID Separation Protocol (LISP) <xref
        target="RFC6830"/> target="RFC6830" format="default"/> for both IPv4/IPv6.</t>
        <t>In a BGP multi-path scenario, the BGP route MAY <bcp14>MAY</bcp14> be resolved over a
        mix of paths that include those that are steered over SR Policies and
        others resolved via the normal BGP nexthop next-hop resolution. Implementations
        MAY
        <bcp14>MAY</bcp14> provide options to prefer one type over the other or other forms
        of local policy to determine the paths that are selected.</t>
        <section anchor="Steering-per-destination-colors"
                 title="Multiple Colors"> numbered="true" toc="default">
          <name>Multiple Colors</name>
          <t>When a BGP route has multiple Color Extended communities each
          with a valid SR Policy, the BGP process installs the route on the SR
          Policy giving preference to the Color Extended community with the
          highest numerical value.</t>
          <t>Let us assume that headend H: <list style="symbols">
              <t>learns </t>
          <ul spacing="compact">
            <li>learns a BGP route R/r via next-hop N, Color Extended
              communities C1 and C2.</t>

              <t>has C2.</li>
            <li>has a valid SR Policy P1 to (color = C1, endpoint = N) of
              Segment-List
              segment list &lt;S1, S2, S3&gt; and BSID B1.</t>

              <t>has B1.</li>
            <li>has a valid SR Policy P2 to (color = C2, endpoint = N) of
              Segment-List
              segment list &lt;S4, S5, S6&gt; and BSID B2.</t>

              <t>has B2.</li>
            <li>has a BGP policy that matches the Color Extended communities
              C1 and C2 and allows their usage as SLA steering information</t>
            </list> information</li>
          </ul>
          <t> If all these conditions are met, H installs R/r in RIB/FIB
          with next-hop = SR Policy P2 of BSID=B2 (instead of N) because C2
          &gt; C1.</t>
          <t>When the SR Policy with a specific color is not instantiated or
          in the down/inactive state, the SR Policy with the next highest
          numerical value of color is considered.</t>
        </section>
      </section>
      <section anchor="Steering-per-dynamic-BSID"
               title="Recursion numbered="true" toc="default">
        <name>Recursion on an on-demand dynamic BSID"> On-Demand Dynamic BSID</name>
        <t>In the previous section, it was assumed that H had a
        pre-established "explicit" SR Policy (color C, endpoint N).</t>
        <t>In this section, independent of the a-priori a priori existence of any
        explicit candidate path of the SR policy Policy (C, N), it is to be noted
        that the BGP process at headend node H triggers the instantiation of a
        dynamic candidate path for the SR policy Policy (C, N) as soon as: <list
            style="symbols">
            <t>the </t>
        <ul spacing="compact">
          <li>the BGP process learns of a route R/r via N and with Color
            Extended community C.</t>

            <t>a C.</li>
          <li>a local policy at node H authorizes the on-demand SR Policy
            path instantiation and maps the color to a dynamic SR Policy path
            optimization template.</t>
          </list></t> template.</li>
        </ul>
        <section anchor="Steering-per-dynamic-BSID-color"
                 title="Multiple Colors"> numbered="true" toc="default">
          <name>Multiple Colors</name>
          <t>When a BGP route R/r via N has multiple Color Extended
          communities Ci (with i=1 ... n), an individual on-demand SR Policy
          dynamic path request (color Ci, endpoint N) is triggered for each
          color Ci. The SR Policy that is used for steering is then determined
          as described in <xref
          target="Steering-per-destination-colors"/>.</t> target="Steering-per-destination-colors" format="default"/>.</t>
        </section>
      </section>
      <section anchor="Steering-per-flow" title="Per-Flow Steering"> numbered="true" toc="default">
        <name>Per-Flow Steering</name>
        <t>This section provides an example of how a headend might apply
        per-flow steering in practice.</t>
        <t>Let us assume that headend H: <list style="symbols">
            <t>has </t>
        <ul spacing="compact">
          <li>has a valid SR Policy P1 to (color = C1, endpoint = N) of
            Segment-List
            segment list &lt;S1, S2, S3&gt; and BSID B1.</t>

            <t>has B1.</li>
          <li>has a valid SR Policy P2 to (color = C2, endpoint = N) of
            Segment-List
            segment list &lt;S4, S5, S6&gt; and BSID B2.</t>

            <t>is B2.</li>
          <li>is configured to instantiate an array of paths to N where the
            entry 0 is the IGP path to N, color C1 is the first entry entry, and
            color C2 is the second entry. The index into the array is called a
            Forwarding Class (FC). The index can have values 0 to 7,
            especially when derived from the MPLS TC bits <xref
            target="RFC5462"/>.</t>

            <t>is target="RFC5462" format="default"/>.</li>
          <li>is configured to match flows in its ingress interfaces (upon
            any field such as Ethernet destination/source/VLAN/TOS or IP
            destination/source/DSCP
            destination/source/Differentiated Services Code Point (DSCP), or transport ports etc.) etc.), and color them
            with an internal per-packet forwarding-class variable (0, 1 1, or 2
            in this example).</t>
          </list></t> example).</li>
        </ul>
        <t>If all these conditions are met, H installs in RIB/FIB: <list
            style="symbols">
            <t>N </t>
        <ul spacing="compact">
          <li>N via recursion on an array A (instead of the immediate
            outgoing link associated with the IGP shortest-path shortest path to N).</t>

            <t>Entry N).</li>
          <li>Entry A(0) set to the immediate outgoing link of the IGP
            shortest-path
            shortest path to N.</t>

            <t>Entry N.</li>
          <li>Entry A(1) set to SR Policy P1 of BSID=B1.</t>

            <t>Entry BSID=B1.</li>
          <li>Entry A(2) set to SR Policy P2 of BSID=B2.</t>
          </list></t> BSID=B2.</li>
        </ul>
        <t>H receives three packets K, K1, and K2 on its incoming interface.
        These three packets either longest-match longest match on N or more likely on a
        BGP/service route which that recurses on N. H colors these 3 packets
        respectively with forwarding-class 0, 1, and 2.</t>
        <t>As a result, for SR-MPLS: <list style="symbols">
            <t>H </t>
        <ul spacing="compact">
          <li>H forwards K along the shortest path to N (i.e., pushes the
            Prefix-SID of N).</t>

            <t>H N).</li>
          <li>H pushes &lt;S1, S2, S3&gt; on packet K1 and forwards the
            resulting frame along the shortest path to S1.</t>

            <t>H S1.</li>
          <li>H pushes &lt;S4, S5, S6&gt; on packet K2 and forwards the
            resulting frame along the shortest path to S4.</t>
          </list></t> S4.</li>
        </ul>
        <t>For SRv6, the processing is similar and the segment lists of the
        individual SR Policies P1 and P2 are enforced for packets K1 and K2
        using the SR Policy headend behaviors as specified in section 5 of <xref target="RFC8986"/>.</t>
        target="RFC8986" sectionFormat="of" section="5"
        format="default"/>.</t>
        <t>If the local configuration does not specify any explicit forwarding
        information for an entry of the array, then this entry is filled with
        the same information as entry 0 (i.e., the IGP shortest path).</t>
        <t>If the SR Policy mapped to an entry of the array becomes invalid,
        then this entry is filled with the same information as entry 0. When
        all the array entries have the same information as entry0, entry 0, the
        forwarding entry for N is updated to bypass the array and point
        directly to its outgoing interface and next-hop.</t>
        <t>The array index values (e.g. (e.g., 0, 1, and 2) and the notion of
        forwarding-class
        forwarding class are implementation-specific implementation specific and only meant to
        describe the desired behavior. The same can be realized by other
        mechanisms.</t>
        <t>This realizes per-flow steering: different flows bound to the same
        BGP endpoint are steered on different IGP or SR Policy paths.</t>
        <t>A headend MAY <bcp14>MAY</bcp14> support options to apply per-flow steering only for
        traffic matching specific prefixes (e.g. (e.g., specific IGP or BGP
        prefixes).</t>
      </section>
      <section anchor="Steering-policy-based" title="Policy-based Routing"> numbered="true" toc="default">
        <name>Policy-Based Routing</name>
        <t>Finally, headend H MAY <bcp14>MAY</bcp14> be configured with a local routing policy
        which
        that overrides any BGP/IGP path and steers a specified packet on an
        SR Policy. This includes the use of mechanisms like IGP Shortcut for
        automatic routing of IGP prefixes over SR Policies intended for such
        purpose.</t>
      </section>
      <section anchor="Steering-optional-bgp"
               title="Optional numbered="true" toc="default">
        <name>Optional Steering Modes for BGP Destinations"> Destinations</name>
        <section anchor="Steering-optional-bgp-color-only-steering"
                 title="Color-Only numbered="true" toc="default">
          <name>Color-Only BGP Destination Steering"> Steering</name>
          <t>In the previous section, it is seen that the steering on an SR
          Policy is governed by the matching of the BGP route's next-hop N and
          the authorized Color Extended community C with an SR Policy defined
          by the tuple (N, C).</t>
          <t>This is the most likely form of BGP destination steering and the
          one recommended for most use-cases.</t> use cases.</t>
          <t>This section defines an alternative steering mechanism based only
          on the Color Extended community.</t>
          <t>Three types of steering modes are defined.</t>
          <t>For the default, Type 0, the BGP destination is steered as
          follows:</t>

          <t><list hangIndent="50" style="hanging">
              <t
              hangText="

<sourcecode type="pseudocode">
   IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6"/>

              <t hangText=" IPv6
           endpoint address and C is a color;"/>

              <t hangText=" color;
       Steer into SR Policy (N, C);"/>

              <t hangText="    ELSE;"/>

              <t hangText=" C);
   ELSE;
       Steer on the IGP path to the next-hop N."/>
            </list></t> N.
</sourcecode>

<t>This is the classic case described in this document previously
          and what is recommended in most scenarios.</t>
          <t>For Type 1, the BGP destination is steered as follows:</t>

          <t><list hangIndent="50" style="hanging">
              <t
              hangText="

<sourcecode type="pseudocode">
   IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6"/>

              <t hangText=" IPv6
           endpoint address and C is a color;"/>

              <t hangText=" color;
       Steer into SR Policy (N, C);"/>

              <t
              hangText=" C);
   ELSE IF there is a valid SR Policy (null endpoint, C) of the"/>

              <t hangText=" the
           same address-family of N;"/>

              <t hangText=" N;
       Steer into SR Policy (null endpoint, C);"/>

              <t hangText=" C);
   ELSE IF there is any valid SR Policy"/>

              <t
              hangText=" Policy
           (any address-family null endpoint, C);"/>

              <t
              hangText=" C);
       Steer into SR Policy (any null endpoint, C);"/>

              <t hangText="    ELSE;"/>

              <t hangText=" C);
   ELSE;
       Steer on the IGP path to the next-hop N."/>
            </list></t> N.
</sourcecode>

<t>For Type 2, the BGP destination is steered as follows:</t>

          <t><list hangIndent="50" style="hanging">
              <t
              hangText="
<sourcecode type="pseudocode">
   IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6"/>

              <t hangText=" IPv6
           endpoint address and C is a color;"/>

              <t hangText=" color;
       Steer into SR Policy (N, C);"/>

              <t
              hangText=" C);
   ELSE IF there is a valid SR Policy (null endpoint, C)"/>

              <t hangText=" C)
           of the same address-family of N;"/>

              <t hangText=" N;
       Steer into SR Policy (null endpoint, C);"/>

              <t hangText=" C);
   ELSE IF there is any valid SR Policy"/>

              <t
              hangText=" Policy
           (any address-family null endpoint, C);"/>

              <t
              hangText=" C);
       Steer into SR Policy (any null endpoint, C);"/>

              <t
              hangText=" C);
   ELSE IF there is any valid SR Policy (any endpoint, C)"/>

              <t hangText=" C)
           of the same address-family of N;"/>

              <t hangText=" N;
       Steer into SR Policy (any endpoint, C);"/>

              <t hangText=" C);
   ELSE IF there is any valid SR Policy"/>

              <t hangText=" Policy
           (any address-family endpoint, C);"/>

              <t
              hangText=" C);
       Steer into SR Policy (any address-family endpoint, C);"/>

              <t hangText="    ELSE;"/>

              <t hangText=" C);
   ELSE;
       Steer on the IGP path to the next-hop N."/>
            </list></t> N.
</sourcecode>

<t>The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits
          set to the 0 value).</t>
          <t>Please refer to <xref
          target="I-D.ietf-idr-segment-routing-te-policy"/> target="I-D.ietf-idr-segment-routing-te-policy" format="default"/> for the updates to
          the BGP Color Extended community for the implementation of these
          mechanisms.</t>
        </section>
        <section anchor="Steering-optional-bgp-multi-color"
                 title="Multiple numbered="true" toc="default">
          <name>Multiple Colors and CO flags"> flags</name>

          <t>The steering preference is first based on the highest Color
          Extended community value and then Color-Only steering type for the
          color. Assuming a Prefix via (NH, C1(CO=01), C2(CO=01)); C1&gt;C2 C1&gt;C2.
          The steering preference order is: <list style="symbols">
              <t>SR policy </t>
          <ul spacing="compact">
            <li>SR Policy (NH, C1).</t>

              <t>SR policy C1).</li>
            <li>SR Policy (null, C1).</t>

              <t>SR policy C1).</li>
            <li>SR Policy (NH, C2).</t>

              <t>SR policy C2).</li>
            <li>SR Policy (null, C2).</t>

              <t>IGP C2).</li>
            <li>IGP to NH.</t>
            </list></t> NH.</li>
          </ul>
        </section>
        <section anchor="Steering-optional-bgp-drop-on-invalid"
                 title="Drop upon Invalid"> numbered="true" toc="default">
          <name>Drop-upon-Invalid</name>
          <t>This document defined earlier that when all the following
          conditions are met, H installs R/r in RIB/FIB with next-hop = SR
          Policy P of BSID B instead of via N. <list style="symbols">
              <t>H </t>
          <ul spacing="compact">
            <li>H learns a BGP route R/r via next-hop N, Color Extended
              community C.</t>

              <t>H C.</li>
            <li>H has a valid SR Policy P to (color = C, endpoint = N) of
              Segment-List
              segment list &lt;S1, S2, S3&gt; and BSID B.</t>

              <t>H B.</li>
            <li>H has a BGP policy that matches the Color Extended community
              C and allows its usage as SLA steering information.</t>
            </list></t> information.</li>
          </ul>
          <t>This behavior is extended by noting that the BGP policy Policy may
          require the BGP steering to always stay on the SR policy Policy whatever
          its validity.</t>
          <t>This is the "drop upon invalid" "drop-upon-invalid" option described in <xref
          target="Steering-drop"/> target="Steering-drop" format="default"/> applied to BGP-based steering.</t>
        </section>
      </section>
    </section>
    <section anchor="protection" title="Recovering numbered="true" toc="default">
      <name>Recovering from Network Failures"> Failures</name>
      <section anchor="Local-protection-tilfa"
               title="Leveraging numbered="true" toc="default">
        <name>Leveraging TI-LFA local protection Local Protection of the constituent Constituent IGP segments"> Segments</name>
        <t>In any topology, Topology-Independent Loop-Free Alternate (TI-LFA)
        <xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/> target="I-D.ietf-rtgwg-segment-routing-ti-lfa" format="default"/> provides a
        50msec
        50 msec local protection technique for IGP SIDs. The backup path is
        computed on a per IGP SID per-IGP-SID basis along the post-convergence path.</t>
        <t>In a network that has deployed TI-LFA, an SR Policy built on the
        basis of TI-LFA protected IGP segments leverages the local protection
        of the constituent segments. Since TI-LFA protection is based on IGP
        computation, there are cases where the path used during the
        fast-reroute time window may not meet the exact constraints of the SR
        Policy.</t>
        <t>In a network that has deployed TI-LFA, an SR Policy instantiated
        only with non-protected Adj SIDs does not benefit from any local
        protection.</t>
      </section>
      <section anchor="Local-protection-policy"
               title="Using numbered="true" toc="default">
        <name>Using an SR Policy to locally protect Locally Protect a link">
        <t><figure anchor="PROTECTION"
            title="Local protection using Link</name>
        <figure anchor="PROTECTION">
          <name>Local Protection Using SR Policy"> Policy</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
     1----2-----6----7
     |    |     |    |
     4----3-----9----8
        ]]></artwork>
        </figure>

	<t> An SR Policy can be instantiated at node 2 to protect link
        2to6.
        2-to-6. A typical explicit Segment-List segment list would be &lt;3, 9, 6&gt;.</t>
        <t>A typical use-case use case occurs for links outside an IGP domain: e.g. e.g., 1,
        2, 3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are
        part of IGP/SR sub-domain 2. In such a case, links 2to6 2-to-6 and 3to9
        cannot benefit from TI-LFA automated local protection. The SR Policy
        with Segment-List segment list &lt;3, 9, 6&gt; on node 2 can be locally configured
        to be a fast-reroute backup path for the link 2to6.</t> 2-to-6.</t>
      </section>
      <section anchor="cp-path-protection"
               title="Using numbered="true" toc="default">

	<name>Using a Candidate Path for Path Protection"> Protection</name>
        <t>An SR Policy allows for multiple candidate paths, of which at any
        point in time there is a single active candidate path that is
        provisioned in the forwarding plane and used for traffic steering.
        However, another (lower preference) candidate path MAY <bcp14>MAY</bcp14> be designated
        as the backup for a specific or all (active) candidate path(s). The
        following options are possible:<list style="symbols">
            <t>A possible:</t>
        <ul spacing="compact">
          <li>A pair of disjoint candidate paths are provisioned with one of
            them as primary and the other is identified as its backup.</t>

            <t>A backup.</li>
          <li>A specific candidate path is provisioned as the backup for any
            (active) candidate path.</t>

            <t>The path.</li>
          <li>The headend picks the next (lower) preference valid candidate
            path as the backup for the active candidate path.</t>
          </list></t> path.</li>
        </ul>
        <t>The headend MAY <bcp14>MAY</bcp14> compute a-priori a priori and validate such backup candidate
        paths as well as provision them into the forwarding plane as a backup
        for the active path. The backup candidate path may be dynamically
        computed or explicitly provisioned in such a way that they provide the
        most appropriate alternative for the active candidate path. A fast
        re-route fast-reroute mechanism MAY <bcp14>MAY</bcp14> then be used to trigger sub 50msec sub-50 msec switchover
        from the active to the backup candidate path in the forwarding plane.
        Mechanisms like Bidirectional Forwarding Detection (BFD) MAY <bcp14>MAY</bcp14> be used
        for fast detection of such failures.</t>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document specifies in detail the SR Policy construct introduced
      in <xref target="RFC8402"/> target="RFC8402" format="default"/> and its instantiation on a router supporting
      SR along with descriptions of mechanisms for the steering of traffic flows
      over it. Therefore, the security considerations of <xref
      target="RFC8402"/> target="RFC8402" format="default"/> apply. The security consideration related to SR-MPLS
      <xref target="RFC8660"/> target="RFC8660" format="default"/> and SRv6 <xref target="RFC8754"/> target="RFC8754" format="default"/> <xref
      target="RFC8986"/> target="RFC8986" format="default"/> also apply.</t>
      <t>The endpoint of the SR Policy, other than in the case of a null
      endpoint, uniquely identifies the tail-end node of the segment routed
      path. If an address that is used as an endpoint for an SR Policy is
      advertised by more than one node due to a misconfiguration or spoofing
      and the same is advertised via an IGP, the traffic steered over the SR
      Policy may end up getting diverted to an undesired node resulting is in
      misrouting. Mechanisms for detection of duplicate prefix advertisement
      can be used to identify and correct such scenarios. The details of these
      mechanisms are outside the scope of this document.</t>

      <t>The <xref target="Steering"/>
      <t><xref target="Steering" format="default"/> specifies mechanism mechanisms for the steering of
      traffic flows corresponding to BGP routes over SR Policies matching the
      color value signaled via the BGP Color Extended Community attached with
      the BGP routes. Misconfiguration or error in setting of the Color
      Extended Community with the BGP routes can result in the forwarding of
      packets for those routes along undesired paths.</t>
      <t>In Sections <xref target="SR-policy-identification"/> target="SR-policy-identification" format="counter"/> and <xref
      target="SR-policy-candidate-path-identification"/>, target="SR-policy-candidate-path-identification" format="counter"/>, the document
      mentions that a symbolic name MAY <bcp14>MAY</bcp14> be signaled along with a candidate
      path for the SR Policy and for the SR Policy Candidate Path Path,
      respectively. While the value of symbolic names for display clarity is
      indisputable, as with any unrestricted freeform free-form text received from
      external parties, there can be no absolute assurance that the
      information the text purports to show is accurate or even truthful. For
      this reason, users of implementations that display such information
      would be well-advised well advised not to rely on it without question and to use the
      specific identifiers of the SR Policy and SR Policy Candidate Path for
      validation. Furthermore, implementations that display such information
      might wish to display it in such a fashion as to differentiate it from
      known-good information. (Such display conventions are inherently
      implementation-specific;
      implementation specific; one example might be use of a distinguished
      text color or style for information that should be treated with
      caution.)</t>
      <t>This document does not define any new protocol extensions and does
      not introduce any further security considerations.</t>
    </section>
    <section anchor="MGMT" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>This document specifies in detail the SR Policy construct introduced
      in <xref target="RFC8402"/> target="RFC8402" format="default"/> and its instantiation on a router supporting
      SR along with descriptions of mechanisms for the steering of traffic flows
      over it. Therefore, the manageability considerations of <xref
      target="RFC8402"/> target="RFC8402" format="default"/> apply.</t>
      <t>A YANG model for the configuration and operation of SR Policy has
      been defined in <xref target="I-D.ietf-spring-sr-policy-yang"/>.</t> target="I-D.ietf-spring-sr-policy-yang" format="default"/>.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>The document requests IANA to create numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has created a new sub-registry subregistry called
      "Segment Types" under the top-level "Segment Routing" registry that was
      created by <xref target="RFC8986"/>. target="RFC8986" format="default"/>. This sub-registry subregistry maintains the
      alphabetic identifiers for the segment types (as specified in section 4) <xref target="SID-List"/>)
      that may be used within a Segment List segment list of an SR Policy. The alphabetical
      identifiers run from A to Z and may be extended on exhaustion with the
      identifiers AA to AZ, BA to BZ, and so on on, through till ZZ. This
      sub-registry would follow
      subregistry follows the Specification Required allocation policy
      as specified in <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
      <t>The initial registrations for this sub-registry subregistry are as follows:</t>

      <texttable
      <table anchor="table_iana" title="Initial IANA Registration">
        <ttcol align="center">Value</ttcol>

        <ttcol align="left">Description</ttcol>

        <ttcol align="center">Reference</ttcol>

        <c>A</c>

        <c>SR-MPLS Label</c>

        <c>[This.ID]</c>

        <c>B</c>

        <c>SRv6 SID</c>

        <c>[This.ID]</c>

        <c>C</c>

        <c>IPv4 align="center">
        <name>Segment Types</name>
        <thead>
          <tr>
            <th align="center">Value</th>
            <th align="left">Description</th>
            <th align="center">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">A</td>
            <td align="left">SR-MPLS Label</td>
            <td align="center">RFC 9256</td>
          </tr>
          <tr>
            <td align="center">B</td>
            <td align="left">SRv6 SID</td>
            <td align="center">RFC 9256</td>
          </tr>
          <tr>
            <td align="center">C</td>
            <td align="left">IPv4 Prefix with optional SR Algorithm</c>

        <c>[This.ID]</c>

        <c>D</c>

        <c>IPv6 Algorithm</td>
            <td align="center">RFC 9256</td>
          </tr>
          <tr>
            <td align="center">D</td>
            <td align="left">IPv6 Global Prefix with optional SR Algorithm for SR-MPLS</c>

        <c>[This.ID]</c>

        <c>E</c>

        <c>IPv4 SR-MPLS</td>
            <td align="center">RFC 9256</td>
          </tr>
          <tr>
            <td align="center">E</td>
            <td align="left">IPv4 Prefix with Local Interface ID</c>

        <c>[This.ID]</c>

        <c>F</c>

        <c>IPv4 ID</td>
            <td align="center">RFC 9256</td>
          </tr>
          <tr>
            <td align="center">F</td>
            <td align="left">IPv4 Addresses for link endpoints as Local, Remote pair</c>

        <c>[This.ID]</c>

        <c>G</c>

        <c>IPv6 pair</td>
            <td align="center">RFC 9256</td>
          </tr>
          <tr>
            <td align="center">G</td>
            <td align="left">IPv6 Prefix and Interface ID for link endpoints as Local, Remote
        pair for SR-MPLS</c>

        <c>[This.ID]</c>

        <c>H</c>

        <c>IPv6 SR-MPLS</td>
            <td align="center">RFC 9256</td>
          </tr>
          <tr>
            <td align="center">H</td>
            <td align="left">IPv6 Addresses for link endpoints as Local, Remote pair for
        SR-MPLS</c>

        <c>[This.ID]</c>

        <c>I</c>

        <c>IPv6
        SR-MPLS</td>
            <td align="center">RFC 9256</td>
          </tr>
          <tr>
            <td align="center">I</td>
            <td align="left">IPv6 Global Prefix with optional SR Algorithm for SRv6</c>

        <c>[This.ID]</c>

        <c>J</c>

        <c>IPv6 SRv6</td>
            <td align="center">RFC 9256</td>
          </tr>
          <tr>
            <td align="center">J</td>
            <td align="left">IPv6 Prefix and Interface ID for link endpoints as Local, Remote
        pair for SRv6</c>

        <c>[This.ID]</c>

        <c>K</c>

        <c>IPv6 SRv6</td>
            <td align="center">RFC 9256</td>
          </tr>
          <tr>
            <td align="center">K</td>
            <td align="left">IPv6 Addresses for link endpoints as Local, Remote pair for
        SRv6</c>

        <c>[This.ID]</c>
      </texttable>
        SRv6</td>
            <td align="center">RFC 9256</td>
          </tr>
        </tbody>
      </table>
      <section anchor="guidance" title="Guidance numbered="true" toc="default">
        <name>Guidance for Designated Experts"> Experts</name>
        <t>The Designated Expert (DE) is expected to ascertain the existence
        of suitable documentation (a specification) as described in <xref
        target="RFC8126"/> target="RFC8126" format="default"/> and to verify that the document is permanently and
        publicly available. The DE is also expected to check the clarity of
        purpose and use of the requested assignment. Additionally, the DE must
        verify that any request for one of these assignments has been made
        available for review and comment within the IETF: the DE will post the
        request to the SPRING Working Group mailing list (or a successor
        mailing list designated by the IESG). If the request comes from within
        the IETF, it should be documented in an Internet-Draft. Lastly, the DE
        must ensure that any other request for a code point does not conflict
        with work that is active or already published within the IETF.</t>
      </section>
    </section>

  </middle>
  <back>

<displayreference target="I-D.ietf-pce-binding-label-sid" to="PCEP-BSID-LABEL"/>
<displayreference target="I-D.ietf-pce-segment-routing-policy-cp" to="PCEP-SR-POLICY-CP"/>
<displayreference target="I-D.ietf-idr-te-lsp-distribution" to="BGP-LS-TE-POLICY" />
<displayreference target="I-D.ietf-idr-segment-routing-te-policy" to="BGP-SR-POLICY"/>
<displayreference target="I-D.ietf-rtgwg-segment-routing-ti-lfa" to="SR-TI-LFA"/>
<displayreference target="I-D.ietf-lsr-flex-algo" to="IGP-FLEX-ALGO"/>
<displayreference target="I-D.ali-spring-sr-traffic-accounting" to="SR-TRAFFIC-ACCOUNTING"/>
<displayreference target="I-D.filsfils-spring-sr-policy-considerations" to="SR-POLICY-CONSID"/>
<displayreference target="I-D.ietf-spring-sr-policy-yang" to="SR-POLICY-YANG"/>
<displayreference target="I-D.anand-spring-poi-sr" to="POI-SR"/>
<displayreference target="I-D.filsfils-spring-sr-traffic-counters" to="SR-TRAFFIC-COUNTERS"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6830.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8476.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8491.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8814.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9086.xml"/>

<reference anchor="I-D.ietf-pce-binding-label-sid">
<front>
<title>Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.
</title>
<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
  <organization/>
</author>

<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
  <organization/>
</author>

<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
  <organization/>
</author>

<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
  <organization/>
</author>

<author initials='C' surname='Li' fullname='Cheng Li' role='editor'>
  <organization/>
</author>

<date month='March' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-pce-binding-label-sid-15'/>
</reference>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-pce-segment-routing-policy-cp.xml"/>

<reference anchor="I-D.ietf-idr-te-lsp-distribution">
<front>
<title>Distribution of Traffic Engineering (TE) Policies and State using BGP-LS
</title>
<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
  <organization/>
</author>
<author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role="editor">
  <organization/>
</author>
<author initials='J' surname='Dong' fullname='Jie Dong' role="editor">
  <organization/>
</author>
<author initials='M' surname='Chen' fullname='Mach(Guoyi) Chen'>
  <organization/>
</author>
<author initials='H' surname='Gredler' fullname='Hannes Gredler'>
  <organization/>
</author>
<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
  <organization/>
</author>
<date month='April' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-idr-te-lsp-distribution-17'/>
</reference>

<reference anchor="I-D.ietf-idr-segment-routing-te-policy">
<front>
<title>Advertising Segment Routing Policies in BGP
</title>
<author initials='S' surname='Previdi' fullname='Stefano Previdi' >
  <organization/>
</author>

<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
  <organization/>
</author>

<author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role='editor'>
  <organization/>
</author>

<author initials='P' surname='Mattes' fullname='Paul Mattes'>
  <organization/>
</author>

<author initials='D' surname='Jain' fullname='Dhanendra Jain'>
  <organization/>
</author>

<author initials='S' surname='Lin' fullname='Steven Lin'>
  <organization/>
</author>
<date month='June' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-idr-segment-routing-te-policy-18'/>
</reference>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-rtgwg-segment-routing-ti-lfa.xml"/>

<reference anchor="I-D.ietf-lsr-flex-algo">
<front>
<title>IGP Flexible Algorithm
</title>
<author initials='P' surname='Psenak' fullname='Peter Psenak' role='editor'>
  <organization/>
</author>

<author initials='S' surname='Hegde' fullname='Shraddha Hegde'>
  <organization/>
</author>

<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
  <organization/>
</author>

<author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar'>
  <organization/>
</author>

<author initials='A' surname='Gulko' fullname='Arkadiy Gulko'>
  <organization/>
</author>

<date month='May' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-lsr-flex-algo-20'/>
</reference>

<reference anchor="I-D.ietf-spring-sr-policy-yang">
<front>
<title>YANG Data Model for Segment Routing Policy
</title>
<author initials='K' surname='Raza' fullname='Kamran Raza' role="editor">
  <organization/>
</author>

<author initials='S' surname='Sawaya' fullname='Robert Sawaya'>
  <organization/>
</author>

<author initials='Z' surname='Shunwan' fullname='Zhuang Shunwan'>
  <organization/>
</author>

<author initials='D' surname='Voyer' fullname='Daniel Voyer'>
  <organization/>
</author>

<author initials='M' surname='Durrani' fullname='Muhammad Durrani'>
  <organization/>
</author>

<author initials='S' surname='Matsushima' fullname='Satoru Matsushima'>
  <organization/>
</author>

<author initials='V' surname='Beeram' fullname='Vishnu Pavan Beeram'>
  <organization/>
</author>
<date month='April' year='2021'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-spring-sr-policy-yang-01'/>
</reference>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.anand-spring-poi-sr.xml"/>

<reference anchor="I-D.ali-spring-sr-traffic-accounting">
<front>
<title>Traffic Accounting in Segment Routing Networks
</title>
<author initials='Z' surname='Ali' fullname='Zafar Ali'>
  <organization/>
</author>

<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
  <organization/>
</author>

<author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar'>
  <organization/>
</author>

<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
  <organization/>
</author>

<author initials='M' surname='Horneffer' fullname='Martin Horneffer'>
  <organization/>
</author>

<author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
  <organization/>
</author>

<author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
  <organization/>
</author>

<author initials='D' surname='Voyer' fullname='Voyer'>
  <organization/>
</author>

<author initials='R' surname='Morton' fullname='Rick Morton'>
  <organization/>
</author>

<author initials='G' surname='Dawra' fullname='Gaurav Dawra'>
  <organization/>
</author>

<date month='May' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ali-spring-sr-traffic-accounting-07'/>
</reference>

<reference anchor="I-D.filsfils-spring-sr-policy-considerations">
<front>
<title>SR Policy Implementation and Deployment Considerations
</title>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
  <organization/>
</author>

<author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role="editor">
  <organization/>
</author>

<author initials='P' surname='Krol' fullname='Przemyslaw Krol'>
  <organization/>
</author>

<author initials='M' surname='Horneffer' fullname='Martin Horneffer'>
  <organization/>
</author>

<author initials='P' surname='Mattes' fullname='Paul Mattes'>
  <organization/>
</author>
<date month='April' day='24' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-filsfils-spring-sr-policy-considerations-09'/>
</reference>

<reference anchor="I-D.filsfils-spring-sr-traffic-counters">
<front>
<title>Segment Routing Traffic Accounting Counters
</title>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
  <organization/>
</author>

<author initials='Z' surname='Ali' fullname='Zafar Ali' role="editor">
  <organization/>
</author>

<author initials='M' surname='Horneffer' fullname='Martin Horneffer'>
  <organization/>
</author>

<author initials='D' surname='Voyer' fullname='Daniel Voyer'>
  <organization/>
</author>

<author initials='M' surname='Durrani' fullname='Muhammad Durrani'>
  <organization/>
</author>

<author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
  <organization/>
</author>
<date month='October' year='2021'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-filsfils-spring-sr-traffic-counters-02'/>
</reference>

</references>
    </references>
    <section anchor="Acknowledgement" title="Acknowledgement"> numbered="false" toc="default">
      <name>Acknowledgement</name>
      <t>The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger
      Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha, Jim
      Guichard, Martin Vigoureux, Benjamin Schwartz, David Schinazi, Matthew
      Bocci, Cullen Jennings, and Carlos Bernardos <contact fullname="Tarek Saad"/>,
      <contact fullname="Dhanendra Jain"/>, <contact fullname="Ruediger
      Geib"/>, <contact fullname="Rob Shakir"/>, <contact fullname="Cheng
      Li"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Gyan
      Mishra"/>, <contact fullname="Nandan Saha"/>, <contact fullname="Jim
      Guichard"/>, <contact fullname="Martin Vigoureux"/>, <contact
      fullname="Benjamin Schwartz"/>, <contact fullname="David Schinazi"/>,
      <contact fullname="Matthew Bocci"/>, <contact fullname="Cullen
      Jennings"/>, and <contact fullname="Carlos J. Bernardos"/> for their review comments
      review, comments, and suggestions.</t>
    </section>
    <section anchor="Contributors" title="Contributors"> numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following people have contributed to this document:<figure>
          <artwork><![CDATA[Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Zafar Ali
Cisco Systems
Email: zali@cisco.com]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Jose Liste
Cisco Systems
Email: jliste@cisco.com]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Francois Clad
Cisco Systems
Email: fclad@cisco.com]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Kamran Raza
Cisco Systems
Email: skraza@cisco.com]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Mike Koldychev
Cisco Systems
Email: mkoldych@cisco.com]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Shraddha Hegde
Juniper Networks
Email: shraddha@juniper.net]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Steven Lin
Google, Inc.
Email: stevenlin@google.com]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Przemyslaw Krol
Google, Inc.
Email: pkrol@google.com]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Martin Horneffer
Deutsche Telekom
Email: martin.horneffer@telekom.de]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Dirk Steinberg
Steinberg Consulting
Email: dws@steinbergnet.net]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Bruno Decraene
Orange document:</t>

<author fullname="Siva Sivabalan" initials="S" surname="Sivabalan">
      <organization>Cisco Systems</organization>
      <address>
	<email>msiva@cisco.com</email>
      </address>
    </author>

<author fullname="Zafar Ali" initials="Z" surname="Ali">
      <organization>Cisco Systems</organization>
      <address>
	<email>zali@cisco.com</email>
      </address>
    </author>

<author fullname="Jose Liste" initials="J" surname="Liste">
      <organization>Cisco Systems</organization>
      <address>
	<email>jliste@cisco.com</email>
      </address>
    </author>

<author fullname="Francois Clad" initials="F" surname="Clad">
      <organization>Cisco Systems</organization>
      <address>
	<email>fclad@cisco.com</email>
      </address>
    </author>

<author fullname="Kamran Raza" initials="K" surname="Raza">
      <organization>Cisco Systems</organization>
      <address>
	<email>skraza@cisco.com</email>
      </address>
    </author>

<author fullname="Mike Koldychev" initials="M" surname="Koldychev">
      <organization>Cisco Systems</organization>
      <address>
	<email>mkoldych@cisco.com</email>
      </address>
    </author>

<author fullname="Shraddha Hegde" initials="S" surname="Hegde">
      <organization>Juniper Networks</organization>
      <address>
	<email>shraddha@juniper.net</email>
      </address>
    </author>

<author fullname="Steven Lin" initials="S" surname="Lin">
      <organization>Google, Inc.</organization>
      <address>
	<email>stevenlin@google.com</email>
      </address>
    </author>

<author fullname="Przemyslaw Krol" initials="P" surname="Krol">
      <organization>Google, Inc.</organization>
      <address>
	<email>pkrol@google.com</email>
      </address>
    </author>

<author fullname="Martin Horneffer" initials="M" surname="Horneffer">
      <organization>Deutsche Telekom</organization>
      <address>
	<email>martin.horneffer@telekom.de</email>
      </address>
    </author>

<author fullname="Dirk Steinberg" initials="D" surname="Steinberg">
      <organization>Steinberg Consulting</organization>
      <address>
	<email>dws@steinbergnet.net</email>
      </address>
    </author>

<author fullname="Bruno Decraene" initials="B" surname="Decraene">
      <organization>Orange Business Services
Email: bruno.decraene@orange.com]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Stephane Litkowski
Orange Services</organization>
      <address>
	<email>bruno.decraene@orange.com</email>
      </address>
    </author>

<author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
      <organization>Orange Business Services
Email: stephane.litkowski@orange.com]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Luay Jalil
Verizon
Email: luay.jalil@verizon.com]]></artwork>
        </figure></t> Services</organization>
      <address>
	<email>stephane.litkowski@orange.com</email>
      </address>
    </author>

<author fullname="Luay Jalil" initials="L" surname="Jalil">
      <organization>Verizon</organization>
      <address>
	<email>luay.jalil@verizon.com</email>
      </address>
    </author>

    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8660.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8986.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8754.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7752.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9012.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.0020.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5340.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5462.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6830.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5307.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5329.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8570.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7471.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8231.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8476.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8491.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8664.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8814.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9086.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-binding-label-sid"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-segment-routing-policy-cp"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-te-lsp-distribution"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-segment-routing-te-policy"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-segment-routing-ti-lfa"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lsr-flex-algo"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-spring-sr-policy-yang"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.anand-spring-poi-sr"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ali-spring-sr-traffic-accounting"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.filsfils-spring-sr-policy-considerations"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.filsfils-spring-sr-traffic-counters"?>
    </references>

  </back>
</rfc>