<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" ipr="trust200902" docName="draft-ietf-lsr-ospf-admin-tags-29" number="9825" consensus="true" updates="" obsoletes="" submissionType="IETF" symRefs="true" sortRefs="true" xml:lang="en" tocInclude="true" prepTime="2025-07-31T10:26:00" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags-29" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9825" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="OSPF Administrative Tags">Extensions to OSPF for Advertising Prefix Administrative Tags</title>
    <seriesInfo name="RFC" value="9825" stream="IETF"/>
    <author initials="A." surname="Lindem" fullname="Acee Lindem" role="editor">
      <organization showOnFrontPage="true">LabN Consulting, L.L.C.</organization>
      <address>
        <postal>
          <street>301 Midenhall Way</street>
          <city>Cary</city>
          <region>NC</region>
          <country>United States of America</country>
          <code>27513</code>
        </postal>
        <email>acee.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="P." surname="Psenak" fullname="Peter Psenak">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <street>Apollo Business Center</street>
          <street>Mlynske nivy 43</street>
          <city>Bratislava</city>
          <code>821 09</code>
          <country>Slovakia</country>
        </postal>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>
    <author fullname="Yingzhen Qu" initials="Y" surname="Qu">
      <organization showOnFrontPage="true">Futurewei Technologies</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>
          <country>United States of America</country>
        </postal>
        <email>yingzhen.ietf@gmail.com</email>
      </address>
    </author>
    <date month="07" year="2025"/>
    <area>RTG</area>
    <workgroup>lsr</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">It is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to
   associate tags with prefixes.
   Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous
   System (AS) External and Not-So-Stubby-Area (NSSA) prefixes.
   With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement
   and OSPFv3 Extended Link State Advertisements (LSAs), multiple administrative
   tags may be advertised for all types of prefixes. These administrative
   tags can be used for many applications including route redistribution policy, selective
   prefix prioritization, selective IP Fast Reroute (IPFRR) prefix protection, and many
   others.</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/rfc9825" 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) 2025 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-administrative-tag-sub-tlv">Administrative Tag Sub-TLV</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-administrative-tag-applicab">Administrative Tag Applicability</xref></t>
          </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-protocol-operation">Protocol Operation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-equal-cost-multipath-applic">Equal-Cost Multipath Applicability</xref></t>
              </li>
            </ul>
          </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-bgp-ls-advertisement">BGP-LS Advertisement</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-management-considerations">Management 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-yang-data-model">YANG Data Model</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tree-for-the-yang-data-mode">Tree for the YANG Data Model</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-yang-data-model-for-ospf-pr">YANG Data Model for OSPF Prefix Administrative Tags</xref></t>
              </li>
            </ul>
          </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-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <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.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.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 numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
    It is useful for routers in OSPFv2 <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>
    and OSPFv3 <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/> routing domains to be able to associate tags with prefixes.
    Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous System (AS)
    External and Not-So-Stubby-Area (NSSA) prefixes.
    With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement
    <xref target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/> and OSPFv3 Extended Link State Advertisement (LSA) <xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC8362"/>,
    multiple administrative tags may be advertised for all types of prefixes. These administrative
    tags can be used in many applications including (but not limited to):
      </t>
      <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-1-2">
   <li pn="section-1-2.1" derivedCounter="1.">Controlling which routes are redistributed into other protocols for
       re-advertisement.</li>
        <li pn="section-1-2.2" derivedCounter="2.">Prioritizing selected prefixes for faster convergence and installation in the
      forwarding plane.</li>
        <li pn="section-1-2.3" derivedCounter="3.">Identifying selected prefixes for Loop-Free Alternative (LFA) protection.</li>
      </ol>
      <t indent="0" pn="section-1-3">Throughout this document, "OSPF" is used when the text applies to both
   OSPFv2 and OSPFv3.  "OSPFv2" or "OSPFv3" is used when the text is
   specific to one version of the OSPF protocol.</t>
      <t indent="0" pn="section-1-4">The definition of the 64-bit tag was considered but discarded, given that
     there is no strong requirement or use case.</t>
      <t indent="0" pn="section-1-5">The IS-IS protocol supports a similar mechanism that is described in
  <xref target="RFC5130" format="default" sectionFormat="of" derivedContent="RFC5130"/>.</t>
      <section numbered="true" removeInRFC="false" toc="include" 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="UINT32-TAG" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-administrative-tag-sub-tlv">Administrative Tag Sub-TLV</name>
      <t indent="0" pn="section-2-1">This document creates a new Administrative Tag Sub-TLV for OSPFv2 and
   OSPFv3. This sub-TLV specifies one or
   more 32-bit unsigned integers that may be associated with an
   OSPF advertised prefix. The precise usage of these tags is beyond
   the scope of this document.</t>
      <t indent="0" pn="section-2-2">
      The format of the Administrative Tag Sub-TLV is as follows:
      </t>
      <figure align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-administrative-tag-sub-tlv-2">Administrative Tag Sub-TLV</name>
        <artwork align="left" pn="section-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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             First Administrative Tag                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             o                                 |
                                 o
   |                             o                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Last Administrative Tag                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
      </figure>
      <dl spacing="normal" newline="false" indent="3" pn="section-2-4">
        <dt pn="section-2-4.1">Type:</dt>
        <dd pn="section-2-4.2">
          <t indent="0" pn="section-2-4.2.1">A 16-bit field set to:</t>
          <dl spacing="normal" newline="false" indent="3" pn="section-2-4.2.2">
            <dt pn="section-2-4.2.2.1">13:</dt>
            <dd pn="section-2-4.2.2.2">"OSPFv2 Extended Prefix TLV Sub-TLVs" registry</dd>
            <dt pn="section-2-4.2.2.3">39:</dt>
            <dd pn="section-2-4.2.2.4">"OSPFv3 Extended-LSA Sub-TLVs" registry</dd>
            <dt pn="section-2-4.2.2.5">6:</dt>
            <dd pn="section-2-4.2.2.6">"OSPFv3 SRv6 Locator LSA Sub-TLVs" registry</dd>
          </dl>
        </dd>
        <dt pn="section-2-4.3">Length:</dt>
        <dd pn="section-2-4.4">A 16-bit field that indicates the length of the value
  portion in octets and <bcp14>MUST</bcp14> be a multiple of 4 octets
  dependent on the number of administrative tags
  advertised. At least one administrative tag <bcp14>MUST</bcp14> be
  advertised.</dd>
        <dt pn="section-2-4.5">Value:</dt>
        <dd pn="section-2-4.6">A variable length list of one or more administrative
  tags.</dd>
      </dl>
      <t indent="0" pn="section-2-5">
    This sub-TLV will carry one or more 32-bit unsigned integer values
    that will be used as administrative tags. If the length is 0 or not
    a multiple of 4 octets, the sub-TLV <bcp14>MUST</bcp14> be ignored, and the reception
    <bcp14>SHOULD</bcp14> be logged for further analysis (subject to rate-limiting).
      </t>
    </section>
    <section anchor="APPLICABILTY" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-administrative-tag-applicab">Administrative Tag Applicability</name>
      <t indent="0" pn="section-3-1">
    The Administrative Tag Sub-TLV specified herein will be valid as a sub-TLV of
    the following TLVs specified in <xref target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/>:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-2">
        <li pn="section-3-2.1">Extended Prefix TLV advertised in the OSPFv2 Extended Prefix Opaque LSA</li>
      </ul>
      <t indent="0" pn="section-3-3">
    The Administrative Tag Sub-TLV specified herein will be valid as a sub-TLV of
    the following TLVs specified in <xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC8362"/>:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-4">
        <li pn="section-3-4.1">Inter-Area-Prefix TLV advertised in the E-Inter-Area-Prefix-LSA</li>
        <li pn="section-3-4.2">Intra-Area-Prefix TLV advertised in the E-Intra-Area-Prefix-LSA</li>
        <li pn="section-3-4.3">External-Prefix TLV advertised in the E-AS-External-LSA and the E-NSSA-LSA</li>
      </ul>
      <t indent="0" pn="section-3-5">
    The Administrative Tag Sub-TLV specified herein will be valid as a sub-TLV of
    the following TLVs specified in <xref target="RFC9513" format="default" sectionFormat="of" derivedContent="RFC9513"/>:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-6">
        <li pn="section-3-6.1">SRv6 Locator TLV advertised in the SRv6 Locator LSA</li>
      </ul>
    </section>
    <section anchor="OSPF-OPERATION" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-protocol-operation">Protocol Operation</name>
      <t indent="0" pn="section-4-1">An OSPF router supporting this specification <bcp14>MUST</bcp14> be able to advertise and interpret
  at least one tag for all types of prefixes. An OSPF router supporting this
  specification <bcp14>MAY</bcp14> be able to advertise prefixes with multiple tags and propagate prefixes
  with multiple tags between areas. The
  maximum tags that an implementation supports is a local matter depending upon supported
  applications using prefix tags.  Depending on the application, the number of tags supported
  by the OSPF routers in the OSPF routing domain may limit the deployment of that application.
      </t>
      <t indent="0" pn="section-4-2">
    When tags are advertised for AS External or NSSA LSA prefixes, the existing tag in
    the OSPFv2 and OSPFv3 AS-External-LSA and NSSA-LSA encodings <bcp14>MUST</bcp14> be utilized for
    the first tag. Additional tags <bcp14>MAY</bcp14> be advertised using the Administrative Tag
    Sub-TLV specified in this document. This will facilitate backward compatibility with
    implementations that do not support this specification.
      </t>
      <t indent="0" pn="section-4-3">
    An OSPF router supporting this specification <bcp14>SHOULD</bcp14> propagate administrative tags
    when acting as an Area Border Router (ABR) and when originating summary advertisements into other
    areas (unless inhibited by local policy (<xref target="MANAGE" format="default" sectionFormat="of" derivedContent="Section 6"/>)). Similarly, an OSPF
    router supporting this specification and acting as an ABR for a NSSA
    <bcp14>SHOULD</bcp14> propagate tags when translating NSSA routes to AS External
    advertisements <xref target="RFC3101" format="default" sectionFormat="of" derivedContent="RFC3101"/> (also subject to local
    policy (<xref target="MANAGE" format="default" sectionFormat="of" derivedContent="Section 6"/>)).
      </t>
      <t indent="0" pn="section-4-4">
    There is no implied meaning to the ordering of the tags that
    indicates a certain operation or set of operations need to be performed
    based on the order of the tags.  Each tag <bcp14>SHOULD</bcp14> be treated as an
    autonomous identifier that <bcp14>MAY</bcp14> be used in policy to perform a policy
    action.  Whether or not tag A precedes or succeeds, tag B <bcp14>SHOULD NOT</bcp14>
    change the meaning of the tags.
    The number of tags supported by an ABR <bcp14>MAY</bcp14> limit the number
    of tags that are propagated. When propagating multiple tags between areas as
    previously described, the order of the tags <bcp14>MUST</bcp14> be preserved so
    that implementations supporting fewer tags will have a consistent view
    across areas.
      </t>
      <t indent="0" pn="section-4-5">
    For configured area ranges, NSSA ranges, and configured aggregation of redistributed
    routes, tags from component routes <bcp14>SHOULD NOT</bcp14> be propagated to the summary. Implementations
    <bcp14>SHOULD</bcp14> provide a mechanism to configure multiple tags for area ranges, NSSA ranges, and
    redistributed route summaries.
      </t>
      <section anchor="ECMP" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-equal-cost-multipath-applic">Equal-Cost Multipath Applicability</name>
        <t indent="0" pn="section-4.1-1">
    When multiple LSAs contribute to an OSPF route, it is possible that these
    LSAs will all have different tags. In this situation, the OSPF ABR propagating the
    route to other areas with inter-area LSAs <bcp14>MUST</bcp14> associate
    the tags from one of the LSAs contributing a path and, if the implementation supports
    multiple tags, <bcp14>MAY</bcp14> associate tags from multiple contributing LSAs up to the maximum
    number of tags supported. It is <bcp14>RECOMMENDED</bcp14> that tags from LSAs are added to the path
    in ascending order of the LSA originator Router-ID.
        </t>
      </section>
    </section>
    <section anchor="BGP-LS" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-bgp-ls-advertisement">BGP-LS Advertisement</name>
      <t indent="0" pn="section-5-1">
    Border Gateway Protocol - Link State (BGP-LS) <xref target="RFC9552" format="default" sectionFormat="of" derivedContent="RFC9552"/> introduced the support for advertising
    administrative tags	associated with prefixes using the BGP-LS IGP Route
    Tag TLV (TLV 1153). This BGP-LS TLV is used to advertise the OSPF
    Administrative Tags specified in this document.
      </t>
    </section>
    <section anchor="MANAGE" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-management-considerations">Management Considerations</name>
      <t indent="0" pn="section-6-1">
    Implementations <bcp14>MAY</bcp14> include configuration of policies to modify the advertisement of
    tags for redistributed prefixes. Implementations <bcp14>MAY</bcp14> also include configuration of
    policies to modify the propagation of administrative tags between areas
    (OSPFv2 Extended Prefix Opaque LSAs,  OSPFv3 E-Inter-Area-Prefix-LSAs, and
    translated OSPFv3 E-AS-External-LSAs).
    However, the default behavior <bcp14>SHOULD</bcp14> be to advertise or propagate
    the lesser number of all the tags associated with the prefix or the maximum number of
    tags supported by the implementation.
      </t>
      <t indent="0" pn="section-6-2">
    Both the support of this specification and the number of tags supported
    by OSPF routers within an OSPF routing domain will limit the usefulness and
    deployment of applications utilizing tags.
      </t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-yang-data-model">YANG Data Model</name>
      <t indent="0" pn="section-7-1">
    YANG <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> is a data definition language
    used to define the contents of a conceptual data store
    that allows networked devices to be managed using Network Configuration Protocol (NETCONF)
    <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/> or RESTCONF <xref target="RFC8040" format="default" sectionFormat="of" derivedContent="RFC8040"/>.
      </t>
      <t indent="0" pn="section-7-2">
    This section defines a YANG data model that can be used to configure
    and manage the prefix administrative tags defined in this document,
    which augments the OSPF YANG data model <xref target="RFC9129" format="default" sectionFormat="of" derivedContent="RFC9129"/>,
    the OSPFv3 Extended LSA YANG data model <xref target="RFC9587" format="default" sectionFormat="of" derivedContent="RFC9587"/>,
    and the Routing Management YANG data model <xref target="RFC8349" format="default" sectionFormat="of" derivedContent="RFC8349"/>.
    Additionally, the YANG data models defined in <xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6991"/>
    are imported.
      </t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-tree-for-the-yang-data-mode">Tree for the YANG Data Model</name>
        <t indent="0" pn="section-7.1-1">This document uses the graphical representation of data models per
    <xref target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/>.</t>
        <t indent="0" pn="section-7.1-2">The following shows the tree diagram of the module:</t>
        <sourcecode type="yangtree" markers="false" pn="section-7.1-3">
module: ietf-ospf-admin-tags

  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
            /ospf:ranges/ospf:range:
    +--rw admin-tags
       +--rw admin-tag*   uint32
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
            /ospf:interfaces/ospf:interface:
    +--rw local-prefix-admin-tags
       +--rw default-admin-tag*           uint32
       +--rw specific-prefix-admin-tag* [prefix]
          +--rw prefix       inet:ip-prefix
          +--rw admin-tag*   uint32
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:local-rib
            /ospf:route/ospf:next-hops/ospf:next-hop:
    +--ro admin-tag*   uint32
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
            /ospf:interfaces/ospf:interface/ospf:database
            /ospf:link-scope-lsa-type/ospf:link-scope-lsas
            /ospf:link-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2
            /ospf:body/ospf:opaque/ospf:extended-prefix-opaque
            /ospf:extended-prefix-tlv:
    +--ro prefix-admin-tag-sub-tlv
       +--ro admin-tag*   uint32
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
            /ospf:database/ospf:area-scope-lsa-type
            /ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
            /ospf:ospfv2/ospf:ospfv2/ospf:body/ospf:opaque
            /ospf:extended-prefix-opaque/ospf:extended-prefix-tlv:
    +--ro prefix-admin-tag-sub-tlv
       +--ro admin-tag*   uint32
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:database
            /ospf:as-scope-lsa-type/ospf:as-scope-lsas
            /ospf:as-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2
            /ospf:body/ospf:opaque/ospf:extended-prefix-opaque
            /ospf:extended-prefix-tlv:
    +--ro prefix-admin-tag-sub-tlv
       +--ro admin-tag*   uint32
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
            /ospf:database/ospf:area-scope-lsa-type
            /ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
            /ospf:ospfv3/ospf:ospfv3/ospf:body
            /ospfv3-e-lsa:e-inter-area-prefix
            /ospfv3-e-lsa:e-inter-prefix-tlvs
            /ospfv3-e-lsa:inter-prefix-tlv:
    +--ro prefix-admin-tag-sub-tlv
       +--ro admin-tag*   uint32
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
            /ospf:database/ospf:area-scope-lsa-type
            /ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
            /ospf:ospfv3/ospf:ospfv3/ospf:body
            /ospfv3-e-lsa:e-intra-area-prefix
            /ospfv3-e-lsa:e-intra-prefix-tlvs
            /ospfv3-e-lsa:intra-prefix-tlv:
    +--ro prefix-admin-tag-sub-tlv
       +--ro admin-tag*   uint32
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:database
            /ospf:as-scope-lsa-type/ospf:as-scope-lsas
            /ospf:as-scope-lsa/ospf:version/ospf:ospfv3/ospf:ospfv3
            /ospf:body/ospfv3-e-lsa:e-as-external
            /ospfv3-e-lsa:e-external-tlvs
            /ospfv3-e-lsa:external-prefix-tlv:
    +--ro prefix-admin-tag-sub-tlv
       +--ro admin-tag*   uint32
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
            /ospf:database/ospf:area-scope-lsa-type
            /ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
            /ospf:ospfv3/ospf:ospfv3/ospf:body/ospfv3-e-lsa:e-nssa
            /ospfv3-e-lsa:e-external-tlvs
            /ospfv3-e-lsa:external-prefix-tlv:
    +--ro prefix-admin-tag-sub-tlv
       +--ro admin-tag*   uint32</sourcecode>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-yang-data-model-for-ospf-pr">YANG Data Model for OSPF Prefix Administrative Tags</name>
        <t indent="0" pn="section-7.2-1">The following is the YANG module:</t>
        <sourcecode name="ietf-ospf-admin-tags@2025-07-31.yang" type="yang" markers="true" pn="section-7.2-2">
