Subject: [Teas] Comments draft-ietf-teas-ietf-network-slices-06

From: "John Mullooly (jmullool)" <[email-masked]>
Date: Fri, 4 Mar 2022 21:48:26 +0000

Hi,

Adrian I know you are coming out with another draft shorty and have a long list of comments, so I just wanted to add a few. BTW, a big thank you to you and the authors for this work.

  1.  I’m not sure if this is a big deal or not, but in section 4.2 you state “Each SDP maps to a device, application, or a network function, such as (but not limited to) routers, switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, application accelerators…”. Which is all true, but in it’s the most basic use-case (which you also highlight below in figure 1, item #3), the SDP could be the “customer facing ports on the PE”. Should we include “interfaces” in your list of what an SDP can map to?

  1.  Under Core Terminology, should we define a “IETF Network Slice”? and specifically, you highlight “IETF Network Slice Service” in section 3.2, and is it the same thing? I think so, but should we say that somewhere? If we used 3GPPP terminology, we would call this an “instance”. Can a IETF Network Slice exist if it is not instantiated? I don’t’ think so. Maybe this is a minor nit but I want to verify.

  1.  In Section 6.5 “Network Slicing and Aggregation”, seems like you appropriately caveat that this work is still in progress, yet it does lean towards “data plane” mechanisms such that packets are marked in a way so that hop-by-hop network nodes can apply appropriate slice behaviors. In the spirit of being balanced, should we also include a sentence regarding there are also “controller” based approaches which can be used to determine path selection “off-net” and then program the network to drive an explicit forwarding slice behavior?

4)      While the architecture allows for fine-grained uni-directional SLO/SLEs per-connection (which is good), we should also make sure that more generalized transport services can easily fit into this architecture. For example, an any-to-any connectivity “slice” with uniform SLOs/SLEs across all SDPs. Per SDP SLE/SLO definitions could be provisioning overkill in the more general case for the more uniform scenarios. Section 3.2 “and for a given connectivity construct each sending SDP has its own set of SLOs and SLEs, and the SLOs and SLEs in each set may be different.” Could we enhance this that each SDP can have it’s own set of SLOs and SLEs but it can also inherit those from a more generalized set of slice defined SLE/SLOs.

5)      Should we also include hub-spoke in the connectivity constructs? It seems like P2MP is unidirectional only.

Thanks

John

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 4 Mar 2022 21:57:41 -0000

Thanks John

Thanks for reading. All comments very gratefully received.

I will be having another pass on the document on Sunday (to get -08 out before the cut-off). I’ll work on your comments for that.

Best,

Adrian

From: John Mullooly (jmullool) <[email-masked]> 
Sent: 04 March 2022 21:48
To: [email-masked]; Adrian Farrel <[email-masked]>
Subject: Comments draft-ietf-teas-ietf-network-slices-06

Hi,

2.	Under Core Terminology, should we define a “IETF Network Slice”? and specifically, you highlight “IETF Network Slice Service” in section 3.2, and is it the same thing? I think so, but should we say that somewhere? If we used 3GPPP terminology, we would call this an “instance”. Can a IETF Network Slice exist if it is not instantiated? I don’t’ think so. Maybe this is a minor nit but I want to verify.

3.	In Section 6.5 “Network Slicing and Aggregation”, seems like you appropriately caveat that this work is still in progress, yet it does lean towards “data plane” mechanisms such that packets are marked in a way so that hop-by-hop network nodes can apply appropriate slice behaviors. In the spirit of being balanced, should we also include a sentence regarding there are also “controller” based approaches which can be used to determine path selection “off-net” and then program the network to drive an explicit forwarding slice behavior?  

Thanks
John

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 6 Mar 2022 11:10:11 -0000

Hi again John,

Thanks for these thoughts.

Responses in line.

Best,

Adrian

==========

[AF] Yeah. Not a big deal, but worth mentioning.

[AF] I decided to not included “IETF Network Slice” and “IETF Network Slice Service” in the Core Terminology section (2.1) because the definitions just needed too many words. Hence section 3 is dedicated to those definitions.

[AF] I agree that the separation between “IETF Network Slice” and “IETF Network Slice Service” is subtle. The text tries to draw out the distinction, but perhaps it could be clearer.

[AF] I’d note that we have, for the longest time, suffered from a blurring between the service provided to the customer, and how that service is engineered in the network. This leads us to talk about VPNs in schizoid way where sometimes a VPN is what the customer gets and sometimes it is what the operator engineers. A good example is the term “MPLS VPN” as though the customer actually cares whether the VPN is provided using MPLS technology.

[AF] Can a slice exist without being “instantiated”? Probably not. I suppose, however, it might be instantiated in planning without being instantiated in the network? But I don’t think it is helpful, in our work, to talk about a slice being an instance of a slice service.

[AF] Indeed, some of the “aggregation” work is talking about control plane only solutions. I think, however, that even the control plane approaches require that the packets are marked in some way in the data plane. (Consider, for example, using an MPLS-TE control plane to build the slice. In this case, the packets are marked with an MPLS label to ensure that they use the resources assigned to the slice.) Conversely, data plane only solutions need some work to “program” the forwarding nodes to know what to do with a packet (and here, while we might smudge the definitions of control plane and management plane, there is something that can be called a control plane).

[AF] I think it is a mistake to map a functional architecture straight to your code. Allowing an SLO-set per SDP does not mean that it has to be implemented like that. Indeed, an implementation might separate the configuration of SLO-sets from the configuration of SDPs, and allow the SDP configuration to point to the SLO-set. However, what is certain is that, in building the slice that delivers the slice service, the NSC must know what SLOs apply to each SDP. Thus, I think, stating that each SDP has its own SLO-set does not preclude using a less granular approach.

[AF] Ah, this one! 😊

Early versions of the draft did discuss hub-and-spoke.

However, in discussions, we decided that hub-and-spoke is a way of realizing a slice service, but not a way of expressing it.

That is, the customer doesn’t appreciate a difference between (say) an any-to-any service that is voiced as a full mesh and one that is voiced as hub-and-spoke. 

There is obviously a big difference in how the operator builds their network, but that is their business.

Furthermore, we observed that if a customer really does want a hub-and-spoke service, that is probably because they want to control the hub. The concept of an ancillary SDP springs to mind as a reason. In this case, the customer can express the service as n P2P connectivity constructs from spokes to hub and either n P2P constructs from hub to spokes or 1 P2MP construct from hub to spokes depending on the precise service they want to build.

[AF] We have been considering including one or more simple worked examples in the document. This could form one of those.

---

From: "John Mullooly (jmullool)" <[email-masked]>
Date: Sun, 6 Mar 2022 16:15:57 +0000

Hi Adrian,

Thank you for the quick and thoughtful response. By the way, I agree with you that this network-slicing work should  not just to be used for the 5G use-cases but also for the general transport services case.  Focused on desired outcome and intent.  What I would like to see is this draft and the cooresponding nbi-yang model  draft become the norm in how transport services are requested to the transport orchestration layer (NSC).  I’ve also been providing feedback to the authors on the network-slice-nbi-yang draft so  my questions below are mainly in the modeling context of how best we support this work.

With that understanding, see in-line for my final thoughts that you can consider (I leave any changes to your judgement).

Thanks
John

From: Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Sunday, March 6, 2022 at 6:10 AM
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Comments draft-ietf-teas-ietf-network-slices-06

Hi again John,

Responses in line.

Best,
Adrian
==========

>>JJM- Thanks!

>>Jjm- cool, got it.

JJM>> That would be great if we can just make some small clarification statement on this. My concern is people (outside of this community and not familiar with the specifics) throw around the term of “slice” so off handedly and in fact some believe that the transport underlay (i.e. aggregation layer) is the “slice”, where the overlay (endpoint) layer is not even mentioned. I think you’ve done an important job in the draft in bringing this topic to clarity, and have confirmed my assumption that either of these terms can be used in the same context. So maybe we just need address this straight up and (using your expert words maybe better here than mine) that in general terms a  “IETF Network Slice” is the same as a “IETF Network Slice Service” and even (where it’s understood the context is IETF transport services) that this is a “slice”?

Jjm> Ok. It’s not a big deal for me. I know we don’t want to get into specific technology “weeds” here but for example purposes only, I was thinking of an explicit path of a SID list placed on a Segment Routed packet. In that case the SID list dictates the path of specific node/link labels to traverse to meet that slice behavior. While technically I see your point that this does have a “marking”, the nodes are just blindly forwarding as told by the controller and the nodes are really not aware of the aggregate slice requirement. If you think this explicit forwarding scenario is still covered in your description, then I’m good.

Jjm>> I agree and this is important feedback to the network-slice-nbi-yang team. Just because we can do things at the SDP level shouldn’t prevent us from also allowing for less granular approaches in implementaion. In fact the combination of the two would be powerful, where SLO-sets can be defined at a group level and on an exception basis they are overridden at the SDP level.

[AF] Ah, this one! 😊

Jjm> Again, in the context of the YANG automation work I’m also working on, I’m trying to balance simplicity with flexibility. While I know at the SDP level we can build any topology we need, for common topologies I like the idea of doing something at a “group” level (see previous point above on where to define SLO-sets). So having a few optional  “canned” topologies that can be defined at the group level would help simplify the automation and provide much needed abstraction. I think that was already part of this work. I think certain RAN transport use cases will lean towards the L3VPN hub/spoke model (with uniform policies) and it would be super easy to instantiate that if the user could simply specify that a hub-spoke connectivity type. Of course they would also need a “role” parameter to attach to the endpoint. If this topic has been well debated and the community has agreed, then I’m fine.

Thanks again
John

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 6 Mar 2022 16:39:23 -0000

Hi once more John, 

Now I have to pick another colour.

Cheers,

Adrian

From: John Mullooly (jmullool) <[email-masked]> 
Sent: 06 March 2022 16:16
To: [email-masked]; [email-masked]
Subject: Re: Comments draft-ietf-teas-ietf-network-slices-06

Hi Adrian,

Thanks

John 

From: Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Organization: Old Dog Consulting
Reply-To: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Date: Sunday, March 6, 2022 at 6:10 AM
To: Cisco Employee <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: RE: Comments draft-ietf-teas-ietf-network-slices-06

Hi again John,

Responses in line.

Best,

Adrian

==========

[AF2] People outside this community? Oh, I see you have met the marketing department :-)

[AF2] Hmmm. I am trying to make a distinction between the service and the realization of the service (see the next paragraph). I think I will try to say that near the front to of the document. 

[AF2] Ah, I think you flipped it here: the dataplane solution might not need a control plane. And I agree with you. I think the SID list is carried in the packet, so the packet is “marked”, and the SID list tells the transit nodes what behaviors (even if only forwarding) to apply.

Anyway, yes, I think avoiding the weeds in this document is what we want/need to do.

 
 
[AF2] Good. We agree. Let’s review the YANG work.

[AF] Ah, this one! 😊

[AF2] Right. This is mainly a question for the YANG model (and maybe even for the tools that use the YANG model), but I have added a few words about hub-and-spoke with or without an ancillary SDP.

Best,

Adrian