Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Vishnu Pavan Beeram <vishnupavan@gmail.com> Tue, 15 September 2020 11:40 UTC

Return-Path: <vishnupavan@gmail.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 E89B03A0AB3; Tue, 15 Sep 2020 04:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IFBvQBfTGTDf; Tue, 15 Sep 2020 04:40:11 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF133A0A82; Tue, 15 Sep 2020 04:39:44 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id m17so3691533ioo.1; Tue, 15 Sep 2020 04:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=25alUHcK2sBCjcHq3I2q0PKjix8SBgeFvWXtc3T1XlM=; b=Wsa5zARn9HC6Q5oqxpjimHCW/ICQDay7P7aIjdeFxOcja8+1UOWKPcTIQjFyFxkwT6 xOWTZLyXggc4YGU9C4QUQ2+XKUpp+YxPLgv04hfcwu4t0xxaV9AIMIusDrQJefFbdEIA T+HS0o73JBTGQRVUhf0RoGpdxLWXhm8Deko5/y9DZ05ckYlKBQ880MqaOxxMyCs0/LTB mmV3A2rYknDqouXg0uLaG/Paa1EhvbEjAaGIxOgnpiBmwj+JYjZaxB2/t+3MRNm5qtmF 1zXDX/vk689bQPsi2eUdnMlcJ3BpztZuvWey56g+Q5CBcJ4ZJWgcxOESA42uSZ4pZPCI 4YwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=25alUHcK2sBCjcHq3I2q0PKjix8SBgeFvWXtc3T1XlM=; b=uMcL4nYNTzi4gjFpeun3yMWozuzzlKg4CojKSXdH5Wkk+i9yCwc4hmDpKjM+Jlh9lC 6s/Y3kHa09DKJNUVIJDc5VEMIfn/a46uo880yP8zEVaYTgtcBAkhgX7hSq8cAedpdlgX RzCEnslENKVkRv39yTCqXwkxzjeu46VbFKmz9omuYMRu3kRMPfrHxWDX9S279RdEhboy A3hAKjRxo1nSB7BFgcfyauryq7R0CfiE1KmWYINNlJ8OAimTTG6rztHJdd30hT7BZKED lajg3tT/B5hMMOcPbXMszGLpve50q2c/lgkOgasM918JRpJbGtsMGch3u6BuqVwMNXYF cpWA==
X-Gm-Message-State: AOAM532soCvaUREykDt3kAEAWBmy6Ha60cpR2Y7sMTD3P4Zt1iwKHETX PyszeWofS1yiXc9tij7QE2L67Elldxx90gT1ykLYtVDACQ4GGA==
X-Google-Smtp-Source: ABdhPJzXqC1FvDQr0Wm0ZgmLKEt6r6QcWW3eTF2f5bD+NaHD4PdsQSwF8fvRZ4h1MnzEGLBagF5tA2P+fGMCD6Rotw0=
X-Received: by 2002:a6b:da16:: with SMTP id x22mr14582944iob.33.1600169983024; Tue, 15 Sep 2020 04:39:43 -0700 (PDT)
MIME-Version: 1.0
References: <CA+YzgTvnv5nUZ6OYx9GkFUxDHxAFNvYsx5LrFfho3860_MLfZA@mail.gmail.com>
In-Reply-To: <CA+YzgTvnv5nUZ6OYx9GkFUxDHxAFNvYsx5LrFfho3860_MLfZA@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Tue, 15 Sep 2020 06:39:31 -0500
Message-ID: <CA+YzgTvvHCYkXEXmBOBj-Y0gPw9SMM1dyae5Xoa7ywwYryKKRw@mail.gmail.com>
To: TEAS WG <teas@ietf.org>
Cc: TEAS WG Chairs <teas-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006b224805af589b6d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Eza_nhJ2K0X2xG_DfCkG9pDZW9Y>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition
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: Tue, 15 Sep 2020 11:40:13 -0000

WG,

Thanks to everyone who contributed to the discussion! It's clear there is
significant interest in this topic – and that we have not yet reached a
point where this version of the document is ready to be published as -00 WG
document.  The discussion has been quite productive and we see a number of
points on which there is general consensus on how the document should be
changed.  Once these changes are made, we can reevaluate publication as a
WG document.  Our reading of the discussion so far:

   1. The objective of this work is to define how IETF technology can be
   used to support Network Slicing. This could be to realize an end-to-end
   network slice including all constituent network slices (multiple network
   slices can be arranged hierarchically or stitched together to constitute an
   end-to-end network slice) or to realize a specific sub-set of the
   end-to-end network slice (as is the case with the 3GPP NSSI use-case). We
   understand that the focus of the 2 documents produced by the DT is on the
   latter (understandably so, given the current interest and immediate need).
   The discussion on the list suggests that there is a need to articulate (the
   focus of the document) this better.
   2. The term "transport slice" seems to have been coined to define the
   specific usage of IETF network slice in the 3GPP NSSI use-case. There is
   currently no consensus on the introduction of the term "transport
   slice"/"transport network slice" and this usage needs more debate and
   justification.
   3. Our (the chairs') intent is for the definitions document to be rolled
   into the framework document after both the documents get adopted.
   4. While not part of this adoption call, we expect that the framework
   will define what network slicing is (using language from the definition
   document) and discuss what is needed to support slicing. Though we do not
   expect the framework document to provide/define solutions, mentioning
   how existing/emerging IETF technology such as ACTN and Enhanced VPN can be
   used to support slicing is within scope (particularly if gaps are
   identified).
   5. The TEAS WG will continue to discuss and progress the framework for
   IETF support of network slicing (independent of solutions). The appropriate
   WG will work on specific protocol extensions/definitions. For example, any
   discussion on use/extension of Transport NBI could take place in CCAMP.

@Authors -- Please make the required changes to the document as per above
and publish a new individual revision.

We are also considering an interim meeting in October to facilitate more
discussion on this topic – please look out for more details on the list.

Regards,
Pavan and Lou

On Wed, Aug 19, 2020 at 10:50 AM Vishnu Pavan Beeram <vishnupavan@gmail.com>
wrote:

> All,
>
> This is start of a *three* week poll on making
> draft-nsdt-teas-transport-slice-definition-03 a TEAS working group
> document.
> Please send email to the list indicating "yes/support" or "no/do not
> support". If indicating no, please state your reservations with the
> document. If yes, please also feel free to provide comments you'd
> like to see addressed once the document is a WG document.
>
> The poll ends September 9th (extra week to account for vacation season).
>
> Thanks,
> Pavan and Lou
>