<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-li-lsvr-bgp-spf-srv6-04" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="BGP-SPF SRv6">Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF</title>
    <seriesInfo name="Internet-Draft" value="draft-li-lsvr-bgp-spf-srv6-04"/>
    <author initials="L." surname="Zhang" fullname="Li Zhang">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>No. 156 Beiqing Road</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhangli344@huawei.com</email>
      </address>
    </author>
    <author initials="J." surname="Dong" fullname="Jie Dong">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>No. 156 Beiqing Road</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <author initials="K." surname="Patel" fullname="Keyur Patel">
      <organization>Arrcus, Inc.</organization>
      <address>
        <email>keyur@arrcus.com</email>
      </address>
    </author>
    <date year="2025" month="October" day="16"/>
    <area>Routing</area>
    <workgroup>LSVR</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 48?>

<t>For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and
the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and
BGP-LS protocol extensions. Segment Routing over IPv6 (SRv6) provides a source routing mechanism that allows a flow to
be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SRv6
domain. In some networks, it may be useful to enable SRv6 based source routing mechanism together with BGP-LS-SPF. This
document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI.</t>
    </abstract>
  </front>
  <middle>
    <?line 57?>

<section anchor="intro">
      <name>Introduction</name>
      <t><xref target="RFC9815"/> extends BGP for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based
calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol <xref target="RFC4271"/> and BGP-LS protocol extensions
<xref target="RFC9552"/>, with the extensions to BGP-LS attribute and new NLRI selection rules.</t>
      <t>Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by
encoding paths as sequences of topological or functional sub-paths called "segments". SRv6 provides a mechanism that
allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress
node(s) to the SRv6 domain.</t>
      <t>In network scenarios such as Data Center networks, WAN networks or other networks where BGP-LS-SPF can be used as the
underlay routing protocol, it may be useful to enable SRv6 based source routing mechanism for traffic engineering and
optimization. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI,
and discusses which SRv6 extensions can be applied to BGP-LS-SPF SAFI.</t>
      <section anchor="requirements-language">
        <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 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="srv6-node-attribute-tlvs">
      <name>SRv6 Node Attribute TLVs</name>
      <t>Based on <xref target="RFC9514"/>, the following SRv6 Node Attributes TLV <bcp14>SHOULD</bcp14> be supported in BGP-LS-SPF.</t>
      <table anchor="ref-to-tab1">
        <name>Node Attribute TLVs for SRv6 with BGP-LS-SPF</name>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1138</td>
            <td align="left">SRv6 Capabilities TLV</td>
            <td align="left">RFC 9514</td>
          </tr>
          <tr>
            <td align="left">266</td>
            <td align="left">Node MSD TLV</td>
            <td align="left">RFC 8814</td>
          </tr>
          <tr>
            <td align="left">1035</td>
            <td align="left">SR Algorithm TLV</td>
            <td align="left">RFC 9085</td>
          </tr>
        </tbody>
      </table>
      <t>These SRv6 Node Attributes TLVs are advertised associated with the BGP-LS-SPF Node NLRI.</t>
      <section anchor="srv6-capabilities-tlv">
        <name>SRv6 Capabilities TLV</name>
        <t>The SRv6 Capabilities TLV defined in <xref target="RFC9514"/> is used to announce the SRv6 capabilities of the node along with the
BGP-LS Node NLRI and indicates the SRv6 support by the node.</t>
        <t>For BGP-LS-SPF, it <bcp14>SHOULD</bcp14> support this TLV for a BGP-LS-SPF node to advertise its support for the SRv6-related capabilities.
This is an optional TLV of BGP-LS-SPF Node NLRI that
<bcp14>MUST</bcp14> be advertised by an SRv6-capable node.</t>
        <t>This TLV <bcp14>MUST</bcp14> be advertised only once in the attributes of BGP-LS-SPF Node NLRI. When multiple SRv6 Capabilities TLVs
are received from a given node, the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV in the attributes of BGP-LS-SPF Node NLRI.</t>
        <t>If no SRv6 Capabilities TLV is advertised in the BGP-LS-SPF Node NLRI, then it indicates that the originator of this
NLRI does not support SRv6.</t>
        <t>The format and flags of SRv6 Capabilities TLV of BGP-LS-SPF is consistent with that in BGP-LS. The format of BGP-LS-SPF
SRv6 Capability TLV is shown as follow:</t>
        <figure anchor="ref-to-fig1">
          <name>SRv6 Capability TLV format</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Flags             |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>where:</t>
        <t>Type: 1038</t>
        <t>Length: 4</t>
        <t>Flags: 2-octet field. the following flags are defined:</t>
        <artwork><![CDATA[
0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |O|       Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        <t>where:</t>
        <t>O-flag: If set, the node supports use of the O-bit in the SRH, as defined in <xref target="RFC9259"/>.</t>
        <t>Other flags are not defined and are reserved for future use. They <bcp14>MUST</bcp14> be set to 0 on transmission and <bcp14>MUST</bcp14> be ignored on receipt.</t>
        <t>Reserved: 2-octet field that <bcp14>MUST</bcp14> be set to 0 when originated and ignored on receipt.</t>
      </section>
      <section anchor="Node-MSD">
        <name>SRv6 Node MSD Types</name>
        <t>The Node MSD TLV defined in <xref target="RFC8814"/> is used to advertise the limits and the Segment Routing Header (SRH) operations supported by the SRv6-capable node in BGP-LS.</t>
        <t>For BGP-LS-SPF, different SRv6-capable node may have different limits related to SRH processing, therefore, BGP-LS-SPF <bcp14>SHOULD</bcp14> support this TLV for nodes to advertise the limits and operations.</t>
        <t>The SRv6 Node MSD TLV is an optional TLV of BGP-LS-SPF Node Attribute that <bcp14>MAY</bcp14> be advertised by an SRv6-capable node.</t>
        <t>This TLV <bcp14>MUST</bcp14> be advertised only once in the attributes of BGP-LS-SPF Node NLRI. When multiple SRv6 Node MSD TLVs are received from a given node, the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV in the attributes of BGP-LS-SPF Node NLRI.</t>
        <t>The MSD types for SRv6 that are defined in <xref section="4" sectionFormat="of" target="RFC9352"/> for IS-IS are also used by BGP-LS-SPF. These MSD types are allocated in the "IGP MSD-Types" registry maintained by IANA and are shared by IS-IS, OSPF, and BGP-LS-SPF. They are described in the subsections below.</t>
        <t>The format of this TLV is the same as that in BGP-LS:</t>
        <figure anchor="ref-to-fig2">
          <name>SRv6 Node MSD TLV format</name>
          <artwork><![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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    MSD-Type   |  MSD-Value    |  MSD-Type...  |  MSD-Value... |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <t>where:</t>
        <t>Type: 266.</t>
        <t>Length: variable, represents the total length of the value field in octets.</t>
        <t>Value: consists of one or more pairs of a 1-octet MSD-Type and 1-octet MSD-Value. The detail description of MSD-Type and MSD-Value is in <xref section="3" sectionFormat="of" target="RFC8814"/>.</t>
        <t>Node MSD is the smallest MSD supported by the node on the set of interfaces configured for use by the advertising BGP-LS-SPF instance.  MSD values may be learned via a hardware API or may be provisioned.</t>
        <t>If there are multiple MSD-Types that have the same code point in a Node MSD TLV, then the Node MSD TLV <bcp14>MUST</bcp14> be ignored by the receiver.</t>
        <section anchor="maximum-segments-left-msd-type">
          <name>Maximum Segments Left MSD Type</name>
          <t>The Maximum Segments Left MSD Type signals the maximum value of the Segments Left field in the SRH of a received packet before applying the Endpoint behavior associated with a SID.</t>
          <t>If no value is advertised, the supported value is assumed to be 0.</t>
        </section>
        <section anchor="maximum-end-pop-msd-type">
          <name>Maximum End Pop MSD Type</name>
          <t>The Maximum End Pop MSD Type signals the maximum number of SIDs in the SRH to which the node can apply "Penultimate Segment Pop (PSP) of the SRH" or "Ultimate Segment Pop (USP) of the SRH" behaviors, which defined in <xref section="4.16" sectionFormat="of" target="RFC8986"/>.</t>
          <t>If the advertised value is zero or no value is advertised, then the node cannot apply the PSP or USP flavors.</t>
        </section>
        <section anchor="maximum-hencaps-msd-type">
          <name>Maximum H.Encaps MSD Type</name>
          <t>The Maximum H.Encaps MSD Type signals the maximum number of SIDs that can be added as part of the H.Encaps behavior as defined in <xref target="RFC8986"/>.</t>
          <t>If the advertised value is zero or no value is advertised, then the headend can apply an SR Policy that only contains one segment without inserting any SRH.</t>
          <t>A non-zero SRH Max H.Encaps MSD indicates that the headend can insert an SRH with SIDs up to the advertised value.</t>
        </section>
        <section anchor="maximum-end-d-msd-type">
          <name>Maximum End D MSD Type</name>
          <t>The Maximum End D MSD Type specifies the maximum number of SIDs present in an SRH when performing decapsulation. These include, but are not limited to, End.DX6, End.DT4, End.DT46, End with USD, and End.X with USD as defined in <xref target="RFC8986"/>.</t>
          <t>If the advertised value is zero or no value is advertised, then the node cannot apply any behavior that results in decapsulation and forwarding of the inner packet when the outer IPv6 header contains an SRH.</t>
        </section>
      </section>
      <section anchor="sr-algorithm-tlv">
        <name>SR-Algorithm TLV</name>
        <t><xref target="RFC9514"/> specifies that the algorithm support for SRv6 is advertised via the SR-Algorithm TLV specified in <xref target="RFC9085"/>. The SR-Algorithm is used to advertise the SR algorithms supported by the node.</t>
        <t>This TLV is a basic TLV of SR and <bcp14>SHOULD</bcp14> be supported in BGP-LS-SPF. The SR-Algorithm TLV is an optional TLV of BGP-LS-SPF Node Attribute that <bcp14>MAY</bcp14> be advertised by an SRv6-capable node.</t>
        <t>This TLV <bcp14>MUST</bcp14> be advertised only once in the attributes of BGP-LS-SPF Node NLRI. If a node receiving multiple SR-Algorithm TLVs in the BGP-LS-SPF Node Attribute, the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV in the attributes of BGP-LS-SPF Node NLRI.</t>
        <t>If a SRv6-capable node does not advertise the SR-Algorithm TLV, it implies that algorithm 0 is the only algorithm supported by the node.</t>
        <t>If the originating node does advertise the SR-Algorithm sub-TLV, then algorithm 0 <bcp14>MUST</bcp14> be present while non-zero algorithms <bcp14>MAY</bcp14> be present.</t>
        <t>The format of Algorithm fields in this TLV is consistent with that in BGP-LS, as defined in <xref section="2.1.3" sectionFormat="of" target="RFC9085"/>.</t>
        <figure anchor="ref-to-fig3">
          <name>SRv6 Algorithm TLV format</name>
          <artwork><![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    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Algorithm 1   |  Algorithm 2  | Algorithm ... |  Algorithm n  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <t>where:</t>
        <t>Type: 1035</t>
        <t>Length: Variable</t>
        <t>Algorithm: 1 octet of algorithm.</t>
        <t>The algorithm values are allocated in the "IGP Algorithm Type" registry defined in <xref target="RFC8665"/>, these values are shared by IS-IS, OSPF, and BGP-LS-SPF.</t>
      </section>
    </section>
    <section anchor="srv6-sids-and-reachability">
      <name>SRv6 SIDs and Reachability</name>
      <t>An SRv6 SID is 128 bits and consists of locator, function, and argument parts as described in <xref target="RFC8986"/>.</t>
      <t>An BGP-LS-SPF router is provisioned with algorithm-specific locators for each algorithm supported by that router. Each locator is a covering prefix for all SIDs provisioned on that router that have the matching algorithm.</t>
      <t>Locators <bcp14>MUST</bcp14> be advertised as BGP-LS-SPF Prefix NLRI objects along with the SRv6 Locator TLVs (see <xref target="locator"/>) in its BGP-LS-SPF Attribute. Forwarding entries for the locators advertised in the BGP-LS-SPF Prefix NLRI <bcp14>MUST</bcp14> be installed in the forwarding plane of receiving SRv6-capable routers when the associated algorithm is supported by the receiving BGP-LS-SPF router. The processing of the prefix of the Locator, the calculation of its reachability, and the installation in the forwarding plane follows the process of BGP-LS-SPF <xref target="RFC9815"/>.</t>
      <t>SRv6 SIDs are advertised as SRv6 SID Information TLVs (see <xref target="SID-info"/>) in the SRv6 SID NLRI, except for SRv6 SIDs that are associated with a specific neighbor/link and are therefore advertised as SRv6 End.X SID TLV (see <xref target="end.x-sid"/>).</t>
      <t>SRv6 SIDs received from other nodes are not directly routable and <bcp14>MUST NOT</bcp14> be installed in the forwarding plane. Reachability to SRv6 SIDs depends upon the existence of a covering locator.</t>
      <t>Adherence to the rules defined in this section will ensure that SRv6 SIDs associated with a supported algorithm will be forwarded correctly, while SRv6 SIDs associated with an unsupported algorithm will be dropped. NOTE: The drop behavior depends on the absence of a default/summary route covering a given locator.</t>
    </section>
    <section anchor="srv6-link-attribute-tlvs">
      <name>SRv6 Link Attribute TLVs</name>
      <t>Based on <xref target="RFC9514"/> and <xref target="RFC9085"/>, the following Link Attributes <bcp14>SHOULD</bcp14> be supported in BGP-LS-SPF.</t>
      <table anchor="ref-to-tab2">
        <name>Link Attribute TLVs for SRv6 with BGP-LS-SPF</name>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1106</td>
            <td align="left">SRv6 End.X SID TLV</td>
            <td align="left">RFC 9514</td>
          </tr>
          <tr>
            <td align="left">1106</td>
            <td align="left">L2 Bundle Member Attributes TLV</td>
            <td align="left">RFC 9085</td>
          </tr>
          <tr>
            <td align="left">267</td>
            <td align="left">SRv6 Link MSD TLV</td>
            <td align="left">RFC 8814</td>
          </tr>
        </tbody>
      </table>
      <t>These SRv6 Link Attribute TLVs are advertised associated with the BGP-LS-SPF Link NLRI.</t>
      <section anchor="end.x-sid">
        <name>SRv6 End.X SID TLV</name>
        <t>The SRv6 End.X SID TLV defined in <xref target="RFC9514"/> is used to advertise the SRv6 SIDs associated with an IGP Adjacency SID behavior that correspond to a point-to-point or point-to-multipoint link or adjacency of the node running the IS-IS or OSPFv3 protocols. It is also used by BGP-LS to advertise the BGP EPE Peer Adjacency SID for SRv6 on the same lines as specified for SR-MPLS in <xref target="RFC9086"/>.</t>
        <t>BGP-LS-SPF <bcp14>SHOULD</bcp14> support this TLV to advertise the SRv6 SIDs correspond to a point-to-point or adjacency of the node running the BGP-LS-SPF.</t>
        <t>The SRv6 End.X SID TLV is an optional TLV of BGP-LS-SPF Link Attribute that <bcp14>MAY</bcp14> be advertised by an SRv6-capable node.</t>
        <t>More than one instance of this TLV (one for each SRv6 End.X SID) can be included in the BGP-LS-SPF Attribute. Multiple SRv6 End.X SID TLVs <bcp14>MAY</bcp14> be associated with the same adjacency.</t>
        <t>Every SRv6-enabled node <bcp14>SHOULD</bcp14> instantiate at least one unique SRv6 End.X SID corresponding to each of its neighbors, although it <bcp14>MAY</bcp14> omit doing so if features like TE or TI-LFA that require End.X SID are not in use.</t>
        <t>All End.X SIDs <bcp14>MUST</bcp14> be a subnet of a locator with matching algorithm that is advertised by the same BGP-LS-SPF node in an SRv6 Locator TLV. End.X SIDs that do not meet this requirement <bcp14>MUST</bcp14> be ignored. This ensures that the BGP-LS-SPF node advertising the End.X is also advertising its corresponding locator with the algorithm that will be used for computing paths destined to the SID.</t>
        <t>The format of this TLV is the same as in BGP-LS:</t>
        <figure anchor="ref-to-fig4">
          <name>SRv6 End.X SID TLV format</name>
          <artwork><![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               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Endpoint Behavior      |      Flags    |   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Weight    |   Reserved    |  SID (16 octets) ...          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)             | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>where:</t>
        <t>Type: 1106</t>
        <t>Length: variable</t>
        <t>Endpoint Behavior: 2-octet field. The Endpoint behavior code point for this SRv6 SID as defined in Section 10.2 of <xref target="RFC8986"/>.</t>
        <t>Flags: 1 octet. The definition of flags are same as that in IS-IS SRv6 End.X SID sub-TLV (<xref section="8.1" sectionFormat="of" target="RFC9352"/>) and the OSPFv3 SRv6 End.X SID sub-TLV (<xref section="9.1" sectionFormat="of" target="RFC9513"/>).</t>
        <t>Algorithm: 1-octet field. Algorithm associated with the SID. The algorithm associated with the SRv6 Locator from which the SID is allocated.</t>
        <t>Weight: 1-octet field. The value represents the weight of the SID for the purpose of load balancing. The use of the weight is defined in <xref target="RFC8402"/>.</t>
        <t>Reserved: 1-octet field that <bcp14>MUST</bcp14> be set to 0 when originated and ignored on receipt.</t>
        <t>SID: 16-octet field. This field encodes the advertised SRv6 SID as a 128-bit value.</t>
        <t>Sub-TLVs: Used to advertise sub-TLVs that provide additional attributes for the specific SRv6 SID.</t>
      </section>
      <section anchor="l2-bundle-member-attributes-tlv">
        <name>L2 Bundle Member Attributes TLV</name>
        <t>The L2 Bundle Member Attributes TLV is defined in <xref target="RFC9085"/>, it identifies an L2 Bundle Member link, which in turn is
associated with a parent L3 link. This TLV is useful when entities external to BGP-LS-SPF wish to control traffic flows
on the individual physical links that comprise the Layer 2 interface bundle.</t>
        <t>The network deployed BGP-LS-SPF may include trunk links. Therefore, BGP-LS-SPF <bcp14>MAY</bcp14> support this TLV to advertise L2 bundle
member link attributes.</t>
        <t>The L2 Bundle Member Attributes TLV is an optional TLV of BGP-LS-SPF Link Attribute with BGP-LS-SPF Link NLRI that <bcp14>MAY</bcp14>
be advertised by an SRv6-capable node.</t>
        <t>This TLV <bcp14>MAY</bcp14> include sub-TLVs that describe attributes associated with the bundle member. The identified bundle member
represents a unidirectional path from the originating node to the neighbor specified in the parent L3 link.</t>
        <t>Multiple L2 Bundle Member Attributes TLVs <bcp14>MAY</bcp14> be associated with a BGP-LS-SPF Link NLRI.</t>
        <t>Advertisement of this TLV implies that the identified link is a member of the L2 Bundle associated with the Parent L3
Link, and the member link is operationally up. Therefore, advertisements <bcp14>MUST</bcp14> be withdrawn if the link becomes operationally
down or it is no longer a member of the identified L2 Bundle.</t>
        <t>The format of this TLV is the same as that in BGP-LS:</t>
        <figure anchor="ref-to-fig5">
          <name>L2 Bundle Member Attributes TLV format</name>
          <artwork><![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               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     L2 Bundle Member Descriptor               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Link Attribute Sub-TLVs(variable)          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <t>Where:</t>
        <t>Type: 1172</t>
        <t>Length: Variable.</t>
        <t>L2 Bundle Member Descriptor: 4-octet field that carries a link-local identifier as defined in <xref target="RFC4202"/>.</t>
        <t>Link attribute Sub-TLVs: variable, the detail description of these Sub-TLVs is specified in <xref section="2.2.3" sectionFormat="of" target="RFC9085"/>.</t>
      </section>
      <section anchor="srv6-link-msd-types">
        <name>SRv6 Link MSD Types</name>
        <t>The Link MSD TLV defined in <xref target="RFC8814"/> is used to advertise the limits and the SRH operations supported on the specific link by the SRv6-capable node. BGP-LS-SPF <bcp14>SHOULD</bcp14> support this TLV to advertise the limits and operations supported on the specific link to enable segment routing. The SRv6 MSD types specified in <xref section="4" sectionFormat="of" target="RFC9352"/> are also used with the BGP-LS-SPF Link MSD TLV, as these code points are shared between the IS-IS, OSPF, and BGP-LS-SPF.</t>
        <t>The SRv6 Node MSD TLV is an optional TLV of BGP-LS-SPF Link Attributes that <bcp14>MAY</bcp14> be advertised by an SRv6-capable node.</t>
        <t>This TLV <bcp14>MUST</bcp14> be advertised only once in the attributes of BGP-LS-SPF Link NLRI. When multiple SRv6 Link MSD TLVs are received from a given node, the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV in the attributes of BGP-LS-SPF Link NLRI.</t>
        <t>The format and different MSD Types of SRv6 Link MSD TLV is the same as <xref target="Node-MSD"/>, the Type of Link MSD TLV is 267<xref target="RFC8814"/>.</t>
      </section>
    </section>
    <section anchor="srv6-prefix-attribute-tlvs">
      <name>SRv6 Prefix Attribute TLVs</name>
      <t>Based on <xref target="RFC9514"/>, the BGP-LS SRv6 Prefix Attributes only includes the SRv6 Locator TLV. This TLV <bcp14>SHOULD</bcp14> be supported by BGP-LS-SPF.</t>
      <table anchor="ref-to-tab3">
        <name>Prefix Attribute TLVs for SRv6 with BGP-LS-SPF</name>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1162</td>
            <td align="left">SRv6 Locator TLV</td>
            <td align="left">RFC 9514</td>
          </tr>
        </tbody>
      </table>
      <t>These SRv6 Prefix Attribute TLVs are advertised associated with the BGP-LS-SPF Prefix NLRI.</t>
      <section anchor="locator">
        <name>SRv6 Locator TLV</name>
        <t>The SRv6 Locator TLV defined in <xref target="RFC9514"/> is used to advertise the locators supported by each node.  Locator is the key component of SRv6 SID, BGP-LS-SPF <bcp14>SHOULD</bcp14> support this TLV to enable segment routing.</t>
        <t>A node is provisioned with one or more locators supported by that node. Locators are covering prefixes for the set of SIDs provisioned on that node. Each locator is advertised as a BGP-LS-SPF Prefix NLRI object along with the SRv6 Locator TLV in its BGP-LS-SPF Attribute.</t>
        <t>Only one SRv6 Locator TLVs <bcp14>SHOULD</bcp14> be advertised in the BGP-LS-SPF Attribute, associating with the BGP-LS-SPF prefix NLRI.</t>
        <t>This TLV <bcp14>MUST</bcp14> be advertised only once in the BGP-LS-SPF Attribute associated with the the BGP-LS-SPF Prefix NLRI.</t>
        <t>When multiple SRv6 Locator TLVs are received from a given node in the BGP-LS-SPF Attribute, the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV.</t>
        <t>The format of the SRv6 Locator TLV is the same as BGP-LS<xref section="5.1" sectionFormat="of" target="RFC9514"/>.</t>
        <figure anchor="ref-to-fig6">
          <name>SRv6 Locator TLV format</name>
          <artwork><![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    |   Algorithm   |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Metric                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <t>where:</t>
        <t>Type: 1162</t>
        <t>Length: variable</t>
        <t>Flags: 1 octet of flags. Currently, the flags field is not used and <bcp14>MUST</bcp14> be set to zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt.</t>
        <t>Algorithm: 1-octet field. Algorithm associated with the SID, as defined in the "IGP Algorithm Types" registry <xref target="RFC8665"/>.</t>
        <t>Reserved: 2-octet field. The value <bcp14>MUST</bcp14> be set to 0 when originated and ignored on receipt.</t>
        <t>Metric: 4-octet field. The value of the metric for the locator.</t>
        <t>Sub-TLVs: Used to advertise sub-TLVs that provide additional attributes for the given SRv6 Locator.  Currently, none are defined.</t>
        <t>Since BGP-LS-SPF defines the Prefix Metric TLV is mandatory for Prefix NLRI, so the Metric field in this TLV is no longer usable. It <bcp14>SHOULD</bcp14> be set to 0 and <bcp14>MUST</bcp14> be ignored on receipt.</t>
      </section>
    </section>
    <section anchor="srv6-sid-nlri">
      <name>SRv6 SID NLRI</name>
      <t>The SRv6 SID NLRI defined in <xref target="RFC9514"/> is used to carry the SRv6 SID information. When SRv6 SIDs need to be advertised in BGP-SPF, the following NLRI type and attributes TLV for SRv6 SID <bcp14>SHOULD</bcp14> be supported in BGP-LS-SPF SAFI:</t>
      <table anchor="ref-to-tab4">
        <name>SRv6 SID NLRI with BGP-LS-SPF</name>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="left">NLRI Type</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">6</td>
            <td align="left">SRv6 SID NLRI</td>
            <td align="left">RFC 9514</td>
          </tr>
          <tr>
            <td align="left">518</td>
            <td align="left">SRv6 SID Information TLV</td>
            <td align="left">RFC 9514</td>
          </tr>
        </tbody>
      </table>
      <t>The format of SRv6 SID NLRI is the same as that in BGP-LS<xref section="6" sectionFormat="of" target="RFC9514"/>.</t>
      <t>An SRv6-enabled node <bcp14>SHOULD</bcp14> advertise at least one SRv6 SID associated with an End behavior encapsulated in the SRv6 NLRI for itself as specified in <xref target="RFC8986"/>.</t>
      <t>An SRv6-enabled node <bcp14>MAY</bcp14> advertise multiple instances of the SRv6 SID NLRI -- one for each of the SRv6 SIDs to be advertised.</t>
      <section anchor="SID-info">
        <name>SRv6 SID Information TLV</name>
        <t>The SRv6 SID Information TLV is used to carry the SRv6 SID that do not require a particular neighbor in a SRv6 SID NLRI. This TLV <bcp14>SHOULD</bcp14> be supported in BGP-LS-SPF to advertise SRv6 SIDs of each node.</t>
        <t>SRv6 SID Information TLV is a mandatory TLV in SRv6 NLRI. For each SRv6 SID NLRI, it <bcp14>MUST</bcp14> contain a single SRv6 SID Information TLV.</t>
        <t>When multiple SRv6 SID Information TLVs are received from a given node in an BGP-LS-SPF SRv6 SID NLRI for the same SID, the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV in the NLRI.</t>
        <t>The format of SRv6 SID Information TLV is the same as <xref section="6.1" sectionFormat="of" target="RFC9514"/>.</t>
        <figure anchor="ref-to-fig7">
          <name>SRv6 SID Information TLV format</name>
          <artwork><![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               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (16 octets) ...                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <t>where:</t>
        <t>Type: 518</t>
        <t>Length: 16</t>
        <t>SID: 16-octet field. This field encodes the advertised SRv6 SID as a 128-bit value.</t>
        <t>The SRv6 SID <bcp14>MUST</bcp14> be allocated from its associated locator. SRv6 SIDs that are NOT allocated from the associated locator <bcp14>MUST</bcp14> be ignored.</t>
      </section>
    </section>
    <section anchor="srv6-sid-attribute-tlvs">
      <name>SRv6 SID Attribute TLVs</name>
      <section anchor="srv6-endpoint-behavior-tlv">
        <name>SRv6 Endpoint Behavior TLV</name>
        <t>The Endpoint Behavior TLV defined in <xref target="RFC9514"/> is used to advertise the behaviors associated with a SID. The BGP-LS-SPF <bcp14>SHOULD</bcp14> support this TLV to enable the advertisement of behaviors associated with a SRv6 SID.</t>
        <t>The SRv6 Endpoint Behavior TLV is a mandatory TLV that <bcp14>MUST</bcp14> be included once in the BGP-LS Attribute associated with the BGP-LS-SPF SRv6 SID NLRI.</t>
        <t>When multiple SRv6 Endpoint Behavior TLVs are received from a given node in the BGP-LS Attribute, the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV.</t>
        <t>The format of SRv6 Endpoint is the same as that in BGP-LS.</t>
        <figure anchor="ref-to-fig8">
          <name>SRv6 Endpoint Behavior TLV format</name>
          <artwork><![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               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Endpoint Behavior      |      Flags    |   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <t>Where:</t>
        <t>Type: 1250</t>
        <t>Length: 4</t>
        <t>Endpoint Behavior: 2-octet field. The Endpoint behavior code point for this SRv6 SID.</t>
        <t>Flags: 1 octet of flags. No flags are currently defined, and this field <bcp14>MUST</bcp14> be set to 0 on transmission and <bcp14>MUST</bcp14> be ignored on receipt.</t>
        <t>Algorithm: 1-octet field. Algorithm associated with the SID.</t>
        <t>Supported behavior values for this TLV are defined in <xref target="endpoint-behaviors"/> of this document. Unsupported or unrecognized behavior values are ignored by the receiver.</t>
      </section>
      <section anchor="srv6-sid-structure-tlv">
        <name>SRv6 SID Structure TLV</name>
        <t>The SRv6 SID Structure TLV defined in <xref target="RFC9514"/> is used to advertise the length of each individual part of the SRv6 SID as defined in <xref target="RFC8986"/>. BGP-LS-SPF <bcp14>MAY</bcp14> support this TLV to indicate the length of each individual part of the SRv6 SID of BGP-LS-SPF, which is useful in some scenarios using compressed SID.</t>
        <t>It is an optional TLV that <bcp14>MAY</bcp14> be used in the BGP-LS-SPF Attribute for SRv6 SID NLRI and as a sub-TLV of the SRv6 End.X SID TLV.</t>
        <t>The SRv6 SID Structure TLV <bcp14>MUST NOT</bcp14> appear more than once in its parent TLV. If it appears more than once in its parent TLV, the parent TLV <bcp14>MUST</bcp14> be ignored by the receiver.</t>
        <t>The format of SRv6 Structure TLV is the same as that in BGP-LS.</t>
        <figure anchor="ref-to-fig9">
          <name>SRv6 SID Structure TLV format</name>
          <artwork><![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               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    LB Length  |  LN Length    | Fun. Length   |  Arg. Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <t>where:</t>
        <t>Type: 1252</t>
        <t>Length: 4</t>
        <t>LB Length: 1-octet field. SRv6 SID Locator Block length in bits.</t>
        <t>LN Length: 1-octet field. SRv6 SID Locator Node length in bits.</t>
        <t>Fun. Length: 1-octet field. SRv6 SID Function length in bits.</t>
        <t>Arg. Length: 1-octet field. SRv6 SID Argument length in bits.</t>
        <t>The sum of all four sizes advertised in SRv6 SID Structure TLV <bcp14>MUST</bcp14> be less than or equal to 128 bits. If the sum of all four sizes advertised in the SRv6 SID Structure sub-TLV is larger than 128 bits, the parent TLV or NLRI <bcp14>MUST</bcp14> be ignored by the receiver.</t>
        <t>The SRv6 SID Structure sub-TLV is intended for informational use by the control and management planes. It <bcp14>MUST NOT</bcp14> be used at a transit node (as defined in <xref target="RFC8754"/>) for forwarding packets. The typical use cases for this information are described in the <xref section="10" sectionFormat="of" target="RFC9513"/> and <xref section="9" sectionFormat="of" target="RFC9352"/>.</t>
      </section>
    </section>
    <section anchor="endpoint-behaviors">
      <name>Advertsing Endpoint Behaviors</name>
      <t>Endpoint behaviors are defined in <xref target="RFC8986"/>. The code points for the Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors" registry of <xref target="RFC8986"/>. This section lists the Endpoint behaviors and their code points, which <bcp14>MAY</bcp14> be advertised by BGP-LS-SPF and the TLVs in which each type <bcp14>MAY</bcp14> appear.</t>
      <table anchor="ref-to-tab5">
        <name>SRv6 Endpoint Behaviors in BGP-LS-SPF</name>
        <thead>
          <tr>
            <th align="left">Endpoint Behavior</th>
            <th align="left">Endpoint Behavior Code Point</th>
            <th align="left">End SID</th>
            <th align="left">End.X SID</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">End(PSP, USP, USD)</td>
            <td align="left">1-4, 28-31</td>
            <td align="left">Y</td>
            <td align="left">N</td>
          </tr>
          <tr>
            <td align="left">End.X(PSP, USP, USD)</td>
            <td align="left">5-8, 32-35</td>
            <td align="left">N</td>
            <td align="left">Y</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document introduces no additional security vulnerabilities in addition to the ones as described in <xref target="RFC9552"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>This document refers extensively to the content of <xref target="RFC9514"/>, <xref target="RFC9513"/>, <xref target="RFC9352"/>, and <xref target="RFC9085"/>. The authors would like to thank the authors of these RFCs, they are James Uttaro, Hani Elmalky, Arjun Sreekantiah, Les Ginsberg, Shunwan Zhuang, Zhenbin Li, Zhibo Hu, Ketan Talaulikar, Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Stefano Previdi, Hannes Gredler, and Mach(Guoyi) Chen.</t>
      <t>The authors also would like to thank Acee Lindem for his valuable comments and suggestions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC9815" target="https://www.rfc-editor.org/info/rfc9815" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9815.xml">
          <front>
            <title>BGP Link State (BGP-LS) Shortest Path First (SPF) Routing</title>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="S. Zandi" initials="S." surname="Zandi"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="July" year="2025"/>
            <abstract>
              <t>Many Massively Scaled Data Centers (MSDCs) have converged on simplified Layer 3 (L3) routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both fabric routing and Data Center Interconnect (DCI) routing. This document describes extensions to BGP for use with BGP Link State (BGP-LS) distribution and the Shortest Path First (SPF) algorithm. In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9815"/>
          <seriesInfo name="DOI" value="10.17487/RFC9815"/>
        </reference>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t>BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
        <reference anchor="RFC9552" target="https://www.rfc-editor.org/info/rfc9552" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml">
          <front>
            <title>Distribution of Link-State and Traffic Engineering Information Using BGP</title>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <date month="December" year="2023"/>
            <abstract>
              <t>In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.</t>
              <t>This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control.</t>
              <t>Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</t>
              <t>This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9552"/>
          <seriesInfo name="DOI" value="10.17487/RFC9552"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9514" target="https://www.rfc-editor.org/info/rfc9514" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9514.xml">
          <front>
            <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)</title>
            <author fullname="G. Dawra" initials="G." surname="Dawra"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <author fullname="D. Bernier" initials="D." surname="Bernier"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <date month="December" year="2023"/>
            <abstract>
              <t>Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments". These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3.</t>
              <t>This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9514"/>
          <seriesInfo name="DOI" value="10.17487/RFC9514"/>
        </reference>
        <reference anchor="RFC8814" target="https://www.rfc-editor.org/info/rfc8814" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8814.xml">
          <front>
            <title>Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State</title>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="U. Chunduri" initials="U." surname="Chunduri"/>
            <author fullname="K. Talaulikar" initials="K." surname="Talaulikar"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <author fullname="N. Triantafillis" initials="N." surname="Triantafillis"/>
            <date month="August" year="2020"/>
            <abstract>
              <t>This document defines a way for a Border Gateway Protocol - Link
State (BGP-LS) speaker to advertise multiple types of supported
Maximum SID Depths (MSDs) at node and/or link granularity.</t>
              <t>Such advertisements allow entities (e.g., centralized controllers) to
determine whether a particular Segment Identifier (SID) stack can be
supported in a given network.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8814"/>
          <seriesInfo name="DOI" value="10.17487/RFC8814"/>
        </reference>
        <reference anchor="RFC9352" target="https://www.rfc-editor.org/info/rfc9352" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9352.xml">
          <front>
            <title>IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane</title>
            <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="A. Bashandy" initials="A." surname="Bashandy"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="Z. Hu" initials="Z." surname="Hu"/>
            <date month="February" year="2023"/>
            <abstract>
              <t>The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane.</t>
              <t>This document updates RFC 7370 by modifying an existing registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9352"/>
          <seriesInfo name="DOI" value="10.17487/RFC9352"/>
        </reference>
        <reference anchor="RFC9085" target="https://www.rfc-editor.org/info/rfc9085" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9085.xml">
          <front>
            <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing</title>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="H. Gredler" initials="H." surname="Gredler"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <date month="August" year="2021"/>
            <abstract>
              <t>Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.</t>
              <t>This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9085"/>
          <seriesInfo name="DOI" value="10.17487/RFC9085"/>
        </reference>
        <reference anchor="RFC9513" target="https://www.rfc-editor.org/info/rfc9513" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9513.xml">
          <front>
            <title>OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)</title>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <author fullname="Z. Hu" initials="Z." surname="Hu"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <date month="December" year="2023"/>
            <abstract>
              <t>The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9513"/>
          <seriesInfo name="DOI" value="10.17487/RFC9513"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC9259" target="https://www.rfc-editor.org/info/rfc9259" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9259.xml">
          <front>
            <title>Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)</title>
            <author fullname="Z. Ali" initials="Z." surname="Ali"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) network. The document also specifies the OAM flag (O-flag) in the Segment Routing Header (SRH) for performing controllable and predictable flow sampling from segment endpoints. In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9259"/>
          <seriesInfo name="DOI" value="10.17487/RFC9259"/>
        </reference>
        <reference anchor="RFC8986" target="https://www.rfc-editor.org/info/rfc8986" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <date month="February" year="2021"/>
            <abstract>
              <t>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
        <reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8665" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8665.xml">
          <front>
            <title>OSPF Extensions for Segment Routing</title>
            <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="H. Gredler" initials="H." surname="Gredler"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <date month="December" year="2019"/>
            <abstract>
              <t>Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</t>
              <t>This document describes the OSPFv2 extensions required for Segment Routing.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8665"/>
          <seriesInfo name="DOI" value="10.17487/RFC8665"/>
        </reference>
        <reference anchor="RFC9086" target="https://www.rfc-editor.org/info/rfc9086" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9086.xml">
          <front>
            <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering</title>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="S. Ray" initials="S." surname="Ray"/>
            <author fullname="J. Dong" initials="J." surname="Dong"/>
            <date month="August" year="2021"/>
            <abstract>
              <t>A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or 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 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>
          </front>
          <seriesInfo name="RFC" value="9086"/>
          <seriesInfo name="DOI" value="10.17487/RFC9086"/>
        </reference>
        <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="July" year="2018"/>
            <abstract>
              <t>Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</t>
              <t>SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC4202" target="https://www.rfc-editor.org/info/rfc4202" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4202.xml">
          <front>
            <title>Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <author fullname="K. Kompella" initials="K." role="editor" surname="Kompella"/>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <date month="October" year="2005"/>
            <abstract>
              <t>This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4202"/>
          <seriesInfo name="DOI" value="10.17487/RFC4202"/>
        </reference>
        <reference anchor="RFC8754" target="https://www.rfc-editor.org/info/rfc8754" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml">
          <front>
            <title>IPv6 Segment Routing Header (SRH)</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="D. Dukes" initials="D." role="editor" surname="Dukes"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <date month="March" year="2020"/>
            <abstract>
              <t>Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8754"/>
          <seriesInfo name="DOI" value="10.17487/RFC8754"/>
        </reference>
      </references>
    </references>
    <?line 630?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+0921YbSZLvnMM/5MKLmZXUSFyMObPTgwG3mcGYNbh7uvfs
Q0pKoWpKVerKKjBt3N+y37JfthGR96rUBRt6es8YTw+oKi+RkXGPyFS73V5d
KZMyFfvsYDpN75Lsir387rx9esEuxNVEZCV7l1clPs5vRMFOzm92n128u9nd
YMcfSpHJJM8kK3PdqX1x/mp1hff7hbjZp2fwgGH71ZVhPsj4BCYaFnxUttOk
ncqbot2/mrbldNSWxc1ue3N7dSXvyzwVpZD7qyvVdMjVX/gbfg3g11Ve3O0z
WQ5XV2TVnyQSgbi8m8LQJ8eXMP/qSjIt9llZVLLsbW6+2OwBTIXg+2Ytqyu3
eXF9VeTVdJ+dXnz/bnXlWtzBsyEMkZWiyETZPkIwcTBeleO8gMkBVyzJJHTp
sJ/GHMdhakmniX2QF1c8S37lJQC1z15X/FYk7FIMxlme5leJkNBGTHiS7rNf
sUuabG1v/3VM7TqDfAKvZVkIUe6zs7zDuju77KVIfsEdeJdzWDMbJCWsHx7+
TEthg7zKSkTJ4TjJOEJsAf1bhx3lHpx/S4R58AA4f05EZwi9ngrKv3fYOexr
asH8u7irCvsshPSgKAaVbME+DToOxGvs8VdO7xR8+C/Liwl0u0HKAaLIRsHn
TqdDYLTbjPdhNXxA2/0qLxjsP1IIkwOR8SLJJZPVYMy4ZG84kNuNSO/YxYCn
YsiOeMnZoUCqkezZm4ujQ7nRQtJniWQCeWQIrWBmIJLsun1RwqrYs9OLDTZM
YNKkX+G6GM8AaeVYsAugNSD5Epc/Zq+SAv58Bly0wXgKlJ+U4wnrcwljwvyD
KiW0dDz+Y6kATuVXAvgSxpvAlgL65ESyfMT6OQyKwE2LvMwHeaom1ixvHwrL
253ZcoBpQQC9bpIhTMeZzKtiIFihm9q5ARJewgLS/BabjeA3CI3VlT60FYiF
QQkLAjECQ0zFIBklA/g0JUqEZbIp4KLFbsdJCgviSVbCfzjBVBRtGkwSWvMM
9gUmwnXDaxhasiwfimdyAwcn9GpZhKN0gIgA5Ikw+w1klZQwwR0DwCopRlWK
/YAG+qnqqlE/e535lYBpCnabKETrTemwy3EiSQhWhE1A2jSXgmQnrKfIhxUM
iBDi7vikogbZ8PaEqImg0YvyNv/i4NWJJetJMhymAj+to1yjSYjaPq7TnJ/w
1ceP//bu1eGLve7Op0+aYCUBsQzNsgeRLMrvx6BZBfJ273kXQEYoZtOvXd/O
Tu/Tp5baF5xDRNQX0I5anaBRM3HLzk7fnTApUqEQV1SpkITfhWyhqR2xiBQv
PiRIREMxAtKlsWBpgOt2mbfhF5G4JPCSjN2g0Kmk5QHAS/9udUVkg3xIdE+N
QRxJ8UsFTwUhyucYmHVUZQQ0fAI92VZ94B1KrTWpwJdrHUVJHhOHXAv6r8a2
7Om5FkV3g22Z5lrEPjDubBntiWSPs384OLOfED058al9cgufAk4a8EyLgSEO
Cq3BHgFhXqQgHwznG4r7YsGBZAIqaIQ4FNlVkglRYAsSz/m0TCZaAypJwn4X
QdKCzQfSBKYHtYpzwF4CiqmHN4rGFAcDMlEEERNI6+vsHVBrUggiPHYKxk8F
LI/vLmFuUOEMTTDJ1t68v7hca6nf7Owt/f3u+D/fn7w7PsK/L14fnJ7aP1Z0
i4vXb9+fHrm/XM/Dt2/eHJ8dqc7wlAWPVtbeHPwIb3Cpa2/PL0/enh2crgEy
ASU+psGE1NSfIGlNC1ESaawA2wxAbMAH6PPy8Px//6e7rWVUr9t9ATJKfdjr
Pt+GD0BpmZqNKF99BOzfrQAGBS9wFOA5QOs0KXkKpIuMPs5vM4Y02llZ+dN/
IWb+e5/9uT+Ydrf/oh/ggoOHBmfBQ8JZ80mjs0Ji5FFkGovN4HkN0yG8Bz8G
nw3evYd//jYFNmDt7t63f1lRSowo7wxEAzuwkvry9HuJb18Sg6Fy0wK/u40C
H8l6lKMIQ3aKDCBxBKaXBpsrq+kU9ZnaTafBcY57hn4Gu2dHtOVTkuPBzz0Q
+Qh2CWSy+gyd2vSjf8V+6q+wE+t2t/ZgOIL4kE95P0lBb2hw1UyvDhkuk9mZ
WG93F9/QCsEWNW198KDT3l7Qqbu5tUMzsQOrr/2OeqbNvR3b6eM+Wy/ECJVX
yftdRj7kf6xFtsbJmJpJtPZJc74UM7dFEtPxIejWMlGCWOaDhOPuWE3uCRsa
AlW2kThR7BmJE0ctaWi1+z4loTlPugD1XZaBN6PFLI0y8EdBVQwvUIUBI4Pj
ZGG1lrYFlORAkg0T9GylG1BTIah9O1bHeCduwaR2NOmaHiS0cCHK8vCwQwAh
+Aaf0FvafqSB9PTtQqSEZH9dHcQajA3/A4GfT7VtgVPBimO7oA0Ikk39YB9h
WTAGTUVTpN4SL80CIv1IYuaIehLPwllschYQHfYDSFg2qdIymaYzdl1ShADM
moEA7w78tSKfAPKu4ENGkClBot8XCjQgByVeyOLNB4OqUIyvCQDXsDyYZNaM
YLIZdIlod4jQ48ZGIlAzpAyfrrSBBewNxgUv0QAaEa2srtBWDXOBzlJp6QGh
6BhWUZ4zEeso5Ve0ijiY4fIA6AGYCOA1oAbVbMBLJ1rRnLHDB33BxA4muDNY
UKqQSy3WyZf/7bffVlfYJmv+dCPPepFnW9S/C++22DbbYbvsOdtjLx7ybHXl
39tf+A/FcfhDCieQ4PbnFAxFQGj4c/8EULyiLZ8BBQONJ0WBXPPYUNCueqpm
lFzBdmpdE6MORUeoWcicJ9JQKNxHLbenPiu87bNt9ZFWt8967Rz8GZCDiUiH
nZrdoIgeRYRWD47qokSHj+fSzRL4wV24f3s/G8lLYVlD6ePjbRuXs89A2khR
tpyy0qxPis4IsbftPkkSrRtekzUa6MhvUUf2dsDO7ejxybNyKEOpYnqgBFGS
Vi9nRJ5qWRXkOJE4uLOSH8BDhbWJZh14R5nU0V4axjRKrrK8UKYfyedpqeEw
KKvtrZJAjSnQDrfiUUM6Y+h13xIlMwsoTLKP6/igDQ+MaRMaYg3LAu2wmmVh
VTOiOwWvr5QuzlILObwWHNxRjDe83gB9LApyEKVnwWrroaFnPfkbMyqGyYhs
2DLSE53cMb8RXiMNprEZStRgr9ExHYArD4AShQELAypbgWs4x3DBueRcjLgF
dwKDLkD5craKs1gVaRz8+AczV/w1SfZHsFQQ3QhQSZTv4ggU53ViUtH6hY6e
beOQZFJvYTSOup1ctE8ulJmfylwxAqA7DJ2ij+BmU43TfMBLZwmtnXx3jm3a
xItrgIArjFXe2ciTGvfk4OzACiE55oV+jFC02FsifxdRtPPf6UV5jj5OKqu+
VGuTsPOgK+oGk7axDC1SHz4RKqDk20FOn6Dk+mJLhn25LcPYI2jwmqXQNGdq
75smzf3jQmIoRM2Mn77naSWY+4xvO51O+B4fPBYkUbumF9o1gRBzVk3MrgGX
vxPaNRg9RhnVAiaYoqLFcBuSXpmXIARThWPN+je0fKUYgRpJT0o9IC1931jw
JBDyDH0INgFZzqYcxAk+5KyrFaxFL/KQ/1BhkYz9oQB2TDUzTU0oPOjp9gX9
TV+EbGHbb63uJEAtsgyHTTDILWnipjIkLZZr/hXEohTPG3EMo8NaYTeqQlsm
KDh1PyPWXYpceTiZLDmI0g5Ri0KnNKHgVPACBc9NwgFJIG2GtyhHDs5PCImq
EYXe0aoRQ+MEkr4kkWP1gBVtSnCQCrbiZIBrmuawDgoeBuSj3cGybo3UzSe9
TKM4tKGzzt7wD8mkmhjrQwKZjUpr9VhdMLcVkzALyHeV3dFNFeVpMgz7WXLU
RqciMqvzpnxwDTvXJ5OC4s5UuICNj7OhwkNfAIoSDIHUQkacXZwced72jaEz
p7dbWrgbynFNpKwmysQBzG02cASzs/N8OhM79fdRvGTVpC/IPQdApY8FmFZF
4C0dY+id1s/WzkWGtDLBWL+xFHGuZ+cX5xsWze9eryHprb2PNn1fb2qwKFt6
5rhe73R3LV++2NvVfKkI2beHLCJ/FUXOyMybif8sWCX6EGqh+BSWhL0BXHQz
bgC+xla87hxnYKvJmXvRaLDMZhDvmXzHcKhSQ1NelAZrdlSP/pru0iMjaYyO
QDb0qIGsVdjTNBncKaDJFAXphqaQJDGuU4DEFeBRoCTDoSnpdIfbT/AdwPRZ
m0BBEgTshZiLxJh8cNSgCp7XigEJkdXU5JzqK48y1dFcljry9lAlIsXcXdRK
kWSlBgxRCQ4FqlrEwFDgAm2mWlmgSTZIKzSwwTy2ji15JCQSWghL5+gfu/qP
y237h3qklv/+4kiZmPjuH/bZ70EnTWbCnbaUShsIqAExQmInQIKK/eUFKDBK
QWt6T7IMEKsF8q2ZCMjJZMPHykm1lKcQ7tzodpBz8AoSVNTd309NXq6owA9d
k9kUxkhR6ypJFk5iB/WD/Jt7O4BpdllvP9M5B/6ykER87qZ/iMBhGjgZGD8U
hwCsLs49NcH6/+rcnqAiJzpU2pyy4M7XDVdold/MNf1uYXkeCYXYkHmdMMJV
UJImmWByXJpCKPN609isqgiiTtkRctJywASqEH8OmDmAYAmIswZ9CMzWGqmo
Cjas1PeIXNOObhjxdd10ZMFJm0TX5Do/F9AMLRoDo9fpdrZs8ECxauAwf7G/
/OXu8jI+6H3NA76vOb33y4yz1DxuJ7pqHvegx4L35Nr677NHgyPq6W6Fnm4o
0ua7upioDl3d77Wrq57asaCp8mTJcTBPLcE66tfu2uyIkgcegOCFlZq6end3
RxccSOEPvFyUyStwIBsFX78TfDDW+Q2yxTLbALmp29tjfRMO9Z10WkhetGwJ
WEuHvK50zRDHID8xmxfQapgcB74OopolELGJ9B1W7VIZJLVtHZgGQYUGcRmz
hRsaHTR2hx1jQ91V6csB1tWpSitA+AeV1E5TY8c5QMijt0PVnGSgqcGYLNuA
Fk4NkBHtxqW/+HM1O2VK8/7PIJZkLbWvdkaPqJTXMykEYFWv59OnDcQy7pc3
sNVkHfbKGVewSUWi46oU9jaAzs0A+0Ba7x7DE1Typ9t7Jtw05RlpRaeKAyWn
UCmdWee50tw3kBrayg3YICBly7jkgNHKen/1p1NDwfjBKxqlaA3lGhxntGyC
RC9WtZy1XpXUk3pSAqOm/HVKiypiVa2n48p6OYpjyBNTXg5z+9sP79pYeq73
35IK9lHpevFhIKaeFes8TZquEb+wTJaJ5Grcz4tv0iS7tlFtm2yJQaqcDpwb
xa0GEZy1zoe2TIYAY23BYZ5B10xSbsZm9hJoU6aqJpLoxibnsABsGRrsBJJO
JZAMAEMxpYrkaqpjduIDWRDKnvMEhOYRJbmGY12DpZ1Mqtv1ZTZZJTp2D3gF
iSIyWRXaSPY2vIl9S+yOB2iAvl0YFs7khUKLKYCdM2TGqmzeqMMin07FsIP4
PN5XMVR45Bw3gyONId6XDj+wZg729Teymkx4oXZJOKyZzJGPPa2GsHZ02To7
2nPfk6oX3oWDyT9kvd3mrqm3C7nEztSst1OdTnvsZZUNMUorKNAQVrF59XO6
SO85MzMRXmqVepEivbDermcsqMgWLV9vF+v8sHI7GqFRbhci7+O6ky5BnjZs
tkzVXc25mcNPZLkNf+YDoIs7miMMchB3SpAounydQsaIXBU7hmb2iXJO6TFJ
WbQ/7Mh+pV9RZZmJQqukJjRFU+9my5aJS3CASzJsmrnO5hKxgPv4/JidCySp
YDl2k00iA7MAWC6rTgXY+IZq135zDuO7Yo1Na+ItkY2fg/nFaFyMqhrHzyCP
haGOGjF/RqjjTa6kf0bBUZPWCTK4z3KyH7RBG4K5YcLCOkoYM9A8Y+9NkN8P
Fmv97Bj3qeyxwSoBfgzLu1OLUgcOhgrLekPVSkocB09ZpIJjVAQWUmXJL1UD
ALentEO5Wqs2u4zBgTXpKUaNr8YY3EB48wn8McyxE5B2MmIjwbGqRwJZXoN0
OUZyuDxpn746MIFGOgzgTW0sCkAclgKRIgcNaBt4djqGMzLt3lmHgZDUNPV1
lEHWCMFis14ha6LCoTnf8eGgEYc5QTsRQnNL4Y431LNr+tSGsjG8WGZ9bj/J
qNNZMKcRGP5b3I5wrwI0hIFSms+YEyR2kIoH+WSqj7HQ2SCw6koSwubQjc6T
LVfPECll+FqQyR69INMmOF8ajeZDYSs18bOLXTwuFD+gFCjNLH5hInxGRn6G
6UAqJNig8NJT4ILmwawCzrARoZ/ZP1+h+L2hAGNXhZ/BKzbVKUAa+O+pCoW3
wzBjaE7Ew4w6yAgmPQWHatU0pGrrzNcoG76M1iB49RkqpJN4gYMw6G1C3t3N
Tg/FbSMqp8uVdYDTlNT4p0pd5W291kzZpTWE6MwAe+bi7Xudbliqt2FjLNqi
XTzGC2+Mne6WCS34MdoQdU5cxQwfVEYsDN5Gm/lqm2IWrmJCh01toJfgUcKs
AcylLY2q1VDdKuFniiS0LU7BpKrAk5gqAMvBxuApWJCgXtVoXk21HiOJZXy3
N3t6o135cvdxy5cBaBhzt75gAEdNQMeMdQbds5l8guUYfKbKcJezNyy+z943
PDZp2J+A14eNsYIi0Ra9l4kz+LRhLjNxR93qoP6Bt7nA7Tamy4JmjW3wgxiY
uRvC3qsUNJiFjcHQKTTFMWjxV0XG8FBNM3A05VQtfbpFfTTGNQD6zDBtIk5H
x2nwiG2ByAlP1N4mcoyPUNQWeWqPDeORaphYe4RYlwFIrvAc9vhO0oFsnNfU
sIDtVxiP7pTfwUp6rg6O9WmN1vozZ62HYprmd8JPXFAVm/Z58MoVcMNoGiL6
SNE3+grzfUxAsZp+dWXicOxRSOcBO/sgr7EWMXHxDetP0pUVD86dw5INhkJG
MPkXn/xjUk3hgyl0KHFiyXIYvl1d8QQWRydPBWgVCtDQV2IxmkTWhr9x88JC
CZJxIQ2T32w82QW7MdOt5bNDSgcG0+RTBc6Hn08vQ3wQuSTqKgNT91MG5BLD
8blZGqh+4mmj8XwihFHtuQPQI3esmgaEzn2Anb+KkwwLfpuhY0wJHRysL4AL
RW1EvCPkFiU5yR6sL2CYZxJFYzneiu3KHqf+/Kvb9jTn6OyEdU4x4W3jzT09
FDXJZ3S3Z53bn2++eRQgolb6jrXSF8ly32T/oVkZ0H3ei1cGmNr42SjfZ9tN
+2rAC8rAcmLVNlqMqeO4eFXnds/abhrBvIFgvzq/HM8qhlc1BNZnSmS9ZM0V
xvSihTHr6/X0ApaOW73pJx2++FQalmfHDp+Z0LQtCSCZN+NEWnAb0NKh6Ohx
sEUguItZTAWsvo7FlNkB3txhoxmIrx9lCg8wzUyW2Jp8daOM9Ev3w2oRsLiE
TrsvKhuxUD/s6Fs9JfdPKw90Oj929s3H2z/r7FtolXj6VV2PYw5CuqOg5nh8
wGk1Bfzxoz0uqtOlpKOga71Xb/e59g7doRfN4Lrm40HXoZgLHmP9pdo3ba56
F1IEoXC777E0bnh67/dP4+72bHLVwezPVE/jhsnVLaORoqhdPr0a7/6wBKtX
0ROKdW9hH9dNgVEgC/wmD06u2nqjYFcpE6SEtR1e0zRe3oQuZZ5pQ9347Esd
+J0tkc0JhKGIFp75p9HiMJNQUzDbai/cg1pdmR92UGmlmQVmarBGpVpQasNn
lWWp2rFFpWNz68QQJW+VbI0VnTmOnFsr5lVQGxpMfJC8ptMaET5I6MemjFL9
AsqPKQZ/2fP1wnwEfJbOiHpasa0Mhb6CwNkRO0GUdLtW1/zVEXtkF2h2fsyb
8XOv2vgsR8z9vBF4peK8Fo8IxdPmY6K+3m6YkfGZZEHZN6j0+Ann4AIXr+Sb
MiAddkhsS0V4xM20+fpsqTq5oW539C4T0fF0daTqcy4d+YL8Rv38w4widP9y
A7/0fP6tJ35K40uSB4ZOa16zP7wWhRNFz7UaZj3IYycLlKz3CQuMFG//M9SW
3sUUKmORoEz3lIJ6qSS21kCaK7UonwBmcPA7mthTUi2sesFuur13gtmF31ws
r5IUm8BqMM+ENtuxBKG5owI0fWD6mYfL2H0Y53AuuUqRuUJm7ZC5iq9M2NPP
oXmh73qvl32q4Lk51s8bIR0368KCULpJdF8lf6xDQeM37pQwisX5FEv5E7W3
5E7sqpFCvDbmsR4F9dnp7gV9apXhkT6hB7IdyEk76yyHw7NAwg5zA77OBNmN
GCD6pEm0oMwxalBO5qUHG/WYePjVJsNFZo6VOjGnwhcI9Igi31Kko7CSccYB
lSaUGMFwIFqT0RT0ycBSs7hqt1lQ3FdrJBtEH/hjsV3+uG4r/xvcWW87nyH9
ajNTNUfpxDLBcxGFy9fQ5Q/Bwhb46iGHBVLYLR0vqraun388ILYO7slI7crY
zaUzLl7xpDsCkeiMtj4mjAV+ID7S2Sib5RRET2Isdg54KGkC0rCOIfIRqekv
CjLFwkg+60ZwGkaNLN9+dR3cn0/tOswta5v/869U6PWvBEXUyXnOGsq7ztDz
nR0wHkJfp7urLeanqdoJ9JKN6NizsCQtKcfitLqx5GOn1fDIV603AdTo3aiQ
rlm1zYi2d76kVgHrFftEXz48AGrvvZlxfRB5Ow+KbAbbYsoZ5k7jVz35xyIi
64vo3aBKzJ5JaIbmFoTlZmnFWfo3Ct/DwnNPEZoLYZtrGH/Vok8iLf8YBexR
mb3XKBWOsNiC+oPezmYotvXlwk9RMdxZEPY6y70S4IGJgRghaAqbrOJ4nMt2
v6SuV1WP2qyNwYG+Q8GuH7ehcbeo0KhrW1kKct2UPZnv7uiw994JW7zXLwPo
86ss+TUyIc4x/1Y8L2xRFtWAbi+uf7FA4+1npOHsTY3kM/klnd6VYzMKyQNv
eZkKTHOT1+dMHaTLbTmsrWtN9Pdsue/qqegQE1WhCkl2irmUr4xVLvi1CdWC
jFYYV7JfskD2j6lT9+EPjgY0baJwD+25dv1dLRPv1KBSrWgs6TJJypWf4NE5
3VwubN/yyyyXvaYx5kkGUH9VeP8khXf60k4Bn0/P/Lt+2Ksq67gHeAdPceUe
PKHCe9F0UkJ6WZCP6e30osrOrrahA+w8JuvzEtyAayNlgBTxHhtTOXe29ChU
8BQdxMPt7GFe6etx4kN4uzF7iANzp05kCGRLWU3UHUQpILUqmASNU7/GZZ6o
oUtkpdQio2Dil0odCDCX/5CAKZecqYwLNiMVQUykvLhS1+dkdoqGTELMB5fM
LJBN86fEUwf2SzK95AOs07t+15x2QFEOng6/Uk4U3R+ijtX7V46ovB6IXWXJ
JKpsgz2LqsjnO9t4wom+icC7mYTuNFTnGDCFQScoEKABl75V4kEcvyTcRey6
m+GJKH1rhj0xFdYUao9Y1cCTumwYk1Jdr1A3gIKjap6PWbedfAPhchzWIpqo
5+JxKE0Zt5z9VGX9LJuKXZgrWFK6u2rWhKrUNPHNYnsjbbRi0bMLTJ2quU9Q
9SKrhhJTlC8g7axr1WIOSuzpIcJyjs/oLRH4vbMmXMppQdnarLdeu3sNF97l
28Jrb/H/jjYQrm57u8V6e+2tiJa+Zz/av8487aahrI12z3baey221Wtv7cTG
OmuM2kxd7cz3pLxT4i6FRWEfAX4K3v1ziNeYDU0pry03sl/CZ7/ikLKpXk5Y
mhFuqjSD/vZLiTC6r5uZ8y25viejdv2Z+55QzXr0ZQGLIBpzAkV9scDAfSEF
cO7gOstvUzFUsirSt8AEpTTfpUhfK6xBRHGng0RhAaf9tOV92lJfblq/hEcf
mKTvr5bsNq/SobqNgSbhWAvtvbd159BfyXz1rQd/43hI5X1Z8iJvsdc8S9hx
OuHp9V0L1N/PFSiwQohrumNi3AKNKdl3SSb7orhqsYtxld2CLvlpXHH8JpCf
xiLrA7ZPE/w76efsddVifxcltLnkKa8APl602LnAW9zOJfgL1y12mHIV5HmV
pHKU4HciHozxIu6XXMI6hgDJy6KCXTgSg4KLTMDEpRhxeHJeCHBcEgIct/07
UFSpKBSy3oAUePZdld8lG+wQIHM3BGqcUEl3DHEHA0F19EOhvrsTtxXdR4r1
gVujzv/gHLK6usKLFQxdADuzPuiW1ZX/A/YN40p+fQAA

-->

</rfc>
