Skip to main content

Early Review of draft-ietf-teas-enhanced-vpn-15

Request Review of draft-ietf-teas-enhanced-vpn-11
Requested revision 11 (document currently at 17)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2023-09-10
Requested 2023-01-23
Requested by Lou Berger
Authors Jie Dong , Stewart Bryant , Zhenqiang Li , Takuya Miyasaka , Young Lee
I-D last updated 2023-11-08
Completed reviews Rtgdir Early review of -15 by Ketan Talaulikar (diff)
Document just gone through WG last call - expect some changes, please look at discussion on list and expected resolution from authors to be discussed on list.
Assignment Reviewer Ketan Talaulikar
State Completed
Request Early review on draft-ietf-teas-enhanced-vpn by Routing Area Directorate Assigned
Posted at
Reviewed revision 15 (document currently at 17)
Result Has issues
Completed 2023-11-08
This document is almost ready, but has some issues that need discussion within the

Summary of the document:

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

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 

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.