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

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

Hi Adrian,

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

Best regards,

Luis

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

Running out of colours 😊

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



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

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



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



[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…”

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



[AF2] Changed in the working copy.



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.

[Luis>>] Ok



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.

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



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



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

[Luis>>] Ok



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

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



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



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

+------+



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?



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



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



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



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.



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



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



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

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



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



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



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



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

[Luis>>] understood.



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



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

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



[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

________________________________

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