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

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

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:[e-mail]]
Sent: Tuesday, December 19, 2023 12:25 AM
To: Dongjie (Jimmy) <[e-mail]>
Cc: Greg Mirsky <[e-mail]>; [e-mail]; [e-mail]
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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 28, 2023 4:53 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: Monday, November 27, 2023 5:24 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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=[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas