<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-idr-bgp-ls-flex-algo-12" indexInclude="true" ipr="trust200902" number="9351" prepTime="2023-02-22T10:18:36" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9351" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="BGP-LS Extensions for Flexible Algorithm">Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement</title>
    <seriesInfo name="RFC" value="9351" stream="IETF"/>
    <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Peter Psenak" initials="P." surname="Psenak">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Slovakia</country>
        </postal>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>
    <author fullname="Shawn Zandi" initials="S" surname="Zandi">
      <organization showOnFrontPage="true">LinkedIn</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>United States of America</country>
        </postal>
        <email>szandi@linkedin.com</email>
      </address>
    </author>
    <author fullname="Gaurav Dawra" initials="G" surname="Dawra">
      <organization showOnFrontPage="true">LinkedIn</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>United States of America</country>
        </postal>
        <email>gdawra.ietf@gmail.com</email>
      </address>
    </author>
    <date month="02" year="2023"/>
    <area>rtg</area>
    <workgroup>idr</workgroup>
    <keyword>BGP-LS</keyword>
    <keyword>Segment Routing</keyword>
    <keyword>IS-IS</keyword>
    <keyword>OSPF</keyword>
    <keyword>OSPFv3</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">Flexible Algorithm is a solution that allows some routing protocols
      (e.g., OSPF and IS-IS) to compute paths over a network based on
      user-defined (and hence, flexible) constraints and metrics. The
      computation is performed by routers participating in the specific
      network in a distributed manner using a Flexible Algorithm Definition (FAD).
      This definition is provisioned on one or more routers and propagated
      through the network by OSPF and IS-IS flooding.</t>
      <t indent="0" pn="section-abstract-2">Border Gateway Protocol - Link State (BGP-LS) enables the collection of various
      topology information from the network. This document defines extensions to the
      BGP-LS address family to advertise the FAD as
      a part of the topology information from the network.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9351" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview-of-bgp-ls-extensio">Overview of BGP-LS Extensions for Flexible Algorithm</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flexible-algorithm-definiti">Flexible Algorithm Definition TLV</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flexible-algorithm-exclude-">Flexible Algorithm Exclude-Any Affinity Sub-TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flexible-algorithm-include-">Flexible Algorithm Include-Any Affinity Sub-TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flexible-algorithm-include-al">Flexible Algorithm Include-All Affinity Sub-TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flexible-algorithm-definition">Flexible Algorithm Definition Flags Sub-TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flexible-algorithm-exclude-s">Flexible Algorithm Exclude SRLG Sub-TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flexible-algorithm-unsuppor">Flexible Algorithm Unsupported Sub-TLV</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flexible-algorithm-prefix-m">Flexible Algorithm Prefix Metric TLV</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-manageability-consideration">Manageability Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="INTRO" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The classical IGP (e.g., OSPF and IS-IS) computation of best paths
      over the network is based on the IGP metric assigned to the links in the
      network. Many network deployments use solutions based on RSVP-TE <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/> or Segment Routing (SR) Policy <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> to enforce traffic over a path that is
      computed using different metrics or constraints than the shortest IGP
      path. <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/> defines the Flexible
      Algorithm solution that allows IGPs themselves to compute constraint-based paths over the
      network.</t>
      <t indent="0" pn="section-1-2">Flexible Algorithm is called so because it allows a user the
      flexibility to define:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-3">
        <li pn="section-1-3.1">the type of calculation to be used (e.g., shortest path),</li>
        <li pn="section-1-3.2">the metric type to be used (e.g., IGP metric or TE metric), and</li>
        <li pn="section-1-3.3">the set of constraints to be used (e.g., inclusion or exclusion
          of certain links using affinities).</li>
      </ul>
      <t indent="0" pn="section-1-4">The operations of the IGP Flexible Algorithm solution are described
      in detail in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</t>
      <t indent="0" pn="section-1-5">The BGP-LS extensions for SR are defined in <xref target="RFC9085" format="default" sectionFormat="of" derivedContent="RFC9085"/>
      and <xref target="I-D.ietf-idr-bgpls-srv6-ext" format="default" sectionFormat="of" derivedContent="IDR-BGPLS-SRV6-EXT"/> for SR-MPLS and Segment
      Routing over IPv6 (SRv6), respectively. They include the extensions for
      advertisement of SR information including various types of Segment
      Identifiers (SIDs) as below: </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-6">
        <li pn="section-1-6.1">SR Algorithm TLV to indicate the participation of a node in a
          Flexible Algorithm computation</li>
        <li pn="section-1-6.2">Prefix-SID TLV to indicate the association of the Prefix-SIDs to
          a specific Flexible Algorithm for SR-MPLS forwarding</li>
        <li pn="section-1-6.3">SRv6 Locator TLV to indicate the Locator for a specific Flexible
        Algorithm for SRv6 forwarding</li>
      </ul>
      <t indent="0" pn="section-1-7">This document defines extensions to BGP-LS for the advertisement of
      the Flexible Algorithm Definition (FAD) information to enable learning
      of the mapping of the Flexible Algorithm number to its definition in
      each area/domain of the underlying IGP. This definition indicates the
      type of computation used and the constraints for a given Flexible
      Algorithm. This information can then be used for setting up SR Policy
      paths end to end across domains by using the appropriate Flexible-Algorithm-specific
      SIDs in its segment list <xref target="RFC9256" format="default" sectionFormat="of" derivedContent="RFC9256"/>.
      For example, picking the Flexible Algorithm Prefix-SID (in case of
      SR-MPLS) or End SID (in case of SRv6) of Area Border Routers (ABRs) or
      Autonomous System Border Routers (ASBRs) corresponding to a definition
      that optimizes on the delay metric enables the building of an end-to-end
      low-latency path across IGP domains with minimal SIDs in the SID
      list.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.1-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
        "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
        "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP
        14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="FA" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-overview-of-bgp-ls-extensio">Overview of BGP-LS Extensions for Flexible Algorithm</name>
      <t indent="0" pn="section-2-1">BGP-LS <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/> specifies the Node Network Layer
      Reachability Information (NLRI) for the advertisement of nodes, along
      with their attributes using the BGP-LS Attribute; the Link NLRI for the
      advertisement of links, along with their attributes using the BGP-LS
      Attribute; and the Prefix NLRI for the advertisement of prefixes, along
      with their attributes using the BGP-LS Attribute.</t>
      <t indent="0" pn="section-2-2">The FADs advertised by a node are considered as a node-level
      attribute and advertised as specified in <xref target="FADTLV" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
      <t indent="0" pn="section-2-3">Various link attributes, like affinities and Shared Risk Link Group
      (SRLG), that are used during the Flexible Algorithm route calculations in
      IS-IS and OSPF are advertised in those protocols using the Application-Specific Link
      Attribute (ASLA) advertisements, as described in <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/>, <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/>, and <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>. The BGP-LS extensions for ASLA
      advertisements are specified in <xref target="RFC9294" format="default" sectionFormat="of" derivedContent="RFC9294"/>.</t>
      <t indent="0" pn="section-2-4">The Flexible Algorithm Prefix Metric (FAPM) is considered as a prefix
      attribute and advertised as specified in <xref target="FAMETRIC" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
    </section>
    <section anchor="FADTLV" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-flexible-algorithm-definiti">Flexible Algorithm Definition TLV</name>
      <t indent="0" pn="section-3-1">This document defines a new optional BGP-LS Attribute TLV associated
      with the Node NLRI called the "Flexible Algorithm Definition TLV" ("FAD TLV" for short),
      and its format is as follows:</t>
      <figure align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-flexible-algorithm-definitio">Flexible Algorithm Definition TLV </name>
        <artwork align="center" name="" type="" alt="" pn="section-3-2.1">
 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flex Algo   |   Metric-Type |   Calc-Type   |    Priority   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                sub-TLVs       ...                            //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      
</artwork>
      </figure>
      <dl newline="true" spacing="normal" indent="3" pn="section-3-3">
        <dt pn="section-3-3.1">where:</dt>
        <dd pn="section-3-3.2">
          <dl newline="false" spacing="normal" indent="3" pn="section-3-3.2.1">
            <dt pn="section-3-3.2.1.1">Type:</dt>
            <dd pn="section-3-3.2.1.2"> 1039</dd>
            <dt pn="section-3-3.2.1.3">Length:</dt>
            <dd pn="section-3-3.2.1.4"> The total length of the value field (including any
            sub-TLVs) in octets. The length value <bcp14>MUST</bcp14> be 4 or larger.</dd>
            <dt pn="section-3-3.2.1.5">Flexible Algorithm (Flex Algo):</dt>
            <dd pn="section-3-3.2.1.6"> Single octet value carrying the
            Flexible Algorithm number between 128 and 255 inclusive, as defined
            in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</dd>
            <dt pn="section-3-3.2.1.7">Metric-Type:</dt>
            <dd pn="section-3-3.2.1.8"> Single octet value carrying the metric type, as
            defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</dd>
            <dt pn="section-3-3.2.1.9">Calc-Type:</dt>
            <dd pn="section-3-3.2.1.10"> Single octet value carrying the calculation type, as
            defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</dd>
            <dt pn="section-3-3.2.1.11">Priority:</dt>
            <dd pn="section-3-3.2.1.12"> Single octet value carrying the priority of the FAD
            advertisement, as defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</dd>
            <dt pn="section-3-3.2.1.13">sub-TLVs:</dt>
            <dd pn="section-3-3.2.1.14"> Zero or more sub-TLVs may be included, as described
            further in this section.</dd>
          </dl>
        </dd>
      </dl>
      <t indent="0" pn="section-3-4">The FAD TLV that is advertised in the BGP-LS Attribute along with the
      Node NLRI of a node is derived from the following IGP protocol-specific
      advertisements:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-5">
        <li pn="section-3-5.1">in the case of IS-IS, from the IS-IS Flexible Algorithm
          Definition sub-TLV in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/></li>
        <li pn="section-3-5.2">in the case of OSPFv2/OSPFv3, from the OSPF Flexible Algorithm
          Definition TLV in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/></li>
      </ul>
      <t indent="0" pn="section-3-6">The BGP-LS Attribute associated with a Node NLRI may include one or
      more FAD TLVs corresponding to the FAD for each algorithm that the
      particular node is advertising.</t>
      <t indent="0" pn="section-3-7">The following subsections define sub-TLVs of the FAD TLV.</t>
      <section anchor="FADAFFINITYEXCLANY" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-flexible-algorithm-exclude-">Flexible Algorithm Exclude-Any Affinity Sub-TLV</name>
        <t indent="0" pn="section-3.1-1">The Flexible Algorithm Exclude-Any Affinity sub-TLV is an optional
        sub-TLV that is used to carry the affinity constraints associated with
        the FAD and enable the exclusion of links carrying any of the
        specified affinities from the computation of the specific algorithm, as
        described in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>. The affinity is
        expressed in terms of the Extended Admin Group (EAG), as defined in <xref target="RFC7308" format="default" sectionFormat="of" derivedContent="RFC7308"/>.</t>
        <t indent="0" pn="section-3.1-2">The sub-TLV has the following format:</t>
        <figure align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-flexible-algorithm-exclude-a">Flexible Algorithm Exclude-Any Affinity Sub-TLV</name>
          <artwork align="left" name="" type="" alt="" pn="section-3.1-3.1">
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Exclude-Any EAG (variable)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
</artwork>
        </figure>
        <dl newline="true" spacing="normal" indent="3" pn="section-3.1-4">
          <dt pn="section-3.1-4.1">where:</dt>
          <dd pn="section-3.1-4.2">
            <dl newline="false" indent="3" spacing="normal" pn="section-3.1-4.2.1">
              <dt pn="section-3.1-4.2.1.1">Type:</dt>
              <dd pn="section-3.1-4.2.1.2">1040</dd>
              <dt pn="section-3.1-4.2.1.3">Length:</dt>
              <dd pn="section-3.1-4.2.1.4">The total length of the value field in octets dependent
              on the size of the EAG. It <bcp14>MUST</bcp14> be a non-zero value and a multiple
              of 4.</dd>
              <dt pn="section-3.1-4.2.1.5">Exclude-Any EAG:</dt>
              <dd pn="section-3.1-4.2.1.6">The EAG value, as defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</dd>
            </dl>
          </dd>
        </dl>
        <t indent="0" pn="section-3.1-5">The information in the Flexible Algorithm Exclude-Any Affinity
        sub-TLV is derived from the IS-IS and OSPF protocol-specific Flexible
        Algorithm Exclude Admin Group sub-TLV, as defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</t>
      </section>
      <section anchor="FADAFFINITYINCLANY" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-flexible-algorithm-include-">Flexible Algorithm Include-Any Affinity Sub-TLV</name>
        <t indent="0" pn="section-3.2-1">The Flexible Algorithm Include-Any Affinity sub-TLV is an optional
        sub-TLV that is used to carry the affinity constraints associated with
        the FAD and enable the inclusion of links carrying any of the
        specified affinities in the computation of the specific algorithm, as
        described in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>. The affinity is
        expressed in terms of the EAG, as defined in <xref target="RFC7308" format="default" sectionFormat="of" derivedContent="RFC7308"/>.</t>
        <t indent="0" pn="section-3.2-2">The sub-TLV has the following format:</t>
        <figure align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-flexible-algorithm-include-a">Flexible Algorithm Include-Any Affinity Sub-TLV</name>
          <artwork align="left" name="" type="" alt="" pn="section-3.2-3.1">
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-Any EAG (variable)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
</artwork>
        </figure>
        <dl newline="true" spacing="normal" indent="3" pn="section-3.2-4">
          <dt pn="section-3.2-4.1">where:</dt>
          <dd pn="section-3.2-4.2">
            <dl newline="false" spacing="normal" indent="3" pn="section-3.2-4.2.1">
              <dt pn="section-3.2-4.2.1.1">Type:</dt>
              <dd pn="section-3.2-4.2.1.2">1041</dd>
              <dt pn="section-3.2-4.2.1.3">Length:</dt>
              <dd pn="section-3.2-4.2.1.4">The total length of the value field in octets dependent
              on the size of the EAG. It <bcp14>MUST</bcp14> be a non-zero value and a multiple
              of 4.</dd>
              <dt pn="section-3.2-4.2.1.5">Include-Any EAG:</dt>
              <dd pn="section-3.2-4.2.1.6">The EAG value, as defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</dd>
            </dl>
          </dd>
        </dl>
        <t indent="0" pn="section-3.2-5">The information in the Flexible Algorithm Include-Any Affinity
        sub-TLV is derived from the IS-IS and OSPF protocol-specific Flexible
        Algorithm Include-Any Admin Group sub-TLV, as defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</t>
      </section>
      <section anchor="FADAFFINITYINCLALL" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-flexible-algorithm-include-al">Flexible Algorithm Include-All Affinity Sub-TLV</name>
        <t indent="0" pn="section-3.3-1">The Flexible Algorithm Include-All Affinity sub-TLV is an optional
        sub-TLV that is used to carry the affinity constraints associated with
        the FAD and enable the inclusion of links carrying all of the
        specified affinities in the computation of the specific algorithm, as
        described in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>. The affinity is
        expressed in terms of the EAG, as defined in <xref target="RFC7308" format="default" sectionFormat="of" derivedContent="RFC7308"/>.</t>
        <t indent="0" pn="section-3.3-2">The sub-TLV has the following format:</t>
        <figure align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-flexible-algorithm-include-all">Flexible Algorithm Include-All Affinity Sub-TLV</name>
          <artwork align="left" name="" type="" alt="" pn="section-3.3-3.1">
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-All EAG (variable)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
</artwork>
        </figure>
        <dl newline="true" spacing="normal" indent="3" pn="section-3.3-4">
          <dt pn="section-3.3-4.1">where:</dt>
          <dd pn="section-3.3-4.2">
            <dl newline="false" spacing="normal" indent="3" pn="section-3.3-4.2.1">
              <dt pn="section-3.3-4.2.1.1">Type:</dt>
              <dd pn="section-3.3-4.2.1.2">1042</dd>
              <dt pn="section-3.3-4.2.1.3">Length:</dt>
              <dd pn="section-3.3-4.2.1.4">The total length of the value field in octets dependent
              on the size of the EAG. It <bcp14>MUST</bcp14> be a non-zero value and a multiple
              of 4.</dd>
              <dt pn="section-3.3-4.2.1.5">Include-All EAG:</dt>
              <dd pn="section-3.3-4.2.1.6">The EAG value, as defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</dd>
            </dl>
          </dd>
        </dl>
        <t indent="0" pn="section-3.3-5">The information in the Flexible Algorithm Include-All Affinity
        sub-TLV is derived from the IS-IS and OSPF protocol-specific Flexible
        Algorithm Include-All Admin Group sub-TLV, as defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</t>
      </section>
      <section anchor="FADFLAGS" numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-flexible-algorithm-definition">Flexible Algorithm Definition Flags Sub-TLV</name>
        <t indent="0" pn="section-3.4-1">The Flexible Algorithm Definition Flags sub-TLV is an optional
        sub-TLV that is used to carry the flags associated with the FAD that
        are used in the computation of the specific algorithm, as described in
        <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</t>
        <t indent="0" pn="section-3.4-2">The sub-TLV has the following format:</t>
        <figure align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-flexible-algorithm-definition-">Flexible Algorithm Definition Flags Sub-TLV</name>
          <artwork align="left" name="" type="" alt="" pn="section-3.4-3.1">
 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 (variable)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
</artwork>
        </figure>
        <dl newline="true" spacing="normal" indent="3" pn="section-3.4-4">
          <dt pn="section-3.4-4.1">where:</dt>
          <dd pn="section-3.4-4.2">
            <dl newline="false" spacing="normal" indent="3" pn="section-3.4-4.2.1">
              <dt pn="section-3.4-4.2.1.1">Type:</dt>
              <dd pn="section-3.4-4.2.1.2">1043</dd>
              <dt pn="section-3.4-4.2.1.3">Length:</dt>
              <dd pn="section-3.4-4.2.1.4">The total length of the value field in octets dependent
              on the size of the flags. It <bcp14>MUST</bcp14> be a non-zero value and a
              multiple of 4.</dd>
              <dt pn="section-3.4-4.2.1.5">Flags:</dt>
              <dd pn="section-3.4-4.2.1.6">The bitmask used to represent the flags for the FAD, as
              defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</dd>
            </dl>
          </dd>
        </dl>
        <t indent="0" pn="section-3.4-5">The information in the Flexible Algorithm Definition Flags sub-TLV
        is derived from the IS-IS and OSPF protocol-specific Flexible
        Algorithm Definition Flags sub-TLV, as defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</t>
      </section>
      <section anchor="FADSRLGEXCL" numbered="true" toc="include" removeInRFC="false" pn="section-3.5">
        <name slugifiedName="name-flexible-algorithm-exclude-s">Flexible Algorithm Exclude SRLG Sub-TLV</name>
        <t indent="0" pn="section-3.5-1">The Flexible Algorithm Exclude SRLG sub-TLV is an optional sub-TLV
        that is used to carry the Shared Risk Link Group (SRLG) information
        associated with the FAD and enable the exclusion of links that are
        associated with any of the specified SRLG in the computation of the
        specific algorithm, as described in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>. The SRLGs associated with a link
        are carried in the BGP-LS Shared Risk Link Group (TLV 1096) <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>.</t>
        <t indent="0" pn="section-3.5-2">The sub-TLV has the following format:</t>
        <figure align="left" suppress-title="false" pn="figure-6">
          <name slugifiedName="name-flexible-algorithm-exclude-sr">Flexible Algorithm Exclude SRLG Sub-TLV</name>
          <artwork align="left" name="" type="" alt="" pn="section-3.5-3.1">
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Shared Risk Link Group Values (variable)           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
</artwork>
        </figure>
        <dl newline="true" spacing="normal" indent="3" pn="section-3.5-4">
          <dt pn="section-3.5-4.1">where:</dt>
          <dd pn="section-3.5-4.2">
            <dl newline="false" spacing="normal" indent="3" pn="section-3.5-4.2.1">
              <dt pn="section-3.5-4.2.1.1">Type:</dt>
              <dd pn="section-3.5-4.2.1.2">1045</dd>
              <dt pn="section-3.5-4.2.1.3">Length:</dt>
              <dd pn="section-3.5-4.2.1.4">The total length of the value field in octets dependent
              on the number of SRLG values carried. It <bcp14>MUST</bcp14> be a non-zero value
              and a multiple of 4.</dd>
              <dt pn="section-3.5-4.2.1.5">Shared Risk Link Group Values:</dt>
              <dd pn="section-3.5-4.2.1.6">One or more SRLG values, each with a 
              size of 4 octets, as defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</dd>
            </dl>
          </dd>
        </dl>
        <t indent="0" pn="section-3.5-5">The information in the Flexible Algorithm Exclude SRLG sub-TLV is
        derived from the IS-IS and OSPF protocol-specific Flexible Algorithm
        Exclude SRLG sub-TLV, as defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</t>
      </section>
      <section anchor="FADUNK" numbered="true" toc="include" removeInRFC="false" pn="section-3.6">
        <name slugifiedName="name-flexible-algorithm-unsuppor">Flexible Algorithm Unsupported Sub-TLV</name>
        <t indent="0" pn="section-3.6-1">The OSPF and IS-IS signaling for FAD allows for extensions via new
        sub-TLVs under the respective IGP's Flexible Algorithm Definition TLV.
        As specified in <xref target="RFC9350" format="default" sectionFormat="of" section="5.3" derivedLink="https://rfc-editor.org/rfc/rfc9350#section-5.3" derivedContent="RFC9350"/>, it is important that the entire FAD
        be understood by anyone using it for computation purposes. Therefore,
        the FAD is different from most other protocol extensions, where the
        skipping or ignoring of unsupported sub-TLV information does not
        affect the base behavior.</t>
        <t indent="0" pn="section-3.6-2">The Flexible Algorithm Unsupported sub-TLV is an optional sub-TLV
        that is used to indicate the presence of unsupported FAD sub-TLVs. The
        need for this sub-TLV arises when the BGP-LS implementation on the
        advertising node does not support one or more of the FAD sub-TLVs
        present in the IGP advertisement.</t>
        <t indent="0" pn="section-3.6-3">The sub-TLV has the following format:</t>
        <figure align="left" suppress-title="false" pn="figure-7">
          <name slugifiedName="name-flexible-algorithm-unsupport">Flexible Algorithm Unsupported Sub-TLV</name>
          <artwork align="left" name="" type="" alt="" pn="section-3.6-4.1">
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol-ID  | sub-TLV types (variable) ...                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
</artwork>
        </figure>
        <dl newline="true" spacing="normal" indent="3" pn="section-3.6-5">
          <dt pn="section-3.6-5.1">where:</dt>
          <dd pn="section-3.6-5.2">
            <dl newline="false" spacing="normal" indent="3" pn="section-3.6-5.2.1">
              <dt pn="section-3.6-5.2.1.1">Type:</dt>
              <dd pn="section-3.6-5.2.1.2">1046</dd>
              <dt pn="section-3.6-5.2.1.3">Length:</dt>
              <dd pn="section-3.6-5.2.1.4"> The total length of the value field in octets
            (including any included sub-TLV types).</dd>
              <dt pn="section-3.6-5.2.1.5">Protocol-ID:</dt>
              <dd pn="section-3.6-5.2.1.6"> Indicates the BGP-LS Protocol-ID of the protocol
            from which the FAD is being advertised via BGP-LS. The values are
            from the IANA "BGP-LS Protocol-IDs" subregistry 
            under the "Border Gateway Protocol - Link State (BGP-LS) Parameters"
	    registry <eref target="https://www.iana.org/assignments/bgp-ls-parameters/" brackets="angle"/>.</dd>
              <dt pn="section-3.6-5.2.1.7">sub-TLV types:</dt>
              <dd pn="section-3.6-5.2.1.8"> Zero or more sub-TLV types that are not
            supported by the node originating the BGP-LS advertisement. The
            size of each sub-TLV type depends on the protocol indicated by the
            Protocol-ID field. For example, for IS-IS, each sub-TLV type would
            be 1 octet in size, while for OSPF, each sub-TLV type would be 2 octets
            in size.</dd>
            </dl>
          </dd>
        </dl>
        <t indent="0" pn="section-3.6-6">The node originating the advertisement <bcp14>MUST</bcp14> include the Flexible
        Algorithm Unsupported sub-TLV when it comes across an unsupported
        sub-TLV in the corresponding FAD in the IS-IS and OSPF advertisement.
        When advertising the Flexible Algorithm Unsupported sub-TLV, the
        protocol-specific sub-TLV types that are not supported <bcp14>SHOULD</bcp14> be
        included. This information serves as a diagnostic aid.</t>
        <t indent="0" pn="section-3.6-7">The discussion on the use of the FAD information by the consumers
        of the BGP-LS information is beyond the scope of this document.
        However, it is <bcp14>RECOMMENDED</bcp14> that the choice of the node used for
        originating the IGP topology information into BGP-LS be made such that
        the advertising node supports all the FAD extensions in use in its
        part of the network. This avoids the scenario where an incomplete FAD
        gets advertised via BGP-LS.</t>
      </section>
    </section>
    <section anchor="FAMETRIC" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-flexible-algorithm-prefix-m">Flexible Algorithm Prefix Metric TLV</name>
      <t indent="0" pn="section-4-1">This document defines a new optional BGP-LS Attribute TLV associated
      with the Prefix NLRI called the "Flexible Algorithm Prefix Metric TLV
      ("FAPM TLV" for short), and its format is as follows:</t>
      <figure align="left" suppress-title="false" pn="figure-8">
        <name slugifiedName="name-flexible-algorithm-prefix-me">Flexible Algorithm Prefix Metric TLV</name>
        <artwork align="left" name="" type="" alt="" pn="section-4-2.1"> 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flex Algo   |     Flags     |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Metric                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
      </figure>
      <dl newline="true" spacing="normal" indent="3" pn="section-4-3">
        <dt pn="section-4-3.1">where:</dt>
        <dd pn="section-4-3.2">
          <dl newline="false" spacing="normal" indent="3" pn="section-4-3.2.1">
            <dt pn="section-4-3.2.1.1">Type:</dt>
            <dd pn="section-4-3.2.1.2">1044</dd>
            <dt pn="section-4-3.2.1.3">Length:</dt>
            <dd pn="section-4-3.2.1.4">8 octets</dd>
            <dt pn="section-4-3.2.1.5">Flexible Algorithm (Flex Algo):</dt>
            <dd pn="section-4-3.2.1.6">Single octet value carrying the
            Flexible Algorithm number between 128 and 255 inclusive, as defined
            in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</dd>
            <dt pn="section-4-3.2.1.7">Flags:</dt>
            <dd pn="section-4-3.2.1.8">Single octet value and only applicable for OSPF, as defined
            in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>. The value <bcp14>MUST</bcp14> be set
	    to 0 for IS-IS.</dd>
            <dt pn="section-4-3.2.1.9">Reserved:</dt>
            <dd pn="section-4-3.2.1.10">2-octet value that <bcp14>MUST</bcp14> be set to 0 by the
	    originator and <bcp14>MUST</bcp14> be ignored by the receiver.</dd>
            <dt pn="section-4-3.2.1.11">Metric:</dt>
            <dd pn="section-4-3.2.1.12">4-octet field to carry the metric information.</dd>
          </dl>
        </dd>
      </dl>
      <t indent="0" pn="section-4-4">The FAPM TLV that is advertised in the BGP-LS Attribute along with
      the Prefix NLRI from a node is derived from the following IGP
      protocol-specific advertisements:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5">
        <li pn="section-4-5.1">in the case of IS-IS, from the IS-IS Flexible Algorithm Prefix
        Metric sub-TLV in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/></li>
        <li pn="section-4-5.2">in the case of OSPFv2/OSPFv3, from the OSPF Flexible Algorithm
        Prefix Metric sub-TLV in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/></li>
      </ul>
      <t indent="0" pn="section-4-6">The BGP-LS Attribute associated with a Prefix NLRI may include one or
      more FAPM TLVs corresponding to the Flexible Algorithm Prefix Metric for
      each algorithm associated with that particular prefix.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">IANA has allocated code points in the "BGP-LS Node
      Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry
      <eref target="https://www.iana.org/assignments/bgp-ls-parameters" brackets="angle"/>
      based on the table below for the TLVs/sub-TLVs introduced by this
      document.</t>
      <table anchor="algorithm" align="center" pn="table-1">
        <name slugifiedName="name-flexible-algorithm-code-poi">Flexible Algorithm Code Points</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">TLV Code Point</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">1039</td>
            <td align="left" colspan="1" rowspan="1">Flexible Algorithm Definition</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1040</td>
            <td align="left" colspan="1" rowspan="1">Flexible Algorithm Exclude-Any Affinity</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1041</td>
            <td align="left" colspan="1" rowspan="1">Flexible Algorithm Include-Any Affinity</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1042</td>
            <td align="left" colspan="1" rowspan="1">Flexible Algorithm Include-All Affinity</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1043</td>
            <td align="left" colspan="1" rowspan="1">Flexible Algorithm Definition Flags</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1044</td>
            <td align="left" colspan="1" rowspan="1">Flexible Algorithm Prefix Metric</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1045</td>
            <td align="left" colspan="1" rowspan="1">Flexible Algorithm Exclude SRLG</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1046</td>
            <td align="left" colspan="1" rowspan="1">Flexible Algorithm Unsupported</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Manageability" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <t indent="0" pn="section-6-1">The new protocol extensions introduced in this document augment the
      existing IGP topology information that can be distributed via <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>. Procedures and protocol extensions defined in this
      document do not affect the BGP protocol operations and management other
      than what is discussed in the "Manageability Considerations" section of <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>. Specifically, the malformed NLRIs attribute tests in
      the "Fault Management" section of <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/> now encompass
      the new TLVs for the BGP-LS NLRI in this document.</t>
      <t indent="0" pn="section-6-2">The extensions specified in this document do not specify any new
      configuration or monitoring aspects in BGP or BGP-LS. The specification
      of BGP models is an ongoing work based on <xref target="I-D.ietf-idr-bgp-model" format="default" sectionFormat="of" derivedContent="IDR-BGP-MODEL"/>.</t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">Security considerations for acquiring and distributing BGP-LS
      information are discussed in <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>.</t>
      <t indent="0" pn="section-7-2">The TLVs introduced in this document are used to propagate the IGP
      Flexible Algorithm extensions defined in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>. It is assumed that the IGP instances
      originating these TLVs will support all the required security (as
      described in <xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>) for Flexible
      Algorithm deployment.</t>
      <t indent="0" pn="section-7-3">This document specifies extensions for the advertisement of node and
      prefix-related Flexible Algorithm information. Tampering with this
      Flexible-Algorithm-related information may affect applications using it,
      including impacting route calculation and programming. As the
      advertisements defined in this document are related to a specific
      Flexible Algorithm topology, the impact of tampering is similarly
      limited in scope.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-idr-bgpls-srv6-ext" to="IDR-BGPLS-SRV6-EXT"/>
    <displayreference target="I-D.ietf-idr-bgp-model" to="IDR-BGP-MODEL"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <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 indent="0">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="RFC7308" target="https://www.rfc-editor.org/info/rfc7308" quoteTitle="true" derivedAnchor="RFC7308">
          <front>
            <title>Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)</title>
            <author fullname="E. Osborne" initials="E." surname="Osborne"/>
            <date month="July" year="2014"/>
            <abstract>
              <t indent="0">MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).</t>
              <t indent="0">This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7308"/>
          <seriesInfo name="DOI" value="10.17487/RFC7308"/>
        </reference>
        <reference anchor="RFC7752" target="https://www.rfc-editor.org/info/rfc7752" quoteTitle="true" derivedAnchor="RFC7752">
          <front>
            <title>North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP</title>
            <author fullname="H. Gredler" initials="H." role="editor" surname="Gredler"/>
            <author fullname="J. Medved" initials="J." surname="Medved"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="S. Ray" initials="S." surname="Ray"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">In a number of environments, a component external to a network is called upon to perform computations based on the network topology and 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 indent="0">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 new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.</t>
              <t indent="0">Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7752"/>
          <seriesInfo name="DOI" value="10.17487/RFC7752"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <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 indent="0">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="RFC9350" target="https://www.rfc-editor.org/info/rfc9350" quoteTitle="true" derivedAnchor="RFC9350">
          <front>
            <title>IGP Flexible Algorithm</title>
            <author initials="P" surname="Psenak" fullname="Peter Psenak" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Hegde" fullname="Shraddha Hegde">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K" surname="Talaulikar" fullname="Ketan Talaulikar">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A" surname="Gulko" fullname="Arkadiy Gulko">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2023" month="February"/>
          </front>
          <seriesInfo name="RFC" value="9350"/>
          <seriesInfo name="DOI" value="10.17487/RFC9350"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-idr-bgp-model" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-15" quoteTitle="true" derivedAnchor="IDR-BGP-MODEL">
          <front>
            <title>BGP YANG Model for Service Provider Networks</title>
            <author initials="M." surname="Jethanandani" fullname="Mahesh Jethanandani">
              <organization showOnFrontPage="true">Kloud Services</organization>
            </author>
            <author initials="K." surname="Patel" fullname="Keyur Patel">
              <organization showOnFrontPage="true">Arrcus</organization>
            </author>
            <author initials="S." surname="Hares" fullname="Susan Hares">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author initials="J." surname="Haas" fullname="Jeffrey Haas">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <date month="October" day="13" year="2022"/>
            <abstract>
              <t indent="0">   This document defines a YANG data model for configuring and managing
   BGP, including protocol, policy, and operational aspects, such as
   RIB, based on data center, carrier, and content provider operational
   requirements.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-model-15"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-idr-bgpls-srv6-ext" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-13" derivedAnchor="IDR-BGPLS-SRV6-EXT">
          <front>
            <title>BGP Link State Extensions for SRv6</title>
            <author initials="G" surname="Dawra" fullname="Gaurav Dawra">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K" surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Chen" fullname="Mach Chen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D" surname="Bernier" fullname="Daniel Bernier">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B" surname="Decraene" fullname="Bruno Decraene">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" day="14" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgpls-srv6-ext-13"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-srv6-ext-13.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3209" quoteTitle="true" derivedAnchor="RFC3209">
          <front>
            <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
            <author fullname="D. Awduche" initials="D." surname="Awduche"/>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <author fullname="D. Gan" initials="D." surname="Gan"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="V. Srinivasan" initials="V." surname="Srinivasan"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <date month="December" year="2001"/>
            <abstract>
              <t indent="0">This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).  Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels.  A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3209"/>
          <seriesInfo name="DOI" value="10.17487/RFC3209"/>
        </reference>
        <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" quoteTitle="true" derivedAnchor="RFC8402">
          <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 indent="0">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 indent="0">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 indent="0">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="RFC8919" target="https://www.rfc-editor.org/info/rfc8919" quoteTitle="true" derivedAnchor="RFC8919">
          <front>
            <title>IS-IS Application-Specific Link Attributes</title>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <date month="October" year="2020"/>
            <abstract>
              <t indent="0">Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments.  Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined.  In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link.  This document introduces new link attribute advertisements that address both of these shortcomings.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8919"/>
          <seriesInfo name="DOI" value="10.17487/RFC8919"/>
        </reference>
        <reference anchor="RFC8920" target="https://www.rfc-editor.org/info/rfc8920" quoteTitle="true" derivedAnchor="RFC8920">
          <front>
            <title>OSPF Application-Specific Link Attributes</title>
            <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <date month="October" year="2020"/>
            <abstract>
              <t indent="0">Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments.  Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined.  In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link.  This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8920"/>
          <seriesInfo name="DOI" value="10.17487/RFC8920"/>
        </reference>
        <reference anchor="RFC9085" target="https://www.rfc-editor.org/info/rfc9085" quoteTitle="true" derivedAnchor="RFC9085">
          <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 indent="0">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 indent="0">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="RFC9256" target="https://www.rfc-editor.org/info/rfc9256" quoteTitle="true" derivedAnchor="RFC9256">
          <front>
            <title>Segment Routing Policy Architecture</title>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="A. Bogdanov" initials="A." surname="Bogdanov"/>
            <author fullname="P. Mattes" initials="P." surname="Mattes"/>
            <date month="July" year="2022"/>
            <abstract>
              <t indent="0">Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.</t>
              <t indent="0">This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9256"/>
          <seriesInfo name="DOI" value="10.17487/RFC9256"/>
        </reference>
        <reference anchor="RFC9294" target="https://www.rfc-editor.org/info/rfc9294" quoteTitle="true" derivedAnchor="RFC9294">
          <front>
            <title>Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS)</title>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">Extensions have been defined for link-state routing protocols that enable distribution of application-specific link attributes for existing as well as newer applications such as Segment Routing (SR).  This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) to enable the advertisement of these application-specific attributes as a part of the topology information from the network.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9294"/>
          <seriesInfo name="DOI" value="10.17487/RFC9294"/>
        </reference>
      </references>
    </references>
    <section anchor="ACK" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Les Ginsberg"/>, <contact fullname="Amalesh Maity"/>, <contact fullname="Y. F. Siu"/>,
      <contact fullname="Vijay Gurbani"/>, and <contact fullname="Donald Eastlake 3rd"/> for
      their reviews and contributions to this work. The authors would like to thank <contact fullname="Jie Dong"/> for his shepherd review. The authors would like to thank <contact fullname="Alvaro Retana"/> for his detailed AD review and suggestions for improving this
      document.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country>India</country>
          </postal>
          <email>ketant.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Peter Psenak" initials="P." surname="Psenak">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country>Slovakia</country>
          </postal>
          <email>ppsenak@cisco.com</email>
        </address>
      </author>
      <author fullname="Shawn Zandi" initials="S" surname="Zandi">
        <organization showOnFrontPage="true">LinkedIn</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country>United States of America</country>
          </postal>
          <email>szandi@linkedin.com</email>
        </address>
      </author>
      <author fullname="Gaurav Dawra" initials="G" surname="Dawra">
        <organization showOnFrontPage="true">LinkedIn</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country>United States of America</country>
          </postal>
          <email>gdawra.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
