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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 6 Mar 2022 22:02:17 -0000

There is nothing quite like reviewing your own work to make you feel old and
tired.

This revision includes:
- comments from John Mulloley
- updates are careful reviews by me and John Drake

The only think left in my buffer is "It might be nice to include some worked
examples." I have a sketch of one from Med, and a few thoughts of what I
could include, but do we really need them? I'd welcome your thoughts, but
you might get asked to provide text!

Otherwise, I think the time between now and IETF-113 should be open season
for review comments. We can discuss anything big at the IETF meeting and
then (possibly) be ready for WG last call shortly after.

Best,
Adrian

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: 06 March 2022 21:57
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Traffic Engineering Architecture and
Signaling WG of the IETF.

        Title           : Framework for IETF Network Slices
        Authors         : Adrian Farrel
                          John Drake
                          Reza Rokui
                          Shunsuke Homma
                          Kiran Makhijani
                          Luis M. Contreras
                          Jeff Tantsura
	Filename        : draft-ietf-teas-ietf-network-slices-08.txt
	Pages           : 42
	Date            : 2022-03-06

Abstract:
   This document describes network slicing in the context of networks
   built from IETF technologies.  It defines the term "IETF Network
   Slice" and establishes the general principles of network slicing in
   the IETF context.

   The document discusses the general framework for requesting and
   operating IETF Network Slices, the characteristics of an IETF Network
   Slice, the necessary system components and interfaces, and how
   abstract requests can be mapped to more specific technologies.  The
   document also discusses related considerations with monitoring and
   security.

   This document also provides definitions of related terms to enable
   consistent usage in other IETF documents that describe or use aspects
   of IETF Network Slices.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-teas-ietf-network-slices-08.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-slices-08

Internet-Drafts are also available by rsync at
rsync.ietf.org::internet-drafts

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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Sat, 19 Mar 2022 22:10:50 +0000

Hi Adrian, all,

Thanks for all the work done on the document. Please, find here below some comments after reading version -08.

.- SDP concept: this version includes the new concept of SDP instead of the previous references to Network Slice Endpoints. I do not have any problem with this new term, but I'm not sure if it can serve for the purposes of the IETF Network Slice provision. It is mentioned in the draft that each SDP must have a unique identifier (such as IP or MAC address) and that the SDP identifier plus some SDP provider-network-scope identifiers (e.g., IP addresses, encapsulation identifiers, node ID, etc) will define an SDP in the context of a certain IETF Network Slice. This definition assumes that both the customer and the provider will have the same knowledge about the SDP unique identifier, and in some cases, common knowledge of the provider-network-scope identifiers (for instance node id). I'm not sure if this can be the case in some situations. For instance, looking at Fig. 1, in case 2, with the CE being operated by the customer, the provider could not have any knowledge about the IP or the node id of the CE as seen, known and operated by the customer (i.e., that is the only information the customer could have about the SDP on its side). So, how the provider could determine the corresponding SDP on the provider side? In other words, this way of passing references to the provider could not be sufficient for the provider in order to realize the Network Slice.

.- On SDP definition again: sometimes the usage of SDP is confusing for me. For instance, in Section 3.2, when defining the IETF Network Slice Service, it is mentioned that "The IETF Network Slice is specified in terms of a set of SDPs, a set or more of connectivity constructs between subsets of these SDPs, and a set of SLOs and SLEs for each SDP sending to each connectivity construct." However, as commented on the bullet before, the endpoint of the slice is determined by the SDP plus some SDP provider-network-scope identifiers. So it is not only the SDP what we need for the slice service, but also that other identifiers that particularize the SDP. For instance, thinking on vlan tag as the provider-network-scope identifier, the combination of SDP+vlan is actually a logical interface which is the artifact that will serve as endpoint of the slice. So maybe the usage of SDP along the text could require some clarifications, for instance here it could be convenient to mention something like "... set of SDPs (including provider-network-scope identifiers) ...".

.- SLOs at receiver side: apologies for insisting on this, but I think it is necessary to include for a proper realization of the IETF Network Slices. Section 3.2 and other parts of the draft only consider sending SLOs (and SLEs), but this can lead to non-optimal realizations of IETF Network Slices. 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.

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.

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.

