[Teas] Re: Paul Wouters' No Objection on draft-ietf-teas-enhanced-vpn-19: (with COMMENT)

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

Hi Paul, 

Thanks a lot for your review and comments. Please see some replies inline:

> -----Original Message-----
> From: Paul Wouters via Datatracker <[e-mail]>
> Sent: Thursday, June 13, 2024 9:57 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: [Teas] Paul Wouters' No Objection on draft-ietf-teas-enhanced-vpn-19:
> (with COMMENT)
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-teas-enhanced-vpn-19: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> "Enhanced VPNS" can be easily confused for EVPN / Ethernet VPN ? The
> term is also sometimes capitalized and sometimes not, making it look
> like a formal term and sometimes like an informal description. Why
> not avoid using the word enhanced and call it "NRP VPN" ?

We agree that it is important to not confuse abbreviations. And obviously an Enhanced VPN is not an EVPN/Ethernet VPN. 

Originally, we used the abbreviation "VPN+" to represent "Enhanced VPN", but the WG asked us to not have two names for one thing, so we dropped back to saying "Enhanced VPN" in all cases.

Nevertheless, the service we are describing is an enhanced VPN. That is, a VPN with additional requests/commitments. 

This document (as it says) describes a framework for using existing, modified, and potential new technologies as components to provide NRP-based Enhanced VPN services.
In particular, although regular VPN services could be supported by NRPs using the techniques described in this document, that is not the point. The point is the to deliver enhanced VPN services, that is, connectivity services with advanced characteristics, such as low latency guarantees, bounded jitter, or isolation from other services or customers. 

Thus we think that "Enhanced VPN" is the correct descriptive term.

 
>        [RFC9543] discusses the general framework, components, and interfaces
> for
>        requesting and operating network slices using IETF technologies. These
> network
>        slices may be referred to as RFC 9543 Network Slices, but in this
> document
>        (which is solely about IETF technologies) we simply use the term
> "network
>        slice" to refer to this concept.
> 
> There was a long discussion with the IESG for RFC9543 to not confuse the
> technology
> with 5G network slices. Creating this "alias" here of course counters that whole
> concept.

The above text firstly sets the context to "IETF technologies", then refer to the network slices defined in RFC 9543 as "network slices" in this context. We hope this is clear and can avoid referring to RFC 9543 for many times. 

But if people still feel this could be confusing, we can add "RFC 9543" before each occurrence of "network slice"


>         While an enhanced VPN service may be sold as offering encryption
>         and other security features as part of the service, customers
>         would be well advised to take responsibility for their own
>         security requirements themselves possibly by encrypting traffic
>         before handing it off to the service provider.
> 
> This is true of all VPNs, and not really a security consideration for NRP VPNs ?

You are completely right. However, we wanted to call this point out because such services are being offered (that is, provider-based security), and such service offerings mean that security is promised to the customer, but the customer cannot know whether the security is being provided.

Because such service offerings fall into the scope of enhanced VPNs (and not of regular VPNs), we thought it right to include this text.

Since we all agree that the text is true, we think that it should remain. If it helps someone not to make a bad mistake, then it is valuable.


>         The privacy of enhanced VPN service customers must be
>         preserved. It should not be possible for one customer to discover
>         the existence of another customer, nor should the sites that
>         are members of an enhanced VPN be externally visible.
> 
> Same here?

This is also true. However, the mechanisms for delivering enhanced VPNs are extensions of existing techniques, and it is notable that a number of recent proposals to deliver enhanced services have not been clear on whether or not they are properly privacy-preserving. So the WG wanted this text to be absolutely clear.

Best regards,
Jie


> 
> 
> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]