From nobody Tue Nov 9 05:35:10 2021 Return-Path: X-Original-To: apn@ietfa.amsl.com Delivered-To: apn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B103A0CAD; Tue, 9 Nov 2021 05:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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_PASS=-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 MgbMNdzM5HwP; Tue, 9 Nov 2021 05:35:01 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC2E3A0CA9; Tue, 9 Nov 2021 05:35:01 -0800 (PST) Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HpTQY6rfJz67x9P; Tue, 9 Nov 2021 21:31:17 +0800 (CST) Received: from dggpemm100005.china.huawei.com (7.185.36.231) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Tue, 9 Nov 2021 14:34:49 +0100 Received: from dggpemm500008.china.huawei.com (7.185.36.136) by dggpemm100005.china.huawei.com (7.185.36.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Tue, 9 Nov 2021 21:34:48 +0800 Received: from dggpemm500008.china.huawei.com ([7.185.36.136]) by dggpemm500008.china.huawei.com ([7.185.36.136]) with mapi id 15.01.2308.015; Tue, 9 Nov 2021 21:34:48 +0800 From: Lizhenbin To: "teas@ietf.org" , "apn@ietf.org" CC: "bier@ietf.org" Thread-Topic: What is Slice Aggregate? Thread-Index: AdfVYnnLsrCLw1hUQOmhZ9vm12TKQg== Date: Tue, 9 Nov 2021 13:34:47 +0000 Message-ID: <87ac77be5b384189bd84149826e11722@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.160.4] Content-Type: multipart/alternative; boundary="_000_87ac77be5b384189bd84149826e11722huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Apn] What is Slice Aggregate? X-BeenThere: apn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Application-aware Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 13:35:05 -0000 --_000_87ac77be5b384189bd84149826e11722huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi authors of draft-ietf-teas-ietf-network-slices, The authors of the draft draft-zzhang-bier-slicing-and-differentiation-00 m= entioned in the draft: " [I-D.bestbar-teas-ns-packet] introduces the notion of Slice Aggregate which comprises of one of more IETF network slice traffic streams. A Slice Aggregate is identified by a Slice Selector (SS), and packets carry the SS so that associated forwarding treatment or S-PHB (Slice policy Per Hop Behavior - the externally observable forwarding behavior applied to a specific packet belonging to a slice aggregate) - can be applied along the path. " " The authors of this document believe that the IETF Network Slicing framework, when augmented by the Slice Aggregate, addresses the APN problem domain very well. " According to the past discussion, we think the slice aggregate means the un= derlay slice, that is the new terminology "network resource partition". If so, the Slice Selector should be the identifier of the network resource = partition. But according to the draft-zzhang-bier-slicing-and-differentiati= on-00, the slice aggregate can be augmented to address the APN problem. In the rec= ently published draft draft-li-apn-header-00, the APN attribute is defined including the APN ID (user group/application group) the packet belongs to ,= the Intent and APN parameters applied to the packet. It is apparent these attributes are totally different from the identifier of the underlay slice. Can you clarify the following about the slice aggregate: 1. What is slice aggregate? Is it the underlay network slice, the APN attri= bute-like parameters, both or other identifier? Or can it be all possible i= dentifiers to identify a flow? 2. What is the usage of the slice aggregate in the draft-ietf-teas-ietf-net= work-slices if it is not the network resource partition any more? Is it int= roduced a new identifier to identify a flow? 3. What is the scope of the slice aggregate work in the TEAS WG if it is a = new identifier other than the resource partition? Will you go on to define = the encapsulation and the protocol extensions for the new identifier or augment it to address the APN= problem? Best Regards, Robin --_000_87ac77be5b384189bd84149826e11722huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi authors of draft-ietf-teas-i= etf-network-slices,

 

The authors of the draft draft-= zzhang-bier-slicing-and-differentiation-00 mentioned in the draft:

   [I-D.bestbar-teas-= ns-packet] introduces the notion of Slice Aggregate

   which comprises of= one of more IETF network slice traffic streams.  A<= /p>

   Slice Aggregate is= identified by a Slice Selector (SS), and packets

   carry the SS so th= at associated forwarding treatment or S-PHB (Slice

   policy Per Hop Beh= avior - the externally observable forwarding

   behavior applied t= o a specific packet belonging to a slice aggregate)

   - can be applied a= long the path.

   The authors of thi= s document believe that the IETF Network Slicing

   framework, when au= gmented by the Slice Aggregate, addresses the APN

   problem domain ver= y well.

 

According to the past discussio= n, we think the slice aggregate means the underlay slice, that is the new t= erminology “network resource partition”.

If so, the Slice Selector shoul= d be the identifier of the network resource partition. But according to the= draft-zzhang-bier-slicing-and-differentiation-00,

the slice aggregate can be augm= ented to address the APN problem. In the recently published draft draft-li-= apn-header-00, the APN attribute is defined

including the APN ID (user grou= p/application group) the packet belongs to , the Intent and APN parameters = applied to the packet. It is apparent these

attributes are totally differen= t from the identifier of the underlay slice.

 

Can you clarify the following a= bout the slice aggregate:

1. What is slice aggregate? Is = it the underlay network slice, the APN attribute-like parameters, both or o= ther identifier? Or can it be all possible identifiers to identify a flow?<= o:p>

2. What is the usage of the sli= ce aggregate in the draft-ietf-teas-ietf-network-slices if it is not the ne= twork resource partition any more? Is it introduced a new identifier to ide= ntify a flow?

3. What is the scope of the sli= ce aggregate work in the TEAS WG if it is a new identifier other than the r= esource partition? Will you go on to define the encapsulation and the

protocol extensions for the new= identifier or augment it to address the APN problem?

 

 

Best Regards,=

Robin

 

 

 