module ietf-ospf-admin-tags {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags";
  prefix ospf-admin-tags;

  import ietf-routing {
    prefix rt;
    reference
      "RFC 8349: A YANG Data Model for Routing
       Management (NMDA Version)";
  }
  import ietf-ospf {
    prefix ospf;
    reference
      "RFC 9129: YANG Data Model for the OSPF Protocol";
  }
  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-ospfv3-extended-lsa {
    prefix ospfv3-e-lsa;
    reference
      "RFC 9587: YANG Data Model for OSPFv3 Extended Link
                 State Advertisements (LSAs)";
  }

  organization
    "IETF LSR - Link State Routing Working Group";
  contact
    "WG Web:   &lt;https://datatracker.ietf.org/wg/lsr/&gt;
     WG List:  &lt;mailto:lsr@ietf.org&gt;

     Author:   Yingzhen Qu
               &lt;mailto:yingzhen.ietf@gmail.com&gt;
     Author:   Acee Lindem
               &lt;mailto:acee.ietf@gmail.com&gt;
     Author:   Peter Psenak
               &lt;mailto:ppsenak@cisco.com&gt;";
  description
    "This YANG module defines the configuration
     and operational state for OSPF administrative tags.

     This YANG data model conforms to the Network Management
     Datastore Architecture (NMDA) as described in RFC 8342.

     Copyright (c) 2025 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC 9825;
     see the RFC itself for full legal notices.";
  reference
    "RFC 9825: Extensions to OSPF for Advertising Prefix
               Administrative Tags.";

  revision 2025-07-31 {
    description
      "Initial revision.";
    reference
      "RFC 9825: Extensions to OSPF for Advertising Prefix
                 Administrative Tags.";
  }

  grouping prefix-admin-tag-sub-tlv {
    description
      "Prefix Administrative Tag Sub-TLVs.";
    container prefix-admin-tag-sub-tlv {
      config false;
      description
        "Prefix Administrative Tag Sub-TLV.";
      leaf-list admin-tag {
        type uint32;
        description
          "Administrative tags.";
      }
    }
  }

  /* Configuration */

  augment "/rt:routing/rt:control-plane-protocols"
        + "/rt:control-plane-protocol/ospf:ospf"
        + "/ospf:areas/ospf:area/ospf:ranges/ospf:range" {
    when "derived-from-or-self(../../../../.."
       + "/rt:type, 'ospf:ospf')" {
      description
        "This augments the OSPF routing protocol area range
         configuration.";
    }
    description
      "This augments the OSPF protocol area range configuration
       with administrative tags.  The configured tags will be
       advertised with summary prefix when it is active.";
    container admin-tags {
      when "../ospf:advertise = 'true'";
      leaf-list admin-tag {
        type uint32;
        description
          "Administrative tags.";
      }
      description
        "OSPF prefix administrative tags.";
    }
  }

  augment "/rt:routing/rt:control-plane-protocols"
        + "/rt:control-plane-protocol/ospf:ospf"
        + "/ospf:areas/ospf:area/ospf:interfaces/ospf:interface" {
    when "derived-from-or-self(../../../../.."
       + "/rt:type, 'ospf:ospf')" {
      description
        "This augments the OSPF routing protocol interface
         configuration.";
    }
    description
      "This augments the OSPF protocol interface configuration
       with Administrative Tags.  The configured tags will be
       advertised with local prefixes configured for the interface.";
    container local-prefix-admin-tags {
      leaf-list default-admin-tag {
        type uint32;
        description
          "Administrative tags that will be associated with
           local prefixes if the prefix is not specified explicitly.
           If omitted, no administrative tags are associated with
           local prefixes by default.";
      }
      list specific-prefix-admin-tag {
        key "prefix";
        leaf prefix {
          type inet:ip-prefix;
          description
            "IPv4 or IPv6 prefix.";
        }
        leaf-list admin-tag {
          type uint32;
          description
            "Administrative tags that will be associated with
             the specified local prefix.  If omitted, no
             administrative tags are associated with the specified
             local prefix.";
        }
        description
          "Administrative tags that are explicitly associated with
           the specified prefix.";
      }
      description
        "List of administrative tags that are to be advertised
         with interface local prefixes.";
    }
  }

