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

Igor Bryskin <i_bryskin@yahoo.com> Fri, 13 August 2021 17:43 UTC

Return-Path: <i_bryskin@yahoo.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 0D7923A2083 for <teas@ietfa.amsl.com>; Fri, 13 Aug 2021 10:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 4FLmIV_BukWt for <teas@ietfa.amsl.com>; Fri, 13 Aug 2021 10:43:38 -0700 (PDT)
Received: from sonic308-9.consmr.mail.ne1.yahoo.com (sonic308-9.consmr.mail.ne1.yahoo.com [66.163.187.32]) (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 3A84F3A20BE for <teas@ietf.org>; Fri, 13 Aug 2021 10:43:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1628876616; bh=6QMFzdoQYLk/d4sX6VxC3StphqDppUyyAP0iQ2K5Txw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=L3oPHzGgBHm/jLJoWwxt5iHbuFZkWYCGCOsSU1nA08pxueEEP614wxLgl9mL64+iZYjbBliRmIW/rcMqBurAqlB4q2RMZkTElf6JpCOh3Voku061Wfai0+RqR+gTxbFPK8eCvVSq/cy7LvzS+VFXjdDlgLKz2p5UX/VPZE9wQieoq0s/mo6iYWDjCqAyaX81NuDlPboSFyql1ns7n7PHcRiT5oNw509Y2ySy52guieZBZR/aAt1aBnywjFf5IdWMAZcbqaU7c2+3ZlzVT89xMLneFi4sX4AWF4TYHxKyZwXD1IIcIv0QC+LIevIQfjwATdZfMt1TkYuxx7b5Ars/ww==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1628876616; bh=/XsDFkYvyLXYACiH8A6IkvB49LL3Bnhn4wDYSK8lIdF=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=cW0MCPmRW1lwUn7+FvirxrO6O/FpMNV0zzLAMLhAAt+PKFpdEhj6eTV1et7Ve1JH5mWyFObE6/byU/cSRsjmVrjoaD+5vvNM5FHtMw73HiHR8wEWw22jJypXsRK+rhKiQIcxc19EeebPTTK90eAIYMLulp5s3siZQsVg+macMi7P7zWg5aoO/sIUeMb/UjO47Ec933DB+QLxBRkFt5fsbdcLDtSs53wxyQjXRqhB+Z10zjRIV9eK8LRuLyfS3VVqsdbYOqeBWvKPgWaaPwlRYOXcIIqpamHVKh7WpAx39/VTHTxrfVe8tYpto1dQUdlZtMgJUJkaDSpfFGBI2YXd6A==
X-YMail-OSG: 0sUaOOYVM1nF2cN7n_qdcOuLYWjwL47ucc4sTFdL3uSJZpLHCRoa72lyr5Uff1R n7uzf.U2JKd9f8ac8sczzv1Mc8BGmiNZiwh7BlrM_TGimS2uXCfW7pOlx6sTYl8ZqZHon0wRu38v r0TUpvQYvsgZgPXMlCWtuazX7Yp8uRIdo0SaeISAYvy88tz.dj0Oz6Z.GlpoJ3lnHMipKbS9JHhG eexvP6M8l9r7iJKEYmMAZKhdZYaST86zdHrFfLmH3Cw8NQQbeMYLQxNe62722XoV22UU5_hqoQ8U 8X_YiZjweyqcNcCS3n1j8mszCJC10KWKBbMAouyxnkjIdH.k8bu0HMF3xtvpp_dHrxLn.9bQRE4Q Jq8AD5_L9SzYnaser2v8DaiC_wnq4pPvRqNDYVwblWAtNxtNia1kSEOaVqq8Huj0pfXCrUXb_yP2 Ui.2wSKQ9XyiYLTqWHTeV1EilI1NHTRGj9rrry6Z4cjyKV.ipCXIIWxF_4BcAgGBmfwW4uKS.T8d ZcXqcLB0ROn7HyqUVSp7u3hyF2HqyFS4CBMId..CFfBpER03RnVQukqr6pNkUhzYjJCMUe0LhdSS jd6t.FdMZW.4m9YpNEfNB_MvdUCyn_hCCBko3HpPq5TAWX3wYxd.Pcu9zUemmFppnNue7pylXPrf 4iNNVFl31fTYrQ_eqk1qL1dwQ80o_Qt8lSMYQitHtn9Q9.zFQRhnAL7OUy1TnM_gCeYHc5VuaGnJ BpgueLZfopsbJghx66nxL03_F4f0km3pyAl8nC2DpGeCDDmle.jguqevFtuO39twQ9mDLqMjgCrw xImYM9__UzAsQpKCtsEu70VBn.650DLdByh6zYbvQT05eIeoF2uR2evM5jsCHxSZ627a2x2nPJsA m7orV3RqT4Eym5cjhEky.RxUfDs2Xyg48oCtzuQ0oqeVQ4HTvJPYm0zPYlFZ.MvoKoaHLKjosFVM n_ErzkMRCerRWNdjFMQBCrq39cMxmTb3Jc8igSGscysoJ.rtfetE_pv_jDcj2BnemqGw70oK1lbb VMYHazPTD1538nM206WJt36CoT.SAb1XBMf1gsDlzUlalIQRQgreTL8RzP0AOo8EwUGagiGJIxGH 5lT0agrsu85XyKHcPNMOapR0VnnzaOzv1KU8.gzoJIH1xH9LI_ft8_KFpqmKwnbTWqZt70P9LEeJ 6mBrQXfFvazHhwWfGkgov4BI2gy3PzVs9uHUl_IXABjn46xcwsKYyO72FkmqTqVrkVyES79wVn2r 4su50a_PtV6GkNKSjhwpAM0Ad9F4BpP4aI_1hLhO0x.gkCPzOdPMNtjMIV9WL2_.CztD50lFJMDb G076cYB4C2vsVF6a13XlehRCeSY4gNpS3xyoOFwyXDw8FRzVm441p6KSfUvRNMhHOXcAAG3wfBEV EgK2C0lRE7FczCC6rxpFUOWNortKOd1xL6JJtmd1P.XuwQaFJvZ6ro5EW0o9Axu.H3TyOPzNUjDD DYxutnWqqvVkBRK.hEd6XGq3RWnnJlFjVDE0Yr6J_OvAAbUi.ODyKwNutSkMNSuqCoJe1F.nnXmj uK4KNxDGnstCC8EU8YnMIYlYsYFwfcmA34HJzGCYtJs5xhrK0PMkfV8oeBVRB9naAVFb2MTGgNbb UqEAvbTWtTWQyT97KQSK859QyA0qN.qhcYBqByC7uabOXgpQs1LqlIvwFJMGgBfAaSsgU8OjnLEh 3zC2IqMoVTp1KxVZhekEqU8PuTBpCcgAKXe9qAkc7YpSvQmzQTrtkMoJPyChgueDMNp0Ce2qXoSd DI7kca.rLwJLynbZ60TsviKXzSMnoDFak8IjsiqKpEu.199NUUdE2c67bmDOwAMHE1O34ldPm4eA Jfe07RfD.HSjZSnmLhrh8vcXcNd2mVaGBIryZxRRwaUBSp2nXYdxJCLMdqJcY.tL5sfr0w795nHX YJM4nFJI.pjZsFHBn4O9GXdQKqikkin5.uKmcEG63HoYoTtoeBL2JvTPKR2q7OC.hG3rfUHlpRt_ YMmTBqwuQF8KXXdyk3mO_2Co73O8wKFIGEJkF8w9VsrZHBk26_2kdHAZ4vuSG3KRH81Bcek05_1Z i9KJwtFKu6WdZS6fj5PF5XtnifnJR2Xb16w4raS1ejVlmNkz_omuO6FOfgjh0rb4DXJsbLkN61Au RkAR_YTednveMYLHk2D5RUC1lP_0.gF8rPpC2.nEfRoYR7MYd.yRoXH8zo8ioJDHZ897E4UtPF4t T.DT51ZFs5k1uI_rAnhodbWR6MIVa1wHTGAdtjdrkfZoQt9kjd.zr___TH_XF13v.521O2o6Kezx cy3DNECe2HvTAm9gyN4Mkb2VI4gbkMicDLCXh8nPIpQcmpULewxuugJWddr.JwxpNpQPkeHrem7d mWcnuj.pyHUyppAtbvzmHgHWofAQ1Ncc.FTCcfIDyoQd9
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 13 Aug 2021 17:43:36 +0000
Date: Fri, 13 Aug 2021 17:43:29 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
Reply-To: Igor Bryskin <i_bryskin@yahoo.com>
To: jmh@joelhalpern.com, "Joel M. Halpern" <jmh@joelhalpern.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Message-ID: <996253199.327229.1628876609732@mail.yahoo.com>
In-Reply-To: <80aa6341-0838-0b37-48ff-6139938d8e23@joelhalpern.com>
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> <80aa6341-0838-0b37-48ff-6139938d8e23@joelhalpern.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_327228_161406490.1628876609728"
X-Mailer: WebService/1.1.18850 YahooMailAndroidMobile
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/GIPGYEC6PNTO62p-QpHKoOwzIIA>
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 17:43:55 -0000

I agree with Tarek and Pavan. For example, if a TE LSP carries N services, a transit nodec N of said LSP  interprets the top label in the stack as said services aggregate. The number and identity of the services is not important. What is important is the forwarding treatment of so labeled packets .
Cheers,Igor

Sent from Yahoo Mail on Android 
 
  On Fri, Aug 13, 2021 at 12:01 PM, Joel M. Halpern<jmh@joelhalpern.com> wrote:   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

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas