Re: [Teas] Rtgdir early review of draft-ietf-teas-enhanced-vpn-15

["Dongjie (Jimmy)" <[e-mail]>]

Hi Ketan, 

Thanks for the updated RTG-DIR review comments. 

Please see some replies inline:


> -----Original Message-----
> From: Ketan Talaulikar <[e-mail]>
> Sent: Wednesday, November 8, 2023 3:51 PM
> To: Ketan Talaulikar <[e-mail]>;
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: [Teas] Rtgdir early review of draft-ietf-teas-enhanced-vpn-15
> 
> For some reason, the tool hasn't pushed out my review of v15
> 
> It is available here:
> https://datatracker.ietf.org/doc/review-ietf-teas-enhanced-vpn-14-rtgdir-early-t
> alaulikar-2023-09-15/
> 
> Also reproducing below:
> 
> 
> 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 Issues:
> 
> - 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 terminologies. 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.

This was discussed at the time when the term NRP is introduced, though I don't remember the WG has reached any consensus on this. 

My personal opinion is VTN would be more generic to cover both network resources and other functionalities which could be introduced to a virtual underlay network later. 

That said, the authors are open to any decision made by the WG on this, and can update the document accordingly.


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

Actually this depends on the target network scenarios, the required scale and the specific solutions used for realizing VTNs/NRPs. We can add some brief text about this, and leave the details to the solution documents. 


> - 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 terminology - so be
> it.
> However, at least the authors can avoid the use of "VPN+" and instead use the
> expanded form or perhaps "enh-VPN"?

It is OK to replace "VPN+" with "enhanced VPN" in the document, just the sentences would become a little bit longer. 


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

We will do the nits, spelling & grammar check again to -15 version of the document. 


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

As described in the introduction, the framework of enhanced VPN can be applied to both network slice and non-network slice use cases. 

While I understand your point of not emphasizing the network slice use cases. We will go through the draft and keep network slice mentioned only in the introduction (section 1) and the applicability section (section 6). 

Best regards,
Jie

> 
> Thanks,
> Ketan
> 
> 
> On Fri, Sep 15, 2023 at 12:39 PM Ketan Talaulikar via Datatracker <
> [e-mail]> wrote:
> 
> > 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