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

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Sep 2021 19:23:55 +0100

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

                 (  -                            -                )

                  ------------------------------------------------

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.

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Sep 2021 08:59:27 -0400

Hi,

I really appreciate this discussion and new ascii art!

On 9/27/2021 2:23 PM, Adrian Farrel wrote:
> 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.

Based on yesterday's discussion I too have a slight preference for 
partition -- due to the topology implications of the construct.

Lou

(as contributor)

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 28 Sep 2021 16:16:41 +0000

Hi Adrian,

Thanks for the nice drawing, it helps to clarify the layers and the functions.

Please see some comments inline:

From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, September 28, 2021 2:24 AM
To: [email-masked]
Subject: [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.

[Jie] Perhaps both cases apply here:)

First the picture (with a light touch to the choice of terms), and then some discussion of terms.

                       --      --      --

                      |CE|    |CE|    |CE|

                       --      --      --

                     AC :    AC :    AC :

                                           \       /        Controller

   |            |                             |

     v   v                                    v

     v                                    \            /  Physical Network

                 (  -                            -                )

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

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?

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.

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"?

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?

Best regards,

Jie

Opinions please.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Sep 2021 18:43:51 +0100

Thanks for the constructive comments, Jie.

Also inline:

 

                       --      --      --

                      |CE|    |CE|    |CE|

                       --      --      --

                     AC :    AC :    AC :

                                           \       /        Controller

   |            |                             |

     v   v                                    v

     v                                    \            /  Physical Network

                 (  -                            -                )

[Jie] Agree.

[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"?

     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.

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

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

Best,

Adrian

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 28 Sep 2021 13:49:03 -0500

Adrian, Hi!

Much Thanks for initiating this (and the other threads)! Please see inline
for responses (prefixed VPB)

Regards,
-Pavan (as WG contributor)

> that everyone has been doing their homework and we have something
[VPB] I would like to think that it is the latter.

>                      AC :    AC :    AC
> :
[VPB] Great illustration!

> I think that “IETF Network Slice” is uncontentious.
>
> I think that “Physical Network” is clear, although I would note that this
> There was some debate about what a “Filter Topology” is. This undoubtedly
> [VPB] +1 for "Filter Topology" and the working text that goes with it.

> 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”.
>
>
>
> “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.
>
>
[VPB] Thanks for stating why you think "partition" is better. I prefer
"group" because unlike "partition", it does not imply "no sharing" between
sets of resources. Why preclude sharing?

That said, I can live with "partition" -- would just like to see the WG
adopt a term for this and move on.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Sep 2021 21:15:09 +0100

Hi Pavan,

[mega snip]

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.

[VPB] Thanks for stating why you think "partition" is better. I prefer "group" because unlike "partition", it does not imply "no sharing" between sets of resources. Why preclude sharing? 

That said, I can live with "partition" -- would just like to see the WG adopt a term for this and move on.

[AF] Thank you for your willingness to be flexible.

Seems that, at the moment, there are few marginal preferences in either direction, but nothing dramatic.

I think we’ll give it a few more days in case anyone is going to scream. Then we’ll make a choice.

Best,

Adrian

---

From: <[email-masked]>
Date: Wed, 29 Sep 2021 12:09:05 +0000

Re-,

Thank you, Adrian.

I have a preference for "partition" rather than "group".

Please see more inline.

Cheers,
Med

De : Teas <[email-masked]> De la part de Adrian Farrel
Envoyé : lundi 27 septembre 2021 20:24
À : [email-masked]
Objet : [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology

Hi,

                       --      --      --

                      |CE|    |CE|    |CE|

                       --      --      --

                     AC :    AC :    AC :

                                           \       /        Controller

   |            |                             |

     v   v                                    v

     v                                    \            /  Physical Network

                 (  -                            -                )

[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"?

     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:

   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.

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.

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 29 Sep 2021 08:03:42 -0500

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]> wrote:

> Re-,
>
>
>
> Thank you, Adrian.
>
>
>
> I have a preference for “partition” rather than “group”.
>
>
>
> Please see more inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Teas <[email-masked]> *De la part de* Adrian Farrel
> *Envoyé :* lundi 27 septembre 2021 20:24
> *À :* [email-masked]
> *Objet :* [Teas] Network slicing framework : Issue #6: Realisation
> Architecture and Terminology
>
>
>
> Hi,
>
>
>
> *[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”?
> *[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.*
>
>
>

---

From: <[email-masked]>
Date: Wed, 29 Sep 2021 15:05:29 +0000

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]> De la part de Vishnu Pavan Beeram
Envoyé : mercredi 29 septembre 2021 15:04
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]; [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.

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,

                       --      --      --

                      |CE|    |CE|    |CE|

                       --      --      --

                     AC :    AC :    AC :

                                           \       /        Controller

   |            |                             |

     v   v                                    v

     v                                    \            /  Physical Network

                 (  -                            -                )

[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”?

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:

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

NEW:

   architecture.

Opinions please.

Adrian

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 29 Sep 2021 13:46:53 -0500

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]> 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]> *De la part de* Vishnu Pavan Beeram
> *Envoyé :* mercredi 29 septembre 2021 15:04
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> *Cc :* [email-masked]; [email-masked]
> *Objet :* Re: [Teas] Network slicing framework : Issue #6: Realisation
> *[Med] What is meaning of “*>>>>>>>>>>>>>>>*”? Should “*Controller View”
> be “Provider View”?
>
>
>
>
>
>
>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 30 Sep 2021 01:18:14 +0000

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

Regards,
-Pavan (contributor)

On Wed, Sep 29, 2021 at 10:05 AM <[email-masked] <mailto:[email-masked]> > wrote:

	Hi Pavan, 

	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, 

	Regards,

	-Pavan (contributor)

	On Wed, Sep 29, 2021 at 7:09 AM <[email-masked] <mailto:[email-masked]> > wrote:

		Re-,

		Thank you, Adrian. 

		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,

		                       --      --      --

		                      |CE|    |CE|    |CE|

		                       --      --      --

		                     AC :    AC :    AC :                                       

		                                           \       /        Controller

		   |            |                             |

		     v   v                                    v

		     v                                    \            /  Physical Network

		                 (  -                            -                )

		 

		     Network.

		”

		NEW: 

		   architecture.

		Opinions please.

		Adrian

		 

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

---

From: <[email-masked]>
Date: Thu, 30 Sep 2021 07:05:52 +0000

Hi Pavan,

I think that you got the intent. That is what is supposed to be covered in the proposed NEW text:

   In addition to
   services.

As we don’t want to get into low level details nor recommend support of filtering/extending capabilities, the proposal is explicit out that these are part of the internal machinery of the NSC, hence this wording in the NEW text:

   Both the use of Filter and Extended Topologies are
   internal to the NSC and are, as such, entirely optional in the
   architecture.

I also proposed some minor changes to reason about resources in general, not only links and nodes. This is a provision to manipulate also (virtual) service functions as part of a filtered topology.

Thank you.

Cheers,
Med

De : Vishnu Pavan Beeram <[email-masked]>
Envoyé : mercredi 29 septembre 2021 20:47
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]; [email-masked]
Objet : Re: [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology

Med, Hi!

Thanks for elaborating!

Regards,
-Pavan (contributor)

On Wed, Sep 29, 2021 at 10:05 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavan,

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,

Regards,
-Pavan (contributor)

Thank you, Adrian.

Please see more inline.

Cheers,
Med

Hi,

                       --      --      --

                      |CE|    |CE|    |CE|

                       --      --      --

                     AC :    AC :    AC :

                                           \       /        Controller

   |            |                             |

     v   v                                    v

     v                                    \            /  Physical Network

                 (  -                            -                )

     Network.

NEW:

   architecture.

Opinions please.

Adrian

Thank you.

Thank you.