Hi Megan, Sorry for the late response. It was Chinese New Year holiday and I missed this mail in my mail box.
Please find my replies inline: > -----Original Message----- > From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > Sent: Saturday, February 8, 2025 8:58 AM > To: Dongjie (Jimmy) <jie.d...@huawei.com>; ta-miyas...@kddi.com; > lizhenqi...@chinamobile.com; stewart.bry...@gmail.com; > younglee...@gmail.com > Cc: teas-...@ietf.org; teas-cha...@ietf.org; Lou Berger <lber...@labn.net>; > James Guichard <james.n.guich...@futurewei.com>; > auth48archive@rfc-editor.org; RFC Editor <rfc-edi...@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9732 <draft-ietf-teas-enhanced-vpn-20> for > your review > > Authors, > > Just a friendly reminder that this document awaits your attention. Please > review our messages below and let us know if you have any questions while > you complete your AUTH48 review. > > We look forward to hearing from you at your earliest convenience. > > Thank you. > > RFC Editor/mf > > > > On Jan 27, 2025, at 10:39 PM, rfc-edi...@rfc-editor.org wrote: > > > > 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)... > > --> Thanks for proposing all these options. I would prefer the last one: A Framework for NRP-Based Enhanced Virtual Private Networks, with the suggested update to the abstract. > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > the title) for use on https://www.rfc-editor.org/search. --> The keywords can be: network slicing, traffic engineering, performance guarantee > > > > > > 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. > > --> The first sentence is talking about the customers' requirements to network, while the second sentence is about the characteristics of the enhanced VPN service. They are similar while from different angles. I would prefer to keep them as is. > > > > 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]. Although it is well known that RFC 4364 is about L3VPN, I agree L3VPN or layer-3 is not used explicitly in that document. It uses IP VPN instead. In this draft we can follow that way and replace L3VPN with IP VPN. > > --> > > > > > > 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. > > --> The above update looks good. Thanks. > > > > > > 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). > > > > --> How about: This may introduce scalability concerns in the implementation, as each enhanced VPN may need to be tracked in the network. It may also introduce scalability concerns in deployment, such as how many resources need to be reserved and how the services are mapped to the resources (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. > > --> The update looks good, thanks. > > > > > > 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... > > The rewording looks good to me. > > --> > > > > > > 9) <!--[rfced] Does the following rewording correctly capture your > > intent? > > > > Original: > > With the approach of abstraction,... > > > > Perhaps: > > Using the abstraction approach... This is OK. > > --> > > > > > > 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. > > --> It is OK to remove "service" as it is already covered by the "S". > > > > > > 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. > > --> How about: s/the operation requests/the requests for specific operations > > > > > > 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. > > --> Actually the last sentence "so as to meet the requirements... " is related to both bullets. Maybe split it as a separate bullet? > > > > > > 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. --> Yes, the updated text looks good. > > > > > > 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. > > Yes, the meaning is retained. > > --> > > > > > > 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. Yes, it is correct. > > --> > > > > > > 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. > > This update is OK. > > --> > > > > > > 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. The first sentence is general and not specifically related to GCO. As described in the second sentence, GCO can be of help in this case, while it is not mandatory. I’d suggest to keep both sentences as is. > > --> > > > > > > 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. > > Suggest to rephrase it as: Thus, the coordination of 5G end-to-end network slice management requires an interface between the enhanced VPN management plane and the 5G network slice management system, and relevant service data models. > > --> > > > > > > 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. Here "it" means "enhanced VPN". Suggest to rephrase it as: Reducing the state in the network is important to the deployment of enhanced VPNs, as they require the overlay to be more closely integrated with the underlay than with conventional VPNs. > > --> > > > > > > 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.--> How about rephrase it as: The centralized SDN based approach requires... > > > > > > 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: The updates look good, thanks. > > > > --> > > > > > > 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_NG > MN_ > > 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). --> Thanks, the link you provided point to the right document, it seems the previous link expired. > > > > > > 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 Agree with this usage, thanks. > > > > 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. Yes the latter is the right one. Please make this change, thanks. > > > > 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. Let's make it consistent with the reference (Flex Ethernet), although as I know Flexible Ethernet is extensively used in many documents in the industry. > > > > 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 For SRv6, please use "Segment Routing over IPv6", all the rest look good. > > > > 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) It looks good. > > --> > > > > > > 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 Both look good. > > --> > > > > > > 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.--> All the updates look good, thanks. > > > > > > 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 --> Thanks for the editing! > > > > 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. > > Thanks for the pointer, I have checked the text and nothing needs to be changed. Best regards, Jie > > --> > > > > > > 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-4Q9l2USxI > > Ae6P8O4Zc > > > > * 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
