Re: [Teas] What's in draft-ietf-teas-ietf-network-slices-08.txt

[Adrian Farrel <[e-mail]>]

Hi again,

 

Further thinking and discussing this (I’ll reply to Luis’ mail separately), I wonder if it would help to make a small change in 4.1.2 that describes SLEs

 

OLD

   Quite often, an SLE will imply some details of how an IETF Network

   Slice service is realized by the provider, although most aspects of

   the implementation in the underlying network layers remain a free

   choice for the provider.

NEW

   Quite often, an SLE will imply some details of how an IETF Network

   Slice service is realized by the provider, although most aspects of

   the implementation in the underlying network layers remain a free

   choice for the provider. For example, activating unicast or multicast

   capabilities to deliver an IETF Network Slice service could be explicitly

   requested by a customer or could be left as an engineering decision

   for the service provider based on capabilities of the network and

   operational choices.

END

 

Cheers,

Adrian

 

From: [e-mail] <[e-mail]> 
Sent: 22 March 2022 07:39
To: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [Teas] What's in draft-ietf-teas-ietf-network-slices-08.txt

 

Hi Luis, Adrian, all,

 

(focusing on the received SLO part)

 

In addition to the clarification provided by Adrian, please note also that the framework includes a provision for placeholders to cover specifics of services such as IPTV in your example. This text was one of the outcomes of the “Issue #3: SLOs/SLEs per receiver” thread.

 

 <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices#section-3.2.1> 3.2.1.  Ancillary SDPs
 
   It may be the case that the set of SDPs needs to be supplemented with
   additional senders or receivers.  An additional sender could be, for
   example, an IPTV or DNS server either within the provider's network
   or attached to it, while an extra receiver could be, for example, a
   node reachable via the Internet.  This is modelled as a set of
   ancillary SDPs which supplement the other SDPs in one or more
   connectivity constructs, or which have their own connectivity
   constructs.  Note that an ancillary SDP can either have a resolvable
   address, e.g., an IP address or MAC address, or the SDP may be a
   placeholder, e.g., IPTV or DNS server, which is resolved within the
   provider's network when the IETF Network Slice service is
   instantiated.

 

I fully support the explicit signal mentioned in your message…which is basically aligned what we had in -07, and which I believe will be revived in -09.

 

Cheers,

Med

 

De : Teas <[e-mail] <mailto:[e-mail]> > De la part de LUIS MIGUEL CONTRERAS MURILLO
Envoyé : lundi 21 mars 2022 23:09
À : [e-mail] <mailto:[e-mail]> 
Cc : [e-mail] <mailto:[e-mail]> 
Objet : Re: [Teas] What's in draft-ietf-teas-ietf-network-slices-08.txt

 

Hi Adrian

 

Thanks a lot for the clarifications provided. Please, find some few additional questions to your comments in line.

 

Best regards

 

Luis

 

De: Adrian Farrel <[e-mail] <mailto:[e-mail]> > 
Enviado el: domingo, 20 de marzo de 2022 19:34
Para: LUIS MIGUEL CONTRERAS MURILLO <[e-mail] <mailto:[e-mail]> >
CC: [e-mail] <mailto:[e-mail]> 
Asunto: RE: [Teas] What's in draft-ietf-teas-ietf-network-slices-08.txt

 

Hi Luis,

 

Very many thanks for continuing to review and comment on this document.

 

[snip]

 

Let me explain this with an example. Consider the following schema, where we have to connect A (as sender) with B, C, and D (as receivers), and let's assume a P2MP connectivity construct type.

 

+------+

|        | -----> B

|   A   | -----------> C

|        |------------------> D

+------+

 

Consider as first service scenario the connection of an entity of the mobile packet core (e.g. UPF) with three base stations (e.g. gNB) where each base station can have a max peak traffic of 100 Mbps in downlink (from A to X). The base stations could not necessarily demand the 100 Mb at the same time, since users are moving along the time, so let's think that we can dimension the slice to simultaneously serve 1 of the base stations at peak level (100 Mbps) and two other at average level (e.g. 50 Mbps each). This means that the provider needs to allocate 100 + 50 + 50 = 200 Mbps at the A slice endpoint, but requiring ta maximum 100 Mbps in either B, C or D along the slice lifetime, since neither B, C or D will consume more than that. Following current definition, and stating only sending SLOs as reference for deriving receiver SLOs, the provider would require to allocate 200 Mbps for all B, C and D, as well.

 

