Subject: [Teas] Network slices : Issue #1 (connectivity matrix) resolution

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 25 Oct 2021 18:43:08 +0100

Hi,

There was a lot of email on this particular topic, but I think it boils down
to two things:

1. We need *a* definition to build on. Once we have this, we can construct
other things (such as slice services) based on the definition. Obviously (?)
the definition must be flexible enough to allow providers to deliver the
range of services that they want.

2. There is confusion about how to deliver a "VPN-like service" on our
definition of a network slice service.

I think the second point is the major challenge. 

The VPN service is along the lines of an any-to-any mesh with some
constraints (SLOs) applied to the senders and the receivers, but not to
specific pairs of sender/receiver. So while we can construct the VPN service
from a list of P2P connectivity matrices, or from a set of MP2P connectivity
matrices, the effect is not the same. And the MP2MP connectivity matrix is
not intended to cover this case.

I think this needs breaking out to clarify the different connectivity
matrices and to introduce a new "any-to-any" connectivity matrix
specifically to cover this.

That gives us:

P2P - This is like a private wire or a tunnel. All traffic injected at the
sender is received at the receiver. The SLOs apply at the sender (and
implicitly at the receiver).

P2MP - This is like a P2MP tunnel or multi-access VLAN segment. All traffic
at the sender is received by all receivers. The SLOs apply at the sender
(and implicitly at all receivers).

MP2P - This is like a set of P2P connections all with a common receiver. All
traffic injected at any sender is received by the single receiver. Each
sender may have a different set of SLOs (the combination of those SLOs gives
the implicit SLOs for the receiver - that is, the receiver is expected to
receive all traffic from all senders).

MP2MP - All traffic from any sender is received at all receivers (so it is
like a set of P2MP connections). Each sender may have a different set of
SLOs (the combination of those SLOs gives the implicit SLOs for each/all of
the receivers since each receiver is expect to receive all traffic from all
senders)

A2A - Any sender may send to any receiver or any set of receivers. There is
an implicit level of routing in this service that is not present in the
other services. The SLOs apply to individual senders and individual
receivers, but there is no implicit linkage and a sender may be
"disappointed" if the receiver is over-subscribed.

I believe that this captures the thrust of the many discussions, and I'd ask
you to review not as, "Is this the perfection I would like?" but as, "Can I
do everything I want with this set of connectivity matrices, and can I live
with these definitions?"

I'm going to factor this into the next version of the draft and we can
discuss it from there.

Best,
Adrian

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 29 Oct 2021 11:14:30 -0700

Hi Adrian,
Just going through the text below, one thing is unclear to me . Please bear with me, I have not fully caught up with all the discussions.

In connectivity matrix, connections are unidirectional. We say that P2MP has "one SLO" applied to all receivers and MP2P "may have different set of SLOs" (its more inclusive than P2MP definition). While independently they may be fine, for bidirectional connections, their SLOs may be related.
For example, an operator may begin with provisioning a P2MP traffic and then may want a reverse connection, for reverse traffic, Its opposite should be MP2P with the same SLO. Or they can start with MP2P with one SLO per sender and then create P2MP with same SLO for reverse traffic.

I am wondering in order to have some kind of symmetric provisioning for both the directions, would it be better if SLO descriptions for both P2MP and MP2P descriptions were consistent. i.e. can we also say for P2MP may use "any set of SLOs" ?
One more clarification - is A2A a full-mesh?
Thanks
Kiran

On Oct 25 2021, at 10:43 am, Adrian Farrel <[email-masked]> wrote:
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 29 Oct 2021 22:30:56 +0100

Hi Kiran,

Thanks for working through the changes.

In answer to your questions: you tell me!

That is, I am the pen-holder not the resolver of opinions.

However, some background.

In a unidirectional service, it is normal to specify the SLOs for the sender (the sender will send this much traffic and expect it to be delivered with this quality).

This is clearest with P2P and P2MP.

For MP2P it might seem easiest to specify the SLO at the receiver, and while that could be clear, it doesn’t help with provisioning the network because the provider needs to know which senders will be sending how much traffic.

Yes, A2A is a full mesh in the same way as a L3VPN might be.

Adrian

From: Kiran Makhijani <[email-masked]> 
Sent: 29 October 2021 19:15
To: [email-masked]
Cc: TEAS WG <[email-masked]>
Subject: Re: [Teas] Network slices : Issue #1 (connectivity matrix) resolution

Hi Adrian,

Thanks

Kiran

On Oct 25 2021, at 10:43 am, Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

to two things:

That gives us:

senders)

with these definitions?"

discuss it from there.

Best,

Adrian

Teas mailing list

[email-masked] <mailto:[email-masked]>

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 29 Oct 2021 21:02:23 -0700

Since you asked, my preference is to use set of SLOs for P2MP. Lets say I want to broadcast a live-event to A and B - A being a smartphone and B a smart TV. I want to provide the same service but due to screen size, resolution will be different, hence a different SLO.

Actually, I have tried to make sense of connectivity-matrix. if it is literally represented as a matrix (see below), it is no longer important to talk about X2Y type. The notion of connectivity is not what we started with, now it is a matrix - so why bother describing all connection types? just leave the cells empty where you don't need connections. Each row represents its own sender SLO (like A to B is s2 and B to A is s1 below).
But I don't intend to be disruptive to the forward progress of the document and only wanted to understand the rationale behind the current definition.
-----
A B C
A . 0 s2 0
B . s1 0 . 0
C . s1 . s1 0
---
Cheers,

Kiran

On Oct 29 2021, at 2:30 pm, Adrian Farrel <[email-masked]> wrote:
> On Oct 25 2021, at 10:43 am, Adrian Farrel <[email-masked] (mailto:[email-masked])> wrote:
> > Hi,
> >
> >
> >
> > [email-masked] (mailto:[email-masked])
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 30 Oct 2021 01:29:30 -0400

If the receivers are getting different traffic streams, with different 
SLOs, then that would seem to be described with different connectivity 
matrices.

I can envision more complex cases, but they get a LOT more complex.  For 
example, if the sender sends one stream, and then a (set of) video 
transcoder(s) transform the traffic for some receivers, I think we need 
a different representation.  My inclination would be to treat the video 
transcoder(s) as receiver(s) on the first pt-to-mpt, and as sender(s) on 
a separate second pt-to-mpt.  Because that is what the traffic handling 
has to do.

Yours,
Joel

On 10/30/2021 12:02 AM, Kiran Makhijani wrote:
> Since you asked, my preference is to use set of SLOs for P2MP. Lets say 
> I want to broadcast a live-event  to A and B - A being a smartphone and 
> B  a smart TV. I want to provide the same service but due to screen 
> size, resolution will be different, hence a different SLO.
> 
> Actually, I have tried to make sense of connectivity-matrix. if it is 
> literally represented as a matrix (see below), it is no longer important 
> to talk about X2Y type. The notion of connectivity is not what we 
> started with, now it is  a   matrix - so why bother describing all 
> connection types? just leave the cells empty where you don't need 
> connections. Each row represents its own sender SLO (like A to B is s2 
> and B to A is s1 below).
> 
> But I don't intend to be disruptive to the forward progress of the 
> document and only wanted to understand the rationale behind the current 
> definition.
> -----
>         A    B   C
> A .  0    s2    0
> B .   s1   0 .  0
> C .   s1 . s1  0
> ---
> Cheers,
> Kiran
> 
>     In a unidirectional service, it is normal to specify the SLOs for
>     the sender (the sender will send this much traffic and expect it to
>     be delivered with this quality).
> 
>     For MP2P it might seem easiest to specify the SLO at the receiver,
>     and while that could be clear, it doesn’t help with provisioning the
>     network because the provider needs to know which senders will be
>     sending how much traffic.
> 
> 
>     *From:* Kiran Makhijani <[email-masked]>
>     *Sent:* 29 October 2021 19:15
>     *To:* [email-masked]
>     *Cc:* TEAS WG <[email-masked]>
>     *Subject:* Re: [Teas] Network slices : Issue #1 (connectivity
>     matrix) resolution
> 
>     Hi Adrian,
>     Just going through the text below, one thing is unclear to me . 
>     Please bear with me, I have not fully caught up with all the
>     discussions.
> 
>     In connectivity matrix, connections are unidirectional.   We  say
>     that P2MP has "one SLO" applied to all receivers and MP2P  "may have
>     different set of SLOs" (its more inclusive than P2MP definition). 
>     While independently they may be fine, for bidirectional connections,
>     their SLOs may be related.
> 
>     For  example, an operator may begin with provisioning a P2MP traffic
>     and then may want a reverse connection, for reverse traffic,   Its
>     opposite should be MP2P with the same SLO. Or they can start with
>     MP2P with one SLO per sender and then create P2MP with same SLO for
>     reverse traffic.
>     I am  wondering in order to have some kind of symmetric 
>     provisioning for both the directions, would it be better if SLO
>     descriptions for both P2MP and MP2P descriptions were consistent.
>     i.e. can we also say for P2MP  may use "any set of SLOs" ?
> 
>     On Oct 25 2021, at 10:43 am, Adrian Farrel <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi,
> 
>         <https://www.ietf.org/mailman/listinfo/teas>
> 
>