Hi David, Thanks a lot for the review and comments. Please see some replies inline: > -----Original Message----- > From: David Black via Datatracker <noreply@xxxxxxxx> > Sent: Wednesday, June 5, 2024 12:01 AM > To: tsv-art@xxxxxxxx > Cc: draft-ietf-teas-enhanced-vpn.all@xxxxxxxx; last-call@xxxxxxxx; teas@xxxxxxxx > Subject: Tsvart last call review of draft-ietf-teas-enhanced-vpn-19 > > Reviewer: David Black > Review result: Ready with Issues > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this review > as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if > you reply to or forward this review. > > This document describes basing VPNs on Network Resource Partitions (NRPs) > from the IETF Network Slices Framework in RFC 9543 in order to support the > needs of applications with specific traffic performance requirements. Use of > existing mechanisms such as DetNet and Segment Routing is described as > providing means to deliver enhanced VPNs - these techniques have transport > considerations that are appropriate to cover in the documents that specify those > mechanisms, not in this document. As a result, this document is basically OK from > a transport perspective. > > I noticed a few additional minor issues and nits. > > -- Minor Issues > > [A] RFC 9543's notion of Service Demarcation Point is mentioned briefly in the > Introduction and not elsewhere in the document. This document's introduction > of VPNs to the RFC 9543 IETF Network Slices Framework raises questions about > which network is the context for the SDP's "unique identifier (e.g., an IP address > or Media Access Control (MAC) address)" (RFC 9543 section 3.2). I believe an SDP > identifier is always an underly network identifier (as having it be an overlay > network identifier creates a circular dependency for VPN deployment), and a > statement to that effect would be appropriate to add to section 4.1. > > Something also ought to be said about the relationship between SDPs and VPN > end points. I suspect that an SDP may or may not co-located with be a VPN > endpoint and this may depend on the location of the SDP in the network (e.g., > may vary among the four possibilities shown in Figure 1 in Section 5.2 of RFC > 9543). It would be good to point that out, and also in section 4.1 of this > document, explain where in Figure 1 (especially at what layer), SDPs are resident > and/or visible. Finally, the use of "end points" fourth paragraph in Section 5.5 on > management of VPN endpoints appears to implicitly assume that the managed > VPN endpoints are located at SDPs, which may be a limiting assumption. The focus of this document is about enhanced VPNs. As noted late in the Introduction: The techniques for delivering an NRP-based enhanced VPN can be used to instantiate a network slice service, and they can also be of use in general cases to provide enhanced connectivity services between customer sites or service endpoints. Thus the relationship between the VPN end points and SDPs does not belong to the main part of this document. That said, section 6 is about realizing network slices using enhanced VPNs. The relationship between SDPs and enhanced VPNs will be discussed there, and a forward pointer to section 6 will be added to the introduction. Please let us know whether this change is OK to address this issue. > [B] 3.2. Interaction between Enhanced VPN Services > > "There is a fine distinction between how a customer requests limits on interaction > between enhanced VPN services, and how that is delivered by the service > provider." > > I think this concern is broader - it encompasses interactions between an > enhanced VPN service and all other services and traffic on a network, not just > between/among enhanced VPN services. The needed change here also also > affects the title and first paragraph of section 3.2.3 Thanks for catching this issue. This may be a problem with some legacy text after several revisions. We will update the text to clarify it is about the interactions between an enhanced VPN service and all other services (including other enhanced VPNs and other network services) > [C] 5.1. Forwarding Resource Partitioning > > "Several candidate layer-2 packet-based or frame-based forwarding plane > mechanisms which can provide the required traffic isolation and performance > guarantees are described in the following sections." > > Some of those candidates (e.g., DetNet, SR) are layer-3 mechanisms or > mechanisms that are able to be used at layer-3. Rephrase sentence appropriately. Section 5.1 is about the layer-2 packet-based and frame-based forwarding plane, while Detnet and SR are covered in section 5.2 as encapsulation and forwarding mechanisms in the network layer. Thus we see no problem with the current sub-section classification. That said, we could add some text in the beginning of section 5 to make this classification clearer. > [D] 9. Manageability Considerations > > This section should be connected to (e.g., reference) Section 5.5 on Management > Plane, as much of the Section 5.5 material is Manageability Considerations > material wit a strong focus on service provisioning, modification and > decommissioning. Thanks for the suggestion, we will add a reference to section 5.5. > [E] 15. Informative References - RFC 9543 > > While this is intended to be an Informational RFC, I would have expected RFC > 9543 to be a normative reference, as that RFC has to be understood in order to > understand this document. OK, we will make RFC 9543 a normative reference. > [F] 15. Informative References - TSN > > What is the [TSN] reference referring to? Keep in mind that an RFC is an archive > document. The TSN reference refers to the page of TSN task group of IEEE, which gives the overview of TSN standards and projects. We will add some further information about the reference. > -- Nits > > 1. Introduction > > "Customers of a network operator may request connectivity services with > advanced characteristics, such as low latency guarantees, bounded jitter, or > isolation from other services or customers so that changes in some other services > (e.g., changes in network load, or events such as congestion or > outages) have no or only acceptable effect on the observed throughput or > latency of the services delivered to the customer." > > some other services -> other services > have no or acceptable effect -> have no effect or only acceptable effects > > 3.5. Customized Control > > In many cases the customers are delivered with enhanced VPN services without > information about the underlying NRPs. > > Would be better phrased as: > In many cases enhanced VPN services are delivered to customers without > information about the underlying NRPs. > > 4.4. Scalable Service Mapping > > "Solutions must consider minimizing and controlling the scale of such state," > > That phrase needs to be rewritten because "must consider" is entirely too close to > "should consider" - see Section 2 of RFC 6919 and take note of RFC 6919's 1 April > date of publication. > > 5.4. Control Plane > > "The control plane of NRP-based enhanced VPNs would likely be based on a > hybrid control mechanism" > > "would likely" is entirely too close to "would probably" - see RFC 6919 section 5. > > "There are two candidate control plane mechanisms for the setup of paths in the > NRP: RSVP-TE and Segment Routing (SR)." Rephrase as: "Two candidate control > plane mechanisms for path setup in the NRP are:" to avoid any implication that > these are the only two candidates. Thanks a lot for catching all these nits, we will fix them in next revision. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
