Re: [Teas] Rtgdir early review of draft-ietf-teas-enhanced-vpn-14
"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 09 November 2023 09:51 UTC
Return-Path: <jie.dong@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B526C14CF15; Thu, 9 Nov 2023 01:51:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7U7HpdH77CE; Thu, 9 Nov 2023 01:51:09 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBE8C14CF05; Thu, 9 Nov 2023 01:51:09 -0800 (PST)
Received: from lhrpeml100001.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SQxvW4PTcz689J2; Thu, 9 Nov 2023 17:47:35 +0800 (CST)
Received: from kwepemd100006.china.huawei.com (7.221.188.47) by lhrpeml100001.china.huawei.com (7.191.160.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Thu, 9 Nov 2023 09:51:06 +0000
Received: from kwepemd100004.china.huawei.com (7.221.188.31) by kwepemd100006.china.huawei.com (7.221.188.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.23; Thu, 9 Nov 2023 17:51:04 +0800
Received: from kwepemd100004.china.huawei.com ([7.221.188.31]) by kwepemd100004.china.huawei.com ([7.221.188.31]) with mapi id 15.02.1258.023; Thu, 9 Nov 2023 17:51:04 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>, "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>
CC: Lou Berger <lberger@labn.net>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-teas-enhanced-vpn.all@ietf.org" <draft-ietf-teas-enhanced-vpn.all@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Rtgdir early review of draft-ietf-teas-enhanced-vpn-14
Thread-Index: AQHZ58Dy9GLIwo4iG0Sl4VbjQ+MXwbAhfl/AgATKpACABo/iwIAfdtwwgBw5qwCAAhmgMIAFqa6AgAHHe7A=
Date: Thu, 09 Nov 2023 09:51:04 +0000
Message-ID: <193d93ecea734fcebed47b0a99269a9c@huawei.com>
References: <169477437897.20609.13766236160564136155@ietfa.amsl.com> <2d202e8efa03473c8273ab39647134b9@huawei.com> <CAH6gdPwahLErF5Rv53SEkkuYWh8+5o2CndHN7a6wJednU1R=pA@mail.gmail.com> <fdaabaeb9c1a448e878f8999da038366@huawei.com> <571af2ef57544c4aa452133b40c69d8d@huawei.com> <6d72ec0d-80f8-d25a-d729-e33d993fa16d@labn.net> <c24cabca70c54e39a7e08cbc3692e1d6@huawei.com> <CAH6gdPyJi=xVDXZPaDu4rF_1T+rtv330juqenqSRCa7tEH1GPw@mail.gmail.com>
In-Reply-To: <CAH6gdPyJi=xVDXZPaDu4rF_1T+rtv330juqenqSRCa7tEH1GPw@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.126.169.254]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/n8-NH_J7RmbzvfXgcLVzZDR89ak>
Subject: Re: [Teas] Rtgdir early review of draft-ietf-teas-enhanced-vpn-14
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2023 09:51:11 -0000
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 <ketant.ietf@gmail.com> > Sent: Wednesday, November 8, 2023 3:38 PM > To: Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org> > Cc: Lou Berger <lberger@labn.net>; rtg-dir@ietf.org; > draft-ietf-teas-enhanced-vpn.all@ietf.org; teas@ietf.org > 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= > 40huawei.com@dmarc.ietf.org> 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 <lberger@labn.net> > > *Sent:* Saturday, November 4, 2023 12:05 AM > > *To:* Dongjie (Jimmy) <jie.dong@huawei.com> > > *Cc:* rtg-dir@ietf.org; draft-ietf-teas-enhanced-vpn.all@ietf.org; > > teas@ietf.org; Ketan Talaulikar <ketant.ietf@gmail.com> > > *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:teas-bounces@ietf.org <teas-bounces@ietf.org>] > > *On Behalf Of *Dongjie (Jimmy) > > *Sent:* Wednesday, September 27, 2023 6:27 PM > > *To:* Ketan Talaulikar <ketant.ietf@gmail.com> <ketant.ietf@gmail.com> > > *Cc:* rtg-dir@ietf.org; draft-ietf-teas-enhanced-vpn.all@ietf.org; > > teas@ietf.org > > *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:ketant.ietf@gmail.com > > <ketant.ietf@gmail.com>] > > *Sent:* Friday, September 22, 2023 8:22 PM > > *To:* Dongjie (Jimmy) <jie.dong@huawei.com> > > *Cc:* rtg-dir@ietf.org; draft-ietf-teas-enhanced-vpn.all@ietf.org; > > teas@ietf.org > > *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) <jie.dong@huawei.com> > > 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:noreply@ietf.org] > > > Sent: Friday, September 15, 2023 6:40 PM > > > To: rtg-dir@ietf.org > > > Cc: draft-ietf-teas-enhanced-vpn.all@ietf.org; teas@ietf.org > > > 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
- [Teas] Rtgdir early review of draft-ietf-teas-enh… Ketan Talaulikar via Datatracker
- Re: [Teas] Rtgdir early review of draft-ietf-teas… Dongjie (Jimmy)
- Re: [Teas] Rtgdir early review of draft-ietf-teas… Ketan Talaulikar
- Re: [Teas] Rtgdir early review of draft-ietf-teas… Dongjie (Jimmy)
- Re: [Teas] Rtgdir early review of draft-ietf-teas… Dongjie (Jimmy)
- Re: [Teas] Rtgdir early review of draft-ietf-teas… Lou Berger
- Re: [Teas] Rtgdir early review of draft-ietf-teas… Dongjie (Jimmy)
- Re: [Teas] Rtgdir early review of draft-ietf-teas… Ketan Talaulikar
- [Teas] Rtgdir early review of draft-ietf-teas-enh… Ketan Talaulikar
- Re: [Teas] Rtgdir early review of draft-ietf-teas… Dongjie (Jimmy)
- Re: [Teas] Rtgdir early review of draft-ietf-teas… Dongjie (Jimmy)
- Re: [Teas] Rtgdir early review of draft-ietf-teas… Lou Berger