<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wu-idr-bgp-segment-allocation-ext-08"
     ipr="trust200902">
  <front>
    <title abbrev="BGP for IDs Allocation">BGP Extensions for
    IDs Allocation</title>

    <author initials="H" surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street></street>
          <city>Boston, MA</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>Huaimo.chen@futurewei.com</email>
      </address>
    </author>

    <author fullname="Zhenbin Li" initials="Z. " surname="Li">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>lizhenbin@huawei.com</email>
      </address>
    </author>

  <author fullname="Zhenqiang Li" initials="Z" surname="Li">
    	<organization>China Mobile</organization>
    	<address>
        <postal>
          <street>No. 29 Finance Street, Xicheng District</street>
          <city>Beijing</city>
          <code>100029</code>
          <country>P.R. China</country>
        </postal>
        <email>li_zhenqiang@hotmail.com</email>
      </address>
    </author>

   <author initials="Y" fullname="Yanhe Fan" 
            surname="Fan">
      <organization>Casa Systems</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>yfan@casa-systems.com</email>
      </address>
    </author>

   <author initials="M" fullname="Mehmet Toy" 
            surname="Toy">
      <organization> Verizon </organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <country>USA</country>
        </postal>
        <email>mehmet.toy@verizon.com</email>
      </address>
     </author>

   <author initials="L" fullname="Lei Liu" 
            surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

    <date year="2021" />
    <area>Routing</area>
    <workgroup>IDR Working Group</workgroup> 


    <abstract>
<t>
This document describes extensions to the BGP for IDs allocation. 
The IDs are SIDs for segment routing (SR), including SR for IPv6 (SRv6).
They are distributed to their domains if needed.
</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in 
<xref target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>

    <section title="Introduction">

<t>
In a network with a central controller, 
the controller has the link state information of the network,
including the resource such as traffic enginerring and SIDs information.
It is valuable for the controller to allocate and manage 
the resources including SIDs of the network in a centralized way,
especially for the SIDs representing network resources
<xref target="I-D.ietf-teas-enhanced-vpn"></xref>. 
</t>

<t>
When BGP as a controller allocates an ID, it is natural and beneficial 
to extend BGP to send it to its corresponding network elements. 
</t>

<t>
PCE may be extended to send IDs to their corresponding network 
elements after the IDs are allocated by a controller. 
However, when BGP is already deployed in 
a network, using PCE for IDs will need to deploy an extra protocol 
PCE in the network.
This will increase the CapEx and OpEx. 
</t>

<t>
Yang may be extended to send IDs to their corresponding network 
elements after the IDs are allocated by a controller. 
However, Yang progress may be slow. Some people may not like this.
</t>

<t>
There may not be these issues when BGP is used to send IDs.
In addition, BGP may be used to distribute IDs into their domains
easily when needed. It is also fit for the dynamic and static allocation
of IDs.
</t>

<t>
This document proposes extensions to the BGP for sending Segment
Identifiers (SIDs) for segment routing (SR) including SRv6 
to their corresponding network elements after SIDs are allocated
by the controller.  
If needed, they will be distributed into their network domains.
</t>
    </section> <!-- Introduction -->

    <section title="Terminology">
    <t>The following terminology is used in this document.

    <list style="hanging">
       <t hangText="SR:">Segment Routing.</t>
       <t hangText="SRv6:">SR for IPv6</t>
       <t hangText="SID:">Segment Identifier.</t>
       <t hangText="IID:">Indirection Identifier.</t>
       <t hangText="SR-Path:">Segment Routing Path.</t>
       <t hangText="SR-Tunnel:">Segment Routing Tunnel.</t>
       <t hangText="RR:">Route Reflector.</t>
       <t hangText="MPP:">MPLS Path Programming.</t>
       <t hangText="NAI:">Node or Adjacency Identifier.</t>
       <t hangText="TED:">Traffic Engineering Database.</t>
     </list>
   </t>
    </section> <!-- Terminology -->


    <section title="Protocol Extensions">
      <t>A new AFI and SAFI are defined: 
        the Identifier AFI  and the SID SAFI 
        whose codepoints are to be assigned by IANA.
      A few new NLRI TLVs are defined for the new AFI/SAFI, 
      which are Node, Link and Prefix SID NLRI TLVs.
      When a SID for a node, link or prefix is allocated by the 
      controller, it may be sent to a network element in a UPDATE
      message containing a MP_REACH NLRI with the new AFI/SAFI and 
      the SID NLRI TLV. 
      When the SID is withdrawn by the controller, 
      a UPDATE message containing a MP_UNREACH NLRI with the new AFI/SAFI and 
      the SID NLRI TLV may be sent to the network element.</t>

      <section title="Node SID NLRI TLV">