  /* Local-RIB */

  augment "/rt:routing"
        + "/rt:control-plane-protocols/rt:control-plane-protocol"
        + "/ospf:ospf/ospf:local-rib/ospf:route/ospf:next-hops"
        + "/ospf:next-hop" {
    description
      "This augments local-rib next-hop with administrative tags.";
    leaf-list admin-tag {
      type uint32;
      description
        "Administrative tags.";
    }
  }

  /* Database */

  augment "/rt:routing"
        + "/rt:control-plane-protocols/rt:control-plane-protocol"
        + "/ospf:ospf/ospf:areas/ospf:area"
        + "/ospf:interfaces/ospf:interface/ospf:database"
        + "/ospf:link-scope-lsa-type/ospf:link-scope-lsas"
        + "/ospf:link-scope-lsa/ospf:version/ospf:ospfv2"
        + "/ospf:ospfv2/ospf:body/ospf:opaque"
        + "/ospf:extended-prefix-opaque/ospf:extended-prefix-tlv" {
    when "derived-from-or-self(../../../../../../../../../.."
       + "/../../../../rt:type, 'ospf:ospfv2')" {
      description
        "This augmentation is only valid for OSPFv2.";
    }
    description
      "Prefix Administrative Tag Sub-TLVs for OSPFv2 extended prefix
       TLV in type 9 opaque LSA.";
    uses prefix-admin-tag-sub-tlv;
  }

  augment "/rt:routing"
        + "/rt:control-plane-protocols/rt:control-plane-protocol"
        + "/ospf:ospf/ospf:areas"
        + "/ospf:area/ospf:database"
        + "/ospf:area-scope-lsa-type/ospf:area-scope-lsas"
        + "/ospf:area-scope-lsa/ospf:version/ospf:ospfv2"
        + "/ospf:ospfv2/ospf:body/ospf:opaque"
        + "/ospf:extended-prefix-opaque/ospf:extended-prefix-tlv" {
    when "derived-from-or-self(../../../../../../../../../.."
       + "/../../rt:type, 'ospf:ospfv2')" {
      description
        "This augmentation is only valid for OSPFv2.";
    }
    description
      "Prefix Administrative Tag Sub-TLVs for OSPFv2 extended prefix
       TLV in type 10 opaque LSA.";
    uses prefix-admin-tag-sub-tlv;
  }

  augment "/rt:routing"
        + "/rt:control-plane-protocols/rt:control-plane-protocol"
        + "/ospf:ospf/ospf:database"
        + "/ospf:as-scope-lsa-type/ospf:as-scope-lsas"
        + "/ospf:as-scope-lsa/ospf:version/ospf:ospfv2"
        + "/ospf:ospfv2/ospf:body/ospf:opaque"
        + "/ospf:extended-prefix-opaque/ospf:extended-prefix-tlv" {
    when "derived-from-or-self(../../../../../../../.."
       + "/../../rt:type, 'ospf:ospfv2')" {
      description
        "This augmentation is only valid for OSPFv2.";
    }
    description
      "Prefix Administrative Tag Sub-TLVs for OSPFv2 extended prefix
       TLV in type 11 opaque LSA.";
    uses prefix-admin-tag-sub-tlv;
  }

  augment "/rt:routing"
        + "/rt:control-plane-protocols/rt:control-plane-protocol"
        + "/ospf:ospf/ospf:areas/ospf:area/ospf:database"
        + "/ospf:area-scope-lsa-type/ospf:area-scope-lsas"
        + "/ospf:area-scope-lsa/ospf:version/ospf:ospfv3"
        + "/ospf:ospfv3/ospf:body/ospfv3-e-lsa:e-inter-area-prefix"
        + "/ospfv3-e-lsa:e-inter-prefix-tlvs"
        + "/ospfv3-e-lsa:inter-prefix-tlv" {
    when "derived-from-or-self(../../../../../../../../../.."
       + "/../../rt:type, 'ospf:ospfv3')" {
      description
        "This augmentation is only valid for OSPFv3.";
    }
    description
      "Augment OSPFv3 Inter-Area-Prefix TLV in the
       E-Inter-Area-Prefix-LSA.";
    uses prefix-admin-tag-sub-tlv;
  }

  augment "/rt:routing"
        + "/rt:control-plane-protocols/rt:control-plane-protocol"
        + "/ospf:ospf/ospf:areas/ospf:area/ospf:database"
        + "/ospf:area-scope-lsa-type/ospf:area-scope-lsas"
        + "/ospf:area-scope-lsa/ospf:version/ospf:ospfv3"
        + "/ospf:ospfv3/ospf:body/ospfv3-e-lsa:e-intra-area-prefix"
        + "/ospfv3-e-lsa:e-intra-prefix-tlvs"
        + "/ospfv3-e-lsa:intra-prefix-tlv" {
    when "/rt:routing/rt:control-plane-protocols"
       + "/rt:control-plane-protocol/rt:type = 'ospf:ospfv3'" {
      description
        "This augmentation is only valid for OSPFv3.";
    }
    description
      "Augment OSPFv3 Intra-Area-Prefix TLV in the
       E-Intra-Area-Prefix-LSA.";
    uses prefix-admin-tag-sub-tlv;
  }

  augment "/rt:routing"
        + "/rt:control-plane-protocols/rt:control-plane-protocol"
        + "/ospf:ospf/ospf:database"
        + "/ospf:as-scope-lsa-type/ospf:as-scope-lsas"
        + "/ospf:as-scope-lsa/ospf:version/ospf:ospfv3"
        + "/ospf:ospfv3/ospf:body/ospfv3-e-lsa:e-as-external"
        + "/ospfv3-e-lsa:e-external-tlvs"
        + "/ospfv3-e-lsa:external-prefix-tlv" {
    when "derived-from-or-self(../../../../../../../.."
       + "/../../rt:type, 'ospf:ospfv3')" {
      description
        "This augmentation is only valid for OSPFv3.";
    }
    description
      "Augment OSPFv3 External-Prefix TLV in the E-AS-External-LSA.";
    uses prefix-admin-tag-sub-tlv;
  }

  augment "/rt:routing"
        + "/rt:control-plane-protocols/rt:control-plane-protocol"
        + "/ospf:ospf/ospf:areas/ospf:area/ospf:database"
        + "/ospf:area-scope-lsa-type/ospf:area-scope-lsas"
        + "/ospf:area-scope-lsa/ospf:version/ospf:ospfv3"
        + "/ospf:ospfv3/ospf:body/ospfv3-e-lsa:e-nssa"
        + "/ospfv3-e-lsa:e-external-tlvs"
        + "/ospfv3-e-lsa:external-prefix-tlv" {
    when "/rt:routing/rt:control-plane-protocols"
       + "/rt:control-plane-protocol/rt:type = 'ospf:ospfv3'" {
      description
        "This augmentation is only valid for OSPFv3.";
    }
    description
      "Augment OSPFv3 External-Prefix TLV in the E-NSSA-LSA.";
    uses prefix-admin-tag-sub-tlv;
  }
}</sourcecode>
      </section>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">
    This document describes a generic mechanism for advertising
    administrative tags for OSPF prefixes.
    The administrative tags are generally less critical
    than the topology information currently advertised by the base
    OSPF protocol.
    The security considerations for the generic mechanism are dependent
    on their application. One such application is to control leaking of OSPF
    routes to other protocols (e.g., BGP <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/>). If an attacker
    were able to modify
    the administrative tags associated with OSPF routes, and they were being used for this
    application, such routes could be prevented from being advertised in routing
    domains where they are required (subtle denial of service) or they could be
    advertised into routing domains where they shouldn't be advertised (routing
    vulnerability).
    Security considerations for the base OSPF protocol are covered
    in <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/> and <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>.
      </t>
      <t indent="0" pn="section-8-2">
     The "ietf-ospf-admin-tag" YANG module defines a data model that is
     designed to be accessed via YANG-based management protocols, such as
     NETCONF <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/> and RESTCONF <xref target="RFC8040" format="default" sectionFormat="of" derivedContent="RFC8040"/>.
     These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH
     <xref target="RFC4252" format="default" sectionFormat="of" derivedContent="RFC4252"/>, TLS <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>, and
     QUIC <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/>) and (2) have to use mutual authentication.  
      </t>
      <t indent="0" pn="section-8-3">
     The Network Configuration Access Control Model (NACM) <xref target="RFC8341" format="default" sectionFormat="of" derivedContent="RFC8341"/> provides the
     means to restrict access for particular NETCONF or RESTCONF users to a
     preconfigured subset of all available NETCONF or RESTCONF protocol
     operations and content.
      </t>
      <t indent="0" pn="section-8-4">
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-5">
        <li pn="section-8-5.1">/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/local-prefix-admin-tags</li>
        <li pn="section-8-5.2">/ospf:ospf/ospf:areas/ospf:area/ospf:ranges/ospf:range/admin-tags</li>
      </ul>
      <t indent="0" pn="section-8-6">Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments.  Thus, it is
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Exposure of the OSPF link state
database may be useful in mounting a Denial-of-Service (DoS) attack.
Specifically, the following subtrees and data nodes have particular
sensitivities:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-7">
        <li pn="section-8-7.1">/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/local-prefix-admin-tags</li>
        <li pn="section-8-7.2">/ospf:ospf/ospf:areas/ospf:area/ospf:ranges/ospf:range/admin-tags</li>
        <li pn="section-8-7.3">/prefix-admin-tag-sub-tlv</li>
      </ul>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">
    The following value has been allocated in the "OSPFv2 Extended Prefix TLV
    Sub-TLVs" registry <xref target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/> in the "Open Shortest Path First v2 (OSPFv2)
    Parameters" registry group:
      </t>
      <dl spacing="normal" newline="false" indent="3" pn="section-9-2">
        <dt pn="section-9-2.1">13:</dt>
        <dd pn="section-9-2.2">Administrative Tag</dd>
      </dl>
      <t indent="0" pn="section-9-3">
    The following value has been allocated in the "OSPFv3 Extended-LSA Sub-TLVs"
    registry <xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC8362"/> in the "Open Shortest Path First v3 (OSPFv3) Parameters"
    registry group:
      </t>
      <dl spacing="normal" newline="false" indent="3" pn="section-9-4">
        <dt pn="section-9-4.1">39:</dt>
        <dd pn="section-9-4.2">
          <t indent="0" pn="section-9-4.2.1">Administrative Tag</t>
          <t indent="0" pn="section-9-4.2.2">Since this sub-TLV only applies to prefixes and not links, the value of
    the Layer-2 Bundle Member (L2BM) field will be "X".</t>
        </dd>
      </dl>
      <t indent="0" pn="section-9-5">
    The following value has been allocated in the "OSPFv3 SRv6 Locator LSA
    Sub-TLVs" registry <xref target="RFC9513" format="default" sectionFormat="of" derivedContent="RFC9513"/> in the "Open Shortest Path First v3 (OSPFv3)
    Parameters" registry group:
      </t>
      <dl spacing="normal" newline="false" indent="3" pn="section-9-6">
        <dt pn="section-9-6.1">6:</dt>
        <dd pn="section-9-6.2">Administrative Tag</dd>
      </dl>
      <t indent="0" pn="section-9-7">IANA has assigned one new URI in the "IETF XML Registry"
  <xref target="RFC3688" format="default" sectionFormat="of" derivedContent="RFC3688"/>:</t>
      <dl spacing="compact" newline="false" indent="3" pn="section-9-8">
        <dt pn="section-9-8.1">URI:</dt>
        <dd pn="section-9-8.2">urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags</dd>
        <dt pn="section-9-8.3">Registrant Contact:</dt>
        <dd pn="section-9-8.4">The IESG.</dd>
        <dt pn="section-9-8.5">XML:</dt>
        <dd pn="section-9-8.6">N/A; the requested URI is an XML namespace.</dd>
      </dl>
      <t indent="0" pn="section-9-9"> This document also registers one new YANG module name in the "YANG Module
  Names" registry <xref target="RFC6020" format="default" sectionFormat="of" derivedContent="RFC6020"/> with the
  following:</t>
      <dl spacing="compact" newline="false" indent="3" pn="section-9-10">
        <dt pn="section-9-10.1">Name:</dt>
        <dd pn="section-9-10.2">ietf-ospf-admin-tags</dd>
        <dt pn="section-9-10.3">Namespace:</dt>
        <dd pn="section-9-10.4">urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags</dd>
        <dt pn="section-9-10.5">Prefix:</dt>
        <dd pn="section-9-10.6">ospf-admin-tags</dd>
        <dt pn="section-9-10.7">Reference:</dt>
        <dd pn="section-9-10.8">RFC 9825</dd>
      </dl>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.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="RFC2328" target="https://www.rfc-editor.org/info/rfc2328" quoteTitle="true" derivedAnchor="RFC2328">
          <front>
            <title>OSPF Version 2</title>
            <author fullname="J. Moy" initials="J." surname="Moy"/>
            <date month="April" year="1998"/>
            <abstract>
              <t indent="0">This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="54"/>
          <seriesInfo name="RFC" value="2328"/>
          <seriesInfo name="DOI" value="10.17487/RFC2328"/>
        </reference>
        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" quoteTitle="true" derivedAnchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t indent="0">This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC5340" target="https://www.rfc-editor.org/info/rfc5340" quoteTitle="true" derivedAnchor="RFC5340">
          <front>
            <title>OSPF for IPv6</title>
            <author fullname="R. Coltun" initials="R." surname="Coltun"/>
            <author fullname="D. Ferguson" initials="D." surname="Ferguson"/>
            <author fullname="J. Moy" initials="J." surname="Moy"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <date month="July" year="2008"/>
            <abstract>
              <t indent="0">This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).</t>
              <t indent="0">Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).</t>
              <t indent="0">Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.</t>
              <t indent="0">All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5340"/>
          <seriesInfo name="DOI" value="10.17487/RFC5340"/>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020" quoteTitle="true" derivedAnchor="RFC6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="October" year="2010"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
        <reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6991" quoteTitle="true" derivedAnchor="RFC6991">
          <front>
            <title>Common YANG Data Types</title>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <date month="July" year="2013"/>
            <abstract>
              <t indent="0">This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6991"/>
          <seriesInfo name="DOI" value="10.17487/RFC6991"/>
        </reference>
        <reference anchor="RFC7684" target="https://www.rfc-editor.org/info/rfc7684" quoteTitle="true" derivedAnchor="RFC7684">
          <front>
            <title>OSPFv2 Prefix/Link Attribute Advertisement</title>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <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"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <date month="November" year="2015"/>
            <abstract>
              <t indent="0">OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7684"/>
          <seriesInfo name="DOI" value="10.17487/RFC7684"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" quoteTitle="true" derivedAnchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </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="RFC8341" target="https://www.rfc-editor.org/info/rfc8341" quoteTitle="true" derivedAnchor="RFC8341">
          <front>
            <title>Network Configuration Access Control Model</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
              <t indent="0">This document obsoletes RFC 6536.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="91"/>
          <seriesInfo name="RFC" value="8341"/>
          <seriesInfo name="DOI" value="10.17487/RFC8341"/>
        </reference>
        <reference anchor="RFC8349" target="https://www.rfc-editor.org/info/rfc8349" quoteTitle="true" derivedAnchor="RFC8349">
          <front>
            <title>A YANG Data Model for Routing Management (NMDA Version)</title>
            <author fullname="L. Lhotka" initials="L." surname="Lhotka"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.</t>
              <t indent="0">The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8349"/>
          <seriesInfo name="DOI" value="10.17487/RFC8349"/>
        </reference>
        <reference anchor="RFC8362" target="https://www.rfc-editor.org/info/rfc8362" quoteTitle="true" derivedAnchor="RFC8362">
          <front>
            <title>OSPFv3 Link State Advertisement (LSA) Extensibility</title>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="A. Roy" initials="A." surname="Roy"/>
            <author fullname="D. Goethals" initials="D." surname="Goethals"/>
            <author fullname="V. Reddy Vallem" initials="V." surname="Reddy Vallem"/>
            <author fullname="F. Baker" initials="F." surname="Baker"/>
            <date month="April" year="2018"/>
            <abstract>
              <t indent="0">OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.</t>
              <t indent="0">This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8362"/>
          <seriesInfo name="DOI" value="10.17487/RFC8362"/>
        </reference>
        <reference anchor="RFC9129" target="https://www.rfc-editor.org/info/rfc9129" quoteTitle="true" derivedAnchor="RFC9129">
          <front>
            <title>YANG Data Model for the OSPF Protocol</title>
            <author fullname="D. Yeung" initials="D." surname="Yeung"/>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <author fullname="Z. Zhang" initials="Z." surname="Zhang"/>
            <author fullname="I. Chen" initials="I." surname="Chen"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <date month="October" year="2022"/>
            <abstract>
              <t indent="0">This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9129"/>
          <seriesInfo name="DOI" value="10.17487/RFC9129"/>
        </reference>
        <reference anchor="RFC9513" target="https://www.rfc-editor.org/info/rfc9513" quoteTitle="true" derivedAnchor="RFC9513">
          <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 indent="0">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>
        <reference anchor="RFC9552" target="https://www.rfc-editor.org/info/rfc9552" quoteTitle="true" derivedAnchor="RFC9552">
          <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 indent="0">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 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 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 indent="0">Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</t>
              <t indent="0">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="RFC9587" target="https://www.rfc-editor.org/info/rfc9587" quoteTitle="true" derivedAnchor="RFC9587">
          <front>
            <title>YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs)</title>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="S. Palani" initials="S." surname="Palani"/>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <date month="June" year="2024"/>
            <abstract>
              <t indent="0">This document defines a YANG data model augmenting the IETF OSPF YANG data model (RFC 9129) to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9587"/>
          <seriesInfo name="DOI" value="10.17487/RFC9587"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3101" target="https://www.rfc-editor.org/info/rfc3101" quoteTitle="true" derivedAnchor="RFC3101">
          <front>
            <title>The OSPF Not-So-Stubby Area (NSSA) Option</title>
            <author fullname="P. Murphy" initials="P." surname="Murphy"/>
            <date month="January" year="2003"/>
            <abstract>
              <t indent="0">This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3101"/>
          <seriesInfo name="DOI" value="10.17487/RFC3101"/>
        </reference>
        <reference anchor="RFC4252" target="https://www.rfc-editor.org/info/rfc4252" quoteTitle="true" derivedAnchor="RFC4252">
          <front>
            <title>The Secure Shell (SSH) Authentication Protocol</title>
            <author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
            <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/>
            <date month="January" year="2006"/>
            <abstract>
              <t indent="0">The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4252"/>
          <seriesInfo name="DOI" value="10.17487/RFC4252"/>
        </reference>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" quoteTitle="true" derivedAnchor="RFC4271">
          <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 indent="0">This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t indent="0">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 indent="0">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 indent="0">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="RFC5130" target="https://www.rfc-editor.org/info/rfc5130" quoteTitle="true" derivedAnchor="RFC5130">
          <front>
            <title>A Policy Control Mechanism in IS-IS Using Administrative Tags</title>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="M. Shand" initials="M." role="editor" surname="Shand"/>
            <author fullname="C. Martin" initials="C." surname="Martin"/>
            <date month="February" year="2008"/>
            <abstract>
              <t indent="0">This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5130"/>
          <seriesInfo name="DOI" value="10.17487/RFC5130"/>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" quoteTitle="true" derivedAnchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t indent="0">The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" quoteTitle="true" derivedAnchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t indent="0">This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" quoteTitle="true" derivedAnchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9000" quoteTitle="true" derivedAnchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
      </references>
    </references>
    <section numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The authors of <xref target="RFC5130" format="default" sectionFormat="of" derivedContent="RFC5130"/> are acknowledged, since this
    document draws upon both the IS-IS specification and deployment
    experience. The text in <xref target="OSPF-OPERATION" format="default" sectionFormat="of" derivedContent="Section 4"/> is adopted from
    <xref target="RFC5130" format="default" sectionFormat="of" derivedContent="RFC5130"/>.</t>
      <t indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Donnie Savage"/> for his comments and
    questions.</t>
      <t indent="0" pn="section-appendix.a-3">Thanks to <contact fullname="Ketan Talaulikar"/> for his comments and
    providing the BGP-LS text.</t>
      <t indent="0" pn="section-appendix.a-4">Thanks to <contact fullname="Tony Przygienda"/> and <contact fullname="Les Ginsberg"/> for discussions on tag selection.</t>
      <t indent="0" pn="section-appendix.a-5">Thanks to <contact fullname="Russ White"/> for his Routing Directorate
    review.</t>
      <t indent="0" pn="section-appendix.a-6">Thanks to <contact fullname="Bruno Decraene"/> and <contact fullname="Changwang Lin"/> for working group last call comments.</t>
      <t indent="0" pn="section-appendix.a-7">Thanks to <contact fullname="Gunter Van de Velde"/> for has AD review
    and comments.</t>
      <t indent="0" pn="section-appendix.a-8">Thanks to <contact fullname="David Dong"/> for IANA review and
    comments.</t>
      <t indent="0" pn="section-appendix.a-9">Thanks to <contact fullname="Deb Cooley"/>, <contact fullname="Roman     Danyliw"/>, and <contact fullname="John Scudder"/> for IESG review and
    comments.</t>
      <t indent="0" pn="section-appendix.a-10">Thanks to <contact fullname="Mahesh Jethanandani"/> for an extensive
    IESG review of the YANG data model.</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 initials="A." surname="Lindem" fullname="Acee Lindem" role="editor">
        <organization showOnFrontPage="true">LabN Consulting, L.L.C.</organization>
        <address>
          <postal>
            <street>301 Midenhall Way</street>
            <city>Cary</city>
            <region>NC</region>
            <country>United States of America</country>
            <code>27513</code>
          </postal>
          <email>acee.ietf@gmail.com</email>
        </address>
      </author>
      <author initials="P." surname="Psenak" fullname="Peter Psenak">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <street>Apollo Business Center</street>
            <street>Mlynske nivy 43</street>
            <city>Bratislava</city>
            <code>821 09</code>
            <country>Slovakia</country>
          </postal>
          <email>ppsenak@cisco.com</email>
        </address>
      </author>
      <author fullname="Yingzhen Qu" initials="Y" surname="Qu">
        <organization showOnFrontPage="true">Futurewei Technologies</organization>
        <address>
          <postal>
            <street>2330 Central Expressway</street>
            <city>Santa Clara</city>
            <region>CA</region>
            <code>95050</code>
            <country>United States of America</country>
          </postal>
          <email>yingzhen.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
