Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing

"Dongjie (Jimmy)" <jie.dong@huawei.com> Mon, 31 August 2020 15:50 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 844193A16B9; Mon, 31 Aug 2020 08:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6hDDxWLSwX5; Mon, 31 Aug 2020 08:50:00 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E87793A16B7; Mon, 31 Aug 2020 08:49:59 -0700 (PDT)
Received: from lhreml712-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 5A6BD38E346B8C2856AA; Mon, 31 Aug 2020 16:49:58 +0100 (IST)
Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Mon, 31 Aug 2020 16:49:57 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 31 Aug 2020 23:49:55 +0800
Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Mon, 31 Aug 2020 23:49:55 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Lou Berger <lberger@labn.net>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
CC: 'TEAS WG Chairs' <teas-chairs@ietf.org>
Thread-Topic: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing
Thread-Index: AdZ9h3Zl6le4l7CpS4GedKhoPGFAhgAa3WqAAAST+gAAVCs6gAAUe8GQ
Date: Mon, 31 Aug 2020 15:49:55 +0000
Message-ID: <7a0dc0b653d24ae38f1f759e87b6c07d@huawei.com>
References: <05b401d67d8a$4ddf5890$e99e09b0$@olddog.co.uk> <96590677-a8e2-b8f3-8a03-6a8cb7e54d5f@labn.net> <007101d67e48$4a8edcb0$dfac9610$@olddog.co.uk> <6fee8011-957d-398e-3bbc-9891ca3b446f@labn.net>
In-Reply-To: <6fee8011-957d-398e-3bbc-9891ca3b446f@labn.net>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.220.168]
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/yRGVr1DtCW485tKgzmDjpJlaA8k>
Subject: Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 31 Aug 2020 15:50:03 -0000

Hi Lou and Adrian, 

Sorry to chime in, here I'd like to provide some information about the removal of the ACTN applicability text from draft-ietf-teas-enhanced-vpn-06. 

During the review and update of the latest revision, the authors realized that the management plane section contains a lot of details about the service model applicability, which did not quite match with the depth and length about the candidate technologies description in other subsections, thus reducing the details while keeping the key information is considered the approach to achieve the balance between the candidate technologies subsections. 

In addition, based on the discussion in the NS-DT, it was indicated that the NBI interface and the corresponding data models will be the task of NS-DT in next step (following the definition and framework), thus it may be reasonable to leave the details about the NBI interface and data models described in the NS-DT documents or some dedicated documents, and have this topic fully discussed in the design team.

Thus that change is relatively independent from the respin of draft-king-teas-applicability-actn-slicing.

Based on the chairs' comments and suggestion in IETF 108, we understand that such change need review and discussion from the WG. We have listed that change and the reason in the mail of status update to the WG, and we'd appreciate comments from people regarding such change. Thanks.

