Re: [Teas] Proposed text on "IETF Network Slicing Service"

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi Adrian,

Thanks for your clarifications, and apologies for the late response (I’m on holidays, checking mails time to time).

I have some further comments, in-line.

Thanks

Luis

De: Adrian Farrel <[e-mail]>
Enviado el: viernes, 13 de agosto de 2021 23:48
Para: 'Luis M. Contreras' <[e-mail]>
CC: 'TEAS WG' <[e-mail]>; [e-mail]; [e-mail]
Asunto: RE: [Teas] Proposed text on "IETF Network Slicing Service"

Hi Luis,

Thanks for reading and asking.

Replies in line.

>> 3.2. IETF Network Slice Service
>>
>> A service provider instantiates an IETF network slice service for a
>> customer.  The IETF network slice service is specified in terms of a
>> set of the customer's endpoints (CEs), a set of connectivity matrices
>> (point-to-point (P2P), point-to-multipoint (P2MP), multipoint-to-
>> point (MP2P), or multipoint- to-multipoint (MP2MP)) between subsets
>> of these CEs, and a set of SLOs and SLEs for each CE sending to each
>> connectivity matrix.
>
> [Luis>>] Does it mean that only the sending SLOs/SLEs would be
> considered? For instance, in MP situations, a given CE in the
> receiving direction could have limitations if all the sending parties
> simultaneously use the peak capacity. Expressing such limitations
> could help for instance to make the IETF NSC to infer the need of
> applying some shaping to the traffic. Thus, it can be convenient
> also to express the SLOs/SLEs in the receiving direction as well.
> (This applies also to the hub and spoke case referred below)

While knowledge of the receiver’s capabilities are important to determine the SLOs/SLEs at the sender, isn’t it normal for the CEs to be responsible for the policing and flow control at the ingress side: the network itself is not involved in policing or shaping beyond handling traffic that is in excess of any reservations. I think that is the standard model for transport (underlay, TE) protocols.
[Luis>>] Clear the point for the CE. However (and, precisely, because the fact that the CE is not responsible for policing at the ingress side) we could expect that the network assumes the responsibility of handling the traffic delivered to the CE to be compliant with the expectations of the customer in terms of SLOs/SLEs also in the receiving direction. The only possibility of doing so is by providing such information at the time of requesting the slice.

>> I.e., in a given IETF Network Slice Service
>> there may be multiple connectivity matrices of the same or different
>> type, each connectivity matrix may be between a different subset of
>> CEs, and for a given connectivity matrix each sending CE has its own
>> set of SLOs and SLEs, and the SLOs and SLEs in each set may be
>> different.  It is also the case that a given sending CE may be part
>> of multiple connectivity matrices within a single IETF network slice
>> service, and the CE may have different SLOs and SLEs for each
>> connectivity matrix to which it is sending.  Note that a given
>> sending CE's SLOs and SLEs for a given connectivity matrix apply
>> between it and each of the receiving CEs for that connectivity
>> matrix.
>
> [Luis>>] I'm not sure about this. I think it is more clear to have a
> single connectivity matrix per slice service. Let me explain why. In
> my understanding, each connectivity matrix is elicited to satisfy a
> given service with certain (and particular) SLOs/SLEs that make it
> different from another service of the same customer. That is, the
> customer wants to differentiate those services on purpose. And
> at the time of requesting those services, the customer will ask for
> different slices (as a service) to support them. In summary for me
> it is more natural to associate one single matrix per slice. Also
> note the complexity of handling those different matrices during
> the lifecycle. We would require some form of identifier or
> distinguisher for each of them. Imagine that the customer wants
> to modify some of the matrices but not all. How to refer to such
> specific matrix? How to manage the different lifecycles of each
> matrix? All becomes much more simpler if we manage a single
> connectivity matrix per slice. And finally, how can be ensure the
> consistency of requirements between matrices in terms of
> SLOs/SLEs for a common CE? Inconsistencies can appear.

It is important that the architecture allow you to run your network the way you want. So it is a requirement that you should be permitted to specify each IETF network slice with exactly one connectivity matrix.

