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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 13 August 2021 16:01 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 51E7C3A1D85 for <teas@ietfa.amsl.com>; Fri, 13 Aug 2021 09:01:42 -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 4Mk1N4UeCW19 for <teas@ietfa.amsl.com>; Fri, 13 Aug 2021 09:01:36 -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 32A443A1D84 for <teas@ietf.org>; Fri, 13 Aug 2021 09:01:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GmSwb2PhFz1nvCV; Fri, 13 Aug 2021 09:01:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1628870495; bh=mO7HsWvub5ms0EqXHk5E24IRa2I9WcZhhfarZ32sM1E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=XtF+5xsskbgISmYXjoaZ13ulAlSHYZbGoA5OyZAkOz6zYbdcYMwLWNOOJ40NBHUtC O/KTciF4Riwq3L/IlXsDoUFQpyyKZYgR4RNxChDMK4naurlbXH5uXVdmkJUgfkpiD4 aQ+lUnz1Q0BSeSXPdehftVn5daT7VwDA+MtpMcYw=
X-Quarantine-ID: <bXJJR0fK3bGw>
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) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GmSwZ3dB8z1nsjM; Fri, 13 Aug 2021 09:01:34 -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> <dfc0233d-4021-f127-545b-5d0cccd236f7@joelhalpern.com> <ebe9719f35e54eef9cc954e6b67736a5@huawei.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <80aa6341-0838-0b37-48ff-6139938d8e23@joelhalpern.com>
Date: Fri, 13 Aug 2021 12:01:32 -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: <ebe9719f35e54eef9cc954e6b67736a5@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/k2N6wS4HSvmPftZsrZaEWwErvUY>
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 16:01:42 -0000

I was using "forwarding construct" in the sense of "the information that 
determines where to send the packet."  (I will grant it is a bit fuzzy. 
  The Forwarding construct can select a group, adn non-forwarding 
information may be used within that, such as the 5-tuple.)

The point I am concerned with, that I believe you have confirmed below, 
is that the resource information does not determine the forwarding path 
(although there needs to be a suitable relationship as you say).  It, 
like the five-tuple and the DSCP, is concerned with what resources are 
sued to forward once the path is selected.

Yours,
Joel

On 8/13/2021 11:52 AM, Dongjie (Jimmy) wrote:
> Hi Joel,
> 
> Since usually the set of resources are allocated on a subset of the nodes and links in the underlay network, there is a need to specify the sub-topology on which the resources are allocated. That's why we say "VTN is associated with a logical topology", and it aligns with what you said "it needs to be tied to a topology where it is supported". So, I hope we agree that it is "a set of resources provisioned in a sub-topology".
> 
> And I agree we don't need to introduce a new topology identifier. There are well-defined mechanisms (e.g. MT, Flex-Algo) to specify the sub-topology, and it just need to refer to an existing "topology identifier".
> 
> As for "it is not a forwarding construct", may I know your definition of "forwarding construct"? To me the resources are allocated in the forwarding plane, thus it should be considered as a "forwarding construct". Please note this is a general discussion about the functionality of this construct, which can be applicable to different data plane encapsulations.
> 
> Best regards,
> Jie
> 
>> -----Original Message-----
>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern
>> Sent: Friday, August 13, 2021 9:30 PM
>> To: Dongjie (Jimmy) <jie.dong@huawei.com>om>; teas@ietf.org
>> Subject: Re: [Teas] New term for the underlay construct used for slice
>> realization
>>
>> 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/d
>>>>>> r
>>>>>> 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/d
>>>>>> r
>>>>>> 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/t
>>>>>> e
>>>>>> 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
>>>
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas