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

[Adrian Farrel <[e-mail]>]

Hi Luis,

 

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

 

Some thoughts in line.

 

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

 

[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

+------+

 

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.

 

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.

 

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?

 

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.

 

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.

 

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

 

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.

 

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

 

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

 

[AF] Ack

 

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

 

[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