Re: [Teas] Specifying A2A SLO/SLEs

[Daniele Ceccarelli <[e-mail]>]

Hi Tarek, Med,

We're diverging a bit from the original problem which was: "how to have different SLOs/SLEs between e.g. 20 Mbps between SDP4 and SDP5 instead of the 10 Mbps assigned to the A2A slice between SDP4,5,6,7.

[cid:image003.png@01D85B10.7875F3B0]

This can be solved using the 2 constructs below (I don't really like this solution, but it works):


  *   A2A, 4/5/6/7 - CONSTRUCT1 = 10 Mbps
  *   P2P, 4/5 - CONSTRUCT2 = 10 Mbps

Binding is an issue, as packets from 4 to 5 don't need to be bound to one or the other construct but rather balanced 50%-50% in this example.

Cheers,
Daniele


From: Teas <[e-mail]> On Behalf Of [e-mail]
Sent: den 26 april 2022 07:39
To: Tarek Saad <[e-mail]>
Cc: TEAS WG <[e-mail]>; [e-mail]
Subject: Re: [Teas] Specifying A2A SLO/SLEs

Hi Tarek,

Thank you.

As clarified to John, traffic binding/steering is not what we are discussing here but how to avoid ambiguity in capturing service requirements when enclosed constructs are not disjoint + distinct objectives are set for the common SDPs per construct.

The order should not be set by the system (which is the default behavior in YANG as per rfc7950.html#section-7.7.7), but by the user. The order will then be used to infer which service objectives will take precedence (and then will override others).

Obviously, no issue is encountered when disjoint constructs are used.

Cheers,
Med

De : Tarek Saad <[e-mail]<mailto:[e-mail]>>
Envoyé : lundi 25 avril 2022 17:29
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; Daniele Ceccarelli <daniele.ceccarelli=[e-mail]<mailto:daniele.ceccarelli=[e-mail]>>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc : TEAS WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Objet : Re: Specifying A2A SLO/SLEs

I had a type in the policy below (corrected)..

Regards,
Tarek

From: Tarek Saad <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 25, 2022 at 11:19 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Daniele Ceccarelli <daniele.ceccarelli=[e-mail]<mailto:daniele.ceccarelli=[e-mail]>>, John E Drake <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Specifying A2A SLO/SLEs
Hi John, Danielle and Med,

When multiple connectivity constructs exists (e.g. from a source SDP) within the same IETF NS slice, I agree with John that a policy can decide which packets can use which construct - e.g. by inspecting certain fields from the packet.


  *   A2A, 4/5/6/7 - CONSTRUCT1
  *   P2P, 4/5 - CONSTRUCT2

In the example above, since two possible constructs will exist on SDP 4, a policy such that:

  *   If packet is destined to 6/7, then steer on CONSTRUCT1
  *   If packet is destined to 5, then steer on CONSTRUCT2

In the current IETF NS service model, we have introduced a field that may be serving the above (from Appendix A of draft-ietf-teas-ietf-network-slice-nbi-yang):

              "ns-match-criteria": {
                "ns-match-criterion": [
                  {
                    "index": 0,
                    "match-type":
                    <snip>
                    ],
                    "target-ns-connection-group-id": "Matrix1"
                  },

Regards,
Tarek



From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 25, 2022 at 10:17 AM
To: Daniele Ceccarelli <daniele.ceccarelli=[e-mail]<mailto:daniele.ceccarelli=[e-mail]>>, John E Drake <[e-mail]<mailto:[e-mail]>>, Tarek Saad <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Specifying A2A SLO/SLEs
Re-,

We can indeed consider the following with "ordered-by user" set of constructs and indicate in the text that the order infers which construct takes precedence when there is overlapping/conflicts.

  *   A2A, 4/5/6/7
  *   P2P, 4/5

That design depends on the normative language to get things right.
The advantage of the proposal I made earlier is that we don't rely on extra normative language + the behavior is deterministic.

I still don't think a change is needed to the framework I-D as it does not impose how all this is to be modelled.

Cheers,
Med

De : Teas <[e-mail]<mailto:[e-mail]>> De la part de Daniele Ceccarelli
Envoyé : lundi 25 avril 2022 13:03
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; John E Drake <[e-mail]<mailto:[e-mail]>>; Tarek Saad <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc : TEAS WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Objet : Re: [Teas] Specifying A2A SLO/SLEs

Hi Med,

The solution you're proposing perfectly works but looks a bit complex to me, mostly when the number of end points grows.

I was thinking of something simpler like:

  *   A2A, 4/5/6/7
  *   Override 5/6

>From a service objective point of view it would lead to a single service objectives ID plus a single override.
That said I can live with both, but would like to understand a bit more if there are operational issues implications.

Cheers,
Daniele


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: den 25 april 2022 08:15
To: Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>; John E Drake <[e-mail]<mailto:[e-mail]>>; Tarek Saad <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Specifying A2A SLO/SLEs

Hi Daniele, all,

Thank you for clarifying.

If you want to control the connectivity between a subset of SDPs, then a dedicated construct can be defined. In the example you provided, this can be achieved by the following constructs for example:

  *   A2A, 4/6/7
  *   A2A, 5/6/7
  *   P2P, 4/5

With service objectives in mind, we could have the following:

  *   common-service-objectives{IDs}
  *   A2A, 4/6/7, common-service-objectives{id}
  *   A2A, 5/6/7, common-service-objectives{id}
  *   P2P, 4/5, common-service-objectives{id}+overrides

This behavior follows the same text quoted in previous message.

Cheers,
Med

De : Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>
Envoyé : dimanche 24 avril 2022 22:17
À : John E Drake <[e-mail]<mailto:[e-mail]>>; BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; Tarek Saad <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc : TEAS WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Objet : RE: Specifying A2A SLO/SLEs

Hi John, Med,

Apologies for not being clear enough. Let's try with a couple of pictures.

The text Med is quoting is referring to a scenario like this one. Where SDP1, SDP2 and SDP3 are sending traffic to the same connectivity construct. In this case it makes perfectly sense to have different SLO/SLE for each SDP, or better to have the SLO/SLE defined against a given SDP.
[cid:image004.png@01D85B10.7875F3B0]

On the other hand in a an any to any scenario we might end up with something like figure below. Where each SDP (4,5,6,7) sends traffic to any other SDP. In our example SDP4 and SDP5 are the amin offices of our enterprise and we want to override the top level SLO/SLE e.g. adding more bandwidth between SDP4 and SDP5.  If the new SLO/SLE is defined against SDP4, that would apply not only to the connection between SDP4-SDP5 but also to the other connections that have SDP4 as head end, ie. SDP4-SDP6 and SDP4-SDP7.


[cid:image005.png@01D85B10.7875F3B0]

The conclusion is that we probably need to have the capability to define SLO/SLE both against an SDP "AND" a connectivity construct.
I hope the pictures help clarify the issue.

Cheers,
Daniele

From: John E Drake <[e-mail]<mailto:[e-mail]>>
Sent: den 22 april 2022 14:49
To: [e-mail]<mailto:[e-mail]>; Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>; Tarek Saad <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Specifying A2A SLO/SLEs

As did I

Yours Irrespectively,

John



Juniper Business Use Only
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Friday, April 22, 2022 8:39 AM
To: Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>; John E Drake <[e-mail]<mailto:[e-mail]>>; Tarek Saad <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Specifying A2A SLO/SLEs

[External Email. Be cautious of content]

Re-,

I may be missing something, but I have troubles to understand well the example. Sorry.

We need to remember that it is the construct that ** is associated with the communication type **.

Cheers,
Med

_________________________________________________________________________________________________________________________



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.