Re: [Teas-ns-dt] Brief meeting notes

Adrian Farrel <adrian@olddog.co.uk> Fri, 25 September 2020 14:58 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas-ns-dt@ietfa.amsl.com
Delivered-To: teas-ns-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751C33A0D2C for <teas-ns-dt@ietfa.amsl.com>; Fri, 25 Sep 2020 07:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 w4TIIm2bc_Ug for <teas-ns-dt@ietfa.amsl.com>; Fri, 25 Sep 2020 07:58:12 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 483C13A0D17 for <teas-ns-dt@ietf.org>; Fri, 25 Sep 2020 07:58:09 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08PEw75w014505; Fri, 25 Sep 2020 15:58:07 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5945922042; Fri, 25 Sep 2020 15:58:07 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 4834822040; Fri, 25 Sep 2020 15:58:07 +0100 (BST)
Received: from LAPTOPK7AS653V ([109.249.184.194]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08PEvvMY018396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Sep 2020 15:57:58 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Rokui, Reza (Nokia - CA/Ottawa)'" <reza.rokui@nokia.com>, teas-ns-dt@ietf.org
References: <1A1D96DA-199E-43CC-ADEC-B86D69E7F7CC@nokia.com> <055001d6933f$9ec7df50$dc579df0$@olddog.co.uk> <2A2ED2CF-837F-4E4B-9930-FD5A6F50BD54@nokia.com>
In-Reply-To: <2A2ED2CF-837F-4E4B-9930-FD5A6F50BD54@nokia.com>
Date: Fri, 25 Sep 2020 15:57:55 +0100
Organization: Old Dog Consulting
Message-ID: <059e01d6934c$41d194a0$c574bde0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_059F_01D69354.A397D160"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGdteskH0UMq2JQ15lgfmxlyf1qQQLToDfmAYBZy36pyIuf4A==
Content-Language: en-gb
X-Originating-IP: 109.249.184.194
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-25686.003
X-TM-AS-Result: No--23.422-10.0-31-10
X-imss-scan-details: No--23.422-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25686.003
X-TMASE-Result: 10--23.422100-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtFdJ5gHce5HZHFPUrVDm6jtc9pwoOhfS897ZWRAqE4ZPQVC juoLdH6iKIra+veulC4KGM2V2D7zHNl+dy3lQHNxN19PjPJahlJa9oWcYwi86pm3TxN83Lo4836 gDighvV3z8wHBATsUGUxqeUVLRqsR0FXLLHexU20COhpLDQSMVTpj3ToamD7kxnvNpHdG9JB9qe uIDfKPgyQg74xwKz8WSY7hSQiSdASKAYxIsv6nSzjO57N1IAWNCyj2gR0nEXVOIo0O+5ZV4Xm8O GfHROE8X0oVBEdf7kIVIG761BDveE0H5whZfav/lVHM/F6YkvT37+sC+hJ7iSVJ1X9ZfHjXXa3q Dl7ir0S93H1KjHi5bZhMelHjhkLXJo68qMugjZGQmLXB14cW2qm9/6ObPjnDilzcm2p6JE862pd b96ktr1k+9QC8kY6x8gkcSrELKuaBC0bE9Dj3YoS/TV9k6ppAiFB88PweKrUZSz1vvG+0mt3NNJ QDizxeiP6gZ1mkPFSJxAAXiYfSLYHua69lsoIiJmbrB1j4XwryCvICuK46cjuwTDpX8ii0wP6z6 hIFVzSKK4oV20g9mir9QHJXgaRE67i+HGj0A1PyKt/vA0HdKHAbV1eRKDmgH5kZy/EQbgQjdXY7 w1RwWmoyFBF/Gfm85wSBXJukZhGj9uiv8UoY8C9cBNSlgvYqJuJX9LfoIjgrxUs8Nw/2fvkqvyz JOYuqlzFTLzz3BbJbFkIp07VVk79mgjqjxHVaHcQQBuf4ZFtwJ5RNZmULoz2UWodwCj5HHLQ4ic lzEfRfel619+J2df1fmehio0kXMpC7OW35IMeJDLgwb/1K2WmRqNBHmBveGtkvK5L7RXGw7M6dy uYKg4VH0dq7wY7uoOjOcgQsG+WfX66zmQ8/WTTVumOPNca3e/C6xqk8qdI/e2cXeUj+Sg==
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-ns-dt/hqSr-Xho__-s6RbYAjb5kvvlBS8>
Subject: Re: [Teas-ns-dt] Brief meeting notes
X-BeenThere: teas-ns-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TEAS Network Slicing Design Team <teas-ns-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas-ns-dt>, <mailto:teas-ns-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/>
List-Post: <mailto:teas-ns-dt@ietf.org>
List-Help: <mailto:teas-ns-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas-ns-dt>, <mailto:teas-ns-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2020 14:58:16 -0000

Thanks Reza,

 

I need to digest this some.

 

I see how a connection may be a concatenation of connections. AFAICS an e2e slice is achieved by a concatenation of connections. I am struggling to see what is a “slice” and what is a “connection”.

 

Are these figures your own construction (which would be fine), in which case the term 2e2 network slice is something “you” have defined to help explain the figures, or are they borrowed from work in other bodies, in which case a reference would be really helpful?

 

Cheers,

Adrian

 

From: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com> 
Sent: 25 September 2020 15:42
To: adrian@olddog.co.uk; teas-ns-dt@ietf.org
Cc: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>
Subject: Re: [Teas-ns-dt] Brief meeting notes

 

Adrian,

 

The definition of the “E2E network slice” is better understood based on use-case. I have added two use-cases below.

In summary, the “endpoint” of a Connection might be any combination of various  VNF, PNF or applications. 

A couple of notes related to these use-cases:

*	IETF definition work is beyond any use-case. We are not stuck on 3GPP terms
*	The “E2E network” slice and Connections are not the same. We shall use different terms for them to make sure they are distinct
*	The scope of IETF work is not “E2E network slice” as shown below. Depends on the use case the “E2E network slice” might be different from “Connections”.
*	The IETF scope is related to “Connections” and question is which term to use for them.

 

Cheers,

Reza

 



 



 

 

From: Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >
Organization: Old Dog Consulting
Reply-To: "adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> " <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >
Date: Friday, September 25, 2020 at 9:27 AM
To: Reza Rokui <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >, "teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> " <teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> >
Subject: RE: [Teas-ns-dt] Brief meeting notes

 

Reza,

 

Where can I go for a definition of the term “E2E network slice” so that I can get a better understanding of the concept and work out how the terms “connection” and “network slice” fit in?

 

A lot will depend (I suppose) on how an “end” is defined, and what context is being applied.

 

Thanks,

Adrian

 

From: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> > 
Sent: 25 September 2020 13:29
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org <mailto:jdrake=40juniper.net@dmarc.ietf.org> >; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org <mailto:jari.arkko=40ericsson.com@dmarc.ietf.org> >; teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> 
Cc: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; Lou Berger <lberger@labn.net <mailto:lberger@labn.net> >; 'BRUNGARD, DEBORAH A' <db3546@att.com <mailto:db3546@att.com> >; Vishnu Pavan Beeram <vbeeram=40juniper.net@dmarc.ietf.org <mailto:vbeeram=40juniper.net@dmarc.ietf.org> >; Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >
Subject: Re: [Teas-ns-dt] Brief meeting notes

 

John,

 

                >>>> Reza said that we couldn’t use the term ‘network slice’ because 3GPP uses the term ‘E2E network slice’. 

 

This is not correct and this is not what has been said. It has nothing to do with 3GPP. 

Whatever I mentioned was that an ‘E2E Network Slice” Is a concept between multiple users and for an operator to create it, it need to create one or more artifacts for various “Connections”. 

Calling these Connections “Network Slice” is not accurate as they are part of the “E2E Network Slice”

 

Reza

 

 

From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org <mailto:teas-ns-dt-bounces@ietf.org> > on behalf of John E Drake <jdrake=40juniper.net@dmarc.ietf.org <mailto:jdrake=40juniper.net@dmarc.ietf.org> >
Date: Thursday, September 24, 2020 at 3:41 PM
To: Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org <mailto:jari.arkko=40ericsson.com@dmarc.ietf.org> >, "teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> " <teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> >
Cc: "adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> " <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >, Lou Berger <lberger@labn.net <mailto:lberger@labn.net> >, "'BRUNGARD, DEBORAH A'" <db3546@att.com <mailto:db3546@att.com> >, Vishnu Pavan Beeram <vbeeram=40juniper.net@dmarc.ietf.org <mailto:vbeeram=40juniper.net@dmarc.ietf.org> >
Subject: Re: [Teas-ns-dt] Brief meeting notes

 

Hi,

 

I just wanted to comment on some of the statements that were made during the conference call today.  I think it’s important that we have a written record rather than trying to respond during the conference call.

 

1.	Reza said that we couldn’t use the term ‘network slice’ because 3GPP uses the term ‘E2E network slice’.  Obviously, ‘network slice’ is a different term than ‘E2E network slice’ so this is nonsense.  Further, the definition of the term ‘E2E network slice’ would appear to be the concatenation of two or more ‘network slices’.
2.	Kiran said that the network slicing was introducing an entirely new concept to the IETF.  The last time I checked, there were roughly 20-30 drafts or RFCs on the topic of network slicing, all of which pre-date anything the NSDT has published and all of which use the term ‘network slicing’
3.	Kiran said that ‘transport network’ was a common term in the IETF.  This is incorrect.  ‘Transport Network’ is an ITU term and the only time it is used in the IETF is in support of the ITU’s use of MPLS.  This is MPLS-TP (transport profile).
4.	Kiran said that term ‘IETF network slice’ is not generic.  Why is it important that the term we use be generic and why is this term not generic?
5.	Kiran said that the NBI was not a service definition.  I think this is nonsense – otherwise, why do we have ‘service level objectives’?

 

Further, any discussion of isolation should be in terms of the variation of an SLO parameter’s value, since this is the only thing a customer can measure as the instantiation of its ‘service’.  E.g., absolute isolation would mean that a given SLO parameter’s value is invariant.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org <mailto:teas-ns-dt-bounces@ietf.org> > On Behalf Of Jari Arkko
Sent: Thursday, September 24, 2020 12:34 PM
To: teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> 
Subject: [Teas-ns-dt] Brief meeting notes

 

[External Email. Be cautious of content]

 

Situation:

- Documents not adopted as is

 

Process:

- we need to revise based on feedback and ask again

- wait on framework until definitions agreed

- interim on Oct 19

 

Main changes:

1/ need to use a different term

- Perhaps more about the name itself than its definition – but also have to worry about the latter. Maybe easier to discuss once the name is not objectionable?

- We all recognize the feedback, and agree not to use transport network slice term

- IETF network slice one contender, some resistance

2/ isolation

- Need acceptable content, not just a placeholder

- Need to understand which approach to use, though (Jari recommended explaining how the term relates to this work, perhaps some breakdown of the term as well)

 

Next steps:

- For each issue/change, a small team to look at it, provide some options, and analysis of the implications and tradeoffs in those options

- Post early to main TEAS WG list, keep discussion ongoing

- Jari can arrange a weekly call starting next week (again, posted to main list) for those who want to discuss in real-time. But useful only after the above two steps are done first.

- Responsible people: on the name issue, the author team; on isolation Luis, Jie, and Jeff will work on it

- Everyone else to stay active on list + comment and make counter proposals and additional analysis