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

[Lou Berger <[e-mail]>]

Jie

Can you summarize how the new version addresses comments made as part of 
all reviews and list any outstanding issues from the author's perspective?

Thanks,

Lou

On 10/16/2023 5:23 AM, Dongjie (Jimmy) wrote:
>
> 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] 
> <mailto:[e-mail]>]
> *Sent:* Friday, September 22, 2023 8:22 PM
> *To:* Dongjie (Jimmy) <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; 
> [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]> 
> 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]]
>     > 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.
>
> 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
>     >
>     >
>     >
>