<?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-03" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.30.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-03"/>
    <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="July" day="22"/>
    <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-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="srv6-endx-sid-tlv">
        <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>Multiple SRv6 Locator TLVs <bcp14>MAY</bcp14> be advertised in the BGP-LS-SPF Attribute. Each locator is advertised in a SRv6 Locator TLV.</t>
        <t>When multiple SRv6 Locator TLVs are received from a given node in an BGP-LS-SPF prefix NLRI for the same locator, the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV in the NLRI.</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>
          <tr>
            <td align="left">1250</td>
            <td align="left">SRv6 Endpoint Behavior 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="srv6-sid-information-tlv">
        <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 an BGP-LS-SPF SRv6 SID NLRI, the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV in the NLRI.</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 611?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+0921YjR5LvOod/yIUXmJU0SFya5syOh+ZisIFmG9oee88+
pKQUKnepSq6sAstN+1v2W/bLNiLyUplVqQsN2N4zrR4PqktmRkbGPSJTrVZr
pZFHeSz22cFkEk+j5Ja9+fqqdX7NrsXtWCQ5e5cWOd5O70TGzq7udtev393t
brDjX3KRyChNJMtT3ah1fXWy0uC9Xibu9uke3GD4/kpjkPYTPoaBBhkf5q04
asXyLmv1bictORm2ZHa329rcWmmkPZnGIhdyf6VRTAZcfcO/8KcPf27TbLrP
ZD5YaciiN44kAnEznUDXZ8c3MP5KI5pk+yzPCpl3Nzdfb3YBpkzwfTOXlcZ9
mn24zdJiss/Or797t9L4IKZwbwBdJLnIEpG3jhBM7IwX+SjNYHDAFYsSCU3a
7McRx36YmtJ5ZG+k2S1Pol95DkDts9OC34uI3Yj+KEnj9DYSEt4RYx7F++xX
bBJHW9vb/xjRe+1+OobHMs+EyPfZZdpmnZ1d9kZEP+MKvEs5zJn1oxzmDzd/
oqmwflokOaLkcBQlHCG2gH7TZkepA+c3kTA3HgHnT5FoD6DVS0H5bZtdwbrG
FsxvxbTI7D0f0oMs6xeyCevUb5cgfsAW/+D0TMGH/5I0G0OzO6QcIIpk6F23
220Co9VivAez4X1a7pM0Y7D+SCFM9kXCsyiVTBb9EeOSXXAgtzsRT9l1n8di
wI54ztmhQKqRbP3i+uhQbjSR9FkkmUAeGcBbMDIQSfKhdZ3DrNj6+fUGG0Qw
aNQrcF6MJ4C0fCTYNdAakHyO0x+xkyiDr+vARRuMx0D5UT4asx6X0CeM3y9i
Qkvb4T8WC+BUfiuAL6G/MSwpoE+OJUuHrJdCpwjcJEvztJ/GamDN8vamsLzd
ni0HmBYE0OouGsBwnMm0yPqCZfpVOzZAwnOYQJze42tD+AtCY6XRg3cFYqGf
w4RAjEAXE9GPhlEfriZEiTBNNgFcNNn9KIphQjxKcvgPB5iIrEWdSUJrmsC6
wEA4b3gMXUuWpAOxLjewc0KvlkXYSxuICEAeC7PeQFZRDgNMGQBWSDEsYmwH
NNCLVVON+tnzTG8FDJOx+0ghWi9Km92MIklCsCBsAtImqRQkO2E+WToooEOE
EFfHJRXVyYazJkRNBI2elLP41wcnZ5asx9FgEAu8WkO5RoMQtX1cozE/4aOP
H//t3cnh673OzqdPmmAlAbEMzbJHkSzK7+egWQXydvdVB0BGKGbTr53fzk73
06emWhccQwTUF9COmp2gXhNxzy7P350xKWKhEJcVsZCE34VsoakdsYgUL36J
kIgGYgikS33B1ADXrTxtwR8icUngRQm7Q6FTSMsDgJfedKUhkn46ILqnl0Ec
SfFzAXcFIcrlGBh1WCQENFyBnmypNvAMpdaqVODL1baiJIeJfa4F/VdhW/by
XIuiu8a2THMtYh8Yd7aMdkSyw9nfH1zaK0RPSnxq79zDlcdJfZ5oMTDATuFt
sEdAmGcxyAfD+Ybiniw4kExABQ0RhyK5jRIhMnyDxHM6yaOx1oBKkrDfRZA0
YfGBNIHpQa3iGLCWgGJq4fSiMcXBgIwUQYQE0toaewfUGmWCCI+dg/FTAMvj
sxsYG1Q4QxNMstWL99c3q031l12+pe/vjv/z/dm74yP8fn16cH5uvzT0G9en
b9+fH5XfypaHby8uji+PVGO4y7xbjdWLgx/gCU519e3Vzdnby4PzVUAmoMTF
NJiQmvojJK1JJnIijQawTR/EBlxAmzeHV//7P51tLaO6nc5rkFHqYq/zahsu
gNISNRpRvroE7E8bgEHBM+wFeA7QOolyHgPpIqOP0vuEIY22G42//Bdi5r/3
2d96/Uln++/6Bk7Yu2lw5t0knNXv1BorJAZuBYax2PTuVzDtw3vwg3dt8O7c
/NtXMbABa3X2vvp7QykxorxLEA3swErqm/PvJD59QwyGyk0L/M42Cnwk62GK
IgzZKdCBxB6YnhosriwmE9RnajVLDY5jPDD0M9gDO6Iln5Ac9z4PQORDWCWQ
yeoaGrXoo/+EPtVH2Ih1Olt70B1BfMgnvBfFoDc0uGqkk0OG02R2JNbd3cUn
NEOwRc27LnjQaG/Pa9TZ3NqhkdiB1dduQz3S5t6ObfRxn61lYojKK+e9DiMf
8j9WA0tTypiKSbT6SXO+FDOXRRLT8QHo1jxSglim/Yjj6lhN7ggb6gJVtpE4
QewZiRNGLWlotfouJaE5T7oA9V2SgDejxSz10nd7QVUMD1CFASOD42RhtZa2
BZTkQJQMIvRsZdmhpkJQ+7avtvFOygmT2tGka1qQ0MKJKMvDwQ4BhOAbfEJr
aduRBtLDtzIRE5LdebURa9A3/A8EfjrRtgUOBTMOrYI2IEg29bx1hGlBHzQU
DRE7U7wxEwi0I4mZIupJPIvSYpOzgGiz70HCsnER59EknrHqkiIEYNb0BXh3
4K9l6RiQdwsXCUGmBIl+ninQgByUeCGLN+33i0wxviYAnMPyYJJZM4TBZtAl
or1EhO431BOBmiBluHSlDSxgbzAueI4G0JBoZaVBSzVIBTpLuaUHhKJtWEV5
zkSsw5jf0izCYPrTA6D7YCKA14AaVLMBz0vRiuaM7d5rCya2N8DUYEGpQi61
WCdf/rfffltpsE1W/3QC97qBe1vUvgPPttg222G77BXbY68fc2+l8e+tJ/5D
cex/SOF4Etx+zsFQBIT6n4cXgOKElnwGFAw0nhQZcs1zQ0Gr6qiaYXQLy6l1
TYg6FB2hZiFznkhDoXAftdyeulZ422fb6pJmt8+6rRT8GZCDkYgH7YrdoIge
RYRWDyXVBYkOb8+lmyXwg6vw8PZhNpKXwrKG0sXH2xZOZ5+BtJEib5bKSrM+
KTojxN62eiRJtG44JWvU05FfoY7s7oCd29b9k2dVogylimmBEkRJWj2dIXmq
eZGR40TiYGolP4CHCmsTzTrwjhKpo73UjXkpuk3STJl+JJ8nuYbDoKyytkoC
1YZAO9yKRw3pjK7XXEuUzCygMMk+ruGNFtwwpo1viNUsC7TDKpaFVc2I7hi8
vlyWcZZKyOFUcHBHMd5wugH6WGTkIErHgtXWQ03POvI3ZFQMoiHZsHmgJTq5
I34nnJc0mMZmyFGDnaJj2gdXHgAlCgMWBlQ2PddwjuGCY8m5GCkn3PYMOg/l
y9kqpcWqSOPghz+ZueLOSbI/g6WC6EaAcqL8Mo5Acd5STCpav9bRs23skkzq
LYzGUbOz69bZtTLzY5kqRgB0+6FT9BHK0dTLcdrneWkJrZ59fYXvtIgXVwEB
txirnNrIk+r37ODywAohOeKZvo1QNNlbIv8yomjHn+pJOY4+DiqLnlRzk7Dy
oCuqBpO2sQwtUhs+Fiqg5NpBpT5ByfVkS4Y93ZZh7Bk0eMVSqJszled1k+bh
eSExFKJGxqvveFwIVl7j03a77T/HG88FSdCu6fp2jSfESqsmZNeAy9/27RqM
HqOMagITTFDRYrgNSS9PcxCCscKxZv07mr5SjECNpCel7pCmvm8seBIIaYI+
BBuDLGcTDuIEb3LW0QrWohd5yL2psEjG/kAAO8aamSYmFO61LNcF/U1XhGzh
u19Z3UmAWmQZDhtjkFvSwHVlSFos1fwriEUpnjfkGEaHucJqFJm2TFBw6nZG
rJcpcuXhJDLnIErbRC0KndKEgmPBMxQ8dxEHJIG0GdyjHDm4OiMkqpco9I5W
jRgYJ5D0JYkcqwesaFOCg1SwFSd9nNMkhXlQ8NAjH+0O5lVrpGo+6WkaxaEN
nTV2wX+JxsXYWB8SyGyYW6vH6oK5bzEJo4B8V9kd/aqiPE2GfjtLjtroVERm
dd6E9z/AyvXIpKC4MxUu4MvHyUDhoScARRGGQCohI86uz44cb/vO0Fmpt5ta
uBvKKV+RshgrEwcwt1nDEYzOrtLJTOxUnwfxkhTjniD3HACVLhZgWBWBt3SM
oXeaP1u9EgnSyhhj/cZSxLHWr66vNiya352uIumtvg+++r76qsGibOqRw3q9
3dm1fPl6b1fzpSJk1x6yiPxVZCkjM28m/hNvluhDqIniXZgStgZw0c24A/hq
S3HaPk7AVpMz16L2wjKLQbxn8h2DgUoNTXiWG6zZXh36q7tLz4ykEToCycCh
BrJWYU3jqD9VQJMpCtINTSFJYlynAIkrwKNASYZdU9JpistP8B3A8EmLQEES
BOz5mAvEmFxwVKcKnlPFgITIYmJyTtWZB5nqaC5LHTlrqBKRYu4qaqVIslID
hqgEhwJVLWJgIHCCNlOtLNAo6ccFGthgHlvHljwSEglNhKV99M9d/eVm235R
t9T0318fKRMTn/3T3vs96KTOTLjSllJpAQE1IEZI7HhIULG/NAMFRiloTe9R
kgBitUC+NwMBOZls+Eg5qZbyFMJLN7rl5RycggQVdXfXU5NXWVTghq7JbPJj
pKh1lSTzB7GdukH+zb0dwDS7qb4/0zkH/rKQBHzuun+IwGEaOOobPxS7AKwu
zj3Vwfr/6tyeoSInOlTanLLgpa/rz9Aqv5lz+t3C8jwQCrEh8yph+LOgJE00
xuS4NIVQ5vGmsVlVEUSVsgPkpOWACVQh/kpg5gCCJSClNehCYJbWSEVVsGGl
vkPkmnb0iwFftxyOLDhpk+iaXOfnAuqhRWNgdNud9pYNHihW9RzmJ/vLT3eX
l/FBHyoe8EPF6X1Ypp+lxilXoqPGKW90mfecXFv3efJscAQ93S3f0/VF2nxX
FxPVvqv7nXZ11V3bF7yqPFlyHMxdS7Al9Wt3bXZEyQEPQHDCSnVdvbu7owsO
pHA7Xi7K5BQ4YNHOsgUO1I2rwqoVD35n8k9Z6LC5awodlE0ERppTgBAsdFCN
zrvsTZEM0D0WZOH55QNO4YKujnjFzEiEl0qJRKA6wi906BrSDSzR8oUOocaP
q3OgHmp1Dh7yvJi4j9ZlKhwqigT6IMu55kwnjLhk8BPvAylMaQzfoOynoH7l
JE10qSC554hP5afDa/aOMgTodowzRO/J9uxWVWRFkhiPXwWQ4VVkq7stW5In
wdjIyUaqx5XrU8RiueOrY3YlkIq86dh1NUEjjLhgaZKqwLS2pHqvdXEF/ZeJ
sU1rwS+R+ZiD+cVoXIyqCpPPII+FZmWFfj/DrLzAuA20S8gRNSE0L1q+jk8Q
pYKbkkML5oZxwbVHFiqHsPC12YWXS/Ema22aEMOpSL3BKgF+DNObqkmp4s6B
wrJeUDWTHPvBitZYcLRAYSJFEv1c1AAo15RWKFVzxYAkOGCJiG5HPQq98Bg9
9NsRGpIIbwouJxh82AhIOxqyoeCYQZVAlh9AoBwjOdyctc5PDoxTR4WXztDG
fQXEYdqVPP04Ll+QpcWPpmOiVSkjHZnq+nZQ1f0RBQysllQWnawQgsVmtRrJ
eOAoFXXPsCptFw7qcZAStGMhNLdkZSlpNZKpK2RFIgkl1m+sju0GdHXoEMY0
AsN9isvhr5WHBt8ppfHuI0CmqR5GKu6n44kuGaY67IGQOQlhU+CsY5LL5Y4C
aaMvxS/s2YtfbDD5jdFoLhS2KgavSzvxeaH4HqVAbkZxi0DgGhl5HUOvlLTZ
IFP+JXBB42AEB0fYCNDP7M8XKH5vKMC+Va6+ZOsmEwikgf9eqihr23fpfHMi
7NJphw6seLyqZi5J1VaZr1aidRPM9zi5MFXSCrLTmFGVAIMJL3Q2210Ut7Wg
qy4N086kSV+6O3jKKqdqXl/ZpRWE6CgMWy9jG3vtjl8WsWELfrRFu7iP104f
O50t6ENr9NIf9lFXiquQ4YPKiPmOcvA1V21THUqZnUJASZVqp5rgUcKsBsyN
TUNX8tX3SviZhJS2xfH7pMhw1ws+ilMONgaPwYIE9ap6c+rXdB9RKLq+vdnV
C12WinWet1QMgIY+d6sTBnDUALSlS2crHJvJJVjOOt09qsIr8yOGxffZ+5rH
Jg37E/B6YxdmqyJt0TtRT4NPu3/LDGwcywUetjFZFrxWQ78br8Do6ADWXIX5
wRysdYbOoElAoqVfZAnDwuV6anfCqSLtfIvaaExrAPS+LFo8HI5KlnEbU4ZI
8Xct3UdyhLdQxGZpbLdm4bY1GFh7gpj7AuQWuNdtNJW06Q3HNXlCsPky48md
8ynMpFvWGrAezdFafWY/20BM4nQq3OAQVQpoXwe3tYP7RcMQsQcK69BHmO9b
AorV8CuNcYljhzLaj1jZR3mLleBIGcqwfiRtC350fgKmbDDkM4Ap2nLJPiTN
FD6YQocSI5YsB/7TlYYjqDg6dwPwRcxmSzTwlTgMBuq1wW/cOz8ZRbLNp2Hy
l40Hu2A1ZrqzfHb06MBgmnwpz+lwcxa5jw8il0htFzW51dwjlxCOr8zUQOUT
TxtN5xIh9GprO0F/TFkx8QiduwCXfioOMsj4fYIOcU61otBZTwAXikqPuA/7
HiU4yR7M4TDcpiOy2nScGduZPU+N3xd37WX2KtgBq5xiItnGi3t5KCqSz+hs
xyq3n7/+9VmACFrnO9Y6XyTLXVP9+3r2pfOqG86+mPrD2SjfZ9t1u6rPs4xU
PrFqCy3FuOS4cOXMdtfabBrBvIZgtwIyn1lwqPI01leKZLUsoEw+doPJx7W1
aiYBy/Os3nTzC0+u/McSuFCBvwlJG/NNybwZVf/eiQtLh6CDJfeLQCg3v5sq
I73l3ZQyAN7Kgu4ZiK+Wi/tF4jPzIrbuUe3al255pJ+RA4tL6IqVRak5C/Xj
thdUs29/WAlGqfND+wtcvP1R+wt8q8TRr+oIArPZpNxuY7YgepxWUcAfP9ot
OTozSjoKmlZbdXdfaa+wLCzWDH4FsjT65XFbzs0hWqH2Uq2bNledTb9eCNyu
eyhj6++Q+P0ztrtdm0ctYXZHqmZs/TzqltFIQdQun0kNN39cLlX3UcumuhP7
uKYD/p88WeC+8uikqu6xUjpGGSAlrG33mqbxgAx0KdNEG+rGV19qU9VsiWyq
PAdUOOhUoyt0uRX/YZhJqCmYz80LuAZ9PBNHnZKCKHbDDSqdpIsxywFJl9jO
jhEXcYkEb019l8ZZRJb2fgIFUtl5X1+wKKG8TjBl6Plc1ZYyIMDn5h/nzIOq
9Wu8r+2vmpR2YZgvpHVizYFn4mDILgNlslWvTxTrIcFtC8mrmPdltAKyVPs7
XjBzu1Lq9cVvemaPZXYayxnxc3cff5bfVH4uBJ4yNe+NZ4TiZdMmQdds10+c
uEyyoBIONHB405e3p92pgqNERZsdEgvn8VTXidHi6+02qphVHXjl7K/WYW9V
Zf45+7CfkIaoloTOqMtz93u61XjzN4K7mYenxPgNnVacXLd7LQrHip6N/NWi
V3fy3DF9pQ1cwgKbwln/BDW7s1dXJRYilO+O3lAPlcTWWlZzpRblY8AMdj6l
gR1F3MTiFGym33c2dZXRsjL0VkgKJWDRlmPxmuVYgtDWyqwJDu9ZaubmMmYa
hiVKD1plsszRobgZhDRzWZiVCLshzFfs+vjbakGminWbnY68FoEpR11YqkmH
q5FccOx/6r+2zdYoltIFWMr8rzwl639X9eTjtTaOdQCozU5nz2tzViI0dJ6V
8jK6O5tOXWilEoNaVdr4Tsa2J1stpLN8Csdq8RvMjemWZstuwGg5SGbXipXM
7VWKOZm/Wqkl7iGyeW6RmN05pWhUEQpj4oF5K+KhX6QY2loUhBJt3BJEa4ia
Wj3pWXcWV60W8+r2Ki/JGqN4LleAMmpcXKWc+YzrFo+ZIjjKEuYRnkOalWmY
0hI3k1nggvuc6Enrcrp4xqf16Ei+zpkHd2SpNq3tgrbZiVcLaYCk9CkJRr3D
Cuv1QMzEs1E2y70IvPp4N8MnB8/RIHX+Ek7GPJz6wSDLq19cjPLrS7sYc6vU
5n/+leq2/pWgCDpDr1hNYVcZer5TBEaG7xN1drVl/TJFOJ5estF5u42IpCWl
TkpNbix+VyOaI3PwuNRKawKo1rpW8FyxfuuBameHSN2MMlMJ21iPjmvaIwNm
nLxAXtGjApbespgqhbnDuEVM7i6HwPwCetcr+rJbDNw0i47ul4heEGP27YoZ
+jcI3xM18AsqXAvuXPv4i2J9EQH65yhRD4rxvVoxcIDrFlQagOfnS3J9VONL
1AS3F0TMLlOnyLdvwidGLpoSJqtLnufowqdU7qr6UJufMTjQO1Lt/HEZaie1
CY26lhWvIOpNgZM5Cb3N3idO/j9jRQLQp7dJ9GtgQBxj/hlDTsQjz4o+nQUZ
cv28p5+RcLPnXpEb5RZvOge4zCgV95zmZWotzbkonzO0lxi3ha+2gjXSv1pS
/vJBQduUqN5USDJdzBFHeahGwa1CKBakr/yQlD2ymkwiU4nuwu8V/9fNJH8N
zan1TJ98P3b2BSpti/aTLoikrPgZbo7Tr8uF7zfdgsplD70KOZce1F8U3h+k
8M7f2CHg+vzSPTmBnRRJu7yBJxpkt+WNF1R4r+t+i08vC1I53Z1uUNnZ2dZ0
gB3HJIzegGfwwUgZIEXwU8wZfhZLi3uh0qZgJw5uZ3dzon9vJtyFsxqzu4CX
1G9tBLpAtpTFWJ3oEANSi4xJ0DjVfPo8UUNH8kmpRUbGxM+FKv0H506NxPT5
KsuMlIcFm5GKICZinmFqg4YzQ9RkEmIexeqysmn+kLi/wP7kmJO3gHk6hxma
fQ0oysH54bfKr5rEPBFq47wVzfY3cEDsKksmUgUabD2oIl/tbOMeJjrXuTwu
Sp0QpXYsYPaD9kogQH0uXavEgTh85GoZxOts+nue9FEYdk+UXz2onWRV7U7q
smZM4gnOAQPI24zmuJ1V28k1EG5GftWhCYQu7ocynGHL2c1yVnerqXCGPoyW
xXRc56wBVVFp5JrF9ny/YG2iYxeYilRzOpNqRVYN5bQobUDaWVelhRyU0N1D
hOUK79FTIvCH0poos1ULCtRmPXXee9Bw4cmITTxEEP/vaAPh6rS2m6y719oK
aOkH9oP9duloNw1lpbcHttPaa7KtbmtrJ9TXZa3XegZrZ74n5ewDLzNZFAkS
4KfgmfiHeN7SwBTt2mpS+5NG9gejKBHrpJOl6eGuiBNob3/iAcMN+jWzkyXV
J2F4rOr+6ppmPTp6eRFEI06gqGOa++Xx3sC5/Q9Jeh+LgZJVgbYZ5jal+WUq
+pFGDSKKOx038ks17dWWc7WlfiquerKO3hJJvwYq2X1axAN13gINwrHq2Xlu
K8yhvZL56gzpbzhuR3mf5zxLm+yUJxE7jsc8/jBtgvr7qQAFlgnxgU6RGDVB
Y0r2dZTInshum+x6VCT3oEt+HBUcz1X/cSSSHmD7PMLvUS9lp0WTfStyeOeG
x7wA+HjWZFcCz+O7kuAvfGiyw5irgM9JFMthhL8wdTDCY03fcAnzGAAkb7IC
VuFI9DMuEgED52LI4c5VJsBxiQhwXPavQVHFIlPIugApsP51kU6jDXYIkJXn
LWmcUPF2CHEHfUEV8wOhfgkNlxXdRwr/gVujdvrgGLK4vcWjEwxdADuzHuiW
lcb/ATGRbpXMdgAA

-->

</rfc>
