Re: [Teas] FW: The word "transport"

Adrian Farrel <adrian@olddog.co.uk> Fri, 01 May 2020 16:03 UTC

Return-Path: <adrian@olddog.co.uk>
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 E9E563A1629 for <teas@ietfa.amsl.com>; Fri, 1 May 2020 09:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 s1vasJzz0LxR for <teas@ietfa.amsl.com>; Fri, 1 May 2020 09:03:49 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 DC3EE3A1884 for <teas@ietf.org>; Fri, 1 May 2020 09:02:59 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 041G2t05019699; Fri, 1 May 2020 17:02:55 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3C0302203A; Fri, 1 May 2020 17:02:55 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 303D722032; Fri, 1 May 2020 17:02:55 +0100 (BST)
Received: from LAPTOPK7AS653V (81-174-202-163.bbplus.pte-ag2.dyn.plus.net [81.174.202.163] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 041G2rYI021060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 May 2020 17:02:54 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Rokui, Reza (Nokia - CA/Ottawa)'" <reza.rokui@nokia.com>, 'John E Drake' <jdrake=40juniper.net@dmarc.ietf.org>, teas@ietf.org
References: <036501d61f26$01756f20$04604d60$@olddog.co.uk> <DM5PR05MB33881A76688021C9B05EA556C7AA0@DM5PR05MB3388.namprd05.prod.outlook.com> <03ef01d61f9a$2f5850f0$8e08f2d0$@olddog.co.uk> <A02167A2-4AA6-4522-A6E8-8D9157BEB3F4@nokia.com> <044101d61fc5$1656bd50$430437f0$@olddog.co.uk> <C974BCBC-BDD7-4A01-AED7-30926BC72987@nokia.com>
In-Reply-To: <C974BCBC-BDD7-4A01-AED7-30926BC72987@nokia.com>
Date: Fri, 01 May 2020 17:02:52 +0100
Organization: Old Dog Consulting
Message-ID: <04a901d61fd1$f8f15600$ead40200$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04AA_01D61FDA.5AB744A0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIMCNRaZu8YlTaDCQfeAjf3ZILbpAFlZRhPAfoMhc0CDDG86QGGDXihAkWx32in3dHZUA==
Content-Language: en-gb
X-Originating-IP: 81.174.202.163
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25390.001
X-TM-AS-Result: No--21.909-10.0-31-10
X-imss-scan-details: No--21.909-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25390.001
X-TMASE-Result: 10--21.909200-10.000000
X-TMASE-MatchedRID: oll/cJ/dUC7xIbpQ8BhdbPHkpkyUphL99+PHtghP8GLkOOZ1bT6psUvb zgaPgQGDZEO8Mz5QcJqqcFoiuu90X1ZN3vbgch+RSVHYMTQ1F1qkdO7TbvbzY9Zd/DOmlnxIiLr IVMftV9AAtu70WiyEN8zsxjBXqDOK6XtK5n1RIZKEv01fZOqaQA73P4/aDCIFGUs9b7xvtJq+WN wn66/c77MCKmibVFG2/1pApDTWN7aID0Lqh6RYhNB/IoRhBzVH9/plKg1lCshpsnGGIgWMmUu9e 4S/+fL2AHGqNSKTbkwWlopaNujU8XrSP9RtGZYoTvKpZzlxUs88lvugAFiFP6uPvo9L6iaIY+st XhOphMXBrDLcrkIQOwLk/TX6VQBSKbaLT5sxztM3X0+M8lqGUt9WrDP4LKdpGA7uwIZNHQ1cX89 dDrF4+YmZnwWWIBq/vy1D537721dh9/cDmdaORiH9ExNVXbjbGfESeH6pl4ZHZg0gWH5yUdo4FZ oSpQ8Y8WbxCR6CYWl7EW7ad22PF2GA/BgSguhrJhFEQZiq2ZTyCvICuK46cvAlhlr8vzcdLg4aE fqmR9dv4LXaUTxzCM5gLQgIAFB+pBUgYSl1eZVu2K0KSdxtGYrpD7h4O62+1fKO4SX8ER1R18Qp zXStTvkHxcbJXlk3td4Z7LZFK5hLWe8kV6qU6hlLm7Fc/E3p6ffS8UIW2hzNk+s3CDz+vORqQAx bWD9+4vM1YF6AJbbVZ0g740lL+QSz8fXAzKymKzfM9B6IRt5FGCd0S0NCskkvGmfblYi88WoanI vFQ2AKcdQyycG/RGxr2uTqf0aWCStjCuOR/hg=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Sp6uCMhEZyoWGlB3-fnoxWbZCR0>
Subject: Re: [Teas] FW: The word "transport"
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: Fri, 01 May 2020 16:03:51 -0000

> I don’t understand “we (IETF) do not deal with network slice”.

 

Please refer to Figure 4 of the draft.

In summary, an E2E network slice is the logical network from End user X to End use Y and comprises of:

*	One or more Transport slices (TS)
*	One or more Other Slices (OS)

 

Well yes. I can read the drafts. That’s why I don’t understand your comment that the IETF does not deal with network slice.

 

Referring  this Figure, it is clear that IETF deals with Transport slice which is part of an E2E network slice and “Other slices” are outside scope of IETF.

 

You mean that you are saying that the scope of the IETF is limited to a subset of network slices that you call transport slices. But that is to say that the IETF works on some network slices, so I think we’re clear that the IETF does deal with network slices.

 

Please make a clear distinction between Transport Slices and e2e network slices. They are different.

 

I have read the 3GPP work. Yes, they are different. Although, I think it is a terrible shame to limit ourselves to this use case. Slicing is an abstract function and we should be able to use it to support many different types of service. And I think it is important that it should be a recursive concept. So, when a transport slice is enabled by slicing a lower layer network, you (presumably) call the slice of the lower layer network a transport slice, and the transport slice that is enabled by the transport slice is called a transport slice. Not confusing at all 😊

 

IMHO, any reference to “Network Slice” in IETF drafts means “Transport slice” . 

 

Wow, well, maybe you need to check that with the authors of those drafts and (of course) set it in the context of the definition of “transport”.

 

>  Why do we have a “TEAS Network Slicing Design Team”?

Good question. The correct name can be “TEAS Transport Slicing Design Team”

 

Well, here I am going to be a little snarky, I fear.

No!

The name of the DT and it’s charter were clearly set out. It is what it is, and it’s work scope is clear. 

 

Enjoy,

Adrian