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

From: "Simon Spraggs (sspraggs)" <[email-masked]>
Date: Wed, 3 Nov 2021 09:49:23 +0000

Hi Adrian,
    Please forgive me if this has already been discussed as I've only recently started tracking this discussion. Couple of comments.
1) This concept of a n by n connectivity matrix sounds good when applied to a small number of sites and a single class of service.  I wonder whether it's going to become completely unusable when the number of sites gets into the 100s, 1000s and even 10,000s and there are multiple classes of services particularly when applied to MP2MP and A2A topologies.
2) It seems to me that we need to think about SLA models used in the network industry today. For P2P we use a pipe model, so a simple 1 by 1 connectivity matrix is fine, although I do question the need for a connectivity matrix in this case. For A2A and PM2PM and to some extent MP2P and P2PM SLAs are often based on a hose model where rather than defining a connectivity matrix between sites, the service is defined by the level of traffic to and from the customer (CE) and the network provider (PE). This can be applied on the CE or PE or even both. This is scalable even with 10,000s of sites and multiple levels of services within the same VPN at the network level, it is also scalable from a service modelling perspective. 

Cheers Simon

On 25/10/2021, 18:43, "Teas on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

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

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

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

    I think the second point is the major challenge. 

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

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

    That gives us:

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

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

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

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

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

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

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

    Best,
    Adrian

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

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Wed, 3 Nov 2021 12:39:09 +0100

Hi Simon,

I think with the current text in the draft, all use cases you mentioned in point 2) suppose to be covered with any-to-any slice type. I.e., as far as I understand the current text, only any-to-any slice type allows SLO definition as ingress/egress parameters on AC link (rather that some parameters on CE-to-CE virtual connection).

Thanks,
Krzysztof

> On 2021 -Nov-03, at 10:49, Simon Spraggs (sspraggs) <sspraggs=[email-masked]> wrote:
> 
> Hi Adrian,