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

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

Hi Ketan, 

Thanks for the review and discussion. It is good that we are aligned on the context and scope of this document. 

Best regards,
Jie

> -----Original Message-----
> From: Ketan Talaulikar <[e-mail]>
> Sent: Wednesday, November 8, 2023 3:38 PM
> To: Dongjie (Jimmy) <jie.dong=[e-mail]>
> Cc: Lou Berger <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [Teas] Rtgdir early review of draft-ietf-teas-enhanced-vpn-14
> 
> Hello All,
> 
> Thanks for your patience on this review. It was difficult for me to get the full
> context and history of this document. It helped a lot that Jie and I could meet
> face to face here in Prague.
> 
> However, note that my review has been more from a "here and now"
> perspective since it is very likely that the IESG views it similarly.
> Therefore, some of the questions raised may seem odd to WG members who
> have been working for several years on this document.
> 
> Thanks,
> Ketan
> 
> 
> On Sat, Nov 4, 2023 at 5:10 PM Dongjie (Jimmy) <jie.dong=
> [e-mail]> wrote:
> 
> > Hi Lou,
> >
> >
> >
> > Thanks for the suggestion, I will send a mail summarizing the updates
> > of the new version.
> >
> >
> >
> > Best regards,
> >
> > Jie
> >
> >
> >
> > *From:* Lou Berger <[e-mail]>
> > *Sent:* Saturday, November 4, 2023 12:05 AM
> > *To:* Dongjie (Jimmy) <[e-mail]>
> > *Cc:* [e-mail]; [e-mail];
> > [e-mail]; Ketan Talaulikar <[e-mail]>
> > *Subject:* Re: Rtgdir early review of draft-ietf-teas-enhanced-vpn-14
> >
> >
> >
> > 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] <[e-mail]>]
> > *On Behalf Of *Dongjie (Jimmy)
> > *Sent:* Wednesday, September 27, 2023 6:27 PM
> > *To:* Ketan Talaulikar <[e-mail]> <[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]
> > <[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
> > KT> 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
> > KT> 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
> > VPN+ 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
> > KT> used
> > in this document instead of VTN if those constructs are indeed
> > synonymous