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

From: Xufeng Liu <[email-masked]>
Date: Thu, 16 Dec 2021 10:36:22 -0500

I would agree with Reza's description above. To put it in a more formal
form, the following can be a modeling proposal:

 +--rw connectivity-constructs
 |  +--rw connectivity-construct* [id]
 |  |  +--rw id                  uint32
 |  |  +--rw from
 |  |  |  +--rw end-point?            string
 |  |  +--rw to
 |  |  |  +--rw end-point?            string
 |  |  +--rw underlay?
 |  |  +--rw path-constraints
 |  |  +--rw optimizations
 |  +--rw replication-group* [id]
 |  |  +--rw id                  uint32
 |  |  +--rw entry*              -> ../../connectivity-construct/id
 |  +--rw receiver-constraint-group* [id]
 |     +--rw id                  uint32
 |     +--rw entry*              -> ../../connectivity-construct/id
 |     +--rw te-bandwidth
 |     |  +--rw (technology)?
 |     |     +--:(generic)
 |     |        +--rw generic?   te-bandwidth

Note: This model structure follows RFC8795, with some naming
adjustments and augmentations of "replication-group" and
"receiver-constraint-group". The model in RFC8795 supports only P2P.
The "replication-group" above is used to model the behavior of
multicast, and the "receiver-constraint-group" is used to model the
constraints on receiving end-points.

Examples:

1) P2P
   NSE3 <-> NSC7
   NSE4 -> NSE8

{
  "connectivity-constructs": {
    "connectivity-construct": [
      "id": 1,
      "from": {
        "end-point": "NSE3"
      },
      "to": {
        "end-point": "NSE7"
      }
    ],
    "connectivity-construct": [
      "id": 2,
      "from": {
        "end-point": "NSE7"
      },
      "to": {
        "end-point": "NSE3"
      }
    ],
    "connectivity-construct": [
      "id": 3,
      "from": {
        "end-point": "NSE4"
      },
      "to": {
        "end-point": "NSE8"
      }
    ]
  }
}

2) P2MP
   NSE5 -> {NSC9, NSE10}

{
  "connectivity-constructs": {
    "connectivity-construct": [
      "id": 1,
      "from": {
        "end-point": "NSE5"
      },
      "to": {
        "end-point": "NSE9"
      }
    ],
    "connectivity-construct": [
      "id": 2,
      "from": {
        "end-point": "NSE5"
      },
      "to": {
        "end-point": "NSE10"
      }
    ],
    "replication-group": [
      "id": 1,
      "entry": [1, 2]
    ]
  }
}

3) MP2MP
   {NSE14, NSE15} -> {NSE16, NSE17}

{
  "connectivity-constructs": {
    "connectivity-construct": [
      "id": 1,
      "from": {
        "end-point": "NSE14"
      },
      "to": {
        "end-point": "NSE16"
      }
    ],
    "connectivity-construct": [
      "id": 2,
      "from": {
        "end-point": "NSE14"
      },
      "to": {
        "end-point": "NSE17"
      }
    ],
    "connectivity-construct": [
      "id": 3,
      "from": {
        "end-point": "NSE15"
      },
      "to": {
        "end-point": "NSE16"
      }
    ],
    "connectivity-construct": [
      "id": 4,
      "from": {
        "end-point": "NSE15"
      },
      "to": {
        "end-point": "NSE17"
      }
    ],
    "replication-group": [
      "id": 1,
      "entry": [1, 2]
    ],
    "replication-group": [
      "id": 2,
      "entry": [3, 4]
    ],
    "receiver-constraint-group": [
      "id": 1,
      "entry": [1, 3]
    ],
    "receiver-constraint-group": [
      "id": 2,
      "entry": [2, 4]
    ]
  }
}

3) A2A
   {NSE1, NSE2, NSE6} -> {NSE1, NSE2, NSE6}

{
  "connectivity-constructs": {
    "connectivity-construct": [
      "id": 1,
      "from": {
        "end-point": "NSE1"
      },
      "to": {
        "end-point": "NSE2"
      }
    ],
    "connectivity-construct": [
      "id": 2,
      "from": {
        "end-point": "NSE1"
      },
      "to": {
        "end-point": "NSE6"
      }
    ],
    "connectivity-construct": [
      "id": 3,
      "from": {
        "end-point": "NSE2"
      },
      "to": {
        "end-point": "NSE1"
      }
    ],
    "connectivity-construct": [
      "id": 4,
      "from": {
        "end-point": "NSE2"
      },
      "to": {
        "end-point": "NSE6"
      }
    ],
    "connectivity-construct": [
      "id": 5,
      "from": {
        "end-point": "NSE6"
      },
      "to": {
        "end-point": "NSE1"
      }
    ],
    "connectivity-construct": [
      "id": 6,
      "from": {
        "end-point": "NSE6"
      },
      "to": {
        "end-point": "NSE2"
      }
    ]
  }
}

Thanks,
- Xufeng

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Nov 22, 2021 at 6:33 AM Simon Spraggs (sspraggs) <sspraggs=
[email-masked]> wrote:

> 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:
>       1. 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.
>       2. 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.
>       3. 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,
>
>
>
> 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:
>
>
>
> 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:
>
>
>
>
>
> 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,
>
>
>
> 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:
>
>
>
> 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,
>
> 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 Wed, Nov 17, 2021 at 6:36 AM, Dongjie (Jimmy)
>
> <[email-masked]> wrote:
>
> 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] <[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,
>
>
>
> 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,
>
>
>
> 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,
>
> 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
> >
> > 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
> >
> > _______________________________________________
> > 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.
>
>
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
>
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>