Re: [Teas] My review comments on draft-ietf-teas-ietf-network-slices-09

[Kiran M <[e-mail]>]

Hi Adrian,

Thank you for addressing these changes. I will pick further on 3 things

1. section 4.2 (on Figure 1 notes) -> your explanation below is perfect. 
"It will be nice to have" your text added to the document.

2. section 5.2 Scalability is still not there (it seems to express 
abstraction as you said); but I should first propose a better text (tbd).

3. section 5.3 Abstract Topology -> Yes, the challenge of dealing with 
too many abstractions. By reading this document, what bothered me is 
that a provider (e.g. NSC-1) can also be a customer to another level of 
underlay (say NSC-2). So, from NSC-1 to NSC-2 could  either be a 
service  or a configuration. Therefore, "It will be nice to have" this 
text added for clarity - "the network slice service model provides the 
very highest level of abstract topology".

Cheers,
Kiran


------------------------------------------------------------------------
*From:* Adrian Farrel [mailto:[e-mail]]
*Sent:* Sunday, March 27, 2022, 11:51 AM
*To:* 'Kiran M'; [e-mail]
*Subject:* [Teas] My review comments on 
draft-ietf-teas-ietf-network-slices-09

> Thanks for the careful review, Kiran.
>
> 1.1
> @km: in the above statement, we dont show relation between TN and IETF network slice.	
> @km: perhaps add: entities in RAN and CN segments (including connectivity for TN segments)	
> Will do something like that
>
> 2.1 Attachment Circuit
> @km: for the definition perspective, it seems AC is over described.	
> @km: Perhaps pull everything below to 4.2?
> Maybe, but I'm not enthusiastic about moving text around. I think this can stay as it is without harm.
>
> 3.2
> @km: any chance if  can use CC for connectivity constructs and define it in	
> @km: terminology section?
> 2.1 has a definition of Connectivity Construct, so the question is whether we should us an abbreviation throughout the document.
> If we were writing the document from scratch then, as a lazy author, I would probably be in favour of using an abbreviation. But, in general, I think we obsess with generating new abbreviations for terms that can quite easily have words.
> I suppose that if anyone thinks that the text will become clearer by using "CC" we could go to that, but it doesn't look that way to me.
>
> 4.2 bullets 1 and 2
> @km: just a clarification question wrt honoring SLOs the difference between 1. and 2. is:	
> @km: in 1. CE will honor SLO as traffic enters CE where as in 2.	
> @km: CE only identifies slice-traffic, does not apply any SLOs. is that right?
> I struggle with the idea that a single point in the network "applies" or "honours" an SLO. The SLO applies to the traffic flow as enabled by the entire path.
> Maybe a way to phrase your question is about what role the CE plays in the entire path. As noted in the text, in case 1 the CE's output queues and buffers may form part of the slice and so must be arranged so that they do not encumber the delivery of the SLOs: this is in addition to any slicing of the AC that may be needed. In case 2, the SLO only applies to the traffic as it leaves the CE: the AC may still be sliced, but the CE is not responsible for doing anything to help achieve the SLOs.
> Another way to look at this is to consider the point at which the measurements are made in order to verify the conformance to the SLOs.
>
> 5.2 Scalability
> @km: I did not understand how the text explains scalability?
> Looks like this is 100% inherited text dating back to draft-nsdt-teas-ns-framework-00. I suspect the intended meaning is lost.
> However, I would say that the point of this text is to say that a service API protects the user from the detailed configuration aspects needed for network operation. That could be, for example, not needing to request and configure a set of tunnels to deliver the service, but simply requesting the service. This also means that the user is protected from having to know about the network topology, capabilities, and state.
> We can...
> OLD
>     *  Scalability: Customers do not need to know any information beyond
>        that which is exposed via the IETF Network Slice Service
>        Interface.
> NEW
>     *  Scalability: Customers do not need to know any information concerning
>         Network topology, capabilities, or state beyond that which is exposed
>         via the IETF Network Slice Service Interface.
> END
>
> 5.3 Abstract Topology
> @km: i think this is not ok. the service model will provide	
> @km: the abstract topology -  the SDPs and connectivity constructs.	
> @km: NSC determines the 'mapping' as below or the actual/logical topology	
> @km: from the network controllers.
> Too many layers of abstraction?
> This text also comes from draft-nsdt-teas-ns-framework-00 (which, of course, doesn't mean it can’t be changed).
> I think you are right that the service model does provide the very highest level of abstract topology (the SDPs and connectivity constructs, as you say).
> I think the NSC, however, selects underlay networks, connection technologies, and connectivity mechanisms, with attention to virtual links, tunnels, and key points of transit.
> This is abstraction in  the sense of RFC 7926.
> Section 5.2 already includes a pointer to 7926 specifically to explain "abstraction" so I don't think it is necessary to make any change here.
>
> 5.3 Mapping Functions
> @km: can we add an example here of what kind of filtering?
> I think we can clarify the text here.
> OLD
>     *  Provides "Mapping Functions" for the realization of IETF Network
>        Slices.  In other words, it will use the mapping functions that:
>
>        -  map IETF Network Slice Service Interface requests that are
>           agnostic to the technology of the underlay network to
>           technology-specific network configuration interfaces.
>
>        -  map filtering/selection information as necessary to entities in
>           the underlay network.
> NEW
>     *  Provides "Mapping Functions" for the realization of IETF Network
>        Slices.  In other words, it will use the mapping functions that:
>
>        -  map IETF Network Slice Service Interface requests that are
>           agnostic to the technology of the underlay network to
>           technology-specific network configuration interfaces.
>
>        -  map filtering/selection information as necessary to entities in
>           the underlay network so that those entities are able to identify
>           what traffic is associated with which connectivity construct and
>           IETF network slice and necessary according to the realization
>           solution, and how traffic should be treated to meet the SLOs
>           and SLEs of the connectivity construct.
> END
>
> 6.1 NRP
> @km: can we add an example of an NRP for clarity? I would think an NRP	
> @km: includes allocated bandwidth, port, network or service function. is it?
> I'm *very* reluctant to include an example NRP because I know that the proponents of different solutions want to make very different uses of the NRP concept. It's fine that they do that, but if we include an example here we will appear to be favouring one solution over another.
> You have certainly listed some things that might be in an NRP.
>
> 6.2 The NSC exposes the network slicing capabilities...
> @km: exposes to? an orchestrator? I would prefer if this statement	
> @km: was tighter such as to a registered or authorised entity/orchestrator.
> Good point. This statement is missing the "how?" and "to whom?"
> The "to whom" is easy - it is the customer that needs to know. Of course, that may be in the form of the Network Slice Orchestrator, but I think that "customer" provides the full generalization.
> The "how" is more complicated. Obviously one option is that the IETF Network Slice Service Model could include this. But, in practices, I suspect that this is at least in part an element of the early contractual relationship between the customer and provider. For example, the customer phones up the provider and says "I want to buy three IETF network slices with P2MP connectivity constructs between 317 SDPs," and the provider says "I can't do P2MP," or "317 is a large number," or "What's an IETF Network Slice?"
> Fortunately, this section is pretty abstract about the "how" so I think we get away with...
> OLD
>     *  The NSC exposes the network slicing capabilities that it offers
>        for the network it manages.
> NEW
>     *  The NSC exposes the network slicing capabilities that it offers
>        for the network it manages so that the customer can determine
>        whether to request services and what features are in scope.
> END
>
> 6.2 Steps to request a service
> @km: Do above 2 bullets imply that slice creation is a 2 step process - first to verify	
> @km: if it is feasible and then to create it? for a faster onboarding, one would	
> @km: want to deploy slices right away when possible...
> No. The bullets mean that slice creation could be a 2 step process.
> Hence the use of "may".
> But the faster onboarding approach only works so far. If you go for the 1 step process (simply ask for the service) then you may get a negative response. That forces you into a 2 step process which takes time.
> However, if you ask a few questions in advance of needing the service, you may be more likely to get a quick turn-around when you finally ask for the service.
> How a customer/orchestrator interacts with the NSC is very much an implementation decision.
>
> 6.4 Enhanced VPN
> @km: to be consistent with the use of term 'network slice service' vs 'network slice',	
> @km: I prefer to remove service from here and say - to underpin an IETF Network Slice.
> Good catch. Sloppy text.
> Should certainly s/network slicing/IETF Network Slice/
> I think the use of "service" is right in this context.
> You "underpin the service" or "realize/deliver the slice"
>
> 6.5 SFC
> @km: same as above should we use 'slice service' or slice here?
> I think "service" is right. The connectivity constructs are part of the service definition.
>
> 9. Encryption
> @km: this last paragraph seems same as "Data Integrity of an	
> @km: IETF Network Slice:  A customer wanting to..." above. Perhaps	
> @km: remove one of them.
> They will be merged.
>
> Many thanks,
> Adrian
>
>
> -----Original Message-----
> From: Teas<[e-mail]>  On Behalf Of Kiran M
> Sent: 27 March 2022 07:07
> To:[e-mail]
> Subject: [Teas] My review comments on draft-ietf-teas-ietf-network-slices-09
>
> Hi Adrian,
>
> Thank you for patiently going through several iterations of changes. The
> document is very ready. I had a very few nits or clarifications, should
> you choose to consider them for those, they are attached as html diff.
>