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

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

Hi Ketan,

Currently we are working on a new revision of draft-ietf-teas-enhanced-vpn to solve the RTG-DIR review comments received and reflect the discussion we had on the list.

To make this process efficient, we’d appreciate if you could send remaining comments (if any) to the list, so that we could try to incorporate them into the update version. Many thanks.

Best regards,
Jie

From: Teas [mailto:[e-mail]] On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, September 27, 2023 6:27 PM
To: Ketan Talaulikar <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Teas] Rtgdir early review of draft-ietf-teas-enhanced-vpn-14

Hi Ketan,

Thanks for the discussion. Please see further replies inline with [Jie]:

From: Ketan Talaulikar [mailto:[e-mail]]
Sent: Friday, September 22, 2023 8:22 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Rtgdir early review of draft-ietf-teas-enhanced-vpn-14

Hi Jie,

Thanks for your response and sharing the context for this document. Please check inline below for responses.


On Tue, Sep 19, 2023 at 9:25 AM Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>]
> Sent: Friday, September 15, 2023 6:40 PM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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.

KT> OK. So this document is not about VTN. Also, your further comment indicates that we could replace VTN with NRP in this document. If so, that sounds good to me.

[Jie] Good to know we are converging on the scope of this document. Yes in section 6 about network slice applicability, we could replace VTN with NRP when applicable. While the VTN concept is considered generic, and its relationship with NRP is described in the introduction section.




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

KT> My concern is that the terms "VPN+" and "Enhanced VPN" are vague and not really technical terms. At IETF and in the industry at large, we are constantly enhancing and improving things. Would we next come up with terms like VPN++ to describe the next thing? How about we use a technical term - say something like "Guaranteed Resource Services"? I hesitate to use the word VPN since "service" seems like it would cover a wider spectrum of offerings by service providers.

[Jie] I kind of understand your concern about these terms, they were discussed in the past, and the text in the introduction provides definition and explanation of what is called “enhanced VPN”. The reason we use VPN+ for short is that “EVPN” has been used for “Ethernet VPN”.  I notice that there are also other IETF documents in which the technologies are called “enhanced XX”: for example,  draft-ietf-6man-enhanced-dad and draft-ietf-6tisch-enrollment-enhanced-beacon, etc.

The term “Guaranteed resource services” is good, while as described in the introduction and the requirements in section 3, enhanced VPN could be more than “services with guaranteed resources”. VPN Services with latency guarantee or bounded jitter could also be called enhanced VPN service.

To make this clearer, we can add some text to clarify that this document describes a principle for delivering VPN services with enhanced characteristics (such as guaranteed resources, latency, jitter, etc.). This is not a closed list. It is expected that other enhanced features may be added to VPN over time, and it is expected this framework will support these additions with necessary changes or enhancements in some layers. Obviously, individual protocol solutions may need to be enhanced to support the future functions.



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

KT> I will admit that I have not been following this work very closely through all the twists and turns. But then maybe I benefit from that. I have reviewed the final product from the WG though - i.e. draft-ietf-teas-ietf-network-slices. Isn't it required to clarify the scope and goals of this document considering the present day status when sending it to the IESG?

[Jie] Yes after several rounds of discussion about the relationship between VPN+ and network slicing, I believe the scope and goal of this document is reflected in the introduction section.  Maybe what you want is some further clarification about the relationship with network slices, right? If so, we can add some text about that.


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.

KT> Could you please point me to text in either this or another document that describes the contrast and overlap between this document and the IETF Network slicing framework? Ideal thing would be to avoid overlap and disambiguate the two frameworks.

[Jie] To me the latest version of IETF network slice framework and VPN+ framework are complementary to each other. The former document describes the concept and a general framework of IETF network slices, and the latter is on the layered architecture and realization technologies for delivering VPN+ services.  The VPN+ framework and the component technologies can be used to deliver IETF network slice services, and this reflected in section 7 “Realizing IETF Network Slices” of IETF network slice framework.


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

KT> Yes, I believe it would help bring clarity if the term NRP were used in this document instead of VTN if those constructs are indeed synonymous.

[Jie] As mentioned in the draft, VTN is a generic concept introduced in the VPN+ framework, and it can be used for delivering VPN+ services (including network slice services). In the context of network slicing, VTN can be instantiated as NRPs.


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

KT> There is already a framework for IETF Network Slicing that is soon going to get published as an RFC. Would it not help to focus only on the non-slicing use-case/framework in this document? The Network Slicing framework is done - does the WG intend to propose two frameworks for the same problem statement?

[Jie] As mentioned above, these two frameworks are complementary as they are focusing on different levels. One is about the high level network slice framework without touching the realization technologies, the other one is about the realization technologies and how they are put together.



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

KT> I am not really there as yet - but I think I am getting there. Thanks for your patience. More importantly, our goals should be that clarity should ultimately emerge in the document for the benefit of any new reader.

[Jie] Good to know we are making progress. We can add some further clarification about the relationship between IETF network slice and VPN+ to help the readers.



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?

KT> Indeed the topic is covered in draft-ietf-teas-nrp-scalability and I agree with you that it may be best to discuss it in that document rather than here given your explanations above.

[Jie] This is good, thanks.



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

Thanks. Looking forward to continuing this discussion.
Ketan

[Jie] Please let me know if the above replies solve your remaining concerns. Thanks.

Best regards,
Jie



Best regards,
Jie


>
> Thanks,
> Ketan
>
>
>