Subject: Re: [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 1 Oct 2021 12:30:54 +0200

Hi Kenichi,

I don’t see the requirement to use different topologies for the classes below. All classes can be delivered on the same topology. Overcomplicating it will bring deployment challenges, and thus will not be widely deployed (like e.g. DS-TE, which is overcomplicated, and thus not widely used).

Thanks,
Krzysztof

> On 2021 -Sep-30, at 03:18, Ogaki, Kenichi <[email-masked]> wrote:
> 
> Hi Adrian and all,
> 
> Could you clarify the relationship between IETF Network Slice, Network Resource Partitioning and Filter Topology?
> 
> We are discussing about multiple sets of SLOs/SLEs per slice mainly with Krzysztof on Issue #2 thread.
> 
> For example, when we assign an IETF Network Slice to an Network Resource Partitioning, multiple connectivity matrices with each SLO/SLE inside the Network Resource Partitioning is fine. This is just a terminology issue.
> However, Krzysztof's following SLO/SLE's examples definitely require even different Filter Topology, especially for the 3rd one.
> #We can create a rich Filter Topology covering all three sets of SLOs/SLEs, but we usually don't do so.
> 
>> 1: Conversational Voice, latency 100 ms, 10 Mbps
>> 76: Live Uplink Streaming, latency 500 ms, 100 Mbps
>> 80: Low latency eMBB applications (TCP/UDP-based); Augmented Reality, Latency 10 ms, 1 Gbps
> 
> From your figure, that part is owned by the provider inside Controller View. So, if it's up to each provider's service, it's OK.
> 
> Thanks,
> Kenichi
> 
> -----Original Message-----
> From: Teas <[email-masked]> On Behalf Of Vishnu Pavan Beeram
> Sent: Thursday, September 30, 2021 3:47 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology
> 
> Med, Hi! 
> 
> Thanks for elaborating!
> 
> I believe what you are saying is that if a network slice service request cannot be catered to by the current physical network, the NSC should be able to "suspend" the request, augment the physical network and then continue processing the suspended request using a new network resource group/partition (and possibly, a new filter topology) based off the "new" physical network.  That seems reasonable. 
> 
> We may just need to add a statement saying that "the Physical Network can be augmented if the service cannot be catered to using the existing physical network resources" (add it where "Physical Network" is introduced). 
> 
> I still prefer Adrian's working text for describing "Filter Topology".
> 
> Regards,
> -Pavan (contributor)
> 
> On Wed, Sep 29, 2021 at 10:05 AM <[email-masked] <mailto:[email-masked]> > wrote:
> 
> 
> 	Hi Pavan, 
> 
> 	 
> 
> 	A more conventional approach would be just for the NSC to come up with a proposal for extending the network footprint in order to address a request. This will be then passed to the appropriate components (planning, typically) for further processing. 
> 
> 	 
> 
> 	A more dynamic approach would be to trigger interconnection agreements with peer networks (think about the equivalent of inter-AS VPNs). 
> 
> 	 
> 
> 	In the radio front, there are already plenty project to extend the network capacity by grafting drones which play as flying stations. The same approach can be considered for some specific IP networks, e.g., deploy a drone fleet to extend the IP connectivity (stadium, etc.) and so on.   
> 
> 	 
> 
> 	However, all of this is out of scope of the framework document. We just need to avoid making an assumption that the underlay physical network is “frozen”. 
> 
> 	 
> 
> 	Cheers, 
> 
> 	Med
> 
> 	 
> 
> 	De : Teas <[email-masked] <mailto:[email-masked]> > De la part de Vishnu Pavan Beeram
> 	Envoyé : mercredi 29 septembre 2021 15:04
> 	À : BOUCADAIR Mohamed INNOV/NET <[email-masked] <mailto:[email-masked]> >
> 	Cc : [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
> 	Objet : Re: [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology
> 
> 	 
> 
> 	Med, 
> 
> 	 
> 
> 	My understanding is that the work-flow from Adrian assumes that the provider is catering to the dynamic service request using a given set of physical network resources. The IETF network slice service is mapped onto a network resource group/partition that has an associated filter topology. If the service cannot be catered to by any existing network resource group/partition, then a new one is spawned (a new filter topology may be spawned as part of this exercise). 
> 
> 	 
> 
> 	You make an interesting point about the NSC having the ability to dynamically extend/adjust the physical network. Can you elaborate more on how this is (/can be) done?
> 
> 	 
> 
> 	Regards,
> 
> 	-Pavan (contributor)
> 
> 	 
> 
> 	On Wed, Sep 29, 2021 at 7:09 AM <[email-masked] <mailto:[email-masked]> > wrote:
> 
> 		Re-,
> 
> 		 
> 
> 		Thank you, Adrian. 
> 
> 		 
> 
> 		I have a preference for “partition” rather than “group”.
> 
> 		 
> 
> 		Please see more inline. 
> 
> 		 
> 
> 		Cheers,
> 
> 		Med
> 
> 		 
> 
> 		De : Teas <[email-masked] <mailto:[email-masked]> > De la part de Adrian Farrel
> 		Envoyé : lundi 27 septembre 2021 20:24
> 		À : [email-masked] <mailto:[email-masked]> 
> 		Objet : [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology
> 
> 		 
> 
> 		Hi,
> 
> 		 
> 
> 		There was surprisingly little shouting about this proposal in my slides today. This may meant that more time is needed to digest it, or it may be that everyone has been doing their homework and we have something approaching agreement.
> 
> 		 
> 
> 		First the picture (with a light touch to the choice of terms), and then some discussion of terms.
> 
> 		 
> 
> 		                       --      --      --
> 
> 		                      |CE|    |CE|    |CE|
> 
> 		                       --      --      --
> 
> 		                     AC :    AC :    AC :                                       
> 
> 		                     ----------------------        -------
> 
> 		                    ( |PE|....|PE|....|PE| )      ( IETF  )
> 
> 		                   (   --:     --     :--   )    ( Network )
> 
> 		                   (     :............:     )    (  Slice  )                    
> 
> 		                    (  IETF Network Slice  )      (       )  Customer
> 
> 		                     ----------------------        -------     View
> 
> 		                  ........................\........./..................
> 
> 		                                           \       /        Controller
> 
> 		          >>>>>>>>>>>>>>>  Grouping/Mapping v     v            View
> 
> 		         ^             -----------------------------------------
> 
> 		         ^            ( |PE|.......|PE|........|PE|.......|PE|  )
> 
> 		    ------------     (   --:        --         :--         --    )
> 
> 		   |            |    (     :...................:                 )
> 
> 		   | Controller |     (        Network Resource Partition       )    
> 
> 		   |   (NSC)    |      -----------------------------------------     
> 
> 		   |            |                             |
> 
> 		   |            |>>>>>  Resource Partitioning |
> 
> 		    ------------        of Available Topology |          
> 
> 		     v   v                                    v
> 
> 		     v   v            -----------------------------      --------
> 
> 		     v   v           (|PE|..-..|PE|... ..|PE|..|PE|)    (        )
> 
> 		     v   v          ( :--  |P|  --   :-:  --   :--  )  (  Filter  )    
> 
> 		     v   v          ( :.-   -:.......|P|       :-   )  ( Topology )    
> 
> 		     v   v          (  |P|...........:-:.......|P|  )   (        )
> 
> 		     v   v           (  -    Filter Topology       )     --------
> 
> 		     v   v            -----------------------------       A
> 
> 		     v    >>>>>>>>>>>>  Topology Filter A                /
> 
> 		     v            .......................\............../..............
> 
> 		     v                                    \            /  Physical Network
> 
> 		     v            ------------------------------------------------
> 
> 		     v           ( |PE|.....-.....|PE|.......    |PE|.......|PE|  )
> 
> 		     v          (   --     |P|     --       :-...:--     -..:--    )
> 
> 		      >>>>>>>>>(    :       -:..............|P|.........|P|         )                     
> 
> 		               (    -.......................:-:..-       -          )
> 
> 		                (  |P|..........................|P|......:         )
> 
> 		                 (  -                            -                )
> 
> 		                  ------------------------------------------------
> 
> 		 
> 
> 		[Med] I like this (even if I think that the filtered topologies are internal to the NSC). What is important is that the NSC is provided with network provider policies for mapping slice requests to the underlay infrastructure. The filtering can be achieved during the request processing (e.g., exclude all satellite links for a delay-sensitive slice) instead of maintaining a pre-complied set of filtered topologies. Please note that “filter” is somehow a subset of the underlay which may be misinterpreted as if it is not allowed to adjust the physical network to accommodate new service needs.  
> 
> 		 
> 
> 		[Med] What is meaning of “>>>>>>>>>>>>>>>”? Should “Controller View” be “Provider View”?
> 
> 		 
> 
> 		 
> 
> 		 
> 
> 		And now the names for the pieces.
> 
> 		 
> 
> 		I think that “IETF Network Slice” is uncontentious.
> 
> 		I think that “Physical Network” is clear, although I would note that this could actually be a virtual network. 
> 
> 		 
> 
> 		There was some debate about what a “Filter Topology” is. This undoubtedly needs some words and thought. My working text for this is:
> 
> 		     The Physical Network may be filtered into a number of Filter
> 
> 		     Topologies.  Filter actions may include selection of specific nodes
> 
> 		     and links according to their capabilities and are based on network-
> 
> 		     wide policies.  The resulting topologies can be used to host IETF
> 
> 		     Network Slices and provide a useful way for the network operator to
> 
> 		     know that all of the resources they are using to plan a network
> 
> 		     slice meet specific SLOs.  This could be an offline planning
> 
> 		     activity or could be performed dynamically as new demands arise. 
> 
> 		     The use of Filter Topologies is entirely optional in the architecture
> 
> 		     and  IETF Network Slices could be hosted directly on the Physical
> 
> 		     Network.
> 
> 		 
> 
> 		[Med] I’m not sure to follow this part as the “specific SLOs” may not be known when creating filtered topologies, but when processing the request: 
> 
> 		 
> 
> 		““provide a useful way for the network operator to
> 
> 		     know that all of the resources they are using to plan a network
> 
> 		     slice meet specific SLOs.”
> 
> 		”
> 
> 		 
> 
> 		What about simply saying the following?
> 
> 		 
> 
> 		NEW: 
> 
> 		   The Physical Network may be filtered into a number of Filter
> 
> 		   Topologies.  Filter actions may include selection of specific
> 
> 		   resources (e.g., nodes and links) according to their capabilities and
> 
> 		   network operator policies.  The resulting topologies can be used as
> 
> 		   candidate to host IETF Network Slices.  The filtering procedure could
> 
> 		   be an offline planning activity or could be performed dynamically
> 
> 		   when processing a new slice service request.  In addition to
> 
> 		   filtering, the NSC may decide the required resource adjustment
> 
> 		   (Extended Topologies) that are needed to accommodate requested slice
> 
> 		   services.  Both the use of Filter and Extended Topologies are
> 
> 		   internal to the NSC and are, as such, entirely optional in the
> 
> 		   architecture.
> 
> 		 
> 
> 		The remaining term is for the collection of resources that are used to support the IETF Network Slice or grouping of IETF Network Slices. We appear to be down to a choice between “Network Resource Group” and “Network Resource Partition”.
> 
> 		 
> 
> 		I do not personally have a strong feeling on this. I think that “partition” is a slightly better word because it implies no sharing between sets of resources, and it may better cover statistical use of resources (e.g., you have 10% of the total bandwidth, not exactly that 10% of the bandwidth). But “group” is a perfectly fine word.
> 
> 		 
> 
> 		Opinions please.
> 
> 		 
> 
> 		Adrian
> 
> 		_________________________________________________________________________________________________________________________
> 		 
> 		Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> 		pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> 		a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> 		Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 		 
> 		This message and its attachments may contain confidential or privileged information that may be protected by law;
> 		they should not be distributed, used or copied without authorisation.
> 		If you have received this email in error, please notify the sender and delete this message and its attachments.
> 		As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> 		Thank you.
> 
> 		_______________________________________________
> 		Teas mailing list
> 		[email-masked] <mailto:[email-masked]> 
> 		https://www.ietf.org/mailman/listinfo/teas
> 
> 	_________________________________________________________________________________________________________________________
> 	
> 	Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> 	pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> 	a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> 	Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 	
> 	This message and its attachments may contain confidential or privileged information that may be protected by law;
> 	they should not be distributed, used or copied without authorisation.
> 	If you have received this email in error, please notify the sender and delete this message and its attachments.
> 	As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> 	Thank you.
>

---

From: "Luis M. Contreras" <[email-masked]>
Date: Fri, 1 Oct 2021 12:58:00 +0200

Hi Adrian,

revisiting your proposed figure, and considering current Figure 2 in the
draft (the one showing the NSC between the high level orchestration system
and the Networc Controllers), I think it would be convenient to include the
network controller(s) here interfacing with the NSC in the boundary you
marl as Physical Network. The Network controller will be the one
controlling (i.e., in direct touch) with the physical network, and
providing a view (filtered or not) of the Physical network to the NSC.

Showing it in this way I think keeps consistency with Fig 2 in the document
and also avoids confusion. This does not prevent the fact the NSC could be
integrated with Network Controller in some cases.

Furthermore, it could be better to rename "Controller view" to "NSC view"
or either "provider view" in the upper part of the figure.

Best regards

Luis

El lun, 27 sept 2021 a las 20:24, Adrian Farrel (<[email-masked]>)
escribió:

> Hi,
>
>
>
> There was surprisingly little shouting about this proposal in my slides
> today. This may meant that more time is needed to digest it, or it may be
> that everyone has been doing their homework and we have something
> approaching agreement.
>
>
>
>                      AC :    AC :    AC
> :
> There was some debate about what a “Filter Topology” is. This undoubtedly
> needs some words and thought. My working text for this is:
>
> The remaining term is for the collection of resources that are used to
> support the IETF Network Slice or grouping of IETF Network Slices. We
> appear to be down to a choice between “Network Resource Group” and “Network
> Resource Partition”.
>
>
>
> I do not personally have a strong feeling on this. I think that
> “partition” is a slightly better word because it implies no sharing between
> sets of resources, and it may better cover statistical use of resources
> (e.g., you have 10% of the total bandwidth, not exactly that 10% of the
> bandwidth). But “group” is a perfectly fine word.
>
>
>
> Opinions please.
>
>
>
> Adrian
> [email-masked]

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Fri, 1 Oct 2021 11:33:37 +0000

Hi Krzysztof,

You may don't see the requirement, but the architecture definitely allows multiple topologies if it allows multiple sets of SLOs/SLEs within a slice.
From this basic architecture, the customer must be not aware of the underlying topology. This means the customer is not aware which sets of SLOs/SLEs differentiates the underlying topologies, and which sets of those doesn't do so.
For us/an operator, this makes the service/operation overcomplicating.

We don't say no differentiation of classes within a slice, but need some constrains to the scope of SLOs/SLEs within a slice, Network Resource Partitioning/Filter Topology. So, we think it's simple to differentiate terminologies between those within a slice and those differentiating slices.

Thanks,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Krzysztof Szarkowicz <[email-masked]>
Sent: Friday, October 1, 2021 7:31 PM
To: 大垣 健一
Cc: Vishnu Pavan Beeram; [email-masked]; [email-masked]; [email-masked]
Subject: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology

Hi Kenichi,

Thanks,
Krzysztof

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 1 Oct 2021 14:17:21 +0200

Hi Kenichi,

I agree, architecture should allow (but not mandate) filtering topologies (among other thing to happen in underlay topology). That should be at the operator's discretion to the decide, what is the best way (for given operator) to operate the network that offers slice services to consumers. It might (or might not) involve topology filtering, network-wide resource partitioning (or might be only edge resource partitioning), etc. And I fully agree, the customer doesn’t need to be aware of all this things that happens in the underlying topology (i.e., these things should NOT be part of NBI that is used to request service slice). So we are is full agreement here :-).

Thanks,
Krzysztof

> On 2021 -Oct-01, at 13:33, Ogaki, Kenichi <[email-masked]> wrote:
> 
> Hi Krzysztof,
> 
> Get Outlook for iOS <https://aka.ms/o0ukef>
> From: Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>>
> Cc: Vishnu Pavan Beeram; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > On 2021 -Sep-30, at 03:18, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi Adrian and all,
> > 
> > From: Teas <[email-masked] <mailto:[email-masked]>> On Behalf Of Vishnu Pavan Beeram
> > To: [email-masked] <mailto:[email-masked]>
> > Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > On Wed, Sep 29, 2021 at 10:05 AM <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> > wrote:
> > 
> > 
> >        Hi Pavan, 
> > 
> >         
> > 
> >        De : Teas <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> > De la part de Vishnu Pavan Beeram
> >        À : BOUCADAIR Mohamed INNOV/NET <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >
> >        Cc : [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> ; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> >        On Wed, Sep 29, 2021 at 7:09 AM <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> > wrote:
> > 
> >                Re-,
> > 
> >                 
> > 
> >                Thank you, Adrian. 
> > 
> >                 
> > 
> >                De : Teas <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> > De la part de Adrian Farrel
> >                À : [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> >                [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> >                https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>
> > 
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 4 Oct 2021 03:38:13 +0000

Hi Krzysztof,

I don't still think we are in agreement. We are concerned about the terminology in a relationship with the architecture.
Adrian raised this thread about the basic architecture of ietf network slice realization. That draws the mapping between IETF Network Slice, Network Resource Partition and Filter Topology.

As you said, it's up to each operator whatever realization solution they/we uses. However, the terminology should comply with the architecture.

So, we are saying that multiple sets of SLOs/SLEs within a slice cannot be technically covered by a Network Resource Partition/Filter Topology should not be allowed as the architecture. NBI should comply with this.

An option is that , as a modeling, a slice should have *a* set of SLOs/SLEs at slice level, each set of SLOs/SLEs per connectivity matrix must not be beyond those for the slice from a viewpoint of Network Resource Partition. I think this is a kind of H-QoS someone commented.

Thanks,
Kenichi

-----Original Message-----
From: Krzysztof Szarkowicz <[email-masked]> 
Sent: Friday, October 1, 2021 9:17 PM
To: 大垣 健一 <[email-masked]>
Cc: [email-masked]; [email-masked]; Vishnu Pavan Beeram <[email-masked]>; [email-masked]
Subject: ***フリーメール*** Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #6: Realisation Architecture and Terminology

Hi Kenichi,

Thanks,
Krzysztof

	On 2021 -Oct-01, at 13:33, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> > wrote:

	Hi Krzysztof,

	Thanks,
	Kenichi

	Get Outlook for iOS <https://aka.ms/o0ukef> ________________________________

	From: Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]> >
	Sent: Friday, October 1, 2021 7:31 PM
	To: 大垣 健一
	Cc: Vishnu Pavan Beeram; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
	Subject: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology

	Hi Kenichi,

	Thanks,
	Krzysztof
	
	> On 2021 -Sep-30, at 03:18, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> > wrote:
	> 
	> Hi Adrian and all,
	> 
	> From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of Vishnu Pavan Beeram
	> Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
	> On Wed, Sep 29, 2021 at 10:05 AM <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> > wrote:
	> 
	> 
	>        Hi Pavan, 
	> 
	>         
	> 
	>        De : Teas <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> > De la part de Vishnu Pavan Beeram
	>        À : BOUCADAIR Mohamed INNOV/NET <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> >
	>        Cc : [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> 
	>        On Wed, Sep 29, 2021 at 7:09 AM <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> > wrote:
	> 
	>                Re-,
	> 
	>                 
	> 
	>                Thank you, Adrian. 
	> 
	>                 
	> 
	>                De : Teas <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> > De la part de Adrian Farrel
	>                À : [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> 
	>                [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Mon, 4 Oct 2021 10:31:58 +0200

Hi Kenichi,

Please see inline.

Best regards,
Krzysztof

> On 2021 -Oct-04, at 05:38, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Krzysztof,
> 

[Krzysztof] Agreed.

> So, we are saying that multiple sets of SLOs/SLEs within a slice cannot be technically covered by a Network Resource Partition/Filter Topology should not be allowed as the architecture. NBI should…

[Krzysztof] We certainly will have service slices with multiple traffic classes, having obviously different SLO/SLE requirements. Restricting the architecture to support IETF network slice service with single traffic class only is a mistake, IMHO, as it restricts the use cases that can be addresses with IETF Network Slice service. Also, if underlay transport uses some Network Resource Partitions and/or Filter Topologies, or do not use these elements, as the realization elements to fulfill specified SLOs/SLEs of IETF network slice service - it is subject to the operator’s discretion, realizing the IETF network slice service, if these architectural blocks are required in its network or not. NBI, where IETF network slice service is described, doesn’t refer to Network Resource Partition/Filter Topology, as these are elements of realization of the IETF network slice service definition. So, I am not completely sure about the relation you are mentioning between NBI (defining IETF network slice service) and Network Resource Partition/Filter Topology (defining some realization elements) -> I see them as separate items, where IETF network slice service is decoupled from the realization, as there might be many realization options. One of the realization option might be of course based on Network Resource Partitions/Filter Topologies, but it doesn’t need to be the only possible option to realize IETF network slice service with specified SLOs/SLEs.

> An option is that , as a modeling, a slice should have *a* set of SLOs/SLEs at slice level, each set of SLOs/SLEs per connectivity matrix must not be beyond those for the slice from a viewpoint of…

[Krzysztof] I think, John recommends this (from some earlier e-mail)

Attachment Circuit (AC):  A channel connecting a CE and a PE over which packets are exchanged.  The customer and provider agree on which values in which combination of L2 and L3 fields within a packet identify a given connectivity matrix within a given IETF Network Slice Service.
 
Which is inline with modeling the slice having multiple traffic classes (identified by “combination of L2 and L3 fields within a packet”), and with separate SLOs/SLEs per class, represented via separate connectivity matrixes. Then, different connectivity matrixes can be mapped to different Network Resource Partitions, if the operator choses the slice realization with Network Resource Partitions.

On the other hand, I am fully OK, that operator ‘X' might say, I am supporting only slices with SLOs/SLEs at slice level (i.e., no class differentiation between the slices). At the same time, operator ‘Y’ might decide to support slices with multiple classes. IMHO, NBI should allow both options, to satisfy different requirements.

> To: 大垣 健一 <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> 	On 2021 -Oct-01, at 13:33, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> > wrote:
> 
> 	Hi Krzysztof,
> 	
> 	
> 	Get Outlook for iOS <https://aka.ms/o0ukef <https://aka.ms/o0ukef>> ________________________________
> 
> 	From: Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >
> 	Cc: Vishnu Pavan Beeram; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> ; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> ; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> 	> On 2021 -Sep-30, at 03:18, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> > wrote:
> 	> 
> 	> Hi Adrian and all,
> 	> 
> 	> From: Teas <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> > On Behalf Of Vishnu Pavan Beeram
> 	> To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> 	> Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> ; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> 	> On Wed, Sep 29, 2021 at 10:05 AM <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>  <mailto:[email-masked] <mailto:[email-masked]>> > wrote:
> 	> 
> 	> 
> 	>        Hi Pavan, 
> 	> 
> 	>         
> 	> 
> 	>        De : Teas <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>  <mailto:[email-masked] <mailto:[email-masked]>> > De la part de Vishnu Pavan Beeram
> 	>        À : BOUCADAIR Mohamed INNOV/NET <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>  <mailto:[email-masked] <mailto:[email-masked]>> >
> 	>        Cc : [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>  <mailto:[email-masked] <mailto:[email-masked]>> ; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>  <mailto:[email-masked] <mailto:[email-masked]>> 
> 	>        On Wed, Sep 29, 2021 at 7:09 AM <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>  <mailto:[email-masked] <mailto:[email-masked]>> > wrote:
> 	> 
> 	>                Re-,
> 	> 
> 	>                 
> 	> 
> 	>                Thank you, Adrian. 
> 	> 
> 	>                 
> 	> 
> 	>                De : Teas <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>  <mailto:[email-masked] <mailto:[email-masked]>> > De la part de Adrian Farrel
> 	>                À : [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>  <mailto:[email-masked] <mailto:[email-masked]>> 
> 	>                [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>  <mailto:[email-masked] <mailto:[email-masked]>>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 4 Oct 2021 10:05:55 +0000

Hi Krzysztof,

I don't think the architecture restricts the use cases. Just a terminology issue, what we call a slice is?
We prefer a slice with a set of SLOs/SLEs, which is mapped to a Network Resource Partition/Filter Topology. We agree differentiating multiple traffic classes inside the Network Resource Partition/Filter Topology. If the customer requires to extend the SLOs/SLEs, we just modify or recreate the Network Partition/Filter Topology based on their change order.

Could you let us know what use cases cannot be covered?

Thanks,
Kenichi

From: Krzysztof Szarkowicz <[email-masked]>
Sent: Monday, October 4, 2021 5:32 PM
To: 大垣 健一 <[email-masked]>
Cc: [email-masked]; [email-masked]; Vishnu Pavan Beeram <[email-masked]>; [email-masked]
Subject: ***フリーメール*** Re: [Teas] ***フリーメール*** Re: ***フリーメール*** Re: Network slicing framework : Issue #6: Realisation Architecture and Terminology

Hi Kenichi,

Please see inline.

Best regards,
Krzysztof

On 2021 -Oct-04, at 05:38, Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>> wrote:

Hi Krzysztof,

[Krzysztof] Agreed.

Thanks,
Kenichi

-----Original Message-----
From: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 1, 2021 9:17 PM
To: 大垣 健一 <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: ***フリーメール*** Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #6: Realisation Architecture and Terminology

Hi Kenichi,

Thanks,
Krzysztof

   On 2021 -Oct-01, at 13:33, Ogaki, Kenichi <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> > wrote:

   Hi Krzysztof,

   Thanks,
   Kenichi

   From: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> >
   Sent: Friday, October 1, 2021 7:31 PM
   To: 大垣 健一
   Cc: Vishnu Pavan Beeram; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   Subject: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology

   Hi Kenichi,

   Thanks,
   Krzysztof

   > On 2021 -Sep-30, at 03:18, Ogaki, Kenichi <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> > wrote:
   >
   > Hi Adrian and all,
   >
   > From: Teas <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> > On Behalf Of Vishnu Pavan Beeram
   > To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   > Cc: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   > On Wed, Sep 29, 2021 at 10:05 AM <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]> > wrote:
   >
   >
   >        Hi Pavan,
   >
   >
   >
   >        De : Teas <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]> > De la part de Vishnu Pavan Beeram
   >        À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]> >
>        Cc : [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]>
   >        On Wed, Sep 29, 2021 at 7:09 AM <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]> > wrote:
   >
   >                Re-,
   >
   >
   >
   >                Thank you, Adrian.
   >
   >
   >
   >                De : Teas <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]> > De la part de Adrian Farrel
   >                À : [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]>
   >                [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]>

   _______________________________________________
   Teas mailing list
   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/teas

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Mon, 4 Oct 2021 12:55:05 +0200

Hi Kenichi,

https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices> states:

7.2 <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices#section-7.2>.  Isolation in IETF Network Slice Realization

   Isolation may be achieved in the underlying network by various forms
   of resource partitioning ranging from dedicated allocation of
   resources for a specific IETF Network Slice, to sharing of resources
   with safeguards.  For example, traffic separation between different
   IETF Network Slices may be achieved using VPN technologies, such as
   L3VPN, L2VPN, EVPN, etc.  Interference avoidance may be achieved by
   network capacity planning, allocating dedicated network resources,
   traffic policing or shaping, prioritizing in using shared network
   resources, etc.  

So, restricting the slice only to constructs mapped to “Network Resource Partition/Filter Topology” is not inline with above statement. “Network Resource Partition/Filter Topology” is very valid (and should be standardized, no doubt about that), but is just one of many, as listed above, realization options to achieve slice isolation. Some operators might use “network capacity planning” together with “prioritizing in using shared network resources” and “traffic policing or shaping” at the edge, instead of "allocating dedicated network resources” (represented by Network Resource Partition/Filter Topology), as a simple example based on above definitions.

Some example of use cases of slices with multiple classes:

* 3GPP slices with multiple QCIs (for example eMBB slice with Internet + IPTV + Video)
* Enterprise (Business)  - not related to mobile - slices with e.g. 3-play services (Internet, Video, Voice)

They can be mapped to IETF network slice service in

* 1:1 manner (e.g. single 3GPP slice with multiple QCIs mapped to single IETF Network Slice service with multiple classes)
* 1:N manner (e.g. single QCI from 3GPP slice mapped to single IETF Network Slice service without class differentiation)

Or some combination of above.

In any case, classification based on “combination of L2 and L3 fields within a packet” (as per John) is required. If traffic classes (flow groups) of single consumer slice are mapped to multiple IETF Network Slice services, then some umbrella SLO/SLE for group of IETF Network Slice service would be needed as well (i.e. to say, than entire multi-class consumer slice is 1 Gbps).

Best regards,
Krzysztof 

> On 2021 -Oct-04, at 12:05, Ogaki, Kenichi <[email-masked]> wrote:
> 
> Hi Krzysztof,
>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 5 Oct 2021 03:30:52 +0000

Hi Krzysztof,

I think we are seeing the same view.
See comments inline[KO], please.

Thanks,
Kenichi

From: Krzysztof Szarkowicz <[email-masked]>
Sent: Monday, October 4, 2021 7:55 PM
To: 大垣 健一 <[email-masked]>
Cc: [email-masked]; [email-masked]; Vishnu Pavan Beeram <[email-masked]>; [email-masked]
Subject: ***フリーメール*** Re: ***フリーメール*** Re: [Teas] ***フリーメール*** Re: ***フリーメール*** Re: Network slicing framework : Issue #6: Realisation Architecture and Terminology

Hi Kenichi,

https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices states:

7.2<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices#section-7.2>.  Isolation in IETF Network Slice Realization

   resources, etc.

[KO] My reading is different understanding from "resource partitioning ranging from dedicated allocation of resources for a specific IETF Network Slice, to sharing of resources with safeguards" of Sec 7.2 and the original Adrian’s text proposal of this thread.
https://mailarchive.ietf.org/arch/msg/teas/6I_Rgkunoe169tr0x12nN1wC30s/
"network capacity planning, allocating dedicated network resources, traffic policing or shaping, prioritizing" are the realization options of Network Resource Partition, and we don't limit it to "allocating dedicated network resources".

[KO] Agree and both cases can be covered by Network Resource Partition concept.
Note: As I wrote before, in 3GPP semantics, a single 3GPP slice is a Network Slice Instance whichever with multiple QCIs or a single one within a slice. Then, a class cannot be beyond SLOs/SLEs to meet the NSI's capability/resource, but we can extend. This is same concept as a Network Resource Partition.

In any case, classification based on “combination of L2 and L3 fields within a packet” (as per John) is required. If traffic classes (flow groups) of single consumer slice are mapped to multiple IETF Network Slice services,

[KO] I cannot understand this. A service should be between a customer and a provider. What do you mean "single consumer slice are mapped to multiple IETF Network Slice services"

then some umbrella SLO/SLE for group of IETF Network Slice service would be needed as well (i.e. to say, than entire multi-class consumer slice is 1 Gbps).

[KO] Agree. We are saying this umbrella SLO/SLE is necessary for *an* IETF Network Slice (service).

Best regards,
Krzysztof

On 2021 -Oct-04, at 12:05, Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>> wrote:

Hi Krzysztof,

Thanks,
Kenichi

Hi Kenichi,

Please see inline.

Best regards,
Krzysztof

Hi Krzysztof,

[Krzysztof] Agreed.

Thanks,
Kenichi

-----Original Message-----
From: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 1, 2021 9:17 PM
To: 大垣 健一 <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: ***フリーメール*** Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #6: Realisation Architecture and Terminology

Hi Kenichi,

Thanks,
Krzysztof

   Hi Krzysztof,

   Thanks,
   Kenichi

   Hi Kenichi,

   Thanks,
   Krzysztof

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Wed, 6 Oct 2021 21:03:09 +0200

Hi Kenichi,

Please see inline.

Thanks,
Krzysztof

> On 2021 -Oct-05, at 05:30, Ogaki, Kenichi <[email-masked]> wrote:
> 
> Hi Krzysztof,
>  
> https://mailarchive.ietf.org/arch/msg/teas/6I_Rgkunoe169tr0x12nN1wC30s/ <https://mailarchive.ietf.org/arch/msg/teas/6I_Rgkunoe169tr0x12nN1wC30s/>
[Krzysztof] I agree with Adrian’s text saying "The Physical Network may be filtered into a number of Filter Topologies.” So, it is an option that some operators might use, and that some operators will not use. That was my original comment regarding ‘Filter Topologies'

> "network capacity planning, allocating dedicated network resources, traffic policing or shaping, prioritizing" are the realization options of Network Resource Partition, and we don't limit it to "a…

[Krzysztof] OK, if "network capacity planning, allocating dedicated network resources, traffic policing or shaping, prioritizing” are  the realization options of Network Resource Partition, then we are on the same page. Although I cannot really see how “network capacity planning” can be realization of “Network Resource Partition”, for example. Or, policing/shaping at the access circuit can be realization of “Network Resource Partition”.

> [KO] Agree and both cases can be covered by Network Resource Partition concept.

[Krzysztof] See earlier comment about “Network Slice Partition”.

> Note: As I wrote before, in 3GPP semantics, a single 3GPP slice is a Network Slice Instance whichever with multiple QCIs or a single one within a slice. Then, a class cannot be beyond SLOs/SLEs to…

[Krzysztof] Let me go back to this.

> [KO] I cannot understand this. A service should be between a customer and a provider. What do you mean "single consumer slice are mapped to multiple IETF Network Slice services"

[Krzysztof] Single consumer slice is high level intend, i.e. 

* “I need slice between 10 endpoints, carrying Internet + IPTV + VoIP”
* slice total is 1 Gbps, from this 4 Mbps is IPTV with delay 10 ms, 100 kbps is VoIP with delay 5 ms
* if IPTV/VoIP doesn’t use the full BW allocated to IPTV/VoIP, it can be reused by Internet up to the 1 Gbps cap

And now the question is, if above high-level requirement is mapped to single IETF Network Slice service, with multiple classes, having NBI allowing to specify per class SLOs; or is mapped to multiple IETF Network Slice services, each slice service representing single class above

> [KO] Agree. We are saying this umbrella SLO/SLE is necessary for *an* IETF Network Slice (service).

[Krzysztof] If in above case the consumer high-level slice intend is mapped to single IETF Network Slice Service (with SLO/SLE per class + umbrella SLO/SLE per slice), or to three IETF Network Slice Services. In the 2nd case, umbrella SLO/SLE for group of three IETF Network Slice Services is needed as well.

>  
>  
> Best regards,
> Krzysztof 
> 
> 
> On 2021 -Oct-04, at 12:05, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Krzysztof,
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 12 Oct 2021 06:20:22 +0000

Hi Adrian,

Sorry for the late reply, please see further inline with [Jie #2]:

From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, September 29, 2021 1:44 AM
To: Dongjie (Jimmy) <[email-masked]>; [email-masked]
Subject: RE: [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology

Thanks for the constructive comments, Jie.

Also inline:

                       --      --      --

                      |CE|    |CE|    |CE|

                       --      --      --

                     AC :    AC :    AC :

                                           \       /        Controller

   |            |                             |

     v   v                                    v

     v                                    \            /  Physical Network

                 (  -                            -                )

I think that "IETF Network Slice" is uncontentious.

[Jie] Agree.

I think that "Physical Network" is clear, although I would note that this could actually be a virtual network.

[Jie] Perhaps could call it infrastructure network to show that it is the network layer which provides the resources for partitioning.

[AF] In my scratch copy I had just changed this to "underlay network". Is that better or worse than "infrastructure network"?

[Jie #2] "Underlay network" sounds good to me, it can cover both physical underlay and virtual underlay. The infrastructure network can be seen as the bottom layer which is used to build the "underlays".

There was some debate about what a "Filter Topology" is. This undoubtedly needs some words and thought. My working text for this is:

     Network.

[Jie] Based on this description, is the "filter topology" here equivalent to a sub-topology?  In my understanding, there can be multiple approaches to define a sub-topology based on a physical network: either explicitly specify the set of links and nodes belonging to the sub-topology, or apply a set of constraints (i.e. filters) to the physical network. It seems "filter topology" only refer to the latter approach, while perhaps sub-topology is more generic and can cover both?

[AF] I don't see the difference. An explicit specification is a set of constraints (just as the set of constraints must be configured).

However, I also agree the it is a kind of sub-topology.

[Jie #2] Thanks for the explanation. My reading of the text and the above figure is the "filter topology" only exists in the NSC (controller) by applying the constraints to the underlay network, while the network nodes in the underlay are not aware of the filtered topology.

In some network slice realizations,  the logical topology associated with the network resource partition also needs to be visible to the network nodes, so that topology specific route computation and selection can be performed by the nodes.

Do you think "filter topology" can cover both cases: the controller view and the network nodes view of the topology? Nevertheless, my preference would be to call it "logical topology" to keep the maximum generality.

Now, an ACTN proponent would probably point out that the resources in this "sub-topology" could actually be collected from more than one underlying network. This may be a special case (at least for early deployments of network slicing), but if we include that option then "sub-topology" is a bit confusing. (But only  a bit).

The remaining term is for the collection of resources that are used to support the IETF Network Slice or grouping of IETF Network Slices. We appear to be down to a choice between "Network Resource Group" and "Network Resource Partition".

[Jie] During the interim meeting, Lou asked "What is the relationship between resource partition/group and filter topology", your reply was "The partition/group is built from the resources in only one filter topology." Thus the network resource partition/group is associated with a specific filter-topology or sub-topology. As long as the topology characteristic can be reflected in the term, I don't have a strong opinion on this either.

[AF] OK. We seem to be all easy on this choice.

And in the figure above, it says "Resource Partitioning of Available Topology", perhaps it is better to rephrase it as "available topology of the resource partition"?

[AF] That wasn't my intention. The "available topology" is the sub-topology. So I should be clearer on that.

The "resource partition" is a subset of the resources that exist in the sub-topology.

[Jie #2] Thanks for the clarification. I think we agreed on what it means, just the wording could be clearer.

I do not personally have a strong feeling on this. I think that "partition" is a slightly better word because it implies no sharing between sets of resources, and it may better cover statistical use of resources (e.g., you have 10% of the total bandwidth, not exactly that 10% of the bandwidth). But "group" is a perfectly fine word.

[Jie] Do you mean with resource partition, the 10% of the total bandwidth is not a fixed set, e.g. it can be either the first 10% or the last 10% on a link?

[AF] Exactly.

[Jie #2] It sounds reasonable to allow that flexibility.

Best regards,

Jie

Best,

Adrian