Re: [Teas] A draft on the framework for end-to-end IETF network slicing

Igor Bryskin <i_bryskin@yahoo.com> Fri, 14 May 2021 16:46 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 3A9B73A38B4 for <teas@ietfa.amsl.com>; Fri, 14 May 2021 09:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 1pOuGq4Ag4Mc for <teas@ietfa.amsl.com>; Fri, 14 May 2021 09:46:34 -0700 (PDT)
Received: from sonic301-32.consmr.mail.ne1.yahoo.com (sonic301-32.consmr.mail.ne1.yahoo.com [66.163.184.201]) (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 5CD7A3A38B0 for <teas@ietf.org>; Fri, 14 May 2021 09:46:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621010792; bh=nMfL8REpkYjKoM15cECHewD7IZ1+hDnfGfHABk7t8v0=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=qvFA2EuKhMly3HFftsoYVyDwMpbH9GYKPSa+PvpBSvy2ZUuBR6THHC0Duej3XfG24rSRhFoPDqWpQLzmVWPvrWl3Rpn3/uTBSWfWw2ZxFAjNN0UYt/05J5wPv8iPOx5YyCFpuEkMHolvijTbiuo3trDIRP4O5ph1Eoz/rhb8MiYRDCPg6g44k6BrSrOgvhLzVYORixa4E/mhgKoicCgZwLrbgRGxAHgW3t9eF3RB4JuQX0gllnnFAjfKKOZVaB43XWkAq54myZ6JekDr8T4lweXn7A7xxSVVt/hAFPGNjtEmzztOeN+29MsgwHU/i7VH7IJOrPrsJZGKpeQfzLIVhA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621010792; bh=7tiNdIWW5nxOneA1UckVT+kSWJJUogd9cloj0Ss8CoP=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=bync9t4CoO6GPhxwXfeSSRbDepupIP3QmMhkaJjQIksFc5oqDOb+Kx7/1PDQ0qMYPgdMvBi+3NGHGprOdKdJc1ysCU+376zN2zBtH6z8vcPKiGWfWknCFQmYjsfbbhLMlPC4ZtavsfADASqQo0/UoizDFSnjs+IUyjocc0PgJFKxgWTNpS6JrQsT8N9Feo+E46r1TBZ7iUwqRrYkyEUcOh3oWsXxI2QlzUTYYBMeqnLJxUe+rgmDdzVgpzK/iPf8EDiuujlpX+fbl62LCueudSkrd3ZTDaOU59v3HaedQF2ytFtRU3eVlWc8FLVxoUx9OBdrhOueotwY+xkTfOfhBQ==
X-YMail-OSG: q0fAKIAVM1kTN6jTlcvr7IklhwWB3f9iyzORJAC8GK96ALMzd2Z9Sepz1teFypD gRrUQQeGOL4SssU8KfWzdR1QYZPFGO0by3wrROZX7fm17bRoj9IIfF27u6PE_Sw3GKdy4ap_LF2d CflCulpjWjWDV8palU02KJoRMSyEJDVniYibTHqU2.d27_oyV97V57fkPQDNHNC.nxISn0xTCDes O.x5PX_dukuXHcxy3KARpLMwT9sDUcoFTAujVBVXVcAD3zZh3C8iSE99zz0LCIeVkmsI0on9Cgxr 3H75MxPO.MuXMSnmpltFaE7OWvw21VosjKXZBv7dtThPVlQlolfyGqGuqZOR3qu8gZrfH94CEl4E GlVi0NOek6dUOHOFObfzborjcCetcw73EM2i5jUZBXP2mEG6wJuCWSmk_j_BSCAjSu3RUefbW1Th 3_CQ_JmyMuyoshQyusSR95PJoY_34fUpdzjNhesbjL4xiqzNCJJsxdkW8STi8l0vaDbOoUMDs9e2 VwOzMIff8uWZBZnUr1dH4gsknEB0V45gz1oh7LSGsrZM4r8QsRIto78sZCELjNiUtdmScs8ZLvIN UTp7gwTzUzGOR3rheiYs9rdRrUtTilYqf5sYO8EtkVx8_YUybnHNBHKyymDzdv2QFED1sWh_9HoM n.0KBLj2itpYyLDuDcZsfiw05ykWfXv8_WQmYfqECJWP7GMmyHXLyoBd7N83.V5wM.fURxSrIyWB jz1bHeFZsBjYLyP3oID8TuDo2FWlDNRnuUKYFCdG_ZrKLffZwv3lFaz6a885zRVQPnu3XDQoFk0p dq.e0TPajv.6_2fe5RzNUMNWr8J3t8aZb6INEIAzw405unu5h6b.7eoGF.PwwdpdaK8Em1gnisYE BErsFHcOqq73eX6SAXntPOml4JpOdg6gKdZIHeosCTcNXLePTMsfiCr6LrlI95TR85OTCj.xMez_ JhCbIQGdcgYz1W3nt4Of6_MYZtoV3xKTdb16yGzbSixcCF2LHA6nfcXYoEqogI0jhrARt6UmRcTG fQE4oD_4Qg.KbCwuA2qSPwE1Dk.Fz1LSvVA3MCpAUuSCo8Z0q4r4OXTG0JEyS7M3U_2iJWMtCOxd JnNiqnat_CzGbt1V3jA3z8nnCsVnhhe4x8ykHCV8xZk8eDbIODnRLeZkvV.diysTNer6sPx1_qdt dEMPOICblUQYxLoPnAdh8O3kGXmsNt5DnlSqnSdY7BZpLdS8ZbxByGQLpcY6lXabJ4qAeo6LI3zX KewXI8j60tJAYcQ1wcy6Yvex84nQVrQX7LnyZqcZ4kR7OEZ2h.VMxSEKcmYxpKr6IXSpJrEN6Q5y kz3kjOFnpxfswkeS81pIAtGQ5zOBWCK.eNhA4ZddNxwO8VEE5C97U49NpsGrwD3ZlOFH09J27kGl GSV9sVURnnSy_Af6lh4Rb65sQ7Q5PTxSpgWL87pABP6K..e1cCh6DozGGfdqamML1UeYtVh1M0Oz 5FC_tVYypdn3TWIKF50Vr7V4s6wDp0QV0SurCpAv8rTq2UO0oX5wFdkHFpk.EAzzLlFuivX0VfYj lDKxHqMHeYFsftu2jAVhbPcoTdIfmPU5G87rl7FLaxts97Z15udrxwoGQV8YDPPuXiyGsM3KgF0u 3z_AUrv3Yg3DUof6zwL.H7om4UXAclJBo1cVKmC_viDqlZozryGpn3pAET_szVJ.LRKGNIe2ax_E 7I4QfHHD9Hq22qBn1twi6YCp530MmBLDk1n2XhoWnN.gntcDs1hb0Mi0ucYsOC73UZeXujIQavcH Oaqj4F_Jjc9VHIXKZwOCzNO_KNuTeky9hAHhu6GTaS4czzd.5cvsgou4cU1FeGtTcurM11ims11s XJX.J_f1U5DzdvbRZzYMn82Llm9niySq7TihbNB.kU1IDloabOz3tzSc3BMGsVhwPFiC2BwFr.97 3x3NG_mFSRjlevC.1s4CLK6RW7f25bCqkV1YfSeMpvyQ6L6veRdbSJY0RcMdAjd9TgaUwE.ilAcH tA0aMSFdArHscssIWchXMkHbwTZRyvjubdENOMrUkVAsLxWp6k4e0oQ8YObhWKfJ67UQynw8z4p6 uEXuwldrN6TEA3XralNawf6UUnE6FZb7wa0dnev_xAug3ks7tV8a70ASHUtuJ3T3Q15tHtv6fOIi i8T.3zQ8pfF4YF9.67nQnwq24CwjlXaW8qnP4ycxprDYbeT1yxlg7bNkPzQBd9ttGmDGTS_qc9vA a4EgSf_5gX12sndcossqz2Rw7CgjkzKcIHO0hHAXCFh2FuQiGm3H6L_UjMWmzQERL.3zwzRJTJF9 TL6kX2RGQxURIeJ7cX8AesosWMYVfB2dRZvza_jT9uGo0GpO_aEhp3ZJhIjmi8EVkso9gTHAsaui YgODhiVWhig1KTLVGnTQwB64iibWrxHUsMpdKZz11J3lbx1IUURG5fLef3mls8GlICy5_Ftdm0LB SUjlJ4G8GCCQfci7rjuf4j7SiMOuCd9amFDbe0w38yYjyY76OXtbBRD8tFevgB6_Lbl9r1rjJVhW W0vizsrHKJ97ID2GIYflEXy9uhIpi1deq
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 14 May 2021 16:46:32 +0000
Date: Fri, 14 May 2021 16:45:51 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "teas@ietf.org" <teas@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <1461772929.643501.1621010751444@mail.yahoo.com>
In-Reply-To: <db806eb6-7d24-b0ce-4bd7-a286cfb08b98@joelhalpern.com>
References: <c7bb7462db8f4149912d644adbd4760b@huawei.com> <e8e5e968-f6af-a910-d2ec-510fc98ff1d6@joelhalpern.com> <16d8b18dc5574d728842f086227efa97@huawei.com> <db806eb6-7d24-b0ce-4bd7-a286cfb08b98@joelhalpern.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_643500_1459596715.1621010751441"
X-Mailer: WebService/1.1.18291 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36 Edg/90.0.818.56
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/gMkmzmJ41bLNFX_oDNkI_TYTtpU>
Subject: Re: [Teas] A draft on the framework for end-to-end IETF network slicing
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, 14 May 2021 16:46:49 -0000

 Hi Joel,
Suppose a TE service/tunnel is requested and set up connecting access points A and B across the network. Can I consider such a tunnel as a trivial IETF network slice? If not, why? If yes. why not to reduce, generally speaking, the  IETF network slice problem to the problem of p2p and p2mp TE tunnels interconnecting IETF slice end points? For example, we have spent a lot of time discussing e2e multi-domain TE tunnels and how their segments in each domain are identified, associated, etc. Is it necessary or useful in your opinion to repeat the discussion in the context of slicing?

Thanks,Igor

    On Friday, May 14, 2021, 12:05:44 AM EDT, Joel M. Halpern <jmh@joelhalpern.com> wrote:  
 
 Do you mean traffic monitoring at the domain edges?  Or inside the 
domain?  If at the domain edges, then any mapping technology can also be 
used for monitoring.
If inside the domain, this places a significant disaggregated statistics 
collection load on the internals of the network.
Edge-to-Edge monitoring by the consumer (client? customer?) of the 
component is clealry useful.  But does not requrie such identification. 
  Nor does it requrie internal disaggregated state reporting.
the internals presumably will monitor the aggregated behavior.  Which 
again does not require the identification.

Yours,
Joel

On 5/13/2021 11:54 PM, Dongjie (Jimmy) wrote:
> Hi Joel,
> 
> Thanks for your comments.
> 
> The requirement of carrying network slice related identifier in the data packet was described in draft-dong-teas-enhanced-vpn-vtn-scalability and other relevant documents. Currently there are several proposals about the encapsulation of network slice related identifiers. Based on that, this document further describes the considerations about the multi-domain IETF network slice scenario, and the interaction with other technical domains for 5G end-to-end network slicing.
> 
> You are right that the path selection, resource allocation and traffic handling would be based on the identifiers internal to a network domain. As described in this draft, the end-to-end network slice identifier may be used for traffic monitoring at the end-to-end network slice granularity.
> 
> Best regards,
> Jie
> 
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Sent: Thursday, May 13, 2021 12:49 PM
>> To: Dongjie (Jimmy) <jie.dong@huawei.com>om>; teas@ietf.org
>> Subject: Re: [Teas] A draft on the framework for end-to-end IETF network
>> slicing
>>
>> It is not at all clear that any identifiers are needed inside the various networks,
>> and specifically it is not clear that an internal identifier for the end-to-end
>> network slice is needed at the level of the IETF network slice as is being defined
>> by teas.  Since path selection, QoS parameter handling, and resource
>> allocation needs to be handled in aggregate, it seems likely that no such
>> identifier is needed.
>>
>> Yours,
>> Joel
>>
>> On 5/12/2021 10:53 PM, Dongjie (Jimmy) wrote:
>>> Hi WG,
>>>
>>> Recently we published a draft on the framework for end-to-end IETF
>>> network slicing:
>>> https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-s
>>> licing
>>> <https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-
>>> slicing>
>>>
>>> This document describes the scenarios of end-to-end network slicing,
>>> and the framework of network slice mapping between different network
>>> segments and network domains. Multiple network slice related
>>> identifiers are defined to covers different network scopes.
>>>
>>> The network slice related identifiers of different network scopes can
>>> be instantiated with MPLS or IPv6 data plane, which are further
>>> described in the following drafts:
>>>
>>> https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slicin
>>> g/
>>> <https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slici
>>> ng/>
>>>
>>> https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-s
>>> licing
>>> <https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-
>>> slicing>
>>>
>>> https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-netw
>>> ork-slicing
>>> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-net
>>> work-slicing>
>>>
>>> Your review and comments are welcome. (Comments on the specific data
>>> plane draft can go to the corresponding WG mail list).
>>>
>>> Best regards,
>>>
>>> Jie
>>>
>>>
>>> _______________________________________________
>>> 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