Hi Dhruv, Thanks a lot for the careful review and comments. We will produce an update version to address these comments and nits. And please see some replies inline: > -----Original Message----- > From: Dhruv Dhody via Datatracker [mailto:noreply@xxxxxxxx] > Sent: Tuesday, May 21, 2024 12:55 PM > To: ops-dir@xxxxxxxx > Cc: draft-ietf-teas-enhanced-vpn.all@xxxxxxxx; last-call@xxxxxxxx; teas@xxxxxxxx > Subject: Opsdir last call review of draft-ietf-teas-enhanced-vpn-18 > > Reviewer: Dhruv Dhody > Review result: Has Issues > > # OPSDIR review of draft-ietf-teas-enhanced-vpn-18 > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects of > the IETF drafts. Comments that are not addressed in the last call may be > included in AD reviews during the IESG review. Document editors and WG > chairs should treat these comments just like any other last-call comments. > > The document describes the NRP-based Enhanced VPNs framework. The > document is almost ready for publication. Note that I had reviewed an earlier > version during WGLC. > > The document includes manageability considerations and Operational > considerations sections that provide useful hints. Thanks for including these > explicit sections. Some comments: > > - Section 8.1, is there any NRP-specific OAM text that should be explicitly > listed? One requirement on NRP-specific OAM is that the OAM packets follow the same path and the set of resources as the data packets of the NRP, so that the result can correctly reflect the status of the NRP. We can add some text about this to section 8.1. > - Section 8.2, I was hoping for some explicit text on the role of telemetry here > as as well some high-level consideration even if the bulk of the mechanism is > out of scope. We will add some text about the role of telemetry to the management of NRP and enhanced VPN service. > - In section 10, you should reference back to section 5.6 here. Further are there > any lifecycle concerns that should be highlighted that are specific to enhanced > VPN? OK, we will add the reference to section 5.6. Currently we don't see any concern about the lifecycle management of enhanced VPN. > - I suggest moving current section 9 (Enhanced Resiliency) above section 8 > (Manageability Considerations) to keep Manageability Considerations and > Operational Considerations back to back. Good suggestion. We can change the order of section 8 and section 9 to help the readability. > ## Minor > > - "...enhancements in some network layers and network planes."; 'Network > planes' is unclear, I suggest adding "(data plane, control plane, and > management plane)" alongside if that is what the authors mean... Yes and we will make the change as you suggested. > > - In section 2, NRP is listed twice in the initial relationship list as well as in the > abbreviation list. OK, will clean up the duplication. > > - Section 4, Should OAM and telemetry be listed under the management plane? The purpose was to separate them from the function of management interface. But they can also be listed under the management plane with some text rephrase. > - Section 5.2.3, should there be a reference to > draft-ietf-spring-resource-aware-segments? Yes, we can add a reference to that document. > > - Change reference to RFC 7752 to RFC 9552 OK, will update this reference. > > - Section 7.3, the sentence "The centralized approach of SDN requires state to > be stored in the network, but does not have the overhead of also requiring > control plane state to be maintained" gives an impression that there is no > control plane state if SDN is used which is not true. Further "...with the need > for a control plane to maintain communication with all neighbors" is also > unclear, which communication channel? How about making the following changes: "The centralized approach of SDN requires state to be stored in the network, but can reduce the overhead of control plane state to be maintained. The text about communication channel is to compare the SDN based approach with the distributed control plane based approach in terms of the number of control plane connections needed. How about making the following changes: "Each individual network node may need to maintain a control channel with an SDN controller, which is considered more scalable comparing to the need of maintaining control channels with all neighbors" > > ## Nits > > - Expand NRP in the title and abstract. > > - Expand on first use - PE, > > - s/technologies and adds characteristics/technologies and add characteristics/ > > - s/but in addition they also/but in addition, they also/ > > - I suggest rephrasing "This is not a closed list." to "This list is not exhaustive." > > - s/the general framework, the components, and interfaces/the general > framework, components, and interfaces/ > > - s/service is deployment specific./service is deployment-specific./ > > - s/one or more NRP-based enhanced VPN/one or more NRP-based enhanced > VPNs/ > > - s/not in scope for this document./not in the scope of this document./ > > - s/queues size, and discard policy/queue sizes, and discard policies/ > > - s/augumented/augmented/ > > - s/through different enhanced VPN./through different enhanced VPNs./ > > - s/a spectrum of service guarantees need to be/a spectrum of service > guarantees needs to be/ > > - s/some service may have/some services may have/ > > - s/latency in network layer/latency in the network layer/ > > - s/requirements on separating/requirements for separating/ > > - s/expectations on traffic isolation./expectations of traffic isolation./ > > - s/provide the traffic isolation/provide traffic isolation/ > > - s/In some domains the network/In some domains, the network/ > > - s/IP based/IP-based/ > > - s/a link level technology/a link-level technology/ > > - s/DiffServ based queuing systems/DiffServ-based queuing systems/ > > - s/time sensitive/time-sensitive/ > > - s/such group of services./such a group of services./ > > - s/resource reserved paths/resource-reserved paths/ > > - s/performance related parameters/performance-related parameters/ > > - s/SDN based/SDN-based/ > > - s/And on the network nodes and links/On the network nodes and links/ > > - s/instructed to allocated the/instructed to allocate the/ > > - s/NRP specific/NRP-specific/ > > - s/of an network slice service/of a network slice service/ > > - s/together provide a network slice service./together provides a network slice > service./ > > - s/based either the traffic-engineered paths/based on either the > traffic-engineered paths/ > > - s/performance guaranteed services/performance-guaranteed services/ > > - s/NRP specific segments/NRP-specific segments/ > > - s/resource allocated path/resource-allocated path/ > > - s/performance sensitive application/performance-sensitive application/ Thanks a lot for catching all these nits. We will fix them in next revision. Best regards, Jie > > Thanks, > Dhruv > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
