Last Call Review of draft-ietf-teas-enhanced-vpn-19
review-ietf-teas-enhanced-vpn-19-tsvart-lc-black-2024-06-04-00

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@ietf.org 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.

[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

[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.

[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.

[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.

[F] 15. Informative References - TSN

What is the [TSN] reference referring to?  Keep in mind that an RFC is an
archive document.

-- 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.