<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" docName="draft-ietf-teas-enhanced-vpn-20" number="9732" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" prepTime="2025-03-27T16:11:20" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn-20" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9732" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Enhanced VPN Framework">A Framework for NRP-Based Enhanced Virtual Private Networks</title>
    <seriesInfo name="RFC" value="9732" stream="IETF"/>
    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization showOnFrontPage="true">Huawei</organization>
      <address>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <author fullname="Stewart Bryant" initials="S." surname="Bryant">
      <organization showOnFrontPage="true">University of Surrey</organization>
      <address>
        <email>stewart.bryant@gmail.com</email>
      </address>
    </author>
    <author fullname="Zhenqiang Li" initials="Z." surname="Li">
      <organization showOnFrontPage="true">China Mobile</organization>
      <address>
        <email>lizhenqiang@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Takuya Miyasaka" initials="T." surname="Miyasaka">
      <organization showOnFrontPage="true">KDDI Corporation</organization>
      <address>
        <email>ta-miyasaka@kddi.com</email>
      </address>
    </author>
    <author fullname="Young Lee" initials="Y." surname="Lee">
      <organization showOnFrontPage="true">Samsung</organization>
      <address>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>RTG</area>
    <workgroup>teas</workgroup>
    <keyword>network slicing</keyword>
    <keyword>traffic engineering</keyword>
    <keyword>performance guarantee</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document describes a framework for Enhanced Virtual Private
      Networks (VPNs) based on Network Resource Partitions (NRPs) in order to
      support the needs of applications with specific traffic performance
      requirements (e.g., low latency, bounded jitter). NRP-based enhanced
      VPNs leverage the VPN and Traffic Engineering (TE) technologies and add
      characteristics that specific services require beyond those provided by
      conventional VPNs. Typically, an NRP-based enhanced VPN will be used to
      underpin network slicing, but it could also be of use in its own right
      providing enhanced connectivity services between customer sites. This
      document also provides an overview of relevant technologies in different
      network layers and identifies some areas for potential new work.</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 document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </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).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see 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/rfc9732" 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>
          </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-terminology">Terminology</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-overview-of-the-requirement">Overview of the Requirements</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" keepWithNext="true" 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-performance-guarantees">Performance Guarantees</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-interaction-between-enhance">Interaction Between Enhanced VPN Services</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-on-traffic-iso">Requirements on Traffic Isolation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-limited-interaction-with-ot">Limited Interaction with Other Services</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.3.1"><xref derivedContent="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-realization-of-limited-inte">Realization of Limited Interaction with Enhanced VPN Services</xref></t>
                  </li>
                </ul>
              </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-integration-with-network-re">Integration with Network Resources and Service Functions</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-abstraction">Abstraction</xref></t>
                  </li>
                </ul>
              </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-dynamic-changes">Dynamic Changes</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-customized-control">Customized Control</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-applicability-to-overlay-te">Applicability to Overlay Technologies</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.7">
                <t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent="3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-inter-domain-and-inter-laye">Inter-Domain and Inter-Layer Network</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-the-architecture-of-nrp-bas">The Architecture of NRP-Based Enhanced VPNs</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-layered-architecture">Layered Architecture</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-connectivity-types">Connectivity Types</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-specific-data-t">Application-Specific Data Types</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scalable-service-mapping">Scalable Service Mapping</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-candidate-technologies">Candidate Technologies</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-underlay-forwarding-resourc">Underlay Forwarding Resource Partitioning</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flex-ethernet">Flex Ethernet</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dedicated-queues">Dedicated Queues</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-time-sensitive-networking">Time-Sensitive Networking</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-network-layer-encapsulation">Network Layer Encapsulation and Forwarding</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
                  <li pn="section-toc.1-1.5.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deterministic-networking-de">Deterministic Networking (DetNet)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mpls-traffic-engineering-mp">MPLS Traffic Engineering (MPLS-TE)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.3.1"><xref derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-segment-routing">Segment Routing</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.4.1"><xref derivedContent="5.2.4" format="counter" sectionFormat="of" target="section-5.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-encapsulation-extension">New Encapsulation Extensions</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-non-packet-data-plane">Non-Packet Data Plane</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-control-plane">Control Plane</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-management-plane">Management Plane</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.6">
                <t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability-of-service-da">Applicability of Service Data Models to Enhanced VPNs</xref></t>
              </li>
            </ul>
          </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-applicability-in-network-sl">Applicability in Network Slice Realization</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nrp-planning">NRP Planning</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nrp-creation">NRP Creation</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-network-slice-service-provi">Network Slice Service Provisioning</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-network-slice-traffic-steer">Network Slice Traffic Steering and Forwarding</xref></t>
              </li>
            </ul>
          </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-scalability-considerations">Scalability Considerations</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-maximum-stack-depth-of-sr">Maximum Stack Depth of SR</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-rsvp-te-scalability">RSVP-TE Scalability</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sdn-scaling">SDN Scaling</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-enhanced-resiliency">Enhanced Resiliency</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-manageability-consideration">Manageability Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-oam-considerations">OAM Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-telemetry-considerations">Telemetry Considerations</xref></t>
              </li>
            </ul>
          </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-operational-considerations">Operational Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <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.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.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.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Virtual Private Networks (VPNs) have served the industry well as a
      means of providing different groups of users with logically isolated
      connectivity over a common network. The common (base) network that is
      used to provide the VPNs is often referred to as the "underlay", and the
      VPN is often called an "overlay".</t>
      <t indent="0" pn="section-1-2">Customers of a network operator may request connectivity services
      with advanced characteristics, such as low-latency guarantees, bounded
      jitter, or isolation from other services or customers, so that changes in
      other services (e.g., changes in network load, or events such as
      congestion or outages) have no effect or only acceptable effects on the
      observed throughput or latency of the services delivered to the
      customer. These services are referred to as "enhanced VPNs", as they are
      similar to VPN services, providing the customer with the required
      connectivity, but they also provide enhanced characteristics.</t>
      <t indent="0" pn="section-1-3">This document describes a framework for delivering VPN services with
      enhanced characteristics, such as guaranteed resources, latency, jitter,
      etc. This list is not exhaustive. It is expected that other enhanced
      features may be added to VPN over time and that this
      framework will support these additions with necessary changes or
      enhancements in some network layers and network planes (data plane,
      control plane, and management plane).</t>
      <t indent="0" pn="section-1-4">The concept of network slicing has gained traction, driven largely by
      needs surfacing from 5G (see <xref target="NGMN-NS-Concept" format="default" sectionFormat="of" derivedContent="NGMN-NS-Concept"/>, <xref target="TS23501" format="default" sectionFormat="of" derivedContent="TS23501"/>, and <xref target="TS28530" format="default" sectionFormat="of" derivedContent="TS28530"/>). According to <xref target="TS28530" format="default" sectionFormat="of" derivedContent="TS28530"/>, a 5G end-to-end network slice consists of three
      major types of network segments: Radio Access Network (RAN), Transport
      Network (TN), and mobile Core Network (CN). The transport network
      provides the connectivity between different entities in RAN and CN
      segments of a 5G end-to-end network slice, with specific performance
      commitments.</t>
      <t indent="0" pn="section-1-5"><xref target="RFC9543" format="default" sectionFormat="of" derivedContent="RFC9543"/> discusses the general framework, components,
      and interfaces for requesting and operating network slices using IETF
      technologies. These network slices may be referred to as "RFC 9543
      Network Slices", but in this document (which is solely about IETF
      technologies), we simply use the term "network slice" to refer to this
      concept. A network slice service enables connectivity between a set of
      Service Demarcation Points (SDPs) with specific Service Level Objectives
      (SLOs) and Service Level Expectations (SLEs) over a common underlay
      network. A network slice can be realized as a logical network connecting
      a number of endpoints and is associated with a set of shared or
      dedicated network resources that are used to satisfy the SLO and SLE      requirements. A network slice is considered to be one target use case of
      enhanced VPNs.</t>
      <t indent="0" pn="section-1-6"><xref target="RFC9543" format="default" sectionFormat="of" derivedContent="RFC9543"/> also introduces the concept of NRP, which is a subset of the
      buffer/queuing/scheduling resources and associated policies on each of a
      connected set of links in the underlay network. An NRP can be associated
      with a dedicated or shared network topology to select or specify the set
      of links and nodes involved.</t>
      <t indent="0" pn="section-1-7">The requirements of enhanced VPN services cannot simply be met by
      overlay networks: enhanced VPN services require tighter coordination
      and integration between the overlay and the underlay networks.</t>
      <t indent="0" pn="section-1-8">In the overlay network, the VPN has been defined as the network
      construct to provide the required connectivity for different services or
      customers. Multiple VPN flavors can be considered to create that
      construct <xref target="RFC4026" format="default" sectionFormat="of" derivedContent="RFC4026"/>. In the underlay network, the NRP is
      used to represent a subset of the network resources and associated
      policies in the underlay network. An NRP can be associated with a
      dedicated or shared network topology to select or specify the set of
      links and nodes involved.</t>
      <t indent="0" pn="section-1-9">An enhanced VPN service can be realized by integrating a VPN in the
      overlay and an NRP in the underlay. This is called an "NRP-based enhanced
      VPN". In doing so, an enhanced VPN service can provide enhanced
      properties, such as guaranteed resources and assured or predictable
      performance. An enhanced VPN service may also involve a set of service
      functions (see <xref target="RFC7665" sectionFormat="of" section="1.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7665#section-1.4" derivedContent="RFC7665"/> for the
      definition of service function). The techniques for delivering an
      NRP-based enhanced VPN can be used to instantiate a network slice
      service (as described in <xref target="app-ns-realization" format="default" sectionFormat="of" derivedContent="Section 6"/>), and they
      can also be of use in general cases to provide enhanced connectivity
      services between customer sites or service endpoints.</t>
      <t indent="0" pn="section-1-10">This document describes a framework for using existing, modified, and
      potential new technologies as components to provide NRP-based enhanced
      VPN services. Specifically, this document provides:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-11">
        <li pn="section-1-11.1">
          <t indent="0" pn="section-1-11.1.1">The functional requirements and service characteristics of an
          enhanced VPN service.</t>
        </li>
        <li pn="section-1-11.2">
          <t indent="0" pn="section-1-11.2.1">The design of the data plane for NRP-based enhanced VPNs.</t>
        </li>
        <li pn="section-1-11.3">
          <t indent="0" pn="section-1-11.3.1">The necessary control and management protocols in both the
          underlay and the overlay of enhanced VPNs.</t>
        </li>
        <li pn="section-1-11.4">
          <t indent="0" pn="section-1-11.4.1">The mechanisms to achieve integration between the overlay network
          and the underlay network.</t>
        </li>
        <li pn="section-1-11.5">
          <t indent="0" pn="section-1-11.5.1">The necessary Operation, Administration, and Maintenance (OAM)
          methods to instrument an enhanced VPN to make sure that the required
          Service Level Agreement (SLA) between the customer and the network
          operator is met and to take any corrective action (such as
          switching traffic to an alternate path) to avoid SLA violation.</t>
        </li>
      </ul>
      <t indent="0" pn="section-1-12">One possible layered network structure to achieve these objectives is
      shown in <xref target="COMLAY" format="default" sectionFormat="of" derivedContent="Section 4.1"/>.</t>
      <t indent="0" pn="section-1-13">It is not envisaged that enhanced VPN services will replace
      conventional VPN services. VPN services will continue to be delivered
      using existing mechanisms and can coexist with enhanced VPN services.
      Whether enhanced VPN features are added to an active VPN service is
      deployment specific.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">In this document, the relationship of the four terms "VPN", "enhanced
      VPN", "NRP", and "Network Slice" are as follows:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-2">
        <li pn="section-2-2.1">
          <t indent="0" pn="section-2-2.1.1">A Virtual Private Network (VPN) refers to the overlay network
          service that provides connectivity between different customer sites
          and that maintains traffic separation between different customers.
          Examples of technologies to provide VPN services are as follows: IP VPN <xref target="RFC2764" format="default" sectionFormat="of" derivedContent="RFC2764"/> <xref target="RFC4364" format="default" sectionFormat="of" derivedContent="RFC4364"/>, L2VPN <xref target="RFC4664" format="default" sectionFormat="of" derivedContent="RFC4664"/>, and EVPN <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>.</t>
        </li>
        <li pn="section-2-2.2">
          <t indent="0" pn="section-2-2.2.1">An enhanced VPN service is an evolution of the VPN service that
          makes additional service-specific commitments. An NRP-based enhanced
          VPN is made by integrating a VPN with a set of network resources
          allocated in the underlay network (i.e., an NRP).</t>
        </li>
        <li pn="section-2-2.3">
          <t indent="0" pn="section-2-2.3.1">An NRP, as defined in <xref target="RFC9543" format="default" sectionFormat="of" derivedContent="RFC9543"/>, is a subset of the buffer/queuing/scheduling
          resources and associated policies on each of a connected set of
          links in the underlay network. An NRP can be associated with a
          dedicated or shared network topology to select or specify the set of
          links and nodes involved. An NRP is designed to meet the network
          resources and performance characteristics required by the enhanced
          VPN services.</t>
        </li>
        <li pn="section-2-2.4">
          <t indent="0" pn="section-2-2.4.1">A network slice service could be delivered by provisioning one or
          more NRP-based enhanced VPNs in the network. Other mechanisms for
          realizing network slices may exist but are not in the scope of this
          document.</t>
        </li>
      </ul>
      <t indent="0" pn="section-2-3">The term "tenant" is used in this document to refer to a customer of
      the enhanced VPN services.</t>
      <t indent="0" pn="section-2-4">The following terms, defined in other documents, are also used in
      this document. </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-2-5">
        <dt pn="section-2-5.1">SLA:</dt>
        <dd pn="section-2-5.2">Service Level Agreement (see <xref target="RFC9543" format="default" sectionFormat="of" derivedContent="RFC9543"/>)</dd>
        <dt pn="section-2-5.3">SLO:</dt>
        <dd pn="section-2-5.4">Service Level Objective (see <xref target="RFC9543" format="default" sectionFormat="of" derivedContent="RFC9543"/>)</dd>
        <dt pn="section-2-5.5">SLE:</dt>
        <dd pn="section-2-5.6">Service Level Expectation (see <xref target="RFC9543" format="default" sectionFormat="of" derivedContent="RFC9543"/>)</dd>
        <dt pn="section-2-5.7">ACTN:</dt>
        <dd pn="section-2-5.8">Abstraction and Control of TE Networks (see <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/>)</dd>
        <dt pn="section-2-5.9">DetNet:</dt>
        <dd pn="section-2-5.10">Deterministic Networking (see <xref target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655"/>)</dd>
        <dt pn="section-2-5.11">FlexE:</dt>
        <dd pn="section-2-5.12">Flex Ethernet (see <xref target="FLEXE" format="default" sectionFormat="of" derivedContent="FLEXE"/>)</dd>
        <dt pn="section-2-5.13">TSN:</dt>
        <dd pn="section-2-5.14">Time-Sensitive Networking (see <xref target="TSN" format="default" sectionFormat="of" derivedContent="TSN"/>)</dd>
        <dt pn="section-2-5.15">VN:</dt>
        <dd pn="section-2-5.16">Virtual Network (see <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/>)</dd>
      </dl>
    </section>
    <section anchor="overview-of-the-requirements" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-overview-of-the-requirement">Overview of the Requirements</name>
      <t indent="0" pn="section-3-1">This section provides an overview of the requirements of an enhanced
      VPN service.</t>
      <section anchor="diverse-performance-guarantees" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-performance-guarantees">Performance Guarantees</name>
        <t indent="0" pn="section-3.1-1">Performance guarantees are committed by network operators to their
        customers in relation to the services delivered to the customers. They
        are usually expressed in SLAs as a set of SLOs.</t>
        <t indent="0" pn="section-3.1-2">There are several kinds of performance guarantees, including
        guaranteed maximum packet loss, guaranteed maximum delay, and
        guaranteed delay variation. Note that these guarantees apply to
        conformance traffic; out-of-profile traffic will be handled according
        to a separate agreement with the customer (see, for example,
        <xref target="RFC7297" sectionFormat="of" section="3.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7297#section-3.6" derivedContent="RFC7297"/>).</t>
        <t indent="0" pn="section-3.1-3">Guaranteed maximum packet loss is usually addressed by setting
        packet priorities, queue sizes, and discard policies. However, this
        becomes more difficult when the requirement is combined with latency
        requirements. The limiting case is zero congestion loss, and that is
        the goal of DetNet <xref target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655"/>
        and Time-Sensitive Networking (TSN) <xref target="TSN" format="default" sectionFormat="of" derivedContent="TSN"/>. In modern
        optical networks, loss due to transmission errors already approaches
        zero, but there is the possibility of failure of the interface or the
        fiber itself. This type of fault can be addressed by some form of
        signal duplication and transmission over diverse paths.</t>
        <t indent="0" pn="section-3.1-4">Guaranteed maximum latency is required by a number of applications,
        particularly real-time control applications and some types of
        augmented reality and virtual reality (AR/VR) applications. DetNet
        techniques may be considered <xref target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655"/>; however,
        additional methods of enhancing the underlay to better support the
        delay guarantees may be needed. These methods will need to be
        integrated with the overall service provisioning mechanisms.</t>
        <t indent="0" pn="section-3.1-5">Guaranteed maximum delay variation is a performance guarantee that
        may also be needed. <xref target="RFC8578" format="default" sectionFormat="of" derivedContent="RFC8578"/> calls up a number of
        cases that need this guarantee, for example, in electrical utilities.
        Time transfer is an example service that needs this performance
        guarantee, although it is in the nature of time that the service might
        be delivered by the underlay as a shared service and not provided
        through different enhanced VPNs. Alternatively, a dedicated enhanced
        VPN might be used to provide time transfer as a shared service.</t>
        <t indent="0" pn="section-3.1-6">This suggests that a spectrum of service guarantees needs to be
        considered when designing and deploying an enhanced VPN. For
        illustration purposes and without claiming to be exhaustive, four
        types of services are considered:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-7">
          <li pn="section-3.1-7.1">
            <t indent="0" pn="section-3.1-7.1.1">Best effort</t>
          </li>
          <li pn="section-3.1-7.2">
            <t indent="0" pn="section-3.1-7.2.1">Assured bandwidth</t>
          </li>
          <li pn="section-3.1-7.3">
            <t indent="0" pn="section-3.1-7.3.1">Guaranteed latency</t>
          </li>
          <li pn="section-3.1-7.4">
            <t indent="0" pn="section-3.1-7.4.1">Enhanced delivery</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.1-8">It is noted that some services may have mixed requirements from
        this list, e.g., both assured bandwidth and guaranteed latency can be
        required.</t>
        <t indent="0" pn="section-3.1-9">The best-effort service is the basic connectivity service that can
        be provided by current VPNs.</t>
        <t indent="0" pn="section-3.1-10">An assured bandwidth service is a connectivity service in which the
        bandwidth over some period of time is assured. This could be achieved
        either simply based on a best-effort service with over-capacity
        provisioning or based on MPLS TE Label
        Switching Paths (TE-LSPs) with bandwidth reservations. Depending on
        the technique used, however, the bandwidth is not necessarily assured
        at any instant. Providing assured bandwidth to VPNs, for example, by
        using per-VPN TE-LSPs, is not widely deployed at least partially due
        to scalability concerns. The more common approach of aggregating
        multiple VPNs onto common TE-LSPs results in shared bandwidth and so
        may reduce the assurance of bandwidth to any one service. Enhanced
        VPNs aim to provide a more scalable approach for such services.</t>
        <t indent="0" pn="section-3.1-11">A guaranteed latency service has an upper bound to edge-to-edge
        latency. Assuring the upper bound is sometimes more important than
        minimizing latency. There are several new technologies that provide
        some assistance with this performance guarantee:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.1-12">
          <li pn="section-3.1-12.1">the IEEE TSN
        project <xref target="TSN" format="default" sectionFormat="of" derivedContent="TSN"/> introduces the concept of scheduling of
          delay-sensitive and loss-sensitive packets.</li>
          <li pn="section-3.1-12.2">FlexE <xref target="FLEXE" format="default" sectionFormat="of" derivedContent="FLEXE"/> is
          useful to help provide a guaranteed upper bound to latency.</li>
          <li pn="section-3.1-12.3">DetNet is of relevance in assuring an upper bound of end-to-end
          packet latency in the network layer.</li>
        </ul>
        <t indent="0" pn="section-3.1-13">The use of these technologies to
        deliver enhanced VPN services needs to be considered when a guaranteed
        latency service is required.</t>
        <t indent="0" pn="section-3.1-14">An enhanced delivery service is a connectivity service in which the
        underlay network (at Layer 3) needs to ensure to eliminate or minimize
        packet loss in the event of equipment or media failures. This may be
        achieved by delivering a copy of the packet through multiple paths.
        Such a mechanism may need to be used for enhanced VPN services.</t>
      </section>
      <section anchor="interaction-between-vpn-services" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-interaction-between-enhance">Interaction Between Enhanced VPN Services</name>
        <t indent="0" pn="section-3.2-1">There is a fine distinction between how a customer requests limits
        on interaction between an enhanced VPN service and other services
        (whether they are other enhanced VPN services or any other network
        service) and how that is delivered by the service provider. This
        section examines the requirements and realization of limited
        interaction between an enhanced VPN service and other services.</t>
        <section anchor="requirements-on-traffic-isolation" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-requirements-on-traffic-iso">Requirements on Traffic Isolation</name>
          <t indent="0" pn="section-3.2.1-1">"Traffic isolation" is a generic term that can be used to describe
          the requirements for separating the services of different customers
          or different service types in the network. In the context of network
          slicing, traffic isolation is defined as an SLE of the network slice
          service (<xref target="RFC9543" sectionFormat="of" section="8.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9543#section-8.1" derivedContent="RFC9543"/>), which is one
          element of the SLA. A customer may care about disruption caused by
          other services, contamination by other traffic, or delivery of their
          traffic to the wrong destinations.</t>
          <t indent="0" pn="section-3.2.1-2">A customer may want to specify (and thus pay for) the traffic
          isolation provided by the service provider. Some customers (banking,
          for example) may have strict requirements on how their flows are
          handled when delivered over a shared network. Some professional
          services are used to relying on specific certifications and audits
          to ensure the compliancy of a network with traffic-isolation
          requirements and, specifically, to prevent data leaks.</t>
          <t indent="0" pn="section-3.2.1-3">With traffic isolation, a customer expects that the service
          traffic cannot be received by other customers in the same network.
          In <xref target="RFC4176" format="default" sectionFormat="of" derivedContent="RFC4176"/>, traffic isolation is mentioned as one
          of the requirements of VPN customers. Traffic isolation is also
          described in <xref target="RFC7297" sectionFormat="of" section="3.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7297#section-3.8" derivedContent="RFC7297"/>.</t>
          <t indent="0" pn="section-3.2.1-4">There can be different expectations of traffic isolation. For
          example, a customer may further request the protection of their
          traffic by requesting specific encryption schemes at the enhanced
          VPN access and also when transported between Provider Edge
          (PE) nodes.</t>
          <t indent="0" pn="section-3.2.1-5">An enhanced VPN service customer may request traffic isolation
          together with other operator-defined service characteristics. The
          exact details about the expected behavior need to be specified in
          the service request so that meaningful service assurance and
          fulfillment feedback can be exposed to the customer. It is out of
          the scope of this document to elaborate the service-modeling
          considerations.</t>
        </section>
        <section anchor="limited-interaction-with-other-services" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.2">
          <name slugifiedName="name-limited-interaction-with-ot">Limited Interaction with Other Services</name>
          <t indent="0" pn="section-3.2.2-1"><xref target="RFC2211" format="default" sectionFormat="of" derivedContent="RFC2211"/> describes the controlled-load service.
          In that document, the end-to-end behavior provided to an application
          by a series of network elements providing controlled-load service is
          described as closely approximating to the behavior visible to
          applications receiving best-effort service when those network
          elements are not carrying substantial traffic from other
          services.</t>
          <t indent="0" pn="section-3.2.2-2">Thus, a consumer of a controlled-load service may assume
          that:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.2-3">
            <li pn="section-3.2.2-3.1">
              <t indent="0" pn="section-3.2.2-3.1.1">A very high percentage of transmitted packets will be
              successfully delivered by the network to the receiving
              end nodes.</t>
            </li>
            <li pn="section-3.2.2-3.2">
              <t indent="0" pn="section-3.2.2-3.2.1">The transit delay experienced by a very high percentage of
              the delivered packets will not greatly exceed the minimum
              transmit delay experienced by any successfully delivered
              packet.</t>
            </li>
          </ul>
          <t indent="0" pn="section-3.2.2-4">An enhanced VPN customer may request a controlled-load service in
          one of two ways:</t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.2.2-5"><li pn="section-3.2.2-5.1" derivedCounter="1.">
              <t indent="0" pn="section-3.2.2-5.1.1">It may configure a set of SLOs (for example, for delay and
              loss) such that the delivered enhanced VPN meets the behavioral
              objectives of the customer.</t>
            </li>
            <li pn="section-3.2.2-5.2" derivedCounter="2.">
              <t indent="0" pn="section-3.2.2-5.2.1">As described in <xref target="RFC2211" format="default" sectionFormat="of" derivedContent="RFC2211"/>, a customer may
              request the controlled-load service without reference to or
              specification of specific target values for control parameters
              such as delay or loss. Instead, acceptance of a request for
              controlled-load service is defined to imply a commitment by the
              network element to provide the requestor with service closely
              equivalent to that provided to uncontrolled (best-effort)
              traffic under lightly loaded conditions. This way of requesting
              the service is an SLE.</t>
            </li>
          </ol>
          <t indent="0" pn="section-3.2.2-6">Limited interaction between enhanced VPN services does not cover
          service degradation due to non-interaction-related causes, such as
          link errors.</t>
        </section>
        <section anchor="realization-of-limited-interaction-between-vpn-services" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.3">
          <name slugifiedName="name-realization-of-limited-inte">Realization of Limited Interaction with Enhanced VPN Services</name>
          <t indent="0" pn="section-3.2.3-1">A service provider may translate the requirements related to
          limited interaction into distinct engineering rules in its network.
          Honoring the service requirement may involve tweaking a set of QoS,
          TE, security, and planning tools, while traffic isolation will
          involve adequately configuring routing and authorization
          capabilities.</t>
          <t indent="0" pn="section-3.2.3-2">Concretely, there are many existing techniques that can be used
          to provide traffic isolation, such as IP and MPLS VPNs or other
          multi-tenant virtual network techniques. Controlled-load services
          may be realized as described in <xref target="RFC2211" format="default" sectionFormat="of" derivedContent="RFC2211"/>. Other
          tools may include various forms of resource management and
          reservation techniques, such as network capacity planning,
          allocating dedicated network resources, traffic policing or shaping,
          prioritizing in using shared network resources, etc., so that a
          subset of bandwidth, buffers, and queueing resources can be
          available in the underlay network to support the enhanced VPN
          services.</t>
          <t indent="0" pn="section-3.2.3-3">To provide the required traffic isolation, or to reduce the
          interaction with other enhanced VPN services, network resources may
          need to be reserved in the data plane of the underlay network and
          dedicated to traffic from a specific enhanced VPN service or a
          specific group of enhanced VPN services.

This may introduce scalability concerns in the implementation, as each
enhanced VPN may need to be tracked in the network. It may also introduce
scalability concerns in deployment, such as how many resources need to be
reserved and how the services are mapped to the resources (<xref target="scalable-mapping" format="default" sectionFormat="of" derivedContent="Section 4.4"/>). Thus, some trade-off needs to be considered to
provide the traffic isolation and limited interaction between an enhanced VPN
service and other services.</t>
          <t indent="0" pn="section-3.2.3-4">A dedicated physical network can be used to meet stricter SLO and
          SLE requests, at the cost of allocating resources on a long-term and
          end- to-end basis. On the other hand, where adequate traffic
          isolation and limited interaction can be achieved at the packet
          layer, this permits the resources to be shared amongst a group of
          services and only dedicated to a service on a temporary basis. By
          combining conventional VPNs with TE, QoS, and security techniques,
          an enhanced VPN offers a variety of means to honor customer's
          requirements.</t>
        </section>
      </section>
      <section anchor="integration" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-integration-with-network-re">Integration with Network Resources and Service Functions</name>
        <t indent="0" pn="section-3.3-1">The way to meet the enhanced VPN service's demand for certain
        characteristics (such as guaranteed or predictable performance) is by
        integrating the overlay VPN with a particular set of resources in the
        underlay network that are allocated to meet the service requirements.
        This needs to be done in a flexible and scalable way so that it can be
        widely deployed in operators' networks to support a good number of
        enhanced VPN services.</t>
        <t indent="0" pn="section-3.3-2">Taking mobile networks and, in particular, 5G into consideration, the
        integration of the network with service functions is likely a
        requirement. The IETF's work on Service Function Chaining (SFC) <xref target="RFC7665" format="default" sectionFormat="of" derivedContent="RFC7665"/> provides a foundation for this. Service functions
        in the underlay network can be considered to be part of the enhanced VPN
        services, which means the service functions may need to be an integral
        part of the corresponding NRP. The details of the integration between
        service functions and enhanced VPNs are out of the scope of this
        document.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.3.1">
          <name slugifiedName="name-abstraction">Abstraction</name>
          <t indent="0" pn="section-3.3.1-1">Integration of the overlay VPN and the underlay network resources
          and service functions does not always need to be a direct mapping.
          As described in <xref target="RFC7926" format="default" sectionFormat="of" derivedContent="RFC7926"/>, abstraction is the process
          of applying policy to a set of information about a traffic-engineered network to produce selective information that
          represents the potential ability to connect across the network. The
          process of abstraction presents the connectivity graph in a way that
          is independent of the underlying network technologies, capabilities,
          and topology so that the graph can be used to plan and deliver
          network services in a uniform way.</t>
          <t indent="0" pn="section-3.3.1-2">Using the abstraction approach, an enhanced VPN may be built on
          top of an abstracted topology that represents the connectivity
          capabilities of the underlay TE-based network as described in the
          framework for Abstraction and Control of TE Networks (ACTN) <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/> as discussed further in <xref target="management-plane" format="default" sectionFormat="of" derivedContent="Section 5.5"/>.</t>
        </section>
      </section>
      <section anchor="dynamic-configuration" numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-dynamic-changes">Dynamic Changes</name>
        <t indent="0" pn="section-3.4-1">Enhanced VPNs need to be created, modified, and removed from the
        network according to service demands (including scheduled requests).
        An enhanced VPN that requires limited interaction with other services
        (<xref target="limited-interaction-with-other-services" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>) must not be
        disrupted by the instantiation or modification of another enhanced VPN
        service. As discussed in <xref target="RFC4176" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4176#section-3.1" derivedContent="RFC4176"/>, the
        assessment of traffic isolation is part of the management of a VPN
        service. Determining whether modification of an enhanced VPN can be
        disruptive to that enhanced VPN and whether the traffic in flight will
        be disrupted can be a difficult problem.</t>
        <t indent="0" pn="section-3.4-2">Dynamic changes both to the enhanced VPN and to the underlay
        network need to be managed to avoid disruption to services that are
        sensitive to changes in network performance.</t>
        <t indent="0" pn="section-3.4-3">In addition to managing the network without disruption during changes
        such as the inclusion of a new enhanced VPN service endpoint or a
        change to a link, enhanced VPN traffic might need to be moved because
        of changes to traffic patterns and volume. This means that during the
        lifetime of an enhanced VPN service, closed-loop optimization is
        needed so that the delivered service always matches the ordered
        SLA.</t>
        <t indent="0" pn="section-3.4-4">The data plane aspects of this problem are discussed further in
        Sections <xref target="L2-DP" format="counter" sectionFormat="of" derivedContent="5.1"/>, <xref target="NW-DP" format="counter" sectionFormat="of" derivedContent="5.2"> </xref>, and <xref target="Non-Packet-DP" format="counter" sectionFormat="of" derivedContent="5.3"/>.</t>
        <t indent="0" pn="section-3.4-5">The control plane aspects of this problem are discussed further in
        <xref target="control-plane" format="default" sectionFormat="of" derivedContent="Section 5.4"/>.</t>
        <t indent="0" pn="section-3.4-6">The management plane aspects of this problem are discussed further
        in <xref target="management-plane" format="default" sectionFormat="of" derivedContent="Section 5.5"/>.</t>
      </section>
      <section anchor="customized-control-plane" numbered="true" toc="include" removeInRFC="false" pn="section-3.5">
        <name slugifiedName="name-customized-control">Customized Control</name>
        <t indent="0" pn="section-3.5-1">In many cases enhanced VPN services are delivered to customers
        without information about the underlying NRPs. However, in some cases, depending on
        the agreement between the operator and the customer, the
        customer may also be provided with some information about the
        underlying NRPs. Such information can be filtered or aggregated
        according to the operator's policy. This allows the customer of an
        enhanced VPN service to have some visibility and even control over how
        the underlying topology and resources of the NRP are used. For
        example, the customer may be able to specify the path or path
        constraints within the NRP for specific traffic flows of their
        enhanced VPN service. Depending on the requirements, an enhanced VPN
        customer may have their own network controller, which may be provided
        with an interface to the control or management system run by the
        network operator. Note that such a control is within the scope of the
        customer's enhanced VPN service; any additional changes beyond this
        would require some intervention by the network operator.</t>
        <t indent="0" pn="section-3.5-2">A description of the control plane aspects of this problem are
        discussed further in <xref target="control-plane" format="default" sectionFormat="of" derivedContent="Section 5.4"/>. A description of
        the management plane aspects of this feature can be found in <xref target="management-plane" format="default" sectionFormat="of" derivedContent="Section 5.5"/>.</t>
      </section>
      <section anchor="applicability" numbered="true" toc="include" removeInRFC="false" pn="section-3.6">
        <name slugifiedName="name-applicability-to-overlay-te">Applicability to Overlay Technologies</name>
        <t indent="0" pn="section-3.6-1">The concept of an enhanced VPN can be applied to any existing and
        future multi-tenancy overlay technologies including but not limited
        to:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.6-2">
          <li pn="section-3.6-2.1">
            <t indent="0" pn="section-3.6-2.1.1">Layer 2 point-to-point (P2P) services, such as pseudowires (see <xref target="RFC3985" format="default" sectionFormat="of" derivedContent="RFC3985"/>)</t>
          </li>
          <li pn="section-3.6-2.2">
            <t indent="0" pn="section-3.6-2.2.1">Layer 2 VPNs (see <xref target="RFC4664" format="default" sectionFormat="of" derivedContent="RFC4664"/>)</t>
          </li>
          <li pn="section-3.6-2.3">
            <t indent="0" pn="section-3.6-2.3.1">Ethernet VPNs (see <xref target="RFC7209" format="default" sectionFormat="of" derivedContent="RFC7209"/> and <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>)</t>
          </li>
          <li pn="section-3.6-2.4">
            <t indent="0" pn="section-3.6-2.4.1">Layer 3 VPNs (see <xref target="RFC4364" format="default" sectionFormat="of" derivedContent="RFC4364"/> and <xref target="RFC2764" format="default" sectionFormat="of" derivedContent="RFC2764"/>)</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.6-3">Where such VPN service types need enhanced isolation and delivery
        characteristics, the technologies described in <xref target="SDDC" format="default" sectionFormat="of" derivedContent="Section 5"/>
        can be used to tweak the underlay to provide the required enhanced
        performance.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.7">
        <name slugifiedName="name-inter-domain-and-inter-laye">Inter-Domain and Inter-Layer Network</name>
        <t indent="0" pn="section-3.7-1">In some scenarios, an enhanced VPN service may span multiple
        network domains. A domain is considered to be any collection of
        network elements under the responsibility of the same administrative
        entity, for example, an Autonomous System (AS). In some domains, the
        network operator may manage a multi-layered network, for example, a
        packet network over an optical network. When enhanced VPN services are
        provisioned in such network scenarios, the technologies used in
        different network planes (the data plane, control plane, and management
        plane) need to provide mechanisms to support multi-domain and
        multi-layer coordination and integration; this is to provide the
        required service characteristics for different enhanced VPN services
        and improve network efficiency and operational simplicity. The
        mechanisms for multi-domain VPNs (see <xref target="RFC4364" format="default" sectionFormat="of" derivedContent="RFC4364"/>) may be
        reused, and some enhancement may be needed to meet the additional
        requirements of enhanced VPN services.</t>
      </section>
    </section>
    <section anchor="architecture-and-components-of-vpn" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-the-architecture-of-nrp-bas">The Architecture of NRP-Based Enhanced VPNs</name>
      <t indent="0" pn="section-4-1">Multiple NRP-based enhanced VPN services can be provided by a common
      network infrastructure. Each NRP-based enhanced VPN service is
      provisioned with an overlay VPN and mapped to a corresponding NRP, which
      has a specific set of network resources and service functions allocated
      in the underlay to satisfy the needs of the customer. One NRP may
      support one or more NRP-based enhanced VPN services. The integration
      between the overlay connectivity and the underlay resources ensures the
      required isolation between different enhanced VPN services and achieves
      the guaranteed performance for different customers.</t>
      <t indent="0" pn="section-4-2">The NRP-based enhanced VPN architecture needs to be designed with
      consideration given to:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-3">
        <li pn="section-4-3.1">
          <t indent="0" pn="section-4-3.1.1">An enhanced data plane.</t>
        </li>
        <li pn="section-4-3.2">
          <t indent="0" pn="section-4-3.2.1">A control plane to create enhanced VPNs and NRPs, making use of
          the data plane isolation and performance guarantee techniques.</t>
        </li>
        <li pn="section-4-3.3">
          <t indent="0" pn="section-4-3.3.1">A management plane to manage enhanced VPN service life cycles.</t>
        </li>
        <li pn="section-4-3.4">
          <t indent="0" pn="section-4-3.4.1">The OAM mechanisms for enhanced VPNs and the underlying NRPs.</t>
        </li>
        <li pn="section-4-3.5">
          <t indent="0" pn="section-4-3.5.1">Telemetry mechanisms for enhanced VPNs and the underlying
          NRPs.</t>
        </li>
      </ul>
      <t indent="0" pn="section-4-4"> These topics are expanded below.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5">
        <li pn="section-4-5.1">
          <t indent="0" pn="section-4-5.1.1">The enhanced data plane provides:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5.1.2">
            <li pn="section-4-5.1.2.1">
              <t indent="0" pn="section-4-5.1.2.1.1">The required packet-latency and jitter characteristics.</t>
            </li>
            <li pn="section-4-5.1.2.2">
              <t indent="0" pn="section-4-5.1.2.2.1">The required packet-loss characteristics.</t>
            </li>
            <li pn="section-4-5.1.2.3">
              <t indent="0" pn="section-4-5.1.2.3.1">The required resource-isolation capability, e.g., bandwidth
              guarantee.</t>
            </li>
            <li pn="section-4-5.1.2.4">
              <t indent="0" pn="section-4-5.1.2.4.1">The mechanism to associate a packet with the set of resources
              allocated to an NRP to which the enhanced VPN service packet is
              mapped.</t>
            </li>
          </ul>
        </li>
        <li pn="section-4-5.2">
          <t indent="0" pn="section-4-5.2.1">The control plane:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5.2.2">
            <li pn="section-4-5.2.2.1">
              <t indent="0" pn="section-4-5.2.2.1.1">Collects information about the underlying network topology
              and network resources and exports this to network nodes and/or
              a centralized controller as required.</t>
            </li>
            <li pn="section-4-5.2.2.2">
              <t indent="0" pn="section-4-5.2.2.2.1">Creates NRPs with the network resource and topology
              properties needed by the enhanced VPN services.</t>
            </li>
            <li pn="section-4-5.2.2.3">
              <t indent="0" pn="section-4-5.2.2.3.1">Distributes the attributes of NRPs to network nodes that
              participate in the NRPs and/or a centralized controller.</t>
            </li>
            <li pn="section-4-5.2.2.4">
              <t indent="0" pn="section-4-5.2.2.4.1">Computes and sets up network paths in each NRP.</t>
            </li>
            <li pn="section-4-5.2.2.5">
              <t indent="0" pn="section-4-5.2.2.5.1">Maps enhanced VPN services to an appropriate NRP.</t>
            </li>
            <li pn="section-4-5.2.2.6">
              <t indent="0" pn="section-4-5.2.2.6.1">Determines the risk of SLA violation and takes appropriate
              avoidance/correction actions.</t>
            </li>
            <li pn="section-4-5.2.2.7">
              <t indent="0" pn="section-4-5.2.2.7.1">Considers the right balance of per-packet and per-node state
              according to the needs of the enhanced VPN services to scale to
              the required size.</t>
            </li>
          </ul>
        </li>
        <li pn="section-4-5.3">
          <t indent="0" pn="section-4-5.3.1">The management plane includes management interfaces, the
          OAM and telemetry
          mechanisms. More specifically, it provides:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5.3.2">
            <li pn="section-4-5.3.2.1">
              <t indent="0" pn="section-4-5.3.2.1.1">An interface between the enhanced VPN service provider (e.g.,
              the operator's network management system) and the enhanced VPN
              customer (e.g., an organization or service with an enhanced VPN
              requirement) such that the requests for specific operations and the related
              parameters can be exchanged without the awareness of other
              enhanced VPN customers.</t>
            </li>
            <li pn="section-4-5.3.2.2">
              <t indent="0" pn="section-4-5.3.2.2.1">An interface between the enhanced VPN service provider and
              the enhanced VPN customers to expose the network capability
              information toward the customer.</t>
            </li>
            <li pn="section-4-5.3.2.3">
              <t indent="0" pn="section-4-5.3.2.3.1">The service life-cycle management and operation of enhanced
              VPN services (e.g., creation, modification,
              assurance/monitoring, and decommissioning).</t>
            </li>
            <li pn="section-4-5.3.2.4">
              <t indent="0" pn="section-4-5.3.2.4.1">The OAM tools to verify whether the underlay network
              resources (i.e., NRPs) are correctly allocated and operating
              properly.</t>
            </li>
            <li pn="section-4-5.3.2.5">
              <t indent="0" pn="section-4-5.3.2.5.1">The OAM tools to verify the connectivity and monitor the
              performance of the enhanced VPN service.</t>
            </li>
            <li pn="section-4-5.3.2.6">
              <t indent="0" pn="section-4-5.3.2.6.1">Telemetry of information in the underlay network for overall
              performance evaluation and the planning of the enhanced VPN
              services.</t>
            </li>
            <li pn="section-4-5.3.2.7">
              <t indent="0" pn="section-4-5.3.2.7.1">Telemetry of information of enhanced VPN services for
              monitoring and analytics of the characteristics and SLA
              fulfillment of the enhanced VPN services.</t>
            </li>
          </ul>
        </li>
      </ul>
      <section anchor="COMLAY" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-layered-architecture">Layered Architecture</name>
        <t indent="0" pn="section-4.1-1">The layered architecture of NRP-based enhanced VPNs is shown in
        <xref target="LAFIG" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
        <t indent="0" pn="section-4.1-2">Underpinning everything is the physical network infrastructure
        layer, which provides the underlying resources used to provision the
        separate NRPs. This layer is responsible for the partitioning of link
        and/or node resources for different NRPs. Each subset of a link or node
        resource can be considered to be a virtual link or virtual node used to
        build the NRPs.</t>
        <figure anchor="LAFIG" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-the-layered-architecture-of">The Layered Architecture of Enhanced VPNs</name>
          <artwork align="center" name="" type="" alt="" pn="section-4.1-3.1">
                           /\
                           ||
                 +-------------------+       Centralized
                 | Network Controller|   Control &amp; Management
                 +-------------------+
                           ||
                           \/
             o---------------------------o   Enhanced VPN #1
                           /-------------o
             o____________/______________o   Enhanced VPN #2
                        _________________o
                  _____/
             o___/     \_________________o   Enhanced VPN #3
                 \_______________________o
                        ......                  ...
             o-----------\ /-------------o
             o____________X______________o   Enhanced VPN #n

                __________________________
               /       o----o-----o      /
              /       /          /      /       NRP-1
             / o-----o-----o----o----o /
            /_________________________/
                __________________________
               /       o----o            /
              /       /    / \          /       NRP-2
             / o-----o----o---o------o /
            /_________________________/
                      ......                     ...
               ___________________________
              /             o----o       /
             /             /    /       /       NRP-m
            /  o-----o----o----o-----o /
           /__________________________/


              ++++   ++++   ++++
              +--+===+--+===+--+
              +--+===+--+===+--+
              ++++   +++\\  ++++
               ||     || \\  ||                Physical
               ||     ||  \\ ||                Network
       ++++   ++++   ++++  \\+++   ++++     Infrastructure
       +--+===+--+===+--+===+--+===+--+
       +--+===+--+===+--+===+--+===+--+
       ++++   ++++   ++++   ++++   ++++

  o    Virtual Node     ++++
                        +--+  Physical Node with resource partition
  --   Virtual Link     +--+
                        ++++
  ==  Physical Link with resource partition
          </artwork>
        </figure>
        <t indent="0" pn="section-4.1-4">Various components and techniques discussed in <xref target="SDDC" format="default" sectionFormat="of" derivedContent="Section 5"/> can be used to enable resource partitioning of the
        physical network infrastructure, such as FlexE, TSN, dedicated queues,
        etc. These partitions may be physical or virtual so long as the SLA
        required by the higher layers is met.</t>
        <t indent="0" pn="section-4.1-5">Based on the set of NRPs provided by the
        physical network infrastructure, multiple NRPs can be created. Each of these NRPs:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.1-6">
          <li pn="section-4.1-6.1">has a set of dedicated or shared network resources allocated from the
        physical underlay network,</li>
          <li pn="section-4.1-6.2">can be associated with a
        customized logical network topology, and</li>
          <li pn="section-4.1-6.3">meets the requirements of a specific enhanced VPN service or
	a specific group of enhanced VPN services.</li>
        </ul>
        <t indent="0" pn="section-4.1-7">According to the associated logical network topology, each
        NRP needs to be instantiated on a set of network nodes and links that
        are involved in the logical topology. On each node or link, each
        NRP is associated with a set of local resources that are allocated
        for the processing of traffic in the NRP. The NRP provides the
        integration between the logical network topology and the required
      underlying network resources.</t>
        <t indent="0" pn="section-4.1-8">According to the service requirements of connectivity, performance,
        isolation, etc., enhanced VPN services can be mapped to the
        appropriate NRPs in the network. Different enhanced VPN services can
        be mapped to different NRPs; it is also possible that multiple
        enhanced VPN services are mapped to the same NRP. Thus, the NRP is an
        essential scaling technique as it has the potential of eliminating
        per-service per-path state from the network. In addition, when a group
        of enhanced VPN services is mapped to a single NRP, only the network
        state of the single NRP needs to be maintained in the network (see
        <xref target="scalable-mapping" format="default" sectionFormat="of" derivedContent="Section 4.4"/> for more information).</t>
        <t indent="0" pn="section-4.1-9">The network controller is responsible for creating an NRP,
        instructing the involved network nodes to allocate network resources
        to the NRP, and provisioning the enhanced VPN services on the NRP. A
        distributed control plane may be used for distributing the NRP
        resource and topology attributes among nodes in the NRP. Extensions to
        distributed control protocols (if any) are out of the scope of this
        document.</t>
        <t indent="0" pn="section-4.1-10">The process used to create NRPs and to allocate network resources
        for use by the NRPs needs to take a holistic view of the needs of all
        of the service provider's customers and to partition the resources
        accordingly. However, within an NRP, these resources can
        be managed via a dynamic control plane if required. This provides the required
        scalability and isolation with some flexibility.</t>
      </section>
      <section anchor="multi-point-to-multi-point" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-connectivity-types">Connectivity Types</name>
        <t indent="0" pn="section-4.2-1">At the VPN service level, the required connectivity for a Multipoint-to-Multipoint (MP2MP)
        VPN service is usually full or partial mesh. To support such VPN
        services, the corresponding NRP also needs to provide MP2MP
        connectivity among the endpoints.</t>
        <t indent="0" pn="section-4.2-2">Other service requirements may be expressed at different
        granularities, some of which can be applicable to the whole service
        while others may only be applicable to some pairs of endpoints.
        For example, when a particular level of performance guarantee is
        required, the point-to-point path through the underlying NRP of the
        enhanced VPN service may need to be specifically engineered to meet
        the required performance guarantee.</t>
      </section>
      <section anchor="application-specific-network-types" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-application-specific-data-t">Application-Specific Data Types</name>
        <t indent="0" pn="section-4.3-1">Although a lot of the traffic that will be carried over enhanced
        VPN will likely be IP based, the design must be capable of carrying
        other traffic types, in particular Ethernet traffic. This is easily
        accomplished through various pseudowire (PW) techniques <xref target="RFC3985" format="default" sectionFormat="of" derivedContent="RFC3985"/>.</t>
        <t indent="0" pn="section-4.3-2">Where the underlay is MPLS, Ethernet traffic can be carried over an
        enhanced VPN encapsulated according to the method specified in <xref target="RFC4448" format="default" sectionFormat="of" derivedContent="RFC4448"/>. Where the underlay is IP, L2 Tunneling
        Protocol - Version 3 (L2TPv3) <xref target="RFC3931" format="default" sectionFormat="of" derivedContent="RFC3931"/> can be used
        with Ethernet traffic carried according to <xref target="RFC4719" format="default" sectionFormat="of" derivedContent="RFC4719"/>.
        Encapsulations have been defined for most of the common L2 types
        for both PW over MPLS and for L2TPv3.</t>
      </section>
      <section anchor="scalable-mapping" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-scalable-service-mapping">Scalable Service Mapping</name>
        <t indent="0" pn="section-4.4-1">VPNs are instantiated as overlays on top of an operator's network
        and offered as services to the operator's customers. An important
        feature of overlays is that they can deliver services without placing
        per-service state in the core of the underlay network.</t>
        <t indent="0" pn="section-4.4-2">An enhanced VPN may need to install some additional state within
        the network to achieve the features that they require. Solutions need
        to take the scale of such state into consideration, and deployment
        architectures should constrain the number of enhanced VPN services so
        that the additional state introduced to the network is acceptable and
        under control. It is expected that the number of enhanced VPN services
        will be small at the beginning: even in the future, the number of
        enhanced VPN services will be fewer than conventional VPNs because
        existing VPN techniques are good enough to meet the needs of most
        existing VPN-type services.</t>
        <t indent="0" pn="section-4.4-3">In general, it is not required that the state in the network be
        maintained in a 1:1 relationship with the enhanced VPN services. It
        will usually be possible to aggregate a set or group of enhanced VPN
        services so that they share the same NRP and the same set of network
        resources (much in the same way that current VPNs are aggregated over
        transport tunnels) so that collections of enhanced VPN services that
        require the same behavior from the network in terms of resource
        reservation, latency bounds, resiliency, etc. can be grouped together.
        This is an important feature to assist with the scaling
        characteristics of NRP-based enhanced VPN deployments.</t>
        <t indent="0" pn="section-4.4-4"><xref target="I-D.ietf-teas-nrp-scalability" format="default" sectionFormat="of" derivedContent="NRP-SCALABILITY"/> provides more
        details of scalability considerations for the NRPs used to instantiate
        NRPs, and <xref target="scalability-considerations" format="default" sectionFormat="of" derivedContent="Section 7"/> includes a
        greater discussion of scalability considerations.</t>
      </section>
    </section>
    <section anchor="SDDC" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-candidate-technologies">Candidate Technologies</name>
      <t indent="0" pn="section-5-1">A VPN is created by applying a demultiplexing technique to the
      underlying network (the underlay) to distinguish the traffic of one VPN
      from that of another. The connections of a VPN are supported by a set of
      underlay paths. Any path other than the shortest path through the
      underlay normally requires state to specify that path. The state of the
      paths could be applied to the underlay through the use of the RSVP-TE
      signaling protocol or directly through the use of a Software-Defined
      Networking (SDN) controller. Based on Segment Routing (SR), state could
      be maintained at the ingress node of the path and carried in the data
      packet. Other techniques may emerge as this problem is studied.  This
      state gets harder to manage as the number of paths increases.
      Furthermore, as we increase the coupling between the underlay and the
      overlay to support the enhanced VPN service, this state is likely to
      increase further. Through the use of NRP, a subset of underlay network
      resources can be either dedicated for a particular enhanced VPN service
      or shared among a group of enhanced VPN services. A group of underlay
      paths can be established using the common set of network resources of
      the NRP.</t>
      <t indent="0" pn="section-5-2">This section describes the candidate technologies and examines them
      in the context of the different network planes that may be used together
      to build NRPs. <xref target="L2-DP" format="default" sectionFormat="of" derivedContent="Section 5.1"/> discusses the L2 packet-based
      or frame-based forwarding-plane mechanisms for resource partitioning.
      <xref target="NW-DP" format="default" sectionFormat="of" derivedContent="Section 5.2"/> discusses the corresponding encapsulation and
      forwarding mechanisms in the network layer. Non-packet data plane
      mechanisms are briefly discussed in <xref target="Non-Packet-DP" format="default" sectionFormat="of" derivedContent="Section 5.3"/>. The
      control plane and management plane mechanisms are discussed in Sections <xref target="control-plane" format="counter" sectionFormat="of" derivedContent="5.4"/> and <xref target="management-plane" format="counter" sectionFormat="of" derivedContent="5.5"/>, respectively.</t>
      <section anchor="L2-DP" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-underlay-forwarding-resourc">Underlay Forwarding Resource Partitioning</name>
        <t indent="0" pn="section-5.1-1">Several candidate L2 packet-based or frame-based forwarding-plane mechanisms that can provide the required traffic isolation and
        performance guarantees are described in the following sections.</t>
        <section anchor="flexe" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1">
          <name slugifiedName="name-flex-ethernet">Flex Ethernet</name>
          <t indent="0" pn="section-5.1.1-1">FlexE <xref target="FLEXE" format="default" sectionFormat="of" derivedContent="FLEXE"/> provides the
	  ability to multiplex channels over an Ethernet link to create
	  point-to-point fixed-bandwidth connections in a way that provides
	  separation between enhanced VPN services. FlexE also supports
	  bonding multiple low-capacity links to create larger
	  links.</t>
          <t indent="0" pn="section-5.1.1-2">However, FlexE is only a link-level technology. When packets are
	  received by the downstream node, they need to be processed in a way
	  that preserves traffic isolation. In turn, this requires a queuing
	  and forwarding implementation that preserves the end-to-end
	  separation of enhanced VPNs.</t>
          <t indent="0" pn="section-5.1.1-3">If different FlexE channels are
	  used for different services, then no sharing is possible between the
	  FlexE channels. Thus, it may be difficult to dynamically
	  redistribute unused bandwidth to lower priority services in another
	  FlexE channel. If one FlexE channel is used by one customer, the
	  customer can use some methods to manage the relative priority of
	  their own traffic in the FlexE channel.</t>
        </section>
        <section anchor="dedicated-queues" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2">
          <name slugifiedName="name-dedicated-queues">Dedicated Queues</name>
          <t indent="0" pn="section-5.1.2-1">Diffserv-based queuing systems are described in <xref target="RFC2475" format="default" sectionFormat="of" derivedContent="RFC2475"/> and <xref target="RFC4594" format="default" sectionFormat="of" derivedContent="RFC4594"/>. This approach is
          not sufficient to provide separation of enhanced VPN services
          because Diffserv does not provide enough markers to differentiate
          between traffic of a large number of enhanced VPN services.
          Additionally, Diffserv does not offer the range of service classes
          that each enhanced VPN service needs to provide to its tenants. This
          problem is particularly acute with an MPLS underlay because MPLS
          only provides eight traffic classes.</t>
          <t indent="0" pn="section-5.1.2-2">In addition, Diffserv, as currently implemented, mainly provides
          per- hop priority-based scheduling, and it is difficult to use it to
          achieve quantitative resource reservation for different enhanced VPN
          services.</t>
          <t indent="0" pn="section-5.1.2-3">To address these problems and to reduce the potential
          interactions between enhanced VPN services, it would be necessary to
          steer traffic to dedicated input and output queues per enhanced VPN
          service or per group of enhanced VPN services: some routers have a
          large number of queues and sophisticated queuing systems that could
          support this while some routers may struggle to provide the
          granularity and level of separation required by the applications of
          an enhanced VPN.</t>
        </section>
        <section anchor="time-sensitive-networking" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.3">
          <name slugifiedName="name-time-sensitive-networking">Time-Sensitive Networking</name>
          <t indent="0" pn="section-5.1.3-1"><xref target="TSN" format="default" sectionFormat="of" derivedContent="TSN"/> is an IEEE
          project to provide a method of carrying time-sensitive information
          over Ethernet. It introduces the concept of packet scheduling where
          a packet stream may be given a time slot guaranteeing that it will
          experience no queuing delay or increase in latency beyond a very
          small scheduling delay. The mechanisms defined in TSN can be used to
          meet the requirements of time-sensitive traffic flows of enhanced
          VPN service.</t>
          <t indent="0" pn="section-5.1.3-2">Ethernet can be emulated over a L3 network using an IP or
          MPLS pseudowire. However, a TSN Ethernet payload would be opaque to
          the underlay; thus, it would not be treated specifically as time-sensitive
          data. The preferred method of carrying TSN over a L3 network is
          through the use of DetNet as explained in <xref target="deterministic-networking" format="default" sectionFormat="of" derivedContent="Section 5.2.1"/>.</t>
        </section>
      </section>
      <section anchor="NW-DP" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-network-layer-encapsulation">Network Layer Encapsulation and Forwarding</name>
        <t indent="0" pn="section-5.2-1">This section considers the problem of enhanced VPN service
        differentiation and the representation of underlying network resources
        in the network layer. More specifically, it describes the possible
        data plane mechanisms to determine the network resources and the
        logical network topology or paths associated with an NRP.</t>
        <section anchor="deterministic-networking" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.1">
          <name slugifiedName="name-deterministic-networking-de">Deterministic Networking (DetNet)</name>
          <t indent="0" pn="section-5.2.1-1">DetNet <xref target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655"/> is a
          technique being developed in the IETF to enhance the ability of
          L3 networks to deliver packets more reliably and with greater
          control over the delay. The design cannot use retransmission
          techniques such as TCP because that can exceed the delay tolerated by
          the applications. DetNet preemptively sends copies of the packet
          over various paths to minimize the chance of all copies of a packet
          being lost. It also seeks to set an upper bound on latency, but the
          goal is not to minimize latency. DetNet can be realized over the IP data
          plane <xref target="RFC8939" format="default" sectionFormat="of" derivedContent="RFC8939"/> or the MPLS data plane <xref target="RFC8964" format="default" sectionFormat="of" derivedContent="RFC8964"/>, and it may be used to provide deterministic paths
          for enhanced VPN services.</t>
        </section>
        <section anchor="mpls-traffic-engineering-mpls-te" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.2">
          <name slugifiedName="name-mpls-traffic-engineering-mp">MPLS Traffic Engineering (MPLS-TE)</name>
          <t indent="0" pn="section-5.2.2-1">MPLS-TE (see <xref target="RFC2702" format="default" sectionFormat="of" derivedContent="RFC2702"/> and <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>)
          introduces the concept of reserving end-to-end bandwidth for a
          TE-LSP, which can be used to provide a set of point-to-point
          resource-reserved paths across the underlay network to support VPN
          services. VPN traffic can be carried over dedicated TE-LSPs to
          provide guaranteed bandwidth for each specific connection in a VPN,
          and VPNs with similar behavior requirements may be multiplexed onto
          the same TE-LSPs. Some network operators have concerns about the
          scalability and management overhead of MPLS-TE system, especially
          with regard to those systems that use an active control plane, and
          this has lead them to consider other solutions for TE in their networks.</t>
        </section>
        <section anchor="SR" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3">
          <name slugifiedName="name-segment-routing">Segment Routing</name>
          <t indent="0" pn="section-5.2.3-1">SR <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> is
          a method that prepends instructions to packets at the headend of a
          path. These instructions are used to specify the nodes and links to
          be traversed, and they allow the packets to be routed on paths other
          than the shortest path. By encoding the state in the packet,
          per-path state is transitioned out of the network. SR can be
          instantiated using the MPLS data plane (SR-MPLS) (see <xref target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>) or the IPv6 data plane (SRv6)
          (see <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>).</t>
          <t indent="0" pn="section-5.2.3-2">An SR traffic-engineered path operates with the granularity of a
          link. Hints about priority are provided using the Traffic Class (TC)
          field in the packet header. However, to achieve the performance and
          isolation characteristics that are sought by enhanced VPN customers,
          it will be necessary to steer packets through specific virtual links
          and/or queues on the same link and direct them to use specific
          resources. With SR, it is possible to introduce such fine-grained
          packet steering by specifying the queues and the associated
          resources through an SR instruction list. One approach to do this is
          described in <xref target="I-D.ietf-spring-resource-aware-segments" format="default" sectionFormat="of" derivedContent="RESOURCE-AWARE-SEGMENTS"/>.</t>
          <t indent="0" pn="section-5.2.3-3">Note that the concept of a queue is a useful abstraction for
          different types of underlay mechanisms that may be used to provide
          enhanced isolation and performance support. How the queue satisfies
          the requirement is implementation specific and is transparent to the
          L3 data plane and control plane mechanisms used.</t>
          <t indent="0" pn="section-5.2.3-4">With SR, the SR instruction list could be used to
          build a P2P SR path. In addition, a group of SR Segment Identifiers
          (SIDs) could also be used to represent an MP2MP network. Thus, the
          SR-based mechanism could be used to provide both resource-reserved
          paths and NRPs for enhanced VPN services.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2.4">
          <name slugifiedName="name-new-encapsulation-extension">New Encapsulation Extensions</name>
          <t indent="0" pn="section-5.2.4-1">In contrast to reusing an existing data plane for enhanced VPN,
          another possible approach is to introduce new encapsulations or
          extensions to an existing data plane to allow dedicated identifiers for
          the underlay network resources of an enhanced VPN and the logical
          network topology or paths associated with an enhanced VPN. This may
          require more protocol work; however, the potential benefits are that it can
          reduce the impact to existing network operation and improve the
          scalability of enhanced VPN. More details about the encapsulation
          extensions and the scalability concerns are described in <xref target="I-D.ietf-teas-nrp-scalability" format="default" sectionFormat="of" derivedContent="NRP-SCALABILITY"/>.</t>
        </section>
      </section>
      <section anchor="Non-Packet-DP" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-non-packet-data-plane">Non-Packet Data Plane</name>
        <t indent="0" pn="section-5.3-1">Non-packet underlay data plane technologies, such as optical-based
        data planes, often have TE properties and behaviors. They meet many of
        the key requirements, particularly those for:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-5.3-2">
          <li pn="section-5.3-2.1">bandwidth guarantees,</li>
          <li pn="section-5.3-2.2">traffic
        isolation (with physical isolation often being an integral part of the
        technology),</li>
          <li pn="section-5.3-2.3">highly predictable latency and jitter characteristics,</li>
          <li pn="section-5.3-2.4">measurable loss characteristics, and</li>
          <li pn="section-5.3-2.5">ease of identification of flows.</li>
        </ul>
        <t indent="0" pn="section-5.3-3">The cost is that the resources are allocated on a long-term and
        end-to-end basis. Such an arrangement means that the full cost of the
        resources has to be borne by the client to which the resources are
        allocated. When an NRP built with this data plane is used to support
        multiple enhanced VPN services, the cost could be distributed among
        such a group of services.</t>
      </section>
      <section anchor="control-plane" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-control-plane">Control Plane</name>
        <t indent="0" pn="section-5.4-1">The control plane of NRP-based enhanced VPNs is likely be based on
        a hybrid control mechanism that takes advantage of a logically
        centralized controller for on-demand provisioning and global
        optimization while still relying on a distributed control plane to
        provide scalability, high reliability, fast reaction, automatic
        failure recovery, etc. Extension to and optimization of the
        centralized and distributed control plane is needed to support the
        enhanced properties of an NRP-based enhanced VPN.</t>
        <t indent="0" pn="section-5.4-2">As described in <xref target="architecture-and-components-of-vpn" format="default" sectionFormat="of" derivedContent="Section 4"/>, the enhanced VPN control plane needs to
        provide the following functions: </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.4-3">
          <li pn="section-5.4-3.1">
            <t indent="0" pn="section-5.4-3.1.1">Collection of information about the underlying network topology and
            network resources and exportation of this to network nodes and/or a
            centralized controller as required.</t>
          </li>
          <li pn="section-5.4-3.2">
            <t indent="0" pn="section-5.4-3.2.1">Creation of NRPs with the network resource and topology properties
            needed by NRP-based enhanced VPN services.</t>
          </li>
          <li pn="section-5.4-3.3">
            <t indent="0" pn="section-5.4-3.3.1">Distribution of the attributes of NRPs to network nodes that
            participate in the NRPs and/or the centralized controller.</t>
          </li>
          <li pn="section-5.4-3.4">
            <t indent="0" pn="section-5.4-3.4.1">Mapping of enhanced VPN services to an appropriate NRP.</t>
          </li>
          <li pn="section-5.4-3.5">
            <t indent="0" pn="section-5.4-3.5.1">Computation and set up of service paths in each NRP to meet enhanced
            VPN service requirements.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.4-4">Underlying network topology and resource
        information can be collected using mechanisms based on the existing IGP and Border Gateway
        Protocol - Link State (BGP-LS) <xref target="RFC9552" format="default" sectionFormat="of" derivedContent="RFC9552"/>. The creation of NRPs and the distribution of NRP
        attributes may need further control protocol extensions. The
        computation of service paths based on the attributes and constraints
        of the NRP can be performed either by the headend node of the path or
        by a centralized Path Computation Element (PCE) <xref target="RFC4655" format="default" sectionFormat="of" derivedContent="RFC4655"/>.</t>
        <t indent="0" pn="section-5.4-5">Two candidate control plane mechanisms for path setup in the NRP
        are RSVP-TE and SR.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.4-6">
          <li pn="section-5.4-6.1">
            <t indent="0" pn="section-5.4-6.1.1">RSVP-TE, as described in <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>, provides the signaling
            mechanism for establishing a TE-LSP in an MPLS network with
            end-to-end resource reservation. This can be seen as an approach
            of providing resource-reserved paths that could be used to bind
            the VPN to a specific set of network resources allocated within the
            underlay; however, there remain scalability concerns, as mentioned in
            <xref target="mpls-traffic-engineering-mpls-te" format="default" sectionFormat="of" derivedContent="Section 5.2.2"/>.</t>
          </li>
          <li pn="section-5.4-6.2">
            <t indent="0" pn="section-5.4-6.2.1">The SR control plane, as described in <xref target="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/>, <xref target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>, and <xref target="RFC9085" format="default" sectionFormat="of" derivedContent="RFC9085"/>, does not have the
            capability of signaling resource reservations along the path. On
            the other hand, the SR approach provides a potential way of
            binding the underlay network resource and the NRPs without
            requiring per-path state to be maintained in the network. A
            centralized controller can perform resource planning and
            reservation for NRPs, and it needs to instruct the network nodes
            to ensure that resources are correctly allocated for the NRP. The
            controller could provision the SR paths based on the mechanism in
            <xref target="RFC9256" format="default" sectionFormat="of" derivedContent="RFC9256"/> to the headend nodes of the paths.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.4-7">According to the service requirements for connectivity, performance,
        and isolation, one enhanced VPN service may be mapped to a dedicated
        NRP or a group of enhanced VPN services may be mapped to the same
        NRP. The mapping of enhanced VPN services to an NRP can be achieved using
        existing control mechanisms with possible extensions; it can be
        based on either the characteristics of the data packet or the
        attributes of the VPN service routes.</t>
      </section>
      <section anchor="management-plane" numbered="true" toc="include" removeInRFC="false" pn="section-5.5">
        <name slugifiedName="name-management-plane">Management Plane</name>
        <t indent="0" pn="section-5.5-1">The management plane provides the interface between the enhanced
        VPN service provider and the customers for life-cycle management of
        the enhanced VPN service (i.e., creation, modification,
        assurance/monitoring, and decommissioning). It relies on a set of
        service data models for the description of the information and
        operations needed on the interface.</t>
        <t indent="0" pn="section-5.5-2">As an example, in the context of 5G end-to-end network slicing
        <xref target="TS28530" format="default" sectionFormat="of" derivedContent="TS28530"/>, the management of the
        transport network segment of the 5G end-to-end network slice can be
        realized with the management plane of the enhanced VPN. The 3GPP
        management system may provide the connectivity and performance-related
        parameters as requirements to the management plane of the transport
        network. It may also require the transport network to expose the
        capabilities and status of the network slice. Thus, the coordination
        of 5G end-to-end network slice management requires an interface
        between the enhanced VPN management plane and the 5G network slice
        management system, and relevant service data models.</t>
        <t indent="0" pn="section-5.5-3">The management plane interface and data models for enhanced VPN
        services can be based on the service models described in <xref target="sdm-app" format="default" sectionFormat="of" derivedContent="Section 5.6"/>.</t>
        <t indent="0" pn="section-5.5-4">It is important that the life-cycle management support in-place
        modification of enhanced VPN services. That is, it should be possible
        to add and remove endpoints, as well as to change the requested
        characteristics of the service that is delivered. The management
        system needs to be able to assess the revised enhanced VPN requests
        and determine whether they can be provided by the existing NRPs or
        whether changes must be made. It will also need to
        determine whether those changes to the NRP are possible. If not, then
        the customer's modification request may be rejected.</t>
        <t indent="0" pn="section-5.5-5">When the modification of an enhanced VPN service is possible, the
        management system must make every effort to make the changes in a
        non-disruptive way. That is, the modification of the enhanced VPN
        service or the underlying NRP must not perturb traffic on the enhanced
        VPN service in a way that causes the service level to drop below the
        agreed levels. Furthermore, changes to one enhanced VPN service should
        not cause disruption to other enhanced VPN services.</t>
        <t indent="0" pn="section-5.5-6">The network operator for the underlay network (i.e., the provider
        of the enhanced VPN service) may delegate some operational aspects of
        the overlay VPN and the underlying NRP to the customer. In this way,
        the enhanced VPN is presented to the customer as a virtual network,
        and the customer can choose how to use that network. Some mechanisms
        in the operator's network are needed so that:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-5.5-7">
          <li pn="section-5.5-7.1">a customer cannot exceed
          the capabilities of the virtual links and nodes, but</li>
          <li pn="section-5.5-7.2">it can decide how to
        load traffic onto the network, for example, by assigning different
        metrics to the virtual links so that the customer can control how
          traffic is routed through the virtual network.</li>
        </ul>
        <t indent="0" pn="section-5.5-8">This approach requires
        a management system for the virtual network but does not necessarily
        require any coordination between the management systems of the virtual
        network and the physical network, except that the virtual network
        management system might notice when the NRP is close to capacity or
        considerably under-used and automatically request changes in the
        service provided by the underlay network.</t>
      </section>
      <section anchor="sdm-app" numbered="true" toc="include" removeInRFC="false" pn="section-5.6">
        <name slugifiedName="name-applicability-of-service-da">Applicability of Service Data Models to Enhanced VPNs</name>
        <t indent="0" pn="section-5.6-1">This section describes the applicability of the existing and
        in-progress service data models to enhanced VPNs. <xref target="RFC8309" format="default" sectionFormat="of" derivedContent="RFC8309"/> describes the scope and purpose of service models
        and shows where a service model might fit into an SDN-based network
        management architecture. New service models may also be introduced for
        some of the required management functions.</t>
        <t indent="0" pn="section-5.6-2">Service data models are used to represent, monitor, and manage the
        virtual networks and services enabled by enhanced VPNs. The VPN
        customer service models (e.g., the L3VPN Service Model (L3SM)
        in <xref target="RFC8299" format="default" sectionFormat="of" derivedContent="RFC8299"/>, the L2VPN Service Model (L2SM) in <xref target="RFC8466" format="default" sectionFormat="of" derivedContent="RFC8466"/>), or the ACTN VN model in <xref target="RFC9731" format="default" sectionFormat="of" derivedContent="RFC9731"/>) are service models that can
        provide the customer's view of the enhanced VPN service. The L3VPN
        Network Model (L3NM) from <xref target="RFC9182" format="default" sectionFormat="of" derivedContent="RFC9182"/> and the L2VPN
        Network Model (L2NM) from <xref target="RFC9291" format="default" sectionFormat="of" derivedContent="RFC9291"/> provide the operator's
        view of the managed infrastructure as a set of virtual networks and
        the associated resources. The Service Attachment Points (SAPs) model
        in <xref target="RFC9408" format="default" sectionFormat="of" derivedContent="RFC9408"/> provides an abstract view of the SAPs to various network services in the provider
        network, where enhanced VPN could be one of the service types. <xref target="RFC9375" format="default" sectionFormat="of" derivedContent="RFC9375"/> provides the data model for performance monitoring
        of network and VPN services. Augmentation to these service models may
        be needed to provide the enhanced VPN services. The NRP model in <xref target="I-D.ietf-teas-nrp-yang" format="default" sectionFormat="of" derivedContent="NRP-YANG"/> further provides the management of
        the NRP topology and resources both in the controller and in the
        network devices to instantiate the NRPs needed for the enhanced VPN
        services.</t>
      </section>
    </section>
    <section anchor="app-ns-realization" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-applicability-in-network-sl">Applicability in Network Slice Realization</name>
      <t indent="0" pn="section-6-1">This section describes the applicability of NRP-based enhanced VPN
      for network slice realization.</t>
      <t indent="0" pn="section-6-2">In order to provide network slice services to customers, a
      technology-agnostic network slice service model <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang" format="default" sectionFormat="of" derivedContent="NETWORK-SLICE-YANG"/> is needed for the
      customers to communicate the requirements of network slices (SDPs,
      connectivity, SLOs, and SLEs). These requirements may be realized using
      technology specified in this document to instruct the network to deliver
      an enhanced VPN service so as to meet the requirements of the network
      slice customers. According to the location of SDPs used for the network
      slice service (see <xref target="RFC9543" sectionFormat="of" section="5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9543#section-5.2" derivedContent="RFC9543"/>), an SDP can
      be mapped to a Customer Edge (CE), a PE, a port on a CE, or a customer-facing port on a
      PE, any of which can be correlated to the endpoint of the enhanced VPN
      service. The detailed approach for SDP mapping is described in <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang" format="default" sectionFormat="of" derivedContent="NETWORK-SLICE-YANG"/>.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-nrp-planning">NRP Planning</name>
        <t indent="0" pn="section-6.1-1">An NRP is used to support the SLOs and SLEs required by the network
        slice services. According to the network operators' network resource
        planning policy, or based on the requirements of one or a group of
        customers or services, an NRP may need to be created to meet the
        requirements of network slice services. One of the basic requirements
        for the NRP is to provide a set of dedicated network resources to
        avoid unexpected interference from other services in the same network.
        Other possible requirements may include the required topology and
        connectivity, bandwidth, latency, reliability, etc.</t>
        <t indent="0" pn="section-6.1-2">A centralized network controller can be responsible for calculating
        a subset of the underlay network topology (which is called a logical
        topology) to support the NRP requirement. On the network nodes and
        links within the logical topology, the set of network resources to be
        allocated to the NRP can also be determined by the controller.
        Normally, such calculation needs to take the underlay network
        connectivity information and the available network resource
        information of the underlay network into consideration. The network
        controller may also take the status of the existing NRPs into
        consideration in the planning and calculation of a new NRP.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-nrp-creation">NRP Creation</name>
        <t indent="0" pn="section-6.2-1">According to the result of the NRP planning, the network nodes and
        links involved in the logical topology of the NRP are instructed to
        allocate the required set of network resources for the NRP. One or
        multiple mechanisms as specified in <xref target="L2-DP" format="default" sectionFormat="of" derivedContent="Section 5.1"/> can be used to
        partition the forwarding-plane network resources and allocate
        different subsets of resources to different NRPs. In addition, the
        data plane identifiers that are used to identify the set of network
        resources allocated to the NRP are also provisioned on the network
        nodes. Depending on the data plane technologies used, the set of
        network resources of an NRP can be identified using, e.g.,
        resource-aware SR segments as specified in <xref target="I-D.ietf-spring-resource-aware-segments" format="default" sectionFormat="of" derivedContent="RESOURCE-AWARE-SEGMENTS"/> and <xref target="I-D.ietf-spring-sr-for-enhanced-vpn" format="default" sectionFormat="of" derivedContent="SR-ENHANCED-VPN"/> or a dedicated
        Resource ID as specified in <xref target="I-D.ietf-6man-enhanced-vpn-vtn-id" format="default" sectionFormat="of" derivedContent="IPv6-NRP-OPTION"/> can be introduced. The
        network nodes involved in an NRP may distribute the logical topology
        information, the NRP-specific network resource information, and the
        Resource ID of the NRP using the control plane. Such
        information could be used by the controller and the network nodes to
        compute the TE or shortest paths within the NRP and to install the NRP-specific forwarding entries to network nodes.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-network-slice-service-provi">Network Slice Service Provisioning</name>
        <t indent="0" pn="section-6.3-1">According to the connectivity requirements of a network slice
        service, an overlay VPN can be created using the existing or future
        multi-tenancy overlay technologies as described in <xref target="applicability" format="default" sectionFormat="of" derivedContent="Section 3.6"/>.</t>
        <t indent="0" pn="section-6.3-2">Then, according to the SLO and SLE requirements of a network slice
        service, the network slice service is mapped to an appropriate NRP as
        the virtual underlay. The integration of the overlay VPN and the
        underlay NRP provides a network slice service.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-network-slice-traffic-steer">Network Slice Traffic Steering and Forwarding</name>
        <t indent="0" pn="section-6.4-1">At the edge of the operator's network, network slice traffic
        can be classified based on the rules defined by the operator's policy;
        this is so that the traffic that matches the rules for specific network slice
        services can be mapped to the corresponding NRP. Thus, packets
        belonging to a specific network slice service will be processed and
        forwarded by network nodes based on either:</t>
        <ul spacing="compact" bare="false" empty="false" indent="3" pn="section-6.4-2">
          <li pn="section-6.4-2.1">the traffic-engineered paths or</li>
          <li pn="section-6.4-2.2">the shortest paths in the associated network topology</li>
        </ul>
        <t indent="0" pn="section-6.4-3">using the
        set of network resources of the corresponding NRP.</t>
      </section>
    </section>
    <section anchor="scalability-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-scalability-considerations">Scalability Considerations</name>
      <t indent="0" pn="section-7-1">NRP-based enhanced VPNs provide performance guaranteed services in
      packet networks; however, this comes with the potential cost of introducing additional
      state into the network. There are at least three ways that this
      additional state might be added:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-2">
        <li pn="section-7-2.1">
          <t indent="0" pn="section-7-2.1.1">by introducing the complete state into the packet, as is done in SR.
          This allows the controller to specify the detailed series of
          forwarding and processing instructions for the packet as it transits
          the network. The cost of this is an increase in the packet header
          size. A further cost is that systems will have to provide NRP-specific segments in case they are called upon by a service. This is
          a type of latent state, and it increases as the segments and resources
          that need to be exclusively available to enhanced VPN service are
          specified more precisely.</t>
        </li>
        <li pn="section-7-2.2">
          <t indent="0" pn="section-7-2.2.1">by introducing the state to the network. This is normally done by
          creating a path using signaling such as RSVP-TE. This could be
          extended to include any element that needs to be specified along the
          path, for example, explicitly specifying queuing policy. It is also
          possible to use other methods to introduce path state, such as via
          an SDN controller or possibly by modifying a routing protocol. With
          this approach, there is state per path: a per-path characteristic that
          needs to be maintained over the life of the path. This is more
          network state than is needed using SR, but the packets are usually
          shorter.</t>
        </li>
        <li pn="section-7-2.3">
          <t indent="0" pn="section-7-2.3.1">by providing a hybrid approach. One example is based on using binding
          SIDs (see <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>) to represent path fragments and binding
          them together with SR. Dynamic creation of a VPN service path using
          SR requires less state maintenance in the network core at the
          expense of larger packet headers. The packet size can be lower if a
          form of loose source routing is used (using a few nodal SIDs), and
          it will be lower if no specific functions or resources on the
          routers are specified. For Segment Routing over IPv6 (SRv6), the packet size may also be reduced
          by utilizing the compression techniques specified in <xref target="I-D.ietf-spring-srv6-srh-compression" format="default" sectionFormat="of" derivedContent="SRv6-SRH-COMPRESSION"/>.</t>
        </li>
      </ul>
      <t indent="0" pn="section-7-3">Reducing the state in the network is important to the deployment of
      enhanced VPNs, as they require the overlay to be more closely integrated
      with the underlay than with conventional VPNs. This tighter coupling
      would normally mean that more state needs to be created and maintained
      in the network, as state about fine-granularity processing would need to
      be loaded and maintained in the routers. Aggregation is a
      well-established approach to reduce the amount of state and improve
      scaling, and NRP is considered to be the network construct to aggregate
      the states of enhanced VPN services.  In addition, an SR approach allows
      much of the state to be spread amongst the network ingress nodes and
      transiently carried in the packets as SIDs.</t>
      <t indent="0" pn="section-7-4">The following subsections describe some of the scalability concerns
      that need to be considered. Further discussion of the scalability
      considerations of the underlaying network constructs of NRP-based
      enhanced VPNs can be found in <xref target="I-D.ietf-teas-nrp-scalability" format="default" sectionFormat="of" derivedContent="NRP-SCALABILITY"/>.</t>
      <section anchor="maximum-stack-depth" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-maximum-stack-depth-of-sr">Maximum Stack Depth of SR</name>
        <t indent="0" pn="section-7.1-1">One of the challenges with SR is the stack depth that nodes are
        able to impose on packets <xref target="RFC8491" format="default" sectionFormat="of" derivedContent="RFC8491"/>. This leads to a
        difficult balance between:</t>
        <ul spacing="compact" bare="false" empty="false" indent="3" pn="section-7.1-2">
          <li pn="section-7.1-2.1">adding state to the network and minimizing
          stack depth and</li>
          <li pn="section-7.1-2.2">minimizing state and increasing the stack depth.</li>
        </ul>
      </section>
      <section anchor="rsvp-scalability" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-rsvp-te-scalability">RSVP-TE Scalability</name>
        <t indent="0" pn="section-7.2-1">The established method of creating a resource-reserved path through
        an MPLS network is to use the RSVP-TE protocol. However, there have
        been concerns that this requires significant continuous state
        maintenance in the network. Work to improve the scalability of RSVP-TE
        LSPs in the control plane can be found in <xref target="RFC8370" format="default" sectionFormat="of" derivedContent="RFC8370"/>.</t>
        <t indent="0" pn="section-7.2-2">There is also concern at the scalability of the forwarder footprint
        of RSVP-TE as the number of paths through a Label Switching Router
        (LSR) grows. <xref target="RFC8577" format="default" sectionFormat="of" derivedContent="RFC8577"/> addresses this by employing SR
        within a tunnel established by RSVP-TE.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-sdn-scaling">SDN Scaling</name>
        <t indent="0" pn="section-7.3-1">The centralized SDN-based approach requires control plane state to be
        stored in the network, but can reduce the overhead of control channels
        to be maintained. Each individual network node may need to maintain a
        control channel with an SDN controller, which is considered more
        scalable compared to the need of maintaining control channels with a
        set of neighbor nodes.</t>
        <t indent="0" pn="section-7.3-2">However, SDN may transfer some of the scalability concerns from the
        network to a centralized controller. In particular, there may be a
        heavy processing burden at the controller and a heavy load in the
        network surrounding the controller. A centralized controller may also
        present a single point of failure within the network.</t>
      </section>
    </section>
    <section anchor="enhanced-resiliency" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-enhanced-resiliency">Enhanced Resiliency</name>
      <t indent="0" pn="section-8-1">Each enhanced VPN service has a life cycle and may need modification
      during deployment as the needs of its tenant change (see <xref target="management-plane" format="default" sectionFormat="of" derivedContent="Section 5.5"/>). Additionally, as the network
      evolves, garbage collection may need to be performed to consolidate
      resources into usable quanta.</t>
      <t indent="0" pn="section-8-2">Systems in which the path is imposed, such as SR or some form of
      explicit routing, tend to do well in these applications because it is
      possible to perform an atomic transition from one path to another. That
      is, a single action by the headend that changes the path without the
      need for coordinated action by the routers along the path. However,
      implementations and the monitoring protocols need to make sure that the
      new path is operational and meets the required SLA before traffic is
      transitioned to it. It is possible for deadlocks to arise as a result of
      the network becoming fragmented over time, such that it is impossible to
      create a new path or to modify an existing path without impacting the
      SLA of other paths. The global concurrent optimization mechanisms as
      described in <xref target="RFC5557" format="default" sectionFormat="of" derivedContent="RFC5557"/> and discussed in
      <xref target="RFC7399" format="default" sectionFormat="of" derivedContent="RFC7399"/> may be helpful, while complete
      resolution of this situation is as much a commercial issue as it is a
      technical issue.</t>
      <t indent="0" pn="section-8-3">However, there are two manifestations of the latency problem that
      are for further study in any of these approaches:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-4">
        <li pn="section-8-4.1">
          <t indent="0" pn="section-8-4.1.1">Packets overtaking one another if path latency
          reduces during a transition.</t>
        </li>
        <li pn="section-8-4.2">
          <t indent="0" pn="section-8-4.2.1">Transient variation in latency in either direction
          as a path migrates.</t>
        </li>
      </ul>
      <t indent="0" pn="section-8-5">There is also the matter of what happens during failure in the
      underlay infrastructure. Fast reroute is one approach, but that still
      produces a transient loss with a normal goal of rectifying this within
      50 ms <xref target="RFC5654" format="default" sectionFormat="of" derivedContent="RFC5654"/>. An alternative is some form of N+1
      delivery such as has been used for many years to support protection from
      service disruption. This may be taken to a different level using the
      techniques of DetNet with multiple in-network replications and the
      culling of later packets <xref target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655"/>.</t>
      <t indent="0" pn="section-8-6">In addition to the approach used to protect high-priority packets,
      consideration should be given to the impact of best-effort traffic on
      the high-priority packets during a transition. Specifically, if a
      conventional re-convergence process is used, there will inevitably be
      micro-loops and, while some form of explicit routing will protect the
      high-priority traffic, lower-priority traffic on best-effort shortest
      paths will micro-loop without the use of a loop-prevention technology.
      To provide the highest quality of service to high-priority traffic,
      either this traffic must be shielded from the micro-loops or
      micro-loops must be prevented completely.</t>
    </section>
    <section anchor="oam-and-instrumentation" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <t indent="0" pn="section-9-1">This section describes the considerations about the OAM and telemetry
      mechanisms used to support the verification, monitoring, and optimization
      of the characteristics and SLA fulfillment of NRP-based enhanced VPN
      services. It should be read along with <xref target="management-plane" format="default" sectionFormat="of" derivedContent="Section 5.5"/>, which gives consideration to the management plane techniques that can be
      used to build NRPs.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-oam-considerations">OAM Considerations</name>
        <t indent="0" pn="section-9.1-1">The following requirements need to be considered in the design of
        OAM for enhanced VPN services:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9.1-2">
          <li pn="section-9.1-2.1">
            <t indent="0" pn="section-9.1-2.1.1">Instrumentation of the NRP (the virtual underlay) so that the
            network operator can be sure that the resources committed to a
            customer are operating correctly and delivering the required
            performance. It is important that the OAM packets follow the same
            path and set of resources as the service packets mapped to the
            NRP.</t>
          </li>
          <li pn="section-9.1-2.2">
            <t indent="0" pn="section-9.1-2.2.1">Instrumentation of the overlay by the customer. This is likely
            to be transparent to the network operator and to use existing
            methods. Particular consideration needs to be given to the need to
            verify the various committed performance characteristics.</t>
          </li>
          <li pn="section-9.1-2.3">
            <t indent="0" pn="section-9.1-2.3.1">Instrumentation of the overlay by the service provider to
            proactively demonstrate that the committed performance is being
            delivered. This needs to be done in a non-intrusive manner,
            particularly when the tenant is deploying a performance-sensitive
            application.</t>
          </li>
        </ul>
        <t indent="0" pn="section-9.1-3">A study of OAM in SR networks is documented in <xref target="RFC8403" format="default" sectionFormat="of" derivedContent="RFC8403"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-9.2">
        <name slugifiedName="name-telemetry-considerations">Telemetry Considerations</name>
        <t indent="0" pn="section-9.2-1">Network visibility is essential for network operation. Network
        telemetry has been considered to be an ideal means to gain sufficient
        network visibility with better flexibility, scalability, accuracy,
        coverage, and performance than conventional OAM technologies.</t>
        <t indent="0" pn="section-9.2-2">As defined in <xref target="RFC9232" format="default" sectionFormat="of" derivedContent="RFC9232"/>, the
        objective of network telemetry is to acquire network data remotely for
        network monitoring and operation. It is a general term for a large set
        of network visibility techniques and protocols. Network telemetry
        addresses the current network operation issues and enables smooth
        evolution toward intent-driven autonomous networks. Telemetry can be
        applied on the forwarding plane, the control plane, and the management
        plane in a network. The following requirements need to be considered
        for telemetry for enhanced VPN service:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9.2-3">
          <li pn="section-9.2-3.1">
            <t indent="0" pn="section-9.2-3.1.1">Collecting data of NRPs for overall performance evaluation and
            the planning of the enhanced VPN services.</t>
          </li>
          <li pn="section-9.2-3.2">
            <t indent="0" pn="section-9.2-3.2.1">Collecting data of each enhanced VPN service for monitoring and
            analytics of the service characteristics and SLA fulfillment.</t>
          </li>
        </ul>
        <t indent="0" pn="section-9.2-4">How the telemetry mechanisms could be used or extended for enhanced
        VPN services is out of the scope of this document.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
      <t indent="0" pn="section-10-1">It is expected that NRP-based enhanced VPN services will be
      introduced in networks that already have conventional VPN services
      deployed. Depending on service requirements, the tenants or the operator
      may choose to use a VPN or an enhanced VPN to fulfill a service
      requirement. The information and parameters to assist such a decision
      needs to be supplied on the management interface between the tenant and
      the operator. The management interface and data models (as described in
      <xref target="sdm-app" format="default" sectionFormat="of" derivedContent="Section 5.6"/>) can be used for the life-cycle management of
      enhanced VPN services, such as service creation, modification,
      performance monitoring, and decommissioning.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-11-1">All types of virtual networks require special consideration to be
      given to the isolation of traffic belonging to different tenants. That
      is, traffic belonging to one VPN must not be delivered to endpoints
      outside that VPN. In this regard, the enhanced VPN neither introduces
      nor experiences greater security risks than other VPNs.</t>
      <t indent="0" pn="section-11-2">However, in an enhanced VPN service, the additional service
      requirements need to be considered. For example, if a service requires a
      specific upper bound to latency, then it can be damaged by simply
      delaying the packets through the activities of another tenant, i.e., by
      introducing bursts of traffic for other services. In some respects, this
      makes the enhanced VPN more susceptible to attacks since the SLA may be
      broken. Another view is that the operator must, in any case, preform
      monitoring of the enhanced VPN to ensure that the SLA is met; thus, the operator may be more likely to spot the early onset of a
      security attack and be able to take preemptive protective action.</t>
      <t indent="0" pn="section-11-3">The measures to address these dynamic security risks must be
      specified as part of the specific solution to the isolation requirements
      of an enhanced VPN service.</t>
      <t indent="0" pn="section-11-4">While an enhanced VPN service may be sold as offering encryption and
      other security features as part of the service, customers would be well
      advised to take responsibility for their security requirements
      themselves, possibly by encrypting traffic before handing it off to the
      service provider.</t>
      <t indent="0" pn="section-11-5">The privacy of enhanced VPN service customers must be preserved. It
      should not be possible for one customer to discover the existence of
      another customer nor should the sites that are members of an enhanced
      VPN be externally visible.</t>
      <t indent="0" pn="section-11-6">An enhanced VPN service (even one with traffic isolation requirements
      or with limited interaction with other enhanced VPNs) does not provide
      any additional guarantees of privacy for customer traffic compared to
      regular VPNs: the traffic within the network may be intercepted and
      errors may lead to mis-delivery. Users who wish to ensure the privacy of
      their traffic must take their own precautions including end-to-end
      encryption.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-12-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-teas-ietf-network-slice-nbi-yang" to="NETWORK-SLICE-YANG"/>
    <displayreference target="I-D.ietf-teas-nrp-scalability" to="NRP-SCALABILITY"/>
    <displayreference target="I-D.ietf-spring-resource-aware-segments" to="RESOURCE-AWARE-SEGMENTS"/>
    <displayreference target="I-D.ietf-spring-sr-for-enhanced-vpn" to="SR-ENHANCED-VPN"/>
    <displayreference target="I-D.ietf-6man-enhanced-vpn-vtn-id" to="IPv6-NRP-OPTION"/>
    <displayreference target="I-D.ietf-teas-nrp-yang" to="NRP-YANG"/>
    <displayreference target="I-D.ietf-spring-srv6-srh-compression" to="SRv6-SRH-COMPRESSION"/>
    <references pn="section-13">
      <name slugifiedName="name-references">References</name>
      <references pn="section-13.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC9543" target="https://www.rfc-editor.org/info/rfc9543" quoteTitle="true" derivedAnchor="RFC9543">
          <front>
            <title>A Framework for Network Slices in Networks Built from IETF Technologies</title>
            <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
            <author fullname="J. Drake" initials="J." role="editor" surname="Drake"/>
            <author fullname="R. Rokui" initials="R." surname="Rokui"/>
            <author fullname="S. Homma" initials="S." surname="Homma"/>
            <author fullname="K. Makhijani" initials="K." surname="Makhijani"/>
            <author fullname="L. Contreras" initials="L." surname="Contreras"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <date month="March" year="2024"/>
            <abstract>
              <t indent="0">This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context.</t>
              <t indent="0">The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security.</t>
              <t indent="0">This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9543"/>
          <seriesInfo name="DOI" value="10.17487/RFC9543"/>
        </reference>
      </references>
      <references pn="section-13.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="FLEXE" target="https://www.oiforum.com/wp-content/uploads/2019/01/OIF-FLEXE-01.0.pdf" quoteTitle="true" derivedAnchor="FLEXE">
          <front>
            <title>Flex Ethernet Implementation Agreement</title>
            <author>
              <organization showOnFrontPage="true">Optical Internetworking Forum</organization>
            </author>
            <date month="March" year="2016"/>
          </front>
          <refcontent>IA # OIF-FLEXE-01.0</refcontent>
        </reference>
        <reference anchor="I-D.ietf-6man-enhanced-vpn-vtn-id" target="https://datatracker.ietf.org/doc/html/draft-ietf-6man-enhanced-vpn-vtn-id-10" quoteTitle="true" derivedAnchor="IPv6-NRP-OPTION">
          <front>
            <title>Carrying Network Resource (NR) related Information in IPv6 Extension Header</title>
            <author initials="J." surname="Dong" fullname="Jie Dong">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="Z." surname="Li" fullname="Zhenbin Li">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="C." surname="Xie" fullname="Chongfeng Xie">
              <organization showOnFrontPage="true">China Telecom</organization>
            </author>
            <author initials="C." surname="Ma" fullname="Chenhao Ma">
              <organization showOnFrontPage="true">China Telecom</organization>
            </author>
            <author initials="G. S." surname="Mishra" fullname="Gyan Mishra">
              <organization showOnFrontPage="true">Verizon Inc.</organization>
            </author>
            <date month="March" day="2" year="2025"/>
            <abstract>
              <t indent="0">   Virtual Private Networks (VPNs) provide different customers with
   logically separated connectivity over a common network
   infrastructure.  With the introduction of 5G and also in some
   existing network scenarios, some customers may require network
   connectivity services with advanced features comparing to
   conventional VPN services.  Such kind of network service is called
   enhanced VPNs.  Enhanced VPNs can be used, for example, to deliver
   network slice services.

   A Network Resource Partition (NRP) is a subset of the network
   resources and associated policies on each of a connected set of links
   in the underlay network.  An NRP may be used as the underlay to
   support one or a group of enhanced VPN services.  For packet
   forwarding within a specific NRP, some fields in the data packet are
   used to identify the NRP to which the packet belongs.  In doing so,
   NRP-specific processing can be performed on each node along a path in
   the NRP.

   This document specifies a new IPv6 Hop-by-Hop option to carry network
   resource related information (e.g., identifier) in data packets.  The
   NR Option can also be generalized for other network resource
   semantics and functions.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-enhanced-vpn-vtn-id-10"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-teas-ietf-network-slice-nbi-yang" target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-22" quoteTitle="true" derivedAnchor="NETWORK-SLICE-YANG">
          <front>
            <title>A YANG Data Model for the RFC 9543 Network Slice Service</title>
            <author initials="B." surname="Wu" fullname="Bo Wu">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="R." surname="Rokui" fullname="Reza Rokui">
              <organization showOnFrontPage="true">Ciena</organization>
            </author>
            <author initials="T." surname="Saad" fullname="Tarek Saad">
              <organization showOnFrontPage="true">Cisco Systems, Inc</organization>
            </author>
            <author initials="J." surname="Mullooly" fullname="John Mullooly">
              <organization showOnFrontPage="true">Cisco Systems, Inc</organization>
            </author>
            <date month="February" day="8" year="2025"/>
            <abstract>
              <t indent="0">   This document defines a YANG data model for RFC 9543 Network Slice
   Service.  The model can be used in the Network Slice Service
   interface between a customer and a provider that offers RFC 9543
   Network Slice Services.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network-slice-nbi-yang-22"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="NGMN-NS-Concept" target="https://www.ngmn.org/wp-content/uploads/Publications/2016/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf" quoteTitle="true" derivedAnchor="NGMN-NS-Concept">
          <front>
            <title>NGMN 5G P1 Requirements and Architecture Work Stream End-to-End Architecture: Description of Network Slicing Concept</title>
            <author>
              <organization showOnFrontPage="true">NGMN Alliance</organization>
            </author>
            <date day="14" month="September" year="2016"/>
          </front>
          <refcontent>Version 1.0.8 (draft)</refcontent>
        </reference>
        <reference anchor="I-D.ietf-teas-nrp-scalability" target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-nrp-scalability-07" quoteTitle="true" derivedAnchor="NRP-SCALABILITY">
          <front>
            <title>Scalability Considerations for Network Resource Partition</title>
            <author initials="J." surname="Dong" fullname="Jie Dong">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="Z." surname="Li" fullname="Zhenbin Li">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="L." surname="Gong" fullname="Liyan Gong">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <author initials="G." surname="Yang" fullname="Guangming Yang">
              <organization showOnFrontPage="true">China Telecom</organization>
            </author>
            <author initials="G. S." surname="Mishra" fullname="Gyan Mishra">
              <organization showOnFrontPage="true">Verizon Inc.</organization>
            </author>
            <date month="March" day="2" year="2025"/>
            <abstract>
              <t indent="0">   A network slice offers connectivity services to a network slice
   customer with specific Service Level Objectives (SLOs) and Service
   Level Expectations (SLEs) over a common underlay network.

   RFC 9543 describes a framework for network slices built using
   networks that use IETF technologies.  As part of that framework, the
   Network Resource Partition (NRP) is introduced as a set of network
   resources that are allocated from the underlay network to carry a
   specific set of network slice service traffic and meet specific SLOs
   and SLEs.

   As the demand for network slices increases, scalability becomes an
   important factor.  Although the scalability of network slices can be
   improved by mapping a group of network slices to a single NRP, that
   design may not be suitable or possible for all deployments, thus
   there are concerns about the scalability of NRPs themselves.

   This document discusses some considerations for NRP scalability in
   the control and data planes.  It also investigates a set of
   optimization mechanisms.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-teas-nrp-scalability-07"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-teas-nrp-yang" target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-nrp-yang-03" quoteTitle="true" derivedAnchor="NRP-YANG">
          <front>
            <title>YANG Data Models for Network Resource Partitions (NRPs)</title>
            <author initials="B." surname="Wu" fullname="Bo Wu">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="V. P." surname="Beeram" fullname="Vishnu Pavan Beeram">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <author initials="T." surname="Saad" fullname="Tarek Saad">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="S." surname="Peng" fullname="Shaofu Peng">
              <organization showOnFrontPage="true">ZTE Corporation</organization>
            </author>
            <date month="March" day="2" year="2025"/>
            <abstract>
              <t indent="0">   RFC 9543 describes a framework for Network Slices in networks built
   from IETF technologies.  In this framework, the network resource
   partition (NRP) is introduced as a collection of network resources
   allocated from the underlay network to carry a specific set of
   Network Slice Service traffic and meet specific Service Level
   Objective (SLO) and Service Level Expectation (SLE) characteristics.

   This document defines YANG data models for Network Resource
   Partitions (NRPs), applicable to devices and network controllers.
   The models can be used, in particular, for the realization of the
   RFC9543 Network Slice Services in IP/MPLS and Segment Routing (SR)
   networks.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-teas-nrp-yang-03"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-spring-resource-aware-segments" target="https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-11" quoteTitle="true" derivedAnchor="RESOURCE-AWARE-SEGMENTS">
          <front>
            <title>Introducing Resource Awareness to SR Segments</title>
            <author initials="J." surname="Dong" fullname="Jie Dong">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="T." surname="Miyasaka" fullname="Takuya Miyasaka">
              <organization showOnFrontPage="true">KDDI Corporation</organization>
            </author>
            <author initials="Y." surname="Zhu" fullname="Yongqing Zhu">
              <organization showOnFrontPage="true">China Telecom</organization>
            </author>
            <author initials="F." surname="Qin" fullname="Fengwei Qin">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <author initials="Z." surname="Li" fullname="Zhenqiang Li">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <date month="March" day="2" year="2025"/>
            <abstract>
              <t indent="0">   This document describes the mechanism to allocate network resources
   to one or a set of Segment Routing Identifiers (SIDs).  Such SIDs are
   referred to as resource-aware SIDs.  The resource-aware SIDs retain
   their original forwarding semantics, with the additional semantics to
   identify the set of network resources available for the packet
   processing and forwarding action.  A list of resource-aware SIDs can
   be used to allow an SR Policy to use a specific set of network
   resources, and a group of resource-aware SIDs can be used to
   represent a virtual network with a specific set of reserved network
   resources.  The proposed mechanism is applicable to both segment
   routing with MPLS data plane (SR-MPLS) and segment routing with IPv6
   data plane (SRv6).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-spring-resource-aware-segments-11"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC2211" target="https://www.rfc-editor.org/info/rfc2211" quoteTitle="true" derivedAnchor="RFC2211">
          <front>
            <title>Specification of the Controlled-Load Network Element Service</title>
            <author fullname="J. Wroclawski" initials="J." surname="Wroclawski"/>
            <date month="September" year="1997"/>
            <abstract>
              <t indent="0">This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2211"/>
          <seriesInfo name="DOI" value="10.17487/RFC2211"/>
        </reference>
        <reference anchor="RFC2475" target="https://www.rfc-editor.org/info/rfc2475" quoteTitle="true" derivedAnchor="RFC2475">
          <front>
            <title>An Architecture for Differentiated Services</title>
            <author fullname="S. Blake" initials="S." surname="Blake"/>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <author fullname="M. Carlson" initials="M." surname="Carlson"/>
            <author fullname="E. Davies" initials="E." surname="Davies"/>
            <author fullname="Z. Wang" initials="Z." surname="Wang"/>
            <author fullname="W. Weiss" initials="W." surname="Weiss"/>
            <date month="December" year="1998"/>
            <abstract>
              <t indent="0">This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2475"/>
          <seriesInfo name="DOI" value="10.17487/RFC2475"/>
        </reference>
        <reference anchor="RFC2702" target="https://www.rfc-editor.org/info/rfc2702" quoteTitle="true" derivedAnchor="RFC2702">
          <front>
            <title>Requirements for Traffic Engineering Over MPLS</title>
            <author fullname="D. Awduche" initials="D." surname="Awduche"/>
            <author fullname="J. Malcolm" initials="J." surname="Malcolm"/>
            <author fullname="J. Agogbua" initials="J." surname="Agogbua"/>
            <author fullname="M. O'Dell" initials="M." surname="O'Dell"/>
            <author fullname="J. McManus" initials="J." surname="McManus"/>
            <date month="September" year="1999"/>
            <abstract>
              <t indent="0">This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2702"/>
          <seriesInfo name="DOI" value="10.17487/RFC2702"/>
        </reference>
        <reference anchor="RFC2764" target="https://www.rfc-editor.org/info/rfc2764" quoteTitle="true" derivedAnchor="RFC2764">
          <front>
            <title>A Framework for IP Based Virtual Private Networks</title>
            <author fullname="B. Gleeson" initials="B." surname="Gleeson"/>
            <author fullname="A. Lin" initials="A." surname="Lin"/>
            <author fullname="J. Heinanen" initials="J." surname="Heinanen"/>
            <author fullname="G. Armitage" initials="G." surname="Armitage"/>
            <author fullname="A. Malis" initials="A." surname="Malis"/>
            <date month="February" year="2000"/>
            <abstract>
              <t indent="0">This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2764"/>
          <seriesInfo name="DOI" value="10.17487/RFC2764"/>
        </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="RFC3931" target="https://www.rfc-editor.org/info/rfc3931" quoteTitle="true" derivedAnchor="RFC3931">
          <front>
            <title>Layer Two Tunneling Protocol - Version 3 (L2TPv3)</title>
            <author fullname="J. Lau" initials="J." role="editor" surname="Lau"/>
            <author fullname="M. Townsley" initials="M." role="editor" surname="Townsley"/>
            <author fullname="I. Goyret" initials="I." role="editor" surname="Goyret"/>
            <date month="March" year="2005"/>
            <abstract>
              <t indent="0">This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3931"/>
          <seriesInfo name="DOI" value="10.17487/RFC3931"/>
        </reference>
        <reference anchor="RFC3985" target="https://www.rfc-editor.org/info/rfc3985" quoteTitle="true" derivedAnchor="RFC3985">
          <front>
            <title>Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture</title>
            <author fullname="S. Bryant" initials="S." role="editor" surname="Bryant"/>
            <author fullname="P. Pate" initials="P." role="editor" surname="Pate"/>
            <date month="March" year="2005"/>
            <abstract>
              <t indent="0">This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3985"/>
          <seriesInfo name="DOI" value="10.17487/RFC3985"/>
        </reference>
        <reference anchor="RFC4026" target="https://www.rfc-editor.org/info/rfc4026" quoteTitle="true" derivedAnchor="RFC4026">
          <front>
            <title>Provider Provisioned Virtual Private Network (VPN) Terminology</title>
            <author fullname="L. Andersson" initials="L." surname="Andersson"/>
            <author fullname="T. Madsen" initials="T." surname="Madsen"/>
            <date month="March" year="2005"/>
            <abstract>
              <t indent="0">The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services.</t>
              <t indent="0">To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4026"/>
          <seriesInfo name="DOI" value="10.17487/RFC4026"/>
        </reference>
        <reference anchor="RFC4176" target="https://www.rfc-editor.org/info/rfc4176" quoteTitle="true" derivedAnchor="RFC4176">
          <front>
            <title>Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management</title>
            <author fullname="Y. El Mghazli" initials="Y." role="editor" surname="El Mghazli"/>
            <author fullname="T. Nadeau" initials="T." surname="Nadeau"/>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <author fullname="K. Chan" initials="K." surname="Chan"/>
            <author fullname="A. Gonguet" initials="A." surname="Gonguet"/>
            <date month="October" year="2005"/>
            <abstract>
              <t indent="0">This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4176"/>
          <seriesInfo name="DOI" value="10.17487/RFC4176"/>
        </reference>
        <reference anchor="RFC4364" target="https://www.rfc-editor.org/info/rfc4364" quoteTitle="true" derivedAnchor="RFC4364">
          <front>
            <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="February" year="2006"/>
            <abstract>
              <t indent="0">This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4364"/>
          <seriesInfo name="DOI" value="10.17487/RFC4364"/>
        </reference>
        <reference anchor="RFC4448" target="https://www.rfc-editor.org/info/rfc4448" quoteTitle="true" derivedAnchor="RFC4448">
          <front>
            <title>Encapsulation Methods for Transport of Ethernet over MPLS Networks</title>
            <author fullname="L. Martini" initials="L." role="editor" surname="Martini"/>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="N. El-Aawar" initials="N." surname="El-Aawar"/>
            <author fullname="G. Heron" initials="G." surname="Heron"/>
            <date month="April" year="2006"/>
            <abstract>
              <t indent="0">An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4448"/>
          <seriesInfo name="DOI" value="10.17487/RFC4448"/>
        </reference>
        <reference anchor="RFC4594" target="https://www.rfc-editor.org/info/rfc4594" quoteTitle="true" derivedAnchor="RFC4594">
          <front>
            <title>Configuration Guidelines for DiffServ Service Classes</title>
            <author fullname="J. Babiarz" initials="J." surname="Babiarz"/>
            <author fullname="K. Chan" initials="K." surname="Chan"/>
            <author fullname="F. Baker" initials="F." surname="Baker"/>
            <date month="August" year="2006"/>
            <abstract>
              <t indent="0">This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4594"/>
          <seriesInfo name="DOI" value="10.17487/RFC4594"/>
        </reference>
        <reference anchor="RFC4655" target="https://www.rfc-editor.org/info/rfc4655" quoteTitle="true" derivedAnchor="RFC4655">
          <front>
            <title>A Path Computation Element (PCE)-Based Architecture</title>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="J.-P. Vasseur" initials="J.-P." surname="Vasseur"/>
            <author fullname="J. Ash" initials="J." surname="Ash"/>
            <date month="August" year="2006"/>
            <abstract>
              <t indent="0">Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.</t>
              <t indent="0">This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4655"/>
          <seriesInfo name="DOI" value="10.17487/RFC4655"/>
        </reference>
        <reference anchor="RFC4664" target="https://www.rfc-editor.org/info/rfc4664" quoteTitle="true" derivedAnchor="RFC4664">
          <front>
            <title>Framework for Layer 2 Virtual Private Networks (L2VPNs)</title>
            <author fullname="L. Andersson" initials="L." role="editor" surname="Andersson"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <date month="September" year="2006"/>
            <abstract>
              <t indent="0">This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4664"/>
          <seriesInfo name="DOI" value="10.17487/RFC4664"/>
        </reference>
        <reference anchor="RFC4719" target="https://www.rfc-editor.org/info/rfc4719" quoteTitle="true" derivedAnchor="RFC4719">
          <front>
            <title>Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)</title>
            <author fullname="R. Aggarwal" initials="R." role="editor" surname="Aggarwal"/>
            <author fullname="M. Townsley" initials="M." role="editor" surname="Townsley"/>
            <author fullname="M. Dos Santos" initials="M." role="editor" surname="Dos Santos"/>
            <date month="November" year="2006"/>
            <abstract>
              <t indent="0">This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4719"/>
          <seriesInfo name="DOI" value="10.17487/RFC4719"/>
        </reference>
        <reference anchor="RFC5557" target="https://www.rfc-editor.org/info/rfc5557" quoteTitle="true" derivedAnchor="RFC5557">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization</title>
            <author fullname="Y. Lee" initials="Y." surname="Lee"/>
            <author fullname="JL. Le Roux" initials="JL." surname="Le Roux"/>
            <author fullname="D. King" initials="D." surname="King"/>
            <author fullname="E. Oki" initials="E." surname="Oki"/>
            <date month="July" year="2009"/>
            <abstract>
              <t indent="0">The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.</t>
              <t indent="0">This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5557"/>
          <seriesInfo name="DOI" value="10.17487/RFC5557"/>
        </reference>
        <reference anchor="RFC5654" target="https://www.rfc-editor.org/info/rfc5654" quoteTitle="true" derivedAnchor="RFC5654">
          <front>
            <title>Requirements of an MPLS Transport Profile</title>
            <author fullname="B. Niven-Jenkins" initials="B." role="editor" surname="Niven-Jenkins"/>
            <author fullname="D. Brungard" initials="D." role="editor" surname="Brungard"/>
            <author fullname="M. Betts" initials="M." role="editor" surname="Betts"/>
            <author fullname="N. Sprecher" initials="N." surname="Sprecher"/>
            <author fullname="S. Ueno" initials="S." surname="Ueno"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).</t>
              <t indent="0">This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.</t>
              <t indent="0">The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5654"/>
          <seriesInfo name="DOI" value="10.17487/RFC5654"/>
        </reference>
        <reference anchor="RFC7209" target="https://www.rfc-editor.org/info/rfc7209" quoteTitle="true" derivedAnchor="RFC7209">
          <front>
            <title>Requirements for Ethernet VPN (EVPN)</title>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="A. Isaac" initials="A." surname="Isaac"/>
            <date month="May" year="2014"/>
            <abstract>
              <t indent="0">The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7209"/>
          <seriesInfo name="DOI" value="10.17487/RFC7209"/>
        </reference>
        <reference anchor="RFC7297" target="https://www.rfc-editor.org/info/rfc7297" quoteTitle="true" derivedAnchor="RFC7297">
          <front>
            <title>IP Connectivity Provisioning Profile (CPP)</title>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <author fullname="C. Jacquenet" initials="C." surname="Jacquenet"/>
            <author fullname="N. Wang" initials="N." surname="Wang"/>
            <date month="July" year="2014"/>
            <abstract>
              <t indent="0">This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP.</t>
              <t indent="0">Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7297"/>
          <seriesInfo name="DOI" value="10.17487/RFC7297"/>
        </reference>
        <reference anchor="RFC7399" target="https://www.rfc-editor.org/info/rfc7399" quoteTitle="true" derivedAnchor="RFC7399">
          <front>
            <title>Unanswered Questions in the Path Computation Element Architecture</title>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="D. King" initials="D." surname="King"/>
            <date month="October" year="2014"/>
            <abstract>
              <t indent="0">The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.</t>
              <t indent="0">These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.</t>
              <t indent="0">This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7399"/>
          <seriesInfo name="DOI" value="10.17487/RFC7399"/>
        </reference>
        <reference anchor="RFC7432" target="https://www.rfc-editor.org/info/rfc7432" quoteTitle="true" derivedAnchor="RFC7432">
          <front>
            <title>BGP MPLS-Based Ethernet VPN</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="A. Isaac" initials="A." surname="Isaac"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="February" year="2015"/>
            <abstract>
              <t indent="0">This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7432"/>
          <seriesInfo name="DOI" value="10.17487/RFC7432"/>
        </reference>
        <reference anchor="RFC7665" target="https://www.rfc-editor.org/info/rfc7665" quoteTitle="true" derivedAnchor="RFC7665">
          <front>
            <title>Service Function Chaining (SFC) Architecture</title>
            <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern"/>
            <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/>
            <date month="October" year="2015"/>
            <abstract>
              <t indent="0">This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7665"/>
          <seriesInfo name="DOI" value="10.17487/RFC7665"/>
        </reference>
        <reference anchor="RFC7926" target="https://www.rfc-editor.org/info/rfc7926" quoteTitle="true" derivedAnchor="RFC7926">
          <front>
            <title>Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks</title>
            <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <author fullname="D. Ceccarelli" initials="D." surname="Ceccarelli"/>
            <author fullname="X. Zhang" initials="X." surname="Zhang"/>
            <date month="July" year="2016"/>
            <abstract>
              <t indent="0">In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.</t>
              <t indent="0">In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information.</t>
              <t indent="0">This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="206"/>
          <seriesInfo name="RFC" value="7926"/>
          <seriesInfo name="DOI" value="10.17487/RFC7926"/>
        </reference>
        <reference anchor="RFC8299" target="https://www.rfc-editor.org/info/rfc8299" quoteTitle="true" derivedAnchor="RFC8299">
          <front>
            <title>YANG Data Model for L3VPN Service Delivery</title>
            <author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="L. Tomotaki" initials="L." surname="Tomotaki"/>
            <author fullname="K. Ogaki" initials="K." surname="Ogaki"/>
            <date month="January" year="2018"/>
            <abstract>
              <t indent="0">This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.</t>
              <t indent="0">This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8299"/>
          <seriesInfo name="DOI" value="10.17487/RFC8299"/>
        </reference>
        <reference anchor="RFC8309" target="https://www.rfc-editor.org/info/rfc8309" quoteTitle="true" derivedAnchor="RFC8309">
          <front>
            <title>Service Models Explained</title>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="W. Liu" initials="W." surname="Liu"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="January" year="2018"/>
            <abstract>
              <t indent="0">The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions.</t>
              <t indent="0">A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049).</t>
              <t indent="0">This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8309"/>
          <seriesInfo name="DOI" value="10.17487/RFC8309"/>
        </reference>
        <reference anchor="RFC8370" target="https://www.rfc-editor.org/info/rfc8370" quoteTitle="true" derivedAnchor="RFC8370">
          <front>
            <title>Techniques to Improve the Scalability of RSVP-TE Deployments</title>
            <author fullname="V. Beeram" initials="V." role="editor" surname="Beeram"/>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <author fullname="D. Pacella" initials="D." surname="Pacella"/>
            <author fullname="T. Saad" initials="T." surname="Saad"/>
            <date month="May" year="2018"/>
            <abstract>
              <t indent="0">Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.</t>
              <t indent="0">This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8370"/>
          <seriesInfo name="DOI" value="10.17487/RFC8370"/>
        </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="RFC8403" target="https://www.rfc-editor.org/info/rfc8403" quoteTitle="true" derivedAnchor="RFC8403">
          <front>
            <title>A Scalable and Topology-Aware MPLS Data-Plane Monitoring System</title>
            <author fullname="R. Geib" initials="R." role="editor" surname="Geib"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/>
            <author fullname="N. Kumar" initials="N." surname="Kumar"/>
            <date month="July" year="2018"/>
            <abstract>
              <t indent="0">This document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations, Administration, and Maintenance (OAM) measurements while enabling new OAM features.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8403"/>
          <seriesInfo name="DOI" value="10.17487/RFC8403"/>
        </reference>
        <reference anchor="RFC8453" target="https://www.rfc-editor.org/info/rfc8453" quoteTitle="true" derivedAnchor="RFC8453">
          <front>
            <title>Framework for Abstraction and Control of TE Networks (ACTN)</title>
            <author fullname="D. Ceccarelli" initials="D." role="editor" surname="Ceccarelli"/>
            <author fullname="Y. Lee" initials="Y." role="editor" surname="Lee"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.</t>
              <t indent="0">Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.</t>
              <t indent="0">This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8453"/>
          <seriesInfo name="DOI" value="10.17487/RFC8453"/>
        </reference>
        <reference anchor="RFC8466" target="https://www.rfc-editor.org/info/rfc8466" quoteTitle="true" derivedAnchor="RFC8466">
          <front>
            <title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery</title>
            <author fullname="B. Wen" initials="B." surname="Wen"/>
            <author fullname="G. Fioccola" initials="G." role="editor" surname="Fioccola"/>
            <author fullname="C. Xie" initials="C." surname="Xie"/>
            <author fullname="L. Jalil" initials="L." surname="Jalil"/>
            <date month="October" year="2018"/>
            <abstract>
              <t indent="0">This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.</t>
              <t indent="0">The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.</t>
              <t indent="0">The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8466"/>
          <seriesInfo name="DOI" value="10.17487/RFC8466"/>
        </reference>
        <reference anchor="RFC8491" target="https://www.rfc-editor.org/info/rfc8491" quoteTitle="true" derivedAnchor="RFC8491">
          <front>
            <title>Signaling Maximum SID Depth (MSD) Using IS-IS</title>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="U. Chunduri" initials="U." surname="Chunduri"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <date month="November" year="2018"/>
            <abstract>
              <t indent="0">This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8491"/>
          <seriesInfo name="DOI" value="10.17487/RFC8491"/>
        </reference>
        <reference anchor="RFC8577" target="https://www.rfc-editor.org/info/rfc8577" quoteTitle="true" derivedAnchor="RFC8577">
          <front>
            <title>Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane</title>
            <author fullname="H. Sitaraman" initials="H." surname="Sitaraman"/>
            <author fullname="V. Beeram" initials="V." surname="Beeram"/>
            <author fullname="T. Parikh" initials="T." surname="Parikh"/>
            <author fullname="T. Saad" initials="T." surname="Saad"/>
            <date month="April" year="2019"/>
            <abstract>
              <t indent="0">As the scale of MPLS RSVP-TE networks has grown, the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.</t>
              <t indent="0">However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane.</t>
              <t indent="0">This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled 'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8577"/>
          <seriesInfo name="DOI" value="10.17487/RFC8577"/>
        </reference>
        <reference anchor="RFC8578" target="https://www.rfc-editor.org/info/rfc8578" quoteTitle="true" derivedAnchor="RFC8578">
          <front>
            <title>Deterministic Networking Use Cases</title>
            <author fullname="E. Grossman" initials="E." role="editor" surname="Grossman"/>
            <date month="May" year="2019"/>
            <abstract>
              <t indent="0">This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8578"/>
          <seriesInfo name="DOI" value="10.17487/RFC8578"/>
        </reference>
        <reference anchor="RFC8655" target="https://www.rfc-editor.org/info/rfc8655" quoteTitle="true" derivedAnchor="RFC8655">
          <front>
            <title>Deterministic Networking Architecture</title>
            <author fullname="N. Finn" initials="N." surname="Finn"/>
            <author fullname="P. Thubert" initials="P." surname="Thubert"/>
            <author fullname="B. Varga" initials="B." surname="Varga"/>
            <author fullname="J. Farkas" initials="J." surname="Farkas"/>
            <date month="October" year="2019"/>
            <abstract>
              <t indent="0">This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8655"/>
          <seriesInfo name="DOI" value="10.17487/RFC8655"/>
        </reference>
        <reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660" quoteTitle="true" derivedAnchor="RFC8660">
          <front>
            <title>Segment Routing with the MPLS Data Plane</title>
            <author fullname="A. Bashandy" initials="A." role="editor" surname="Bashandy"/>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <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="December" year="2019"/>
            <abstract>
              <t indent="0">Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8660"/>
          <seriesInfo name="DOI" value="10.17487/RFC8660"/>
        </reference>
        <reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8665" quoteTitle="true" derivedAnchor="RFC8665">
          <front>
            <title>OSPF Extensions for Segment Routing</title>
            <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="H. Gredler" initials="H." surname="Gredler"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <date month="December" year="2019"/>
            <abstract>
              <t indent="0">Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</t>
              <t indent="0">This document describes the OSPFv2 extensions required for Segment Routing.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8665"/>
          <seriesInfo name="DOI" value="10.17487/RFC8665"/>
        </reference>
        <reference anchor="RFC8667" target="https://www.rfc-editor.org/info/rfc8667" quoteTitle="true" derivedAnchor="RFC8667">
          <front>
            <title>IS-IS Extensions for Segment Routing</title>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="A. Bashandy" initials="A." surname="Bashandy"/>
            <author fullname="H. Gredler" initials="H." surname="Gredler"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <date month="December" year="2019"/>
            <abstract>
              <t indent="0">Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</t>
              <t indent="0">This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8667"/>
          <seriesInfo name="DOI" value="10.17487/RFC8667"/>
        </reference>
        <reference anchor="RFC8939" target="https://www.rfc-editor.org/info/rfc8939" quoteTitle="true" derivedAnchor="RFC8939">
          <front>
            <title>Deterministic Networking (DetNet) Data Plane: IP</title>
            <author fullname="B. Varga" initials="B." role="editor" surname="Varga"/>
            <author fullname="J. Farkas" initials="J." surname="Farkas"/>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <author fullname="D. Fedyk" initials="D." surname="Fedyk"/>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <date month="November" year="2020"/>
            <abstract>
              <t indent="0">This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8939"/>
          <seriesInfo name="DOI" value="10.17487/RFC8939"/>
        </reference>
        <reference anchor="RFC8964" target="https://www.rfc-editor.org/info/rfc8964" quoteTitle="true" derivedAnchor="RFC8964">
          <front>
            <title>Deterministic Networking (DetNet) Data Plane: MPLS</title>
            <author fullname="B. Varga" initials="B." role="editor" surname="Varga"/>
            <author fullname="J. Farkas" initials="J." surname="Farkas"/>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <author fullname="A. Malis" initials="A." surname="Malis"/>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <author fullname="J. Korhonen" initials="J." surname="Korhonen"/>
            <date month="January" year="2021"/>
            <abstract>
              <t indent="0">This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8964"/>
          <seriesInfo name="DOI" value="10.17487/RFC8964"/>
        </reference>
        <reference anchor="RFC8986" target="https://www.rfc-editor.org/info/rfc8986" quoteTitle="true" derivedAnchor="RFC8986">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <date month="February" year="2021"/>
            <abstract>
              <t indent="0">The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t indent="0">Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t indent="0">This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
        <reference anchor="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="RFC9182" target="https://www.rfc-editor.org/info/rfc9182" quoteTitle="true" derivedAnchor="RFC9182">
          <front>
            <title>A YANG Network Data Model for Layer 3 VPNs</title>
            <author fullname="S. Barguil" initials="S." surname="Barguil"/>
            <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="L. Munoz" initials="L." surname="Munoz"/>
            <author fullname="A. Aguado" initials="A." surname="Aguado"/>
            <date month="February" year="2022"/>
            <abstract>
              <t indent="0">As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.</t>
              <t indent="0">The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9182"/>
          <seriesInfo name="DOI" value="10.17487/RFC9182"/>
        </reference>
        <reference anchor="RFC9232" target="https://www.rfc-editor.org/info/rfc9232" quoteTitle="true" derivedAnchor="RFC9232">
          <front>
            <title>Network Telemetry Framework</title>
            <author fullname="H. Song" initials="H." surname="Song"/>
            <author fullname="F. Qin" initials="F." surname="Qin"/>
            <author fullname="P. Martinez-Julia" initials="P." surname="Martinez-Julia"/>
            <author fullname="L. Ciavaglia" initials="L." surname="Ciavaglia"/>
            <author fullname="A. Wang" initials="A." surname="Wang"/>
            <date month="May" year="2022"/>
            <abstract>
              <t indent="0">Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9232"/>
          <seriesInfo name="DOI" value="10.17487/RFC9232"/>
        </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="RFC9291" target="https://www.rfc-editor.org/info/rfc9291" quoteTitle="true" derivedAnchor="RFC9291">
          <front>
            <title>A YANG Network Data Model for Layer 2 VPNs</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/>
            <author fullname="S. Barguil" initials="S." surname="Barguil"/>
            <author fullname="L. Munoz" initials="L." surname="Munoz"/>
            <date month="September" year="2022"/>
            <abstract>
              <t indent="0">This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.</t>
              <t indent="0">Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9291"/>
          <seriesInfo name="DOI" value="10.17487/RFC9291"/>
        </reference>
        <reference anchor="RFC9375" target="https://www.rfc-editor.org/info/rfc9375" quoteTitle="true" derivedAnchor="RFC9375">
          <front>
            <title>A YANG Data Model for Network and VPN Service Performance Monitoring</title>
            <author fullname="B. Wu" initials="B." role="editor" surname="Wu"/>
            <author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <author fullname="B. Wen" initials="B." surname="Wen"/>
            <date month="April" year="2023"/>
            <abstract>
              <t indent="0">The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9375"/>
          <seriesInfo name="DOI" value="10.17487/RFC9375"/>
        </reference>
        <reference anchor="RFC9408" target="https://www.rfc-editor.org/info/rfc9408" quoteTitle="true" derivedAnchor="RFC9408">
          <front>
            <title>A YANG Network Data Model for Service Attachment Points (SAPs)</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <author fullname="S. Barguil" initials="S." surname="Barguil"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="V. Lopez" initials="V." surname="Lopez"/>
            <date month="June" year="2023"/>
            <abstract>
              <t indent="0">This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks).</t>
              <t indent="0">This document augments the 'ietf-network' data model defined in RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9408"/>
          <seriesInfo name="DOI" value="10.17487/RFC9408"/>
        </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="RFC9731" target="https://www.rfc-editor.org/info/rfc9731" quoteTitle="true" derivedAnchor="RFC9731">
          <front>
            <title>A YANG Data Model for Virtual Network (VN) Operations</title>
            <author initials="Y." surname="Lee" fullname="Young Lee" role="editor">
              <organization showOnFrontPage="true">Samsung Electronics</organization>
            </author>
            <author initials="D." surname="Dhody" fullname="Dhruv Dhody" role="editor">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author initials="D." surname="Ceccarelli" fullname="Daniele Ceccarelli">
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <author initials="I." surname="Bryskin" fullname="Igor Bryskin">
              <organization showOnFrontPage="true">Individual</organization>
            </author>
            <author initials="B." surname="Yoon" fullname="Bin Yeong Yoon">
              <organization showOnFrontPage="true">ETRI</organization>
            </author>
            <date month="March" year="2025"/>
          </front>
          <seriesInfo name="RFC" value="9731"/>
          <seriesInfo name="DOI" value="10.17487/RFC9731"/>
        </reference>
        <reference anchor="I-D.ietf-spring-sr-for-enhanced-vpn" target="https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-for-enhanced-vpn-08" quoteTitle="true" derivedAnchor="SR-ENHANCED-VPN">
          <front>
            <title>Segment Routing based Network Resource Partition (NRP) for Enhanced VPN</title>
            <author initials="J." surname="Dong" fullname="Jie Dong">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="T." surname="Miyasaka" fullname="Takuya Miyasaka">
              <organization showOnFrontPage="true">KDDI Corporation</organization>
            </author>
            <author initials="Y." surname="Zhu" fullname="Yongqing Zhu">
              <organization showOnFrontPage="true">China Telecom</organization>
            </author>
            <author initials="F." surname="Qin" fullname="Fengwei Qin">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <author initials="Z." surname="Li" fullname="Zhenqiang Li">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <date month="October" day="12" year="2024"/>
            <abstract>
              <t indent="0">   Enhanced VPNs aim to deliver VPN services with enhanced
   characteristics, such as guaranteed resources, latency, jitter, etc.,
   so as to support customers requirements on connectivity services with
   these enhanced characteristics.  Enhanced VPN requires integration
   between the overlay VPN connectivity and the characteristics provided
   by the underlay network.  A Network Resource Partition (NRP) is a
   subset of the network resources and associated policies on each of a
   connected set of links in the underlay network.  An NRP could be used
   as the underlay to support one or a group of enhanced VPN services.

   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 topological or service based
   instructions.  A segment can further be associated with a set of
   network resources used for executing the instruction.  Such a segment
   is called resource-aware segment.

   Resource-aware Segment Identifiers (SIDs) may be used to build SR
   paths with a set of reserved network resources.  In addition, a group
   of resource-aware SIDs may be used to build SR based NRPs, which
   provide customized network topology and resource attributes required
   by one or a group of enhanced VPN services.

   This document describes an approach to build SR based NRPs using
   resource-aware SIDs.  The SR based NRP can be used to deliver
   enhanced VPN services in SR networks.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-for-enhanced-vpn-08"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-spring-srv6-srh-compression" target="https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-18" quoteTitle="true" derivedAnchor="SRv6-SRH-COMPRESSION">
          <front>
            <title>Compressed SRv6 Segment List Encoding (CSID)</title>
            <author initials="W." surname="Cheng" fullname="Weiqiang Cheng" role="editor">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author initials="Z." surname="Li" fullname="Zhenbin Li">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="B." surname="Decraene" fullname="Bruno Decraene">
              <organization showOnFrontPage="true">Orange</organization>
            </author>
            <author initials="F." surname="Clad" fullname="Francois Clad" role="editor">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <date month="February" day="6" year="2025"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-srh-compression-23"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="TS23501" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144" quoteTitle="true" derivedAnchor="TS23501">
          <front>
            <title>System architecture for the 5G system (5GS)</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
            <date year=""/>
          </front>
          <seriesInfo name="3GPP TS" value="23.501"/>
        </reference>
        <reference anchor="TS28530" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3273" quoteTitle="true" derivedAnchor="TS28530">
          <front>
            <title>Management and orchestration; Concepts, use cases and requirements</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
            <date year=""/>
          </front>
          <seriesInfo name="3GPP TS" value="28.530"/>
        </reference>
        <reference anchor="TSN" target="https://1.ieee802.org/tsn/" quoteTitle="true" derivedAnchor="TSN">
          <front>
            <title>Time-Sensitive Networking (TSN) Task Group</title>
            <author>
              <organization showOnFrontPage="true">IEEE 802.1 Working Group</organization>
            </author>
            <date month="" year=""/>
          </front>
        </reference>
      </references>
    </references>
    <section 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="Charlie Perkins"/>, <contact fullname="James N. Guichard"/>,
      <contact fullname="John E. Drake"/>, <contact fullname="Shunsuke Homma"/>, <contact fullname="Luis M. Contreras"/>, and <contact fullname="Joel Halpern"/> for
      their review and valuable comments.</t>
      <t indent="0" pn="section-appendix.a-2">This work was supported in part by the European Commission funded
      H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Daniel King">
        <address>
          <email>daniel@olddog.co.uk</email>
        </address>
      </contact>
      <contact fullname="Adrian Farrel">
        <address>
          <email>adrian@olddog.co.uk</email>
        </address>
      </contact>
      <contact fullname="Jeff Tantsura">
        <address>
          <email>jefftant.ietf@gmail.com</email>
        </address>
      </contact>
      <contact fullname="Zhenbin Li">
        <address>
          <email>lizhenbin@huawei.com</email>
        </address>
      </contact>
      <contact fullname="Qin Wu">
        <address>
          <email>bill.wu@huawei.com</email>
        </address>
      </contact>
      <contact fullname="Bo Wu">
        <address>
          <email>lana.wubo@huawei.com</email>
        </address>
      </contact>
      <contact fullname="Daniele Ceccarelli">
        <address>
          <email>daniele.ietf@gmail.com</email>
        </address>
      </contact>
      <contact fullname="Mohamed Boucadair">
        <address>
          <email>mohamed.boucadair@orange.com</email>
        </address>
      </contact>
      <contact fullname="Sergio Belotti">
        <address>
          <email>sergio.belotti@nokia.com</email>
        </address>
      </contact>
      <contact fullname="Haomian Zheng">
        <address>
          <email>zhenghaomian@huawei.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Jie Dong" initials="J." surname="Dong">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <email>jie.dong@huawei.com</email>
        </address>
      </author>
      <author fullname="Stewart Bryant" initials="S." surname="Bryant">
        <organization showOnFrontPage="true">University of Surrey</organization>
        <address>
          <email>stewart.bryant@gmail.com</email>
        </address>
      </author>
      <author fullname="Zhenqiang Li" initials="Z." surname="Li">
        <organization showOnFrontPage="true">China Mobile</organization>
        <address>
          <email>lizhenqiang@chinamobile.com</email>
        </address>
      </author>
      <author fullname="Takuya Miyasaka" initials="T." surname="Miyasaka">
        <organization showOnFrontPage="true">KDDI Corporation</organization>
        <address>
          <email>ta-miyasaka@kddi.com</email>
        </address>
      </author>
      <author fullname="Young Lee" initials="Y." surname="Lee">
        <organization showOnFrontPage="true">Samsung</organization>
        <address>
          <email>younglee.tx@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
