<?xml version="1.0" encoding="UTF-8"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
]>
<?rfc comments="yes"?>
<?rfc compact="no"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="5"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8669"
     category="std" consensus="true" submissionType="IETF"
     ipr="trust200902" docName="draft-ietf-idr-bgp-prefix-sid-27"
     ipr="trust200902"> obsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3">

  <front>
    <title abbrev="">Segment abbrev="SR Prefix-SID Extensions for BGP">Segment Routing Prefix SID extensions
    Segment Identifier Extensions for BGP</title>
    <seriesInfo name="RFC" value="8669"/>
    <author fullname="Stefano Previdi" initials="S." surname="Previdi">
      <organization>Cisco Systems</organization>
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>
          <city/>

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

        <email>cfilsfils@cisco.com</email>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Acee Lindem" initials="A." surname="Lindem" role="editor">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>301 Midenhall Way</street>
          <city>Cary, NC</city>

          <country>USA</country>
          <country>United States of America</country>
          <code>27513</code>
        </postal>
        <phone/>
        <email>acee@cisco.com</email>
      </address>
    </author>
    <author fullname="Arjun Sreekantiah" initials="A." surname="Sreekantiah">
      <address>
        <email>arjunhrs@gmail.com</email>
      </address>
    </author>
    <author fullname="Hannes Gredler" initials="H." surname="Gredler">
      <organization>RtBrick Inc.</organization>
      <address>
        <email>hannes@rtbrick.com</email>
      </address>
    </author>

    <date/>
    <date month="December" year="2019"/>
    <area>Routing</area>
    <workgroup>IDR</workgroup>

    <keyword>SR</keyword>
    <keyword>MPLS</keyword>
    <keyword>BGP</keyword>
    <keyword>Prefix-SID</keyword>
    <keyword>Label-Index</keyword>
    <keyword>SRGB</keyword>
    <abstract>
      <t>Segment Routing (SR) leverages the source routing source-routing paradigm. A node
      steers a packet through an ordered list of instructions, instructions called
        segments.
      "segments". A segment can represent any instruction, topological or
        service-based.
      service based. The ingress node prepends an SR header to a packet
      containing a set of segment identifiers (SID). (SIDs). Each SID represents a
      topological or a service-based instruction. Per-flow state is maintained
      only on the ingress node of the SR domain. An SR domain "SR domain" is defined as a
      single administrative domain for global SID assignment.</t>
      <t>This document defines an optional, transitive BGP attribute for
      announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SID)
      information Prefix-SIDs)
      and the specification for SR-MPLS SIDs.</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>The Segment Routing (SR) architecture leverages the source routing source-routing
      paradigm. A segment represents either a topological instruction instruction, such as
      "go to prefix P following shortest path" path", or a service instruction.
      Other types of segments may be defined in the future.</t>
      <t>A segment is identified through a Segment Identifier (SID).
      An SR domain "SR domain" is defined as a single administrative domain for
      global SID assignment. It may be comprised of a single Autonomous System (AS)
      or multiple ASes under consolidated global SID administration. Typically, the ingress
      node of the SR domain prepends an SR header containing segments
      identifiers (SIDs) SIDs to an incoming packet.</t>
      <t>As described in <xref target="I-D.ietf-spring-segment-routing"/>, target="RFC8402" format="default"/>,
      when SR is applied to the MPLS dataplane data plane (<xref
      target="I-D.ietf-spring-segment-routing-mpls"/>), target="RFC8660" format="default"/>), the SID consists of a
      label.</t>
      <t><xref target="I-D.ietf-spring-segment-routing"/> target="RFC8402" format="default"/> also
      describes how segment routing Segment Routing can be applied to an IPv6 dataplane data plane (SRv6) using
      an IPv6 routing header containing a stack of SR SIDs encoded as
      IPv6 addresses <xref target="I-D.ietf-6man-segment-routing-header"/>. target="I-D.ietf-6man-segment-routing-header" format="default"/>.
      The applicability and support for Segment Routing over IPv6 is beyond the
      scope of this document.</t>
      <t>A BGP-Prefix BGP Prefix Segment is a BGP prefix with a Prefix-SID attached.
      A BGP Prefix-SID is always a global SID (<xref
      target="I-D.ietf-spring-segment-routing"/>) target="RFC8402" format="default"/>) within the SR domain
      and identifies an instruction to forward
      the packet over the Equal-Cost Multi-Path Multipath (ECMP) best-path best path
      computed by BGP to the related
      prefix. The BGP Prefix-SID is the identifier of the BGP prefix segment. Prefix Segment.
      In this document, we always refer to the BGP-Prefix segment BGP Prefix Segment by the BGP
      Prefix-SID.</t>
      <t>This document describes the BGP extension extensions to signal the BGP
      Prefix-SID. Specifically, this document defines a BGP attribute
      known as the BGP "BGP Prefix-SID attribute attribute" and specifies the rules to
      originate, receive, and handle error conditions for the attribute.</t>
      <t>The BGP Prefix-SID attribute defined in this document can be attached
       to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled
       Unicast (<xref target="RFC4760"/>, target="RFC4760" format="default"/> <xref target="RFC8277"/>). target="RFC8277" format="default"/>).
       Usage of the BGP Prefix-SID attribute for other
       Address Family Identifier (AFI)/ (AFI) / Subsequent Address
       Family Identifier (SAFI) combinations
       is not defined herein but may be specified in
       future specifications.</t>
      <t><xref target="I-D.ietf-spring-segment-routing-msdc"/> target="RFC8670" format="default"/> describes
      example use cases where the BGP Prefix-SID is used for the above
      AFI/SAFI combinations.</t>
      <t>It should be noted that:<list style="symbols">
          <t>A that:</t>
      <ul spacing="normal">
        <li>A BGP Prefix-SID will be global across ASes when the
          interconnected ASes are part of the same SR domain.
          Alternatively, when interconnecting ASes, the ASBRs of each
          domain will have to handle the advertisement of unique SIDs. The
          mechanisms for such interconnection are outside the scope of the
          protocol extensions defined in this document.</t>

          <t>A document.</li>
        <li>A BGP Prefix-SID MAY <bcp14>MAY</bcp14> be attached to a BGP prefix.
          This implies that each prefix is advertised individually, reducing the
          ability to pack BGP advertisements (when sharing common
          attributes).</t>
        </list></t>
          attributes).</li>
      </ul>
      <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 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section anchor="MPLSPREFIXSID" title="MPLS numbered="true" toc="default">
      <name>MPLS BGP Prefix SID"> Prefix-SID</name>
      <t>The BGP Prefix-SID is realized on the MPLS dataplane data plane (<xref
        target="I-D.ietf-spring-segment-routing-mpls"/>) target="RFC8660" format="default"/>) in the following
        way:<list style="hanging">
            <t>The
      way:</t>

      <ul empty="true" spacing="normal">

        <li>The operator
            assigns a globally unique label index, L_I, to a locally originated
            prefix of a BGP speaker N N, which is advertised to all other BGP
            speakers in the SR domain.</t>

            <t>According domain.</li>

        <li>According to <xref target="I-D.ietf-spring-segment-routing"/>, target="RFC8402" format="default"/>,
            each BGP speaker is configured with a label block called the
            Segment Routing Global Block (SRGB). While <xref
            target="I-D.ietf-spring-segment-routing"/> target="RFC8402" format="default"/> recommends using the
            same SRGB across all the nodes within the SR domain, the SRGB of a
            node is a local property and could be different on different
            speakers. The drawbacks of the use case where BGP speakers have
            different SRGBs are documented in <xref
            target="I-D.ietf-spring-segment-routing"/> target="RFC8402" format="default"/> and <xref
            target="I-D.ietf-spring-segment-routing-msdc"/>.</t>

            <t>If traffic-engineering target="RFC8670" format="default"/>.</li>

        <li>If traffic engineering within the SR domain is required, each
            node may also be required to advertise topological information and
            Peering
            Peer SIDs for each of its links and peers. This information is
            required to perform the explicit path computation and to
            express an explicit path as a list of SIDs. The advertisement
            of topological information and peer segments (Peer SIDs) is done
            through <xref target="I-D.ietf-idr-bgpls-segment-routing-epe"/>.</t>

            <t>If target="I-D.ietf-idr-bgpls-segment-routing-epe" format="default"/>.</li>

        <li>If a prefix segment is to be included in an MPLS label stack,
        e.g., for traffic engineering traffic-engineering purposes, the knowledge of the SRGB
               of the originator of the prefix
        originator's SRGB is required in order to compute the local label used
        by the originator.</t>

            <t>This originator.</li>

        <li>This document assumes that BGP-LS Border Gateway Protocol - Link State
	    (BGP-LS) is the preferred method for a
            collecting both peer segments (Peer SIDs) and SRGB
            information through <xref target="RFC7752"/>, target="RFC7752" format="default"/>, <xref
            target="I-D.ietf-idr-bgpls-segment-routing-epe"/>, target="I-D.ietf-idr-bgpls-segment-routing-epe" format="default"/>, and <xref
            target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/>. target="I-D.ietf-idr-bgp-ls-segment-routing-ext" format="default"/>. However, as an
            optional alternative for the advertisement of the local SRGB
            without the topology nor or the peer SIDs, hence SIDs and, therefore, without
            applicability for TE, the Originator SRGB TLV of the BGP Prefix-SID
            attribute is specified in <xref target="ORIGINSRGBTLV"/> target="ORIGINSRGBTLV" format="default"/> of this
            document.</t>

            <t>A
            document.</li>

        <li>A BGP speaker will derive its local MPLS label L from the
               label index L_I and its local SRGB as
               described in <xref target="I-D.ietf-spring-segment-routing-mpls"/>. target="RFC8660" format="default"/>. The
               BGP speaker then programs the MPLS label L in its MPLS dataplane data plane as
               its incoming/local label for the prefix.
               See <xref target="RECMPLSLABEL"/> target="RECMPLSLABEL" format="default"/> for more details.</t>

            <t>The details.</li>

        <li>The outgoing label for the prefix is found in the
            Network Layer Reachability Information (NLRI) of the
            Multiprotocol BGP IPv4/IPv6 Labeled Unicast prefix advertisement as
            defined in <xref target="RFC8277"/>. target="RFC8277" format="default"/>.
            The label index L_I is only used as a hint to derive the local/incoming
            label.</t>

            <t><xref target="LABELINDEX"/>
            label.</li>

        <li>
          <xref target="LABELINDEX" format="default"/> of this document specifies the
            Label-Index TLV of the BGP Prefix-SID attribute; this TLV can be
            used to advertise the label index for a given prefix.</t>
          </list></t> prefix.</li>
      </ul>
    </section>
    <section anchor="PREFIXSIDATTR" title="BGP numbered="true" toc="default">
      <name>BGP Prefix-SID Attribute"> Attribute</name>
      <t>The BGP Prefix-SID attribute is an optional, transitive BGP path
      attribute. The attribute type code 40 has been assigned by IANA (see
      <xref target="IANA"/>).</t> target="IANA" format="default"/>).</t>
      <t>The BGP Prefix-SID attribute is defined here to be a set of elements
      encoded as "Type/Length/Value" tuples (i.e., a set of TLVs). All BGP
      Prefix-SID attribute TLVs will start with a 1-octet type and a 2-octet
      length. The following TLVs are defined in this
      document:<list style="symbols">
          <t>Label-Index TLV</t>

          <t>Originator
      document:</t>
      <ul spacing="normal">
        <li>Label-Index TLV</li>
        <li>Originator SRGB TLV</t>
        </list></t> TLV</li>
      </ul>
      <t>The Label-Index and Originator SRGB TLVs are used only when SR is applied
      to the MPLS dataplane.</t> data plane.</t>
      <t>For future extensibility, unknown TLVs MUST <bcp14>MUST</bcp14> be ignored and propagated
         unmodified.</t>
      <section anchor="LABELINDEX" title="Label-Index TLV"> numbered="true" toc="default">
        <name>Label-Index TLV</name>
        <t>The Label-Index TLV MUST <bcp14>MUST</bcp14> be present in the BGP Prefix-SID attribute
        attached to IPv4/IPv6 Labeled Unicast prefixes (<xref
        target="RFC8277"/>). target="RFC8277" format="default"/>). It MUST <bcp14>MUST</bcp14> be ignored when received for other
        BGP AFI/SAFI combinations. The Label-Index TLV has the
        following format:<figure
            align="center"> format:</t>
        <artwork align="left"> align="left" name="" type="" alt=""><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Type    |             Length            |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Flags              |       Label Index             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Label Index          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
          </figure>where: <list style="symbols">
            <t>Type is 1.</t>

            <t>Length: is 7,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        <t>where: </t><ul empty="true"><li>
        <dl newline="false" spacing="normal">
          <dt>Type:</dt>
	  <dd>1</dd>
          <dt>Length:</dt><dd>7, the total length in octets of the value portion
               of the TLV.</t>

            <t>RESERVED: 8-bit TLV.</dd>
          <dt>RESERVED:</dt><dd>8-bit field. MUST It <bcp14>MUST</bcp14> be clear on transmission and MUST <bcp14>MUST</bcp14> be
            ignored on reception.</t>

            <t>Flags: 16 reception.</dd>
          <dt>Flags:</dt><dd>16 bits of flags. None are defined by this document. The
            flag
            Flags field MUST <bcp14>MUST</bcp14> be clear on transmission and MUST <bcp14>MUST</bcp14> be ignored on
            reception.</t>

            <t>Label Index: 32-bit
            reception.</dd>
          <dt>Label Index:</dt><dd>32-bit value representing the index value in the
            SRGB space.</t>
          </list></t> space.</dd>
        </dl></li></ul>
      </section>
      <section anchor="ORIGINSRGBTLV" title="Originator numbered="true" toc="default">
        <name>Originator SRGB TLV"> TLV</name>
        <t>The Originator SRGB TLV is an optional TLV and has the following
        format:<figure align="center">
        format:</t>
        <artwork align="left"> align="left" name="" type="" alt=""><![CDATA[  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |          Length               |    Flags      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Flags     |
 +-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         SRGB 1 (6 octets)                                     |
 |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         SRGB n (6 octets)                                     |
 |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
          </figure>where: <list style="symbols">
            <t>Type is 3.</t>

            <t>Length is the
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        <t>where:</t><ul empty="true"><li>

	   <dl newline="false" spacing="normal">
          <dt>Type:</dt><dd>3</dd>
          <dt>Length:</dt><dd>The total length in octets of the value portion of
            the TLV: 2 + (non-zero multiple of 6).</t>

            <t>Flags: 16 6).</dd>
          <dt>Flags:</dt><dd>16 bits of flags. None are defined in this document.
            The Flags MUST field <bcp14>MUST</bcp14> be clear on transmission and MUST <bcp14>MUST</bcp14> be ignored on
            reception.</t>

            <t>SRGB: 3
            reception.</dd>
          <dt>SRGB:</dt><dd>3 octets specifying the first label in the range followed
            by 3 octets specifying the number of labels in the range. Note that
            the SRGB field MAY <bcp14>MAY</bcp14> appear multiple times. If the SRGB field
            appears multiple times, the SRGB consists of multiple ranges
            that are concatenated.</t>
          </list></t> concatenated.</dd>
        </dl></li></ul>
        <t>The Originator SRGB TLV contains the SRGB of the node originating
        the prefix to which the BGP Prefix-SID is attached. The Originator
        SRGB TLV MUST NOT <bcp14>MUST NOT</bcp14> be changed during the propagation of the BGP
        update. It is used to build segment routing SR policies
        when different SRGBs are used in the fabric, for example (<xref
        target="I-D.ietf-spring-segment-routing-msdc"/>).</t> example, <xref target="RFC8670" format="default"/>.</t>
        <t>Examples of how the receiving routers concatenate the
          ranges and build their neighbor's Segment Routing Global Block (SRGB)
          are included in <xref target="I-D.ietf-spring-segment-routing-mpls"/>).</t> target="RFC8660" format="default"/>.</t>
        <t>The Originator SRGB TLV may only appear in a BGP Prefix-SID attribute
        attached to IPv4/IPv6 Labeled Unicast prefixes (<xref
        target="RFC8277"/>). target="RFC8277" format="default"/>). It MUST <bcp14>MUST</bcp14> be ignored when received for other
        BGP AFI/SAFI combinations. Since the Label-Index TLV is required
        for IPv4/IPv6 prefix applicability, the Originator SRGB TLV will be
        ignored if it is not specified in a manner consistent with <xref
        target="ERRORHANDLING"/>.</t> target="ERRORHANDLING" format="default"/>.</t>
        <t>If a BGP speaker receives a node’s node's SRGB as an attribute of the BGP-LS
         Node NLRI and the BGP speaker also receives the same node’s node's SRGB
         in a BGP Prefix-SID attribute, then the received values should be the
         same. If the values are different, the values advertised in the BGP-LS
         NLRI SHOULD <bcp14>SHOULD</bcp14> be preferred preferred, and an error should be logged.</t>
      </section>
    </section>
    <section title="Receiving numbered="true" toc="default">
      <name>Receiving BGP Prefix-SID Attribute"> Attribute</name>
      <t>A BGP speaker receiving a BGP Prefix-SID attribute from an External BGP (EBGP)
      neighbor residing outside the boundaries of the SR domain MUST <bcp14>MUST</bcp14>
      discard the attribute unless it is configured to accept the attribute
      from the EBGP neighbor. A BGP speaker SHOULD <bcp14>SHOULD</bcp14> log an error for further
      analysis when discarding an attribute.</t>
      <section anchor="RECMPLSLABEL" title="MPLS Dataplane: numbered="true" toc="default">
        <name>MPLS Data Plane: Labeled Unicast"> Unicast</name>
        <t>A BGP session supporting the Multiprotocol BGP labeled Labeled IPv4 or IPv6 Unicast (<xref
        target="RFC8277"/>) target="RFC8277" format="default"/>) AFI/SAFI is required.</t>
        <t>When the  BGP Prefix-SID attribute is attached to a BGP labeled Labeled IPv4 or IPv6
          Unicast <xref target="RFC8277"/> target="RFC8277" format="default"/> AFI/SAFI, it MUST <bcp14>MUST</bcp14> contain the Label-Index TLV
          and MAY <bcp14>MAY</bcp14> contain the Originator SRGB TLV.  A BGP Prefix-SID attribute received
          without a Label-Index TLV MUST <bcp14>MUST</bcp14> be considered as to be "invalid" by the
          receiving speaker.</t>
        <t>The label index provides guidance to the receiving BGP speaker as to
          the incoming label that SHOULD <bcp14>SHOULD</bcp14> be allocated to the prefix.</t>
        <t>A BGP speaker may be locally configured with an SRGB=[SRGB_Start,
        SRGB_End]. The preferred method for deriving the SRGB is a matter of
        local node configuration.</t>
        <t>The mechanisms through which a given label index label-index value is assigned
        to a given prefix are outside the scope of this document.</t>
        <t>Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the
        derived label. A BGP Prefix-SID attribute is designated "conflicting" for
        a speaker M if the derived label value L lies outside the SRGB
        configured on M. Otherwise Otherwise, the Label-Index TLV is designated
        "acceptable" to speaker M.</t>
        <t>If multiple different prefixes are received with the same label
           index, all of the different prefixes MUST <bcp14>MUST</bcp14> have
           their BGP Prefix-SID attribute considered as “conflicting”.</t> to be "conflicting".</t>
        <t>If multiple valid paths for the same prefix are received from
          multiple BGP speakers or, in the case of <xref target="RFC7911"/>, target="RFC7911" format="default"/>,
          from the same BGP speaker, and the BGP Prefix-SID attributes do
          not contain the same label index, then the label index from
          the best path BGP Prefix-SID attribute SHOULD <bcp14>SHOULD</bcp14> be chosen with
          a notable exception being when <xref target="RFC5004"/> target="RFC5004" format="default"/>
          is being used to dampen route changes.</t>
        <t>When a BGP speaker receives a path from a neighbor with an
        "acceptable" BGP Prefix-SID attribute and that path is selected as
        the best path, it SHOULD <bcp14>SHOULD</bcp14> program the derived label
        as the label for the prefix in its local MPLS dataplane.</t> data plane.</t>
        <t>When a BGP speaker receives a path from a neighbor with an
        "invalid" or "conflicting" BGP Prefix-SID attribute attribute, or when a
        BGP speaker receives a path from a neighbor with a BGP Prefix-SID
        attribute but is unable to process it (e.g., local policy disables
        the functionality), it MUST <bcp14>MUST</bcp14> ignore the
        BGP Prefix-SID attribute. For the purposes of label allocation, a
        BGP speaker MUST <bcp14>MUST</bcp14> assign a local (also called dynamic) label (non-SRGB)
        for such a prefix as per classic Multiprotocol BGP IPv4/IPv6 Labeled
        Unicast (<xref target="RFC8277"/>) target="RFC8277" format="default"/>) operation.</t>
        <t>In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker MUST <bcp14>MUST</bcp14>
        follow the error handling error-handling rules specified in <xref target="ERRORHANDLING"/>. target="ERRORHANDLING" format="default"/>.
        A BGP speaker SHOULD <bcp14>SHOULD</bcp14> log an error for further analysis. In the case of a
        "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT <bcp14>SHOULD NOT</bcp14> treat it
        as an error and SHOULD <bcp14>SHOULD</bcp14> propagate the attribute unchanged. A BGP Speaker SHOULD speaker <bcp14>SHOULD</bcp14>
        log a warning for further analysis, i.e., in the case the conflict is
        not due to a label index label-index transition.</t>
        <t>When a BGP Prefix-SID attribute changes and transitions from
           "conflicting" to "acceptable", the BGP Prefix-SID attributes for other
           prefixes may also transition to "acceptable" as well. Implementations SHOULD
           assure <bcp14>SHOULD</bcp14>
           ensure all impacted prefixes revert to using the label indices
           corresponding to these newly "acceptable" BGP Prefix-SID attributes.</t>
        <t>The outgoing label is always programmed as per classic
        Multiprotocol BGP IPv4/IPv6 Labeled Unicast (<xref target="RFC8277"/>) target="RFC8277" format="default"/>)
        operation. Specifically, a BGP speaker receiving a prefix with a BGP Prefix-SID
        attribute and a label NLRI field of Implicit NULL
        <xref target="RFC3032"/> target="RFC3032" format="default"/> from a neighbor MUST <bcp14>MUST</bcp14>
        adhere to standard behavior and program its MPLS dataplane data plane to pop the
        top label when forwarding traffic to the prefix. The label NLRI
        defines the outbound label that MUST <bcp14>MUST</bcp14> be used by the receiving node.</t>
      </section>
    </section>
    <section title="Advertising numbered="true" toc="default">
      <name>Advertising BGP Prefix-SID Attribute"> Attribute</name>
      <t>The BGP Prefix-SID attribute MAY <bcp14>MAY</bcp14> be attached to BGP IPv4/IPv6 Label Labeled Unicast prefixes
      <xref target="RFC8277"/>. target="RFC8277" format="default"/>. In order to prevent distribution of the BGP
      Prefix-SID attribute beyond its intended scope of applicability,
      attribute filtering SHOULD <bcp14>SHOULD</bcp14> be deployed to remove the BGP
      Prefix-SID attribute at the administrative boundary of the
      segment routing
      SR domain.</t>
      <t>A BGP speaker that advertises a path received from one of its
        neighbors SHOULD <bcp14>SHOULD</bcp14> advertise the BGP Prefix-SID received with the path
        without modification, modification as long as the BGP Prefix-SID was acceptable.
        If the path did not come with a BGP Prefix-SID attribute, the
        speaker MAY <bcp14>MAY</bcp14> attach a BGP Prefix-SID to the path if configured to do so.
        The content of the TLVs present in the BGP Prefix-SID is determined by the
        configuration.</t>
      <section anchor="ADVMPLSLABEL" title="MPLS Dataplane: numbered="true" toc="default">
        <name>MPLS Data Plane: Labeled Unicast"> Unicast</name>
        <t>A BGP speaker that originates a prefix attaches the BGP Prefix-SID
        attribute when it advertises the prefix to its neighbors via
        Multiprotocol BGP IPv4/IPv6 Labeled Unicast (<xref
        target="RFC8277"/>). target="RFC8277" format="default"/>). The value of the label index in the Label-Index
        TLV is determined by configuration.</t>
        <t>A BGP speaker that originates a BGP Prefix-SID attribute MAY <bcp14>MAY</bcp14> optionally
        announce the Originator SRGB TLV along with the mandatory Label-Index TLV.
        The content of the Originator SRGB TLV is determined by
        configuration.</t>
        <t>Since the label index label-index value must be unique within an SR domain, by
        default an implementation SHOULD NOT <bcp14>SHOULD NOT</bcp14> advertise the BGP Prefix-SID
        attribute outside an Autonomous System AS unless it is explicitly
        configured to do so.</t>
        <t>In all cases, the label Label field of the advertised NLRI (<xref
        target="RFC8277"/>, target="RFC8277" format="default"/> <xref target="RFC4364"/>) MUST target="RFC4364" format="default"/>) <bcp14>MUST</bcp14> be set to the
        local/incoming label programmed in the MPLS dataplane data plane for the given
        advertised prefix. If the prefix is associated with one of the BGP
        speaker's interfaces, this is the usual MPLS label (such as the
        Implicit or Explicit NULL label
        <xref target="RFC3032"/>).</t> target="RFC3032" format="default"/>).</t>
      </section>
    </section>
    <section anchor="ERRORHANDLING"
             title="Error numbered="true" toc="default">
      <name>Error Handling of BGP Prefix-SID Attribute"> Attribute</name>

      <t>When a BGP Speaker speaker receives a BGP Update UPDATE message containing a
      malformed or invalid BGP Prefix-SID attribute attached to a an
      IPv4/IPv6 Labeled Unicast prefix <xref target="RFC8277"/>, (<xref target="RFC8277" format="default"/>), it MUST <bcp14>MUST</bcp14>
      ignore the received BGP Prefix-SID attributes attribute and not advertise it to
      other BGP peers. In this context, a malformed BGP Prefix-SID attribute
      is one that cannot be parsed due to not meeting the minimum attribute
      length requirement, contains containing a TLV length that doesn't conform to the
      length constraints for the TLV, or containing a contains TLV length that would
      extend beyond the end of the attribute (as defined by the attribute
      length).
      This is equivalent to the "Attribute discard"
      action specified in <xref target="RFC7606"/>. target="RFC7606" format="default"/>. When discarding an
      attribute, a BGP speaker SHOULD <bcp14>SHOULD</bcp14> log an error for further analysis.</t>
      <t>As per with <xref target="RFC7606"/>, target="RFC7606" format="default"/>, if the BGP
         Prefix-SID attribute appears more than once in an UPDATE
         message, then all the occurrences of the attribute other than the
         first one SHALL <bcp14>SHALL</bcp14> be discarded and the UPDATE message will continue
         to be processed.
         Similarly, if a recognized TLV appears more than once in an a BGP
         Prefix-SID attribute while the specification only allows for a single
         occurrence, then all the occurrences of the TLV other than the
         first one SHALL <bcp14>SHALL</bcp14> be discarded and the Prefix-SID attribute will continue
         to be processed.</t>
      <t>For future extensibility, unknown TLVs MUST <bcp14>MUST</bcp14> be ignored and
         propagated unmodified.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document defines a BGP path attribute known as the BGP
      Prefix-SID attribute. This document requests  IANA to assign an has assigned
      attribute code type (suggested value: 40) 40 to the BGP Prefix-SID
      attribute from the BGP "BGP Path Attributes Attributes" registry.</t>

      <t>IANA temporarily assigned the following: <list>
          <t>40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires
          2018-09-30) [draft-ietf-idr-bgp-prefix-sid]</t>
        </list></t>
      <t>This document defines two TLVs for the BGP Prefix-SID attribute. These
      TLVs need to be have been registered with IANA. We request IANA to create has created a
      registry for BGP Prefix-SID Attribute TLVs as follows:</t>
      <t>Under the "Border Gateway Protocol (BGP) Parameters" registry, the new registry titled "BGP
      Prefix-SID TLV Types" Reference: draft-ietf-idr-bgp-prefix-sid
      Registration Procedure(s): Values 1-254 - has been created and points to this
      document as the reference.</t>
<t>Registration Procedure(s):</t>
      <ul empty="true" spacing="compact">
      <li>Values 1-254, Expert Review as defined in
      <xref target="RFC8126"/>, Value target="RFC8126" format="default"/></li> <li>Values
      0 and 255 reserved</t>

      <figure align="center">
        <artwork align="left">Value Type            Reference
0     Reserved        this document
1     Label-Index     this document
2     Deprecated      this document
3     Originator SRGB this document
4-254 Unassigned
255   Reserved        this document</artwork>
      </figure> 255, Reserved</li></ul>

<table anchor="IANA1" align="left">
  <name>BGP Prefix-SID TLV Types</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Type</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Reserved</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Label-Index</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Deprecated</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Originator SRGB</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>4-254</td>
      <td>Unassigned</td>
      <td></td>
    </tr>
    <tr>
      <td>255</td>
      <td>Reserved</td>
      <td>This document</td>
    </tr>
  </tbody>
</table>

      <t>The value 2 previously corresponded to the IPv6 SID TLV TLV, which was specified
         in previous versions of this document. It was removed removed, and usage use of
         the BGP Prefix-SID for Segment Routing over the IPv6 dataplane data plane
         <xref target="I-D.ietf-spring-segment-routing"/> target="RFC8402" format="default"/> has been deferred to
         future specifications.</t>

      <t>This document
      <t>IANA has also requests creation of created the "BGP Prefix-SID Label-Index TLV Flags"
         registry under the  "Border Gateway Protocol (BGP) Parameters" registry,
         Reference: draft-ietf-idr-bgp-prefix-sid.
         with a reference to this document. Initially, this 16-bit flags registry will be is
         empty. The registration policy for flag bits will is Expert Review <xref target="RFC8126"/> target="RFC8126" format="default"/>,
         consistent with the BGP "BGP Prefix-SID TLV Types Types" registry.</t>
      <t>Finally, this document requests creation of IANA has created the "BGP Prefix-SID Originator SRGB TLV Flags"
         registry under the  "Border Gateway Protocol (BGP) Parameters" registry,
         Reference: draft-ietf-idr-bgp-prefix-sid.
         with a reference to this document. Initially, this 16-bit flags registry will be is
         empty. The registration policy for flag bits will is Expert Review <xref target="RFC8126"/> target="RFC8126" format="default"/>
         consistent with the BGP Prefix-SID TLV Types registry.</t>
      <t>The designated experts must be good and faithful stewards of the above registries,
        assuring
        ensuring that each request is legitimate and corresponds to a viable use case. Given
        the limited number of bits in the flags registries and the applicability to a single TLV,
        additional scrutiny should be afforded to flag bit allocation requests. requests for flag-bit allocation. In general, no
        single use case should require more than one flag bit and, should the use case
        require more, alternate encodings using new TLVs should be considered.</t>
    </section>
    <section anchor="MANAGE" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>This document defines a BGP attribute to address use
      cases such as the one described in
      <xref target="I-D.ietf-spring-segment-routing-msdc"/>. target="RFC8670" format="default"/>.
      It is assumed that advertisement of the BGP Prefix-SID attribute is
      controlled by the operator in order to:<list style="symbols">
          <t>Prevent to:</t>
      <ul spacing="normal">
        <li>Prevent undesired origination/advertisement of the BGP Prefix-SID
          attribute. By default, a BGP Prefix-SID attribute SHOULD NOT <bcp14>SHOULD NOT</bcp14> be
          attached to a prefix and advertised. Hence, BGP Prefix-SID
          advertisement SHOULD
          Advertisement <bcp14>SHOULD</bcp14> require explicit enablement.</t>

          <t>Prevent enablement.</li>
        <li>Prevent any undesired propagation of the BGP Prefix-SID
          attribute. By default, the BGP Prefix-SID is not advertised outside
          the boundary of a single SR/administrative domain which that may include
          one or more ASes. The propagation to other ASes MUST <bcp14>MUST</bcp14> be
          explicitly configured.</t>
        </list></t> configured.</li>
      </ul>
      <t>The deployment model described in <xref
      target="I-D.ietf-spring-segment-routing-msdc"/> target="RFC8670" format="default"/> assumes multiple
      Autonomous Systems (ASes)
      ASes under a common administrative domain. For this
      use case, the BGP  Prefix-SID advertisement Advertisement is applicable to the inter-AS
      context, i.e., EBGP,  while it is confined to a single
      administrative domain.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document introduces a BGP attribute (BGP Prefix-SID) Prefix-SID), which
      inherits the security considerations expressed in: <xref
      target="RFC4271"/>, target="RFC4271" format="default"/>, <xref target="RFC8277"/>, target="RFC8277" format="default"/>, and
      <xref target="I-D.ietf-spring-segment-routing"/>.</t> target="RFC8402" format="default"/>.</t>
      <t>When advertised using BGPsec as described in <xref target="RFC8205"/>, target="RFC8205" format="default"/>,
     the BGP Prefix-SID attribute doesn't impose any unique
     security considerations. It should be noted that the BGP Prefix-SID
     attribute is not protected by the BGPsec signatures.</t>
      <t>It should be noted that,
      as described in <xref target="MANAGE"/>, target="MANAGE" format="default"/>, this document refers
      to a deployment model where all nodes are under the single administrative domain.
      In this context, we assume that the operator doesn't want to leak
      any information related to internal prefixes and topology outside of the
      administrative domain.
      The internal information includes the BGP Prefix-SID. In order
      to prevent such leaking, the common BGP mechanisms (filters) are
      applied at the boundary of the SR/administrative domain.
      Local BGP attribute filtering BGP-attribute-filtering policies
      and mechanisms are not standardized and, consequently, are beyond the
      scope of this document.</t>
      <t>To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service
      (DDoS) attack due to excessive BGP updates with an invalid or conflicting
      BGP Prefix-SID attribute, error log message rate-limiting rate limiting as well as suppression of
      duplicate error log messages SHOULD <bcp14>SHOULD</bcp14> be deployed.</t>
      <t>Since BGP-LS is the preferred method for advertising SRGB information,
         the BGP speaker SHOULD <bcp14>SHOULD</bcp14> log an error if a BGP Prefix-SID attribute
         is received with SRGB information different from that received as an attribute of
         the same node's BGP-LS Node NLRI.</t>
    </section>

    <section anchor="Contributors" title="Contributors">
      <figure>
        <artwork>Keyur Patel
Arrcus, Inc.
US

Email: Keyur@arrcus.com</artwork>
      </figure>

      <figure>
        <artwork>Saikat Ray
Unaffiliated
US

Email: raysaikat@gmail.com</artwork>
      </figure>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-idr-bgpls-segment-routing-epe"
		      to="BGPLS-SR-EPE"/>
    <displayreference target="I-D.ietf-idr-bgp-ls-segment-routing-ext"
		      to="BGPLS-SR-EXT"/>

<displayreference target="I-D.ietf-6man-segment-routing-header"
		  to="IPv6-SRH" />
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7911.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8205.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <!-- draft-ietf-spring-segment-routing-mpls-22: Companion Document -->

     <reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660">
<front>
<title>Segment Routing with the MPLS Data Plane</title>
<author initials='A' surname='Bashandy' fullname='Ahmed Bashandy'
	role="editor">
  <organization/>
</author>
<author initials='C' surname='Filsfils' fullname='Clarence' role="editor">
  <organization/>
</author>
<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
  <organization/>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
  <organization/>
  </author>
<author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
  <organization/>
</author>
<author initials='R' surname='Shakir' fullname='Rob Shakir'>
  <organization/>
</author>
<date month='December' year='2019'/>
</front>
<seriesInfo name="RFC" value="8660"/>
<seriesInfo name="DOI" value="10.17487/RFC8660"/>
</reference>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>

        <!-- I-D.ietf-spring-segment-routing-msdc: Companion Document -->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-segment-routing-header.xml"/>

<reference anchor='RFC8670' target='https://www.rfc-editor.org/info/rfc8670'>
<front>
<title>BGP Prefix Segment in Large-Scale Data Centers</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'>
    <organization />
</author>
<author initials='E' surname='Aries' fullname='Ebben Aries'>
    <organization />
</author>
<author initials='P' surname='Lapukhov' fullname='Petr Lapukhov'>
    <organization />
</author>
<date month='December' year='2019' />
</front>
<seriesInfo name='RFC' value='8670' />
<seriesInfo name='DOI' value='10.17487/RFC8670'/>
</reference>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgpls-segment-routing-epe.xml"/>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-ext.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5004.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>
      </references>
    </references>
    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Satya Mohanty for his contribution
      to this document.</t>
      <t>The authors would like to thank Alvaro Retana for substantive
         comments as part of the Routing AD review.</t>
      <t>The authors would like to thank Bruno Decraene for substantive
         comments and suggested text as part of the Routing Directorate
         review.</t>
      <t>The authors would like to thank Shyam Sethuram for comments and
         discussion of TLV processing and validation.</t>
      <t>The authors would like to thank Robert Raszuk for comments and
         suggestions regarding the MPLS data plane data-plane behavior.</t>
      <t>The authors would like to thank Krishna Deevi,
         Juan Alcaide, Howard Yang, and Jakob Heitz for discussions
         on conflicting BGP Prefix-SID label indices and BGP add paths.</t>
      <t>The authors would like to thank Peter Yee, Tony Przygienda,
         Mirja Kühlewind, Kuhlewind, Alexey Melnikov, Eric Rescorla, Suresh
         Krishnan, Warren Kumari, Ben Campbell Sue Hares, and Martin
         Vigoureux for IDR Working Group last call, IETF Last Call,
         directorate, and IESG reviews.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

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

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

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

    <references title="Informative References">
      <?rfc include="reference.RFC.3032"?>

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

      <?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe.xml"?>

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

      <?rfc include="reference.I-D.ietf-6man-segment-routing-header.xml"?>

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

      <?rfc include="reference.RFC.7752"?>
    </references>
    <section anchor="Contributors" numbered="false" toc="default">
      <name>Contributors</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[Keyur Patel
Arrcus, Inc.
United States of America

Email: Keyur@arrcus.com]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[Saikat Ray
Unaffiliated
United States of America

Email: raysaikat@gmail.com]]></artwork>
    </section>
  </back>
</rfc>