Subject: Re: [Teas] Network Slicing : Issue #6 (realization) resolution

From: Krzysztof Szarkowicz <[email-masked]>
Date: Wed, 3 Nov 2021 11:41:22 +0100

Hi Adrian,

Thanks for your efforts to clean the text.

I have few comments inline.

Best regards,
Krzysztof

> On 2021 -Oct-25, at 20:19, Adrian Farrel <[email-masked]> wrote:
> 
> Hi,
> 
> I think we reached compromise agreement on terminology and the picture here
> with the only open issue (Krzysztof) being whether partitioning the AC forms
> part of partitioning the network.
> 
> My view is that it can do, but it doesn't have to. A lot of stuff about the
> AC depends on the discussion of where the end points are (which is part of
> issue #5). If the end point is on the customer side of the AC, then, yes,
> the AC is part of the network that can be partitioned, but if the end point
> is in the PE then the AC is not part of the network that can be partitioned.

[Krzysztof] IMHO, looking at draft-ietf-teas-ietf-network-slices-05, Section 4.2 definitions, in use cases 1), 2) and 3) we can talk about AC partitioning. My understanding of use case 4) is, that frames/packets can arrive to PE on any AC, and AC contact is not taken into account when the frames/packets are  classified to some IETF Network Slice (only frame/packet fields are taken into account for slice classification). Indeed, in such use case we cannot talk about AC partitioning.

The overall use case I mentioned is:

a) the network (transit interfaces/nodes) doesn’t use granular resource partitioning scheme, apart from basic 8-queues/shapers QoS model (i.e., no hierarchical-shaping or policing used on transit)
b) granular (hierarchical-policing/hierarchical-shaping) partitioning of ACs -> granular admission control for the each slice
c) capacity planning/dimensioning/management at global level (not related to individual IETF Network Slices) in the underlay network, including capacity management using TE toolset (traffic redirection during congestion, traffic distribution over less utilized links, etc.)

Section 6.1 of the draft shows “Network Resource Partition” behind PEs (i.e., ACs not included), so my impression from it is, that the underlay network has some more granular (rather than basic 8-queue model) QoS scheme to realize these partitions. Also, while Section 6.2. mentions that "Filter Topologies" are optional, it has no qualifying statement about “Network Resource Partition” (MUST, SHOULD, MAY)

So, IMHO, next revisions of the draft, these aspects should be addressed in more details.

> 
> With that, I'm going to include the figure we discussed and pick up the
> terminology as debated (especially Kenichi and Jie).
> 
> As with all of these resolutions, the changes that will find there way into
> the next revision of the draft remain open for further discussion.
> 
> Best,
> Adrian
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 8 Nov 2021 14:24:07 +0000

Hi Adrian,

Thanks a lot for your efforts in organizing the discussion and putting them into the text. 

Regarding the new terms introduced for the realization part, I see the new term "Network Resource Partition" is used in the both Figure 5 and the descriptions after it, however there is no formal definition of the this new term yet.

Similarly, "filter topology" is another new term which does not have its definition. As mentioned in a previous mail, from the figure it is not clear (at least to me) that whether the filter topology only exists in the controller, or it is also available to the network nodes, so that they can perform distributed path computation based on the topology associated with the network resource partition. 

Thus I would suggest that we also provide the definitions of these new terms in this document, so that people could have consistent understanding about what they mean and what they can do. Many thanks.

Best regards,
Jie

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Tuesday, October 26, 2021 2:19 AM
> To: 'TEAS WG' <[email-masked]>
> Subject: [Teas] Network Slicing : Issue #6 (realization) resolution(at
> 
> Hi,
> 
> I think we reached compromise agreement on terminology and the picture
> here with the only open issue (Krzysztof) being whether partitioning the AC
> forms part of partitioning the network.
> 
> My view is that it can do, but it doesn't have to. A lot of stuff about the AC
> depends on the discussion of where the end points are (which is part of issue
> #5). If the end point is on the customer side of the AC, then, yes, the AC is part
> of the network that can be partitioned, but if the end point is in the PE then
> the AC is not part of the network that can be partitioned.
> 
> As with all of these resolutions, the changes that will find there way into the
> next revision of the draft remain open for further discussion.
> 
> Best,
> Adrian
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Nov 2021 14:44:19 -0000

Thanks Jie.

Yes, it is a mistake not to call out clear definitions of these terms. We
have some text on both of them, but not clearly and unambiguously pulling
out the meanings.

We currently have (in 6.1)

   The underlay network may be filtered by the network operator into a
   number of Filter Topologies.  Filter actions may include selection of
   specific resources (e.g., nodes and links) according to their
   capabilities, and are based on network-wide policies.  The resulting
   topologies can be used as candidates to host IETF Network Slices and
   provide a useful way for the network operator to know in advance that
   all of the resources they are using to plan an IETF Network Slice
   would be able to meet specific SLOs and SLEs.  The filtering
   procedure 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 underlay network.

...and...

   Each group of IETF Network Slices is mapped onto a set of network
   resources that are available to carry traffic and meet the SLOs and
   SLEs.  These resources are known as a Network Resource Partition and
   are selected from the Filter Topology (or direct from the underlay
   network): they may be reserved and dedicated for use by the group of
   IETF Network Slices, or may be shared between groups depending on the
   details of the SLOs and SLEs.

I'd really appreciate suggestions. Alternatively, I'll add it to my list and
make up some text.

Best,
Adrian

-----Original Message-----
From: Dongjie (Jimmy) <[email-masked]> 
Sent: 08 November 2021 14:24
To: [email-masked]; 'TEAS WG' <[email-masked]>
Subject: RE: [Teas] Network Slicing : Issue #6 (realization) resolution

Hi Adrian,

Thanks a lot for your efforts in organizing the discussion and putting them
into the text. 

Regarding the new terms introduced for the realization part, I see the new
term "Network Resource Partition" is used in the both Figure 5 and the
descriptions after it, however there is no formal definition of the this new
term yet.

Similarly, "filter topology" is another new term which does not have its
definition. As mentioned in a previous mail, from the figure it is not clear
(at least to me) that whether the filter topology only exists in the
controller, or it is also available to the network nodes, so that they can
perform distributed path computation based on the topology associated with
the network resource partition. 

Thus I would suggest that we also provide the definitions of these new terms
in this document, so that people could have consistent understanding about
what they mean and what they can do. Many thanks.

Best regards,
Jie