Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

[[e-mail]]

Re-,

Indeed.

FWIW, some of this is captured in RFC7297 with a focus on legacy mechanisms:

==
   These requirements include: reachability scope (e.g., limited scope,
   Internet-wide), direction, bandwidth requirements, QoS parameters
   (e.g., one-way delay [RFC2679], loss [RFC2680], or one-way delay
   variation [RFC3393]), protection, and high-availability guidelines
   (e.g., restoration in less than 50 ms, 100 ms, or 1 second).

   These requirements are then translated into IP/MPLS-related technical
   clauses (e.g., need for recovery means, definition of the class of
   service, need for control-plane protection, etc.).  In a later stage,
   these various clauses will be addressed by the activation of adequate
   network features and technology-specific actions (e.g., Multiprotocol
   Label Switching Traffic Engineering (MPLS-TE, [RFC3346]), Resource
   Reservation Protocol (RSVP, [RFC2205]), Open Shortest Path First
   (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), by
   means of CPP-derived configuration information.

   …

   The CPP template aims to capture connectivity needs and to represent
   and value these requirements in a standardized manner.  Service- and
   Customer-specific IP provisioning rules may lead to a dramatic
   increase of the number of IP transfer classes that need to be
   (pre-)engineered in the network.  Instantiating each CPP into a
   distinct class of service should therefore be avoided for the sake of
   performance and scalability.

   Therefore, application-agnostic IP provisioning practices should be
   recommended, since the requirements captured in the CPP can be used
   to identify which network class of service is to be used to meet
   those requirements/guarantees.  From that standpoint, the CPP concept
   is meant to design a limited number of generic classes so that
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   individual CPP documents, by capturing the connectivity requirements
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   of services, applications, and Customers, can be easily mapped to
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   these classes.
   ^^^^^^^^^^^^
==

Cheers,
Med

De : Krzysztof Szarkowicz <[e-mail]>
Envoyé : vendredi 1 avril 2022 15:26
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]; [e-mail]
Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Med,

We are on the same page here. I see this as well as predominant approach, in fact.

Cheers,
Krzysztof



On 2022 -Apr-01, at 15:20, <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>> wrote:

Krzysztof,

Admission control + use of limited set of core QoS classes (PDBs) + much more access QoS classes + map access QoS classes to core classes + no multi-topology/customized path selection is also an example network partitioning. I even expect this to be the privileged approach when legacy forwarding mechanisms should be used to fulfil slicing objectives.

Cheers,
Med

De : Krzysztof Szarkowicz <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 1 avril 2022 10:30
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>
Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Adrian, Med,

Returning to this. I’ve seen many design cases with SPs, where the network is designed physically in very structured manner. Also, I’ve seen some analysis done by couple of SPs, that as the result of this very structured network design, after making internal analysis, they don’t really see the difference between path placement done using IGP metric, and path placement done using delay metric. Hence, even introducing some flex-algos (TE meshes) with different metric optimization is questionable here (as the resulting paths are the same).

To realize services with SLO commitments, these SPs today extensively use admission control at the edge (some times even relatively complex admission control schemes at the edge). But, they don’t use anything specific (TE, Flex-Algo) in the transport, apart from mentioned admission control at the edge (ingress/egress policers/shapers), basic QoS on transit, network capacity planning, and timely capacity upgrades, where needed.

Does this approach could be considered as well as some way of ’network resource partitioning’ mentioned in the draft?

Cheers,
Krzysztof


On 2022 -Mar-28, at 12:26, Krzysztof Szarkowicz <[e-mail]<mailto:[e-mail]>> wrote:

OK,

If a realization example of network partition is flex-algo + admission control, then I am fine.

Thanks,
Krzysztof



_________________________________________________________________________________________________________________________

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.