Re: [Teas] Rtgdir early review of draft-ietf-teas-enhanced-vpn-14
Lou Berger <lberger@labn.net> Fri, 03 November 2023 16:14 UTC
Return-Path: <lberger@labn.net>
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 9FB99C15C2A9; Fri, 3 Nov 2023 09:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.com
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 fHOUA1ad2mCz; Fri, 3 Nov 2023 09:14:12 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2105.outbound.protection.outlook.com [40.107.220.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD85C187721; Fri, 3 Nov 2023 09:05:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QnatT1QNP2sLJGVmuNUlOrtvZYdbDOjCl96Nm4fyF1NKWbNh2aBLwgd5Qw49xLM4sZTygqJc8jPKscwQv3iamPNr58+I5PdXdw6JXuM4LYSvXs7YIlcx3ykR9FZVon6E8W5CZCB8jthD9VPRYoRtQFlBoRZK7qs2PiUuS6Bv7e2I33fMe45ZWzCphiEOg6hkGaIXsxBsydmVbCtvGD43c2yFTj20YFy4IJHarcOUtr/1x76pUcdx9pOxipI0lb2HXfHxCdmVagIPPzGU5vl6w0VEZ7KhnG9yCtpRRk6af6zpFAs3bNoFyfhW1q9fdbpgh/2A34OceeRlxYUecBo85w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oNF84a2ndx8mzMQtRyOVOw1v7k+K/DI9a590n24mgT4=; b=HfOtPqU2+yKr6z033S66FbPA2NGBuCJTZ++9SutD/HilgGu5ek64mO5TScDtXmSqVM1yZMQf3lReXvjm/o2tu8DxCJoBJXT4kMLg92WJ/iYjGoJyZP/7p9/b7pyCOq8xVIMtFCXdPDrNowe5g52n4zue0JyTLdM+2JeynqBjPnQy4y/1D6vL/P3j8fF41BO1SPbvpUTsCVx9PT2TBvfArYDGw9y4S8XzMwdCmIlKIXkEngA6BpgLqNQVe1VLHGpZiyT1PDy2GLQQi7qQ2cwVjYHcuEbuA/yr+0Bb/3Bg5AjDY3lB/WuF1/QX+544lkRpNXTtgJ5r9QSNTmpECUILog==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oNF84a2ndx8mzMQtRyOVOw1v7k+K/DI9a590n24mgT4=; b=OpRlBh13CKzRgqhKj8G5HhFH1HKD1ItCVMraJ1QPpJZ64btvy8PCmo5htfvsLPg9MLnWyiItF4r0q+DaIf6KbjhRKQ1Zx+NRQT0Y0AXUZINNfwbPe6cNVR0I8RnamXl5Ja009nzCsnSvjP40EpiyNLttz9WfY0sgSVMnqktUjck=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=labn.net;
Received: from SJ0PR14MB4792.namprd14.prod.outlook.com (2603:10b6:a03:379::24) by SA1PR14MB6606.namprd14.prod.outlook.com (2603:10b6:806:336::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.21; Fri, 3 Nov 2023 16:05:13 +0000
Received: from SJ0PR14MB4792.namprd14.prod.outlook.com ([fe80::37c5:8b87:837e:183a]) by SJ0PR14MB4792.namprd14.prod.outlook.com ([fe80::37c5:8b87:837e:183a%7]) with mapi id 15.20.6954.021; Fri, 3 Nov 2023 16:05:13 +0000
Content-Type: multipart/alternative; boundary="------------7RenoqepKKUU9pWEYYmfC0Mf"
Message-ID: <6d72ec0d-80f8-d25a-d729-e33d993fa16d@labn.net>
Date: Fri, 03 Nov 2023 12:05:10 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
Content-Language: en-US
To: "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>
Cc: "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>, Ketan Talaulikar <ketant.ietf@gmail.com>
References: <169477437897.20609.13766236160564136155@ietfa.amsl.com> <2d202e8efa03473c8273ab39647134b9@huawei.com> <CAH6gdPwahLErF5Rv53SEkkuYWh8+5o2CndHN7a6wJednU1R=pA@mail.gmail.com> <fdaabaeb9c1a448e878f8999da038366@huawei.com> <571af2ef57544c4aa452133b40c69d8d@huawei.com>
From: Lou Berger <lberger@labn.net>
In-Reply-To: <571af2ef57544c4aa452133b40c69d8d@huawei.com>
X-ClientProxiedBy: BL1PR13CA0388.namprd13.prod.outlook.com (2603:10b6:208:2c0::33) To SJ0PR14MB4792.namprd14.prod.outlook.com (2603:10b6:a03:379::24)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ0PR14MB4792:EE_|SA1PR14MB6606:EE_
X-MS-Office365-Filtering-Correlation-Id: 801c23f8-f73d-4aa5-c6a5-08dbdc86a95c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: cG21SCyqNXLEXMyBE2ZYgarVw2uULvsNH0IZ6mxYpYX5MvPm3SkpLxbtyBlnVq8c8HvLJYg4u4kcF2FVZuV7AEwIp5xUYuNjaUuJb/cd2LO5nj2KiS+nP7R1RZKZHJl6fwxLnIoRNdRYPVULCbZmusQOpNac+9OWA2g+oEuUELb3ajMHuLjsbXX/BixOXRtLYKMRdjmnRtAR3tR3SB8R4qkoFaKBb+a8Onl6h+Gf0lxGB9uwr4gnGZlsjwxPYzXL7GRs8vc0ccLGmVPV0/RBpGcKFhoiT4gRoI9m8R3UPKxC/fcOCGpJuqwwTAXT26FT5TPu02HBvDhf3/UArGc3Hb3K9Kze5ZcUGwux8iMqJ7/6t266/YTbtTQ8HiShpY56HKN++fiSJyjEQkSYSQ4TwKPc/J/HELG2o7vBwDwGRsK//ochV+vGXpUvg69mPUoxsB1Fey8cuwoxmVM8Dmg5WTVEre6Q5j2ApcHeq15L/NJVGOkOXi1Ks+ioTTSf9wuMs1goX5ML5nT7jirWmLrpvjcgPzFrqC0xFsUFwgENcHWYcaTh4CBMJr03lokIMQgacoPmHfPvKWrgP/iiGLjVZHvHEcVQMdUY96mIuABkA93TvuVnszratmbL18APdjtTo/3eScoXJoaQq3kgmtaNug==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR14MB4792.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39830400003)(376002)(346002)(136003)(366004)(396003)(230922051799003)(64100799003)(451199024)(1800799009)(186009)(6486002)(30864003)(31686004)(8676002)(66556008)(54906003)(8936002)(66476007)(66946007)(4326008)(2906002)(316002)(5660300002)(478600001)(107886003)(6512007)(53546011)(66899024)(2616005)(41300700001)(26005)(33964004)(6506007)(83380400001)(38100700002)(86362001)(36756003)(31696002)(45980500001)(43740500002)(559001)(579004); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: nPtmvGTQcuEMjoAQUb2eYL1XKq9FJtiSsqlC82ZahOV1aDAVN37fQUBe/UAHKU7rcR8sQgS1lk9uIa/aYztoRDj4WyUerBgdfmk31mF8F/K1BPPutYClKtCHMY+JPWn8oCU+N1WlSAupZvw4un3perIQqcdq4NCQw8nUoSRht1HKVS1DXtzniqmOaQX1OrQDG2vPVE51BAxyFq+bo/q/EPi4QQD/HVWbKwiJS17Klay2ptJZSAdPGwfbdNbIIbePwBEKDV50j3F5ZfHeUt2xgHa7V+IYz8ctTNCMjplg841NggWpIAkcaQqhPPm+Iy91AKCz/TchVYogTmHKLkkBRCX0pLzj5/U+PUVxPk3GbYqn7TwwqO5wnSmuLFmXQ96/A3zJexnxkt3Iq3O6SgP2/p+/ploGzCzn70VZpvTcnyKztShwz1E1rEGzHK8NH7OI6B9uoaZLu+D1frXWhN+lpImr7wv3ZlzUXUAud/IqJ3FPyAB+1phsF+DCAU8dTBjbKzlyYqKlr91C6Y+u1r9uRJKfrj/Q4bt+1xCEUw7n14wfqPuESM4d3goQRvteytwPdiOP+9IA9npmLD0jHIIUiq1PR3bng9k0JPwimnK6Bzp6l3OGZIwAjRlTPilrhes6wQG5XyBXvEoFZB7O2znEs62qOP/uRAuB2TQ+3lFJ6e4VfNRud6Ip0YZI3KYi2pUYlwoXOCFbRfeDw6y8KbFefHg++EG3buX/+s66ejORxvuTOW9PejFPJ5igPP22Uvsso+eIkSh8m/iyXOf0aySYy3yTkZRGLLIpvvO5GBgxuhfYGMytZAe5lhMGw0xTjRJpLh9KcwU/DBqQTIDCvENFGsdCnwQKf7Fl8oylCCc/Jnvg5Dx6QaqQC2nieoMW8Cj3pvNYg2EKipv7PBMMpA/4M3k1CgRrQ59Xy/pQNkbbJ5tAl64tw8Hm9/6JONyjM/nw5lygvaSfvpDwYOT3MG1ljxSmLjzWapcVCaIvH0Cv7wQlA1T9L3m3H94tvk2tW+VFGxTDCC2ANI5EfRGCTIYI+QVb0efdAkZMpMEom8k0j6JAoNf9ifKnjoxOkKWCxkz/BeEgsE998RdBrmPmB5aJUMn89THF1NtyehHfnyFwd5x9F9zhoIcXuze4UUaj5+65M8DPUaxtXLVBrD8Y4OrJIR33hLVFitQPkH+F6cV+Uk0DXcWZEy3l0EQGGmViCDVezYZon9lgXh3Di0hv4Gq5uJpqynKZcEZ3xpBuic1iibsN6+jOyEYVqQA21Za4I0Y3UAKnA5DteuMomdP6K5i97JmzfJM94+bzGEHSTY2A1oEZe18O53BnA6LsD5Nmgkpx+21WFo2xnoPLxZNXBXCy/hhW9F7QnlNzrDDl8L/lZeB8obHBuKA8uRg02cpWURcxsTEHc9W69n0bc/Sadh/9rMTKoJTLQKBMW0Meytop/u5o19oALHIfcYa7I+VFS46C7GhLGiN2zN6hLFFADn+dVD69qjxk7hQTu9zzndYKeFmQUBrIHqQ9J85CgTtSfC2KjpsROaI7lG1uswOtRfxWbAh5JMuSLLQt7HzbfBpCiRhelHzeKAkBYjSALJGV8qm9
X-OriginatorOrg: labn.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 801c23f8-f73d-4aa5-c6a5-08dbdc86a95c
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR14MB4792.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2023 16:05:13.2346 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: eb60ac54-2184-4344-9b60-40c8b2b72561
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: erECEJclYeYs1bl/tvR8F03gYc3TZTomFWqFEQaD177K3VJwbIK7+CTkiHSkgnDZP7O1ypOJpxXFifKshJxBSQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR14MB6606
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/1w_aOzOFEoulwvvYQK3aB2gBVJA>
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: Fri, 03 Nov 2023 16:14:13 -0000
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] *On Behalf Of *Dongjie (Jimmy) > *Sent:* Wednesday, September 27, 2023 6:27 PM > *To:* Ketan Talaulikar <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 > <mailto: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 > 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 > 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 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 > used in this document instead of VTN if those constructs are indeed > synonymous. > > [Jie] As mentioned in the draft, VTN is a generic concept introduced > in the VPN+ framework, and it can be used for delivering VPN+ services > (including network slice services). In the context of network slicing, > VTN can be instantiated as NRPs. > > > But then the document says that VTN can be also used outside the context of > > IETF Network Slicing. > > My thought is the WG has reached consensus on this: VPN+/VTN is > generic, it can be used for realizing IETF network slices, and > they can also be used for other scenarios (assume that we would > not call all those services "slice"). > > KT> There is already a framework for IETF Network Slicing that is soon > going to get published as an RFC. Would it not help to focus only on > the non-slicing use-case/framework in this document? The Network > Slicing framework is done - does the WG intend to propose two > frameworks for the same problem statement? > > [Jie] As mentioned above, these two frameworks are complementary as > they are focusing on different levels. One is about the high level > network slice framework without touching the realization technologies, > the other one is about the realization technologies and how they are > put together. > > > > > Suggestion: Focus on the description of the VTN construct by itself > > independently. Then cover its applicability in the IETF Network > Slicing > > framework in one section and the applicability independently (as > an underlay > > for any VPN service) in another section. > > With the above background information and explanation, hope you > have better understanding about the relationship between VPN+/VTN > and network slicing. > > KT> I am not really there as yet - but I think I am getting there. > Thanks for your patience. More importantly, our goals should be that > clarity should ultimately emerge in the document for the benefit of > any new reader. > > [Jie] Good to know we are making progress. We can add some further > clarification about the relationship between IETF network slice and > VPN+ to help the readers. > > > The applicability of VPN+ for IETF network slicing is briefly > described in the IETF Network Slicing framework in one section. > The details are in this document. > > > > 3) Identification of VTN > > > > There are multiple documents out in other routing WGs (some adopted, > > some > > individual) and in 6man WG that talk about a VTN-ID. This > document which is > > used as the reference for VTN in all those places is > conspicuously silent on > > the aspect of an VTN-ID - i.e., Do we need a new ID or can we > use existing > > identifiers based on the underlying transport/underlay > technologies used? > > You are right that the data plane VTN-ID is not explicitly > discussed in this document, this is because there is another > document draft-ietf-teas-nrp-scalability which is focusing on the > scalability considerations of NRP, and whether to use new ID or > existing identifiers was fully discussed there. My suggestion is > we may add some brief description about the new data plane ID > mechanism in this framework document, and refer to the > nrp-scalability draft for details. What do you think? > > KT> Indeed the topic is covered in draft-ietf-teas-nrp-scalability and > I agree with you that it may be best to discuss it in that document > rather than here given your explanations above. > > [Jie] This is good, thanks. > > > > > I am sharing these uber-level comments first so we can have a > discussion and > > converge. The detailed review will follow once were are past > these issues. > > Thanks again for your high-level comments, and hope my reply can > help to better understand this work and the relationship with > other network slicing work. > > Thanks. Looking forward to continuing this discussion. > > Ketan > > [Jie] Please let me know if the above replies solve your remaining > concerns. Thanks. > > Best regards, > > Jie > > > > Best regards, > Jie > > > > > > Thanks, > > Ketan > > > > > > >
- [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