[AF] OK. Remembering that a P2MP connectivity construct means that *all* traffic sent by A will be delivered to B, C, and D. That is, the P2MP connectivity construct is not a routed service where the provider’s network decides to which receivers to send the traffic. So I don’t understand, at this point, why you are using a P2MP connectivity construct and not three P2P constructs. Indeed, if you were using P2MP there would be no problems, I think.

[Luis>>] I was considering P2PM having in mind a routed service with a kind of hub-and-spoke connection. I was considering a L3VPN connection, where the SDP identifier used on A could be common for connecting with B, C or D. Is this kind of connectivity only possible through A2A constructs then?

Anyway, assuming A2A, the convenience of having information about the receiver SLOs is there, isn’t it?

 

I *do* understand that the load on AB, AC, and AD may have a complex relationship where, in your example, max{AB, AC, AD} = 100, and sum{AB, AC, AD}=200

 

I do not think that this is solved by receiver SLOs:

*	In the P2MP case, since all traffic is sent to all receivers, the throughput that can be allowed depends on the capabilities of the four SDPs, i.e., min{A, B, C, D}. In other words, the sender may be gated by any one of the receivers. Well, knowing that, and to make the SLA meaningful, the sender’s SLO must be set accordingly.
*	In the case of three P2P connectivity constructs, each sender SLO must be set according to the capabilities of the pairs of SDPs, i.e., min{A,B}, min{A,C}, and min{A,D}.

[Luis>>] I understand your rationale for the P2MP and P2P cases (without routing on them), but would it not be needed some view of receiver SLO in the example I provided if we use A2A?.

 

However, I think you are describing a more complex service relationship, and what you need to achieve this is a dependency relationship between the three P2P connectivity constructs.

 

1.	I don’t know how common this relationship is, but I am willing to believe that your use case is real.
2.	I don’t know how to express this relationship in SLA terms. I hope the YANG modellers can achieve it.

 

But perhaps we can solve this in the *framework* with a simple statement that cross-relationships between the SLOs for different connectivity constructs within a slice service may be required to deliver some types of slice service.

[Luis>>] If the scenario I described is only solved with A2A constructs, it’s fine for me. Maybe we can check if some other situation could require such service relationship, but I think it is fine for now.

 

Consider a second service scenario, with the depicted setup, being the slice requested in this case to host an IPTV service with each of the receiver consuming at most 100 Mbps, with the video source in A using multicast for delivering the content. In this scenario, B, C and D will certainly need as SLO at the receiver side the same SLO as specified for A at the transmitter side.

 

[AF] So, I think this can use the P2MP connectivity construct. Whether multicast is used within the operator’s network is not important to how this is perceived by the customer, but it is the intent that all traffic transmitted by A is received by B, C, and D. So, as you say, the receivers can expect to receive according to the SLO at the sender. In this case, why is it necessary to specify the SLO of the receivers? Isn’t it implicit in the fact that it is a P2MP connectivity construct and deduced from the SLO of the sender?

[Luis>>] Yes, I was commenting this case just as an example of situation where receiver SLO could not be needed.

 

In other words, could you ever meaningfully give any of the receivers a different SLO from that of the sender? If you can’t do that, you don’t need to specify it at all.

[Luis>>] agree, this case is clear.

 

So looking at these two scenarios we see that following the current description in the document, we can found that for the same kind of slice relaying only on sending SLOs plus connectivity type cannot be sufficient for an optimal realization of the network slice in terms of allocated resources. In the first scenario, just leveraging on sending SLOs the provider could infer the need of assuring the double of throughput at the receiver side than that actually needed. Note that the stakeholder completely knowing the nature and the logic of the service is the customer, so the provider can only infer that from the information passed through the NBI. In consequence, for achieving optimal resource allocation, the view of the SLO at the receiver is needed. In page 10 it is stated that "it can be seen that the SLOs of the senders define the SLOs of the receivers on any connectivity construct", but I think this is not always true.

 

[AF] Perhaps there is a case in an Any-to-Any connectivity construct that more complex sender and receiver SLOs are needed. I defer here to the people who want to model VPNs (especially L3VPNs) with SLOs.

[Luis>>] Yes, I think it is needed as in the example above, so hearing how others understand/interpret the case would be great.

 

_________________________________________________________________________________________________________________________
 
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.