[RTG-DIR] Rtgdir early review of draft-ietf-teas-enhanced-vpn-14

[Ketan Talaulikar via Datatracker <[e-mail]>]

Reviewer: Ketan Talaulikar
Review result: Not Ready

I believe that the document is not ready and needs further work. I have some
major concerns that I am sharing below that I would like to bring to the
attention of the authors and the WG.

Summary of the document (please correct my understanding):

a) Introduces a notion of VPN+ that seems to describe some (so-called)
enhancements over (so-called) "conventional" VPN services. It goes on to
describe why these VPN+ services are special and different and what they could
provide and how they are provisioned/managed that are different from what
already exists.

b) Introduces a VTN construct for identifying (?) a subset of the underlay
network topology with some awareness of resources associated with it that are
derived from the underlying physical network. A VPN+ service is built on top of
this VTN construct.

c) Discusses the realization of the VTN constructs using existing technologies
and how it can be managed and operated. Also, how it can deliver as an NRP
solution in the IETF Network Slicing framework.

Major Issues:

1) Use of “VPN+” & “Enhanced VPN” terminologies

When the document creates this notion of VPN+, it is implying that this is
something new and something that can be realized using what is in the document.
That is at best misleading.

A service provider called X could have provided a P2P PW L2VPN service some 10+
years ago over an RSVP-TE tunnel that provides guaranteed bandwidth,
protection, avoidance, some level of isolation and works around network
failures. Would that be considered as a VPN+ service?

My point is that the VPN+ (and enhanced VPN) sound more like marketing terms to
me and do not reflect how operators have deployed and are deploying "enhanced"
VPNs for their customers. It seems futile and misleading for the IETF to try to
define what is "enhanced" and what is "conventional" VPN services.

I believe the document should focus on VTN (which to me seems like a TE
construct?) and how *any* VPN service can be delivered on top of it to provide
the benefits that VTN has to offer.

If the authors believe they have advice to offer to operators on the
provisioning and management of VPN services, perhaps it should be a separate
draft in the OPS area?

2) Relation to IETF Network Slices document

The draft-ietf-teas-ietf-network-slices (now with the IESG) that the WG has
sent for publication has a lot of content that is repeated in sometimes
different words and phrases in this document. The authors should consider
citing the relevant sections of that document instead of repeating. I
understand that this might have happened over the course of time and the IETF
network slicing document does acknowledge text drawn from this document.

The document says that VTN is one way to deliver NRP. If so, VTN would fit with
the IETF Network Slicing framework and the content in Section 6 should be then
using the terminologies of that document.

But then the document says that VTN can be also used outside the context of
IETF Network Slicing.

Suggestion: Focus on the description of the VTN construct by itself
independently. Then cover its applicability in the IETF Network Slicing
framework in one section and the applicability independently (as an underlay
for any VPN service) in another section.

3) Identification of VTN

There are multiple documents out in other routing WGs (some adopted, some
individual) and in 6man WG that talk about a VTN-ID. This document which is
used as the reference for VTN in all those places is conspicuously silent on
the aspect of an VTN-ID - i.e., Do we need a new ID or can we use existing
identifiers based on the underlying transport/underlay technologies used?

I am sharing these uber-level comments first so we can have a discussion and
converge. The detailed review will follow once were are past these issues.

Thanks,
Ketan