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

Lou Berger <lberger@labn.net> Mon, 31 August 2020 13:16 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 92FBF3A1373 for <teas@ietfa.amsl.com>; Mon, 31 Aug 2020 06:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 ipjzcwF8Wy_I for <teas@ietfa.amsl.com>; Mon, 31 Aug 2020 06:16:46 -0700 (PDT)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 BDE133A1375 for <teas@ietf.org>; Mon, 31 Aug 2020 06:16:46 -0700 (PDT)
Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 70B2C92AF1738 for <teas@ietf.org>; Mon, 31 Aug 2020 07:16:45 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id Cjfxk8gnrDlydCjfxkExGP; Mon, 31 Aug 2020 07:16:45 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=f91m+t6M c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=y4yBn9ojGxQA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=wU2YTnxGAAAA:8 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=1OgDWpaR0EyxrKTmQFsA:9 a=Y7jpg6tgkngkl1iY:21 a=4DfkP9aOm6SCt7s6:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=-RoEEKskQ1sA:10:nop_election2020_name_body a=Yz9wTY_ffGCQnEDHKrcv:22 a=NCq4FBG6EvGFEERSFaZp:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sBQxK3FOWPiW+GHhRIz/1ceaeU3iqjCVHCyDQX+lyyQ=; b=vOCRxEgLOv2949XMM3K/d23xfo Swq0rougqqZ7CD9tFaa7fZBw02bNlETY4tKhFY7N2unud2ri95bEr0tX2qahvBUGRKXdSPMc49+Oq VbILJG059x3YOo21c1zXKjqG4;
Received: from [127.0.0.1] (port=21421 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <lberger@labn.net>) id 1kCjfx-001jfc-2K; Mon, 31 Aug 2020 07:16:45 -0600
To: adrian@olddog.co.uk, teas@ietf.org
Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org>
References: <05b401d67d8a$4ddf5890$e99e09b0$@olddog.co.uk> <96590677-a8e2-b8f3-8a03-6a8cb7e54d5f@labn.net> <007101d67e48$4a8edcb0$dfac9610$@olddog.co.uk>
From: Lou Berger <lberger@labn.net>
Message-ID: <6fee8011-957d-398e-3bbc-9891ca3b446f@labn.net>
Date: Mon, 31 Aug 2020 09:16:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <007101d67e48$4a8edcb0$dfac9610$@olddog.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 127.0.0.1
X-Source-L: Yes
X-Exim-ID: 1kCjfx-001jfc-2K
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:21421
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/herxLV_cWczbPrsGA0rrINPAWQ8>
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 13:16:48 -0000

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
>>
>