Re: [Teas] Ongoing update of the enhanced VPN draft

Hi Jie,

MPLS, SRv6, LDP/RSVP, etc. are all mechanisms using which NRP can be
realized. "Enhanced VPN" uses the NRP framework and hence I thought that
NRP-based VPN is perhaps a better technical term. Just as BGP MPLS VPN was
perhaps a correct technical term.

End customers will ask for VPN service with whatever brand name that their
service providers will come up with. I don't think we should worry about
those marketing names ? ;-)

In any case, I think it is best to leave it to the chairs and the IESG to
arrive at a suitable choice of terminology during the review and
publication process.

Thanks,
Ketan

On Tue, Dec 19, 2023 at 9:01 AM Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

> Hi Ketan,
>
>
>
> Thanks for your review and reply. It seems you are OK with other changes
> in this version, except the terms enhanced VPN vs NRP-based VPN.
>
>
>
> I believe that is because we are looking at this term from different
> perspectives. What you suggest is a term from the realization point of
> view, similar terms are MPLS VPN, SRv6 VPN, LDP/RSVP based VPN etc. While
> the term “enhanced VPN” is from the service experience point of view, which
> should be technology agnostic. Customers used to ask for a VPN service
> without requiring to use LDP or RSVP, similarly they could ask for an
> enhanced VPN service, without being bothered with how the enhanced VPN is
> delivered.
>
>
>
> It would be great if we can firstly converge on the perspective from which
> this term should be defined.
>
>
>
> And I fully agree with you to not hold this document on this terminology
> issue, so it is time to ask the WG chairs for guidance about the next
> steps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Ketan Talaulikar [mailto:ketant.ietf@gmail.com]
> *Sent:* Tuesday, December 19, 2023 12:25 AM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* Greg Mirsky <gregimirsky@gmail.com>; teas@ietf.org;
> teas-chairs@ietf.org
> *Subject:* Re: [Teas] Ongoing update of the enhanced VPN draft
>
>
>
> Hi Jie,
>
>
>
> I had suggested NRP-based VPNs because these "enhanced VPNs" require NRP
> for their realization and that is what brings the "enhancements" from
> "traditional" VPNs. Right?
>
>
>
> The problem with use of a generic "enhanced" term is that VPN service has
> been continuously enhanced over the decades and this process will continue.
> Therefore instead of saying "enhanced" using a term that indicates what
> that enhancement is would be more meaningful.
>
>
>
> That said, I will leave this terminology discussion to the WG and then to
> our ADs/IESG.
>
>
>
> If there is no consensus in the WG to change or not to change, we should
> not (IMHO) hold this document over this terminology issue.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Wed, Nov 29, 2023 at 6:58 PM Dongjie (Jimmy) <jie.dong=
> 40huawei.com@dmarc.ietf.org> wrote:
>
> Hi Greg,
>
>
>
> Thanks for your further comments on the terminology.
>
>
>
> Personally I don’t think we need the term “connectivity service VPN”, as
> connectivity is just the service an normal VPN would provide, and as you
> said there is no definition of “connectivity service VPN”. Introducing
> such a new term does not add value to this document IMO.
>
>
>
> And since TE or RSVP-TE is just one approach to provide the underlay for
> enhanced VPN, “VPN-TE” is not generic enough to describe this type of
> service without limiting the realization technologies.
>
>
>
> Thus unless people propose a better term, my suggestion is to stay with “enhanced
> VPN” as the term for this service.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Tuesday, November 28, 2023 4:53 AM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* teas@ietf.org; teas-chairs@ietf.org
> *Subject:* Re: [Teas] Ongoing update of the enhanced VPN draft
>
>
>
> Hi Jie,
>
> thank you for the clarification. That helps a lot. I would propose two
> additional updates in the terminology used in the draft that, in my
> opinion, could help a reader:
>
>    - Instead of "conventional VPN" refer to "connectivity service VPN".
>    Although I cannot find the definition of "connectivity service VPN, it
>    seems easier to understand compared to the existing term.
>    - Use VPN-TE, analogous to LSP-TE, in place of "enhanced VPN". As
>    we've agreed, RSVP-TE is a well-established technology that can already be
>    used to provide VPN-based services that conform to a variety of performance
>    metrics.
>
> Regards,
>
> Greg
>
>
>
> On Mon, Nov 27, 2023 at 2:21 AM Dongjie (Jimmy) <jie.dong@huawei.com>
> wrote:
>
> Hi Greg,
>
>
>
> Thanks for showing your support to the terminology update.
>
>
>
> Regarding the “conventional VPN” service, as mentioned in my previous
> mail, it is just a connectivity service. Traffic engineering (TE) is
> technology used in the underlay network, though it may be used in
> delivering VPN services, it is considered that TE is not an integral piece
> of the “conventional VPN” service.
>
>
>
> This document says “This document describes a framework for using
> existing, modified, and potential new technologies as components to provide
> VPN+ services”.  Thus RSVP-TE could also be considered as one candidate
> technology for delivering enhanced VPN service.
>
>
>
> Section 7.2 also gives some analysis about the scalability of RSVP-TE when
> used to provide enhanced VPN service.
>
>
>
> Hope this helps to solve your question.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Monday, November 27, 2023 5:24 AM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* teas@ietf.org; teas-chairs@ietf.org
> *Subject:* Re: [Teas] Ongoing update of the enhanced VPN draft
>
>
>
> Hi Jie,
>
> thank you for the detailed update. I greatly appreciate that the authors
> kindly considered our discussion at IETF-118. I welcome all the proposed
> steps to tighten the terminology, but it seems like I still have a question
> about the interpretation of "enhanced VPN". Here are my thoughts:
>
>    - An enhanced VPN is characterized in Abstract as "
>
>    leverages the VPN and Traffic Engineering (TE) technologies and
>
>    adds characteristics that specific services require beyond those
>
>    provided by conventional VPNs.
>
>
>    - Next, I look at what can be characterized as "a conventional VPN".
>    It looks like there are two technologies - Best Effort and Traffic
>    Engineering, with the latter using RSVP-TE LSP. Would you agree?
>    - If my understanding of the "conventional VPNs" is accurate and it
>    already includes TE, in which regard the proposed solution is enhancing the
>    well-established technology?
>
> I appreciate your thoughts and welcome others to share their views.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Nov 24, 2023 at 6:27 PM Dongjie (Jimmy) <jie.dong=
> 40huawei.com@dmarc.ietf.org> wrote:
>
> Dear WG,
>
>
>
> As discussed in the IETF 118 meeting, we are updating the Enhanced VPN
> draft to make two changes:
>
>
>
> 1.         To make the work more consistent with the network slice
> framework draft, we will replace the term VTN with NRP
>
>
>
> 2.      To avoid any possible feeling of “marketing”, we will remove the
> term “VPN+” and use only “enhanced VPN” within the document.
>
>
>
> During the meeting there was some suggestion that the term “enhanced VPN”
> should also be replaced, but we think this would be a mistake:
>
>
>
> 1.         When we talk about existing VPN services as described in many
> IETF documents, we don’t use terms like “traditional VPN” or anything
> like that. A VPN service as described in those existing documents is just a
> connectivity service. It is true that many vendors sell, and many operators
> deploy, VPN services with additional QoS / SLA commitments. This document
> does not try to imply that those services didn’t previously exist – just
> that they have not previously been described in the IETF. We suggest that
> “enhanced VPN” is a good way to describe this type of service that is
> more than has previously been described in the IETF.
>
>
>
> 2.         There was some concern about “What would we call a future
> further enhancement of the VPN service if we have already used the name ‘enhanced
> VPN’?” We think that any future additional parameterization of the VPN
> service would still fit within the description and categorization of “enhanced
> VPN” as described in this document.
>
>
>
> 3.         When we refer to the solution technologies for realizing VPN
> services, we may talk about “BGP/MPLS VPN” or similar. But in this case,
> we are not focusing on the solution technology – yes, there is an
> architecture for delivering the solution, but just like network slicing,
> the detailed solution is out of scope for the framework and left to
> multiple other I-Ds. Therefore the term “enhanced VPN” should not be
> taken as describing the solution/protocol technology.
>
>
>
> 4.         An idea was proposed in the meeting to use the name “NRP-based
> VPN”. We don’t think this is the right term because it exposes a
> realization mechanism and seems to force a solution. What we need in this
> document is a term to describe this type of service.
>
>
>
> Thus we suggest that the term enhanced VPN, which has been used all the
> way through the development of this document, should be retained as no
> better term has been suggested.
>
>
>
>
>
> Best regards,
>
> Jie (on behalf of the coauthors)
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
>