.- Unicast/multicast: I also insist that having information of this could be certainly good (with this wording or another). Section 3.2 describes extensively how multicast can be mapped to the different connectivity constructs defined. But there are yet cases that could benefit from an explicit indication of the need or not of replicating traffic. For instance, there could be an slice that originally could require multicast distribution in a P2P construct, with the implications in terms of protocols, etc. Without a clear clue on that, the provider could realize such slice ignoring any multicast capability, and yet work. However if along the lifetime of the service a new receiver is added to the slice (through the capability of modifying existing slices), in case the provider did not originally realized the slice considering multicast, it will be forced to release the original slice and create a new one for accommodating the additional receiver. This again is clearly not optimal and can even affect service terms (the agreed SLA) because of service disruption. Again, the more information the provider could have about the nature of the service, the better.

.- In Section 5.3, page 23, when talking about mapping functions, it is stated in a sub-bullet: "map filtering/selection information as necessary to entities in the underlay network". Not clear for me this statement, what would be such needs? Would it be possible to detail a bit what needs we are considering?

.- The representation of the Network Controllers is not at the same level in Figs. 3 and 5. In Fig. 3 the Network Controller sits at the operator/provider view while in Fig. 5 it seems the Network Controllers sit at the underlay physical network. It could be convenient to be consistent and sit the Network Controller at the same level in both figures.

.- Typo in section 4.2. "... characteristics of IETF Network Slice (SDPs are ..." -> "... characteristics of IETF Network Slice SDPs are ..."

.- Typo after Fig. 4. "... (EP1 ro EPn) ..." -> "... (EP1 to EPn) ..."

Thanks

Best regards

Luis

-----Mensaje original-----
De: Teas <[email-masked]> En nombre de Adrian Farrel
Enviado el: domingo, 6 de marzo de 2022 23:02
Para: [email-masked]
Asunto: [Teas] What's in draft-ietf-teas-ietf-network-slices-08.txt

There is nothing quite like reviewing your own work to make you feel old and tired.

This revision includes:

The only think left in my buffer is "It might be nice to include some worked examples." I have a sketch of one from Med, and a few thoughts of what I could include, but do we really need them? I'd welcome your thoughts, but you might get asked to provide text!

Otherwise, I think the time between now and IETF-113 should be open season for review comments. We can discuss anything big at the IETF meeting and then (possibly) be ready for WG last call shortly after.

Best,
Adrian

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: 06 March 2022 21:57
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF.

Abstract:

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

________________________________

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 confidential and privileged 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 20 Mar 2022 18:34:07 -0000

Hi Luis,

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

Some thoughts in line.

[AF] I'm glad that the change in name has brought this out. Clearly the previous terms (CE, end point, etc.) had some associated meanings that were clouding the issue because, apart from the change in name, nothing else changed.

[AF] I think that the confusion arises here in the use of the term "network slice" compared to "network slice service." It should be the case that the customer only knows about identifiers in its scope and specifically in the relationship between it and the operator. The operator, on the other hand, needs to know identifiers applicable within the operator network and specifically in the relationship between it and the customer.

[AF] In section 2.1 we have...

      Each SDP must have a unique identifier (e.g., an IP address or MAC

      address) within a given IETF Network Slice service and may use the

      same identifier in multiple IETF Network Slice services.

...I think you agree with that.

It is probably section 4.2 that introduces the complexity. There we have...

   *  An SDP is identified by a unique identifier in the context of an

      IETF Network Slice customer.

...That's as above, so probably OK. And...

   *  Each SDP is associated with a set of provider-scope identifiers

      such as IP addresses, encapsulation-specific identifiers (e.g.,

      VLAN tag, MPLS Label), interface/port numbers, node ID, etc.

…This may be causing a disconnect because of the passive voice. Perhaps it should say that “The provider associates each SDP with a set of provider-scope identifiers…”

And…

   *  SDPs are mapped to endpoints of services/tunnels/paths within the

      IETF Network Slice during its initialization and realization.

      -  A combination of the SDP identifier and SDP provider-network-

         scope identifiers define an SDP in the context of the Network

         Slice Controller (NSC) (see Section 5.3).

      -  The NSC will use the SDP provider-network-scope identifiers as

         part of the process of realizing the IETF Network Slice.

…Here the context is the NSC not the network slice or the network slice service. That is, the NSC must map the SDP to the underlay paths, and will do this using the identifiers in the customer context and the provider context. This shouldn’t be an issue.

But you go on to ask about Figure 1 case 2. I agree that in this case the IP address used in the CE may not be visible to the operator. But “IP address” was given as an example customer scope identifier. In this case (presumably), an identifier such as a VLAN tag or a MAC address or a port number or some other AC indicator is used.

.- On SDP definition again: sometimes the usage of SDP is confusing for me. For instance, in Section 3.2, when defining the IETF Network Slice Service, it is mentioned that "The IETF Network Slice [service] is specified in terms of a set of SDPs, a set [of one or more] or more of connectivity constructs between subsets of these SDPs, and a set of SLOs and SLEs for each SDP sending to each connectivity construct." However, as commented on the bullet before, the endpoint of the slice is determined by the SDP plus some SDP provider-network-scope identifiers. So it is not only the SDP what we need for the slice service, but also that other identifiers that particularize the SDP. For instance, thinking on vlan tag as the provider-network-scope identifier, the combination of SDP+vlan is actually a logical interface which is the artifact that will serve as endpoint of the slice. So maybe the usage of SDP along the text could require some clarifications, for instance here it could be convenient to mention something like "... set of SDPs (including provider-network-scope identifiers) ...".

[AF] Again, I think the difference between the “slice service” and the “slice” is important. In your quote, above, you missed out the word “service” yet it is crucial. The thing is that the customer is not aware of the actual slicing of the network. I would go as far as to say that the customer does not even care (they may think they care, but they don’t!) about how or if the network is actually sliced. What they care about is the service they contract for.

In this case, the end point of the service has no knowledge of the provider identifiers or anything like that. But the realisation of the slice in the operator’s network needs the customer identifiers and the provider-scope identifiers.

.- SLOs at receiver side: apologies for insisting on this, but I think it is necessary to include for a proper realization of the IETF Network Slices. 

[AF] I’m glad that you are continuing to voice your concern on this point. As editor I don’t try to call consensus, but I do look for a patten of support: it’s easy if all voices are on one side; but where there is disagreement, I look for a compromise position if we are going to change the text.

Section 3.2 and other parts of the draft only consider sending SLOs (and SLEs), but this can lead to non-optimal realizations of IETF Network Slices.

[AF] I think the counter argument is that knowing the sending SLOs and the connectivity construct is enough to deduce what the customer expects to be delivered. Recalling that the SLO is not the capabilities of the sending or receiving SDP/AC, but what the customer expects the traffic flow to look like. When requesting (for example) a P2P connectivity construct, it the customer asks for 10GB throughput but the sending AC only supports 5GB and the receiving only supports 2GB, the operator should say “Sorry, I can’t provide that service.”

Let’s work through your examples to see whether we can get some agreements.

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

+------+

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

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

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.

[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?

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.

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

[AF] I’m afraid I don’t understand this example. I don’t understand why sending multicast traffic on a P2P construct is interesting: it just gets delivered to the other end.

But also, if there is a P2P connectivity construct, you cannot add a receiver because it would no longer be P2P: you can change the construct to P2MP, if you want, but that makes it a different construct.

What you might do in this case is have a P2MP connectivity construct with only one receiver, then you can add receivers if you want.

Note well that how an operator realises a P2MP connectivity construct is up to them. They may use ingress replication, hub-and-spoke, p2mp tunnels, or multicast. The customer is probably sending multicast (or broadcast) traffic onto a P2MP connectivity construct (but not necessarily: for example, in the case of egress protection where the identical unicast traffic needs to reach two receivers).

[AF] Hmmm. I inherited this text from draft-ietf-teas-ietf-network-slice-framework-00, and it seems to have been present ever since draft-nsdt-teas-ns-framework-00.

*I* interpreted this to mean that the provider edge of the slice needs to know what traffic coming in on (say) an AC needs to be mapped or filtered into a particular path/resource in the provider’s network. For example, an SDP may have a role in multiple connection constructs that are realised using MPLS-TE tunnels: the PE must determine what traffic belongs in which tunnel using information contained in the packets (e.g., the VLAN IDs, or the destination port field, etc.). The NSC is responsible for knowing about this and “programming the classifier” accordingly.

[AF] Yeah. I see what you mean, but not how to fix it. Are you suggesting that the Network Controller does or does not belong as “part of the underlay”?

[AF] Ack

[AF] Ack. But actually, Section 5.4 is being pruned from -09 (see slides on Wednesday) because everything it says is already present in other places in the document.

Best,

Adrian

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 21 Mar 2022 22:08:31 +0000

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 <[email-masked]>
Enviado el: domingo, 20 de marzo de 2022 19:34
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
CC: [email-masked]
Asunto: RE: [Teas] What's in draft-ietf-teas-ietf-network-slices-08.txt

Hi Luis,

Some thoughts in line.

[Luis>>] Does it mean that the SDP identifier should be known or agreed (or passed) between customer and provider beforehand?

[Luis>>] I think that written in this way is more clear, thank you

And…

…Here the context is the NSC not the network slice or the network slice service. That is, the NSC must map the SDP to the underlay paths, and will do this using

the identifiers in the customer context and the provider context. This shouldn’t be an issue.

[Luis>>] Ok

[Luis>>] So whatever the identifier is, both customer and provider should have a common knowledge of it before the slice request arrives to the NSC, right?

[Luis>>] Ok

[Luis>>] No problem with this, my only problem is about allowing the provider to properly analyse the needs from the customer (and the limitation on provider side to honour the customer request).

+------+

|        | -----> B

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

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

+------+

[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?

[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?.

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

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

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

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

[Luis>>] I agree with you, but I think that the only way for the customer to infer that a given Network Slice Service could support future additional receivers (and be prepared for that) is only achieved if the customer can signal that fact. Indicating some kind of multicast delivery for the slice could assist the provider to implement the service by means of a P2MP construct. Without any clue, the provider does not have enough information to be prepared in advance for that situation. Maybe someone can argue: well, the customer can ask for a P2MP construct but indicating only one sender and one receiver as initial parties to connect. Would that work? I mean, would it be consistent with the model? Maybe yes, but it would be good to have the view of others here.

[Luis>>] understood.

[Luis>>] Yes, we need to look for consistency in both representations, I think.  Probably the network controller should be represented as part of the underlay in both.

[AF] Ack

[Luis>>] Ok!

Best,

Adrian

---

From: <[email-masked]>
Date: Tue, 22 Mar 2022 07:38:42 +0000

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.

3.2.1<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices#section-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 <[email-masked]> De la part de LUIS MIGUEL CONTRERAS MURILLO
Envoyé : lundi 21 mars 2022 23:09
À : [email-masked]
Cc : [email-masked]
Objet : Re: [Teas] What's in draft-ietf-teas-ietf-network-slices-08.txt

Hi Adrian

Best regards

Luis

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

Hi Luis,

[snip]

+------+

|        | -----> B

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

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

+------+

_________________________________________________________________________________________________________________________

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Mar 2022 09:10:26 -0000

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: [email-masked] <[email-masked]> 
Sent: 22 March 2022 07:39
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Teas] What's in draft-ietf-teas-ietf-network-slices-08.txt

Hi Luis, Adrian, all,

 <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices#section-3.2.1> 3.2.1.  Ancillary SDPs

Cheers,

Med

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

Hi Adrian

Best regards

Luis

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

Hi Luis,

[snip]

+------+

|        | -----> B

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

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

+------+

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Mar 2022 09:57:46 -0000

Running out of colours 😊

[AF2] Yes. That is, some form of coordination of the identifier is needed. This may be paper configuration, YANG, or a negotiation protocol. Compare with the VLAN tag used on the AC for L2VPN, or the port for L3VPN.

[AF2] Changed in the working copy.

And…

[Luis>>] Ok

[AF2] As above, yes. Or it could be carried in the slice request.

[Luis>>] Ok

[AF2] OK. I think this may be covered by 6.2 that has

   *  The customer may issue a request to determine whether a specific

      IETF Network Slice could be supported by the network.  The NSC may

      respond indicating a simple yes or no, and may supplement a

      negative response with information about what it could support

      were the customer to change some requirements.

   *  The customer requests an IETF Network Slice.  The NSC may respond

      that the slice has or has not been created, and may supplement a

      negative response with information about what it could support

      were the customer to change some requirements.

+------+

|        | -----> B

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

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

+------+

[AF2] Yes. If you want the provider network to offer a routed service, then you are going to use A2A. P2P and P2MP should be thought of as “pipes”.

[AF2] I agree that the conversation about receiver SLOs should be held in the context of the A2A connectivity construct.

[AF2] OK. This seems to be the open question. I’m going to give it its own thread in the hope that we will attract discussion from readers who might not be digging deep enough through this thread.

[AF2] Yeah. Happy to have some more voices on this. My opinion is exactly that: the customer initially asks for a P2MP construct but supplies only one receiver. This tells the provider that further receivers might be added and that the provider might want to use multicast to deliver the service.

[Luis>>] understood.

[AF2] OK. This gives us the following. Does that work?

      --------------

     | Network      |

     | Slice        |

     | Orchestrator |

      --------------

       | IETF Network Slice

       | Service Request

       |                       Customer view

   ....|................................

      -v-------------------    Operator view

     |Controller           |

     |  ------------       |

     | | IETF       |      |

     | | Network    |      |--> Virtual Network 

     | | Slice      |      |

     | | Controller |      |

     | | (NSC)      |      |

     |  ------------       |

   ..|     | Network       |............

     |     | Configuration |   Underlay Network

     |     v               |

     |  ------------       |

     | | Network    |      |

     | | Controller |      |

     | | (NC)       |      |

     |  ------------       |

      ---------------------

       | Device Configuration

       v                       

Best,

Adrian

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 22 Mar 2022 10:10:28 +0000

Hi Adrian,

Thanks so much for all the clarifications. The position of the controller is fine for me.

Best regards,

Luis

De: Adrian Farrel <[email-masked]>
Enviado el: martes, 22 de marzo de 2022 10:58
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
CC: [email-masked]
Asunto: RE: [Teas] What's in draft-ietf-teas-ietf-network-slices-08.txt

Running out of colours 😊

And…

[Luis>>] Ok

[Luis>>] Ok

+------+

|        | -----> B

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

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

+------+

[Luis>>] understood.

      --------------

     | Network      |

     | Slice        |

     | Orchestrator |

      --------------

       | IETF Network Slice

       | Service Request

       |                       Customer view

     |Controller           |

     |  ------------       |

     | | IETF       |      |

     | | Slice      |      |

     | | Controller |      |

     | | (NSC)      |      |

     |  ------------       |

     |     v               |

     |  ------------       |

     | | Network    |      |

     | | Controller |      |

     | | (NC)       |      |

     |  ------------       |

      ---------------------

       | Device Configuration

       v

Best,

Adrian

---

From: <[email-masked]>
Date: Tue, 22 Mar 2022 12:30:03 +0000

Re-,

That’s great. Thank you Adrian.

Cheers,
Med

De : Adrian Farrel <[email-masked]>
Envoyé : mardi 22 mars 2022 10:10
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; 'LUIS MIGUEL CONTRERAS MURILLO' <[email-masked]>
Cc : [email-masked]
Objet : RE: [Teas] What's in draft-ietf-teas-ietf-network-slices-08.txt

Hi again,

OLD

Cheers,
Adrian

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

Hi Luis, Adrian, all,

   instantiated.

Cheers,
Med

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

Hi Adrian

Best regards

Luis

Hi Luis,

[snip]

+------+

|        | -----> B

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

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

+------+