<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ietf-teas-enhanced-vpn-20"
     ipr="trust200902"> number="9732" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="Enhanced VPN Framework">A Framework for Network Resource
    Partition Based Enhanced Virtual Private Networks</title>

<!-- [rfced] Please note that the title of the document has been
     updated as follows:

a) We have cut the abbreviation NRP from the document title.  Note that
this abbreviation is expanded in the first line of the Abstract.

Original:
A Framework for Network Resource Partition (NRP) based Enhanced
Virtual Private Networks</title> Networks

Current:
A Framework for Network Resource Partition Based Enhanced Virtual
Private Networks

b) To avoid awkward hyphenation with "based" might one of the
following be an acceptable further update to the document title?

Perhaps:
A Framework for Enhanced Virtual Private Networks Based on Network
Resource Partitions

We could also not expand NRP since We see it is expanded in the first
line of the Abstract; however, it too suffers from the same "based"
hyphenation problem. Perhaps if the title suggestion above is not to
your liking, we could try:

Perhaps:
A Framework for NRP-Based Enhanced Virtual Private Networks

[With the first sentence of the Abstract updated to:]

This document describes a framework for Enhanced Virtual Private
Networks (VPNs) based on Network Resource Partitions (NRPs)...
-->

    <seriesInfo name="RFC" value="9732"/>
    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei</organization>
      <address>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <author fullname="Stewart Bryant" initials="S." surname="Bryant">
      <organization>University of Surrey</organization>
      <address>
        <email>stewart.bryant@gmail.com</email>
      </address>
    </author>
    <author fullname="Zhenqiang Li" initials="Z." surname="Li">
      <organization>China Mobile</organization>
      <address>
        <email>lizhenqiang@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Takuya Miyasaka" initials="T." surname="Miyasaka">
      <organization>KDDI Corporation</organization>
      <address>
        <email>ta-miyasaka@kddi.com</email>
      </address>
    </author>
    <author fullname="Young Lee" initials="Y." surname="Lee">
      <organization>Samsung</organization>
      <address>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>
    <date day="14" month="June" year="2024"/>

    <workgroup>TEAS Working Group</workgroup> month="January" year="2025"/>
    <area>RTG</area>
    <workgroup>teas</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
     the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>This document describes the framework for enhanced Virtual Private Networks (VPNs) that are Network Resource Partition
      (NRP) based Enhanced Virtual Private Networks (VPNs) in order to support the
      needs of applications with specific traffic performance requirements
      (e.g., low latency, bounded jitter). An NRP represents a subset of
      network resources and associated policies in the underlay network.
      NRP-based Enhanced 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, layers and identifies some areas for
      potential new work.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>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, "underlay", and the
      VPN is often called an overlay.</t> "overlay".</t>
      <t>Customers of a network operator may request connectivity services
      with advanced characteristics, such as low latency low-latency guarantees, bounded
      jitter, or isolation from other services or customers 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 services, providing the customer with the required
      connectivity, but in addition, they also provide enhanced characteristics.</t>

<!--[rfced] These two sentences from the Introduction seem to have
     similar examples.  To reduce redundancy, might these be compiled
     in one place?  If changes are desired, please let us know how to
     update using old/new.  Note also that similar text exists in the
     Terminology section.

Original:
(paragraph 2)
...such as low latency guarantees, bounded jitter, or isolation from
other services or customers so that changes in other services

and
(paragraph 3)
...such as guaranteed resources, latency, jitter, etc.
-->

      <t>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, time and it is expected 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>The concept of network slicing has gained traction traction, driven largely by
      needs surfacing from 5G (see <xref target="NGMN-NS-Concept"/> target="NGMN-NS-Concept" format="default"/>, <xref
      target="TS23501"/> target="TS23501" format="default"/>, and <xref target="TS28530"/>. target="TS28530" format="default"/>). According to <xref
      target="TS28530"/>, target="TS28530" format="default"/>, a 5G end-to-end network slice consists of three
      major types of network segments: Radio Access Network (RAN), Transport
      Network (TN), and Mobile 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><xref target="RFC9543"/> target="RFC9543" format="default"/> 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 "RFC 9543
      Network Slices, Slices", but in this document (which is solely about IETF
      technologies)
      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 SLOs SLO and SLEs SLE      requirements. A network slice is considered as to be one target use case of
      enhanced VPNs.</t>
      <t><xref target="RFC9543"/> target="RFC9543" format="default"/> also introduces the concept of Network
      Resource Partition (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>The requirements of enhanced VPN services cannot simply be met by
      overlay networks, as networks: enhanced VPN services require tighter coordination
      and integration between the overlay and the underlay networks.</t>
      <t>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"/>. target="RFC4026" format="default"/>. 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>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 "NRP-based enhanced
      VPN.
      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 Section 1.4 of <xref target="RFC7665"/> target="RFC7665" sectionFormat="of" section="1.4"/> 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"/>), target="app-ns-realization" format="default"/>), and they
      can also be of use in general cases to provide enhanced connectivity
      services between customer sites or service endpoints.</t>
      <t>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>

      <t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>The functional requirements and service characteristics of an
          enhanced VPN service.</t>
        </li>
        <li>
          <t>The design of the data plane for NRP-based enhanced VPNs.</t>
        </li>
        <li>
          <t>The necessary control and management protocols in both the
          underlay and the overlay of enhanced VPNs.</t>
        </li>
        <li>
          <t>The mechanisms to achieve integration between the overlay network
          and the underlay network.</t>
        </li>
        <li>
          <t>The necessary Operation, Administration, and Management (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, met and to take any corrective action (such as
          switching traffic to an alternate path) to avoid SLA violation.</t>
        </list></t>
        </li>
      </ul>
      <t>One possible layered network structure to achieve these objectives is
      shown in <xref target="COMLAY"/>.</t> target="COMLAY" format="default"/>.</t>
      <t>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 co-exist coexist with enhanced VPN services.
      Whether enhanced VPN features are added to an active VPN service is
      deployment-specific.</t>
      deployment specific.</t>
    </section>
    <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>In this document, the relationship of the four terms "VPN", "enhanced
      VPN", "NRP", and "Network Slice" are as follows:</t>

      <t><list style="symbols">
      <ul spacing="normal">
        <li>
<!-- [rfced] Please review the use of RFC 4364 as a reference for
     L3VPN in the following text as we don't see L3VPN or layer 3 in
     that document.

Original:
Examples of technologies to provide VPN services are: IPVPN [RFC2764],
L2VPN [RFC4664], L3VPN [RFC4364], and EVPN [RFC7432].

-->
          <t>A Virtual Private Network (VPN) refers to the overlay network
          service that provides connectivity between different customer sites, sites
          and that maintains traffic separation between different customers.
          Examples of technologies to provide VPN services are: are as follows: IPVPN <xref
          target="RFC2764"/>, target="RFC2764" format="default"/>, L2VPN <xref target="RFC4664"/>, target="RFC4664" format="default"/>, L3VPN <xref
          target="RFC4364"/>, target="RFC4364" format="default"/>, and EVPN <xref target="RFC7432"/>.</t> target="RFC7432" format="default"/>.</t>
        </li>
        <li>
          <t>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. (i.e., an NRP).</t>
        </li>
        <li>
          <t>A Network Resource Partition (NRP) (NRP), as defined in <xref
          target="RFC9543"/> target="RFC9543" format="default"/>, 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>
          <t>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>
        </list></t>
        </li>
      </ul>
      <t>The term "tenant" is used in this document to refer to a customer of
      the enhanced VPN services.</t>
      <t>The following terms, defined in other documents, are also used in
      this document. <list style="hanging">
          <t hangText="SLA:">Service </t>
      <dl newline="false" spacing="normal">
        <dt>SLA:</dt>
        <dd>Service Level Agreement. See Agreement (see <xref
          target="RFC9543"/>.</t>

          <t hangText="SLO:">Service target="RFC9543" format="default"/>)</dd>
        <dt>SLO:</dt>
        <dd>Service Level Objective. See Objective (see <xref
          target="RFC9543"/>.</t>

          <t hangText="SLE:">Service target="RFC9543" format="default"/>)</dd>
        <dt>SLE:</dt>
        <dd>Service Level Expectation. See Expectation (see <xref
          target="RFC9543"/>.</t>

          <t hangText="ACTN:">Abstraction target="RFC9543" format="default"/>)</dd>
        <dt>ACTN:</dt>
        <dd>Abstraction and Control of Traffic Engineered TE Networks (see <xref target="RFC8453" format="default"/>)</dd>
        <dt>DetNet:</dt>
        <dd>Deterministic Networking (see <xref target="RFC8453"/>.</t>

          <t hangText="DetNet:">Deterministic Networking. See <xref
          target="RFC8655"/>.</t>

          <t hangText="FlexE:">Flexible target="RFC8655" format="default"/>)</dd>
        <dt>FlexE:</dt>
        <dd>Flexible Ethernet (see <xref target="FLEXE"/>.</t>

          <t hangText="TSN:">Time Sensitive target="FLEXE" format="default"/>)</dd>
        <dt>TSN:</dt>
        <dd>Time-Sensitive Networking (see <xref
          target="TSN"/>.</t>

          <t hangText="VN:">Virtual Network. See target="TSN" format="default"/>)</dd>
        <dt>VN:</dt>
        <dd>Virtual Network (see <xref target="RFC8453"/>.</t>
        </list></t> target="RFC8453" format="default"/>)</dd>
      </dl>
    </section>
    <section anchor="overview-of-the-requirements"
             title="Overview numbered="true" toc="default">
      <name>Overview of the Requirements"> Requirements</name>
      <t>This section provides an overview of the requirements of an enhanced
      VPN service.</t>
      <section anchor="diverse-performance-guarantees"
               title="Performance Guarantees"> numbered="true" toc="default">
        <name>Performance Guarantees</name>
        <t>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>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, Section
        3.6 of
        <xref target="RFC7297"/>).</t> target="RFC7297" sectionFormat="of" section="3.6"/>).</t>
        <t>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 Deterministic Networking (DetNet) <xref target="RFC8655"/> target="RFC8655" format="default"/>
        and Time-Sensitive Networking (TSN) <xref target="TSN"/>. target="TSN" format="default"/>. 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>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"/>, however target="RFC8655" format="default"/>; however,
        additional methods of enhancing the underlay to better support the
        delay guarantees may be needed, and these needed. These methods will need to be
        integrated with the overall service provisioning mechanisms.</t>
        <t>Guaranteed maximum delay variation is a performance guarantee that
        may also be needed. <xref target="RFC8578"/> target="RFC8578" format="default"/> calls up a number of
        cases that need this guarantee, for example example, in electrical utilities.
        Time transfer is an example service that needs a 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>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>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>Best effort</t>
          </li>
          <li>
            <t>Assured bandwidth</t>
          </li>
          <li>
            <t>Guaranteed latency</t>
          </li>
          <li>
            <t>Enhanced delivery</t>
          </list></t>
          </li>
        </ul>
        <t>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>The best effort best-effort service is the basic connectivity service that can
        be provided by current VPNs.</t>
        <t>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 best-effort service with over-capacity
        provisioning,
        provisioning or it can be based on MPLS traffic engineered label
        switching paths 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 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>

