Subject: Re: [Teas] Network slicing framework : Issue #1 : What is a connectivity matrix?

From: Xufeng Liu <[email-masked]>
Date: Fri, 1 Oct 2021 15:44:03 -0400

The use case that Krzysztof described can be covered by the Type 2 VN
(Virtual Network) described in RFC 8453. The request can be presented as
one virtual/logical/abstract node with 48 endpoints. Each endpoint has a
bandwidth of 1GB.

The use cases that can be satisfied by a connectivity matrix are covered by
the Type 1 VN (Virtual Network) described in RFC 8453.

It seems that both service types should be covered in this document, as in
RFC 8453.

Thanks,
- Xufeng

On Tue, Sep 28, 2021 at 7:00 AM Krzysztof Szarkowicz <[email-masked]>
wrote:

> Hi Adrian,
>
> Let add my comments as well.
>
> MP2P and MP2MP slices might have two different types: with connectivity
> matrixes defining SLO (as discussed in this thread), or with ingress/egress
> SLO per endpoint.
>
> Imaging following use case. Vendor-X produces Ethernet switch (or IP
> router) with 48 x 1G ports, and SLO provided by this switch/router is:
>
> - Guaranteed 1G ingress BW on each port
> - Guaranteed 1G egress BW on each port
> - Maximum latency between any two ports: ‘X’ microseconds.
>
> As you see, there is no connectivity matrix in above SLO definitions. Does
> it mean, can I send 1G from each of 47 ports to remaining 48th port -
> absolutely not! 48th port has only 1G ingress/egress guarantee, not 47G.
>
> Now, instead of having physical switch (or router) I would like to
> implement above as some sort of ‘virtual switch/router’ - as network slice
> service, with 48 end-points, each end-point having guaranteed 1G
> uplink/downlink capacity, and max latency between any two EPs ‘X’
> milliseconds. Again, SLO is not defined here as connectivity matrix.
>
> Above is very common in fact - many L3VPN business services use above
> approach in SLO definitions.
>
> Best regards,
> Krzysztof
>
>
> > On 2021 -Sep-28, at 11:19, Oscar González de Dios <
> [email-masked]> wrote:
> >
> > Hi Adrian,
> >
> >        My 2 cents (and personal View) on the topic, complementing
> >
> >        I fully agree with decoupling routing from "connectivity matrix"
> (or whatever name you come up). Some thoughts here to see if we have the
> same understanding:
> >
> >        A) A slice could be "just" a set of "connectivity matrixes". In
> that case, the slice would "expose" all the endpoints of all the
> connectivity matrixes to the customer, who will know the behavior (not how
> things are done internally). The customer has to take care of all his
> routing (that is, he has to know the slice destination endpoints to use for
> every packet/frame sent, not as in a regular vpn where the customer sends
> packets with the customer addresses and the vpn knows what to do),  as the
> customer knows what will happen when a packet (or frame or light) enters
> each endpoint. The customer will need to explicitly enter the traffic in
> the correct exposed endpoint-connectivity matrix.
> >
> >        This type of slice is "perfect" for the cases where the customers
> are, for example, routers.
> >
> >        B) A "connectivity matrix" can be realized by different
> technologies. This could be open to negotiation, open to have preferences
> by customer, fully free. Not only MPLS-TE or SR-policy based for a packet
> network, a slice could be a set of optical connections..
> >
> >        C) The customer, during the lifecycle of the slice, can interact
> and request changes on the connectivity matrixes. For example, the slices
> has some resources given, so the customer can choose to put all rosources
> from A-B, and then change from A-C. Of course, if they are in the agreed
> terms. One technology-specific example is a customer's slice where the
> resources granted are a set of OTN links and client ports, and he is free
> to select the low level ODUs between the customer ports.
> >
> >        D) Each connection of the connectivity matrix can have different
> guarantees, can be best effort, guaranteed bandwidth, delay, security,
> isolation, etc etc.
> >
> >        E) In a "regular" VPN, most of the complexity is associated with
> the routing of the customer traffic. The customer just sends a packet via
> the CE-PE connection, and the service provider does it job to make it to
> the other end. Internally, the service provider will have its connectivity
> between the end points. Do you envision that the IETF Network slice will
> also include the routing part? In my view, it could be considered something
> optional, and that if you use it, it can be realized by multiple
> technologies (e.g. BGP Based VPNs such as EVPN, etc)... I see that for some
> of  proposed use cases, it is difficult to get rid of the routing part...
> >
> >
> >        Best Regards,
> >
> >             Oscar
> >
> >
> >
> > -----Mensaje original-----
> > De: Teas <[email-masked]> En nombre de Adrian Farrel
> > Enviado el: martes, 28 de septiembre de 2021 10:00
> > Para: [email-masked]
> > CC: [email-masked]
> > Asunto: Re: [Teas] Network slicing framework : Issue #1 : What is a
> connectivity matrix?
> >
> > Hi Peng,
> >
> > I think we need to make a distinction between two things:
> > - how a network slice service is specified in the contract between the
> consumer and the provider
> > - how the provider manages their network to deliver the network slice
> service (the network slice)
> >
> > What you say here is all about how the network slice is built by the
> provider. It is true that this may require the provider to provision paths
> (such as TE paths) and to reserve resources at transit nodes.
> >
> > BUT...
> >
> > How this is done, what techniques are used, what management or control
> plane protocols are used, etc., is a function of the network technology and
> the solution that is selected. For example, the operation in an IP-based
> DSCP environment will be very different from an SR-policy solution, and
> that is very different from MPLS-TE. This framework document does not spend
> much time on solutions except at a very high level because it is supposed
> to be an abstract framework. The solutions work is left to other documents
> (and there are already plenty of them).
> >
> > What this document is doing is describing the network slice service. The
> service is expressed in terms of edge nodes only (endpoints) : the consumer
> has no right to know about the transit nodes used to deliver the service.
> Thus, the SLOs are part of the contract between the consumer and the
> provider and they are applied at the ingress endpoints : how the provider
> chooses to map those SLOs to resource reservations and policies within the
> network is private to the provider's choice of solution and is kept secret
> from the consumer. (Indeed, one solution is to lay edge-to-edge fibre in a
> full mesh and achieve high bandwidth with low latency!)
> >
> > The connectivity matrix may be thought about as tunnels between the
> endpoints. That is (in the definition of a tunnel), traffic presented at an
> ingress is delivered transparently to all of the egress nodes. Whether this
> is actually implemented using a tunnelling technology (e.g., MPLS) or
> whether the traffic is just IP routed, is not know to the consumer and is a
> provider choice depending on which solution they are using.
> >
> > The value of describing the connectivity matrix as "like a tunnel" is
> that it explains the nature of the connectivity matrix as compared to a
> virtual network. That is, in a virtual network with five edge nodes (A, B,
> C, D, E), a packet presented at A may be routed to and of B, C, D, or E
> depending on the destination address, and the network is responsible for
> achieving that routing. A connectivity matrix is much more explicit: the
> network slice service with the same four edge nodes may have several
> connectivity matrices rooted at A (A-C, A-D, A-{B, C, D}). If a packet is
> presented to the first of these it is delivered to C regardless of its
> address (although the address may be used at A to help select which
> connectivity matrix to use). If a packet is presented to the third of
> these, it is delivered to all of B, C, and D, regardless of its address.
> And, with this set of connectivity matrices, packets cannot be sent from A
> to E (which can be achieved in a virtual network).
> >
> > Best,
> > Adrian
> > -----Original Message-----
> > From: [email-masked] <[email-masked]>
> > Sent: 28 September 2021 04:37
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re:[Teas] Network slicing framework : Issue #1 : What is a
> connectivity matrix?
> >
> > Hi Adrian,
> >
> > IMO, for a given network slice, the best-effort traffic in that network
> slice may invole all nodes (especially caused by node/link events), for
> example, for a given traffic, although edge A and B are PE device, edge C
> and D may be potential intermediate nodes, thus all these nodes need to
> reserve corresponding resources for the traffic through. So that it seems
> that, at least, a common SLO need to be configured on each node within that
> slice.
> >
> > However, more TE paths (connectivity matrix you mentioned ?) can be
> created within a network slice. For a given network slice, the bandwidth
> resources of TE paths of that slice need to be reserved, and at the same
> time the bandwidth of best-effort paths of that slice need to be reduced.
> For this reason, and to distinguish the treatment of TE traffic and
> best-effort traffic for that slice, additional DSCP-based or a
> further-slice-id based queue/bandwidth resources (different SLO you
> mentioned ?) may be used. TE traffic and best-effort traffic can use
> resource sharing group to avoid resource waste, i.e., best-effort service
> can use bandwidth resources of TE service when the latter has no traffic
> transmission.
> >
> > Regards,
> > PSF
> >
> >
> > ------------------原始邮件------------------
> > 发件人：AdrianFarrel
> > 收件人：'TEAS WG';
> > 日 期 ：2021年09月28日 00:09
> > 主 题 ：[Teas] Network slicing framework : Issue #1 : What is a
> connectivity matrix?
> > Hi,
> > We have usually seen a virtual network as a set of potential connections
> or connectivity possibilities. Consider four nodes A, B, C, D at the edge
> of a virtual network: it is normal to consider that traffic may be sent
> from any to any. This is achieved by routing or by the establishment of a
> full mesh of tunnels. It is not part of the specification of such a VN
> whether there will be traffic from B to C, or whether D will want to
> multicast traffic to A and B. This function is either provided by routing
> within the VN or by the establishment of tunnels within the VN.
> > There is nothing wrong with this.
> > But in the context of a network slice, we have determined that it is
> useful to specify more precisely which edges are connected to which other
> edges.
> > This allows us to have different SLOs/SLEs for the connections and to
> specify exactly what traffic demands will be placed.
> > Note that a p2mp connectivity matrix means that traffic placed on the
> matrix will be delivered to all the destination endpoints. That is *will*
> not "may depending on how it is addressed".
> > This means that a VN as previously discussed is a set of n(n-1) p2p
> connection matrices, and possibly a set of n p2mp connectivity matrices
> (also achievable as one mp2mp matrix).
> > [[ NOTE WELL : We come to the question of how many connection matrices
> in a slice as a separate issue. Please don't discuss it here! ]] Any debate?
> > Does the text in the draft need more clarity on this point?
> > Is "connectivity matrix" too confusing. Should we revert to "connection"
> or something similar?
> > Hint: I don't like "connection" because it seems to imply a
> connection-oriented situation, where "connectivity" just means "data gets
> through".
> > Or can I close this issue and rest with the text in the draft?
> > Cheers,
> > Adrian
> > _______________________________________________
> > Teas mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/teas
> >
> > _______________________________________________
> > Teas mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/teas
> >
> > ________________________________
> >
> > 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
> > _______________________________________________
> > Teas mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: <[email-masked]>
Date: Fri, 8 Oct 2021 09:20:47 +0800 (CST)

Hi Adrian,

Thanks for your clarification, that is clear.

Regards,
PSF

------------------原始邮件------------------
发件人：AdrianFarrel
收件人：彭少富10053815;
抄送人：[email-masked];
日 期 ：2021年09月28日 16:00
主 题 ：Re: [Teas] Network slicing framework : Issue #1 : What is a connectivity matrix?
Hi Peng,

I think we need to make a distinction between two things:
- how a network slice service is specified in the contract between the consumer and the provider
- how the provider manages their network to deliver the network slice service (the network slice)

What you say here is all about how the network slice is built by the provider. It is true that this may require the provider to provision paths (such as TE paths) and to reserve resources at transit nodes.

BUT...

How this is done, what techniques are used, what management or control plane protocols are used, etc., is a function of the network technology and the solution that is selected. For example, the operation in an IP-based DSCP environment will be very different from an SR-policy solution, and that is very different from MPLS-TE. This framework document does not spend much time on solutions except at a very high level because it is supposed to be an abstract framework. The solutions work is left to other documents (and there are already plenty of them).

What this document is doing is describing the network slice service. The service is expressed in terms of edge nodes only (endpoints) : the consumer has no right to know about the transit nodes used to deliver the service. Thus, the SLOs are part of the contract between the consumer and the provider and they are applied at the ingress endpoints : how the provider chooses to map those SLOs to resource reservations and policies within the network is private to the provider's choice of solution and is kept secret from the consumer. (Indeed, one solution is to lay edge-to-edge fibre in a full mesh and achieve high bandwidth with low latency!)

The connectivity matrix may be thought about as tunnels between the endpoints. That is (in the definition of a tunnel), traffic presented at an ingress is delivered transparently to all of the egress nodes. Whether this is actually implemented using a tunnelling technology (e.g., MPLS) or whether the traffic is just IP routed, is not know to the consumer and is a provider choice depending on which solution they are using.

The value of describing the connectivity matrix as "like a tunnel" is that it explains the nature of the connectivity matrix as compared to a virtual network. That is, in a virtual network with five edge nodes (A, B, C, D, E), a packet presented at A may be routed to and of B, C, D, or E depending on the destination address, and the network is responsible for achieving that routing. A connectivity matrix is much more explicit: the network slice service with the same four edge nodes may have several connectivity matrices rooted at A (A-C, A-D, A-{B, C, D}). If a packet is presented to the first of these it is delivered to C regardless of its address (although the address may be used at A to help select which connectivity matrix to use). If a packet is presented to the third of these, it is delivered to all of B, C, and D, regardless of its address. And, with this set of connectivity matrices, packets cannot be sent from A to E (which can be achieved in a virtual network).

Best,
Adrian
-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: 28 September 2021 04:37
To: [email-masked]
Cc: [email-masked]
Subject: Re:[Teas] Network slicing framework : Issue #1 : What is a connectivity matrix?

Hi Adrian,

IMO, for a given network slice, the best-effort traffic in that network slice may invole all nodes (especially caused by node/link events), for example, for a given traffic, although edge A and B are PE device, edge C and D may be potential intermediate nodes, thus all these nodes need to reserve corresponding resources for the traffic through. So that it seems that, at least, a common SLO need to be configured on each node within that slice.

However, more TE paths (connectivity matrix you mentioned ?) can be created within a network slice. For a given network slice, the bandwidth resources of TE paths of that slice need to be reserved, and at the same time the bandwidth of best-effort paths of that slice need to be reduced. For this reason, and to distinguish the treatment of TE traffic and best-effort traffic for that slice, additional DSCP-based or a further-slice-id based queue/bandwidth resources (different SLO you mentioned ?) may be used. TE traffic and best-effort traffic can use resource sharing group to avoid resource waste, i.e., best-effort service can use bandwidth resources of TE service when the latter has no traffic transmission.

Regards,
PSF

------------------原始邮件------------------
发件人：AdrianFarrel
收件人：'TEAS WG';
日 期 ：2021年09月28日 00:09
主 题 ：[Teas] Network slicing framework : Issue #1 : What is a connectivity matrix?
Hi,
We have usually seen a virtual network as a set of potential connections or
connectivity possibilities. Consider four nodes A, B, C, D at the edge of a
virtual network: it is normal to consider that traffic may be sent from any
to any. This is achieved by routing or by the establishment of a full mesh
of tunnels. It is not part of the specification of such a VN whether there
will be traffic from B to C, or whether D will want to multicast traffic to
A and B. This function is either provided by routing within the VN or by the
establishment of tunnels within the VN.
There is nothing wrong with this.
But in the context of a network slice, we have determined that it is useful
to specify more precisely which edges are connected to which other edges.
This allows us to have different SLOs/SLEs for the connections and to
specify exactly what traffic demands will be placed.
Note that a p2mp connectivity matrix means that traffic placed on the matrix
will be delivered to all the destination endpoints. That is *will* not "may
depending on how it is addressed".
This means that a VN as previously discussed is a set of n(n-1) p2p
connection matrices, and possibly a set of n p2mp connectivity matrices
(also achievable as one mp2mp matrix).
[[ NOTE WELL : We come to the question of how many connection matrices in a
slice as a separate issue. Please don't discuss it here! ]]
Any debate?
Does the text in the draft need more clarity on this point?
Is "connectivity matrix" too confusing. Should we revert to "connection" or
something similar?
Hint: I don't like "connection" because it seems to imply a
connection-oriented situation, where "connectivity" just means "data gets
through".
Or can I close this issue and rest with the text in the draft?
Cheers,
Adrian
_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas