<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="std" consensus="true" number="9086"
     docName="draft-ietf-idr-bgpls-segment-routing-epe-19"
     ipr="trust200902"> ipr="trust200902"
     obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3"
     symRefs="true" sortRefs="true" version="3">

  <front>

    <title abbrev="Segment Routing EPE BGP-LS Extensions">BGP-LS extensions Extensions">Border Gateway
    Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress
    Peer Engineering</title>
    <seriesInfo name="RFC" value="9086"/>
    <author fullname="Stefano Previdi" initials="S." surname="Previdi">
      <organization>Individual</organization>
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>stefano@previdi.net</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@cisco.com</email>
      </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city>Brussels</city>
          <region/>
          <code/>
          <country>Belgium</country>
        </postal>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Keyur Patel" initials="K." surname="Patel">
      <organization>Arrcus, Inc.</organization>
      <address>
        <email>Keyur@arrcus.com</email>
      </address>
    </author>
    <author fullname="Saikat Ray" initials="S." surname="Ray">
      <organization>Individual Contributor</organization>
      <organization>Individual</organization>
      <address>
        <email>raysaikat@gmail.com</email>
      </address>
    </author>
    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>
          <city>Beijing</city>
          <region/>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <date year=""/> year="2021" month="August"/>
    <area>Routing</area>
    <workgroup>Inter-Domain Routing</workgroup>
    <keyword>BGP</keyword>
    <keyword>BGP-LS</keyword>
    <keyword>Segment Routing</keyword>
    <abstract>
      <t>Segment Routing (SR) leverages source routing.
      <t>
A node steers a packet through a controlled set of instructions, called
segments, by prepending the packet with an SR header. a list of segment identifiers (SIDs).

A segment can represent any instruction, topological or service-based. service based. SR
segments allow steering a flow through any topological path and service chain
while maintaining per-flow state only at the ingress node of the SR
domain.</t>
      <t>This document describes an extension to BGP Link-State Border Gateway Protocol -
      Link State (BGP-LS) for advertisement of BGP Peering Segments along with
      their BGP peering node information so that efficient BGP Egress Peer
      Engineering (EPE) policies and strategies can be computed based on
      Segment Routing.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>
    </note>

  </front>
  <middle>
    <section anchor="INTRO" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Segment Routing (SR) leverages source routing.

A node steers a packet through a controlled set of instructions, called
segments, by prepending the packet with an SR header with a list of segment identifiers (SID). (SIDs).