--_000_87ac77be5b384189bd84149826e11722huaweicom_-- From nobody Tue Nov 9 09:50:13 2021 Return-Path: X-Original-To: apn@ietfa.amsl.com Delivered-To: apn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F883A0E83; Tue, 9 Nov 2021 09:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 s0JxJ9ErWFyg; Tue, 9 Nov 2021 09:50:08 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F5F3A0E97; Tue, 9 Nov 2021 09:50:07 -0800 (PST) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id F3A0854804B; Tue, 9 Nov 2021 18:49:59 +0100 (CET) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id DFC774E9D3A; Tue, 9 Nov 2021 18:49:59 +0100 (CET) Date: Tue, 9 Nov 2021 18:49:59 +0100 From: Toerless Eckert To: Lizhenbin Cc: "teas@ietf.org" , "apn@ietf.org" , "bier@ietf.org" Message-ID: References: <87ac77be5b384189bd84149826e11722@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ac77be5b384189bd84149826e11722@huawei.com> Archived-At: Subject: Re: [Apn] [Bier] What is Slice Aggregate? X-BeenThere: apn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Application-aware Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 17:50:11 -0000 I think a slice aggregate is a pizza Sorry... to much serious IETF work, i just could not let that opportunity go, but i am sure you could upsell the idea especially to the BIER-WG if you came up with a way how the technology could be abbreviated PIZZA ;-) Please carry on. Toerless On Tue, Nov 09, 2021 at 01:34:47PM +0000, Lizhenbin wrote: > Hi authors of draft-ietf-teas-ietf-network-slices, > > The authors of the draft draft-zzhang-bier-slicing-and-differentiation-00 mentioned in the draft: > " > [I-D.bestbar-teas-ns-packet] introduces the notion of Slice Aggregate > which comprises of one of more IETF network slice traffic streams. A > Slice Aggregate is identified by a Slice Selector (SS), and packets > carry the SS so that associated forwarding treatment or S-PHB (Slice > policy Per Hop Behavior - the externally observable forwarding > behavior applied to a specific packet belonging to a slice aggregate) > - can be applied along the path. > " > " > The authors of this document believe that the IETF Network Slicing > framework, when augmented by the Slice Aggregate, addresses the APN > problem domain very well. > " > > According to the past discussion, we think the slice aggregate means the underlay slice, that is the new terminology "network resource partition". > If so, the Slice Selector should be the identifier of the network resource partition. But according to the draft-zzhang-bier-slicing-and-differentiation-00, > the slice aggregate can be augmented to address the APN problem. In the recently published draft draft-li-apn-header-00, the APN attribute is defined > including the APN ID (user group/application group) the packet belongs to , the Intent and APN parameters applied to the packet. It is apparent these > attributes are totally different from the identifier of the underlay slice. > > Can you clarify the following about the slice aggregate: > 1. What is slice aggregate? Is it the underlay network slice, the APN attribute-like parameters, both or other identifier? Or can it be all possible identifiers to identify a flow? > 2. What is the usage of the slice aggregate in the draft-ietf-teas-ietf-network-slices if it is not the network resource partition any more? Is it introduced a new identifier to identify a flow? > 3. What is the scope of the slice aggregate work in the TEAS WG if it is a new identifier other than the resource partition? Will you go on to define the encapsulation and the > protocol extensions for the new identifier or augment it to address the APN problem? > > > Best Regards, > Robin > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Tue Nov 9 11:41:18 2021 Return-Path: X-Original-To: apn@ietfa.amsl.com Delivered-To: apn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A64F3A102E; Tue, 9 Nov 2021 11:41:17 -0800 (PST) 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 NQEfnH4idoa5; Tue, 9 Nov 2021 11:41:13 -0800 (PST) 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 90DF03A0846; Tue, 9 Nov 2021 11:41:10 -0800 (PST) Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1A9Jf1k7021478; Tue, 9 Nov 2021 19:41:01 GMT Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7CADA4604A; Tue, 9 Nov 2021 19:41:01 +0000 (GMT) Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5D16E46043; Tue, 9 Nov 2021 19:41:01 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs4.iomartmail.com (Postfix) with ESMTPS; Tue, 9 Nov 2021 19:41:01 +0000 (GMT) Received: from LAPTOPK7AS653V ([84.93.2.138]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1A9Jf037010948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Nov 2021 19:41:00 GMT Reply-To: From: "Adrian Farrel" To: "'Lizhenbin'" , Cc: , Date: Tue, 9 Nov 2021 19:41:00 -0000 Organization: Old Dog Consulting Message-ID: <082801d7d5a1$b9d5b380$2d811a80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0829_01D7D5A1.B9D69DE0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AdfVobUfu5fKYYXNS7e7b5Y+B25kqQ== X-Originating-IP: 84.93.2.138 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1018-26520.002 X-TM-AS-Result: No--11.224-10.0-31-10 X-imss-scan-details: No--11.224-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26520.002 X-TMASE-Result: 10--11.224100-10.000000 X-TMASE-MatchedRID: yebcs53SkkDxIbpQ8BhdbPasUbStwoVITf7gOymYF/UG2HMvWEJennKg 3ZCIm2XRU3qDF57pkvxtbcAhYCEabN6wgRkhIxdmlVHM/F6YkvSlY4F8r0vXP2SNz3YOhE6cP7C Sa70XxNSXEeU7bkxKt1SCmfT2v3teYHC1jKwbvyUF5SnBHIsu+iY6ALX8FNLO5EMP7GciAv4Gga FXVN25AdODcwprt0bckmQvAgn/yY/BFC99YaZJBxlJRfzNw8afKQNhMboqZlr/64I/Z3Fs/QvFW mxT0wjkmQvB0TMcuSL4uDILCf1F+i/agNmcw83wDOs94g784geDwntrnEWhGS196sn93sBv9VlG BjCDncjTFeWcNFHhRV7LYHGSSpoCBkffQtrJ8l9ZNYSHk3Zr0cWLeiJW8Z+pqygDDXZjVRN5lcY ctN8+uXvm1fWA4NWX0Sko3nM1nsz64/7yjnFR8wvBTB90+he+qf/efKFN1nBKDB5fXKOhT9kH72 1k1bYD4LFi3GKU1uw5/BzAOjfPJWI3sSM2ArHAIvAdZ4z9ghKTwP20/MuGwRA51mU/clLzlPCV1 PehGgUkVhfzFt0Z1JkV20ZEXVAmR1ElV9YK2TA2R+dF8NaywnVNoFzxmabnQG82tVSByGXFYxBB ONJAzYtXBmhPHqj3AwhI3SAg8iim1xN/3Bsy6T8mh1cI7ZYGYkXignU4RgR0PA/ki2kI7N6xPDq O2Y+uSSTrJqBYoSyv8TAvJrvuV7QJ4oUF56voUgKYbZFF6Gi87rU89eLPKUV2EP27j48EO93iME NTwkWs0EHiNeK3BiLpU+g8w+Z2ZngMhfHTpEieAiCmPx4NwBaLWfA4qcOBmI+faDiwdhpheV+cr sE6IXkaPvbCdntAryis8Dw5zIn4nmGbAXhIuDPRgAPu1ejLv3vKqL2Uhgd5acJMmFW2w3wBp2Pf dDlz70qBipHyu4++8HLBKso7QZPvporKy+uo X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Archived-At: Subject: Re: [Apn] What is Slice Aggregate? X-BeenThere: apn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Application-aware Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 19:41:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0829_01D7D5A1.B9D69DE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Robin, Answering as pen-holder for draft-ietf-teas-ietf-network-slices, but providing a definitive answer for something that might need WG consensus. In line. From: BIER On Behalf Of Lizhenbin Sent: 09 November 2021 13:35 To: teas@ietf.org; apn@ietf.org Cc: bier@ietf.org Subject: [Bier] What is Slice Aggregate? Hi authors of draft-ietf-teas-ietf-network-slices, The authors of the draft draft-zzhang-bier-slicing-and-differentiation-00 mentioned in the draft: " [I-D.bestbar-teas-ns-packet] introduces the notion of Slice Aggregate which comprises of one of more IETF network slice traffic streams. A Slice Aggregate is identified by a Slice Selector (SS), and packets carry the SS so that associated forwarding treatment or S-PHB (Slice policy Per Hop Behavior - the externally observable forwarding behavior applied to a specific packet belonging to a slice aggregate) - can be applied along the path. " " The authors of this document believe that the IETF Network Slicing framework, when augmented by the Slice Aggregate, addresses the APN problem domain very well. " According to the past discussion, we think the slice aggregate means the underlay slice, that is the new terminology "network resource partition". If so, the Slice Selector should be the identifier of the network resource partition. But according to the draft-zzhang-bier-slicing-and-differentiation-00, the slice aggregate can be augmented to address the APN problem. In the recently published draft draft-li-apn-header-00, the APN attribute is defined including the APN ID (user group/application group) the packet belongs to , the Intent and APN parameters applied to the packet. It is apparent these attributes are totally different from the identifier of the underlay slice. Can you clarify the following about the slice aggregate: 1. What is slice aggregate? Is it the underlay network slice, the APN attribute-like parameters, both or other identifier? Or can it be all possible identifiers to identify a flow? I have no specific definition for a "slice aggregate." There is some text on the concept of "aggregating slices" in Section 6.5 of draft-ietf-teas-ietf-network-slices-05. But this is fairly high-level and conceptual acknowledgement that there may be some form of scaling required so that a network is not required to maintain state on every slice service it supports. As far as "identifiers in the underlay network" is concerned, I think that is entirely a choice for the solution. The solution mechanism needs to be able to deliver the high-level functionality that results in the slice service. I think it is likely that some form of "grouping" is needed, but that is not a requirement. If the designers of the solution believe that they have enough identifiers to handle the number of slices, and if they believe that the network can be provisioned and managed, then the solution is practical. In short, the framework does not force the solutions, but the solutions have to be able to deliver the function described in the framework. 2. What is the usage of the slice aggregate in the draft-ietf-teas-ietf-network-slices if it is not the network resource partition any more? Is it introduced a new identifier to identify a flow? As above, the concept of "slice aggregation" is only that: a concept. The text reads. These approaches are also sensitive to the scaling concerns of supporting a large number of IETF Network Slices within a single IP or MPLS network, and so offer ways to aggregate the slices so that the packet markings indicate an aggregate or grouping of IETF Network Slices where all of the packets are subject to the same routing and forwarding behavior. So, in this context, I think you can consider a slice aggregate to be equivalent to a "group" as described in the following text from 6.1 For scalability reasons, IETF Network Slices may be grouped together according to characteristics (including SLOs and SLEs). This grouping allows an operator to host a number of slices on a particular set of resources and so reduce the amount of state information needed in the network. The NSC is responsible for grouping the IETF Network Slice requests. 3. What is the scope of the slice aggregate work in the TEAS WG if it is a new identifier other than the resource partition? Will you go on to define the encapsulation and the protocol extensions for the new identifier or augment it to address the APN problem? I can't answer this question as editor of the framework document. It is a wider question for the working group, I think. Best, Adrian ------=_NextPart_000_0829_01D7D5A1.B9D69DE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Robin,

=  

Answe= ring as pen-holder for draft-ietf-teas-ietf-n= etwork-slices, but providing a definitive answer for something that = might need WG consensus…

 

In = line…

 

From: BIER <bier-bounces@ietf.org> On = Behalf Of Lizhenbin
Sent: 09 November 2021 = 13:35
To: teas@ietf.org; apn@ietf.org
Cc: = bier@ietf.org
Subject: [Bier] What is Slice = Aggregate?

 

Hi authors of = draft-ietf-teas-ietf-network-slices,

 

The authors of the draft = draft-zzhang-bier-slicing-and-differentiation-00 mentioned in the = draft:

   = [I-D.bestbar-teas-ns-packet] introduces the notion of Slice = Aggregate

   which comprises of one = of more IETF network slice traffic streams.  = A

   Slice Aggregate is = identified by a Slice Selector (SS), and packets

   carry the SS so that = associated forwarding treatment or S-PHB (Slice

   policy Per Hop = Behavior - the externally observable forwarding

   behavior applied to a = specific packet belonging to a slice aggregate)

   - can be applied along = the path.

   The authors of this = document believe that the IETF Network Slicing

   framework, when = augmented by the Slice Aggregate, addresses the = APN

   problem domain very = well.

 

According to the past discussion, = we think the slice aggregate means the underlay slice, that is the new = terminology “network resource partition”. =

If so, the Slice Selector should be = the identifier of the network resource partition. But according to the = draft-zzhang-bier-slicing-and-differentiation-00, =

the slice aggregate can be = augmented to address the APN problem. In the recently published draft = draft-li-apn-header-00, the APN attribute is defined =

including the APN ID (user = group/application group) the packet belongs to , the Intent and APN = parameters applied to the packet. It is apparent these =

attributes are totally different = from the identifier of the underlay slice.

 

Can you clarify the following about = the slice aggregate:

1.       = What is slice aggregate? Is it the = underlay network slice, the APN attribute-like parameters, both or other = identifier? Or can it be all possible identifiers to identify a = flow?

 

I = have no specific definition for a “slice aggregate.” There = is some text on the concept of “aggregating slices” in = Section 6.5 of draft-ietf-teas-ietf-network-slices-05. But this is = fairly high-level and conceptual acknowledgement that there may be some = form of scaling required so that a network is not required to maintain = state on every slice service it supports.

=  

As = far as “identifiers in the underlay network” is concerned, I = think that is entirely a choice for the solution. The solution mechanism = needs to be able to deliver the high-level functionality that results in = the slice service. I think it is likely that some form of = “grouping” is needed, but that is not a requirement. If the = designers of the solution believe that they have enough identifiers to = handle the number of slices, and if they believe that the network can be = provisioned and managed, then the solution is practical. =

 

In = short, the framework does not force the solutions, but the solutions = have to be able to deliver the function described in the = framework.

 

2.       = What is the usage of the slice = aggregate in the draft-ietf-teas-ietf-network-slices if it is not the = network resource partition any more? Is it introduced a new identifier = to identify a flow?

 

As = above, the concept of “slice aggregation” is only that: a = concept. The text reads…

=  

 = ;  These approaches are also sensitive to the scaling concerns = of

 = ;  supporting a large number of IETF Network Slices within a single = IP

 = ;  or MPLS network, and so offer ways to aggregate the slices so = that

 = ;  the packet markings indicate an aggregate or grouping of IETF = Network

 = ;  Slices where all of the packets are subject to the same routing = and

 = ;  forwarding behavior.

=  

So, = in this context, I think you can consider a slice aggregate to be = equivalent to a “group” as described in the following text = from 6.1

=  

 = ;  For scalability reasons, IETF Network Slices may be grouped = together

 = ;  according to characteristics (including SLOs and SLEs).  = This

 = ;  grouping allows an operator to host a number of slices on = a

 = ;  particular set of resources and so reduce the amount of = state

 = ;  information needed in the network.  The NSC is responsible = for

 = ;  grouping the IETF Network Slice = requests.

 

3. What is the scope = of the slice aggregate work in the TEAS WG if it is a new identifier = other than the resource partition? Will you go on to define the = encapsulation and the protocol extensions for the new identifier or = augment it to address the APN problem?

 

I = can’t answer this question as editor of the framework document. It = is a wider question for the working group, I = think.

=  

Best,=

Adria= n

 

 

 

 

 

------=_NextPart_000_0829_01D7D5A1.B9D69DE0-- From nobody Sun Nov 14 18:08:50 2021 Return-Path: X-Original-To: apn@ietfa.amsl.com Delivered-To: apn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA9F3A0A49; Sun, 14 Nov 2021 18:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 6BG1qtOZWMum; Sun, 14 Nov 2021 18:08:39 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729293A0AAA; Sun, 14 Nov 2021 18:08:39 -0800 (PST) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Hssvq4kQQz67ZTx; Mon, 15 Nov 2021 10:04:55 +0800 (CST) Received: from dggeml758-chm.china.huawei.com (10.1.199.159) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.20; Mon, 15 Nov 2021 03:08:35 +0100 Received: from dggeml757-chm.china.huawei.com (10.1.199.137) by dggeml758-chm.china.huawei.com (10.1.199.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Mon, 15 Nov 2021 10:08:34 +0800 Received: from dggeml757-chm.china.huawei.com ([10.1.199.137]) by dggeml757-chm.china.huawei.com ([10.1.199.137]) with mapi id 15.01.2308.020; Mon, 15 Nov 2021 10:08:34 +0800 From: "Pengshuping (Peng Shuping)" To: apn CC: "architecture-discuss@iab.org" , "rtgwg@ietf.org" Thread-Topic: APN Summary Report @IETF112 Thread-Index: AdfZxLllIvseZh1mQrqTv/bBIR2LVQ== Date: Mon, 15 Nov 2021 02:08:33 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.181.146] Content-Type: multipart/alternative; boundary="_000_c256aab755e945bd8afe6ecd5d342176huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Apn] APN Summary Report @IETF112 X-BeenThere: apn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Application-aware Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 02:08:44 -0000 --_000_c256aab755e945bd8afe6ecd5d342176huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Thank you very much for your interest in APN. We have finished the presenta= tions and discussions in IETF 112. Below please find a summary report on th= e APN @IETF112. Hope it accurately captured the meeting and the progress ma= de. Please let us know if you have any comments and suggestions. Thank you! The suggestions we received from the BoF @IETF111 are as follows, "... write an I-D with one specific use case and data plane technology, and= see if are able to understand how APN would work in this scenario." Based on the suggestions above, the team made an effort to update two key d= rafts (to focus on and clarify one specific use case to help people underst= and how APN would work in this scenario) and publish four new drafts (inclu= ding the data plane technology) to try to address the understanding gaps be= tween the proponents and the community. Moreover, a dedicated slot was requ= ested and allocated in the RTGWG to present an update of the work and addre= ss open issues. The agenda for the APN presentations in the RTGWG is as follows. 25 mins we= re allocated. For each following draft, its goals and the changes made as w= ell as the comments received are elaborated in details below. 1. Updates to the existing drafts APN Framework and Gap Analysis updates Gyan Mishra/Shuping Peng https://datatracker.ietf.org/doc/draft-li-apn-framework/ Changes made: Two new sections are added, section 6 illustration to explain= an exact use case covering how APN is applied in this use case in terms of= the APN ID tagging and the example for policy mapping according to the APN= ID. The benefits of APN are also presented in section 7. https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis/ Changes made: Several existing IDs were added and compared with APN ID. A s= ummary table is presented in the draft. Comments received: Rick Taylor believed that APN is a really important work= and it will be great to have it standardized so he could use the standardi= zed solution in his network. The communications in the chat box is copied and pasted. FYI. @gyan - this is really important work. You're right about QoS being the de-= facto alternative01:33:08 Gyan Mishra @Rick, Thank you. Yes QOS has been the defacto standard for decades and it = will be around I think forever for IP SLA. What APN does is quite unique as= it takes QOS and Diff-Serv TE etc to the next level being able to classify= traffic with flow based granularity which fits perfect into SR intent base= d stateless architecture where micro and macro steering can now occur at th= e APN head end mapping flows to discrete SR-TE instantiated paths. This avo= ids any hardware DPI and would provide more efficient use of hardware resou= rces as the APN ID is in the outer payload encapsulation so don't have to g= o deep into the payload for classification / path instantiation as well as = for IOAM for example classification / path instantiation. Thank you Rick Taylor @Gyan - thanks - I do understand. Annoyingly I have had to use custom IP op= tion headers within my private networks to achieve the same thing for years= . It will be great to see this standardised and then I can drop my hacks. Gyan Mishra @Rick, Excellent and many thanks for your support on this work. One more comment was received. 1) The flow in APN work indicates a single flow or a group of flows. Answer: It could be both. The granularity of APN is flexible. 2. New drafts published APN Header and IPv6 Encapsulation Robin Li https://datatracker.ietf.org/doc/draft-li-apn-header/ https://datatracker.ietf.org/doc/draft-li-apn-ipv6-encap/ Goals: These two drafts define the APN header and its encapsulation in IPv6= data plane. APN FlowSpec and YANG Shuping Peng https://datatracker.ietf.org/doc/draft-peng-apn-bgp-flowspec/ https://datatracker.ietf.org/doc/draft-peng-apn-yang/ Goals: These two drafts define the control plane Flow specification mechani= sms for APN and the management control YANG model. It aims to show how the = APN policy can be configured. The other comment was received. 2) The purpose of the APN parameters are better to clarify in the mail= ing list. Answer: It has been addressed in the draft. The APN Para is optional. We wi= ll further address these comments in the mailing list. In summary, it seems that the APN presentations were well received. No more= strong challenges were received. One clear support was received during the= meeting which is great. The authors will continue the work and progress it= further. We plan to close the comments we received from the BoF in the mai= ling list. Your suggestions and comments are always very welcomed. Best Regards, Shuping From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Pengshuping (Peng Shup= ing) Sent: Tuesday, October 26, 2021 9:31 AM To: apn Subject: [Apn] The APN drafts updated and published Dear all, We have updated the following drafts and published some new drafts as follo= ws. Your reviews and comments are very welcomed. Thank you! Drafts updated: 1. APN Framework https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04 An illustration section is added with an example use case described. The be= nefits of using APN is also introduced. 2. Gap Analysis updates https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis-03 The solution gap analysis section is updated with more existing IDs analyze= d and compared. A comparison table is added in the Summary sub-section. 3. APN Use case https://datatracker.ietf.org/doc/html/draft-yang-apn-sd-wan-usecase-03 The APN with iOAM is added as a new section. New drafts published: 4. APN Header https://datatracker.ietf.org/doc/html/draft-li-apn-header-00 This document defines the application-aware networking (APN) header which c= an be used in the different data planes. 5. IPv6 Encapsulation https://datatracker.ietf.org/doc/html/draft-li-apn-ipv6-encap-00 This document defines the encapsulation of the APN header in the IPv6 data = plane. 6. APN FlowSpec https://datatracker.ietf.org/doc/html/draft-peng-apn-bgp-flowspec-00 This document specifies a new BGP Flow Spec Component Type in order to supp= ort APN traffic filtering. The match field is the APN ID. It also specifies= traffic filtering actions to enable the creation of the APN ID in the oute= r tunnel encapsulation when matched to the corresponding Flow Spec rules. 7. APN YANG https://datatracker.ietf.org/doc/html/draft-peng-apn-yang-00 This document defines a YANG module for APN. Thank you! Best Regards, Shuping --_000_c256aab755e945bd8afe6ecd5d342176huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Thank you very much for your in= terest in APN. We have finished the presentations and discussions in IETF 1= 12. Below please find a summary report on the APN @IETF112. Hope it accurat= ely captured the meeting and the progress made. Please let us know if you have any comments and suggestions. Thank y= ou!

 

The suggestions we received fro= m the BoF @IETF111 are as follows,

“… write an I-D wit= h one specific use case and data plane technology, and see if are able to understand how APN wou= ld work in this scenario.”

 

Based on the suggestions above,= the team made an effort to update two key drafts (to focus on and clarify = one specific use case to help people understand how APN would work in this = scenario) and publish four new drafts (including the data plane technology) to try to address the understanding = gaps between the proponents and the community. Moreover, a dedicated slot w= as requested and allocated in the RTGWG to present an update of the work an= d address open issues.

 

The agenda for the APN presenta= tions in the RTGWG is as follows. 25 mins were allocated. For each followin= g draft, its goals and the changes made as well as the comments received ar= e elaborated in details below.

1= .   &= nbsp;  Updates to the existing= drafts

   APN Framework and = Gap Analysis updates

   Gyan Mishra/Shupin= g Peng

   https://datatracker.ietf.org/doc/draft-li-apn-framework/

Changes made: Two new sections = are added, section 6 illustration to explain an exact use case covering how= APN is applied in this use case in terms of the APN ID tagging and the exa= mple for policy mapping according to the APN ID. The benefits of APN are also presented in section 7.

   https://datatracker.ietf.org/doc/draft-peng-apn-scop= e-gap-analysis/

Changes made: Several existing = IDs were added and compared with APN ID. A summary table is presented in th= e draft.

 

Comments received: Rick Taylor = believed that APN is a really important work and it will be great to have i= t standardized so he could use the standardized solution in his network.

 

The communications in the chat = box is copied and pasted. FYI.

@gyan - this is really importan= t work. You're right about QoS being the de-facto alternative01:33:08<= /o:p>

Gyan Mishra

@Rick, Thank you. Yes QOS has b= een the defacto standard for decades and it will be around I think forever = for IP SLA. What APN does is quite unique as it takes QOS and Diff-Serv TE = etc to the next level being able to classify traffic with flow based granularity which fits perfect into SR in= tent based stateless architecture where micro and macro steering can now oc= cur at the APN head end mapping flows to discrete SR-TE instantiated paths.= This avoids any hardware DPI and would provide more efficient use of hardware resources as the APN ID is in= the outer payload encapsulation so don't have to go deep into the payload = for classification / path instantiation as well as for IOAM for example cla= ssification / path instantiation. Thank you

Rick Taylor

@Gyan - thanks - I do understan= d. Annoyingly I have had to use custom IP option headers within my private = networks to achieve the same thing for years. It will be great to see this = standardised and then I can drop my hacks.

Gyan Mishra

@Rick, Excellent and many thank= s for your support on this work.

 

One more comment was received. =

1= )   &= nbsp;  The flow in APN work in= dicates a single flow or a group of flows.

Answer: It could be both. The g= ranularity of APN is flexible.

 

2= .   &= nbsp;  New drafts published

AP= N Header and IPv6 Encapsulation

   Robin Li=

   https://datatracker.ietf.org/doc/draft-li-apn-header/

   https://datatracker.ietf.org/doc/draft-li-apn-ipv6-encap/<= /span>

Goals: These two drafts define = the APN header and its encapsulation in IPv6 data plane.

 

AP= N FlowSpec and YANG

   Shuping Peng<= /o:p>

   https://datatracker.ietf.org/doc/draft-peng-apn-bgp-flowspec/=

   https://datatracker.ietf.org/doc/draft-peng-apn-yang/

Goals: These two drafts define = the control plane Flow specification mechanisms for APN and the management = control YANG model. It aims to show how the APN policy can be configured.

 

The other comment was received.=

2= )   &= nbsp;  The purpose of the APN = parameters are better to clarify in the mailing list.

Answer: It has been addressed i= n the draft. The APN Para is optional. We will further address these commen= ts in the mailing list.

 

In summary, it seems that the A= PN presentations were well received. No more strong challenges were receive= d. One clear support was received during the meeting which is great. The au= thors will continue the work and progress it further. We plan to close the comments we received from the BoF in the = mailing list. Your suggestions and comments are always very welcomed.

 

Best Regards,

Shuping

&n= bsp;

&n= bsp;

&n= bsp;

From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Pengshuping (Peng Shuping)
Sent: Tuesday, October 26, 2021 9:31 AM
To: apn <apn@ietf.org>
Subject: [Apn] The APN drafts updated and published

 

Dear all,

 

We have updated the following d= rafts and published some new drafts as follows.

Your reviews and comments are v= ery welcomed. Thank you!

 

Drafts updated:

 

1= .   &= nbsp;  APN Framework

= https://datatracker.ietf.org/doc/html/draft-li-apn-fr= amework-04

= An illustration section is added with an example use c= ase described. The benefits of using APN is also introduced.

=  

2= .   &= nbsp;  Gap Analysis updates

= https://datatracker.ietf.org/doc/html/draf= t-peng-apn-scope-gap-analysis-03

= The solution gap analysis section is updated with more= existing IDs analyzed and compared. A comparison table is added in the Sum= mary sub-section.

=  

3= .   &= nbsp;  APN Use case

= https://datatracker.ietf.org/doc/html/draft-ya= ng-apn-sd-wan-usecase-03

= The APN with iOAM is added as a new section.

 

New drafts published:

 

4= .   &= nbsp;  APN Header

= https://datatracker.ietf.org/doc/html/draft-li-apn-heade= r-00

= This document defines the application-aware networking= (APN) header which can be used in the different data planes.

=  

5= .   &= nbsp;  IPv6 Encapsulation

= https://datatracker.ietf.org/doc/html/draft-li-apn-i= pv6-encap-00

= This document defines the encapsulation of the APN hea= der in the IPv6 data plane.

=  

6= .   &= nbsp;  APN FlowSpec

= https://datatracker.ietf.org/doc/html/draft-peng= -apn-bgp-flowspec-00

= This document specifies a new BGP Flow Spec Component = Type in order to support APN traffic filtering. The match field is the APN = ID. It also specifies traffic filtering actions to enable the creation of the APN ID in the outer tunnel encapsula= tion when matched to the corresponding Flow Spec rules.

=  

7= .   &= nbsp;  APN YANG

= https://datatracker.ietf.org/doc/html/draft-peng-apn-yan= g-00

= This document defines a YANG module for APN.

 

Thank you!

 

Best Regards,

Shuping

--_000_c256aab755e945bd8afe6ecd5d342176huaweicom_-- From nobody Thu Nov 25 08:13:12 2021 Return-Path: X-Original-To: apn@ietfa.amsl.com Delivered-To: apn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2570D3A0B11; Thu, 25 Nov 2021 08:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 V-AxKLl_M_q7; Thu, 25 Nov 2021 08:13:05 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6053A0B53; Thu, 25 Nov 2021 08:13:05 -0800 (PST) Received: from fraeml704-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4J0NF85QL3z67nKm; Fri, 26 Nov 2021 00:12:28 +0800 (CST) Received: from dggpemm500008.china.huawei.com (7.185.36.136) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Thu, 25 Nov 2021 17:13:01 +0100 Received: from dggpemm500008.china.huawei.com (7.185.36.136) by dggpemm500008.china.huawei.com (7.185.36.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 26 Nov 2021 00:13:00 +0800 Received: from dggpemm500008.china.huawei.com ([7.185.36.136]) by dggpemm500008.china.huawei.com ([7.185.36.136]) with mapi id 15.01.2308.020; Fri, 26 Nov 2021 00:12:59 +0800 From: Lizhenbin To: "adrian@olddog.co.uk" , "teas@ietf.org" CC: "bier@ietf.org" , "apn@ietf.org" , "draft-bestbar-teas-ns-packet@ietf.org" Thread-Topic: What is Slice Aggregate? Thread-Index: AdfVobUfsrCLw1hUQOmhZ9vm12TKQgMdWj8w Date: Thu, 25 Nov 2021 16:12:59 +0000 Message-ID: References: <082801d7d5a1$b9d5b380$2d811a80$@olddog.co.uk> In-Reply-To: <082801d7d5a1$b9d5b380$2d811a80$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.231.177] Content-Type: multipart/alternative; boundary="_000_c87ccb8111cf4dffab15b0d483608ebehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Apn] What is Slice Aggregate? X-BeenThere: apn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Application-aware Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 16:13:10 -0000 --_000_c87ccb8111cf4dffab15b0d483608ebehuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, I am a little sorry that my question should have been for the co-authors of= draft-bestbar-teas-ns-packet instead of you. Best Regards, Robin From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, November 10, 2021 3:41 AM To: Lizhenbin ; teas@ietf.org Cc: bier@ietf.org; apn@ietf.org Subject: RE: What is Slice Aggregate? Hi Robin, Answering as pen-holder for draft-ietf-teas-ietf-network-slices, but provid= ing a definitive answer for something that might need WG consensus... In line... From: BIER > On Behalf = Of Lizhenbin Sent: 09 November 2021 13:35 To: teas@ietf.org; apn@ietf.org Cc: bier@ietf.org Subject: [Bier] What is Slice Aggregate? Hi authors of draft-ietf-teas-ietf-network-slices, The authors of the draft draft-zzhang-bier-slicing-and-differentiation-00 m= entioned in the draft: " [I-D.bestbar-teas-ns-packet] introduces the notion of Slice Aggregate which comprises of one of more IETF network slice traffic streams. A Slice Aggregate is identified by a Slice Selector (SS), and packets carry the SS so that associated forwarding treatment or S-PHB (Slice policy Per Hop Behavior - the externally observable forwarding behavior applied to a specific packet belonging to a slice aggregate) - can be applied along the path. " " The authors of this document believe that the IETF Network Slicing framework, when augmented by the Slice Aggregate, addresses the APN problem domain very well. " According to the past discussion, we think the slice aggregate means the un= derlay slice, that is the new terminology "network resource partition". If so, the Slice Selector should be the identifier of the network resource = partition. But according to the draft-zzhang-bier-slicing-and-differentiati= on-00, the slice aggregate can be augmented to address the APN problem. In the rec= ently published draft draft-li-apn-header-00, the APN attribute is defined including the APN ID (user group/application group) the packet belongs to ,= the Intent and APN parameters applied to the packet. It is apparent these attributes are totally different from the identifier of the underlay slice. Can you clarify the following about the slice aggregate: 1. What is slice aggregate? Is it the underlay network slice, the APN= attribute-like parameters, both or other identifier? Or can it be all poss= ible identifiers to identify a flow? I have no specific definition for a "slice aggregate." There is some text o= n the concept of "aggregating slices" in Section 6.5 of draft-ietf-teas-iet= f-network-slices-05. But this is fairly high-level and conceptual acknowled= gement that there may be some form of scaling required so that a network is= not required to maintain state on every slice service it supports. As far as "identifiers in the underlay network" is concerned, I think that = is entirely a choice for the solution. The solution mechanism needs to be a= ble to deliver the high-level functionality that results in the slice servi= ce. I think it is likely that some form of "grouping" is needed, but that i= s not a requirement. If the designers of the solution believe that they hav= e enough identifiers to handle the number of slices, and if they believe th= at the network can be provisioned and managed, then the solution is practic= al. In short, the framework does not force the solutions, but the solutions hav= e to be able to deliver the function described in the framework. 2. What is the usage of the slice aggregate in the draft-ietf-teas-ie= tf-network-slices if it is not the network resource partition any more? Is = it introduced a new identifier to identify a flow? As above, the concept of "slice aggregation" is only that: a concept. The t= ext reads... These approaches are also sensitive to the scaling concerns of supporting a large number of IETF Network Slices within a single IP or MPLS network, and so offer ways to aggregate the slices so that the packet markings indicate an aggregate or grouping of IETF Network Slices where all of the packets are subject to the same routing and forwarding behavior. So, in this context, I think you can consider a slice aggregate to be equiv= alent to a "group" as described in the following text from 6.1 For scalability reasons, IETF Network Slices may be grouped together according to characteristics (including SLOs and SLEs). This grouping allows an operator to host a number of slices on a particular set of resources and so reduce the amount of state information needed in the network. The NSC is responsible for grouping the IETF Network Slice requests. 3. What is the scope of the slice aggregate work in the TEAS WG if it is a = new identifier other than the resource partition? Will you go on to define = the encapsulation and the protocol extensions for the new identifier or aug= ment it to address the APN problem? I can't answer this question as editor of the framework document. It is a w= ider question for the working group, I think. Best, Adrian --_000_c87ccb8111cf4dffab15b0d483608ebehuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adri= an,

I am a = little sorry that my question should have been for the co-authors of draft-= bestbar-teas-ns-packet instead of you.

&n= bsp;

Best Re= gards,

Robin

&n= bsp;

&n= bsp;

 

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, November 10, 2021 3:41 AM
To: Lizhenbin <lizhenbin@huawei.com>; teas@ietf.org
Cc: bier@ietf.org; apn@ietf.org
Subject: RE: What is Slice Aggregate?

 

Hi Robin,

 

Answering as pen-holder for draft-ietf-teas-ietf-ne= twork-slices, but providing a definitive answer for something that might ne= ed WG consensus…

&n= bsp;

In line= …

 

From: BIER <bier-bounces@ietf.org> On Behalf Of Lizhenbin
Sent: 09 November 2021 13:35
To: teas@ietf.org; apn@ietf.org
Cc: bier@ietf.org
Subject: [Bier] What is Slice Aggregate?

 

Hi authors of draft-ietf-teas-i= etf-network-slices,

 

The authors of the draft draft-= zzhang-bier-slicing-and-differentiation-00 mentioned in the draft:

   [I-D.bestbar-teas-= ns-packet] introduces the notion of Slice Aggregate

   which comprises of= one of more IETF network slice traffic streams.  A<= /p>

   Slice Aggregate is= identified by a Slice Selector (SS), and packets

   carry the SS so th= at associated forwarding treatment or S-PHB (Slice

   policy Per Hop Beh= avior - the externally observable forwarding

   behavior applied t= o a specific packet belonging to a slice aggregate)

   - can be applied a= long the path.

   The authors of thi= s document believe that the IETF Network Slicing

   framework, when au= gmented by the Slice Aggregate, addresses the APN

   problem domain ver= y well.

 

According to the past discussio= n, we think the slice aggregate means the underlay slice, that is the new t= erminology “network resource partition”.

If so, the Slice Selector shoul= d be the identifier of the network resource partition. But according to the= draft-zzhang-bier-slicing-and-differentiation-00,

the slice aggregate can be augm= ented to address the APN problem. In the recently published draft draft-li-= apn-header-00, the APN attribute is defined

including the APN ID (user grou= p/application group) the packet belongs to , the Intent and APN parameters = applied to the packet. It is apparent these

attributes are totally differen= t from the identifier of the underlay slice.

 

Can you clarify the following a= bout the slice aggregate:

1= .   &= nbsp;   What is slice aggregate= ? Is it the underlay network slice, the APN attribute-like parameters, both= or other identifier? Or can it be all possible identifiers to identify a f= low?

 

I have no specific definition for a “slice aggregate.”= ; There is some text on the concept of “aggregating slices” in = Section 6.5 of draft-ietf-teas-ietf-network-slices-05. But this is fairly high-level and conceptual acknowledgement that there may be some= form of scaling required so that a network is not required to maintain sta= te on every slice service it supports.

 

As far as “identifiers in the underlay network” is co= ncerned, I think that is entirely a choice for the solution. The solution m= echanism needs to be able to deliver the high-level functionality that results in the slice service. I think it is likely that= some form of “grouping” is needed, but that is not a requireme= nt. If the designers of the solution believe that they have enough identifi= ers to handle the number of slices, and if they believe that the network can be provisioned and managed, then the solution= is practical.

 

In short, the framework does not force the solutions, but the sol= utions have to be able to deliver the function described in the framework.<= o:p>

 

2= .   &= nbsp;   What is the usage of th= e slice aggregate in the draft-ietf-teas-ietf-network-slices if it is not t= he network resource partition any more? Is it introduced a new identifier t= o identify a flow?

 

As above, the concept of “slice aggregation” is only = that: a concept. The text reads…

 

   These approaches are also sensitive to the scaling c= oncerns of

   supporting a large number of IETF Network Slices wit= hin a single IP

   or MPLS network, and so offer ways to aggregate the = slices so that

   the packet markings indicate an aggregate or groupin= g of IETF Network

   Slices where all of the packets are subject to the s= ame routing and

   forwarding behavior.

 

So, in this context, I think you can consider a slice aggregate t= o be equivalent to a “group” as described in the following text= from 6.1

 

   For scalability reasons, IETF Network Slices may be = grouped together

   according to characteristics (including SLOs and SLE= s).  This

   grouping allows an operator to host a number of slic= es on a

   particular set of resources and so reduce the amount= of state

   information needed in the network.  The NSC is = responsible for

   grouping the IETF Network Slice requests.=

 

3.= What is the scope of the slice aggregate work in the TEAS WG if it is a ne= w identifier other than the resource partition? Will you go on to define th= e encapsulation and the protocol extensions for the new identifier or augment it to address the APN problem?

 

I can’t answer this question as editor of the framework doc= ument. It is a wider question for the working group, I think.

 

Best,

Adrian

 

 

 

 

 

--_000_c87ccb8111cf4dffab15b0d483608ebehuaweicom_-- From nobody Thu Nov 25 08:14:45 2021 Return-Path: X-Original-To: apn@ietfa.amsl.com Delivered-To: apn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D733A0B25; Thu, 25 Nov 2021 08:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 mq8IIIsZ3E4V; Thu, 25 Nov 2021 08:14:39 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3693A0B2F; Thu, 25 Nov 2021 08:14:39 -0800 (PST) Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4J0NBz2bQbz67ZDL; Fri, 26 Nov 2021 00:10:35 +0800 (CST) Received: from dggpemm100007.china.huawei.com (7.185.36.116) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 25 Nov 2021 17:14:30 +0100 Received: from dggpemm500008.china.huawei.com (7.185.36.136) by dggpemm100007.china.huawei.com (7.185.36.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 26 Nov 2021 00:14:28 +0800 Received: from dggpemm500008.china.huawei.com ([7.185.36.136]) by dggpemm500008.china.huawei.com ([7.185.36.136]) with mapi id 15.01.2308.020; Fri, 26 Nov 2021 00:14:28 +0800 From: Lizhenbin To: "draft-bestbar-teas-ns-packet@ietf.org" , "teas@ietf.org" CC: "apn@ietf.org" , "bier@ietf.org" Thread-Topic: What is Slice-Flow Aggregate? Thread-Index: AdfiFkWucgGciKb+SMKdeZrfklHfhw== Date: Thu, 25 Nov 2021 16:14:28 +0000 Message-ID: <12f10e42b0d0489c9130bf3395d1e6d5@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.231.177] Content-Type: multipart/alternative; boundary="_000_12f10e42b0d0489c9130bf3395d1e6d5huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Apn] What is Slice-Flow Aggregate? X-BeenThere: apn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Application-aware Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 16:14:44 -0000 --_000_12f10e42b0d0489c9130bf3395d1e6d5huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi authors of draft-bestbar-teas-ns-packet, Thanks for updating the terminologies based on the comments and suggestions= made during the meeting and the mail list. While there are still several = thing which are not clear to me: 1. The term Slice Aggregate is now changed to Slice Flow Aggregate to= reflect that it is the aggregation of a set of network flows. This term ma= y help the description of the mapping of network slice services to the unde= rlay network resource partition. However, it is not clear whether this conc= ept is needed or related to the realization of the network resource partiti= on. Also it is not clear whether the identifier of Slice Flow Aggregate in = data packet is needed. 2. If the Slice-Flow Aggregate is the aggregation of network flows, w= hat is the meaning of the term "Slice-Flow Aggregate Topology" in section 3= .4? Is it the topology associated with the underlay network construct? Or i= s it something related to the connectivity matrix? IMHO this updated terminology is still confusing about what is the attribut= e of the service flows, and what is the attribute of the underlay network c= onstruct. They are still mixed up. Moreover, based on the mail list discussion, the consensus is to use genera= l terms instead of slice specific terms in the network slice realization, p= lease consider to follow that Best regards, Robin From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, November 10, 2021 3:41 AM To: Lizhenbin ; teas@ietf.org Cc: bier@ietf.org; apn@ietf.org Subject: RE: What is Slice Aggregate? Hi Robin, Answering as pen-holder for draft-ietf-teas-ietf-network-slices, but provid= ing a definitive answer for something that might need WG consensus... In line... From: BIER > On Behalf = Of Lizhenbin Sent: 09 November 2021 13:35 To: teas@ietf.org; apn@ietf.org Cc: bier@ietf.org Subject: [Bier] What is Slice Aggregate? Hi authors of draft-ietf-teas-ietf-network-slices, The authors of the draft draft-zzhang-bier-slicing-and-differentiation-00 m= entioned in the draft: " [I-D.bestbar-teas-ns-packet] introduces the notion of Slice Aggregate which comprises of one of more IETF network slice traffic streams. A Slice Aggregate is identified by a Slice Selector (SS), and packets carry the SS so that associated forwarding treatment or S-PHB (Slice policy Per Hop Behavior - the externally observable forwarding behavior applied to a specific packet belonging to a slice aggregate) - can be applied along the path. " " The authors of this document believe that the IETF Network Slicing framework, when augmented by the Slice Aggregate, addresses the APN problem domain very well. " According to the past discussion, we think the slice aggregate means the un= derlay slice, that is the new terminology "network resource partition". If so, the Slice Selector should be the identifier of the network resource = partition. But according to the draft-zzhang-bier-slicing-and-differentiati= on-00, the slice aggregate can be augmented to address the APN problem. In the rec= ently published draft draft-li-apn-header-00, the APN attribute is defined including the APN ID (user group/application group) the packet belongs to ,= the Intent and APN parameters applied to the packet. It is apparent these attributes are totally different from the identifier of the underlay slice. Can you clarify the following about the slice aggregate: 1. What is slice aggregate? Is it the underlay network slice, the APN= attribute-like parameters, both or other identifier? Or can it be all poss= ible identifiers to identify a flow? I have no specific definition for a "slice aggregate." There is some text o= n the concept of "aggregating slices" in Section 6.5 of draft-ietf-teas-iet= f-network-slices-05. But this is fairly high-level and conceptual acknowled= gement that there may be some form of scaling required so that a network is= not required to maintain state on every slice service it supports. As far as "identifiers in the underlay network" is concerned, I think that = is entirely a choice for the solution. The solution mechanism needs to be a= ble to deliver the high-level functionality that results in the slice servi= ce. I think it is likely that some form of "grouping" is needed, but that i= s not a requirement. If the designers of the solution believe that they hav= e enough identifiers to handle the number of slices, and if they believe th= at the network can be provisioned and managed, then the solution is practic= al. In short, the framework does not force the solutions, but the solutions hav= e to be able to deliver the function described in the framework. 2. What is the usage of the slice aggregate in the draft-ietf-teas-ie= tf-network-slices if it is not the network resource partition any more? Is = it introduced a new identifier to identify a flow? As above, the concept of "slice aggregation" is only that: a concept. The t= ext reads... These approaches are also sensitive to the scaling concerns of supporting a large number of IETF Network Slices within a single IP or MPLS network, and so offer ways to aggregate the slices so that the packet markings indicate an aggregate or grouping of IETF Network Slices where all of the packets are subject to the same routing and forwarding behavior. So, in this context, I think you can consider a slice aggregate to be equiv= alent to a "group" as described in the following text from 6.1 For scalability reasons, IETF Network Slices may be grouped together according to characteristics (including SLOs and SLEs). This grouping allows an operator to host a number of slices on a particular set of resources and so reduce the amount of state information needed in the network. The NSC is responsible for grouping the IETF Network Slice requests. 3. What is the scope of the slice aggregate work in the TEAS WG if it is a = new identifier other than the resource partition? Will you go on to define = the encapsulation and the protocol extensions for the new identifier or aug= ment it to address the APN problem? I can't answer this question as editor of the framework document. It is a w= ider question for the working group, I think. Best, Adrian --_000_12f10e42b0d0489c9130bf3395d1e6d5huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi authors of draft-bestbar-tea= s-ns-packet,