<t>
The Node SID NLRI TLV  
is used to represent the IDs such as SID associated with a node.  
Its format is illustrated in the Figure below, 
which is similar to the corresponding one defined 
in <xref target="RFC7752"></xref>. 

        <figure>
            <artwork align="center"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type (TBDa for Node SID)   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Identifier                          |
|                           (8 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Peer IP (4/16 bytes for IPv4/IPv6 Address)                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~                    Local Node Descriptors TLV                 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~                            Sub-TLVs                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
          </figure>
</t>

<t>
Where:
<list style="hanging">
<t hangText="  Type (TBDa):"> It is to be assigned by IANA.</t>
<t hangText="  Length:"> It is the length of the value field in bytes.</t>
<t hangText="  Peer IP:"> 4/16 octet value indicates an IPv4/IPv6 peer.
   When receiving a UPDATE message, a BGP speaker processes it only
   if the peer IP is the IP address of the BGP speaker or 0.</t>
<t hangText="  Protocol-ID, Identifier, and Local Node Descriptor:">defined 
  in <xref target="RFC7752"></xref>,
  can be reused.</t>
</list>
</t>


<t>
Sub-TLVs may be some of the followings:
<list style="hanging">
<t hangText="  SR-Capabilities TLV (1034):">It contains the 
Segment Routing Global Base (SRGB) range(s) allocated for the node.</t>

<t hangText="  SR Local Block TLV (1036):">  
The SR Local Block (SRLB) TLV contains the range(s) of SIDs/labels 
allocated to the node for local SIDs.</t>

<t hangText="  SRv6 SID Node TLV (TBD1):">  
A new TLV, called SRv6 Node SID TLV, contains an SRv6 SID 
and related information.</t>

<t hangText="  SRv6 Locator TLV (TBD2):">  
A new TLV, called SRv6 Locator TLV, contains an SRv6 locator 
and related information.</t>
</list>
</t>

<t>The format of SRv6 SID Node TLV is illustrated below.</t>
        <t><figure>
            <artwork align="center"><![CDATA[
 0                   1                   2                   3   
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1                                                
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Type (TBD1)          |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Reserved    |     Flags    |     SRv6 Endpoint Function    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SRv6 Identifier                        |
|                          (128 bits)                           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Optional sub-TLVs                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        SRv6 Node SID TLV
]]></artwork>
          </figure>
</t>

<t>
     <list style="hanging">
       <t hangText="Type:"> TBD1 for SRv6 Node SID TLV 
          is to be assigned by IANA.</t>
       <t hangText="Length:"> Variable.</t>
       <t hangText="Flags:"> 1 octet. No flags are defined now.</t>
       <t hangText="SRv6 Endpoint Function:"> 2 octets. 
          The function associated with SRv6 SID.</t>
       <t hangText="SRv6 Identifier:"> 16 octets. 
          IPv6 address representing SRv6 SID.</t>
       <t hangText="Reserved:">MUST be set to 0 while sending 
          and ignored on receipt.</t>
      </list>
SRv6 node SID inherits the topology and algorithm from its
locator. 
</t>

<t>The format of SRv6 locator TLV is illustrated below.</t>
        <t><figure>
            <artwork align="center"><![CDATA[
 0                   1                   2                   3   
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1                                                
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Type (TBD2)          |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|          MT-ID        |   Algorithm   |     Flags     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Metric                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Locator-Size | Locator (variable)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Optional sub-TLVs                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        SRv6 Locator TLV]]></artwork>
          </figure>
</t>

<t>
     <list style="hanging">
       <t hangText="Type:"> TBD2 for SRv6 Locator TLV 
          is to be assigned by IANA.</t>
       <t hangText="Length:"> Variable.</t>
       <t hangText="MT-ID:"> Multitopology Identifier as defined in
          <xref target="RFC5120"></xref>.</t>
       <t hangText="Algorithm:"> 1 octet. Associated algorithm.</t>
       <t hangText="Flags:"> 1 octet. 
          As described in 
          <xref target="I-D.ietf-lsr-isis-srv6-extensions"></xref>.</t>
       <t hangText="Metric:"> 4 octets. 
          As described in <xref target="RFC5305"></xref>.</t>
       <t hangText="Locator-Size:"> 1 octet. 
          Number of bits in the Locator field (1 to 128).</t>
       <t hangText="Locator:"> 1 to 16 octets. 
          SRv6 Locator encoded in the minimum number of octets for 
          the given Locator-Size.</t>
       <t hangText="Reserved:">MUST be set to 0 while sending 
          and ignored on receipt.</t>
      </list>
</t>


      </section> <!-- Node SID NLRI TLV -->


      <section title="Link SID NLRI TLV">
<t>
The Link SID NLRI TLV  
is used to represent the IDs such as SID associated with a link.  
Its format is illustrated in the Figure below, 
which is similar to the corresponding one defined 
in <xref target="RFC7752"></xref>.

        <figure>
            <artwork align="center"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type (TBDb for Link SID)   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Identifier (8 octets)                      ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Peer IP (4/16 bytes for IPv4/IPv6 Address)                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~                    Local Node Descriptors TLV                 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Remote Node Descriptors TLV                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        Link Descriptors TLV                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            Sub-TLVs                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

<t>
Where:
<list style="hanging">
<t hangText="  Type (TBDb):"> It is to be assigned by IANA.</t>
<t hangText="  Length:"> It is the length of the value field in bytes.</t>
<t hangText="  Peer IP:"> 4/16 octet value indicates an IPv4/IPv6 peer.</t>
<t hangText="  Protocol-ID, Identifier, Local Node Descriptors, 
  Remote Node Descriptors and Link Descriptors:"> defined 
  in <xref target="RFC7752"></xref>,
  can be reused.</t>
</list>
</t>


<t>
The Sub-TLVs may be some of the followings:
<list style="hanging">
<t hangText="  Adj-SID TLV (1099):">It contains the 
Segment Identifier (SID) allocated for the link/adjacency.</t>

<t hangText="  LAN Adj-SID TLV (1100):"> It contains the 
Segment Identifier (SID) allocated for the adjacency/link 
to a non-DR router on a broadcast, NBMA, or hybrid link.</t>

<t hangText="  SRv6 Adj-SID TLV (TBD3):">  
A new TLV, called SRv6 Adj-SID TLV, contains an SRv6 Adj-SID and 
related information.</t>

<t hangText="  SRv6 LAN Adj-SID TLV (TBD4):">  
A new TLV, called SRv6 LAN Adj-SID TLV, contains an SRv6 LAN Adj-SID and 
related information.</t>
</list>
</t>

<t>The format of an SRv6 Adj-SID TLV is illustrated below.
        <figure>
            <artwork align="center"><![CDATA[
 0                   1                   2                   3   
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1                                                
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Type (TBD3)          |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Weight    |   Algorithm   |B|S|P|             Flags       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Reserved            |     SRv6 Endpoint Function    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SRv6 Identifier                        |
|                          (128 bits)                           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Optional sub-TLVs                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         SRv6 Adj-SID TLV
]]></artwork>
          </figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:"> TBD3 for SRv6 Adj-SID TLV 
          is to be assigned by IANA.</t>
       <t hangText="Length:"> Variable.</t>
       <t hangText="Weight:"> 1 octet. The value represents the 
          weight of the SID for the purpose of load balancing.</t>
       <t hangText="Algorithm:"> 1 octet. Associated algorithm.</t>
       <t hangText="Flags:"> 2 octets. Three flags are defined in
          <xref target="I-D.ietf-lsr-isis-srv6-extensions"></xref>.</t>
       <t hangText="SRv6 Endpoint Function:"> 2 octets. 
          The function associated with SRv6 SID.</t>
       <t hangText="SRv6 Identifier:"> 16 octets. 
          IPv6 address representing SRv6 SID.</t>
       <t hangText="Reserved:">MUST be set to 0 while sending 
          and ignored on receipt.</t>
      </list>
</t>

<t>The format of an SRv6 LAN Adj-SID TLV is illustrated below.
        <figure>
            <artwork align="center"><![CDATA[
 0                   1                   2                   3   
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1                                                
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Type (TBD4)          |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Weight    |   Algorithm   |B|S|P|             Flags     |O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Reserved            |     SRv6 Endpoint Function    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    neighbor Router ID (4 octets) / System ID (6 octets)       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SRv6 Identifier                        |
|                          (128 bits)                           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Optional sub-TLVs                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       SRv6 LAN Adj-SID TLV
]]></artwork>
          </figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:"> TBD4 for SRv6 LAN Adj-SID TLV 
          is to be assigned by IANA.</t>
       <t hangText="Length:"> Variable.</t>
       <t hangText="Weight:"> 1 octet. The value represents the 
          weight of the SID for the purpose of load balancing.</t>
       <t hangText="Algorithm:"> 1 octet. Associated algorithm.</t>
       <t hangText="Flags:"> 2 octets. Three flags B, S and P are defined in
          <xref target="I-D.ietf-lsr-isis-srv6-extensions"></xref>. 
          Flag O set to 1 indicating OSPF neighbor Router ID of 4 
          octets, set to 0 indicating IS-IS neighbor System ID of 6 
          octets.</t>
       <t hangText="SRv6 Endpoint Function:"> 2 octets. 
          The function associated with SRv6 SID.</t>
       <t hangText="SRv6 Identifier:"> 16 octets. 
          IPv6 address representing SRv6 SID.</t>
       <t hangText="Reserved:">MUST be set to 0 while sending 
          and ignored on receipt.</t>
      </list>
</t>

      </section>  <!-- Link SID NLRI TLV -->

      <section title="Prefix SID NLRI TLV">
<t>
The Prefix SID NLRI TLV  
is used to represent the IDs such as SID associated with a prefix.  
Its format is illustrated in the Figure below, 
which is similar to the corresponding one defined 
in <xref target="RFC7752"></xref>. 
        <figure>
            <artwork align="center"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type (TBDc for Prefix SID)  |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                       Identifier (8 octets)                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Peer IP (4/16 bytes for IPv4/IPv6 Address)                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~                    Local Node Descriptors TLV                 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~                        Prefix Descriptors TLV                 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~                            Sub-TLVs                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>
<t>
Where:
<list style="hanging">
<t hangText="  Type (TBDc):"> It is to be assigned by IANA.</t>
<t hangText="  Length:"> It is the length of the value field in bytes.</t>
<t hangText="  Peer IP:"> 4/16 octet value indicates an IPv4/IPv6 peer.</t>
<t hangText="  Protocol-ID, Identifier, Local Node Descriptors and 
  Prefix Descriptors:">defined 
  in <xref target="RFC7752"></xref>,
  can be reused.</t>
</list>
</t>


<t>Sub-TLVs may be some of the followings:
<list style="hanging">
<t hangText="  Prefix-SID TLV (1158):">It contains the 
Segment Identifier (SID) allocated for the prefix.</t>

<t hangText="  Prefix Range TLV (1159):"> It contains a range of prefixes and 
the Segment Identifier (SID)s allocated for the prefixes.</t>
</list>
</t>
      </section>  <!-- Prefix SID NLRI TLV -->

     <section title="Capability Negotiation">
        <t>It is necessary to negotiate the capability to support BGP 
        Extensions for sending and receiving Segment Identifiers (SIDs). 
        The BGP SID
        Capability is a new BGP capability <xref target="RFC5492"/>. The
        Capability Code for this capability is to be specified by the IANA.
        The Capability Length field of this capability is variable. The
        Capability Value field consists of one or more of the following
        tuples:</t>

        <t><figure>
            <artwork align="center"><![CDATA[
+--------------------------------------------------+
|  Address Family Identifier (2 octets)            |
+--------------------------------------------------+
|  Subsequent Address Family Identifier (1 octet)  |
+--------------------------------------------------+
|  Send/Receive (1 octet)                          |
+--------------------------------------------------+

               BGP SID Capability]]></artwork>
          </figure></t>

        <t>The meaning and use of the fields are as follows:</t>

        <t>Address Family Identifier (AFI): This field is the same as the one
        used in <xref target="RFC4760"/>.</t>

        <t>Subsequent Address Family Identifier (SAFI): This field is the same
        as the one used in <xref target="RFC4760"/>.</t>

        <t>Send/Receive: This field indicates whether the sender is (a)
        willing to receive SID from its peer
        (value 1), (b) would like to send SID to
        its peer (value 2), or (c) both (value 3) for the &lt;AFI,
        SAFI&gt;.</t>
      </section> <!-- Capability Negotiation -->
    </section> <!-- Protocol Extensions -->


    <section anchor="IANA" title="IANA Considerations">
     <t>This document requests assigning a new AFI in the registry 
         "Address Family Numbers" as 
         follows:
        <figure>
            <artwork align="center"><![CDATA[
   +-------------+---------------------+-------------+
   | Code Point  | Description         | Reference   |
   +-------------+---------------------+-------------+
   |    TBDx     |  Identifier AFI     |This document|
   +-------------+---------------------+-------------+]]></artwork>
          </figure>
</t>
      <t>This document requests assigning a new SAFI in the registry 
         "Subsequent Address Family Identifiers (SAFI) Parameters" as 
         follows:
        <figure>
            <artwork align="center"><![CDATA[
   +-------------+----------------------+-------------+
   | Code Point  | Description          | Reference   |
   +-------------+----------------------+-------------+
   |    TBDy     |  SID SAFI            |This document|
   +-------------+----------------------+-------------+]]></artwork>
          </figure>
</t>

      <t>This document defines a new registry called "SID NLRI TLVs".
         The allocation policy of this registry is "First Come First
         Served (FCFS)" according to <xref target="RFC8126"></xref>.
      </t>
      <t>Following TLV code points are defined:

        <figure>
            <artwork align="center"><![CDATA[
   +-------------+-----------------------------------+-------------+
   | Code Point  | Description                       | Reference   |
   +-------------+-----------------------------------+-------------+
   |  1 (TBDa)   | Node SID NLRI                     |This document|
   +-------------+-----------------------------------+-------------+
   |  2 (TBDb)   | Link SID NLRI                     |This document|
   +-------------+-----------------------------------+-------------+
   |  3 (TBDc)   | Prefix SID NLRI                   |This document|
   +-------------+-----------------------------------+-------------+
]]></artwork>
          </figure>
      </t>

      <t>This document requests assigning a code-point from the registry 
      "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"
      as follows:
        <figure>
            <artwork align="center"><![CDATA[
   +----------------+-----------------------------------+-------------+
   | TLV Code Point | Description                       | Reference   |
   +----------------+-----------------------------------+-------------+
   |     TBD1       | SRv6 Node SID                     |This document|
   +----------------+-----------------------------------+-------------+
   |     TBD2       | SRv6 Allocator                    |This document|
   +----------------+-----------------------------------+-------------+
   |     TBD3       | SRv6 Adj-SID                      |This document|
   +----------------+-----------------------------------+-------------+
   |     TBD4       | SRv6 LAN Adj-SID                  |This document|
   +----------------+-----------------------------------+-------------+
]]></artwork>
          </figure>
      </t>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Protocol extensions defined in this document do not 
      affect the BGP security other than those as discussed 
      in the Security Considerations section of 
      <xref target="RFC7752"></xref>.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank 
  Eric Wu, 
  Robert Raszuk, Zhengquiang Li, 
  and Ketan Talaulikar
  for their valuable suggestions and comments on this draft.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.4760.xml"?>
      <?rfc include="reference.RFC.5120.xml"?>
      <?rfc include="reference.RFC.5305.xml"?>
      <?rfc include="reference.RFC.5492.xml"?>
      <?rfc include="reference.RFC.5575.xml"?>
      <?rfc include="reference.RFC.7752.xml"?>
      <?rfc include="reference.RFC.8126.xml"?>
      <?rfc include='reference.I-D.ietf-isis-segment-routing-extensions'?>

      <?rfc include='reference.I-D.ietf-spring-segment-routing'?>

      <?rfc include='reference.I-D.ietf-rtgwg-bgp-routing-large-dc'?>

      <?rfc include='reference.I-D.ietf-spring-segment-routing-ldp-interop'?>

      <?rfc include='reference.I-D.ietf-idr-flowspec-path-redirect'?>

      <?rfc include='reference.I-D.li-ospf-ospfv3-srv6-extensions'?>
      <?rfc include='reference.I-D.ietf-lsr-isis-srv6-extensions'?>


    </references>

    <references title="Informative References">
     <?rfc include='reference.I-D.ietf-teas-enhanced-vpn'?>
      <?rfc include='reference.I-D.gredler-idr-bgp-ls-segment-routing-extension'?>

      <?rfc include='reference.I-D.ietf-idr-bgpls-segment-routing-epe'?>
    </references>
  </back>
</rfc>
