Subject: [Teas] Slicing : The term Connectivity Matrix

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Nov 2021 14:23:17 -0000

There seems to be a lot of distress about the term "Connectivity Matrix".

Although, by "matrix", I intended, "The set of conditions that provides a
system in which something grows or develops," I think that the mathematician
amongst us may have assumed, "A group of numbers or other symbols arranged
in a rectangle."

So I propose to change the term (but not the meaning) in order to better
capture what the text is trying to describe.

Would "connectivity construct" suit you all?

Thanks,
Adrian

---

From: <[email-masked]>
Date: Mon, 15 Nov 2021 15:05:33 +0000

Hi Adrian, all,

I like the change. Thanks. 

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[email-masked]> De la part de Adrian Farrel
> Envoyé : lundi 15 novembre 2021 15:23
> À : [email-masked]
> Objet : [Teas] Slicing : The term Connectivity Matrix
> 
> system in which something grows or develops," I think that the
> mathematician amongst us may have assumed, "A group of numbers or other
> symbols arranged in a rectangle."
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> 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.

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 15 Nov 2021 15:46:39 +0000 (UTC)

Hi,
Connectivity matrix means that you can describe multiple connectivity constructs (each applied to a separate subset of senders/receivers) as a rectangle specified  for the full set of senders (i.e. matrix rows) and the full set of receivers (i.e. matrix columns). This is a reason why (at least) some believe that a single connectivity matrix per slice is sufficient. For what it is worth, this is how Connectivity Matrix container for a TE node is defined by the TE Topology model.
Regards,Igor

Sent from Yahoo Mail on Android 
 
  On Mon, Nov 15, 2021 at 10:05 AM, [email-masked]<[email-masked]> wrote:   Hi Adrian, all,

Cheers,
Med

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Nov 2021 15:54:31 -0000

Hi Igor,

I think you are describing a hierarchy of constructs…

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

I was previously using the term “matrix” to describe the third of these, but many people (including you?) assumed I meant the second of these.

Therefore, I want to clarify that point by using the term Connectivity Construct.

Now…

Can a slice service have more than one connectivity construct?

I believe we all agree, yes.

Could we have one connectivity construct in a slice service? 

I think that we could do that in any view of the world.

Whether we think this is a good idea or not is not important.

OK?

Thanks,

Adrian

From: Igor Bryskin <[email-masked]> 
Sent: 15 November 2021 15:47
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi,

Regards,

Igor

Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> 

On Mon, Nov 15, 2021 at 10:05 AM, [email-masked] <mailto:[email-masked]> 

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

Hi Adrian, all,

Cheers,
Med

> De : Teas <[email-masked] <mailto:[email-masked]> > De la part de Adrian Farrel
> À : [email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]> 

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

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 15 Nov 2021 17:02:09 +0000 (UTC)

Thanks, Adrian
Your description is accurate.  I am glad you are making the clarification for the term of connectivity construct.A slice service with a single connectivity construct is possible, of course,  as a trivial case. In case of a slice with multiple connectivity constructs the concept of connectivity matrix ( as hierarchy) is useful, because it allows for specifying comon connectivity construct parameters (e.g. some or all SLOs) only once, i.e. without repeating for each construct. 
Igor

  On Mon, Nov 15, 2021 at 10:54 AM, Adrian Farrel<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Tarek Saad <[email-masked]>
Date: Mon, 15 Nov 2021 17:32:50 +0000

Hi Adrian,

Thanks. Please see inline..

From: Teas <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Date: Monday, November 15, 2021 at 10:55 AM
To: 'Igor Bryskin' <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix
Hi Igor,

Slice Service…
   Connectivity Matrix…
       Connectivity Construct…
[TS]: yes, this is similar to what I pointed out too in a couple of emails and on mic. I’ll maybe highlight that the `connectivity constructs` belonging to a specific connectivity matrix have the same type (i.e. connectivity matrix has the type, e.g. p2p)

Now…
Can a slice service have more than one connectivity construct?
I believe we all agree, yes.
[TS]: I also believe so. As an example, I should be able to create a connectivity matrix type=p2p and another for type=p2mp – this should not preclude creating 2 connectivity matrices of same type.

OK?
[TS]: yes, one point to bring up still is composite connectivity matrix types (like mp2p, mp2mp, etc.). IMO, these can be simply derived from the base type (p2p and p2mp) – or am I missing something?

Regards,
Tarek

Thanks,
Adrian

Hi,

Regards,
Igor
Sent from Yahoo Mail on Android<https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>

On Mon, Nov 15, 2021 at 10:05 AM, [email-masked]<mailto:[email-masked]>
<[email-masked]<mailto:[email-masked]>> wrote:
Hi Adrian, all,

Cheers,
Med

> De : Teas <[email-masked]<mailto:[email-masked]>> De la part de Adrian Farrel
> À : [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Nov 2021 18:08:28 -0000

I agree.

Although I *think* that, in this hierarchy, the matrix is a convenience rather than an essential.

It will almost certainly show up in the YANG model as a way of (as you say) clustering together the connectivity constructs within a slice service.

(Trying to not confuse myself with old and new meanings :-)

A

From: Tarek Saad <[email-masked]> 
Sent: 15 November 2021 17:33
To: [email-masked]; 'Igor Bryskin' <[email-masked]>; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Adrian,

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Regards,

Tarek

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,
Med

---

From: "Kiran Makhijani" <[email-masked]>
Date: Mon, 15 Nov 2021 19:40:01 +0000

Hi:
+1 on proposal to use connectivity constructs instead.

And I think, it is better that way (i.e. the connectivity matrix to show 
up in YANG).  It makes more sense to express connectivity structure from 
a customer’s view. Framework simply should state what they are.

-Kiran

------ Original Message ------
From: "Adrian Farrel" <[email-masked]>
To: "Tarek Saad" <[email-masked]>; "Igor Bryskin" 
<[email-masked]>; [email-masked]
Sent: 11/15/2021 10:08:28 AM
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

>It will almost certainly show up in the YANG model as a way of (as you 
>say) clustering together the connectivity constructs within a slice 
>service.
>
>
>
>[TS]: yes, this is similar to what I pointed out too in a couple of 
>emails and on mic. I’ll maybe highlight that the `connectivity 
>constructs` belonging to a specific connectivity matrix have the same 
>type (i.e. connectivity matrix has the type, e.g. p2p)
>
>
>
>I was previously using the term “matrix” to describe the third of 
>these, but many people (including you?) assumed I meant the second of 
>these.
>
>
>
>[TS]: I also believe so. As an example, I should be able to create a 
>connectivity matrix type=p2p and another for type=p2mp – this should 
>not preclude creating 2 connectivity matrices of same type.
>
>
>
>[TS]: yes, one point to bring up still is composite connectivity matrix 
>types (like mp2p, mp2mp, etc.). IMO, these can be simply derived from 
>the base type (p2p and p2mp) – or am I missing something?
>
>
>
>Regards,
>
>Tarek
>
>
>
>Thanks,
>
>Adrian
>
>
>
>Connectivity matrix means that you can describe multiple connectivity 
>constructs (each applied to a separate subset of senders/receivers) as 
>a rectangle specified  for the full set of senders (i.e. matrix rows) 
>and the full set of receivers (i.e. matrix columns). This is a reason 
>why (at least) some believe that a single connectivity matrix per slice 
>is sufficient. For what it is worth, this is how Connectivity Matrix 
>container for a TE node is defined by the TE Topology model.
>
>
>
>Regards,
>
>Igor
>
><https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
>
>
>>On Mon, Nov 15, 2021 at 10:05 AM, [email-masked]
>>
>><[email-masked]> wrote:
>>
>>Hi Adrian, all,
>>
>>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,
>>This message and its attachments may contain confidential or 
>>privileged information that may be protected by law;

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 15 Nov 2021 20:39:19 +0000

Fine also for me.

Regarding what Tarek mentions: “one point to bring up still is composite connectivity matrix types (like mp2p, mp2mp, etc.). IMO, these can be simply derived from the base type (p2p and p2mp)”

In previous discussions on the list, the p2mp case was associated to multicast-like communication. However, it does not necessarily could be the case. So I wonder if we could consider simply p2p as the basic relation and then indicating either unicast or multicast as the way of defining how to deal with the traffic for that construct. Aggregation of such basic p2p’s (i.e. groupings of unicast_p2p or multicast_p2p) will help to create whatever of the other schemas (p2mp, a2a, mp2mp, …) in a non-ambiguous way.

Best regards

Luis

De: Teas <[email-masked]> En nombre de Kiran Makhijani
Enviado el: lunes, 15 de noviembre de 2021 20:40
Para: [email-masked]; Tarek Saad <[email-masked]>; Igor Bryskin <[email-masked]>; [email-masked]
Asunto: Re: [Teas] Slicing : The term Connectivity Matrix

Hi:

And I think, it is better that way (i.e. the connectivity matrix to show up in YANG).  It makes more sense to express connectivity structure from a customer’s view. Framework simply should state what they are.

-Kiran

------ Original Message ------
From: "Adrian Farrel" <[email-masked]<mailto:[email-masked]>>
To: "Tarek Saad" <[email-masked]<mailto:[email-masked]>>; "Igor Bryskin" <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Sent: 11/15/2021 10:08:28 AM
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

I agree.

A

From: Tarek Saad <[email-masked]<mailto:[email-masked]>>
Sent: 15 November 2021 17:33
To: [email-masked]<mailto:[email-masked]>; 'Igor Bryskin' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Adrian,

From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 15, 2021 at 10:55 AM
To: 'Igor Bryskin' <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Regards,

Tarek

Thanks,

Adrian

From: Igor Bryskin <[email-masked]<mailto:[email-masked]>>
Sent: 15 November 2021 15:47
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,
Med

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 15 Nov 2021 21:46:19 +0000 (UTC)

Adrian and All, 
I do not disagree with you,  guys.However, consider a slice service with N edges requiring full mesh p2p connectivity with identical SLOs ( e.g. delay under 5ms). Do you expect the service requestor to specify 5ms N**2 times, or would you allow to just say once 5ms for any pair of edges [except between edges X and Y that require 3ms] ?
Igor

  On Mon, Nov 15, 2021 at 3:39 PM, LUIS MIGUEL CONTRERAS MURILLO<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Nov 2021 21:15:44 -0500

There are at least two levels of requestor.  The interface the human 
requestor uses is likely to have all sorts of shortcuts, depending upon 
implementation.
The question exactly identical service descriptions is whether the 
machine-to-machine representation significantly benefits from havign its 
own shortcut.  Clearly, we do not need it.
Note that even with such a shortcut in the machine representaiton, the 
systems will need to send descriptions to each edge.  A factor of N in 
scaling can be beneficial.  But I have rarely seen cases where the 
service is identical at all of the many points.

Yours,
Joel

On 11/15/2021 4:46 PM, Igor Bryskin wrote:
> Adrian and All,
> 
> I do not disagree with you,  guys.
> However, consider a slice service with N edges requiring full mesh p2p 
> connectivity with identical SLOs ( e.g. delay under 5ms). Do you expect 
> the service requestor to specify 5ms N**2 times, or would you allow to 
> just say once 5ms for any pair of edges [except between edges X and Y 
> that require 3ms] ?
> 
> Igor
> 
>     On Mon, Nov 15, 2021 at 3:39 PM, LUIS MIGUEL CONTRERAS MURILLO
>     <[email-masked]> wrote:
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 15 Nov 2021 23:11:38 -0500

Hi Adrian

I agree with Connectivity Construct.

I think having the connectivity construct provides the base building block
P2P for any connectivity matrix type which could be made up of multiple P2P
so could be P2MP, MP2P or MP2MP per Tarek’s comments.

Responses in-line

On Mon, Nov 15, 2021 at 12:33 PM Tarek Saad <[email-masked]> wrote:

> *From: *Teas <[email-masked]> on behalf of Adrian Farrel <
> [email-masked]>
> *Date: *Monday, November 15, 2021 at 10:55 AM
> *To: *'Igor Bryskin' <[email-masked]>, [email-masked] <[email-masked]>
> *Subject: *Re: [Teas] Slicing : The term Connectivity Matrix
>
> Hi Igor,
>
>
>
> [TS]: yes, this is similar to what I pointed out too in a couple of emails
> and on mic. I’ll maybe highlight that the `connectivity constructs`
> belonging to a specific connectivity matrix have the same type (i.e.
> connectivity matrix has the type, e.g. p2p)
>
 Gyan> Agreed.  This is making more sense now
So a connectivity construct would be P2P and connectivity matrix would be
made up of multiple connectivity constructs.

> I was previously using the term “matrix” to describe the third of these,
> but many people (including you?) assumed I meant the second of these.
>
>
>
> connectivity matrix type=p2p and another for type=p2mp – this should not
> preclude creating 2 connectivity matrices of same type.
>
>  Gyan> Yes believe so.  In your example I would think that P2P as is the
> base connectivity construct I guess it could be a connectivity matrix also
>  but I would think that it is not.
>
> types (like mp2p, mp2mp, etc.). IMO, these can be simply derived from the
> base type (p2p and p2mp) – or am I missing something?
>
>  Gyan> Agreed I believe so
>
Regards,
>
> Tarek
>
>
>
> Thanks,
>
> Adrian
>
>
>
> *From:* Igor Bryskin <[email-masked]>
> *Sent:* 15 November 2021 15:47
> *To:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [Teas] Slicing : The term Connectivity Matrix
>
>
>
> Hi,
>
>
>
> constructs (each applied to a separate subset of senders/receivers) as a
> rectangle specified  for the full set of senders (i.e. matrix rows) and the
> full set of receivers (i.e. matrix columns). This is a reason why (at
> least) some believe that a single connectivity matrix per slice is
> sufficient. For what it is worth, this is how Connectivity Matrix container
> for a TE node is defined by the TE Topology model.
>
>
>
> Regards,
>
> Igor
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 16 Nov 2021 11:00:02 +0000

Hi Igor,
To go on with comparison to what defined in RFC 8795, in the topology we have connectivity-matrices (that would be connectivity matrix here in the discussion) umbrella for a list of connectivity-matrix (connectivity construct here).
Is correct my understanding ?

Thanks
Sergio

From: Teas <[email-masked]> On Behalf Of Igor Bryskin
Sent: Monday, November 15, 2021 4:47 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi,

Regards,
Igor

Cheers,
Med

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 16 Nov 2021 14:40:07 +0000 (UTC)

Yes, Sergio. Your understanding is correct.
Igir
    On Tuesday, November 16, 2021, 06:00:04 AM EST, Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]> wrote:  
 
 <!--#yiv7373807720 _filtered {} _filtered {} _filtered {}#yiv7373807720 #yiv7373807720 p.yiv7373807720MsoNormal, #yiv7373807720 li.yiv7373807720MsoNormal, #yiv7373807720 div.yiv7373807720MsoNormal {margin:0cm;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv7373807720 a:link, #yiv7373807720 span.yiv7373807720MsoHyperlink {color:blue;text-decoration:underline;}#yiv7373807720 .yiv7373807720MsoChpDefault {font-family:"Calibri", sans-serif;} _filtered {}#yiv7373807720 div.yiv7373807720WordSection1 {}-->
Hi Igor,

 
Thanks
 
Sergio

 
Hi,

 
Regards,
 
Igor

 

On Mon, Nov 15, 2021 at 10:05 AM,[email-masked]

Hi Adrian, all,

Cheers,
Med

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 16 Nov 2021 15:20:19 +0000 (UTC)

Hi Joel,
requestor uses is likely to have all sorts of shortcuts, depending upon
implementation.
The question exactly identical service descriptions is whether the
machine-to-machine representation significantly benefits from havign its
own shortcut.  Clearly, we do not need it.
IB>> Then why in IETF interfaces/models (e.g. for managing TE tunnels) we define things like templates, named objects, etc. if not to alleviate the client from repeating the same pieces of configuration over and over again? Also this is not limited to just client convenience. When on the provider side one investigates a problem, least of all one wants to wade through the volumes of traces with totally avoidable repetitions of the same data.  >Note that even with such a shortcut in the machine representaiton, the
systems will need to send descriptions to each edge. IB>> Ah, but this would be over a different interface (SBI) with each edge being a separate server processing a single set of (complete, of course) configuration
>A factor of N in
scaling can be beneficial. IB>> Scalability, of course, is a concern
 >But I have rarely seen cases where the
service is identical at all of the many points.IB>> The service does not have to be fully identical. Only (predominantly) common parameters could be specified for the entire connectivity matrix defaults, with each of its entries being free to overwrite the defaults with entry specific values.
I find this discussion useful. Interestingly, the previous discussion on the same topic was equally heated, but in the hindsight quite comical now that we know that about half of the participants was interpreting the term "connectivity matrix" in a totally differently way than the other half :)
Regards,Igor

    On Tuesday, November 16, 2021, 09:40:39 AM EST, Igor Bryskin <i_bryskin=[email-masked]> wrote:  

 <!--#yiv9846783969 filtered {}#yiv9846783969 filtered {}#yiv9846783969 filtered {}#yiv9846783969 p.yiv9846783969MsoNormal, #yiv9846783969 li.yiv9846783969MsoNormal, #yiv9846783969 div.yiv9846783969MsoNormal {margin:0cm;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv9846783969 a:link, #yiv9846783969 span.yiv9846783969MsoHyperlink {color:blue;text-decoration:underline;}#yiv9846783969 .yiv9846783969MsoChpDefault {font-family:"Calibri", sans-serif;}#yiv9846783969 filtered {}#yiv9846783969 div.yiv9846783969WordSection1 {}-->
Hi Igor,

 
Thanks
 
Sergio

 
Hi,

 
Regards,
 
Igor

 

 
Hi Adrian, all,

Cheers,
Med

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 16 Nov 2021 16:29:34 +0100

Hi,

I second Luis here.

The connectivity construct should cover couple of aspects, e.g.

a) end-points connectivity (i.,e. P2P, P2MP, etc.)
b) forwarding behavior for MP types (i.e. unicast to single end-point, or replication to multiple end-points: multicast/broadcast)
c) forwarding decision for MP types (i.e., how the end-point is selected for unicast: manual/static, or dynamically learned via some dynamic protocols; mcast: how the subset of end-points is selected: manual/static, or dynamically learned via some dynamic protocols)
d) how the SLOs are assigned for MP types (on a point-to-point basis; or on MP aggregation bases -> i.e. CE1 can send to N remaining CEs X amount of traffic, without specifying individually the amount towards each receiver CE)

All above elements should be part of connectivity construct definition, IMHO.

Best regards,
Krzysztof

> On 2021 -Nov-15, at 21:39, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> wrote:
> 
> Fine also for me.
>  
> De: Teas <[email-masked] <mailto:[email-masked]>> En nombre de Kiran Makhijani
> Para: [email-masked] <mailto:[email-masked]>; Tarek Saad <[email-masked] <mailto:[email-masked]>>; Igor Bryskin <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> From: "Adrian Farrel" <[email-masked] <mailto:[email-masked]>>
> To: "Tarek Saad" <[email-masked] <mailto:[email-masked]>>; "Igor Bryskin" <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> From: Tarek Saad <[email-masked] <mailto:[email-masked]>> 
> To: [email-masked] <mailto:[email-masked]>; 'Igor Bryskin' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> From: Teas <[email-masked] <mailto:[email-masked]>> on behalf of Adrian Farrel <[email-masked] <mailto:[email-masked]>>
> To: 'Igor Bryskin' <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> From: Igor Bryskin <[email-masked] <mailto:[email-masked]>> 
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>>
>  
>  
>  
> <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Adrian, all,
> 
> > De : Teas <[email-masked] <mailto:[email-masked]>> De la part de Adrian Farrel
> > https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>
> 
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>
>  
> 
> 
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>

---

From: Tarek Saad <[email-masked]>
Date: Tue, 16 Nov 2021 16:10:34 +0000

There are two things that p2mp could indicate:

  1.  P2MP connectivity (simply a group of p2p connections from the same source)
  2.  P2MP packet delivery (i.e. multicasting or replication service from one sender to multiple receivers)

I think the draft describes p2mp connectivity matrix to mean both for 1) connectivity and for 2) multicast packet delivery.

   o  For a P2MP connectivity matrix, there is only one sending CE and
      more than one receiving CE.  This is like a P2MP tunnel or multi-
      access VLAN segment.  All traffic from the sending CE is intended
      to be received by all the receiving CEs.

However, for Any-to-Any (AFAI understand it), I think it is a mesh of p2p connectivity, without any replication packet delivery.

      With an A2A matrix, any sending CE may send to any one receiving
      CE or any set of receiving CEs.  There is an implicit level of
      routing in this connectivity matrix that is not present in the
      other connectivity matrices as the matrix must determine to which
      receiving CEs to deliver each packet.

Maybe connectivity type and packet replication service can be different attributes of a connectivity matrix – so in theory for
A2A I can enable replication packet delivery and it would be able to do `broadcast`.

Regards,
Tarek

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tuesday, November 16, 2021 at 10:29 AM
To: Luis Miguel Contreras Murillo <[email-masked]>
Cc: Kiran Makhijani <[email-masked]>, [email-masked] <[email-masked]>, Tarek Saad <[email-masked]>, Igor Bryskin <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix
Hi,

I second Luis here.

Best regards,
Krzysztof

On 2021 -Nov-15, at 21:39, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>> wrote:

Fine also for me.

Best regards

Luis

De: Teas <[email-masked]<mailto:[email-masked]>> En nombre de Kiran Makhijani
Enviado el: lunes, 15 de noviembre de 2021 20:40
Para: [email-masked]<mailto:[email-masked]>; Tarek Saad <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Asunto: Re: [Teas] Slicing : The term Connectivity Matrix

Hi:

-Kiran

------ Original Message ------
From: "Adrian Farrel" <[email-masked]<mailto:[email-masked]>>
To: "Tarek Saad" <[email-masked]<mailto:[email-masked]>>; "Igor Bryskin" <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Sent: 11/15/2021 10:08:28 AM
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

I agree.

A

Hi Adrian,

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Regards,

Tarek

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,
Med

---

From: "Kiran Makhijani" <[email-masked]>
Date: Tue, 16 Nov 2021 16:39:47 +0000

For me, wanting to say these connectivity constructs are multicast, 
broadcast is an unnecessary burden since they are specific to traffic. 
What is important for a customer is to first express how endpoints are 
connected to other endpoints. One may have different type/cast of 
traffic allowed to flow across these endpoints.

Cheers,
Kiran

------ Original Message ------
From: "Tarek Saad" <[email-masked]>
To: "Krzysztof Szarkowicz" <[email-masked]>; "Luis Miguel 
Contreras Murillo" <[email-masked]>
Cc: "Kiran Makhijani" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "Igor Bryskin" <[email-masked]>; 
"[email-masked]" <[email-masked]>
Sent: 11/16/2021 8:10:34 AM
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

>P2MP connectivity (simply a group of p2p connections from the same 
>source)P2MP packet delivery (i.e. multicasting or replication service 
>from one sender to multiple receivers)
>
>
>I think the draft describes p2mp connectivity matrix to mean both for 
>1) connectivity and for 2) multicast packet delivery.
>
>
>
>However, for Any-to-Any (AFAI understand it), I think it is a mesh of 
>p2p connectivity, without any replication packet delivery.
>
>
>
>Maybe connectivity type and packet replication service can be different 
>attributes of a connectivity matrix – so in theory for
>
>To: Luis Miguel Contreras Murillo 
><[email-masked]>
>Cc: Kiran Makhijani <[email-masked]>, [email-masked] 
><[email-masked]>, Tarek Saad <[email-masked]>, Igor Bryskin 
><[email-masked]>, [email-masked] <[email-masked]>
>b) forwarding behavior for MP types (i.e. unicast to single end-point, 
>or replication to multiple end-points: multicast/broadcast)
>
>c) forwarding decision for MP types (i.e., how the end-point is 
>selected for unicast: manual/static, or dynamically learned via some 
>dynamic protocols; mcast: how the subset of end-points is selected: 
>manual/static, or dynamically learned via some dynamic protocols)
>
>d) how the SLOs are assigned for MP types (on a point-to-point basis; 
>or on MP aggregation bases -> i.e. CE1 can send to N remaining CEs X 
>amount of traffic, without specifying individually the amount towards 
>each receiver CE)
>
>
>
>>On 2021 -Nov-15, at 21:39, LUIS MIGUEL CONTRERAS MURILLO 
>>Regarding what Tarek mentions: “one point to bring up still is 
>>composite connectivity matrix types (like mp2p, mp2mp, etc.). IMO, 
>>these can be simply derived from the base type (p2p and p2mp)”
>>
>>
>>
>>In previous discussions on the list, the p2mp case was associated to 
>>multicast-like communication. However, it does not necessarily could 
>>be the case. So I wonder if we could consider simply p2p as the basic 
>>relation and then indicating either unicast or multicast as the way of 
>>defining how to deal with the traffic for that construct. Aggregation 
>>of such basic p2p’s (i.e. groupings of unicast_p2p or multicast_p2p) 
>>will help to create whatever of the other schemas (p2mp, a2a, mp2mp, 
>>…) in a non-ambiguous way.
>>
>>
>>
>>Best regards
>>
>>
>>
>>Luis
>>
>>
>>
>>Para: [email-masked]; Tarek Saad <[email-masked]>; Igor 
>>Bryskin <[email-masked]>; [email-masked]
>>And I think, it is better that way (i.e. the connectivity matrix to 
>>show up in YANG).  It makes more sense to express connectivity 
>>structure from a customer’s view. Framework simply should state what 
>>they are.
>>
>>
>>
>>-Kiran
>>
>>
>>
>>>It will almost certainly show up in the YANG model as a way of (as 
>>>you say) clustering together the connectivity constructs within a 
>>>slice service.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>[TS]: yes, one point to bring up still is composite connectivity 
>>>matrix types (like mp2p, mp2mp, etc.). IMO, these can be simply 
>>>derived from the base type (p2p and p2mp) – or am I missing 
>>>something?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Regards,
>>>
>>>
>>>
>>>Tarek
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Thanks,
>>>
>>>
>>>
>>>Adrian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>constructs (each applied to a separate subset of senders/receivers) 
>>>as a rectangle specified  for the full set of senders (i.e. matrix 
>>>rows) and the full set of receivers (i.e. matrix columns). This is a 
>>>reason why (at least) some believe that a single connectivity matrix 
>>>per slice is sufficient. For what it is worth, this is how 
>>>Connectivity Matrix container for a TE node is defined by the TE 
>>>Topology model.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Regards,
>>>
>>>
>>>
>>>Igor
>>>
>>>
>>>
>>>>pas etre diffuses, exploites ou copies sans autorisation. Si vous 
>>>>avez recu ce message par erreur, veuillez le signaler
>>>>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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>--------------------------------------------------------------------------------
>>
>>Este mensaje y sus adjuntos se dirigen exclusivamente a su 
>>destinatario, puede contener información privilegiada o confidencial y 
>>es para uso exclusivo de la persona o entidad de destino. Si no es 
>>usted. el destinatario indicado, queda notificado de que la lectura, 
>>utilización, divulgación y/o copia sin autorización puede estar 
>>prohibida en virtud de la legislación vigente. Si ha recibido este 
>>mensaje por error, le rogamos que nos lo comunique inmediatamente por 
>>esta misma vía y proceda a su destrucción.
>>
>>The information contained in this transmission is privileged and 
>>confidential information intended only for the use of the individual 
>>or entity named above. If the reader of this message is not the 
>>intended recipient, you are hereby notified that any dissemination, 
>>distribution or copying of this communication is strictly prohibited. 
>>If you have received this transmission in error, do not read it. 
>>Please immediately reply to the sender that you have received this 
>>communication in error and then delete it.
>>
>>Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
>>destinatário, pode conter informação privilegiada ou confidencial e é 
>>para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
>>senhoria o destinatário indicado, fica notificado de que a leitura, 
>>utilização, divulgação e/ou cópia sem autorização pode estar proibida 
>>em virtude da legislação vigente. Se recebeu esta mensagem por erro, 
>>rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
>>proceda a sua destruição

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 16 Nov 2021 16:56:55 +0000

Thanks Igor for confirmation !
Sergio

From: Igor Bryskin <[email-masked]>
Sent: Tuesday, November 16, 2021 3:40 PM
To: [email-masked]; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Igir

On Tuesday, November 16, 2021, 06:00:04 AM EST, Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Igor,

Thanks

Sergio

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Igor Bryskin
Sent: Monday, November 15, 2021 4:47 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,
Med

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 16 Nov 2021 17:13:38 +0000 (UTC)

Speaking of connectivity  constructs and hierarchies of thereof (connectivity matrices). It is possible to express connectivity construct of one type as connectivity matrix of another type. For example, one  way to express/describe a mp2mp  connectivity construct  as p2mp connectivity matrix.
Igor

  On Tue, Nov 16, 2021 at 11:39 AM, Kiran Makhijani<[email-masked]> wrote:   #yiv4649245671 blockquote.yiv4649245671cite {margin-left:5px;margin-right:0px;padding-left:10px;padding-right:0px;border-left:1px solid #cccccc;}#yiv4649245671 blockquote.yiv4649245671cite2 {margin-left:5px;margin-right:0px;padding-left:10px;padding-right:0px;border-left:1px solid #cccccc;margin-top:3px;padding-top:0px;}#yiv4649245671 a img {border:0px;}#yiv4649245671 For me, wanting to say these connectivity constructs are multicast, broadcast is an unnecessary burden since they are specific to traffic. What is important for a customer is to first express how endpoints are connected to other endpoints. One may have different type/cast of traffic allowed to flow across these endpoints.
Cheers,Kiran
------ Original Message ------From: "Tarek Saad" <[email-masked]>To: "Krzysztof Szarkowicz" <[email-masked]>; "Luis Miguel Contreras Murillo" <[email-masked]>Cc: "Kiran Makhijani" <[email-masked]>; "[email-masked]" <[email-masked]>; "Igor Bryskin" <[email-masked]>; "[email-masked]" <[email-masked]>Sent: 11/16/2021 8:10:34 AMSubject: Re: [Teas] Slicing : The term Connectivity Matrix

There are two things that p2mp could indicate: P2MP connectivity (simply a group of p2p connections from the same source)P2MP packet delivery (i.e. multicasting or replication service from one sender to multiple receivers)  I think the draft describes p2mp connectivity matrix to mean both for 1) connectivity and for 2) multicast packet delivery.      o  For a P2MP connectivity matrix, there is only one sending CE and       more than one receiving CE.  This is like a P2MP tunnel or multi-       access VLAN segment.  All traffic from the sending CE is intended       to be received by all the receiving CEs.   However, for Any-to-Any (AFAI understand it), I think it is a mesh of p2p connectivity, without any replication packet delivery.         With an A2A matrix, any sending CE may send to any one receiving       CE or any set of receiving CEs.  There is an implicit level of       routing in this connectivity matrix that is not present in the       other connectivity matrices as the matrix must determine to which       receiving CEs to deliver each packet.    Maybe connectivity type and packet replication service can be different attributes of a connectivity matrix – so in theory for A2A I can enable replication packet delivery and it would be able to do `broadcast`.   Regards, Tarek     From:Krzysztof Szarkowicz <[email-masked]>
Date: Tuesday, November 16, 2021 at 10:29 AM
To: Luis Miguel Contreras Murillo <[email-masked]>
Cc: Kiran Makhijani <[email-masked]>, [email-masked] <[email-masked]>, Tarek Saad <[email-masked]>, Igor Bryskin <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix Hi,   I second Luis here.   The connectivity construct should cover couple of aspects, e.g.   a) end-points connectivity (i.,e. P2P, P2MP, etc.) b) forwarding behavior for MP types (i.e. unicast to single end-point, or replication to multiple end-points: multicast/broadcast) c) forwarding decision for MP types (i.e., how the end-point is selected for unicast: manual/static, or dynamically learned via some dynamic protocols; mcast: how the subset of end-points is selected: manual/static, or dynamically learned via some dynamic protocols) d) how the SLOs are assigned for MP types (on a point-to-point basis; or on MP aggregation bases -> i.e. CE1 can send to N remaining CEs X amount of traffic, without specifying individually the amount towards each receiver CE)   All above elements should be part of connectivity construct definition, IMHO.   Best regards, Krzysztof 

On 2021 -Nov-15, at 21:39, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> wrote:   Fine also for me.   Regarding what Tarek mentions: “one point to bring up still is composite connectivity matrix types (like mp2p, mp2mp, etc.). IMO, these can be simply derived from the base type (p2p and p2mp)”   In previous discussions on the list, the p2mp case was associated to multicast-like communication. However, it does not necessarily could be the case. So I wonder if we could consider simply p2p as the basic relation and then indicating either unicast or multicast as the way of defining how to deal with the traffic for that construct. Aggregation of such basic p2p’s (i.e. groupings of unicast_p2p or multicast_p2p) will help to create whatever of the other schemas (p2mp, a2a, mp2mp, …) in a non-ambiguous way.   Best regards   Luis   De: Teas <[email-masked]> En nombre de Kiran Makhijani
Enviado el: lunes, 15 de noviembre de 2021 20:40
Para: [email-masked]; Tarek Saad <[email-masked]>; Igor Bryskin <[email-masked]>; [email-masked]
Asunto: Re: [Teas] Slicing : The term Connectivity Matrix   Hi: +1 on proposal to use connectivity constructs instead.   And I think, it is better that way (i.e. the connectivity matrix to show up in YANG).  It makes more sense to express connectivity structure from a customer’s view. Framework simply should state what they are.   -Kiran   ------ Original Message ------ From: "Adrian Farrel" <[email-masked]> To: "Tarek Saad" <[email-masked]>; "Igor Bryskin" <[email-masked]>; [email-masked] Sent: 11/15/2021 10:08:28 AM Subject: Re: [Teas] Slicing : The term Connectivity Matrix   
I agree.       Although I *think* that, in this hierarchy, the matrix is a convenience rather than an essential.   It will almost certainly show up in the YANG model as a way of (as you say) clustering together the connectivity constructs within a slice service.       (Trying to not confuse myself with old and new meanings :-)       A       From: Tarek Saad <[email-masked]> 
Sent: 15 November 2021 17:33
To: [email-masked]; 'Igor Bryskin' <[email-masked]>; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix       Hi Adrian,       Thanks. Please see inline..       From: Teas <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Date: Monday, November 15, 2021 at 10:55 AM
To: 'Igor Bryskin' <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix   Hi Igor,       I think you are describing a hierarchy of constructs…       Slice Service…      Connectivity Matrix…          Connectivity Construct…   [TS]: yes, this is similar to what I pointed out too in a couple of emails and on mic. I’ll maybe highlight that the `connectivity constructs` belonging to a specific connectivity matrix have the same type (i.e. connectivity matrix has the type, e.g. p2p)       I was previously using the term “matrix” to describe the third of these, but many people (including you?) assumed I meant the second of these.       Therefore, I want to clarify that point by using the term Connectivity Construct.       Now…   Can a slice service have more than one connectivity construct?   I believe we all agree, yes.   [TS]: I also believe so. As an example, I should be able to create a connectivity matrix type=p2p and another for type=p2mp – this should not preclude creating 2 connectivity matrices of same type.       Could we have one connectivity construct in a slice service?   I think that we could do that in any view of the world.   Whether we think this is a good idea or not is not important.       OK?   [TS]: yes, one point to bring up still is composite connectivity matrix types (like mp2p, mp2mp, etc.). IMO, these can be simply derived from the base type (p2p and p2mp) – or am I missing something?       Regards,   Tarek       Thanks,   Adrian       From: Igor Bryskin <[email-masked]> 
Sent: 15 November 2021 15:47
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix       Hi,       Connectivity matrix means that you can describe multiple connectivity constructs (each applied to a separate subset of senders/receivers) as a rectangle specified  for the full set of senders (i.e. matrix rows) and the full set of receivers (i.e. matrix columns). This is a reason why (at least) some believe that a single connectivity matrix per slice is sufficient. For what it is worth, this is how Connectivity Matrix container for a TE node is defined by the TE Topology model.       Regards,   Igor   Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>       
On Mon, Nov 15, 2021 at 10:05 AM, [email-masked]   <[email-masked]> wrote:   Hi Adrian, all,

Cheers,
Med

---

From: Loa Andersson <[email-masked]>
Date: Wed, 17 Nov 2021 10:46:40 +0100

Folks,

This is a naming discussing, perfect names are almost impossible. 
However once you settle for a name it is gradual filled with the content 
needed/wanted.

Adrian wants to change "connectivity matrices" to "connectivity 
constructs". I have no opinion on the brilliance of that change.

However, reading all mails on the subject and thinking offline a bit I 
find that I can live with "connectivity constructs".

So I would like to ask those of you that have participated in the naming 
discussion if it would be possible to step back and think about if it is 
possible to live with "connectivity constructs", understanding that 
there might be a name that you personal prefer?

/Loa

On 2021-11-16 18:13, Igor Bryskin wrote:
> Speaking of connectivity  constructs and hierarchies of thereof 
> (connectivity matrices). It is possible to express connectivity 
> construct of one type as connectivity matrix of another type. For 
> example, one  way to express/describe a mp2mp  connectivity construct  
> as p2mp connectivity matrix.
> 
> Igor
> 
>     On Tue, Nov 16, 2021 at 11:39 AM, Kiran Makhijani
>     <[email-masked]> wrote:
>     broadcast is an unnecessary burden since they are specific to
>     traffic. What is important for a customer is to first express how
>     endpoints are connected to other endpoints. One may have different
>     type/cast of traffic allowed to flow across these endpoints.
> 
>     Cheers,
>     Kiran
> 
>>     source)P2MP packet delivery (i.e. multicasting or replication
>>     service from one sender to multiple receivers)
>>     I think the draft describes p2mp connectivity matrix to mean both
>>     for 1) connectivity and for 2) multicast packet delivery.
>>     However, for Any-to-Any (AFAI understand it), I think it is a mesh
>>     of p2p connectivity, without any replication packet delivery.
>>     Maybe connectivity type and packet replication service can be
>>     different attributes of a connectivity matrix – so in theory for
>>     <[email-masked]>, Tarek Saad <[email-masked]>, Igor
>>     Bryskin <[email-masked]>, [email-masked] <[email-masked]>
>>     b) forwarding behavior for MP types (i.e. unicast to single
>>     end-point, or replication to multiple end-points: multicast/broadcast)
>>     selected for unicast: manual/static, or dynamically learned via
>>     some dynamic protocols; mcast: how the subset of end-points is
>>     selected: manual/static, or dynamically learned via some dynamic
>>     protocols)
>>     d) how the SLOs are assigned for MP types (on a point-to-point
>>     basis; or on MP aggregation bases -> i.e. CE1 can send to
>>     N remaining CEs X amount of traffic, without specifying
>>     individually the amount towards each receiver CE)
>>         composite connectivity matrix types (like mp2p, mp2mp, etc.).
>>         IMO, these can be simply derived from the base type (p2p and
>>         p2mp)”
>>         In previous discussions on the list, the p2mp case was
>>         associated to multicast-like communication. However, it does
>>         not necessarily could be the case. So I wonder if we could
>>         consider simply p2p as the basic relation and then indicating
>>         either unicast or multicast as the way of defining how to deal
>>         with the traffic for that construct. Aggregation of such basic
>>         p2p’s (i.e. groupings of unicast_p2p or multicast_p2p) will
>>         help to create whatever of the other schemas (p2mp, a2a,
>>         mp2mp, …) in a non-ambiguous way.
>>         Best regards
>>         Luis
>>         Para: [email-masked]; Tarek Saad <[email-masked]>;
>>         Igor Bryskin <[email-masked]>; [email-masked]
>>         And I think, it is better that way (i.e. the connectivity
>>         matrix to show up in YANG).  It makes more sense to express
>>         connectivity structure from a customer’s view. Framework
>>         simply should state what they are.
>>         -Kiran
>>             It will almost certainly show up in the YANG model as a
>>             way of (as you say) clustering together the connectivity
>>             constructs within a slice service.
>>             To: 'Igor Bryskin'
>>             [TS]: yes, this is similar to what I pointed out too in a
>>             couple of emails and on mic. I’ll maybe highlight that the
>>             `connectivity constructs` belonging to a specific
>>             connectivity matrix have the same type (i.e. connectivity
>>             matrix has the type, e.g. p2p)
>>             I was previously using the term “matrix” to describe the
>>             third of these, but many people (including you?) assumed I
>>             meant the second of these.
>>             [TS]: I also believe so. As an example, I should be able
>>             to create a connectivity matrix type=p2p and another for
>>             type=p2mp – this should not preclude creating 2
>>             connectivity matrices of same type.
>>             [TS]: yes, one point to bring up still is composite
>>             connectivity matrix types (like mp2p, mp2mp, etc.). IMO,
>>             these can be simply derived from the base type (p2p and
>>             p2mp) – or am I missing something?
>>             Regards,
>>             Tarek
>>             Thanks,
>>             Adrian
>>             Connectivity matrix means that you can describe multiple
>>             connectivity constructs (each applied to a separate subset
>>             of senders/receivers) as a rectangle specified  for the
>>             full set of senders (i.e. matrix rows) and the full set of
>>             receivers (i.e. matrix columns). This is a reason why (at
>>             least) some believe that a single connectivity matrix per
>>             slice is sufficient. For what it is worth, this is how
>>             Connectivity Matrix container for a TE node is defined by
>>             the TE Topology model.
>>             Regards,
>>             Igor
>>                 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,
>>                 This message and its attachments may contain
>>                 confidential or privileged information that may be
>>                 protected by law;
>>                 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.
>>
>>
>>         destinatario, puede contener información privilegiada o
>>         confidencial y es para uso exclusivo de la persona o entidad
>>         de destino. Si no es usted. el destinatario indicado, queda
>>         notificado de que la lectura, utilización, divulgación y/o
>>         copia sin autorización puede estar prohibida en virtud de la
>>         legislación vigente. Si ha recibido este mensaje por error, le
>>         rogamos que nos lo comunique inmediatamente por esta misma vía
>>         y proceda a su destrucción.
>>
>>         The information contained in this transmission is privileged
>>         and confidential information intended only for the use of the
>>         individual or entity named above. If the reader of this
>>         message is not the intended recipient, you are hereby notified
>>         that any dissemination, distribution or copying of this
>>         communication is strictly prohibited. If you have received
>>         this transmission in error, do not read it. Please immediately
>>         reply to the sender that you have received this communication
>>         in error and then delete it.
>>
>>         destinatário, pode conter informação privilegiada ou
>>         confidencial e é para uso exclusivo da pessoa ou entidade de
>>         destino. Se não é vossa senhoria o destinatário indicado, fica
>>         notificado de que a leitura, utilização, divulgação e/ou cópia
>>         sem autorização pode estar proibida em virtude da legislação
>>         vigente. Se recebeu esta mensagem por erro, rogamos-lhe que
>>         nos o comunique imediatamente por esta mesma via e proceda a
>>         sua destruição

-- 
Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Wed, 17 Nov 2021 11:18:44 +0100

I can live with either (‘connectivity construct’ or ‘connectivity matrix’), with slight preference towards ‘connectivity construct’.

//Krzysztof

> On 2021 -Nov-17, at 10:46, Loa Andersson <[email-masked]> wrote:
> 
> Folks,
> 
> This is a naming discussing, perfect names are almost impossible. However once you settle for a name it is gradual filled with the content needed/wanted.
> 
> Adrian wants to change "connectivity matrices" to "connectivity constructs". I have no opinion on the brilliance of that change.
> 
> However, reading all mails on the subject and thinking offline a bit I find that I can live with "connectivity constructs".
> 
> So I would like to ask those of you that have participated in the naming discussion if it would be possible to step back and think about if it is possible to live with "connectivity constructs", understanding that there might be a name that you personal prefer?
> 
> /Loa
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 17 Nov 2021 11:35:58 +0000

Hi Adrian,

Thanks for the effort on clarifying the terminology.

With the introduction of “connectivity construct”, my understanding is that it is the basic construct to describe the service connectivity demands, and a connectivity matrix is the collection of the connectivity constructs in a network slice service. Is this correct?

Then a question is, does the previous “connectivity matrix types” apply to the connectivity construct?   My understanding is it may have two basic connectivity construct types: P2P (unicast) and P2MP (multicast), but not sure about how to concisely describe the any-to-any connectivity as discussed before on the list.

Also, with this new term, do we expect there is always one connectivity matrix per slice service, or there can be multiple connectivity matrices?

Best regards,
Jie

From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, November 15, 2021 11:55 PM
To: 'Igor Bryskin' <[email-masked]>; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Igor,

Slice Service…
   Connectivity Matrix…
       Connectivity Construct…

Now…

OK?

Thanks,
Adrian

Hi,

Regards,
Igor

Cheers,
Med

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Nov 2021 12:28:02 -0000

Hi,

I propose to stop using the term “connectivity matrix”. It has caused, and continues to cause, so much confusion that it is not helpful to use it.

Having put A2A on the table, and having listened to the discussions, I think we can collapse the connectivity constructs to the following four. Note that MP2P is retired, and that MP2MP effectively absorbs the previous A2A definitions.

*	For a unidirectional P2P connectivity matrix, there is one sending CE and one receiving CE, and the matrix is used to send both unicast and multicast (and broadcast) traffic from the sending CE to the receiving CE. There is a single set of SLOs and SLEs for the sending CE. 
*	For a bi-directional P2P connectivity matrix, each CE is both a sending and receiving CE, and the matrix is used send both unicast and multicast (and broadcast) traffic between the two CEs. Each CE has its own set of SLOs and SLEs.
*	For a P2MP connectivity matrix, there is only one sending CE and one or more receiving CEs, and the matrix is used to send broadcast and multicast (and broadcast) traffic from the sending CE to all the receiving CES. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a single set of SLOs and SLEs for the sending CE.
*	For an MP2MP connectivity matrix, there are two or more CEs, each CE is both a sending and receiving CE, and the matrix is used to send unicast traffic from a sending CE to a receiving CE and broadcast and multicast (and broadcast) traffic from a sending CE to all the receiving CEs. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a set of SLOs and SLEs for each sending CE. 

[Note: this text needs to be fixed to use the new term for “service demarcation point” instead of CE]

Cheers,

Adrian

From: Dongjie (Jimmy) <[email-masked]> 

Sent: 17 November 2021 11:36

Subject: RE: [Teas] Slicing : The term Connectivity Matrix

Hi Adrian, 

Best regards,

Jie

To: 'Igor Bryskin' <mailto:[email-masked]>; mailto:[email-masked]

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

From: Igor Bryskin <mailto:[email-masked]> 

To: mailto:[email-masked]; mailto:[email-masked]; mailto:[email-masked]; mailto:[email-masked]

Hi,

Regards,

Igor

https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature

On Mon, Nov 15, 2021 at 10:05 AM, mailto:[email-masked]

<mailto:[email-masked]> wrote:

Hi Adrian, all,

Cheers,

Med

> De : Teas <mailto:[email-masked]> De la part de Adrian Farrel

> À : mailto:[email-masked]

> mailto:[email-masked]

Thank you.

Teas mailing list

mailto:[email-masked]

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Wed, 17 Nov 2021 13:38:41 +0100

Hi Adrien,

Couple of questions:

a) which connectivity construct will be used to request slice for load-balancers, where ingress PE load-balances (flow based LB) the traffic towards set of receiving CEs? Load-balancers is one of the use cases mentioned in the draft.
b) For MP2MP use case you have in mind N x (N-1) SLOs in total (where N is the number of CEs)?

Regards,
Krzysztof

> On 2021 -Nov-17, at 13:28, Adrian Farrel <[email-masked]> wrote:
> 
> Hi,
>  
> For a unidirectional P2P connectivity matrix, there is one sending CE and one receiving CE, and the matrix is used to send both unicast and multicast (and broadcast) traffic from the sending CE to the receiving CE. There is a single set of SLOs and SLEs for the sending CE. 
> For a bi-directional P2P connectivity matrix, each CE is both a sending and receiving CE, and the matrix is used send both unicast and multicast (and broadcast) traffic between the two CEs. Each CE has its own set of SLOs and SLEs.
> For a P2MP connectivity matrix, there is only one sending CE and one or more receiving CEs, and the matrix is used to send broadcast and multicast (and broadcast) traffic from the sending CE to all the receiving CES. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a single set of SLOs and SLEs for the sending CE.
> For an MP2MP connectivity matrix, there are two or more CEs, each CE is both a sending and receiving CE, and the matrix is used to send unicast traffic from a sending CE to a receiving CE and broadcast and multicast (and broadcast) traffic from a sending CE to all the receiving CEs. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a set of SLOs and SLEs for each sending CE. 
>  
> From: Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>> 
> From: Teas [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Adrian Farrel
> To: 'Igor Bryskin' <mailto:[email-masked] <mailto:[email-masked]>>; mailto:[email-masked] <mailto:[email-masked]>
> From: Igor Bryskin <mailto:[email-masked] <mailto:[email-masked]>> 
> To: mailto:[email-masked] <mailto:[email-masked]>; mailto:[email-masked] <mailto:[email-masked]>; mailto:[email-masked] <mailto:[email-masked]>; mailto:[email-masked] <mailto:[email-masked]>
> https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>  
> On Mon, Nov 15, 2021 at 10:05 AM, mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>> wrote:
> Hi Adrian, all,
>  
> > De : Teas <mailto:[email-masked] <mailto:[email-masked]>> De la part de Adrian Farrel
> > À : mailto:[email-masked] <mailto:[email-masked]>
> > mailto:[email-masked] <mailto:[email-masked]>
> mailto:[email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>_______________________________________________
> Teas mailing list

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Nov 2021 13:01:40 -0000

Krzysztof,

Thanks for asking.

a)

I think your first question highlights the need to stop talking about CEs and PEs, and to use the term service demarcation point. The load balancer may be a part of the service or outside the service. In the former case, it seems to me that the service is a P2MP service with traffic balanced across the receivers according to some SLO/SLE. In the latter case, the service demarcation point is the load balancer and what it does is out of scope of the service.

You could, I suppose model a load balancer in a service as the combination of two connectivity constructs: P2P from sender to load balancer; P2MP (or a set of P2P) from the load balancer to the receivers.

b)

For your second question I should like to separate the abstract from the realisation. In the abstract sense (as the text says) there is an SLO/SLE set for each sender (not for each sender/receiver pair), thus N in your example. In terms of realisation, I would think that the sane approach is to define a default SLO/SLE set for the whole connectivity construct (thus all senders), and only configure variations per sender as needed. (This, I think, models how VPN services are sold today.)

What, I hear people ask, about the case where I want to more tightly scope the behaviour on a sender/receiver pair? I think that in that case you are describing a set of P2P connectivity constructs.

Cheers,

Adrian

From: Krzysztof Szarkowicz <[email-masked]> 
Sent: 17 November 2021 12:39
To: [email-masked]
Cc: Dongjie (Jimmy) <[email-masked]>; Igor Bryskin <[email-masked]>; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Adrien,

Couple of questions:

Regards,

Krzysztof

On 2021 -Nov-17, at 13:28, Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

Cheers,

Adrian

From: Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]> > 

To: [email-masked] <mailto:[email-masked]> ; 'Igor Bryskin' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 

Hi Adrian, 

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

https://go.onelink.me/107872968?pid=InProduct <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> &c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature

Hi Adrian, all,

Cheers,

Med

Thank you.

Teas mailing list

mailto:[email-masked]

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Nov 2021 12:50:15 -0000

Sorry for screwing up here.

The new text should read…

*	For a unidirectional P2P connectivity construct, there is one sending CE and one receiving CE, and the construct is used to send both unicast and multicast (and broadcast) traffic from the sending CE to the receiving CE. There is a single set of SLOs and SLEs for the sending CE. 
*	For a bi-directional P2P connectivity construct, each CE is both a sending and receiving CE, and the construct is used send both unicast and multicast (and broadcast) traffic between the two CEs. Each CE has its own set of SLOs and SLEs.
*	For a P2MP connectivity construct, there is only one sending CE and one or more receiving CEs, and the construct is used to send broadcast and multicast (and broadcast) traffic from the sending CE to all the receiving CES. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a single set of SLOs and SLEs for the sending CE.
*	For an MP2MP connectivity construct, there are two or more CEs, each CE is both a sending and receiving CE, and the construct is used to send unicast traffic from a sending CE to a receiving CE and broadcast and multicast (and broadcast) traffic from a sending CE to all the receiving CEs. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a set of SLOs and SLEs for each sending CE. 

From: Adrian Farrel <[email-masked]> 
Sent: 17 November 2021 12:28
To: 'Dongjie (Jimmy)' <[email-masked]>; 'Igor Bryskin' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: RE: [Teas] Slicing : The term Connectivity Matrix

Hi,

Cheers,

Adrian

Hi Adrian, 

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,

Med

Thank you.

Teas mailing list

mailto:[email-masked]

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Nov 2021 14:03:24 +0000

Jimmy,

We are simply replacing the term 'connectivity matrix' with the term 'connectivity construct' and retiring the former term.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, November 17, 2021 6:36 AM
To: [email-masked]; 'Igor Bryskin' <[email-masked]>; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

[External Email. Be cautious of content]

Hi Adrian,

With the introduction of "connectivity construct", my understanding is that it is the basic construct to describe the service connectivity demands, and a connectivity matrix is the collection of the connectivity constructs in a network slice service. Is this correct?

Then a question is, does the previous "connectivity matrix types" apply to the connectivity construct?   My understanding is it may have two basic connectivity construct types: P2P (unicast) and P2MP (multicast), but not sure about how to concisely describe the any-to-any connectivity as discussed before on the list.

Best regards,
Jie

From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, November 15, 2021 11:55 PM
To: 'Igor Bryskin' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Igor,

I think you are describing a hierarchy of constructs...

Slice Service...
   Connectivity Matrix...
       Connectivity Construct...

I was previously using the term "matrix" to describe the third of these, but many people (including you?) assumed I meant the second of these.

Now...

OK?

Thanks,
Adrian

Hi,

Regards,
Igor
Sent from Yahoo Mail on Android<https://urldefense.com/v3/__https:/go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature__;!!NEt6yMaO-gk!RxBjZV7hnDR_m-A6aPg4_9qS8QTfizjvnTFiWaC7AWwKcbjX2VyuIA_I1uxG-r8$>

Cheers,
Med

> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!RxBjZV7hnDR_m-A6aPg4_9qS8QTfizjvnTFiWaC7AWwKcbjX2VyuIA_IUHLkCrA$>

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!RxBjZV7hnDR_m-A6aPg4_9qS8QTfizjvnTFiWaC7AWwKcbjX2VyuIA_IUHLkCrA$>

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 17 Nov 2021 14:11:41 +0000

Hi John, Jimmy

It seems what Jimmy said is correct "With the introduction of "connectivity construct", my understanding is that it is the basic construct to describe the service connectivity demands, and a connectivity matrix is the collection of the connectivity constructs in a network slice service."
And aligned with also Adrian with Igor , said about hierarchy
Slice Service...
   Connectivity Matrix...
       Connectivity Construct...

There is connectivity matrix as umbrella for connectivity constructs.

Cheers
Sergio

From: Teas <[email-masked]> On Behalf Of John E Drake
Sent: Wednesday, November 17, 2021 3:03 PM
To: Dongjie (Jimmy) <[email-masked]>; [email-masked]; 'Igor Bryskin' <[email-masked]>; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Jimmy,

Yours Irrespectively,

John

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Dongjie (Jimmy)

Hi Adrian,

Best regards,
Jie

Hi Igor,

Slice Service...
   Connectivity Matrix...

Now...

OK?

Thanks,
Adrian

Hi,

Regards,
Igor

Cheers,
Med

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 17 Nov 2021 14:27:03 +0000

Hi Adrian,

Thanks for the proposed text.

I think it is good now to explicitly state that P2MP implies multicast (broadcast) distribution in its realization.

However I think is yet confusing to consider all three unicast, multicast or broadcast for P2P or bidirectional P2P. I think this is open to interpretations, with actual implications on how the slice should be realized (e.g. protocol activation, potential ACLs to apply, etc). So I think is yet needed to signal somehow the type of traffic delivery in order to unambiguously interpret how the realization of the slice should be done. Options coming to my mind:

-          Explicitly associate unicast/multicast/broadcast to the construct

-          Leverage on the selected endpoints (e.g., for IP multicast it could be expected to identify the destination address as a multicast address)

-          Specify it as part of the SLEs for such construct
There could be probably others. I think any of them could allow to clearly identify how the construct should be realized to satisfy customer needs.

Best regards

Luis

De: Teas <[email-masked]> En nombre de Adrian Farrel
Enviado el: miércoles, 17 de noviembre de 2021 13:50
Para: 'Dongjie (Jimmy)' <[email-masked]>; 'Igor Bryskin' <[email-masked]>; [email-masked]
Asunto: Re: [Teas] Slicing : The term Connectivity Matrix

-          For a unidirectional P2P connectivity construct, there is one sending CE and one receiving CE, and the construct is used to send both unicast and multicast (and broadcast) traffic from the sending CE to the receiving CE. There is a single set of SLOs and SLEs for the sending CE.
-          For a bi-directional P2P connectivity construct, each CE is both a sending and receiving CE, and the construct is used send both unicast and multicast (and broadcast) traffic between the two CEs. Each CE has its own set of SLOs and SLEs.
-          For a P2MP connectivity construct, there is only one sending CE and one or more receiving CEs, and the construct is used to send broadcast and multicast (and broadcast) traffic from the sending CE to all the receiving CES. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a single set of SLOs and SLEs for the sending CE.
-          For an MP2MP connectivity construct, there are two or more CEs, each CE is both a sending and receiving CE, and the construct is used to send unicast traffic from a sending CE to a receiving CE and broadcast and multicast (and broadcast) traffic from a sending CE to all the receiving CEs. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a set of SLOs and SLEs for each sending CE.

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Sent: 17 November 2021 12:28
To: 'Dongjie (Jimmy)' <[email-masked]<mailto:[email-masked]>>; 'Igor Bryskin' <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] Slicing : The term Connectivity Matrix

Hi,

-          For a unidirectional P2P connectivity matrix, there is one sending CE and one receiving CE, and the matrix is used to send both unicast and multicast (and broadcast) traffic from the sending CE to the receiving CE. There is a single set of SLOs and SLEs for the sending CE.
-          For a bi-directional P2P connectivity matrix, each CE is both a sending and receiving CE, and the matrix is used send both unicast and multicast (and broadcast) traffic between the two CEs. Each CE has its own set of SLOs and SLEs.
-          For a P2MP connectivity matrix, there is only one sending CE and one or more receiving CEs, and the matrix is used to send broadcast and multicast (and broadcast) traffic from the sending CE to all the receiving CES. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a single set of SLOs and SLEs for the sending CE.
-          For an MP2MP connectivity matrix, there are two or more CEs, each CE is both a sending and receiving CE, and the matrix is used to send unicast traffic from a sending CE to a receiving CE and broadcast and multicast (and broadcast) traffic from a sending CE to all the receiving CEs. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a set of SLOs and SLEs for each sending CE.

Cheers,

Adrian

From: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>

Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,

Med

Thank you.

Teas mailing list

mailto:[email-masked]

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Nov 2021 14:38:31 +0000

Sergio,

You will not see the term 'connectivity matrix' in the Framework draft.

Yours Irrespectively,

John

Juniper Business Use Only
From: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Sent: Wednesday, November 17, 2021 9:12 AM
To: John E Drake <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; [email-masked]; 'Igor Bryskin' <[email-masked]>; [email-masked]
Subject: RE: [Teas] Slicing : The term Connectivity Matrix

Hi John, Jimmy

Cheers
Sergio

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Wednesday, November 17, 2021 3:03 PM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Igor Bryskin' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Jimmy,

Yours Irrespectively,

John

Hi Adrian,

Best regards,
Jie

Hi Igor,

Slice Service...
   Connectivity Matrix...

Now...

OK?

Thanks,
Adrian

Hi,

Regards,
Igor

Cheers,
Med

---

From: "Simon Spraggs (sspraggs)" <[email-masked]>
Date: Wed, 17 Nov 2021 14:41:14 +0000

Folks,
We really need to think about the scalability of the connectivity matrix particularly the MP2MP in a slice environment. Depending on where slice begins and ends (CE, AC or PE), it is easy to envisage 1000s of end-points in a slice. As Krzysztof points out the connectivity matrix will be N*(N-1) if it’s a single class of service but if it includes multiple classes of services, it x(N*(N-1) where x is the number of service classes. In either case, this matrix could be huge.
 In addition, using enterprise networks and existing mobile networks as an example, sites can normally be classified into a small number of types. (for example small, medium and large sites) which have common connectivity and SLO/SLEs requirements. Consequently, it seems important to be able to define connectivity profiles that can be applied to many sites without having to build a full connectivity matrix.
Cheers Simon

From: Teas <[email-masked]> on behalf of Krzysztof Szarkowicz <[email-masked]>
Date: Wednesday, 17 November 2021 at 12:39
To: "[email-masked]" <[email-masked]>
Cc: Igor Bryskin <[email-masked]>, "Dongjie (Jimmy)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Adrien,

Couple of questions:

Regards,
Krzysztof

On 2021 -Nov-17, at 13:28, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers,
Adrian

Hi Adrian,

Best regards,
Jie

Hi Igor,

Slice Service…
   Connectivity Matrix…
       Connectivity Construct…

Now…

OK?

Thanks,
Adrian

Hi,

Regards,
Igor

Cheers,
Med

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Nov 2021 14:44:49 +0000

Hi,

Comments inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Krzysztof Szarkowicz
Sent: Wednesday, November 17, 2021 7:39 AM
To: [email-masked]
Cc: Igor Bryskin <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Adrien,

Couple of questions:

  1.  which connectivity construct will be used to request slice for load-balancers, where ingress PE load-balances (flow based LB) the traffic towards set of receiving CEs? Load-balancers is one of the use cases mentioned in the draft.

[JD]  Presumably MP2MP

  1.  For MP2MP use case you have in mind N x (N-1) SLOs in total (where N is the number of CEs)?

[JD]  No, if there are N senders there are O(N) SLOs/SLEs.  It is O because there may be multiple SLOs/SLEs for a given sender.

Regards,
Krzysztof

Hi,

I propose to stop using the term "connectivity matrix". It has caused, and continues to cause, so much confusion that it is not helpful to use it.

[Note: this text needs to be fixed to use the new term for "service demarcation point" instead of CE]

Cheers,
Adrian

Hi Adrian,

Best regards,
Jie

Hi Igor,

Slice Service...
   Connectivity Matrix...

Now...

OK?

Thanks,
Adrian

Hi,

Regards,
Igor
https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature<https://urldefense.com/v3/__https:/go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature__;!!NEt6yMaO-gk!RodRUGobWfG4w6yVGLiuObzZWlKlHZYFhZUHZ-ZrUIsXllErOLoJOBnQy2p1Q1g$>

Cheers,
Med

> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!RodRUGobWfG4w6yVGLiuObzZWlKlHZYFhZUHZ-ZrUIsXllErOLoJOBnQVrKMQcE$>

_______________________________________________
Teas mailing list
mailto:[email-masked]
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!RodRUGobWfG4w6yVGLiuObzZWlKlHZYFhZUHZ-ZrUIsXllErOLoJOBnQVrKMQcE$>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!RodRUGobWfG4w6yVGLiuObzZWlKlHZYFhZUHZ-ZrUIsXllErOLoJOBnQVrKMQcE$>

---

From: <[email-masked]>
Date: Wed, 17 Nov 2021 14:53:23 +0000

Hi Luis,

What about adding this NEW text:

   Activating unicast or multicast capabilities to deliver an IETF
   Slice Service can be explicitly requested by a Customer or
   can be an engineering decision of a Network Provider based on
   the analysis of the connectivity constructs.

I’m not sure we need to say more given that this is a framework document, not an information model.

Cheers,
Med

De : Teas <[email-masked]> De la part de LUIS MIGUEL CONTRERAS MURILLO
Envoyé : mercredi 17 novembre 2021 15:27
À : [email-masked]; 'Dongjie (Jimmy)' <[email-masked]>; 'Igor Bryskin' <[email-masked]>; [email-masked]
Objet : Re: [Teas] Slicing : The term Connectivity Matrix

Hi Adrian,

  *   Explicitly associate unicast/multicast/broadcast to the construct
  *   Leverage on the selected endpoints (e.g., for IP multicast it could be expected to identify the destination address as a multicast address)
  *   Specify it as part of the SLEs for such construct
There could be probably others. I think any of them could allow to clearly identify how the construct should be realized to satisfy customer needs.

Best regards

Luis

De: Teas <[email-masked]<mailto:[email-masked]>> En nombre de Adrian Farrel
Enviado el: miércoles, 17 de noviembre de 2021 13:50
Para: 'Dongjie (Jimmy)' <[email-masked]<mailto:[email-masked]>>; 'Igor Bryskin' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Asunto: Re: [Teas] Slicing : The term Connectivity Matrix

Hi,

Cheers,

Adrian

Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,

Med

Thank you.

Teas mailing list

mailto:[email-masked]

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Nov 2021 14:58:59 +0000

Hi,

Comments inline.  Presumably you didn't get the memo about the terminology change to 'connectivity construct'?  8->

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Simon Spraggs (sspraggs)
Sent: Wednesday, November 17, 2021 9:41 AM
To: Krzysztof Szarkowicz <[email-masked]>; [email-masked]; [email-masked]
Cc: Igor Bryskin <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Folks,
We really need to think about the scalability of the connectivity matrix particularly the MP2MP in a slice environment. Depending on where slice begins and ends (CE, AC or PE), it is easy to envisage 1000s of end-points in a slice. As Krzysztof points out the connectivity matrix will be N*(N-1) if it's a single class of service but if it includes multiple classes of services, it x(N*(N-1) where x is the number of service classes. In either case, this matrix could be huge.

[JD]  This is incorrect.  If there are N senders there are O(N) SLOs/SLEs  >From the soon to be published -06:

" Note that a bandwidth SLO determines how much traffic a sending CE can send to a connectivity construct while the other SLOs and SLEs apply between the sending CE and each of the receiving CEs".

And from the published -05:

"Attachment Circuit (AC): A channel connecting a CE and a PE over which packets belonging to an IETF Network Slice Service are exchanged. The customer and provider agree on which values in which combination of layer 2 and layer 3 fields within a packet identify to which {IETF Network Slice Service, connectivity matrix, and SLOs/SLEs} that packet is assigned. The customer and provider may agree on a per {IETF Network Slice Service, connectivity matrix, and SLOs/SLEs} basis to police or shape traffic in both the ingress (CE to PE) direction and egress (PE to CE) direction. This ensures that the traffic is within the capacity profile that is agreed in a Network Slide Service.  Excess traffic is dropped by default, unless specific out-of- profile policies are agreed between the customer and the provider"

[JD]  That's fine.  One of the things that we plan to add to the framework draft is a set of worked examples, similar to what was done in RFC 9015 (https://datatracker.ietf.org/doc/html/rfc9015) section 8.  We can include an example of SLO/SLE profiles.

Cheers Simon

From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 17 November 2021 at 12:39
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Igor Bryskin <[email-masked]<mailto:[email-masked]>>, "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Adrien,

Couple of questions:

Regards,
Krzysztof

Hi,

Cheers,
Adrian

Hi Adrian,

Best regards,
Jie

Hi Igor,

Slice Service...
   Connectivity Matrix...

Now...

OK?

Thanks,
Adrian

Hi,

Regards,
Igor
https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature<https://urldefense.com/v3/__https:/go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature__;!!NEt6yMaO-gk!Tr0uHhv45GHBznb218FzrdT4O1W5tgUK-dGmB-W2hhBsrurHBWNUBeXON0_Jak0$>

Cheers,
Med

> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Tr0uHhv45GHBznb218FzrdT4O1W5tgUK-dGmB-W2hhBsrurHBWNUBeXOgqMvW2M$>

_______________________________________________
Teas mailing list
mailto:[email-masked]
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Tr0uHhv45GHBznb218FzrdT4O1W5tgUK-dGmB-W2hhBsrurHBWNUBeXOgqMvW2M$>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Tr0uHhv45GHBznb218FzrdT4O1W5tgUK-dGmB-W2hhBsrurHBWNUBeXOgqMvW2M$>

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Nov 2021 15:00:31 +0000

This is fine with me.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, November 17, 2021 9:53 AM
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Luis,

I'm not sure we need to say more given that this is a framework document, not an information model.

Cheers,
Med

De : Teas <[email-masked]<mailto:[email-masked]>> De la part de LUIS MIGUEL CONTRERAS MURILLO
Envoyé : mercredi 17 novembre 2021 15:27
À : [email-masked]<mailto:[email-masked]>; 'Dongjie (Jimmy)' <[email-masked]<mailto:[email-masked]>>; 'Igor Bryskin' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [Teas] Slicing : The term Connectivity Matrix

Hi Adrian,

Best regards

Luis

The new text should read...

Hi,

Cheers,

Adrian

Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service...

   Connectivity Matrix...

Now...

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature<https://urldefense.com/v3/__https:/go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature__;!!NEt6yMaO-gk!TQLfNttGAJGPF4e4ZkbOLhB1T4Sciqx2_YgkcbdBEDkcfKc5BNdE4iwU4gX1U-U$>

Hi Adrian, all,

Cheers,

Med

> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TQLfNttGAJGPF4e4ZkbOLhB1T4Sciqx2_YgkcbdBEDkcfKc5BNdE4iwUxoj5fC4$>

Thank you.

Teas mailing list

mailto:[email-masked]

https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TQLfNttGAJGPF4e4ZkbOLhB1T4Sciqx2_YgkcbdBEDkcfKc5BNdE4iwUxoj5fC4$>

Thank you.

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 17 Nov 2021 15:03:54 +0000

Hi Med,

Thanks for the proposal. I think is good. With this I assume the model should incorporate a way for allowing the customer to indicate unicast or multicast in case it is a requirement or expectation for a given service.

Fine to me, thanks

Luis

De: [email-masked] <[email-masked]>
Enviado el: miércoles, 17 de noviembre de 2021 15:53
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]; [email-masked]
Asunto: RE: [Teas] Slicing : The term Connectivity Matrix

Hi Luis,

Cheers,
Med

Hi Adrian,

Best regards

Luis

Hi,

Cheers,

Adrian

Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,

Med

Thank you.

Teas mailing list

mailto:[email-masked]

Thank you.

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 17 Nov 2021 15:08:14 +0000 (UTC)

Ji Jia,
IMHO connectivity construct and connectivity  matrix will share the same set of types. However, a connectivity  construct of one (more complex) type could be described via connectivity  matrix of another (simpler) type. For example, a mp2mp
 connectivity construct  could be described as p2mp connectivity matrix, each of each entries (i.e. p2mp constructs) in turn, could be expressed either as basic (i.e. to be realized via p2mp tunnels) or  as p2p connectivity matrices. 
This approach would make a connectivity construct of any complexity recursively reducable to constructs of simpler types.
Another examples: any2any p2p construct could be expressed as a p2p connectivity matrix, mp2p construct =》p2p matrix, etc.
Cheers, Igor
Sent from Yahoo Mail on Android 
 
  On Wed, Nov 17, 2021 at 6:36 AM, Dongjie (Jimmy)<[email-masked]> wrote:   <!--#yiv8885228277 _filtered {} _filtered {} _filtered {} _filtered {} _filtered {}#yiv8885228277 #yiv8885228277 p.yiv8885228277MsoNormal, #yiv8885228277 li.yiv8885228277MsoNormal, #yiv8885228277 div.yiv8885228277MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv8885228277 a:link, #yiv8885228277 span.yiv8885228277MsoHyperlink {color:blue;text-decoration:underline;}#yiv8885228277 a:visited, #yiv8885228277 span.yiv8885228277MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv8885228277 span.yiv8885228277EmailStyle17 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv8885228277 span.yiv8885228277EmailStyle18 {font-family:"Calibri", sans-serif;color:#1F497D;}#yiv8885228277 .yiv8885228277MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv8885228277 div.yiv8885228277WordSection1 {}-->
Hi Adrian,

 

 

Best regards,
 
Jie

From: Teas [mailto:[email-masked]]On Behalf Of Adrian Farrel
Sent: Monday, November 15, 2021 11:55 PM
To: 'Igor Bryskin' <[email-masked]>; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Igor,

 
Slice Service…
 
   Connectivity Matrix…
 
       Connectivity Construct…

 

Now…

 

 
OK?

Thanks,
 
Adrian

From: Igor Bryskin <[email-masked]>
Sent: 15 November 2021 15:47
To: [email-masked];[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi,

 
Regards,
 
Igor

 

 
Hi Adrian, all,

Cheers,
Med

---

From: Tarek Saad <[email-masked]>
Date: Wed, 17 Nov 2021 15:46:22 +0000

I agree with Igor here on the points he is raising. I also made similar points in my earlier post.

Regards,
Tarek

From: Teas <[email-masked]> on behalf of Igor Bryskin <i_bryskin=[email-masked]>
Date: Wednesday, November 17, 2021 at 10:08 AM
To: [email-masked] <[email-masked]>, Dongjie (Jimmy) <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix
Ji Jia,

Cheers,
Igor

On Wed, Nov 17, 2021 at 6:36 AM, Dongjie (Jimmy)
<[email-masked]> wrote:

Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,
Med

---

From: Tarek Saad <[email-masked]>
Date: Wed, 17 Nov 2021 15:54:31 +0000

Hi Simon,

>> As Krzysztof points out the connectivity matrix will be N*(N-1) if it’s a single class of service but if it includes multiple classes of services, it x(N*(N-1) where x is the number of service classes. In either case, this matrix could be huge.
[TS]: yes, repeating same endpoints for each of the X service classes may be redundant (if a matrix per service class), but on other hand may provide some flexibility in case service `x` does not share the full set of endpoints with `x-1`.

>> Consequently, it seems important to be able to define connectivity profiles that can be applied to many sites without having to build a full connectivity matrix.
Cheers Simon
[TS]: Yes, there were two approaches possible to cover this: 1) a single connectivity matrix that can carry multiple classes of service (here your suggestion of connectivity profiles may help), 2) a separate connectivity matrix per class of service. The latter may be easier from data modelling perspective (as many constructs may be just reusable), but I still think the single matrix with multiple profiles (per class) is worth consideration.

Regards,
Tarek

From: Teas <[email-masked]> on behalf of Simon Spraggs (sspraggs) <sspraggs=[email-masked]>
Date: Wednesday, November 17, 2021 at 9:41 AM
To: Krzysztof Szarkowicz <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Cc: Igor Bryskin <[email-masked]>, Dongjie (Jimmy) <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix
Folks,
We really need to think about the scalability of the connectivity matrix particularly the MP2MP in a slice environment. Depending on where slice begins and ends (CE, AC or PE), it is easy to envisage 1000s of end-points in a slice. As Krzysztof points out the connectivity matrix will be N*(N-1) if it’s a single class of service but if it includes multiple classes of services, it x(N*(N-1) where x is the number of service classes. In either case, this matrix could be huge.
 In addition, using enterprise networks and existing mobile networks as an example, sites can normally be classified into a small number of types. (for example small, medium and large sites) which have common connectivity and SLO/SLEs requirements. Consequently, it seems important to be able to define connectivity profiles that can be applied to many sites without having to build a full connectivity matrix.
Cheers Simon

Hi Adrien,

Couple of questions:

Regards,
Krzysztof

Hi,

Cheers,
Adrian

Hi Adrian,

Best regards,
Jie

Hi Igor,

Slice Service…
   Connectivity Matrix…
       Connectivity Construct…

Now…

OK?

Thanks,
Adrian

Hi,

Regards,
Igor

Cheers,
Med

---

From: Tarek Saad <[email-masked]>
Date: Wed, 17 Nov 2021 16:01:34 +0000

Hi Med,

I agree, this may be useful. It is similar to what I was proposing in my previous email below:
“Maybe connectivity type and packet replication service can be different attributes of a connectivity matrix – so in theory for A2A I can enable replication packet delivery and it would be able to do `broadcast`.”

Regards,
Tarek

From: Teas <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Wednesday, November 17, 2021 at 9:53 AM
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix
Hi Luis,

Cheers,
Med

Hi Adrian,

Best regards

Luis

Hi,

Cheers,

Adrian

Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,

Med

Thank you.

Teas mailing list

mailto:[email-masked]

Thank you.

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 17 Nov 2021 16:08:08 +0000

Thanks Adrian for this effort.

Regarding new “Connectivity Construct”, I have summarized my points in following Figures. I would like to get clarification on following.

-          How does NSE relate to Connectivity Construct definition? IMO, we should address the definition based on NSE (IETF Network Slice Endpoint) not CE or PE as per section 4.2 of Framework draft.

  *   For P2P, the following is my view,
     *   i.e. a “P2P Connectivity Construct” can have move than more than one sending or receiving NSE but at any time ONLY ONE NSE is sending traffic and ONE NSE receives the traffic.
     *   IMO the traffic type is only unicast. Not clear on the reasons on why traffic should be broadcast and multicast.

[Diagram  Description automatically generated]

  *   For P2MP, the following is my view, i.e. a “P2MP Connectivity Construct” can have move than more than one sending or receiving NSE but at any time ONE NSE will send traffic and all other  NSE (i.e. traffic should be multicast or broadcast).

[Diagram  Description automatically generated]

  *   For P2MP, the following is my view, i.e. a “MP2MP Connectivity Construct” is just combination of multiple P2MP construct..

[Diagram  Description automatically generated]

Cheers,

Reza

From: Teas <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Wednesday, November 17, 2021 at 7:50 AM
To: "'Dongjie (Jimmy)'" <[email-masked]>, 'Igor Bryskin' <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi,

Cheers,

Adrian

Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,

Med

Thank you.

Teas mailing list

mailto:[email-masked]

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 19 Nov 2021 16:02:03 +0100

Hi Tarek, Igor,

P2MP, according to the current proposed text, is used for  multicast/broadcast exclusively (no unicast), whereas MP2MP can be used fo unicast. Thus, MP2MP cannot be constructed from group of P2MP constructs, unless I am missing something.

Regards,
Krzysztof

> On 2021 -Nov-17, at 16:46, Tarek Saad <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: Teas <[email-masked] <mailto:[email-masked]>> on behalf of Igor Bryskin <i_bryskin=[email-masked] <mailto:i_bryskin=[email-masked]>>
> To: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>, Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Adrian,
> 
>  
> 
> To: 'Igor Bryskin' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 19 Nov 2021 16:02:53 +0100

Thanks Adrian,

That clarifies things.

//Krzysztof

> On 2021 -Nov-17, at 14:01, Adrian Farrel <[email-masked]> wrote:
> 
> Krzysztof,
>  
> Thanks for asking.
>  
> a)
>  
> From: Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>> 
> To: [email-masked] <mailto:[email-masked]>
> Cc: Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>>; Igor Bryskin <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> On 2021 -Nov-17, at 13:28, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi,
>>

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 19 Nov 2021 16:08:22 +0100

Reza,

MP2MP can be used to deliver unicast traffic, whereas P2MP is restricted to mcast traffic only, So, how MP2MP can be combination of P2MP constructs?

Also, in proposed text for MP2MP there is sets of SLOs/SLEs per sending CE (i.e., site capacities can differ, as raised by Simon), whereas you assume all CEs are equal. That is usually not true (in soma special cases might be OK, but I wouldn’t say it is OK for general case).

Thank you,
Krzysztof

> Begin forwarded message:
> 
> From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
> Date: 2021-11-17:We at 17:08:08 GMT+1
> To: "[email-masked]" <[email-masked]>, "'Dongjie (Jimmy)'" <[email-masked]>, 'Igor Bryskin' <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "Rokui, Reza \(Nokia - CA/Ottawa\)" <[email-masked]>
> 
> For P2P, the following is my view,
> i.e. a “P2P Connectivity Construct” can have move than more than one sending or receiving NSE but at any time ONLY ONE NSE is sending traffic and ONE NSE receives the traffic.
> IMO the traffic type is only unicast. Not clear on the reasons on why traffic should be broadcast and multicast.
>  
> 
>  
> For P2MP, the following is my view, i.e. a “P2MP Connectivity Construct” can have move than more than one sending or receiving NSE but at any time ONE NSE will send traffic and all other  NSE (i.e. traffic should be multicast or broadcast).
>  
>  
> 
>  
> For P2MP, the following is my view, i.e. a “MP2MP Connectivity Construct” is just combination of multiple P2MP construct..
>  
> 
>  
>  
> Cheers,
>  
> Reza
>  
>  
>  
> Reply-To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> To: "'Dongjie (Jimmy)'" <[email-masked] <mailto:[email-masked]>>, 'Igor Bryskin' <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> For a unidirectional P2P connectivity construct, there is one sending CE and one receiving CE, and the construct is used to send both unicast and multicast (and broadcast) traffic from the sending CE to the receiving CE. There is a single set of SLOs and SLEs for the sending CE.
> For a bi-directional P2P connectivity construct, each CE is both a sending and receiving CE, and the construct is used send both unicast and multicast (and broadcast) traffic between the two CEs. Each CE has its own set of SLOs and SLEs.
> For a P2MP connectivity construct, there is only one sending CE and one or more receiving CEs, and the construct is used to send broadcast and multicast (and broadcast) traffic from the sending CE to all the receiving CES. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a single set of SLOs and SLEs for the sending CE.
> For an MP2MP connectivity construct, there are two or more CEs, each CE is both a sending and receiving CE, and the construct is used to send unicast traffic from a sending CE to a receiving CE and broadcast and multicast (and broadcast) traffic from a sending CE to all the receiving CEs. Interactions between a receiving CE and its PE may be used to avoid sending it multicast traffic in which it is not interested. There is a set of SLOs and SLEs for each sending CE. 
>  
>  
> From: Adrian Farrel <[email-masked] <mailto:[email-masked]>> 
> To: 'Dongjie (Jimmy)' <[email-masked] <mailto:[email-masked]>>; 'Igor Bryskin' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>' <[email-masked] <mailto:[email-masked]>>

---

From: Tarek Saad <[email-masked]>
Date: Fri, 19 Nov 2021 15:43:12 +0000

Hi Krzystof,

As of now, I-D.ietf-teas-ietf-network-slices defines MP2MP as multicast delivery.

  o  In an MP2MP connectivity matrix each of the N CEs can be a sending
      CE such that its traffic is delivered to all of the other CEs.

My suggestion is to decouple replication service from connectivity. This allows one to do unicast or multicast delivery on any type of connectivity.

Regards,
Tarek

From: Krzysztof Szarkowicz <[email-masked]>
Date: Friday, November 19, 2021 at 10:02 AM
To: Tarek Saad <[email-masked]>, Igor Bryskin <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Tarek, Igor,

Regards,
Krzysztof

On 2021 -Nov-17, at 16:46, Tarek Saad <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Tarek

From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Igor Bryskin <i_bryskin=[email-masked]<mailto:i_bryskin=[email-masked]>>
Date: Wednesday, November 17, 2021 at 10:08 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix
Ji Jia,

Cheers,
Igor

On Wed, Nov 17, 2021 at 6:36 AM, Dongjie (Jimmy)
<[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,
Med

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 19 Nov 2021 16:50:31 +0100

Hi Tarek,

So, are you proposing to decouple multicast from P2MP, too? 

Thanks,
Krzysztof

> On 2021 -Nov-19, at 16:43, Tarek Saad <[email-masked]> wrote:
> 
> Hi Krzystof,
>

---

From: Tarek Saad <[email-masked]>
Date: Fri, 19 Nov 2021 16:03:00 +0000

My thinking was we needed only 2 basic connectivity construct types: p2p and p2mp (with multicast service) -- I think this may have been shared by others on the list too. From these two basic construct types, one can derive multiple composite connectivities – like MP2MP, MP2P, A2A..

Regards,
Tarek

From: Krzysztof Szarkowicz <[email-masked]>
Date: Friday, November 19, 2021 at 10:50 AM
To: Tarek Saad <[email-masked]>
Cc: Igor Bryskin <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Tarek,

Thanks,
Krzysztof

On 2021 -Nov-19, at 16:43, Tarek Saad <[email-masked]<mailto:[email-masked]>> wrote:

Hi Krzystof,

Regards,
Tarek

From: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 19, 2021 at 10:02 AM
To: Tarek Saad <[email-masked]<mailto:[email-masked]>>, Igor Bryskin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Tarek, Igor,

Regards,
Krzysztof

Regards,
Tarek

Cheers,
Igor

Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,
Med

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 19 Nov 2021 17:09:56 +0100

Hi,

If P2MP is coupled with MCAST, then MP2MP (that should support unicast services, too, IMHO, just like MEF MP2MP support unicast) cannot be build with P2MP. However, while using P2P construct to build MP2MP, it would result with N x (N-1) SLOs, which would not scale (could be OK for some small deployments only).

Hence my question, if in your proposal P2MP is strictly coupled with mcast, or not :-).

Regards,
Krzysztof

> On 2021 -Nov-19, at 17:03, Tarek Saad <[email-masked]> wrote:
> 
> On 2021 -Nov-19, at 16:43, Tarek Saad <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Krzystof,
>  
> To: Tarek Saad <[email-masked] <mailto:[email-masked]>>, Igor Bryskin <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 19 Nov 2021 16:24:21 +0000 (UTC)

I do not understand why mp2mp construct should be limited to unicast. What is wrong with realizing it as a bunch of p2mp tunnels, each of which routed by one of the construct's senders? I am  not sure how this would be useful, but mp2mp construct could be theoretically realized as a combination of p2mp and p2p tunnels.
Cheers,Igor
    On Friday, November 19, 2021, 11:10:18 AM EST, Krzysztof Szarkowicz <[email-masked]> wrote:  
 
 Hi,
Regards,Krzysztof

My thinking was we needed only 2 basic connectivity construct types: p2p and p2mp (with multicast service) -- I think this may have been shared by others on the list too. From these two basic construct types, one can derive multiple composite connectivities – like MP2MP, MP2P, A2A..  Regards,Tarek  From: Krzysztof Szarkowicz <[email-masked]>
Date: Friday, November 19, 2021 at 10:50 AM
To: Tarek Saad <[email-masked]>
Cc: Igor Bryskin <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix  Hi Tarek,  So, are you proposing to decouple multicast from P2MP, too?   Thanks,Krzysztof  
On 2021 -Nov-19, at 16:43, Tarek Saad <[email-masked]> wrote:  Hi Krzystof, As of now, I-D.ietf-teas-ietf-network-slices defines MP2MP as multicast delivery.   o  In an MP2MP connectivity matrix each of the N CEs can be a sending      CE such that its traffic is delivered to all of the other CEs.     My suggestion is to decouple replication service from connectivity. This allows one to do unicast or multicast delivery on any type of connectivity. Regards,Tarek From: Krzysztof Szarkowicz <[email-masked]>
Date: Friday, November 19, 2021 at 10:02 AM
To: Tarek Saad <[email-masked]>, Igor Bryskin <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix Hi Tarek, Igor, P2MP, according to the current proposed text, is used for  multicast/broadcast exclusively (no unicast), whereas MP2MP can be used fo unicast. Thus, MP2MP cannot be constructed from group of P2MP constructs, unless I am missing something. Regards,Krzysztof  

On 2021 -Nov-17, at 16:46, Tarek Saad <[email-masked]> wrote: I agree with Igor here on the points he is raising. I also made similar points in my earlier post. Regards,Tarek 
From: Teas <[email-masked]> on behalf of Igor Bryskin <i_bryskin=[email-masked]>
Date: Wednesday, November 17, 2021 at 10:08 AM
To: [email-masked] <[email-masked]>, Dongjie (Jimmy) <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix
Ji Jia, IMHO connectivity construct and connectivity  matrix will share the same set of types. However, a connectivity  construct of one (more complex) type could be described via connectivity  matrix of another (simpler) type. For example, a mp2mp
 connectivity construct  could be described as p2mp connectivity matrix, each of each entries (i.e. p2mp constructs) in turn, could be expressed either as basic (i.e. to be realized via p2mp tunnels) or  as p2p connectivity matrices.  This approach would make a connectivity construct of any complexity recursively reducable to constructs of simpler types. Another examples: any2any p2p construct could be expressed as a p2p connectivity matrix, mp2p construct =》p2p matrix, etc. Cheers, IgorSent from Yahoo Mail on Android 
On Wed, Nov 17, 2021 at 6:36 AM, Dongjie (Jimmy)<[email-masked]> wrote:
Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,
Med

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 19 Nov 2021 16:30:11 +0000 (UTC)

Also isn't  mp2mp construct realized via unicast p2p tunnels the same as any2any construct?
    On Friday, November 19, 2021, 11:24:40 AM EST, Igor Bryskin <i_bryskin=[email-masked]> wrote:  

 Hi,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,
Med

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 19 Nov 2021 18:00:03 +0100

Hi Igor,

MP2MP absolutely should not be limited to unicast. It should support unicast/multicast/broadcast. So, if P2MP is limited mcast, P2MP can be used as building block for MP2MP supporting unicast (among multicast/broadcast).

If MP2MP is realized via P2P, we are talking about O(N x [N-1]) SLOs. Which might be OK for soma small scale deployment, but it will not scale to large deployments, having 1000s of CEs. If MP2MP is realized via P2MP (supporting unicast, among mcast), then we are talkinh about O(N) SLOs, as mentioned by John, which would scale.

Cheers,
Krzysztof

> On 2021 -Nov-19, at 17:30, Igor Bryskin <[email-masked]> wrote:
> 
>> On 2021 -Nov-19, at 17:03, Tarek Saad <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> 
> To: Tarek Saad <[email-masked] <mailto:[email-masked]>>
> Cc: Igor Bryskin <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: "Simon Spraggs (sspraggs)" <[email-masked]>
Date: Mon, 22 Nov 2021 11:33:11 +0000

Folks,
Seems to me that:

  1.  We need to disconnect the service (ie unicast, broadcast, multicast) from the topology construct (ie P2P, P2PM, MP2MP, A2A etc etc) as every topology construct can all potentially carry every service type.
  2.  We need to disconnect the SLE/SLO/connectivity construct from the way it is delivered in the core transport infrastructure because SLO, SLE are offered at the UNI / NNI. It is up to the provider to determine how the internal transport infrastructure delivers the SLO, SLE, so mention of concepts like Traffic Engineering should be avoided. This point is especially important when describing an abstract service on the NBI.
  3.  An SLO on a UNI/NNI has an ingress and egress component. In some cases, one or both can be inferred from SLOs on other UNIs.
  4.  There seem to be three basic topology constructs with two extremes. The extremes are:
     *   P2P : Only ever two active UNIs and each UNI can only every communicate with its partner. In this case the SLO is a P2P SLO where UNI-1 ingress SLO =UNI-2 egress SLO, UNI-2 ingress SLO = UNI-1 egress SLO.
     *   MP2MP: Any UNI in the topology construct can communicate with any other UNI in the topology construct. To make this topology construct scale it cannot be defined as a series of P2P SLOs, unless the MP2MP topology construct is very small. Rather the SLO needs to be defined at each UNI as to what the transport infrastructure will accept on ingress over the UNI irrespective of destination and what it will deliver on egress irrespective of source within the overall MP2MP construct.
     *   The last topology construct is a tree / hub and spoke / extranet topology (not sure what it should be called) where there are one or more UNI roots and UNI leaves. Communication is possible between roots and associated leaves and vice versa. There is no communication capability between the leaves. In this case there are two potential approaches to defining SLOs. The first is a series of P2P SLO, the second is a MP2MP SLO depending on the number of UNIs in the topology construct.
Thoughts
Cheers Simon

From: Teas <[email-masked]> on behalf of Krzysztof Szarkowicz <[email-masked]>
Date: Friday, 19 November 2021 at 17:01
To: Igor Bryskin <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Igor Bryskin <i_bryskin=[email-masked]>, Tarek Saad <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Igor,

Cheers,
Krzysztof

On 2021 -Nov-19, at 17:30, Igor Bryskin <[email-masked]<mailto:[email-masked]>> wrote:

On Friday, November 19, 2021, 11:24:40 AM EST, Igor Bryskin <i_bryskin=[email-masked]<mailto:i_bryskin=[email-masked]>> wrote:

Cheers,
Igor

On Friday, November 19, 2021, 11:10:18 AM EST, Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,
Krzysztof

On 2021 -Nov-19, at 17:03, Tarek Saad <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Tarek

From: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 19, 2021 at 10:50 AM
To: Tarek Saad <[email-masked]<mailto:[email-masked]>>
Cc: Igor Bryskin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix

Hi Tarek,

Thanks,
Krzysztof

Hi Krzystof,

Regards,
Tarek

Hi Tarek, Igor,

Regards,
Krzysztof

Regards,
Tarek

Cheers,
Igor

Hi Adrian,

Best regards,

Jie

Hi Igor,

Slice Service…

   Connectivity Matrix…

       Connectivity Construct…

Now…

OK?

Thanks,

Adrian

Hi,

Regards,

Igor

Hi Adrian, all,

Cheers,
Med