Hi David, Thanks for your prompt response, please see further replies inline: > -----Original Message----- > From: Black, David <David.Black@xxxxxxxx> > Sent: Tuesday, June 11, 2024 9:28 PM > To: Dongjie (Jimmy) <jie.dong@xxxxxxxxxx>; tsv-art@xxxxxxxx > Cc: draft-ietf-teas-enhanced-vpn.all@xxxxxxxx; last-call@xxxxxxxx; teas@xxxxxxxx; > Black, David <David.Black@xxxxxxxx> > Subject: RE: Tsvart last call review of draft-ietf-teas-enhanced-vpn-19 > > Hi Dongjie, > > Thanks for the responses and forthcoming updates. The proposed resolutions > for everything except item [C] are fine with me. > > >> [C] 5.1. Forwarding Resource Partitioning > > > 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. > > I agree - a sentence in section 5 indicating that layer-2 mechanisms are discussed > in section 5.1 and layer-3 mechanisms are discussed in section 5.2 would > definitely help. OK, will add brief description about the content of each subsection in the beginning of section 5. > > Please also consider changing the section titles of sections 5.1 and 5.2 to better > indicate their complementary relationship (I'll leave what changes, if any, to make > to the section titles up to the authors to decide). Thanks for the suggestion, you're right the technologies in 5.1 and 5.2 are complementary. We will consider how to better reflect this in the section titles. Best regards, Jie > Thanks, --David > > -----Original Message----- > From: Dongjie (Jimmy) <jie.dong@xxxxxxxxxx> > Sent: Tuesday, June 11, 2024 3:41 AM > To: Black, David <David.Black@xxxxxxxx>; tsv-art@xxxxxxxx > Cc: draft-ietf-teas-enhanced-vpn.all@xxxxxxxx; last-call@xxxxxxxx; teas@xxxxxxxx > Subject: RE: Tsvart last call review of draft-ietf-teas-enhanced-vpn-19 > > > [EXTERNAL EMAIL] > > 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