I think that my proposed text allows exactly this as a specific case of the more general approach that also enables those who want to to define more than one connectivity matrix within a slice.
[Luis>>] Probably I’m not understanding well the point. In my view, one slice should have only one connectivity matrix. This means that whatever SLOs/SLEs in the matrix are unique per CE pair (I comment on this as response to some of your clarifications later on). For example, between CE_1 and CE_2 the SLOs/SLEs = {SLx_1-2} are unique. If we require different SLOs/SLEs among the same two CEs that would be part of a different slice. Going on this way, the relation between slice and connectivity matrix is direct and unique.
With the other commented approach of having multiple connectivity matrices associated to a single slice, that is, having two different sets of SLOs/SLEs between CE_1 and CE_2 (ex., SLOs/SLEs-A = {SLx_1-2-A} and SLOs/SLEs-B = {SLx_1-2-B}), the relationship between slice and connectivity matrix is not direct and would be necessary to use additional identifiers for discriminating each of the connectivity matrices of that slice to avoid any ambiguity.
In summary, in my view, the proper way to follow, as you indicate, is “to specify each IETF network slice with exactly one connectivity matrix”. I would say “one and only one”, expressing in that matrix the relationship of all the CEs that intervene in the slice.

>> This approach results in the following possible connectivity
>> matrices:
>>
>> o  For an MP2MP connectivity matrix with N CEs, each of the N sending
>>     CEs has its own set of SLOs and SLEs and they may all be
>>     different.
>
> [Luis>>] I suppose that the SLOs/SLEs would be expressed by pairs,
> i.e., CEx <-> CEy, right? So the set of SLOs/SLEs would be per pair of
> CEs. Otherwise we would have a list (array) and not a matrix. (This
> comment can also apply to the other cases with the corresponding
> particularity for each of them)

When you define a point-to-multipoint connectivity construct (or multipoint-to-multipoint) the idea is that all traffic from any sender gets delivered to all receivers. That is, it is a connection, not a topology. Thus, the SLO/SLE set for a sender in a connectivity construct applies to all the receivers in that connectivity construct. I think this is clearly stated.
[Luis>>] I think this could not apply for the case of slicing. The reason for that is because the traffic from one CE to other CEs could be very different in nature (that is on required SLOs/SLEs). For instance, let me take as example the radio functional split case documented in draft-contreras-teas-slice-nbi-05, section 4.5 / figure 5. There you can see the DU component dealing simultaneously with fronthaul and midhual traffic. This traffics show very different characteristics in terms of BW, jitter, etc. Thus we need to find the way of expressing the different connections that a single CE could require. This is why I think the SLOs/SLEs should be expressed by pairs, i.e., CEx <-> CEy, or at least, this form should be allowed.

>> o  For a P2MP connectivity matrix, there is only one sending CE, and
>>     there is only one set of SLOs and SLEs.
>>
>> o  For an MP2P connectivity matrix with N CEs, there is one receiving
>>     CE and (N - 1) sending CEs.  Each sending CE has its own set of
>>     SLOs and SLEs and they may all be different.
>>
>> o  For a P2P unidirectional connectivity matrix, there is only one
>>     sending CE and there is only one set of SLOs and SLEs.
>>
>> o  For a P2P bidirectional connectivity matrix, there are two sending
>>     CEs, there are two sets of SLOs and SLEs which may be different.
>>
>> If an IETF network slice service customer wants to have hub and spoke
>> connectivity between N CEs in order to control how traffic is
>> distributed between its CEs, it requests a set of N - 1 P2P
>> unidirectional connectivity matrices, each between a sending CE spoke
>> and the hub CE, and a P2MP connectivity matrix between the sending CE
>> hub and the spoke CEs.
>
> [Luis>>] Actually this can be represented by a single, common matrix,
> no need of considering {(N-1)+1} different matrices bounded in some
> form.

I agree that the mp2mp construct defines (at the service level) the correct connectivity as seen by the CEs, it doesn’t represent the hub and spoke functionality.

An operator may decide to deliver mp2mp via a hub, but that is not the point.

If the *customer* wants to achieve hub and spoke functionality (presumably through their own hub site) then they can do as the text describes.

Actually, I’m not very attached to the text here, but someone (can’t recall who – I could look it up) requested that we describe how to achieve this.
[Luis>>] Again, probably I’m not understanding well the point, or I’m interpreting it in a different manner. What I’m referring to is to express the connectivity like this (in the example, applied to hub and spoke, but valid for any kind of connectivity)
     +-----+-----+-----+-----+
     | CEh | CE1 | CE2 | CE3 |
-----+-----+-----+-----+-----+
|CEh |     |sloh1|sloh2|sloh3|
-----+-----+-----+-----+-----+
|CE1 |slo1h|     |     |     |
-----+-----+-----+-----+-----+
|CE2 |slo2h|     |     |     |
-----+-----+-----+-----+-----+
|CE3 |slo3h|     |     |     |
-----+-----+-----+-----+-----+
That is, one single matrix serves to express the connectivity among all the CEs participating in the slice.

>> It should be noted that per Section 9 of [RFC4364] an IETF network
>> slice service customer may actually provide IETF network slice
>> services to other customers.  In this case, the underlying IETF
>> network slice service provider may be owned and operated by the same
>> or a different provider network.
>
> [Luis>>] It is not clear to me the sense of the last sentence. Is the
> purpose of the sentence the following? -> In this case, the underlying
> IETF network slice service provider may be owned and operated by
> A SINGLE OR MULTIPLE providers' networks.

No. This is the “carrier’s carrier” model where the a provider (Provider A) may offer slice services to a customer that is, itself a provider (Provider B). Provider B may also offer slice services to other customers. Provider B may be an internal customer of Provider A (i.e., a sub-division) or an external customer (carrier’s carrier).

This text could probably be clearer. I’ll work on it.
[Luis>>] Ok

>> Section 4.2 provides a description of endpoints in the context of
>> IETF network slicing.  For a given IETF network slice service, the
>> IETF network slice customer and provider agree, on a per-CE basis
>> which end of the attachment circuit provides the service demarcation
>> point.  This determines whether the attachment circuit is included in
>> the set of SLOs and SLEs for the subject CE.
>
> [Luis>>] For the last sentence, would it not be more precise to
> comment in this way? -> This determines whether the attachment
> circuit is included as part of the IETF network slice service (then
> being also the object of the set of SLOs and SLEs for the subject CE).

Yeah, sort of. I mean, whether the AC is part of the service does determine whether or not the AC is part of the service 😊

Perhaps….

  For a given IETF network slice service, the
   IETF network slice customer and provider agree, on a per-CE basis
   which end of the attachment circuit provides the service demarcation
   point (i.e., whether the attachment circuit is inside or outside the
   IETF network slice service).  This determines whether the attachment
   circuit is subject to the set of SLOs and SLEs for the specific CE.
[Luis>>] perfectly fine, thanks

Cheers,
Adrian

From: Luis M. Contreras <[e-mail]<mailto:[e-mail]>>
Sent: 12 August 2021 11:53
To: [e-mail]<mailto:[e-mail]>
Cc: TEAS WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Teas] Proposed text on "IETF Network Slicing Service"

Hi Adrian,

some questions from my side on the proposed text, in-line.

Thanks in advance, best regards

Luis



===

3.2. IETF Network Slice Service

   A service provider instantiates an IETF network slice service for a
   customer.  The IETF network slice service is specified in terms of a
   set of the customer's endpoints (CEs), a set of connectivity matrices
   (point-to-point (P2P), point-to-multipoint (P2MP), multipoint-to-
   point (MP2P), or multipoint- to-multipoint (MP2MP)) between subsets
   of these CEs, and a set of SLOs and SLEs for each CE sending to each
   connectivity matrix.

[Luis>>] Does it mean that only the sending SLOs/SLEs would be considered? For instance, in MP situations, a given CE in the receiving direction could have limitations if all the sending parties simultaneously use the peak capacity. Expressing such limitations could help for instance to make the IETF NSC to infer the need of applying some shaping to the traffic. Thus, it can be convenient also to express the SLOs/SLEs in the receiving direction as well. (This applies also to the hub and spoke case referred below)

