Subject: Re: [Teas] What is Slice Aggregate?

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Nov 2021 19:41:00 -0000

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 <[email-masked]> On Behalf Of Lizhenbin
Sent: 09 November 2021 13:35
To: [email-masked]; [email-masked]
Cc: [email-masked]
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

---

From: Lizhenbin <[email-masked]>
Date: Thu, 25 Nov 2021 16:12:59 +0000

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:[email-masked]]
Sent: Wednesday, November 10, 2021 3:41 AM
To: Lizhenbin <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: What is Slice Aggregate?

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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Lizhenbin
Sent: 09 November 2021 13:35
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Bier] What is Slice Aggregate?

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

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.

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...

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

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