<!--[rfced] Please review our update to make this text a bulleted list
     and let us know any objections.

Original:
There are several new technologies that provide some assistance with
this performance guarantee.  Firstly, the IEEE TSN project [TSN]
introduces the concept of scheduling of delay- and loss-sensitive
packets.  FlexE [FLEXE] is also useful to help provide a guaranteed
upper bound to latency.  DetNet is also of relevance in assuring an
upper bound of end-to-end packet latency in the network layer.  The
use of these technologies to deliver enhanced VPN services needs to be
considered when a guaranteed latency service is required.

Current:
There are several new technologies that provide some assistance with
this performance guarantee:

   *  the IEEE TSN project [TSN] introduces the concept of scheduling of
      delay-sensitive and loss-sensitive packets.

   *  FlexE [FLEXE] is useful to help provide a guaranteed upper bound
      to latency.

   *  DetNet is of relevance in assuring an upper bound of end-to-end
      packet latency in the network layer.

The use of these technologies to deliver enhanced VPN services needs
to be considered when a guaranteed latency service is required.
-->

        <t>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. Firstly, the guarantee:</t>
	<ul>
	  <li>the IEEE TSN
        project <xref target="TSN"/> target="TSN" format="default"/> introduces the concept of scheduling of
        delay-
          delay-sensitive and loss-sensitive packets. FlexE packets.</li>
	  <li>FlexE <xref target="FLEXE"/> target="FLEXE" format="default"/> is
        also
          useful to help provide a guaranteed upper bound to latency.
        DetNet latency.</li>
	  <li>DetNet is also of relevance in assuring an upper bound of end-to-end
          packet latency in the network layer. The layer.</li>
	</ul>
	<t>The use of these technologies to
        deliver enhanced VPN services needs to be considered when a guaranteed
        latency service is required.</t>
        <t>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"
               title="Interaction between numbered="true" toc="default">
        <name>Interaction Between Enhanced VPN Services"> Services</name>
        <t>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),
        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"
                 title="Requirements numbered="true" toc="default">
          <name>Requirements on Traffic Isolation">
          <t>Traffic isolation Isolation</name>
          <t>"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 (Section 8.1 of <xref target="RFC9543"/>), (<xref target="RFC9543" sectionFormat="of" section="8.1"/>), 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>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 traffic-isolation
          requirements and, specifically, to prevent data leaks.</t>
          <t>With traffic isolation, a customer expects that the service
          traffic cannot be received by other customers in the same network.
          In <xref target="RFC4176"/>, target="RFC4176" format="default"/>, traffic isolation is mentioned as one
          of the requirements of VPN customers. Traffic isolation is also
          described in Section 3.8 of <xref target="RFC7297"/>.</t> target="RFC7297" sectionFormat="of" section="3.8"/>.</t>
          <t>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 network access and also when transported between Provider Edge
          (PE) Nodes.</t> nodes.</t>
          <t>An enhanced VPN service customer may request traffic isolation
          together with other operator defined operator-defined service characteristics. The
          exact details about the expected behavior need to be specified in
          the service request, request so that meaningful service assurance and
          fulfillment feedback can be exposed to the customers. It is out of
          the scope of this document to elaborate the service modeling service-modeling
          considerations.</t>
        </section>
        <section anchor="limited-interaction-with-other-services"
                 title="Limited numbered="true" toc="default">
          <name>Limited Interaction with Other Services"> Services</name>
          <t><xref target="RFC2211"/> target="RFC2211" format="default"/> describes the Controlled Load Service. 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>Thus, a consumer of a Controlled Load Service controlled-load service may assume
          that:</t>

          <t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>A very high percentage of transmitted packets will be
              successfully delivered by the network to the receiving
              end-nodes.</t>
              end nodes.</t>
            </li>
            <li>
              <t>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>
            </list></t>
            </li>
          </ul>
          <t>An enhanced VPN customer may request a Controlled Load Service controlled-load service in
          one of two ways:</t>

          <t><list style="numbers">
          <ol spacing="normal" type="1"><li>
              <t>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>
              <t>As described in <xref target="RFC2211"/>, target="RFC2211" format="default"/>, a customer may
              request the Controlled Load Service 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
              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>
            </list></t>
            </li>
          </ol>
          <t>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"
                 title="Realization numbered="true" toc="default">
          <name>Realization of Limited Interaction with Enhanced VPN Services"> Services</name>
          <t>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>Concretely, there are many existing techniques which that can be used
          to provide traffic isolation, such as IP and MPLS VPNs or other
          multi- tenant
          multi-tenant virtual network techniques. Controlled Load Services Controlled-load services
          may be realized as described in <xref target="RFC2211"/>. target="RFC2211" format="default"/>. 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 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>

<!--[rfced] In the following text, the use of "both" with 3 items
     connected with "and"s is a bit confusing.  Perhaps a rephrase
     would benefit the reader?

Original:
This may introduce scalability concerns both in the implementation (as
each enhanced VPN may need to be tracked in the network) and in how
many resources need to be reserved and how the services are mapped to
the resources (Section 4.4).

-->

          <t>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 both in the implementation (as each enhanced
          VPN may need to be tracked in the network) and in how many resources
          need to be reserved and how the services are mapped to the resources
          (Section 4.4).
          (<xref target="scalable-mapping"/>). Thus, some trade-off needs to be considered to
          provide the traffic isolation and limited interaction between an
          enhanced VPN services service and other services.</t>

<!--[rfced] How may the uses of slashes in the following be clarified
     for the reader?

Original:
By combining conventional VPNs with TE/QoS/security techniques, an
enhanced VPN offers a variety of means to honor customer's
requirements.

Perhaps:
By combining conventional VPNs with TE, QoS, and security techniques, an
enhanced VPN offers a variety of means to honor customer's
requirements.
-->

          <t>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/security techniques, an
          enhanced VPN offers a variety of means to honor customer's
          requirements.</t>
        </section>
      </section>
      <section anchor="integration"
               title="Integration numbered="true" toc="default">
        <name>Integration with Network Resources and Service Functions"> Functions</name>

<!--[rfced] Does the following rewording correctly capture your
     intent?

Original:
The way to achieve the characteristics demand...

Perhaps:
The way to meet the enhanced VPN service's demand for certain
characteristics (such as guaranteed or predictable performance) is
by...

