On Mon, Nov 22, 2021 at 6:33 AM Simon Spraggs (sspraggs) <ss= praggs=3D40cisco.com@dmarc.ie= tf.org> wrote:

Folks,

Seems to me that:

We need to disconnect the service (ie unicast, broadcast, m= ulticast) from the topology construct (ie P2P, P2PM, MP2MP, A2A etc etc) as= every topology construct can all potentially carry every service type.=
We need to disconnect the SLE/SLO/connectiv= ity construct from the way it is delivered in the core transport infrastruc= ture because SLO, SLE are offered at the UNI / NNI. It is up to the provider to determine how th= e internal transport infrastructure delivers the SLO, SLE, so mention of co= ncepts like Traffic Engineering should be avoided. This point is especially= important when describing an abstract service on the NBI.
An SLO on a U= NI/NNI has an ingress and egress component. In some cases, one or both can = be inferred from SLOs on other UNIs.
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 =3DUNI-2 egress SLO, UNI-2 ingress SLO =3D UNI-1 egress SLO. =C2=A0=C2= =A0
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 co= nstruct 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 irre= spective 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 associat= ed leaves and vice versa. There is no communication capability between the = leaves. In this case there are two potential approaches to defining SLOs. T= he 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

=C2=A0

From: = Teas <teas-bounces@ietf.org>= ; on behalf of Krzysztof Szarkowicz <kszarkowicz@gmail.com>
Date: Friday, 19 November 2021 at 17:01
To: Igor Bryskin <i_bryskin@yahoo.com>
Cc: "j= ie.dong@huawei.com" <jie.dong@huawei.com>, Igor Bryskin <i_bryskin=3D40yahoo.com@d= marc.ietf.org>, Tarek Saad <tsaad.net@gmail.com>, "teas@ietf.org" <teas@ietf.org>, "adrian@olddog.co.uk"= <adrian@olddog= .co.uk>
Subject: Re: [Teas] Slicing : The term Connectivity Matrix=

=C2=A0

Hi Igor,

=C2=A0

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

=C2=A0

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 real= ized via P2MP (supporting unicast, among mcast), then we are talkinh about O(N) SLOs, as mentioned by John, w= hich would scale.

=C2=A0

Cheers,

Krzysztof

=C2=A0

On 2021 -Nov-19, at 17:30, Igor Bryskin <i_bryskin@yahoo.com&g= t; wrote:

=C2=A0

Also isn't=C2=A0 mp2mp construct realized via unicast= p2p tunnels the same as any2any construct?

=C2=A0

On Friday, November 19, 2021, 11:24:4= 0 AM EST, Igor Bryskin <i_bryskin=3D40yahoo.com@dmarc.ietf.org> = wrote:

=C2=A0

=C2=A0

I do not understand why mp2mp constru= ct 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=C2=A0 not sure how this would be useful, but= mp2mp construct could be theoretically realized as a combination of p2mp a= nd p2p tunnels.

=C2=A0

Cheers,

Igor

=C2=A0

On Friday, November 19, 2021, 11:10:1= 8 AM EST, Krzysztof Szarkowicz <kszarkowicz@gmail.com> wrote:

=C2=A0

=C2=A0

Hi,

=C2=A0

If P2MP is coupled with MCAST, then M= P2MP (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) S= LOs, which would not scale (could be OK for some small deployments only).

=C2=A0

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

=C2=A0

Regards,

Krzysztof

=C2=A0

On 2021 -Nov-19, at 17:03, Tarek Saad= <tsaad.net@gma= il.com> wrote:

=C2=A0

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

=C2=A0

Regards,

Tarek

=C2=A0

From:=C2=A0Krzysztof Szarkowicz <= kszarkowicz@gmail.com>
Date:=C2=A0Friday, November 19, 2021 at 10:50 AM
To:= =C2=A0Tarek Saad <tsaad.net@gmail.com>
Cc:= =C2=A0Igor Bryskin <i_bryskin@yahoo.com>, "jie.dong@huawei.com" <jie.dong@huaw= ei.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org&g= t;
Subject:=C2=A0Re: [Teas] Slicing : The term Connectivity Matrix=

=C2=A0=

Hi Tarek,=

=C2=A0=

So, are you prop= osing to decouple multicast from P2MP, too?=C2=A0

=C2=A0=

Thanks,

Krzysztof=

=C2=A0=

On 2021 -Nov-19,= at 16:43, Tarek Saad <tsaad.net@gmail.com> wrote:

=C2=A0=

Hi Krzystof,

=C2=A0

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

=C2=A0

=C2=A0 o=C2=A0 In = an MP2MP connectivity matrix=C2=A0each of the N CEs can be a sending

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 CE such that its traffic is delivered to all of the other C= Es.

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0

My suggestion is t= o decouple replication service from connectivity. This allows one to do uni= cast or multicast delivery on any type of connectivity.

=C2=A0

Regards,

Tarek

=C2=A0

From:=C2=A0Krzysztof Szarkowicz <= kszarkowicz@gmail.com>
Date:=C2=A0Friday, November 19, 2021 at 10:02 AM
To:= =C2=A0Tarek Saad <tsaad.net@gmail.com>, Igor Bryskin <i_bryskin@yahoo.com>
Cc:= =C2=A0"jie.d= ong@huawei.com" <jie.dong@huawei.com>, "adrian@oldd= og.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Subject:=C2=A0Re: [Teas] Slicing : The term Connectivity Matrix=

=C2=A0=

Hi Tarek, Igor,<= u>

=C2=A0=

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

=C2=A0=

Regards,<= u>

Krzysztof=

=C2=A0=

=C2=A0=

=C2=A0=

On 2021 -Nov-17,= at 16:46, Tarek Saad <tsaad.net@gmail.com> wrote:

=C2=A0=

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

=C2=A0

Regards,

Tarek

=C2=A0

From:=C2=A0Teas <teas-bounce= s@ietf.org> on behalf of Igor Bryskin <i_bryskin=3D40yahoo.com@d= marc.ietf.org>
Date:=C2=A0Wednesday, November 17, 2021 at 10:08 AM
To:= =C2=A0jie.dong@hu= awei.com=C2=A0<jie.dong@huawei.com>, Dongjie (Jimmy) <jie.dong@huawei.com>,=C2=A0adrian@olddog.co.uk=C2=A0<adrian@olddog.co.uk>,= =C2=A0teas@ietf.org= =C2=A0<= teas@ietf.org>
Subject:=C2=A0Re: [Teas] Slicing : The term Connectivity Matrix=

Ji Jia,

=C2=A0=

IMHO connectivit= y construct and connectivity=C2=A0 matrix will share the same set of types.= However, a connectivity=C2=A0 construct of one (more complex) type could b= e described via connectivity=C2=A0 matrix of another (simpler) type. For example, a mp2mp
=C2=A0connectivity construct=C2=A0 could be described as p2mp connectivity = matrix, each of each entries (i.e. p2mp constructs) in turn, could be expre= ssed either as basic (i.e. to be realized via p2mp tunnels) or=C2=A0 as p2p= connectivity matrices.=C2=A0

=C2=A0=

This approach wo= uld make a connectivity construct of any complexity recursively reducable t= o constructs of simpler types.

=C2=A0=

Another examples= : any2any p2p construct could be expressed as a p2p connectivity matrix, mp= 2p construct =3D=E3=80=8Bp2p matrix, etc.

=C2=A0=

Cheers,=C2=A0=

Igor

Sent = from Yahoo Mail on Android

=C2=A0=

On Wed, Nov 1= 7, 2021 at 6:36 AM, Dongjie (Jimmy)

<jie.dong@huawei.com&g= t; wrote:

Hi Adrian,

= =C2=A0

Thanks for the effort on clarify= ing the terminology.

= =C2=A0

With the introduction of =E2=80= =9Cconnectivity construct=E2=80=9D, my understanding is that it is the basi= c construct to describe the service connectivity demands, and a connectivity matrix is the collection of the connectivity c= onstructs in a network slice service. Is this correct?

= =C2=A0

Then a question is, does the pre= vious =E2=80=9Cconnectivity matrix types=E2=80=9D apply to the connectivity= construct? =C2=A0=C2=A0My 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.

= =C2=A0

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

= =C2=A0

Best regards,

Jie

= =C2=A0

From:=C2=A0Teas [mailto:teas-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Adrian= Farrel Sent:=C2=A0Monday, November 15, 2021 11:55 PM
To:= =C2=A0= 'Igor Bryskin' <i_bryskin@yahoo.com>;=C2=A0teas@ietf.org
Subject:=C2=A0Re: [Teas] Slicing : The term Connectivity Matrix

=C2=A0

Hi Igor,

=C2=A0

I think you are describing a hierarchy of constructs=E2=80=A6

=C2=A0

Slice Service=E2=80=A6

=C2=A0 =C2=A0Connectivity Matrix=E2=80=A6

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Connectivity Construct=E2=80= =A6<= /p>

=C2=A0

I was previously using the term =E2=80=9Cmatrix=E2=80=9D to describ= e the third of these, but many people (including you?) assumed I meant the = second of these.

=C2=A0

Therefore, I want to clarify that point by using the term Connectiv= ity Construct.<= /u>

=C2=A0

Now=E2=80=A6

Can a slice service have more than one connectivity construct?

I believe we all agree, yes.

=C2=A0

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.

=C2=A0

OK?=

=C2=A0

Thanks,=

Adrian<= /u>

=C2=A0

From:=C2=A0Igor Bryskin <i_bryskin@yahoo.com>=C2=A0
Sent:=C2=A015 November 2021 15:47
To:= =C2=A0= mohamed.b= oucadair@orange.com;=C2=A0mohamed.boucadair@orange.com;=C2=A0<= /span>adrian@olddog.co.uk;=C2=A0teas@ietf.org
Subject:=C2=A0Re: [Teas] Slicing : The term Connectivity Matrix

=C2=A0

Hi,=

=C2=A0

Connectivity matrix means that you can describe multiple connectivi= ty constructs (each applied to a separate subset of senders/receivers) as a= rectangle specified=C2=A0 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 s= ingle connectivity matrix per slice is sufficient. For what it is worth, th= is is how Connectivity Matrix container for a TE node is defined by the TE Topology model.

=C2=A0

Regards,

Igor

Sent from Yahoo Mail on Android

=C2=A0

On Mon, Nov 15, 2021 at 10= :05 AM,=C2=A0mohamed.boucadair@orange.com

<mohamed.boucadair@orange.com> wrote:

Hi Adrian, all,
I like the change= . Thanks.=C2=A0

Cheers, Med

> -----Message= d'origine-----
> De=C2=A0: Te= as <teas-boun= ces@ietf.org> De la part de Adrian Farrel
> Envoy=C3=A9= =C2=A0: lundi 15 novembre 2021 15:23
> =C3=80=C2=A0= :=C2=A0teas@ietf.org
> Objet=C2=A0:= [Teas] Slicing : The term Connectivity Matrix
>= =C2=A0
> There seems = to be a lot of distress about the term "Connectivity Matrix".
>= =C2=A0
> Although, by= "matrix", I intended, "The set of conditions that provides = a
> system in wh= ich something grows or develops," I think that the
> mathematicia= n amongst us may have assumed, "A group of numbers or other
> symbols arra= nged in a rectangle."
>= =C2=A0
> So I propose= to change the term (but not the meaning) in order to better
> capture what= the text is trying to describe.
>= =C2=A0
> Would "= connectivity construct" suit you all?
>= =C2=A0
> Thanks,
> Adrian
>= =C2=A0
> ____________= ___________________________________
> Teas mailing= list
>= =C2=A0 Teas@ietf.org
>= =C2=A0https:= //www.ietf.org/mailman/listinfo/teas

_________________= ___________________________________________________________________________= _____________________________

Ce message et ses= pieces jointes peuvent contenir des informations confidentielles ou privil= egiees et ne doivent donc
pas etre diffuses= , exploites ou copies sans autorisation. Si vous avez recu ce message par e= rreur, veuillez le signaler
a l'expediteu= r et le detruire ainsi que les pieces jointes. Les messages electroniques e= tant susceptibles d'alteration,
Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.<= /span>

This message and = its attachments may contain confidential or privileged information that may= be protected by law;
they should not b= e distributed, used or copied without authorisation.
If you have recei= ved this email in error, please notify the sender and delete this message a= nd its attachments.
As emails may be = altered, Orange is not liable for messages that have been modified, changed= or falsified.
Thank you.=

_________________= ______________________________
Teas mailing list=
Teas@ietf.org
https://www.ietf.or= g/mailman/listinfo/teas

_______________________________________________
Teas mailing list=
Teas@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/teas=

=C2=A0

_____________________________________= __________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

_____________________________________= __________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

=C2=A0

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas