Re: [Teas] New term for the underlay construct used for slice realization

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 13 August 2021 13:30 UTC

Return-Path: <jmh@joelhalpern.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 4E1C83A18C8 for <teas@ietfa.amsl.com>; Fri, 13 Aug 2021 06:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 7-09j7cHLHM6 for <teas@ietfa.amsl.com>; Fri, 13 Aug 2021 06:30:00 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 833563A18D3 for <teas@ietf.org>; Fri, 13 Aug 2021 06:29:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GmPYZ11sfz1nsY3; Fri, 13 Aug 2021 06:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1628861394; bh=CuUAWYV7Fd2MbXdJQbbZ7Fh5YzDQq7FBHfJ/GIGLJEU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jWn6DSvL5xbhv5/VKBJ+uckuUfnmHGo9olFKZjLZLvXaFfI2J9MOZJn9fGDf/Fyn6 YVCSOBupM00UEmURPzz7P7rltVjCA+brIz2+r3OnfoduiQ8q7MlMz34lmkO2xomBHc FOYYxWmHbHDvt+zEtjqMWe6KOPLCljeIlg8vIX2M=
X-Quarantine-ID: <7gI_1YYQUo0f>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GmPYY341Sz1nsRP; Fri, 13 Aug 2021 06:29:53 -0700 (PDT)
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "teas@ietf.org" <teas@ietf.org>
References: <2ae53e44d60548e6ac961ac992615e9b@huawei.com> <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@BY3PR05MB8081.namprd05.prod.outlook.com> <33ca73966af4490d84b88c765e183a98@huawei.com> <BY3PR05MB80816B3982271C1FEA86E46CC7F89@BY3PR05MB8081.namprd05.prod.outlook.com> <a1e378cd81e144adad89d38987a2cb47@huawei.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <dfc0233d-4021-f127-545b-5d0cccd236f7@joelhalpern.com>
Date: Fri, 13 Aug 2021 09:29:51 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <a1e378cd81e144adad89d38987a2cb47@huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/7BiCMegkOo746QB3oIq0TEQdUG0>
Subject: Re: [Teas] New term for the underlay construct used for slice realization
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, 13 Aug 2021 13:30:06 -0000

If, as per the bestbar draft and the discussion of VTN-ID on 6man, this 
construct is NOT a forwarding construct, then I do not see how it 
identifies a sub-topology.   It needs to be tied to a topology where it 
is supported.  But since it is not the forwarding construct, it doesn't 
need to identify that topology as far as I can tell.

Yours,
Joel

On 8/13/2021 8:11 AM, Dongjie (Jimmy) wrote:
> Hi John,
> 
> Thanks for your clarification. I think we are mostly aligned.
> 
> My hope is the new term could reflect the two basic attributes of the underlay construct: partitioned resource and a (sub-)topology.
> 
> Best regards,
> Jie
> 
>> -----Original Message-----
>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of John E Drake
>> Sent: Wednesday, August 11, 2021 8:38 PM
>> To: Dongjie (Jimmy) <jie.dong@huawei.com>om>; Lizhenbin
>> <lizhenbin@huawei.com>om>; teas@ietf.org
>> Subject: Re: [Teas] New term for the underlay construct used for slice
>> realization
>>
>> Jimmy,
>>
>> Snipped, comments inline.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>
>> Juniper Business Use Only
>>
>>> -----Original Message-----
>>> From: Dongjie (Jimmy) <jie.dong@huawei.com>
>>> Sent: Tuesday, August 10, 2021 11:03 PM
>>> To: John E Drake <jdrake@juniper.net>et>; Lizhenbin
>>> <lizhenbin@huawei.com>om>; teas@ietf.org
>>> Subject: RE: New term for the underlay construct used for slice
>>> realization
>>>
>>> [External Email. Be cautious of content]
>>>
>> underlay construct for network slice realization bound to
>>>>> network slice services? That is, is the underlay construct only
>>>>> for use in network slicing, or should it be generalized for more possible
>> uses?
>>>>
>>>> [JD] Absolutely yes
>>>
>>> [Jie] I guess you mean "Yes" to the latter case, which is "it should
>>> be generalized for more possible uses", is my understanding correct?
>>
>> [JD]  Yes to the latter
>>
>>>
>>>>
>>>>>
>>>>> 2.      If the answer to question 1 is YES, should it reflect the following
>>>>> characteristics?
>>>>>
>>>>> a.      It is about the underlay
>>>>> b.      It is about the partitioned resources used to deliver the network
>> slice
>>>>> services
>>>>> c.      It allows the 1:1, N:1, and 1:N mapping models between the
>> network
>>>> slice
>>>>> services and the underlay construct. The 1:1 and N:1 mapping may
>>>>> be straightforward. Does it also make sense to divide the elements
>>>>> or traffic flows in a single network slice service to carry them
>>>>> in different
>>>> underlay constructs?
>>>>
>>>> [JD]  Yes to all of the above.  Please see:
>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
>>>> af
>>>> t-drake-bess-enhanced-vpn-06__;!!NEt6yMaO-
>>> gk!TCiJHCZCwFgwpuFoujxVlZ4r9
>>>> F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNaR2ImI4$
>>>>>
>>>>> Lastly, here are some candidates of the "new term":
>>>>>
>>>>> Option 1: The network slice service is called "overlay slice",
>>>>> then the underlay construct is called "underlay slice".
>>>>>
>>>>> Option 2: The network slice service is called "service slice",
>>>>> then the underlay construct is called "resource slice".
>>>>
>>>> [JD]  I don't think we need another term for what we are already
>>>> calling an 'IETF Network Slice Service'.  Adrian and I are
>>>> considering the term 'resource partition' to describe the
>>>> partitioning of underlay network resources in support of various
>>>> overlay services such as IETF Network
>>> Slice Services.
>>>> This is congruent with the ideas expressed in:
>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
>>>> af
>>>> t-ietf-spring-resource-aware-segmen__;!!NEt6yMaO-
>>> gk!TCiJHCZCwFgwpuFouj
>>>> xVlZ4r9F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNxEfwaXg$
>>>> ts-03.  What this allows one to build is an 'partitioned underlay
>>>> network topology'.
>>>
>>> [Jie] Agree that here we are talking about the term for the underlay construct.
>>> "Resource partition" captures one of its key characteristics, while
>>> IMO another thing the term needs to reflect is that the resource
>>> partition is needed on a subset of the links and nodes (rather than on
>>> a single node or link) in the physical network, which together builds a logical
>> network topology.
>>
>> [JD]  In my initial email, above, I was proposing 'partitioned underlay network
>> topology'
>>
>>>
>>> Best regards,
>>> Jie
>>>
>>>>
>>>>>
>>>>> Your opinion about these candidates are much appreciated. You may
>>>>> also propose other new term if it complies with the above two points.
>>>>
>>>> [JD]  I think you have exceeded your remit.
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Best Regards,
>>>>> Robin
>>>>>
>>>>> _______________________________________________
>>>>> Teas mailing list
>>>>> Teas@ietf.org
>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
>>>>> te
>>>>> as
>>>>> __;!!N
>>>>> Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
>>>>> O08HqD31TGJciNjuxL2A$
>>>>
>>>> _______________________________________________
>>>> Teas mailing list
>>>> Teas@ietf.org
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
>>>> as
>>>> __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
>>> ROxL4C2
>>>> _xNDCrPaNQ$
>>
>> _______________________________________________
>> 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
>