A SID can represent any instruction, topological or service-based. service based. SR segments
allows to enforce a flow through any topological path or service function
while maintaining per-flow state only at the ingress node of the SR
domain.</t>
      <t>The SR architecture <xref target="RFC8402"/> target="RFC8402" format="default"/> defines three types of
      BGP Peering Segments that may be instantiated at a BGP node:<list
          style="symbols">
          <t>Peer node:</t>
      <ul spacing="normal">
        <li>Peer Node Segment (PeerNode SID) : instruction to steer to a
          specific peer node</t>

          <t>Peer node</li>
        <li>Peer Adjacency Segment (PeerAdj SID) : instruction to steer over
          a specific local interface towards a specific peer node</t>

          <t>Peer node</li>
        <li>Peer Set Segment (PeerSet SID) : instruction to load-balance to a
          set of specific peer nodes</t>
        </list></t> nodes</li>
      </ul>

      <t>SR can be directly applied to either to an MPLS dataplane (SR/MPLS) data plane (SR-MPLS)
      with no change on the forwarding plane or to a modified IPv6 forwarding
      plane (SRv6).</t>
      <t>This document describes extensions to the BGP Link-State NLRI - Link State Network
      Layer Reachability Information (BGP-LS NLRI) and the BGP-LS Attribute
      defined for BGP-LS <xref
      target="RFC7752"/> target="RFC7752" format="default"/> for
      advertising BGP peering segments from a BGP node along with its peering
      topology information (i.e., its peers, interfaces, and peering ASs)
      Autonomous Systems (ASes)) to enable computation of efficient BGP Egress
      Peer Engineering (BGP-EPE) policies and strategies using the
      SR/MPLS dataplane. SR-MPLS
      data plane. The corresponding extensions for SRv6 are specified in <xref target="I-D.dawra-idr-bgpls-srv6-ext"/>.</t>
      target="I-D.ietf-idr-bgpls-srv6-ext" format="default"/>.</t>

      <t><xref target="I-D.ietf-spring-segment-routing-central-epe"/> target="RFC9087"
      format="default"/> illustrates a centralized controller-based BGP Egress
      Peer Engineering solution involving SR path computation using the BGP
      Peering Segments.  This use case comprises a centralized controller that
      learns the BGP Peering SIDs via BGP-LS and then uses this information to
      program a BGP-EPE policy at any node in the domain to perform traffic
      steering via a specific BGP egress node to a specific EBGP External BGP
      (EBGP) peer(s) optionally also over a specific interface. The BGP-EPE
      policy can be realized using the SR Policy framework <xref
      target="I-D.ietf-spring-segment-routing-policy"/>.</t>
      target="I-D.ietf-spring-segment-routing-policy" format="default"/>.</t>
      <t>This document introduces a new BGP-LS Protocol-ID for BGP and defines
      new BGP-LS Node and Link Descriptor TLVs to facilitate advertising
      BGP-LS Link NLRI to represent the BGP peering topology. Further, it
      specifies the BGP-LS Attribute TLVs for advertisement of the BGP Peering
      Segments (i.e., PeerNode SID, PeerAdj SID, and PeerSet SID) to be
      advertised in the same BGP-LS Link NLRI.</t>
    </section>

  <section anchor="TERMINOLOGY">
      <name>Requirements Language</name>

        <t>
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
        </t>
  </section>

    <section anchor="BGPPEERINGSEG" title="BGP numbered="true" toc="default">

      <name>BGP Peering Segments"> Segments</name>
      <t>As described in <xref target="RFC8402"/>, target="RFC8402" format="default"/>, a BGP-EPE enabled
      BGP-EPE-enabled Egress PE Provider Edge (PE) node instantiates SR Segments corresponding to
      its attached peers. These segments are called BGP Peering Segments or
      BGP Peering SIDs. In the case of EBGP, they enable the expression of
      source-routed inter-domain interdomain paths.</t>
      <t>An ingress border router of an AS may compose a list of SIDs to steer
      a flow along a selected path within the AS, towards a selected egress
      border router C of the AS, and to a specific EBGP peer. At minimum, a
      BGP-EPE policy applied at an ingress PE involves two SIDs: the Node SID
      of the chosen egress PE and then the BGP Peering SID for the chosen
      egress PE peer or peering interface.</t>
      <t>Each BGP session MUST <bcp14>MUST</bcp14> be described by a PeerNode
      SID. The description of the BGP session MAY <bcp14>MAY</bcp14> be augmented
      by additional PeerAdj SIDs. Finally, multiple PeerNode SIDs or PeerAdj
      SIDs MAY <bcp14>MAY</bcp14> be part of the same group/set in order to group
      EPE resources under a common PeerSet SID. These BGP Peering SIDs and
      their encoding are described in detail in <xref
      target="PEERSEGMENTS"/>.</t> target="PEERSEGMENTS"
      format="default"/>.</t>
      <t>The following BGP Peering SIDs need to be instantiated on a BGP
      router for each of its BGP peer sessions that are enabled for Egress
      Peer Engineering:<list style="symbols">
          <t>One Engineering:</t>
      <ul spacing="normal">
        <li>One PeerNode SID MUST <bcp14>MUST</bcp14> be instantiated to describe
        the BGP peer
          session.</t>

          <t>One session.</li>
        <li>One or more PeerAdj SID MAY <bcp14>MAY</bcp14> be instantiated
        corresponding to the underlying link(s) to the directly connected BGP
        peer session.</t>

          <t>A session.</li>
        <li>A PeerSet SID MAY <bcp14>MAY</bcp14> be instantiated and additionally
        associated and shared between one or more PeerNode SIDs or PeerAdj SIDs.</t>
        </list></t>
        SIDs.</li>
      </ul>

      <t>While an egress point in a topology usually refers to EBGP sessions
      between external peers, there's nothing in the extensions defined in
      this document that would prevent the use of these extensions in the
      context of IBGP Internal BGP (IBGP) sessions.
      However, unlike EBGP sessions sessions, which are generally between directly
      connected BGP routers which are also along the traffic forwarding path, IBGP peer
      sessions may be setup set up to BGP routers which that are not in the forwarding
      path.
      As such, when the IBGP design includes sessions with route-reflectors, route reflectors, a
      BGP router SHOULD NOT <bcp14>SHOULD NOT</bcp14> instantiate a BGP Peering SID for
      those sessions to peer nodes which that are not in the forwarding path since
      the purpose of BGP Peering SID is to steer traffic to that those specific
      peers. Thus, the applicability for IBGP peering may be limited to only
      those deployments where the IBGP peer is also along the forwarding data
      path.</t>

      <t>Any BGP Peering SIDs instantiated on the node are advertised via
      BGP-LS Link NLRI type as described in the sections below. An
      illustration of the BGP Peering SIDs' allocations in a reference BGP
      peering topology along with the information carried in the BGP-LS Link
      NLRI and its corresponding BGP-LS Attribute are described in <xref
      target="I-D.ietf-spring-segment-routing-central-epe"/>.</t> target="RFC9087" format="default"/>.</t>
    </section>
    <section anchor="EPENLRI"
             title="BGP-LS numbered="true" toc="default">
      <name>BGP-LS NLRI Advertisement for BGP Protocol"> Protocol</name>
      <t>This section describes the BGP-LS NLRI encodings that describe the
      BGP peering and link connectivity between BGP routers.</t>
      <t>This document specifies the advertisement of BGP peering topology
      information via BGP-LS Link NLRI type type, which requires use of a new BGP-LS
      Protocol-ID.</t>

      <texttable
      <table anchor="PROTOCOL-IDS"
                 title="BGP-LS align="center">
        <name>BGP-LS Protocol Identifier for BGP">
        <ttcol align="center">Protocol-ID</ttcol>

        <ttcol BGP</name>
        <thead>
          <tr>
            <th align="center">Protocol-ID</th>
            <th align="left">NLRI information source protocol</ttcol>

        <c>7</c>

        <c>BGP</c>
      </texttable> Information Source Protocol</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">7</td>
            <td align="left">BGP</td>
          </tr>
        </tbody>
      </table>
      <t>The use of a new Protocol-ID allows separation and differentiation
      between the BGP-LS NLRIs carrying BGP information from the BGP-LS NLRIs
      carrying IGP link-state information defined in <xref
      target="RFC7752"/>.</t> target="RFC7752" format="default"/>.</t>
      <t>The BGP Peering information along with their Peering Segments are
      advertised using BGP-LS Link NLRI type with the Protocol-ID set to BGP.
      The
      BGP-LS Link NLRI type uses the Descriptor TLVs and BGP-LS Attribute TLVs
      as defined in <xref target="RFC7752"/>. target="RFC7752" format="default"/>. In order to
      correctly describe BGP nodes, new TLVs are defined in this section.</t>
      <t><xref target="RFC7752"/> target="RFC7752" format="default"/> defines BGP-LS Link NLRI Type is
      type as follows:
      </t>
      <figure anchor="LINKNLRI" title="BGP-LS anchor="LINKNLRI">
        <name>BGP-LS Link NLRI">
          <artwork><![CDATA[ NLRI</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|  Protocol-ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Identifier                          |
|                            (64 bits)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//      Local Node Descriptors                                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//      Remote Node Descriptors                                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//      Link Descriptors                                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure><list style="hanging">
          <t>Node
      </figure>
      <dl newline="false" spacing="normal">
        <dt/>
        <dd>Node Descriptors and Link Descriptors are defined in <xref
          target="RFC7752"/>.</t>
        </list></t> target="RFC7752" format="default"/>.</dd>
      </dl>
      <section anchor="BGPIDCONFEDMEMBER"
               title="BGP numbered="true" toc="default">
        <name>BGP Router-ID and Member AS Number"> Number</name>
        <t>Two new Node Descriptors Descriptor TLVs are defined in this document:<list
            style="symbols"> document:</t>
        <ul spacing="normal">
          <li>
            <t>BGP Router Identifier (BGP Router-ID): <list style="hanging">
                <t>Type: 516</t>

                <t>Length: 4 octets</t>

                <t>Value: </t>
            <dl newline="false" spacing="normal">
              <dt/>
              <dd>Type: 516</dd>
              <dt/>
              <dd>Length: 4 octet octets</dd>
              <dt/>
              <dd>Value: 4-octet unsigned non-zero integer representing the
                BGP Identifier as defined in <xref target="RFC6286"/>.</t>
              </list></t>
          </list><list style="symbols"> target="RFC6286" format="default"/></dd>
            </dl>
          </li>
        </ul>
        <ul spacing="normal">
          <li>
            <t>Member-AS Number (Member-ASN)<list style="hanging">
                <t>Type: 517</t>

                <t>Length: 4 octets</t>

                <t>Value: (Member-ASN)</t>
            <dl newline="false" spacing="normal">
              <dt/>
              <dd>Type: 517</dd>
              <dt/>
              <dd>Length: 4 octet octets</dd>
              <dt/>
              <dd>Value: 4-octet unsigned non-zero integer representing the
                Member-AS Number <xref target="RFC5065"/>.</t>
              </list></t>
          </list></t> target="RFC5065" format="default"/></dd>
            </dl>
          </li>
        </ul>
      </section>
      <section anchor="MANDATORYNODEDESC"
               title="Mandatory numbered="true" toc="default">
        <name>Mandatory BGP Node Descriptors"> Descriptors</name>
        <t>The following Node Descriptors Descriptor TLVs MUST <bcp14>MUST</bcp14> be included in BGP-LS NLRI
        as Local Node Descriptors when distributing BGP information:<list
            style="symbols">
            <t>BGP information:</t>
        <ul spacing="normal">
          <li>BGP Router-ID (TLV 516), which contains a valid BGP Identifier
            of the local BGP node.</t>

            <t>Autonomous node.</li>
          <li>Autonomous System Number (TLV 512) <xref target="RFC7752"/>, target="RFC7752"
          format="default"/>, which contains the ASN Autonomous System Number
          (ASN) or AS Confederation Identifier (ASN) (an ASN) <xref
            target="RFC5065"/>, target="RFC5065"
          format="default"/>, if confederations are used, of the local BGP
            node.</t>
          </list></t>
          node.</li>
        </ul>

        <t>Note that <xref target="RFC6286"/> (section 2.1) target="RFC6286" sectionFormat="of" section="2.1"/>
        requires the BGP identifier (Router-ID) to be unique within an
        Autonomous System and non-zero. Therefore, the &lt;ASN, BGP
        Router-ID&gt; tuple is globally unique. Their use in the Node
        Descriptor helps map Link-State NLRIs with BGP protocol-ID to a unique
        BGP router in the administrative domain where BGP-LS is enabled.</t>
        <t>The following Node Descriptors Descriptor TLVs MUST <bcp14>MUST</bcp14> be included in BGP-LS Link
        NLRI as Remote Node Descriptors when distributing BGP
        information:<list style="symbols">
            <t>BGP
        information:</t>
        <ul spacing="normal">
          <li>BGP Router-ID (TLV 516), which contains the valid BGP
            Identifier of the peer BGP node.</t>

            <t>Autonomous node.</li>
          <li>Autonomous System Number (TLV 512) <xref target="RFC7752"/>, target="RFC7752"
          format="default"/>, which contains the ASN or the AS Confederation
          Identifier (ASN) (an ASN) <xref target="RFC5065"/>, target="RFC5065" format="default"/>, if
          confederations are used, of the peer BGP node.</t>
          </list></t> node.</li>
        </ul>

      </section>
      <section anchor="OPTIONALNODEDESC" title="Optional numbered="true" toc="default">
        <name>Optional BGP Node Descriptors"> Descriptors</name>
        <t>The following Node Descriptors Descriptor TLVs MAY <bcp14>MAY</bcp14> be included in BGP-LS NLRI
        as Local Node Descriptors when distributing BGP information:<list
            style="symbols">
            <t>Member-ASN information:</t>
        <ul spacing="normal">
          <li>Member-ASN (TLV 517), which contains the ASN of the
            confederation member (i.e., Member-AS Number), if BGP
            confederations are used, of the local BGP node.</t>

            <t>Node node.</li>
          <li>Node Descriptors as defined in <xref target="RFC7752"/>.</t>
          </list></t> target="RFC7752" format="default"/>.</li>
        </ul>
        <t>The following Node Descriptors Descriptor TLVs MAY <bcp14>MAY</bcp14> be included in BGP-LS Link
        NLRI as Remote Node Descriptors when distributing BGP
        information:<list style="symbols">
            <t>Member-ASN
        information:</t>
        <ul spacing="normal">
          <li>Member-ASN (TLV 517), which contains the ASN of the
            confederation member (i.e., Member-AS Number), if BGP
            confederations are used, of the peer BGP node.</t>

            <t>Node node.</li>
          <li>Node Descriptors as defined in <xref target="RFC7752"/>.</t>
          </list></t> target="RFC7752" format="default"/>.</li>
        </ul>
      </section>
    </section>
    <section anchor="PEERSEGMENTS"
             title="BGP-LS numbered="true" toc="default">
      <name>BGP-LS Attributes for BGP Peering Segments"> Segments</name>
      <t>This section defines the BGP-LS Attributes corresponding to the
      following BGP Peer Segment SIDs:<list style="hanging">
          <t>Peer SIDs:</t>
<ul>
<li>Peer Node Segment Identifier (PeerNode SID)</t>

          <t>Peer SID)
</li>
<li>Peer Adjacency Segment Identifier (PeerAdj SID)</t>

          <t>Peer SID)
</li>
<li>Peer Set Segment Identifier (PeerSet SID)</t>
        </list></t> SID)
</li>
</ul>

      <t>The following new BGP-LS Link attributes Attribute TLVs are defined for use
      with BGP-LS Link NLRI for advertising BGP Peering SIDs:</t>

      <figure anchor="CODEPOINTVALUES"
              title="BGP-LS

<table anchor="CODEPOINTVALUES">
  <name>BGP-LS TLV code points Code Points for BGP-EPE">
        <artwork><![CDATA[+----------+---------------------------+
| TLV BGP-EPE</name>
  <thead>
    <tr>
      <th>TLV Code | Description               |
|  Point   |                           |
+----------+---------------------------+
|    1101  | PeerNode SID              |
|    1102  | PeerAdj SID               |
|    1103  | PeerSet SID               |
+----------+---------------------------+
]]></artwork>
      </figure> Point</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1101</td>
      <td>PeerNode SID</td>
    </tr>
    <tr>
      <td>1102</td>
      <td>PeerAdj SID</td>
    </tr>
<tr>
      <td>1103</td>
      <td>PeerSet SID</td>
</tr>
  </tbody>
</table>

      <t/>
      <t>PeerNode SID, PeerAdj SID, and PeerSet SID have all have the same format
      as defined here below: </t>
      <figure anchor="PEERSID"
          title="BGP anchor="PEERSID">
        <name>BGP Peering SIDs TLV Format">
          <artwork><![CDATA[ Format</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         |     Weight    |             Reserved          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   SID/Label/Index (variable)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure><list style="symbols">
          <t>Type:
      </figure>
      <ul spacing="normal">
        <li>Type: 1101, 1102 1102, or 1103 as listed in <xref
          target="CODEPOINTVALUES"/>.</t>

          <t>Length: target="CODEPOINTVALUES" format="default"/></li>
        <li>Length: variable. Valid values are either 7 or 8 based on the whether
        the encoding is done as a SID Index or a label.</t> label.</li>
        <li>
          <t>Flags: one octet of flags with the following definition: </t>
          <figure
              anchor="PEERINGSIDFLAGS" title="Peering anchor="PEERINGSIDFLAGS">
            <name>Peering SID TLV Flags Format">
              <artwork><![CDATA[ Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|L|B|P| Rsvd  |
+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure><list style="symbols">
              <t>V-Flag:
          </figure>
          <ul spacing="normal">
            <li>V-Flag: Value flag. Flag. If set, then the SID carries a label
              value. By default default, the flag is SET.</t>

              <t>L-Flag: SET.</li>
            <li>L-Flag: Local Flag. If set, then the value/index carried by
              the SID has local significance. By default default, the flag is SET.</t>

              <t>B-Flag: SET.</li>
            <li>B-Flag: Backup Flag. If set, the SID refers to a path that is
            eligible for protection using fast re-route reroute (FRR). The computation
            of the backup forwarding path and its association with the BGP
            Peering SID forwarding entry is implementation specific. <xref
              target="I-D.ietf-spring-segment-routing-central-epe"/> section
              3.6
            target="RFC9087"
            sectionFormat="of" section="3.6"/> discusses some of the possible
            ways of identifying backup paths for BGP Peering SIDs.</t>

              <t>P-Flag: SIDs.</li>
            <li>P-Flag: Persistent Flag: If set, the SID is persistently
              allocated, i.e., the SID value remains consistent across router
              restart and session/interface flap.</t>

              <t>Rsvd flap.</li>
            <li>Rsvd bits: Reserved for future use and MUST <bcp14>MUST</bcp14> be zero when
              originated and ignored when received.</t>
            </list></t>

          <t>Weight: received.</li>
          </ul>
        </li>
        <li>Weight: 1 octet. The value represents the weight of the SID for
          the purpose of load balancing. An example use of the weight is
          described in <xref target="RFC8402"/>.</t> target="RFC8402" format="default"/>.</li>
        <li>
          <t>SID/Index/Label. According to the TLV length and to the V V- and L
          flags L-Flag settings, it contains either: <list style="symbols">
              <t>A 3 octet </t>
          <ul spacing="normal">
            <li>A 3-octet local label where the 20 rightmost bits are used
              for encoding the label value. In this case, the V V- and L flags
              MUST L-Flags
              <bcp14>MUST</bcp14> be SET.</t>

              <t>A 4 octet SET.</li>
            <li>A 4-octet index defining the offset in the Segment Routing
            Global Block (SRGB) <xref target="RFC8402"/> target="RFC8402" format="default"/>
            advertised by this router. In this case, the SRGB MUST
            <bcp14>MUST</bcp14> be advertised using the extensions defined in
            <xref
              target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/>.</t>
            </list></t>
        </list></t> target="RFC9085" format="default"/>.</li>
          </ul>
        </li>
      </ul>
      <t>The values of the PeerNode SID, PeerAdj SID, and PeerSet SID Sub-TLVs
      SHOULD
      <bcp14>SHOULD</bcp14> be persistent across router restart.</t>
      <t>When enabled for Egress Peer Engineering, the BGP router MUST <bcp14>MUST</bcp14> include
      the PeerNode SID TLV in the BGP-LS Attribute for the BGP-LS Link NLRI
      corresponding to its BGP peering sessions. The PeerAdj SID and PeerSet
      SID TLVs MAY <bcp14>MAY</bcp14> be included in the BGP-LS Attribute for the BGP-LS Link
      NLRI.</t>
      <t>Additional BGP-LS Link Attribute TLVs, TLVs as defined in <xref
      target="RFC7752"/> MAY target="RFC7752" format="default"/> <bcp14>MAY</bcp14> be included with the BGP-LS Link NLRI in order to
      advertise the characteristics of the peering link. E.g., link, e.g., one or more
      interface addresses (TLV 259 or TLV 261) of the underlying link(s) over
      which a multi-hop BGP peering session is setup set up may be included in the
      BGP-LS Attribute along with the PeerNode SID TLV.</t>
      <section anchor="PEERNODESID" title="Advertisement numbered="true" toc="default">
        <name>Advertisement of the PeerNode SID"> SID</name>
        <t>The PeerNode SID TLV includes a SID associated with the BGP peer
        node that is described by a BGP-LS Link NLRI as specified in <xref
        target="EPENLRI"/>.</t> target="EPENLRI" format="default"/>.</t>
        <t>The PeerNode SID, at the BGP node advertising it, has the following
        semantics (as defined in <xref target="RFC8402"/>):<list
            style="symbols">
            <t>SR target="RFC8402" format="default"/>):</t>
        <ul spacing="normal">
          <li>SR operation: NEXT.</t>

            <t>Next-Hop: NEXT</li>
          <li>Next-Hop: the connected peering node to which the segment is
            associated.</t>
          </list></t>
            associated</li>
        </ul>
        <t>The PeerNode SID is advertised with a BGP-LS Link NLRI, where:
        <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>Local Node Descriptors include:<list>
                <t>Local include:</t>
            <ul spacing="normal">
              <li>Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress
                PE.</t>

                <t>Local BGP-EPE-enabled Egress
                PE</li>
              <li>Local ASN (TLV 512).</t>
              </list></t> 512)</li>
            </ul>
          </li>
          <li>
            <t>Remote Node Descriptors include:<list>
                <t>Peer include:</t>
            <ul spacing="normal">
              <li>Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in
                the BGP session)</t>

                <t>Peer session)</li>
              <li>Peer ASN (TLV 512).</t>
              </list></t> 512)</li>
            </ul>
          </li>
          <li>
            <t>Link Descriptors include the addresses used by the BGP session
            encoded using TLVs as defined in <xref target="RFC7752"/>: <list>
                <t>IPv4 target="RFC7752" format="default"/>: </t>
            <ul spacing="normal">
              <li>IPv4 Interface Address (TLV 259) contains the BGP session
                IPv4 local address.</t>

                <t>IPv4 address.</li>
              <li>IPv4 Neighbor Address (TLV 260) contains the BGP session
                IPv4 peer address.</t>

                <t>IPv6 address.</li>
              <li>IPv6 Interface Address (TLV 261) contains the BGP session
                IPv6 local address.</t>

                <t>IPv6 address.</li>
              <li>IPv6 Neighbor Address (TLV 262) contains the BGP session
                IPv6 peer address.</t>
              </list></t>

            <t>Link address.</li>
            </ul>
          </li>
          <li>Link Attribute TLVs include the PeerNode SID TLV as defined in
            <xref target="PEERSID"/>.</t>
          </list></t> target="PEERSID" format="default"/>.</li>
        </ul>
      </section>
      <section anchor="PEERADJSID" title="Advertisement numbered="true" toc="default">
        <name>Advertisement of the PeerAdj SID"> SID</name>
        <t>The PeerAdj SID TLV includes a SID associated with the underlying
        link to the BGP peer node that is described by a BGP-LS Link NLRI as
        specified in <xref target="EPENLRI"/>.</t> target="EPENLRI" format="default"/>.</t>
        <t>The PeerAdj SID, at the BGP node advertising it, has the following
        semantics (as defined in <xref target="RFC8402"/>):<list
            style="symbols">
            <t>SR target="RFC8402" format="default"/>):</t>
        <ul spacing="normal">
          <li>SR operation: NEXT.</t>

            <t>Next-Hop: NEXT</li>
          <li>Next-Hop: the interface peer address.</t>
          </list></t> address</li>
        </ul>
        <t>The PeerAdj SID is advertised with a BGP-LS Link NLRI, where:<list
            style="symbols"> where:</t>
        <ul spacing="normal">
          <li>
            <t>Local Node Descriptors include:<list>
                <t>Local include:</t>
            <ul spacing="normal">
              <li>Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress
                PE.</t>

                <t>Local BGP-EPE-enabled Egress
                PE</li>
              <li>Local ASN (TLV 512).</t>
              </list></t> 512)</li>
            </ul>
          </li>
          <li>
            <t>Remote Node Descriptors include:<list>
                <t>Peer include:</t>
            <ul spacing="normal">
              <li>Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in
                the BGP session).</t>

                <t>Peer session)</li>
              <li>Peer ASN (TLV 512).</t>
              </list></t> 512)</li>
            </ul>
          </li>
          <li>
            <t>Link Descriptors MUST <bcp14>MUST</bcp14> include the following TLV, as defined in
            <xref target="RFC7752"/>: <list>
                <t>Link target="RFC7752" format="default"/>: </t>
            <ul spacing="normal">
              <li>Link Local/Remote Identifiers (TLV 258) contains the
                4-octet Link Local Identifier followed by the 4-octet Link
                Remote Identifier. The value 0 is used by default when the
                link remote identifier is unknown.</t>
              </list></t> unknown.</li>
            </ul>
          </li>
          <li>
            <t>Additional Link Descriptors TLVs, as defined in <xref
            target="RFC7752"/>, MAY target="RFC7752" format="default"/>, <bcp14>MAY</bcp14> also be included to describe the addresses
            corresponding to the link between the BGP routers: <list>
                <t>IPv4 </t>
            <ul spacing="normal">
              <li>IPv4 Interface Address (Sub-TLV 259) contains the address
                of the local interface through which the BGP session is
                established.</t>

                <t>IPv6
                established.</li>
              <li>IPv6 Interface Address (Sub-TLV 261) contains the address
                of the local interface through which the BGP session is
                established.</t>

                <t>IPv4
                established.</li>
              <li>IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4
                address of the peer interface used by the BGP session.</t>

                <t>IPv6 session.</li>
              <li>IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6
                address of the peer interface used by the BGP session.</t>
              </list></t>

            <t>Link session.</li>
            </ul>
          </li>
          <li>Link Attribute TLVs include the PeerAdj SID TLV as defined in
            <xref target="PEERSID"/>.</t>
          </list></t> target="PEERSID" format="default"/>.</li>
        </ul>
      </section>
      <section anchor="PEERSETSID" title="Advertisement numbered="true" toc="default">
        <name>Advertisement of the PeerSet SID "> SID</name>
        <t>The PeerSet SID TLV includes a SID that is shared amongst BGP peer
        nodes or the underlying links that are described by BGP-LS Link NLRI
        as specified in <xref target="EPENLRI"/>.</t> target="EPENLRI" format="default"/>.</t>
        <t>The PeerSet SID, at the BGP node advertising it, has the following
        semantics (as defined in <xref target="RFC8402"/>):<list
            style="symbols">
            <t>SR target="RFC8402" format="default"/>):</t>
        <ul spacing="normal">
          <li>SR operation: NEXT.</t>

            <t>Next-Hop: load balance NEXT</li>
          <li>Next-Hop: load-balance across any connected interface to any
          peer in the associated peer set.</t>
          </list></t> set</li>
        </ul>
        <t>The PeerSet SID TLV containing the same SID value (encoded as
        defined in <xref target="PEERSID"/>) target="PEERSID" format="default"/>) is included in the BGP-LS
        Attribute for all of the BGP-LS Link NLRI corresponding to the
        PeerNode or PeerAdj segments associated with the peer set.</t>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document defines:<list style="hanging">
          <t>A defines:</t>
<ul>
<li>A new Protocol-ID: BGP. The codepoint code point is from the "BGP-LS Protocol-IDs" registry.</t>

          <t>Two registry.
</li>
<li>Two new TLVs: BGP-Router-ID and BGP Confederation Member. The
          codepoints code points
are in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs" registry.</t>

          <t>Three registry.
</li>
<li>Three new BGP-LS Attribute TLVs: PeerNode SID, PeerAdj SID SID, and PeerSet
SID. The codepoints code points are in the "BGP-LS Node Descriptor, Link Descriptor,
Prefix Descriptor, and Attribute TLVs" registry.</t>
        </list></t> registry.
</li>
</ul>

      <section anchor="IANAPROT" title="New numbered="true" toc="default">
        <name>New BGP-LS Protocol-ID"> Protocol-ID</name>
        <t>This document defines a new value in the registry "BGP-LS
        Protocol-IDs":<figure align="center" anchor="BGPPROT"
            title="BGP Protocol Codepoint">
            <artwork align="center"><![CDATA[+------------------------------------------------------+
|  Codepoint | Description |         Status            |
+------------------------------------------------------+
|    7       | BGP         | Early Allocation by IANA  |
+------------------------------------------------------+]]></artwork>
          </figure></t>
        Protocol-IDs":</t>

<table anchor="BGPPROT">
  <name>BGP-LS Protocol-ID</name>
  <thead>
    <tr>
      <th>Protocol-ID</th>
      <th>NLRI information source protocol</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>7</td>
      <td>BGP</td>
      <td>RFC 9086</td>
    </tr>

  </tbody>
</table>

      </section>
      <section anchor="IANANODEATTR"
               title="Node numbered="true" toc="default">
        <name>Node Descriptors and Link Attribute TLVs"> TLVs</name>
        <t>This document defines 5 five new TLVs in the registry "BGP-LS Node
        Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
        TLVs":<list style="symbols">
            <t>Two
        TLVs":</t>
        <ul spacing="normal">
          <li>Two new node descriptor TLVs</t>

            <t>Three Node Descriptor TLVs</li>
          <li>Three new link attribute TLVs</t>
          </list></t> Link Attribute TLVs</li>
        </ul>
        <t>All five of the new 5 codepoints code points are in the same registry: "BGP-LS Node
        Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
        TLVs".</t>
        <t>The following new Node Descriptors Descriptor TLVs are defined: <figure
            align="center" anchor="DESCCODE"
            title="BGP-LS </t>

<table anchor="DESCODE">
  <name>BGP-LS Descriptor TLVs Codepoints">
            <artwork align="center"><![CDATA[+-------------------------------------------------------------------+
|  Codepoint | Description              |         Status            |
+-------------------------------------------------------------------+
|    516     | BGP Router-ID            | Early Allocation by IANA  |
|    517     | BGP TLV Code Points</name>
  <thead>
    <tr>
      <th>TLV Code Point</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>516</td>
      <td>BGP Router-ID</td>
      <td>RFC 9086</td>
    </tr>
    <tr>
      <td>517</td>
      <td>BGP Confederation Member | Early Allocation by IANA  |
+------------+------------------------------------------------------+]]></artwork>
          </figure></t> Member</td>
      <td>RFC 9086</td>
    </tr>
  </tbody>
</table>

        <t>The following new Link Attribute TLVs are defined: <figure
            align="center" anchor="ATTRCODE"
            title="BGP-LS </t>

<table anchor="ATTRCODE">
  <name>BGP-LS Attribute TLVs Codepoints">
            <artwork align="center"><![CDATA[+-------------------------------------------------------------------+
|  Codepoint | Description              |         Status            |
+-------------------------------------------------------------------+
|    1101    | PeerNode SID             | Early Allocation by IANA  |
|    1102    | PeerAdj SID              | Early Allocation by IANA  |
|    1103    | PeerSet SID              | Early Allocation by IANA  |
+------------+------------------------------------------------------+]]></artwork>
          </figure></t> TLV Code Points</name>
  <thead>
    <tr>
      <th>TLV Code Point</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1101</td>
      <td>PeerNode SID </td>
      <td>RFC 9086</td>
    </tr>
    <tr>
      <td>1102</td>
      <td>PeerAdj SID</td>
      <td>RFC 9086</td>
    </tr>
    <tr>
      <td>1103</td>
      <td>PeerSet SID</td>
      <td>RFC 9086</td>
    </tr>
  </tbody>
</table>

      </section>
    </section>
    <section anchor="Manageability" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>The new protocol extensions introduced in this document augment the
      existing IGP topology information BGP-LS distribution <xref
      target="RFC7752"/>
      target="RFC7752" format="default"/> by adding support for distribution
      of BGP peering topology information. As such, the Manageability Considerations section
      of <xref target="RFC7752"/> target="RFC7752"
      sectionFormat="of" section="6"/> (Manageability Considerations) applies
      to these new extensions as well.</t>
      <t>Specifically, the malformed Link-State NLRI and BGP-LS Attribute
      tests for syntactic checks in the Fault Management section of <xref
      target="RFC7752"/> target="RFC7752" sectionFormat="of"
      section="6.2.2"/> (Fault Management) now apply to the TLVs defined in
      this document. The semantic or content checking for the TLVs specified
      in this document and their association with the BGP-LS NLRI types or
      their associated BGP-LS Attributes is left to the consumer of the BGP-LS
      information (e.g., an application or a controller) and not the BGP
      protocol.</t>
      <t>A consumer of the BGP-LS information retrieves this information from
      a BGP Speaker, over a BGP-LS session (refer Section 1 to Sections <xref
      target="RFC7752" sectionFormat="bare" section="1"/> and 2 <xref
      target="RFC7752" sectionFormat="bare" section="2"/> of <xref
      target="RFC7752"/>).
      target="RFC7752" format="default"/>). The handling of semantic or
      content errors by the consumer would be dictated by the nature of its
      application usage and
      hence is hence beyond the scope of this document. It may
      be expected that an error detected in the NLRI descriptor Descriptor TLVs would
      result in that specific NLRI update being unusable and hence its update
      to be discarded along with an error log. While log, whereas an error in Attribute
      TLVs would result in only that specific attribute being discarded with
      an error log.</t>

      <t>The operator MUST <bcp14>MUST</bcp14> be provided with the options of configuring,
      enabling, and disabling the advertisement of each of the PeerNode SID,
      PeerAdj SID, and PeerSet SID as well as control of which information is
      advertised to which internal or external peer. This is not different
      from what is required by a BGP speaker in terms of information
      origination and advertisement.</t>
      <t>BGP Peering Segments are associated with the normal BGP routing
      peering sessions. However, the BGP peering information along with these
      Peering Segments themselves are advertised via a distinct BGP-LS peering
      session. It is expected that this isolation as described in <xref
      target="RFC7752"/>
      target="RFC7752" format="default"/> is followed when advertising BGP
      peering topology information via BGP-LS.</t>
      <t>BGP-EPE functionality enables the capability for instantiation of an
      SR path for traffic engineering a flow via an egress BGP router to a
      specific peer, bypassing the normal BGP best path best-path routing for that flow
      and any routing policies implemented in BGP on that egress BGP router.
      As with any traffic engineering traffic-engineering solution, the controller or application
      implementing the policy needs to ensure that there is no looping or
      mis-routing
      misrouting of traffic. Traffic counters corresponding to the MPLS label
      of the BGP Peering SID on the router would indicate the traffic being
      forwarded based on the specific EPE path. Monitoring these counters and
      the flows hitting the corresponding MPLS forwarding entry would help
      identify issues, if any, with traffic engineering over the EPE paths.
      Errors in the encoding or decoding of the SR information in the TLVs
      defined in this document may result in the unavailability of such
      information to a Centralized EPE Controller or incorrect information
      being made available to it. This may result in the controller not being
      able to perform the desired SR based SR-based optimization functionality or to
      perform
      performing it in an unexpected or inconsistent manner. The handling of
      such errors by applications like such a controller may be implementation
      specific and out of scope of this document.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t><xref target="RFC7752"/> target="RFC7752" format="default"/> defines BGP-LS NLRI to
      which the extensions defined in this document apply. The Security Considerations section of <xref target="RFC7752"/>
      target="RFC7752" sectionFormat="of" section="8"/> also applies to these extensions. The procedures and new
      TLVs defined in this document, by themselves, do not affect the BGP-LS
      security model discussed in <xref
      target="RFC7752"/>.</t> target="RFC7752"
      format="default"/>.</t>
      <t>BGP-EPE enables engineering of traffic when leaving the
      administrative domain via an egress BGP router. Therefore Therefore, precaution is
      necessary to ensure that the BGP peering information collected via
      BGP-LS is limited to specific consumers in a secure manner. Segment
      Routing operates within a trusted domain <xref target="RFC8402"/> target="RFC8402" format="default"/>, and
      its security considerations also apply to BGP Peering Segments. The
      BGP-EPE policies are expected to be used entirely within this trusted SR
      domain (e.g., between multiple AS/domains within a single provider
      network).</t>
      <t>The isolation of BGP-LS peering sessions is also required to ensure
      that BGP-LS topology information (including the newly added BGP peering
      topology) is not advertised to an external BGP peering session outside
      an administrative domain.</t>
    </section>

    <section anchor="Contributors" title="Contributors">
      <figure>
        <artwork><![CDATA[Mach (Guoyi) Chen
Huawei Technologies
China

Email: mach.chen@huawei.com]]></artwork>
      </figure>

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

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

  </middle>
  <back>

<displayreference target="I-D.ietf-spring-segment-routing-policy" to="SR-POLICY"/>

<displayreference target="I-D.ietf-idr-bgpls-srv6-ext" to="BGPLS-SRV6"/>

    <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.6286.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5065.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.7752.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<reference anchor='RFC9085' target='https://www.rfc-editor.org/info/rfc9085'>
<front>
<title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing</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='C' surname='Filsfils' fullname='Clarence Filsfils'>
    <organization />
</author>

<author initials='H' surname='Gredler' fullname='Hannes Gredler'>
    <organization />
</author>

<author initials='M' surname='Chen' fullname='Mach(Guoyi) Chen'>
    <organization />
</author>

<date month="August" year="2021"/>

</front>
<seriesInfo name="RFC" value="9085"/>
<seriesInfo name="DOI" value="10.17487/RFC9085"/>
</reference>

      </references>

      <references>
        <name>Informative References</name>

<reference anchor='RFC9087' target='https://www.rfc-editor.org/info/rfc9087'>
<front>
<title>Segment Routing Centralized BGP Egress Peer Engineering</title>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils' role='editor'>
<organization />
</author>
<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
<organization />
</author>
<author initials='G' surname='Dawra' fullname='Gaurav Dawra' role='editor'>
<organization />
</author>
<author initials='E' surname='Aries' fullname='Ebben Aries'>
<organization />
</author>
<author initials='D' surname='Afanasiev' fullname='Dmitry Afanasiev'>
<organization />
</author>

<date month="August" year="2021"/>
</front>
<seriesInfo name="RFC" value="9087"/>
<seriesInfo name="DOI" value="10.17487/RFC9087"/>
</reference>

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

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-idr-bgpls-srv6-ext.xml"/>

  </references>
    </references>
    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Jakob Heitz, Howard Yang, Hannes
      Gredler, Peter Psenak, Arjun Sreekantiah and Bruno Decraene <contact fullname="Jakob Heitz"/>,
      <contact fullname="Howard Yang"/>, <contact fullname="Hannes
      Gredler"/>, <contact fullname="Peter Psenak"/>, <contact fullname="Arjun
      Sreekantiah"/>, and <contact fullname="Bruno Decraene"/> for their
      feedback and comments. Susan Hares <contact fullname="Susan Hares"/> helped in improving the clarity of
      the document with her substantial contributions during her shepherd's
      review. The authors would also like to thank Alvaro Retana <contact fullname="Alvaro Retana"/> for his
      extensive review and comments comments, which helped correct issues and improve
      the document.</t>
    </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.6286.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5065.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.7752.xml"?>

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

      <?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-spring-segment-routing-central-epe.xml"?>

      <?rfc include="reference.I-D.ietf-spring-segment-routing-policy.xml"?>

      <?rfc include="reference.I-D.dawra-idr-bgpls-srv6-ext.xml"?>
    </references>

    <section anchor="Contributors" numbered="false" toc="default">
      <name>Contributors</name>

 <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>China
	  </country>
        </postal>
        <email>mach.chen@huawei.com</email>
      </address>
 </author>

<author fullname="Acee Lindem" initials="A" surname="Lindem">
      <organization>Cisco Systems Inc.</organization>
      <address>
	<postal>
          <street/>
          <city/>
          <code/>
          <country>United States of America
	  </country>
	</postal>
	<email>acee@cisco.com</email>
      </address>
</author>

    </section>

  </back>
</rfc>