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

[Adrian Farrel <[e-mail]>]

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: [e-mail] <[e-mail]> 
Sent: 28 September 2021 04:37
To: [e-mail]
Cc: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/teas