Dear Editor Madison, Thank you for your careful work! I approve the document in its current form with the following suggestions.
Introduction Current: 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 [RFC4026]. In the underlay network, the NRP is used to represent a subset of the network resources and associated policies in the underlay network. An NRP can be associated with a dedicated or shared network topology to select or specify the set of links and nodes involved.Suggestion: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 [RFC4026]. In the underlay network, the NRP is used to represent a subset of the network resources and associated policies in the underlay network. Reason: We do not need to repeat the following sentence here since it is stated in the the end of the previous two paragraph. An NRP can be associated with a dedicated or shared network topology to select or specify the set of links and nodes involved. 3.1. Performance GuaranteesCurrent: 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.Suggestion: Time transfer is an example service that needs this performance guarantee, although it is in the nature of time that the service might be delivered by the underlay as a shared service and not provided through different enhanced VPNs. 3.2.1. Requirements on Traffic IsolationCurrent:An enhanced VPN service customer may request traffic isolation together with other operator-defined service characteristics. The exact details about the expected behavior need to be specified in the service request so that meaningful service assurance and fulfillment feedback can be exposed to the customers.Suggestion:An enhanced VPN service customer may request traffic isolation together with other operator-defined service characteristics. The exact details about the expected behavior need to be specified in the service request so that meaningful service assurance and fulfillment feedback can be exposed to the customer. Best Regards, Zhenqiang Li 13911635816 lizhenqi...@chinamobile.com From: Madison Church Date: 2025-02-12 00:38 To: Dongjie (Jimmy); ta-miyas...@kddi.com; lizhenqi...@chinamobile.com; younglee...@gmail.com; stewart.bry...@gmail.com CC: Megan Ferguson; teas-...@ietf.org; teas-cha...@ietf.org; Lou Berger; James Guichard; auth48archive@rfc-editor.org; RFC Editor Subject: Re: AUTH48: RFC-to-be 9732 <draft-ietf-teas-enhanced-vpn-20> for your review Hi Authors, Jie - Thank you for your quick reply! We have updated the document as requested and your approval has been noted on the AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9732). All of our questions have been addressed. All - Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9732.txt https://www.rfc-editor.org/authors/rfc9732.pdf https://www.rfc-editor.org/authors/rfc9732.html https://www.rfc-editor.org/authors/rfc9732.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9732-diff.html https://www.rfc-editor.org/authors/rfc9732-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9732-auth48diff.html https://www.rfc-editor.org/authors/rfc9732-auth48rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9732 Thank you! RFC Editor/mc > On Feb 11, 2025, at 12:11 AM, Dongjie (Jimmy) <jie.d...@huawei.com> wrote: > > Hi, > > Thanks for the update, please see replies to the remaining questions inline: > >> -----Original Message----- >> From: Madison Church <mchu...@staff.rfc-editor.org> >> Sent: Tuesday, February 11, 2025 6:58 AM >> To: Dongjie (Jimmy) <jie.d...@huawei.com>; ta-miyas...@kddi.com; >> lizhenqi...@chinamobile.com; younglee...@gmail.com; >> stewart.bry...@gmail.com >> Cc: Megan Ferguson <mfergu...@staff.rfc-editor.org>; 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 >> >> Hi Jie and Stewart, >> >> Thank you for your replies. We have updated the document according to >> Jie’s response and have a few followup questions/comments. >> >>>>> 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. >> >> 1) Note that we have updated the citation tag for RFC 4364 to appear after >> "IPVPN [RFC2764]". Additionally, should "IPVPN" have a space between "IP" >> and "VPN" based on its use RFCs 2764 and 4364? >> >> Current: >> Examples of technologies to provide VPN services are as follows: IPVPN >> [RFC2764] [RFC4364], L2VPN [RFC4664], and EVPN [RFC7432]. >> >> Perhaps: >> Examples of technologies to provide VPN services are as follows: IP VPN >> [RFC2764] [RFC4364], L2VPN [RFC4664], and EVPN [RFC7432]. > > It is better to align with RFC 2764 and 4364, using IP VPN instead of IPVPN. > > >>>>> >>>>> 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? >> >> 2) Thank you for your suggestion! We have updated the text as follows. >> Please let us know if any additional changes are needed. >> >> 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, >> >> * can be associated with a customized logical network topology, and >> >> * meets the requirements of different enhanced VPN services or >> different groups of enhanced VPN services. > > This update looks good. I just have one small suggestion for your > consideration: > > Since it is talking about "each NRP", in the last bullet maybe it is better > to replace "different enhanced VPN services" with "a specific enhanced VPN > service", and replace "different groups of enhanced VPN services" with "a > specific group of enhanced VPN services"? > > With these updates, I approve the publication of this document. > > Thanks for all the help! > > Best regards, > Jie > >> >> The updated files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9732.txt >> https://www.rfc-editor.org/authors/rfc9732.pdf >> https://www.rfc-editor.org/authors/rfc9732.html >> https://www.rfc-editor.org/authors/rfc9732.xml >> >> The diff files have been posted here: >> https://www.rfc-editor.org/authors/rfc9732-diff.html (comprehensive >> diff) >> https://www.rfc-editor.org/authors/rfc9732-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9732-auth48diff.html (AUTH48 >> updates only) >> https://www.rfc-editor.org/authors/rfc9732-auth48rfcdiff.html (side by >> side) >> >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9732 >> >> Thank you, >> RFC Editor/mc
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
