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

[Krzysztof Szarkowicz <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> On Behalf Of Vishnu Pavan Beeram
> Sent: Thursday, September 30, 2021 3:47 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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 <[e-mail] <mailto:[e-mail]> > 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 <[e-mail] <mailto:[e-mail]> > De la part de Vishnu Pavan Beeram
> 	Envoyé : mercredi 29 septembre 2021 15:04
> 	À : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]> >
> 	Cc : [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
> 	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 <[e-mail] <mailto:[e-mail]> > wrote:
> 
> 		Re-,
> 
> 		 
> 
> 		Thank you, Adrian. 
> 
> 		 
> 
> 		I have a preference for “partition” rather than “group”.
> 
> 		 
> 
> 		Please see more inline. 
> 
> 		 
> 
> 		Cheers,
> 
> 		Med
> 
> 		 
> 
> 		De : Teas <[e-mail] <mailto:[e-mail]> > De la part de Adrian Farrel
> 		Envoyé : lundi 27 septembre 2021 20:24
> 		À : [e-mail] <mailto:[e-mail]> 
> 		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
> 		[e-mail] <mailto:[e-mail]> 
> 		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.
>