Early Review of draft-ietf-teas-enhanced-vpn-15
review-ietf-teas-enhanced-vpn-14-rtgdir-early-talaulikar-2023-09-15-01

This document is almost ready, but has some issues that need discussion within the
WG.


Summary of the document:

a) Introduces a framework for "enhanced" VPN services that provide certain
characteristics (also described in the document) beyond "conventional" VPN
services.

b) The main goal of this framework is for service providers that are not
deploying network slicing but want to provide these "enhanced" VPN services to
their customers. This framework may also be used to realize a network slice as
described in the IETF Network Slicing Framework 
(draft-ietf-teas-ietf-network-slices).


Major Issuess:

- VTN and NRP seem to be functionally equivalent. That NRP is used in the
context of Network Slicing and VTN in Enhanced VPN is not a good enough reason
to coin two terminolgies. IMO the WG needs to try and converge on a single
term if possible because there are several drafts across RTG and INT area that
 are introducing this concept into protocol encoding and technology 
architectures. To me, NRP seems a better and more technical term and there is
the draft-ietf-teas-nrp-scalability WG document for NRP scalability with 
common authors with this document.

- The document is not clear whether the VTN/NRP construct is needed to be
introduced in routing protocols (e.g., to identify sub-set of topologies)
and if so, the reasons for it. Or is it simply more of a forwarding plane 
construct (e.g., to mark packet for a specific VTN/NRP)? Some clear text 
would help.

- In my previous review, I've highlighted that the term "Enhanced VPN" is
misleading, but I am not able to come up with a better terminolgy - so be it.
However, at least the authors can avoid the use of "VPN+" and instead use the
expanded form or perhaps "enh-VPN"?


Minor Issues & Nits:

- IDnits points to unused references.

- A run by a spelling and grammar check tool will help the authors find and
  fix issues.

- There are few references to "network slice" in the document apart from Sec
  6. Suggest to move them all into Sec 6 and perhaps move Sec 6 at the end of
this document so the focus of this document becomes the "enhanced VPN"
framework and use for non-network slice use cases.