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

[Ketan Talaulikar <[e-mail]>]

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

- 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 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"?


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.


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.
>
> Thanks,
> Ketan
>
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>