Best regards,
Jie

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Monday, August 31, 2020 9:17 PM
> To: adrian@olddog.co.uk; teas@ietf.org
> Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org>
> Subject: Re: [Teas] WG adoption of draft-king-teas-applicability-actn-slicing
> 
> Hi Adrian,
> 
>      As a general principle, I believe that if there is a suitable WG document
> for text sent to the list or contributed via an individual draft that such text
> should be incorporated into the WG document.
> 
> In this case, since we had/have ACTN applicability statements in both the
> draft-ietf-teas-enhanced-vpn and the draft-nsdt-teas-ns-framework. While the
> latter is not yet a WG document, the intent to issue an adoption call has been
> stated for a while.  (Extended IPR call completed last week, and adoption call
> just issued.)
> 
> So, I think it is reasonable to ask (a) what additional information is provided in
> draft-king-teas-applicability-actn-slicing and (b) can this additional information
> be reasonable incorporated into those documents.
> 
> WRT to your specific questions:
> 
> > - Is there a substantive difference between VPN+ and network slicing?
> My reading of the current documents is that the network slicing allows for
> different specific technology solutions.  In other words, network slicing *can*
> be implemented by VPN+, but can also be implemented using other
> solutions.  This is basically the same difference as exists between *what* is
> being done (i.e., network slicing), versus *how* it's being done (e.g., VPN+).
> > - Do we want to describe how to use ACTN for network slicing?
> 
> Given the inclusion of section 4 in the framework document, I'd say yes.  Also
> with the adoption call open, I think this is a great time for the authors of
> draft-king-teas-applicability-actn-slicing to voice that additional text  should
> be added to the framework document (with proper attribution).
> 
> Thank you for the discussion and usual good work on
> draft-king-teas-applicability-actn-slicing.
> 
> Lou
> 
> On 8/29/2020 5:06 PM, Adrian Farrel wrote:
> > Hi Lou,
> >
> > Just to be clear, text was not removed from draft-ietf-enhanced-vpn and
> moved to draft-king-teas-applicability-actn-slicing.
> >
> > draft-king-teas-applicability-actn-slicing pre-dates the enhanced VPN work
> and only lapsed when the enhanced VPN draft was brought to TEAS from
> RTGWG, and some (a lot?) of the same material was brought into the
> enhanced VPN draft.
> >
> > But I think you bring out three good points for discussion:
> >
> > 1. Is enhanced VPN sufficiently equivalent to network slicing to mean that
> discussing "realisation of VPN+ using ACTN" is a duplication of discussing
> "applicability of ACTN to network slicing"? My opinion is that when viewed at
> the service level, VPN+ and network slicing are very, very similar. However,
> despite having the enhanced VPN framework that described network slicing,
> the working group decided it wanted a network slicing design team. That team
> has not come back with a statement that the two concepts are very similar
> and has, in fact, produced its own framework for slicing that might (or might
> not) overlap with a current working group draft.
> >
> > 2. Should draft-ietf-teas-enhanced-VPN go in to details on technologies that
> can deliver VPN+ or should it focus on describing the function and architecture
> that is an enhanced VPN? The current section 5 ("Candidate Technologies")
> gives a very brief description of the different network and management
> technologies that could be used, and highlights areas for future work, but it
> does not dig deep into solutions. Indeed, there are a number of related
> solutions drafts in other working groups (LSR, BESS, SPRING,...) that set out
> more detailed solutions work. In that respect, the old sections 5.6.1 and 5.6.2
> were overly detailed compared to the rest of section 5, and removing text
> seems to have been a reasonable thing to do.
> >
> > 3. How many is too many Informational documents? While the various VPN+
> solutions drafts in other WGs are marked as Standards Track, it is a
> strangeness of where we are with ACTN that there is already and architecture
> and there are already YANG models (done or being worked on) that address all
> of the protocol needs. All that a document requires to do is show which of
> those models to use where and when in order to enable support for network
> slicing using ACTN, and that makes the document Informational. Once upon a
> time it was quite popular to write "cookbook" style Informational RFCs that
> helped people work out how to pull together bits of technology and build
> systems.
> >
> > Depending on the discussion of these three questions we could:
> > a. Pull material from draft-king-teas-applicability-actn-slicing into
> > draft-ietf-teas-enhanced-vpn and abandon
> > draft-king-teas-applicability-actn-slicing
> > b. Adopt draft-king-teas-applicability-actn-slicing and publish both
> > it and draft-ietf-teas-enhanced-vpn c. Abandon the work of the network
> > slicing design team folding new text into draft-ietf-teas-enhanced-vpn
> > d. Adopt and publish lots of documents e. Any combination of the above
> >
> > I think it is reasonable to ask the WG:
> > - Is there a substantive difference between VPN+ and network slicing?
> > - Do we want to describe how to use ACTN for network slicing?
> >
> > I don't think it is reasonable to ask the WG:
> > - What documents do you want to publish to achieve all of this?
> > This is my belief because the WG is focused on technology not the
> > niceties of publication. Actually, you either have to take the
> > documents that people are working on, or you (as chairs) have to tell
> > us what documents we should be working on (to which me might, of
> > course, object :-)
> >
> > Lots of fun?
> >
> > Best,
> > Adrian
> >
> > -----Original Message-----
> > From: Lou Berger <lberger@labn.net>
> > Sent: 29 August 2020 19:56
> > To: adrian@olddog.co.uk; teas@ietf.org
> > Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org>
> > Subject: Re: [Teas] WG adoption of
> > draft-king-teas-applicability-actn-slicing
> >
> > Hi Adrian,
> >
> > On 8/28/2020 6:26 PM, Adrian Farrel wrote:
> >> ...
> >>
> >> Looking forward to your thoughts on this.
> >       As we (chairs) mentioned to you off-list, before we can talk
> > about adoption of this document we still have the issue of working
> > through the discussion at the last meeting.  Specifically the text
> > that was removed from the WG document ( draft-ietf-teas-enhanced-vpn)
> > that is largely present in this document.  My question is: assuming
> > the text in is restored from draft-ietf-teas-enhanced-vpn-05, are
> > there one or more suitable existing (or candidate) WG documents that
> > could be a home for the remaining valuable text that is currently in
> > applicability-actn-slicing document? -- after all how many information
> > documents do we really need on this topic....
> >
> > I think this is a question not only for you and your coauthors, but
> > also for the WG as a whole.
> >
> > Cheers,
> >
> > Lou
> >
> >> Best,
> >> Adrian
> >>
> >> _______________________________________________
> >> 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