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

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

Hi Ketan, 

Thanks for the review and comments to help improve this work.

Please see some replies to your high level comments inline. Some background and history about this work are provided to help the understanding and discussion. 

> -----Original Message-----
> From: Ketan Talaulikar via Datatracker [mailto:[e-mail]]
> Sent: Friday, September 15, 2023 6:40 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Rtgdir early review of draft-ietf-teas-enhanced-vpn-14
> 
> 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.

Item c) is not quite accurate. This document mainly describes the architecture and candidate technologies which can be used to realize VPN+ services. VTN is just one of the constructs of this architecture.


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

As described in the introduction, VPN+ refers to a VPN service which can provide not only connectivity but also guaranteed resource and assured/predictable performance. In section 5, RSVP-TE is not excluded from the candidate realization technologies, while as analyzed in section 5.2 and 5.4, RSVP-TE tunnels were not widely used for guaranteed bandwidth for specific VPN services, due to scalability concerns. Thus we would say the convention VPN services are provided mainly for connectivity, the resources are not guaranteed since they are usually shared with many other VPN or non-VPN service in the same network. 


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

If you followed the network slicing discussion in IETF and TEAS WG since 2017, I believe you would not make the judgement that "VPN+" is a marketing term. It was introduced at that time when almost all IETF people said "network slicing is vague and broad", in IETF we need to call it something which can be understood by IETF people, and the work needs to reflect its relationship with existing IETF technologies". "VPN+" was the best term we could find at that time, and it seems people accepted it in IETF since its adoption in TEAS. 

In marketing places, we would use the term "network slice" directly.


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

While VTN is one important construct in the realization of VPN+ services. this is a framework for VPN+ service, it is more than just VTN.


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

This document has some text about the provisioning and management of VPN+ services, and it refers to documents in the OPS area and TEAS WG for the detailed management mechanisms and models. I believe this aligns with the approach you proposed.

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

This is about the history of the two documents (VPN+ framework and IETF network slice framework). 

If my memory is correct, VPN+ framework was the first network slicing related document in TEAS. When the Network Slice Design Team (NSDT) was formed in 2020, the work on network slice framework was initiated, the authors of the VPN+ framework proposed to reuse text of this document for the network slice framework, this seems reasonable as both document are on the same/similar topic. As you mentioned that was reflected in the acknowledgement in the network slice framework. 

As the network slice framework document evolves, we have been working on aligning the concepts and terms between the two documents, and some descriptions become different but still look similar. While since the scope of the VPN+ framework is not fully overlapped with the network slice framework, those texts are considered needed in 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.

Our intention with section 6 was to show how VPN+ framework and candidate technologies can be used to deliver network slice service in the context of network slicing. That said, the authors does not have a strong opinion on which terms are better to use in section 6. Currently VTN is used in the whole VPN+ document, and its relationship with NRP is also described. If the WG think NRP should be used in section 6, we are OK with that.


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

My thought is the WG has reached consensus on this: VPN+/VTN is generic, it can be used for realizing IETF network slices, and they can also be used for other scenarios (assume that we would not call all those services "slice").


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

With the above background information and explanation, hope you have better understanding about the relationship between VPN+/VTN and network slicing.

The applicability of VPN+ for IETF network slicing is briefly described in the IETF Network Slicing framework in one section. The details are in this document.


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

You are right that the data plane VTN-ID is not explicitly discussed in this document, this is because there is another document draft-ietf-teas-nrp-scalability which is focusing on the scalability considerations of NRP, and whether to use new ID or existing identifiers was fully discussed there. My suggestion is we may add some brief description about the new data plane ID mechanism in this framework document, and refer to the nrp-scalability draft for details. What do you think?


> 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 again for your high-level comments, and hope my reply can help to better understand this work and the relationship with other network slicing work. 

Best regards,
Jie


> 
> Thanks,
> Ketan
> 
> 
>