I.e., in a given IETF Network Slice Service
   there may be multiple connectivity matrices of the same or different
   type, each connectivity matrix may be between a different subset of
   CEs, and for a given connectivity matrix each sending CE has its own
   set of SLOs and SLEs, and the SLOs and SLEs in each set may be
   different.  It is also the case that a given sending CE may be part
   of multiple connectivity matrices within a single IETF network slice
   service, and the CE may have different SLOs and SLEs for each
   connectivity matrix to which it is sending.  Note that a given
   sending CE's SLOs and SLEs for a given connectivity matrix apply
   between it and each of the receiving CEs for that connectivity
   matrix.

[Luis>>] I'm not sure about this. I think it is more clear to have a single connectivity matrix per slice service. Let me explain why. In my understanding, each connectivity matrix is elicited to satisfy a given service with certain (and particular) SLOs/SLEs that make it different from another service of the same customer. That is, the customer wants to differentiate those services on purpose. And at the time of requesting those services, the customer will ask for different slices (as a service) to support them. In summary for me it is more natural to associate one single matrix per slice. Also note the complexity of handling those different matrices during the lifecycle. We would require some form of identifier or distinguisher for each of them. Imagine that the customer wants to modify some of the matrices but not all. How to refer to such specific matrix? How to manage the different lifecycles of each matrix? All becomes much more simpler if we manage a single connectivity matrix per slice. And finally, how can be ensure the consistency of requirements between matrices in terms of SLOs/SLEs for a common CE? Inconsistencies can appear.


   This approach results in the following possible connectivity
   matrices:

   o  For an MP2MP connectivity matrix with N CEs, each of the N sending
      CEs has its own set of SLOs and SLEs and they may all be
      different.

[Luis>>] I suppose that the SLOs/SLEs would be expressed by pairs, i.e., CEx <-> CEy, right? So the set of SLOs/SLEs would be per pair of CEs. Otherwise we would have a list (array) and not a matrix. (This comment can also apply to the other cases with the corresponding particularity for each of them)


   o  For a P2MP connectivity matrix, there is only one sending CE, and
      there is only one set of SLOs and SLEs.

   o  For an MP2P connectivity matrix with N CEs, there is one receiving
      CE and (N - 1) sending CEs.  Each sending CE has its own set of
      SLOs and SLEs and they may all be different.

   o  For a P2P unidirectional connectivity matrix, there is only one
      sending CE and there is only one set of SLOs and SLEs.

   o  For a P2P bidirectional connectivity matrix, there are two sending
      CEs, there are two sets of SLOs and SLEs which may be different.

   If an IETF network slice service customer wants to have hub and spoke
   connectivity between N CEs in order to control how traffic is
   distributed between its CEs, it requests a set of N - 1 P2P
   unidirectional connectivity matrices, each between a sending CE spoke
   and the hub CE, and a P2MP connectivity matrix between the sending CE
   hub and the spoke CEs.

[Luis>>] Actually this can be represented by a single, common matrix, no need of considering {(N-1)+1} different matrices bounded in some form.


   It should be noted that per Section 9 of [RFC4364] an IETF network
   slice service customer may actually provide IETF network slice
   services to other customers.  In this case, the underlying IETF
   network slice service provider may be owned and operated by the same
   or a different provider network.

[Luis>>] It is not clear to me the sense of the last sentence. Is the purpose of the sentence the following? -> In this case, the underlying IETF network slice service provider may be owned and operated by A SINGLE OR MULTIPLE providers' networks.


   Section 4.2 provides a description of endpoints in the context of
   IETF network slicing.  For a given IETF network slice service, the
   IETF network slice customer and provider agree, on a per-CE basis
   which end of the attachment circuit provides the service demarcation
   point.  This determines whether the attachment circuit is included in
   the set of SLOs and SLEs for the subject CE.

[Luis>>] For the last sentence, would it not be more precise to comment in this way? -> This determines whether the attachment circuit is included as part of the IETF network slice service (then being also the object of the set of SLOs and SLEs for the subject CE).


_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas


--
___________________________________________
Luis M. Contreras
[e-mail]<mailto:[e-mail]>
[e-mail]<mailto:[e-mail]>
Global CTIO unit / Telefonica

________________________________

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