Early Review of draft-ietf-teas-enhanced-vpn-15
|11 (document currently at 17)
|Routing Area Directorate (rtgdir)
|Jie Dong , Stewart Bryant , Zhenqiang Li , Takuya Miyasaka , Young Lee
|I-D last updated
Rtgdir Early review of -15
by Ketan Talaulikar
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.
|Early review on draft-ietf-teas-enhanced-vpn by Routing Area Directorate Assigned
|15 (document currently at 17)
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.