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

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

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 <[e-mail]> En nombre de Adrian Farrel
Enviado el: domingo, 6 de marzo de 2022 23:02
Para: [e-mail]
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:
- 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 <[e-mail]> On Behalf Of [e-mail]
Sent: 06 March 2022 21:57
To: [e-mail]
Cc: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/teas

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

________________________________

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