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

Hi Ketan

As Jie mentioned there are two points of view which is the provider
perspective SLO and NRP which talks to the underlying underlay under the
provisioning control of the operator and the VPN overlay perspective which
is what is used by the customer that benefits in the user experience in the
SLE Service Level Experience.

So this draft is about the type of customer POV VPN service being delivered
which is underlay type agnostic within the NRP.

Kind Regards

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*

On Tue, Dec 19, 2023 at 1:15 AM Ketan Talaulikar <ketant.ietf@gmail.com>
wrote:

> 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
>>
>> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>