-->

        <t>The way to achieve the characteristics demand of an enhanced VPN
        service (such as guaranteed or predictable performance) is by
        integrating the overlay VPN with a particular set of resources in the
        underlay network which 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>Taking mobile networks and and, in particular particular, 5G into consideration, the
        integration of the network with service functions is likely a
        requirement. The IETF's work on service function chaining Service Function Chaining (SFC) <xref
        target="RFC7665"/> target="RFC7665" format="default"/> provides a foundation for this. Service functions
        in the underlay network can be considered as 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 title="Abstraction"> numbered="true" toc="default">
          <name>Abstraction</name>
          <t>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"/>, target="RFC7926" format="default"/>, abstraction is the process
          of applying policy to a set of information about a traffic
          engineered (TE) 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>

<!--[rfced] Does the following rewording correctly capture your
     intent?

Original:
With the approach of abstraction,...

Perhaps:
Using the abstraction approach...
-->

          <t>With the approach of abstraction, an enhanced VPN may be built on
          top of an abstracted topology that represents the connectivity
          capabilities of the underlay TE based TE-based network as described in the
          framework for Abstraction and Control of TE Networks (ACTN) <xref
          target="RFC8453"/> target="RFC8453" format="default"/> as discussed further in <xref
          target="management-plane"/>.</t> target="management-plane" format="default"/>.</t>
        </section>
      </section>
      <section anchor="dynamic-configuration" title="Dynamic Changes"> numbered="true" toc="default">
        <name>Dynamic Changes</name>
        <t>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"/>) target="limited-interaction-with-other-services" format="default"/>) must not be
        disrupted by the instantiation or modification of another enhanced VPN
        service. As discussed in Section 3.1 of <xref target="RFC4176"/>, target="RFC4176" sectionFormat="of" section="3.1"/>, 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>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>

<!--[rfced] Is "service SLA" redundant?  Or is it an SLA specifically
     about services?

Original:
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 service SLA.