&n= bsp;

Thanks for updating the termino= logies based on the comments and suggestions made during the meeting and th= e mail list.  While there are still several thing which are not clear = to me:

 

1= .   &= nbsp;   The term Slice Aggregat= e is now changed to Slice Flow Aggregate to reflect that it is the aggregat= ion of a set of network flows. This term may help the description of the ma= pping of network slice services to the underlay network resource partition. However, it is not clear whether = this concept is needed or related to the realization of the network resourc= e partition. Also it is not clear whether the identifier of Slice Flow Aggr= egate in data packet is needed.

=  

2= .   &= nbsp;   If the Slice-Flow Aggre= gate is the aggregation of network flows, what is the meaning of the term &= #8220;Slice-Flow Aggregate Topology” in section 3.4? Is it the topolo= gy associated with the underlay network construct? Or is it something related to the connectivity matrix? <= /p>

 =

IMHO this updated terminology i= s still confusing about what is the attribute of the service flows, and wha= t is the attribute of the underlay network construct. They are still mixed = up.

 

Moreover, based on the mail lis= t discussion, the consensus is to use general terms instead of slice specif= ic terms in the network slice realization, please consider to follow that

 

 

Best regards,=

Robin

&n= bsp;

&n= bsp;

&n= bsp;

 

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, November 10, 2021 3:41 AM
To: Lizhenbin <lizhenbin@huawei.com>; teas@ietf.org
Cc: bier@ietf.org; apn@ietf.org
Subject: RE: What is Slice Aggregate?

 

Hi Robin,

 

Answering as pen-holder for draft-ietf-teas-ietf-ne= twork-slices, but providing a definitive answer for something that might ne= ed WG consensus…

&n= bsp;

In line= …

 

From: BIER <bier-bounces@ietf.org> On Behalf Of Lizhenbin
Sent: 09 November 2021 13:35
To: teas@ietf.org; apn@ietf.org
Cc: bier@ietf.org
Subject: [Bier] What is Slice Aggregate?

 

Hi authors of draft-ietf-teas-i= etf-network-slices,

 

The authors of the draft draft-= zzhang-bier-slicing-and-differentiation-00 mentioned in the draft:

   [I-D.bestbar-teas-= ns-packet] introduces the notion of Slice Aggregate

   which comprises of= one of more IETF network slice traffic streams.  A<= /p>

   Slice Aggregate is= identified by a Slice Selector (SS), and packets

   carry the SS so th= at associated forwarding treatment or S-PHB (Slice

   policy Per Hop Beh= avior - the externally observable forwarding

   behavior applied t= o a specific packet belonging to a slice aggregate)

   - can be applied a= long the path.

   The authors of thi= s document believe that the IETF Network Slicing

   framework, when au= gmented by the Slice Aggregate, addresses the APN

   problem domain ver= y well.

 

According to the past discussio= n, we think the slice aggregate means the underlay slice, that is the new t= erminology “network resource partition”.

If so, the Slice Selector shoul= d be the identifier of the network resource partition. But according to the= draft-zzhang-bier-slicing-and-differentiation-00,

the slice aggregate can be augm= ented to address the APN problem. In the recently published draft draft-li-= apn-header-00, the APN attribute is defined

including the APN ID (user grou= p/application group) the packet belongs to , the Intent and APN parameters = applied to the packet. It is apparent these

attributes are totally differen= t from the identifier of the underlay slice.

 

Can you clarify the following a= bout the slice aggregate:

1= .   &= nbsp;   What is slice aggregate= ? Is it the underlay network slice, the APN attribute-like parameters, both= or other identifier? Or can it be all possible identifiers to identify a f= low?

 

I have no specific definition for a “slice aggregate.”= ; There is some text on the concept of “aggregating slices” in = Section 6.5 of draft-ietf-teas-ietf-network-slices-05. But this is fairly high-level and conceptual acknowledgement that there may be some= form of scaling required so that a network is not required to maintain sta= te on every slice service it supports.

 

As far as “identifiers in the underlay network” is co= ncerned, I think that is entirely a choice for the solution. The solution m= echanism needs to be able to deliver the high-level functionality that results in the slice service. I think it is likely that= some form of “grouping” is needed, but that is not a requireme= nt. If the designers of the solution believe that they have enough identifi= ers to handle the number of slices, and if they believe that the network can be provisioned and managed, then the solution= is practical.

 

In short, the framework does not force the solutions, but the sol= utions have to be able to deliver the function described in the framework.<= o:p>

 

2= .   &= nbsp;   What is the usage of th= e slice aggregate in the draft-ietf-teas-ietf-network-slices if it is not t= he network resource partition any more? Is it introduced a new identifier t= o identify a flow?

 

As above, the concept of “slice aggregation” is only = that: a concept. The text reads…

 

   These approaches are also sensitive to the scaling c= oncerns of

   supporting a large number of IETF Network Slices wit= hin a single IP

   or MPLS network, and so offer ways to aggregate the = slices so that

   the packet markings indicate an aggregate or groupin= g of IETF Network

   Slices where all of the packets are subject to the s= ame routing and

   forwarding behavior.

 

So, in this context, I think you can consider a slice aggregate t= o be equivalent to a “group” as described in the following text= from 6.1

 

   For scalability reasons, IETF Network Slices may be = grouped together

   according to characteristics (including SLOs and SLE= s).  This

   grouping allows an operator to host a number of slic= es on a

   particular set of resources and so reduce the amount= of state

   information needed in the network.  The NSC is = responsible for

   grouping the IETF Network Slice requests.=

 

3.= What is the scope of the slice aggregate work in the TEAS WG if it is a ne= w identifier other than the resource partition? Will you go on to define th= e encapsulation and the protocol extensions for the new identifier or augment it to address the APN problem?

 

I can’t answer this question as editor of the framework doc= ument. It is a wider question for the working group, I think.

 

Best,

Adrian

 

 

 

 

 

--_000_12f10e42b0d0489c9130bf3395d1e6d5huaweicom_--