Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [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
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)...
-->
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
3) <!--[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.
-->
4) <!-- [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].
-->
5) <!--[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.
-->
6) <!--[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).
-->
7) <!--[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.
-->
8) <!--[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...
-->
9) <!--[rfced] Does the following rewording correctly capture your
intent?
Original:
With the approach of abstraction,...
Perhaps:
Using the abstraction approach...
-->
10) <!--[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.
-->
11) <!--[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.
-->
12) <!--[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.
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.
-->
13) <!--[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. -->
14) <!--[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.
-->
15) <!--[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.
-->
16) <!--[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.
-->
17) <!--[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.
-->
18) <!--[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.
-->
19) <!--[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.
-->
20) <!--[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.-->
21) <!--[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:
-->
22) <!-- [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_Sl
icing_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). -->
23) <!--[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)
-->
24) <!--[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
-->
25) <!--[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.-->
26) <!--[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 -->
27) <!-- [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.
-->
Thank you.
RFC Editor/mf
*****IMPORTANT*****
Updated 2025/01/27
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9732.xml
https://www.rfc-editor.org/authors/rfc9732.html
https://www.rfc-editor.org/authors/rfc9732.pdf
https://www.rfc-editor.org/authors/rfc9732.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9732-diff.html
https://www.rfc-editor.org/authors/rfc9732-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9732-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9732
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9732 (draft-ietf-teas-enhanced-vpn-20)
Title : A Framework for Network Resource Partition (NRP) based
Enhanced Virtual Private Networks
Author(s) : J. Dong, S. Bryant, Z. Li, T. Miyasaka, Y. Lee
WG Chair(s) : Oscar Gonzalez de Dios, Vishnu Pavan Beeram, Lou Berger
Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