Perhaps:
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>In addition to non-disruptively 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 volumes. 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
        service SLA.</t>
        <t>The data plane aspects of this problem are discussed further in
        Sections <xref target="L2-DP"/>, target="L2-DP" format="counter"/>, <xref target="NW-DP"> target="NW-DP" format="counter"> </xref>, and <xref
        target="Non-Packet-DP"/>.</t> target="Non-Packet-DP" format="counter"/>.</t>
        <t>The control plane aspects of this problem are discussed further in
        <xref target="control-plane"/>.</t> target="control-plane" format="default"/>.</t>
        <t>The management plane aspects of this problem are discussed further
        in <xref target="management-plane"/>.</t> target="management-plane" format="default"/>.</t>
      </section>
      <section anchor="customized-control-plane" title="Customized Control"> numbered="true" toc="default">
        <name>Customized Control</name>
        <t>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, in some cases 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 customers 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>A description of the control plane aspects of this problem are
        discussed further in <xref target="control-plane"/>. target="control-plane" format="default"/>. A description of
        the management plane aspects of this feature can be found in <xref
        target="management-plane"/>.</t> target="management-plane" format="default"/>.</t>
      </section>
      <section anchor="applicability"
               title="Applicability numbered="true" toc="default">
        <name>Applicability to Overlay Technologies"> Technologies</name>
        <t>The concept of an enhanced VPN can be applied to any existing and
        future multi-tenancy overlay technologies including but not limited
        to:</t>

        <t><list style="symbols">
            <t>Layer-2
        <ul spacing="normal">
          <li>
            <t>Layer 2 point-to-point (P2P) services, such as pseudowires (see <xref
            target="RFC3985"/></t>

            <t>Layer-2 target="RFC3985" format="default"/>)</t>
          </li>
          <li>
            <t>Layer 2 VPNs (see <xref target="RFC4664"/></t> target="RFC4664" format="default"/>)</t>
          </li>
          <li>
            <t>Ethernet VPNs (see <xref target="RFC7209"/>, target="RFC7209" format="default"/> and <xref
            target="RFC7432"/></t>

            <t>Layer-3 target="RFC7432" format="default"/>)</t>
          </li>
          <li>
            <t>Layer 3 VPNs (see <xref target="RFC4364"/>, target="RFC4364" format="default"/> and <xref
            target="RFC2764"/></t>
          </list></t> target="RFC2764" format="default"/>)</t>
          </li>
        </ul>
        <t>Where such VPN service types need enhanced isolation and delivery
        characteristics, the technologies described in <xref target="SDDC"/> target="SDDC" format="default"/>
        can be used to tweak the underlay to provide the required enhanced
        performance.</t>
      </section>
      <section title="Inter-Domain numbered="true" toc="default">
        <name>Inter-Domain and Inter-Layer Network"> Network</name>
        <t>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 (data (the data plane, control plane, and management
        plane) need to provide mechanisms to support multi-domain and
        multi-layer coordination and integration, so as integration; this is to provide the
        required service characteristics for different enhanced VPN services, services
        and improve network efficiency and operational simplicity. The
        mechanisms for multi-domain VPNs (see <xref target="RFC4364"/> target="RFC4364" format="default"/>) 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"
             title="The numbered="true" toc="default">
      <name>The Architecture of NRP-based NRP-Based Enhanced VPNs"> VPNs</name>
      <t>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, services and achieves
      the guaranteed performance for different customers.</t>
      <t>The NRP-based enhanced VPN architecture needs to be designed with
      consideration given to:</t>

      <t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>An enhanced data plane.</t>
        </li>
        <li>
          <t>A control plane to create enhanced VPNs and NRPs, making use of
          the data plane isolation and performance guarantee techniques.</t>
        </li>
        <li>
          <t>A management plane for to manage enhanced VPN service life-cycle
          management.</t> life cycles.</t>
        </li>
        <li>
          <t>The OAM mechanisms for enhanced VPNs and the underlying NRPs.</t>
        </li>
        <li>
          <t>Telemetry mechanisms for enhanced VPNs and the underlying
          NRPs.</t>
        </list>
        </li>
      </ul>
      <t> These topics are expanded below.</t>

      <t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>The enhanced data plane provides:<list style="symbols"> provides:</t>
          <ul spacing="normal">
            <li>
              <t>The required packet latency packet-latency and jitter characteristics.</t>
            </li>
            <li>
              <t>The required packet loss packet-loss characteristics.</t>
            </li>
            <li>
              <t>The required resource isolation resource-isolation capability, e.g., bandwidth
              guarantee.</t>
            </li>
            <li>
              <t>The mechanism to associate a packet with the set of resources
              allocated to an NRP to which the enhanced VPN service packet is
              mapped to.</t>
            </list></t>
              mapped.</t>
            </li>
          </ul>
        </li>
        <li>
          <t>The control plane:<list style="symbols"> plane:</t>
          <ul spacing="normal">
            <li>
              <t>Collects information about the underlying network topology
              and network resources, resources and exports this to network nodes and/or
              a centralized controller as required.</t>
            </li>
            <li>
              <t>Creates NRPs with the network resource and topology
              properties needed by the enhanced VPN services.</t>
            </li>
            <li>
              <t>Distributes the attributes of NRPs to network nodes which that
              participate in the NRPs and/or a centralized controller.</t>
            </li>
            <li>
              <t>Computes and sets up network paths in each NRP.</t>
            </li>
            <li>
              <t>Maps enhanced VPN services to an appropriate NRP.</t>
            </li>
            <li>
              <t>Determines the risk of SLA violation and takes appropriate
              avoiding/correction
              avoidance/correction actions.</t>
            </li>
            <li>
              <t>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>
            </list></t>
            </li>
          </ul>
        </li>
        <li>
          <t>The management plane includes management interfaces, the
          Operations, Administration, and Maintenance (OAM) and Telemetry telemetry
          mechanisms. More specifically, it provides:<list style="symbols">
              <t>An provides:</t>
          <ul spacing="normal">

<!--[rfced] Because "requests" can be read as a noun or a verb, might
     an update such as the following (i.e., the operation requests /
     the operation's requests) help readers avoid a "garden path"
     issue?  Or is there another way to rephrase?

Original:
An interface between the enhanced VPN service provider (e.g.,
operator's network management system) and the enhanced VPN customer
(e.g., an organization or a service with enhanced VPN requirement)
such that the operation requests and the related parameters can be
exchanged without the awareness of other enhanced VPN customers.

Perhaps:
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 operation's requests and the related parameters can be
exchanged without the awareness of other enhanced VPN customers.
-->

            <li>
              <t>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 operation requests and the related
              parameters can be exchanged without the awareness of other
              enhanced VPN customers.</t>
            </li>
            <li>
              <t>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>
              <t>The service life-cycle management and operation of enhanced
              VPN services (e.g., creation, modification,
              assurance/monitoring, and decommissioning).</t>
            </li>
            <li>
              <t>The OAM tools to verify whether the underlay network
              resources (i.e. (i.e., NRPs) are correctly allocated and operating
              properly.</t>
            </li>
            <li>
              <t>The OAM tools to verify the connectivity and monitor the
              performance of the enhanced VPN service.</t>
            </li>
            <li>
              <t>Telemetry of information in the underlay network for overall
              performance evaluation and the planning of the enhanced VPN
              services.</t>
            </li>
            <li>
              <t>Telemetry of information of enhanced VPN services for
              monitoring and analytics of the characteristics and SLA
              fulfillment of the enhanced VPN services.</t>
            </list></t>
        </list></t>
            </li>
          </ul>
        </li>
      </ul>
      <section anchor="COMLAY" title="Layered Architecture"> numbered="true" toc="default">
        <name>Layered Architecture</name>
        <t>The layered architecture of NRP-based enhanced VPNs is shown in
        <xref target="LAFIG"/>.</t> target="LAFIG" format="default"/>.</t>
        <t>Underpinning everything is the physical network infrastructure
        layer
        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 as to be a virtual link or virtual node used to
        build the NRPs.</t>
        <figure anchor="LAFIG"
                title="The anchor="LAFIG">
          <name>The Layered Architecture of Enhanced VPNs"> VPNs</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                           /\
                           ||
                 +-------------------+       Centralized
                 | Network Controller|   Control & 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>Various components and techniques discussed in <xref
        target="SDDC"/> target="SDDC" format="default"/> 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>Based

<!--[rfced] FYI - we have broken this long sentence into a bulleted
     list for the ease of the reader.  Please review and ensure we
     have maintained your intended meaning.

Original:
   Based on the set of network resource partitions provided by the
   physical network infrastructure, multiple NRPs can be created, each
   with a set of dedicated or shared network resources allocated from
   the physical underlay network, and each can be associated with a
   customized logical network topology, so as to meet the requirements
   of different enhanced VPN services or different groups of enhanced
   VPN services. According

Current:
   Based on the set of network resource partitions provided by the
   physical network infrastructure, multiple NRPs can be created.  Each
   of these NRPs:

   *  has a set of dedicated or shared network resources allocated from
      the physical underlay network, and

   *  can be associated with a customized logical network topology so as
      to meet the requirements of different enhanced VPN services or
      different groups of enhanced VPN services.
-->

        <t>Based on the set of network resource partitions provided by the
        physical network infrastructure, multiple NRPs can be created. Each of these NRPs:</t><ul>
	<li>has a set of dedicated or shared network resources allocated from the
        physical underlay network, and</li>
	<li>can be associated with a
        customized logical network topology so as to meet the requirements of
        different enhanced VPN services or different groups of enhanced VPN
        services.</li>
      </ul>
      <t>According to the associated logical network topology, each
        NRP needs to be instantiated on a set of network nodes and links which that
        are involved in the logical topology. And on On each node or link, each
        NRP is associated with a set of local resources which 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>According

<!--[rfced] Does this sentence contain a list of three items and an
     "etc."? If our update does not correctly capture your intent,
     please let us know.

Original:
   According to the service requirements of connectivity, performance
   and isolation, etc., enhanced VPN services can be mapped to the
   appropriate NRPs in the network.

Current:
   According to the service requirements of connectivity, performance,
   isolation, etc., enhanced VPN services can be mapped to the
   appropriate NRPs in the network. -->

        <t>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, while NRPs; it is also possible that multiple
        enhanced VPN services are mapped to the same NRP. Thus, the NRP is an
        essential scaling technique, 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 are 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"/> target="scalable-mapping" format="default"/> for more information).</t>
        <t>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>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 NRP, these resources can, if required, can
        be managed via a dynamic control plane. plane if required. This provides the required
        scalability and isolation with some flexibility.</t>
      </section>
      <section anchor="multi-point-to-multi-point" title="Connectivity Types"> numbered="true" toc="default">
        <name>Connectivity Types</name>
        <t>At the VPN service level, the required connectivity for an MP2MP 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 end points.</t> endpoints.</t>
        <t>Other service requirements may be expressed at different
        granularities, some of which can be applicable to the whole service, service
        while some others may only be applicable to some pairs of end points. 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"
               title="Application-Specific numbered="true" toc="default">
        <name>Application-Specific Data Types"> Types</name>
        <t>Although a lot of the traffic that will be carried over enhanced
        VPN will likely be IP-based, IP based, the design must be capable of carrying
        other traffic types, in particular Ethernet traffic. This is easily
        accomplished through the various pseudowire (PW) techniques <xref
        target="RFC3985"/>.</t> target="RFC3985" format="default"/>.</t>
        <t>Where the underlay is MPLS, Ethernet traffic can be carried over an
        enhanced VPN encapsulated according to the method specified in <xref
        target="RFC4448"/>. target="RFC4448" format="default"/>. Where the underlay is IP, Layer Two L2 Tunneling
        Protocol - Version 3 (L2TPv3) <xref target="RFC3931"/> target="RFC3931" format="default"/> can be used
        with Ethernet traffic carried according to <xref target="RFC4719"/>. target="RFC4719" format="default"/>.
        Encapsulations have been defined for most of the common layer-2 L2 types
        for both PW over MPLS and for L2TPv3.</t>
      </section>
      <section anchor="scalable-mapping" title="Scalable numbered="true" toc="default">
        <name>Scalable Service Mapping"> Mapping</name>
        <t>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>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, and beginning: even in the future 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>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><xref target="I-D.ietf-teas-nrp-scalability"/> target="I-D.ietf-teas-nrp-scalability" format="default"/> provides more
        details of scalability considerations for the NRPs used to instantiate
        NRPs, and <xref target="scalability-considerations"/> target="scalability-considerations" format="default"/> includes a
        greater discussion of scalability considerations.</t>
      </section>
    </section>
    <section anchor="SDDC" title="Candidate Technologies"> numbered="true" toc="default">
      <name>Candidate Technologies</name>

<!--[rfced] Does this suggested rephrase retain your intended meaning?

Original:
A path that travels by other than the shortest path through the
underlay normally requires state to specify that path.

Perhaps:
Any path other than the shortest path through the underlay normally
requires state to specify that path.

-->

      <t>A VPN is a virtual network 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. A path that travels by 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, protocol or directly
      through the use of an SDN a Software-Defined Networking (SDN) controller. Based on Segment Routing, Routing (SR), state
      could be maintained at the ingress node of the path, 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
      resource
      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>This section describes the candidate technologies, technologies and examines them
      in the context of the different network planes that may be used together
      to build NRPs. <xref target="L2-DP"/> target="L2-DP" format="default"/> discusses the layer-2 L2 packet-based
      or frame-based forwarding plane forwarding-plane mechanisms for resource partitioning.
      <xref target="NW-DP"/> target="NW-DP" format="default"/> 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"/>. target="Non-Packet-DP" format="default"/>. The
      control plane and management plane mechanisms are discussed in Sections <xref
      target="control-plane"/> target="control-plane" format="counter"/> and <xref target="management-plane"/> target="management-plane" format="counter"/>, respectively.</t>
      <section anchor="L2-DP"
               title="Underlay numbered="true" toc="default">
        <name>Underlay Forwarding Resource Partitioning"> Partitioning</name>
        <t>Several candidate layer-2 L2 packet-based or frame-based forwarding
        plane forwarding-plane mechanisms which that can provide the required traffic isolation and
        performance guarantees are described in the following sections.</t>
        <section anchor="flexe" title="Flexible Ethernet"> numbered="true" toc="default">
          <name>Flexible Ethernet</name>

<!--[rfced] Does this rephrase capture your intended meaning?

Original:
FlexE also supports bonding links to create larger links out of
multiple low-capacity links.

Perhaps:
FlexE also supports bonding multiple low-capacity links to create
larger links.
-->

<!--[rfced] We had two questions about the following sentence:

a) Is the repetition of "downstream node" necessary?
b) Will the reader understand what "that traffic isolation" is?

Original:
When packets are received by the downstream node, they need to be
processed in a way that preserves that traffic isolation in the
downstream node.

Perhaps:
When packets are received by the downstream node, they need to be
processed in a way that preserves traffic isolation.

-->

          <t>FlexE <xref target="FLEXE"/> target="FLEXE" format="default"/> 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 links to
          create larger links out of multiple low-capacity links.</t>
          <t>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 that traffic isolation in the downstream node. This
          in turn In turn, this requires a queuing and forwarding implementation that
          preserves the end-to-end separation of enhanced VPNs.</t>
          <t>If different FlexE channels are used for different services, then
          no sharing is possible between the FlexE channels. This means that 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" title="Dedicated Queues">
          <t>DiffServ-based numbered="true" toc="default">
          <name>Dedicated Queues</name>
          <t>Diffserv-based queuing systems are described in <xref
          target="RFC2475"/> target="RFC2475" format="default"/> and <xref target="RFC4594"/>. target="RFC4594" format="default"/>. This approach is
          not sufficient to provide separation of enhanced VPN services
          because DiffServ Diffserv does not provide enough markers to differentiate
          between traffic of a large number of enhanced VPN services.
          Additionally, DiffServ 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, underlay because MPLS
          only provides eight traffic classes.</t>
          <t>In addition, DiffServ, 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>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 which that could
          support this, 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"
                 title="Time Sensitive Networking">
          <t>Time-Sensitive Networking (TSN) <xref target="TSN"/> numbered="true" toc="default">
          <name>Time-Sensitive Networking</name>
          <t><xref target="TSN" format="default"/> 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
          experiences will
          experience no queuing delay or increase in latency beyond the 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>Ethernet can be emulated over a layer-3 L3 network using an IP or
          MPLS pseudowire. However, a TSN Ethernet payload would be opaque to
          the underlay and thus underlay; thus, it would not be treated specifically as time-sensitive
          data. The preferred method of carrying TSN over a layer-3 L3 network is
          through the use of deterministic networking as explained in <xref
          target="deterministic-networking"/>.</t> target="deterministic-networking" format="default"/>.</t>
        </section>
      </section>
      <section anchor="NW-DP"
               title="Network numbered="true" toc="default">
        <name>Network Layer Encapsulation and Forwarding"> Forwarding</name>
        <t>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"
                 title="Deterministic Networking">
          <t>Deterministic numbered="true" toc="default">
          <name>Deterministic Networking (DetNet) (DetNet)</name>
          <t>DetNet <xref target="RFC8655"/> target="RFC8655" format="default"/> is a
          technique being developed in the IETF to enhance the ability of
          layer-3
          L3 networks to deliver packets more reliably and with greater
          control over the delay. The design cannot use re-transmission retransmission
          techniques such as TCP since 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"/> target="RFC8939" format="default"/> or the MPLS data plane <xref
          target="RFC8964"/>, target="RFC8964" format="default"/>, and it may be used to provide deterministic paths
          for enhanced VPN services.</t>
        </section>
        <section anchor="mpls-traffic-engineering-mpls-te"
                 title="MPLS numbered="true" toc="default">
          <name>MPLS Traffic Engineering (MPLS-TE)"> (MPLS-TE)</name>
          <t>MPLS-TE (see <xref target="RFC2702" format="default"/> and <xref target="RFC2702"/><xref target="RFC3209"/> target="RFC3209" format="default"/>)
          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
          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 traffic
          engineering in their networks.</t>
        </section>
        <section anchor="SR" title="Segment Routing"> numbered="true" toc="default">
          <name>Segment Routing</name>
          <t>Segment Routing (SR) <xref target="RFC8402"/> target="RFC8402" format="default"/> is a method that
          prepends instructions to packets at the head-end 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"/> target="RFC8660" format="default"/>) or the IPv6
          data plane (SRv6) (see <xref target="RFC8986"/>.</t> target="RFC8986" format="default"/>).</t>
          <t>An SR traffic engineered path operates with a 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"/>.</t> target="I-D.ietf-spring-resource-aware-segments" format="default"/>.</t>
          <t>Note that the concept of a queue is a useful abstraction for
          different types of underlay mechanism 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
          layer-3
          L3 data plane and control plane mechanisms used.</t>
          <t>With Segment Routing, 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
          SR-based mechanism could be used to provide both resource reserved resource-reserved
          paths and NRPs for enhanced VPN services.</t>
        </section>
        <section title="New numbered="true" toc="default">
          <name>New Encapsulation Extensions"> Extensions</name>
          <t>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, VPN and the logical
          network topology or paths associated with an enhanced VPN. This may
          require more protocol work, while work; however, the potential benefit is 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"/>.</t> target="I-D.ietf-teas-nrp-scalability" format="default"/>.</t>
        </section>
      </section>
      <section anchor="Non-Packet-DP" title="Non-Packet numbered="true" toc="default">
        <name>Non-Packet Data Plane"> Plane</name>
        <t>Non-packet underlay data plane technologies, such as optical based optical-based
        data planes planes, often have TE properties and behaviors, and behaviors. They meet many of
        the key requirements in particular for bandwidth guarantees, traffic requirements, particularly those for:</t>
	<ul>
	  <li>bandwidth guarantees,</li>
	  <li>traffic
        isolation (with physical isolation often being an integral part of the
        technology), highly
        technology),</li>
	<li>highly predictable latency and jitter characteristics,
        measurable characteristics,</li>
	<li>measurable loss characteristics, and ease and</li>
	<li>ease of identification of flows.
        The flows.</li>
      </ul>
      <t>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" title="Control Plane">
        <t>The numbered="true" toc="default">
        <name>Control Plane</name>

<!--[rfced] Are both of these sentences about GCO?  Please review our
     updates and let us know any objections.

Original 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, whilst still relying on a distributed control plane to
provide scalability, high reliability, fast reaction, automatic
failure recovery, etc.

Current 1:
The control plane of NRP-based enhanced VPNs is likely to be based on
a hybrid control mechanism that takes advantage of a logically
centralized controller for on-demand provisioning and Global
Concurrent Optimization (GCO) while still relying on a distributed
control plane to provide scalability, high reliability, fast reaction,
automatic failure recovery, etc.

Original 2:
The global concurrent optimization mechanisms as described in
[RFC5557] and discussed in [RFC7399] may be helpful, while complete
resolution of this situation is as much a commercial issue as it is a
technical issue.

Current 2:
The GCO mechanisms as described in [RFC5557] and discussed in
[RFC7399] may be helpful, while complete resolution of this situation
is as much a commercial issue as it is a technical issue.
-->

        <t>The control plane of NRP-based enhanced VPNs is likely to be based on
        a hybrid control mechanism that takes advantage of a logically
        centralized controller for on-demand provisioning and Global Concurrent
        Optimization (GCO) 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>As described in Section 4, <xref target="architecture-and-components-of-vpn"/>, the enhanced VPN control plane needs to
        provide the following functions: <list style="symbols">
            <t>Collect </t>
        <ul spacing="normal">
          <li>
            <t>Collection of information about the underlying network topology and
            network resources, resources and exports exportation of this to network nodes and/or a
            centralized controller as required.</t>

            <t>Create
          </li>
          <li>
            <t>Creation of NRPs with the network resource and topology properties
            needed by NRP-based enhanced VPN services.</t>

            <t>Distribute
          </li>
          <li>
            <t>Distribution of the attributes of NRPs to network nodes which that
            participate in the NRPs and/or the centralized controller.</t>

            <t>Map
          </li>
          <li>
            <t>Mapping of enhanced VPN services to an appropriate NRP.</t>

            <t>Compute
          </li>
          <li>
            <t>Computation and set up of service paths in each NRP to meet enhanced
            VPN service requirements.</t>
          </list></t>

        <t>The collection of underlying
          </li>
        </ul>
        <t>Underlying network topology and resource
        information can be done collected using mechanisms based on the existing IGP and Border Gateway
        Protocol - Link State (BGP-LS) <xref target="RFC9552"/> based
        mechanisms. target="RFC9552" format="default"/>. 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"/>.</t> target="RFC4655" format="default"/>.</t>
        <t>Two candidate control plane mechanisms for path setup in the NRP
        are:
        are RSVP-TE and Segment Routing (SR).</t>

        <t><list style="symbols">
            <t>RSVP-TE
        <ul spacing="normal">
          <li>
            <t>RSVP-TE, as described in <xref target="RFC3209"/> target="RFC3209" format="default"/>, 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 which that could be used to bind
            the VPN to a specific set of network resources allocated within the
            underlay, but
            underlay; however, there remain scalability concerns concerns, as mentioned in
            <xref target="mpls-traffic-engineering-mpls-te"/>.</t> target="mpls-traffic-engineering-mpls-te" format="default"/>.</t>
          </li>
          <li>
            <t>The SR control plane plane, as described in <xref target="RFC8665"/> target="RFC8665" format="default"/>, <xref
            target="RFC8667"/> target="RFC8667" format="default"/>, and <xref target="RFC9085"/> target="RFC9085" format="default"/>, 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"/> target="RFC9256" format="default"/> to the headend nodes of the paths.</t>
          </list></t>
          </li>
        </ul>
        <t>According to the service requirements for connectivity, performance performance,
        and isolation, one enhanced VPN service may be mapped to a dedicated
        NRP,
        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, and 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" title="Management Plane"> numbered="true" toc="default">
        <name>Management Plane</name>
        <t>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>

<!--[rfced] Does the following suggested text capture your intended
     meaning?  If not, is there another possible rephrase of the
     original?

Original:
Thus, an interface between the enhanced VPN management plane and the
5G network slice management system, and relevant service data models
are needed for the coordination of 5G end-to-end network slice
management.

Perhaps:
Thus, the coordination of 5G end-to-end network slice management
requires both relevant service data models and an interface between
the enhanced VPN management plane and the 5G network slice management
system.

-->

        <t>As an example, in the context of 5G end-to-end network slicing
        <xref target="TS28530"/>, target="TS28530" format="default"/>, 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, an interface between the enhanced
        VPN management plane and the 5G network slice management system, and
        relevant service data models are needed for the coordination of 5G
        end-to-end network slice management.</t>
        <t>The management plane interface and data models for enhanced VPN
        services can be based on the service models described in <xref
        target="sdm-app"/>.</t> target="sdm-app" format="default"/>.</t>
        <t>It is important that the management life-cycle supports management support in-place
        modification of enhanced VPN services. That is, it should be possible
        to add and remove end points, 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, and it made. It will additionally 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>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>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, needed so that a that:</t>
	<ul>
	  <li>a customer cannot exceed
          the capabilities of the virtual links and nodes, but but</li>
	  <li>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. This network.</li>
	</ul>
	<t>This approach requires
        a management system for the virtual network, 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"
               title="Applicability numbered="true" toc="default">
        <name>Applicability of Service Data Models to Enhanced VPNs"> VPNs</name>
        <t>This section describes the applicability of the existing and
        in-progress service data models to enhanced VPNs. <xref
        target="RFC8309"/> target="RFC8309" format="default"/> 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>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 Layer 3 VPN L3VPN Service Model (L3SM)
        in <xref target="RFC8299"/>, target="RFC8299" format="default"/>, the Layer 2 VPN L2VPN Service Model (L2SM) in <xref
        target="RFC8466"/>), target="RFC8466" format="default"/>), or the ACTN Virtual Network (VN) model in <xref
        target="I-D.ietf-teas-actn-vn-yang"/>) target="RFC9731" format="default"/>) are service models which that can
        provide the customer's view of the enhanced VPN service. The Layer-3
        VPN L3VPN
        Network Model (L3NM) from <xref target="RFC9182"/>, target="RFC9182" format="default"/> and the Layer-2 VPN
        network model L2VPN
        Network Model (L2NM) from <xref target="RFC9291"/> target="RFC9291" format="default"/> 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"/> target="RFC9408" format="default"/> provides an abstract view of the service
        attachment points Service
        Attachment Points (SAPs) to various network services in the provider
        network, where enhanced VPN could be one of the service types. <xref
        target="RFC9375"/> target="RFC9375" format="default"/> 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"/> target="I-D.ietf-teas-nrp-yang" format="default"/> 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"
             title="Applicability numbered="true" toc="default">
      <name>Applicability in Network Slice Realization"> Realization</name>
      <t>This section describes the applicability of NRP-based enhanced VPN
      for network slice realization.</t>
      <t>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"/> target="I-D.ietf-teas-ietf-network-slice-nbi-yang" format="default"/> 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 Section 5.2 of <xref target="RFC9543"/>), target="RFC9543" sectionFormat="of" section="5.2"/>), an SDP can
      be mapped to a CE, 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 end point 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"/>.</t> target="I-D.ietf-teas-ietf-network-slice-nbi-yang" format="default"/>.</t>
      <section title="NRP Planning"> numbered="true" toc="default">
        <name>NRP Planning</name>
        <t>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>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
        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 title="NRP Creation"> numbered="true" toc="default">
        <name>NRP Creation</name>
        <t>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 section 5.1 <xref target="L2-DP"/> can be used to
        partition the forwarding plane forwarding-plane network resources and allocate
        different subsets of resources to different NRPs. In addition, the
        data plane identifiers which 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. either using, e.g.,
        resource-aware SR segments as specified in <xref
        target="I-D.ietf-spring-resource-aware-segments"/> target="I-D.ietf-spring-resource-aware-segments" format="default"/> and <xref
        target="I-D.ietf-spring-sr-for-enhanced-vpn"/>, target="I-D.ietf-spring-sr-for-enhanced-vpn" format="default"/> or a dedicated
        Resource ID as specified in <xref
        target="I-D.ietf-6man-enhanced-vpn-vtn-id"/> target="I-D.ietf-6man-enhanced-vpn-vtn-id" format="default"/> can be introduced. The
        network nodes involved in an NRP may distribute the logical topology
        information, the NRP-specific network resource information information, and the
        Resource Identifier 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, NRP and to install the NRP
        specific NRP-specific forwarding entries to network nodes.</t>
      </section>
      <section title="Network numbered="true" toc="default">
        <name>Network Slice Service Provisioning"> Provisioning</name>
        <t>According to the connectivity requirements of an 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"/>.</t>

        <t>Then target="applicability" format="default"/>.</t>
        <t>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 together provide provides a network slice service.</t>
      </section>
      <section title="Network numbered="true" toc="default">
        <name>Network Slice Traffic Steering and Forwarding "> Forwarding</name>
        <t>At the edge of the operator's network, traffic of network slices slice traffic
        can be classified based on the rules defined by the operator's policy, policy;
        this is so that the traffic which that matches the rules for specific network slice
        services can be mapped to the corresponding NRP. This way, Thus, packets
        belonging to a specific network slice service will be processed and
        forwarded by network nodes based either the on either:</t>
	<ul spacing="compact">
	  <li>the traffic-engineered paths
        or the or</li>
	  <li>the shortest paths in the associated network topology, using topology</li>
	</ul>
	<t>using the
        set of network resources of the corresponding NRP.</t>
      </section>
    </section>
    <section anchor="scalability-considerations"
             title="Scalability Considerations"> numbered="true" toc="default">
      <name>Scalability Considerations</name>
      <t>NRP-based enhanced VPNs provide performance guaranteed services in
      packet networks, but 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 brought into the network:</t>

      <t><list style="symbols">
          <t>Introduce added:</t>
      <ul spacing="normal">
        <li>
          <t>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. The A further cost is also that systems will have to provide NRP
          specific 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>

          <t>Introduce
        </li>
        <li>
          <t>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 example, explicitly specifying queuing policy. It is also
          possible to use other methods to introduce path state, such as via
          an SDN controller, controller or possibly by modifying a routing protocol. With
          this approach 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>

          <t>Provide
        </li>
        <li>
          <t>by providing a hybrid approach. One example is based on using binding
          SIDs (see <xref target="RFC8402"/> target="RFC8402" format="default"/>) to represent path fragments, fragments and bind 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 SRv6, the packet size may also be reduced
          by utilizing the compression techniques as specified in <xref
          target="I-D.ietf-spring-srv6-srh-compression"/>.</t>
        </list></t>

      <t>Reducing target="I-D.ietf-spring-srv6-srh-compression" format="default"/>.</t>
        </li>
      </ul>

<!--[rfced] What is the antecedent of "it" in this sentence?  Please
     clarify.

Original:
Reducing the state in the network is important to enhanced VPNs, as
it requires the overlay to be more closely integrated with the
underlay than with conventional VPNs.

Perhaps:
Reducing state in the network is important to enhanced VPNs, as
state requires the overlay to be more closely integrated with the
underlay than with conventional VPNs.
-->

      <t>Reducing state in the network is important to enhanced VPNs, as
      it requires 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
      the
      state about fine granularity 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 as 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, nodes and transiently carried in the
      packets as SIDs.</t>
      <t>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"/>.</t> target="I-D.ietf-teas-nrp-scalability" format="default"/>.</t>
      <section anchor="maximum-stack-depth" title="Maximum numbered="true" toc="default">
        <name>Maximum Stack Depth of SR"> SR</name>
        <t>One of the challenges with SR is the stack depth that nodes are
        able to impose on packets <xref target="RFC8491"/>. target="RFC8491" format="default"/>. This leads to a
        difficult balance between adding between:</t>
	<ul spacing="compact">
	  <li>adding state to the network and minimizing
          stack depth, or minimizing depth and</li>
	  <li>minimizing state and increasing the stack depth.</t> depth.</li>
	</ul>
      </section>
      <section anchor="rsvp-scalability" title="RSVP-TE Scalability"> numbered="true" toc="default">
        <name>RSVP-TE Scalability</name>
        <t>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"/>.</t> target="RFC8370" format="default"/>.</t>
        <t>There is also concern at the scalability of the forwarder footprint
        of RSVP-TE as the number of paths through a label switching router Label Switching Router
        (LSR) grows. <xref target="RFC8577"/> target="RFC8577" format="default"/> addresses this by employing SR
        within a tunnel established by RSVP-TE.</t>
      </section>
      <section title="SDN Scaling">
        <t/> numbered="true" toc="default">
        <name>SDN Scaling</name>

<!--[rfced] In the following, what "can reduce the overhead of control
     channels"?  The approach?  Please clarify

Original:
The centralized approach of SDN requires control plane state to be
stored in the network, but can reduce the overhead of control channels
to be maintained.-->

        <t>The centralized approach of SDN 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 comparing compared to the need of maintaining control channels with a
        set of neighbor nodes.</t>
        <t>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, 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" title="Enhanced Resiliency"> numbered="true" toc="default">
      <name>Enhanced Resiliency</name>
      <t>Each enhanced VPN service has a life cycle, cycle and may need modification
      during deployment as the needs of its tenant change. This is discussed
      in change (see <xref target="management-plane"/>. target="management-plane" format="default"/>). Additionally, as the network
      evolves, there garbage collection may need to perform garbage collection be performed to consolidate
      resources into usable quanta.</t>
      <t>Systems in which the path is imposed, such as SR or some form of
      explicit routing, tend to do well in these applications, applications because it is
      possible to perform an atomic transition from one path to another. That
      is, a single action by the head-end 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 GCO mechanisms as
      described in <xref target="RFC5557"/> target="RFC5557" format="default"/> and discussed in <xref
      target="RFC7399"/> target="RFC7399" format="default"/> may be helpful, while complete resolution of this
      situation is as much a commercial issue as it is a technical issue.</t>

      <t>There are, however,
      <t>However, there are two manifestations of the latency problem that
      are for further study in any of these approaches:</t>

      <t><list style="symbols">
          <t>The problem of packets
      <ul spacing="normal">
        <li>
          <t>Packets overtaking one another if a path latency
          reduces during a transition.</t>

          <t>The problem of transient
        </li>
        <li>
          <t>Transient variation in latency in either direction
          as a path migrates.</t>
        </list></t>
        </li>
      </ul>
      <t>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
      50ms
      50 ms <xref target="RFC5654"/>. target="RFC5654" format="default"/>. 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 replication replications and the
      culling of later packets <xref target="RFC8655"/>.</t> target="RFC8655" format="default"/>.</t>
      <t>In addition to the approach used to protect high priority high-priority packets,
      consideration should be given to the impact of best effort best-effort traffic on
      the high priority high-priority packets during a transition. Specifically, if a
      conventional re-convergence process is used used, there will inevitably be
      micro-loops and whilst and, while some form of explicit routing will protect the
      high priority
      high-priority traffic, lower priority lower-priority traffic on best effort best-effort shortest
      paths will micro-loop without the use of a loop prevention loop-prevention technology.
      To provide the highest quality of service to high priority high-priority traffic,
      either this traffic must be shielded from the micro-loops, micro-loops or
      micro-loops must be prevented completely.</t>
    </section>
    <section anchor="oam-and-instrumentation"
             title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>This section describes the considerations about the OAM and Telemetry telemetry
      mechanisms used to support the verification, monitoring 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"/>
      that target="management-plane" format="default"/>, which gives consideration of to the management plane techniques that can be
      used to build NRPs.</t>
      <section title="OAM Considerations"> numbered="true" toc="default">
        <name>OAM Considerations</name>

<!--[rfced] The verb "consider" seems a bit odd with a non-human
     subject in the following two sentences.  We will update to the
     suggestions below unless we hear objection.

Original:
The design of OAM for enhanced VPN services needs to consider the
following requirements:

Perhaps:
The following requirements need to be considered in the design of OAM
for enhanced VPN services:

Original:
Telemetry for enhanced VPN service needs to consider the following
requirements:

Perhaps:
The following requirements need to be considered for telemetry for
enhanced VPN service:

-->

        <t>The design of OAM for enhanced VPN services needs to consider the
        following requirements:</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>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 the set of resources as the service packets mapped to the
            NRP.</t>
          </li>
          <li>
            <t>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>
            <t>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>
          </list>A
          </li>
        </ul>
        <t>A study of OAM in SR networks is documented in <xref
        target="RFC8403"/>.</t> target="RFC8403" format="default"/>.</t>
      </section>
      <section title="Telemetry Considerations"> numbered="true" toc="default">
        <name>Telemetry Considerations</name>
        <t>Network visibility is essential for network operation. Network
        telemetry has been considered as to be an ideal means to gain sufficient
        network visibility with better flexibility, scalability, accuracy,
        coverage, and performance than conventional OAM technologies.</t>
        <t>As defined in <xref target="RFC9232"/>, target="RFC9232" format="default"/>, the objective of Network
        Telemetry 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. Telemetry for enhanced VPN service needs to consider the
        following requirements: <list style="symbols"> </t>
        <ul spacing="normal">
          <li>
            <t>Collecting data of NRPs for overall performance evaluation and
            the planning of the enhanced VPN services.</t>
          </li>
          <li>
            <t>Collecting data of each enhanced VPN service for monitoring and
            analytics of the service characteristics and SLA fulfillment.</t>
          </list></t>
          </li>
        </ul>
        <t>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 title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>It is expected that NRP-based enhanced VPN services will be
      introduced in networks which 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 (as described in
      <xref target="sdm-app"/> target="sdm-app" format="default"/>) can be used for the life-cycle management of
      enhanced VPN services, such as service creation, modification,
      performance monitoring monitoring, and decommissioning.</t>

      <t/>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>All types of virtual network 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 end points endpoints
      outside that VPN. In this regard regard, the enhanced VPN neither introduces, introduces
      nor experiences greater security risks than other VPNs.</t>
      <t>However, in an enhanced VPN service service, the additional service
      requirements need to be considered. For example, if a service requires a
      specific upper bound to latency 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 respects, this
      makes the enhanced VPN more susceptible to attacks since the SLA may be
      broken. But another Another view is that the operator must, in any case, preform
      monitoring of the enhanced VPN to ensure that the SLA is met, and this
      means that 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>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>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 own security requirements
      themselves
      themselves, possibly by encrypting traffic before handing it off to the
      service provider.</t>
      <t>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, customer nor should the sites that are members of an enhanced
      VPN be externally visible.</t>
      <t>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" title="IANA Considerations">
      <t>There are numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>This document has no requested IANA actions.</t>
    </section>

    <section anchor="contributors" title="Contributors">
      <t><figure>
          <artwork><![CDATA[
   Daniel King
   Email: daniel@olddog.co.uk

   Adrian Farrel
   Email: adrian@olddog.co.uk

   Jeff Tantsura
   Email: jefftant.ietf@gmail.com

   Zhenbin Li
   Email: lizhenbin@huawei.com

   Qin Wu
   Email: bill.wu@huawei.com

   Bo Wu
   Email: lana.wubo@huawei.com

   Daniele Ceccarelli
   Email: daniele.ietf@gmail.com

   Mohamed Boucadair
   Email: mohamed.boucadair@orange.com

   Sergio Belotti
   Email: sergio.belotti@nokia.com

   Haomian Zheng
   Email: zhenghaomian@huawei.com           ]]></artwork>
        </figure></t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank Charlie Perkins, James N Guichard,
      John E Drake, Shunsuke Homma, Luis M. Contreras, and Joel Halpern for
      their review and valuable comments.</t>

      <t>This work was supported in part by the European Commission funded
      H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).</t>
    </section>

  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.9543'?>

      <?rfc ?>

    <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>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9543.xml"/>
      </references>

    <references title="Informative References">
      <references>
        <name>Informative References</name>

        <reference anchor="TS23501" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144">
          <front>
          <title>3GPP TS23.501</title>
            <title>System architecture for the 5G system (5GS)</title>
            <author>
            <organization/>
              <organization>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">
          <front>
          <title>3GPP TS28.530</title>
            <title>Management and orchestration; Concepts, use cases and requirements</title>
            <author>
            <organization/>
              <organization>3GPP</organization>
            </author>
            <date year=""/>
          </front>
          <seriesInfo name="3GPP TS" value="28.530"/>
        </reference>

<!-- [rfced] Please review the reference entry [NGMN-NS-Concept].

The original URL navigates to a search results page that states
"Nothing Found". We were unable to find any URL with a title matching
the one provided in this reference. (Note: the author element is also
unusual).

We were able to find the following document that matches some of the
information provided in the URL string:

https://www.ngmn.org/wp-content/uploads/Publications/2016/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf

Is this the correct reference? If so, may we update this reference to
use the information from this document? (Note that this reference is a
draft of Version 1.0.8). -->

<!--
XML for the possible updated 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">
          <front>
            <title>NGMN 5G P1 Requirements and Architecture Work Stream End-to-End Architecture: Description of Network Slicing Concept</title>
            <author>
              <organization>NGMN Alliance</organization>
            </author>
            <date day="14" month="September" year="2016"/>
          </front>
          <refcontent>Version 1.0.8 (draft)</refcontent>
        </reference>

-->
        <reference anchor="NGMN-NS-Concept" target="https://www.ngmn.org/fileadmin/user_upload/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf">
          <front>
            <title>NGMN NS Concept</title>
            <author>
              <organization>hao ,</organization>
            </author>
            <date year=""/>
          </front>
        </reference>

        <reference anchor="FLEXE" target="https://www.oiforum.com/wp-content/uploads/2019/01/OIF-FLEXE-01.0.pdf">
          <front>
            <title>Flex Ethernet Implementation Agreement</title>
            <author>
            <organization/>
              <organization>Optical Internetworking Forum</organization>
            </author>
            <date month="March" year="2016"/>
          </front>
          <refcontent>IA # OIF-FLEXE-01.0</refcontent>
        </reference>

        <reference anchor="TSN" target="https://1.ieee802.org/tsn/">
          <front>
          <title>"Time-Sensitive Networking", IEEE 802.1 Time-Sensitive
            <title>Time-Sensitive Networking (TSN) Task Group</title>
            <author>
            <organization/>
              <organization>IEEE 802.1 Working Group</organization>
            </author>
            <date month="" year=""/>
          </front>
        </reference>

      <?rfc include='reference.I-D.ietf-teas-actn-vn-yang'?>

      <?rfc include='reference.I-D.ietf-teas-ietf-network-slice-nbi-yang'?>

      <?rfc include='reference.I-D.ietf-teas-nrp-scalability'?>

      <?rfc include='reference.I-D.ietf-spring-resource-aware-segments'?>

      <?rfc include='reference.I-D.ietf-spring-sr-for-enhanced-vpn'?>

      <?rfc include='reference.I-D.ietf-6man-enhanced-vpn-vtn-id'?>

      <?rfc include='reference.I-D.ietf-teas-nrp-yang'?>

      <?rfc include='reference.I-D.ietf-spring-srv6-srh-compression'?>

      <?rfc include='reference.RFC.2211'?>

      <?rfc include='reference.RFC.2764'?>

      <?rfc include='reference.RFC.3985'?>

      <?rfc include='reference.RFC.4664'?>

      <?rfc include='reference.RFC.2475'?>

      <?rfc include='reference.RFC.2702'?>

      <?rfc include='reference.RFC.3209'?>

      <?rfc include='reference.RFC.3931'?>

      <?rfc include='reference.RFC.4026'?>

      <?rfc include='reference.RFC.4176'?>

      <?rfc include='reference.RFC.4364'?>

      <?rfc include='reference.RFC.4448'?>

      <?rfc include='reference.RFC.4594'?>

      <?rfc include='reference.RFC.4655'?>

      <?rfc include='reference.RFC.4719'?>

      <?rfc include='reference.RFC.5557'?>

      <?rfc include='reference.RFC.5654'?>

      <?rfc include='reference.RFC.7209'?>

      <?rfc include='reference.RFC.7297'?>

      <?rfc include='reference.RFC.7399'?>

      <?rfc include='reference.RFC.7432'?>

      <?rfc include='reference.RFC.7665'?>

      <?rfc include='reference.RFC.7926'?>

      <?rfc include='reference.RFC.8299'?>

      <?rfc include='reference.RFC.8309'?>

      <?rfc include='reference.RFC.8370'?>

      <?rfc include='reference.RFC.8402'?>

      <?rfc include='reference.RFC.8403'?>

      <?rfc include='reference.RFC.8453'?>

      <?rfc include='reference.RFC.8466'?>

      <?rfc include='reference.RFC.8491'?>

      <?rfc include='reference.RFC.8577'?>

      <?rfc include='reference.RFC.8578'?>

      <?rfc include='reference.RFC.8655'?>

      <?rfc include='reference.RFC.8660'?>

      <?rfc include='reference.RFC.8665'?>

      <?rfc include='reference.RFC.8667'?>

      <?rfc include='reference.RFC.8939'?>

      <?rfc include='reference.RFC.8964'?>

      <?rfc include='reference.RFC.8986'?>

      <?rfc include='reference.RFC.9085'?>

      <?rfc include='reference.RFC.9182'?>

      <?rfc include='reference.RFC.9256'?>

      <?rfc include='reference.RFC.9291'?>

      <?rfc include='reference.RFC.9232'?>

      <?rfc include='reference.RFC.9375'?>

      <?rfc include='reference.RFC.9408'?>

      <?rfc include='reference.RFC.9552'?>

<!-- [I-D.ietf-teas-actn-vn-yang] companion document; RFC 9731-->
<reference anchor="RFC9731" target="https://www.rfc-editor.org/info/rfc9731">
<front>
<title>
A YANG Data Model for Virtual Network (VN) Operations
</title>
<author initials="Y." surname="Lee" fullname="Young Lee" role="editor">
<organization>Samsung Electronics</organization>
</author>
<author initials="D." surname="Dhody" fullname="Dhruv Dhody" role="editor">
<organization>Huawei</organization>
</author>
<author initials="D." surname="Ceccarelli" fullname="Daniele Ceccarelli">
<organization>Cisco</organization>
</author>
<author initials="I." surname="Bryskin" fullname="Igor Bryskin">
<organization>Individual</organization>
</author>
<author initials="B. Y." surname="Yoon" fullname="Bin Yeong Yoon">
<organization>ETRI</organization>
</author>
<date month="January" year="2025"/>
</front>
  <seriesInfo name="RFC" value="9731"/>
  <seriesInfo name="DOI" value="10.17487/RFC9731"/>
</reference>

<!-- [I-D.ietf-teas-ietf-network-slice-nbi-yang] IESG state: I-D Exists as of 09/25/24-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-ietf-network-slice-nbi-yang.xml"/>

<!-- [I-D.ietf-teas-nrp-scalability] IESG state: I-D Exists as of 09/25/24-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-nrp-scalability.xml"/>

<!-- [I-D.ietf-spring-resource-aware-segments] IESG state: I-D Exists as of 09/25/24 -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-spring-resource-aware-segments.xml"/>

<!-- [I-D.ietf-spring-sr-for-enhanced-vpn] Expired Internet Draft  -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-spring-sr-for-enhanced-vpn.xml"/>

<!-- [I-D.ietf-6man-enhanced-vpn-vtn-id] IESG state: I-D Exists as of 09/25/24 -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-6man-enhanced-vpn-vtn-id.xml"/>

<!-- [I-D.ietf-teas-nrp-yang] IESG state: I-D exists as of 9/25/24 -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-nrp-yang.xml"/>

<!-- [I-D.ietf-spring-srv6-srh-compression] IESG state: I-D Exists as of 09/25/24
Used long way to add editor roles.
-->
<reference anchor="I-D.ietf-spring-srv6-srh-compression" target="https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-18">
<front>
<title>Compressed SRv6 Segment List Encoding</title>
<author initials="W." surname="Cheng" fullname="Weiqiang Cheng" role="editor">
<organization>China Mobile</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="Z." surname="Li" fullname="Zhenbin Li">
<organization>Huawei Technologies</organization>
</author>
<author initials="B." surname="Decraene" fullname="Bruno Decraene">
<organization>Orange</organization>
</author>
<author initials="F." surname="Clad" fullname="Francois Clad" role="editor">
<organization>Cisco Systems, Inc.</organization>
</author>
<date month="July" day="22" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-srh-compression-18"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2211.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2764.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3985.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4664.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2702.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4026.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4176.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4448.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4594.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4719.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5557.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5654.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7209.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7297.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7399.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7926.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8370.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8403.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8491.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8577.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8578.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8665.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8667.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9085.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9182.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9291.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9232.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9375.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9408.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"/>
      </references>
    </references>

    <section numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>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>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="default">
      <name>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>

 <!--[rfced] We had the following questions related to abbreviation
      use throughout the document:

a) To follow guidance at
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev, we will
update to expand the following abbreviations on first use only and to
use only the abbreviation thereafter unless we hear objection:

OAM
TE
SR
VN
SAP
DetNet
NRP

Note that we have already made this change with regard to the
following terms:

L2
L3
L2VPN
L3VPN

b) We see two different expansions for OAM in this document:

Operation, Administration, and Management (OAM) vs. Operations,
Administration, and Maintenance (OAM)

We will update to use the latter on the first use in this document and
the abbreviation thereafter per RFC 6291.  Please let us know any
objections.

c) This document expands FlexE as "Flexible Ethernet" while the cited
reference uses "Flex Ethernet".  Should these be made consistent?
Please also review Section 5.1.1 for uses of flexible ethernet if
updates are desired.

d) FYI: We have expanded the following abbreviations on first use as
follows.  Please let us know any corrections.

MP2MP - Multipoint-to-Multipoint
SDN - Software-Defined Networking
P2P - point-to-point
CE - Customer Edge
SRv6 - SR over IPv6

e) We have updated the expansion of ACTN for consistency with the
normative references to appear as follows:

Abstraction and Control of TE Networks (ACTN)
 -->

<!--[rfced] We had the following questions/comments related to
      terminology use throughout the document:

a) We have updated to use lowercase and hyphenated "controlled-load
service" throughout (use in RFC 2211 is mixed).

b) We have used the form on the left to match use in the normative
references.  Please let us know any objections.

telemetry vs. Telemetry

-->

 <!--[rfced] Please note that there a few places throughout the text
      where we inserted bulleted lists to attempt to help the reader
      parse lists or complex sentences.  Please review and let us know
      if any of these updates did not correctly capture your intended
      meaning.-->

 <!--[rfced] This document mixed use of citations as a functioning
      part of a sentence (a noun) and citations as just citations
      (with no syntactic weight).  Where the mixed use might lead the
      reader to confusion (mixed in close proximity,) we have tried to
      edit for consistency.  Where not used in close proximity, we
      have left them as they were to limit changes to the doc.  Please
      see more information on this topic for future documents at
      https://www.rfc-editor.org/styleguide/part2/#citation_usage -->

 <!-- [rfced] Please review the "Inclusive Language" portion of the
      online Style Guide
      <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
      and let us know if any changes are needed.  Updates of this
      nature typically result in more precise language, which is
      helpful for readers.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.

-->

  </back>

  <!---->

</rfc>