Re: [Netslices] Comments on COMS BoF

[<[e-mail]>]

Kiran,
Thanks for the replies, follow-ups in-line
phil

From: Kiran.Makhijani [mailto:[e-mail]]
Sent: 11 April 2018 14:39
To: Eardley,PL,Philip,TUD1 R <[e-mail]>; [e-mail]
Subject: Re: [Netslices] Comments on COMS BoF

Hi Philip,
Please see inline.
-Kiran
From: Netslices <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 11, 2018 at 12:01 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Netslices] Comments on COMS BoF

Hi,
I thought the presentations and discussion at the COMS BoF was interesting. Thanks also to the proponents for reacting to previous feedback, personally I think this is getting quite close to a sensible set of work. Here are some comments.
I think it would be useful to work on a common information model to include connectivity, compute and storage resources. I’d exclude functionality (VNFs) from the information model – as VNFs seem orthogonal to resources and also an information model for even one VNF is hard.

[KM] VNFs or NFs should be part of information model because I think it will allow you to “instantiate” a NF instance integrated with the request for allocating resources. Think of CORD or edge computing, it could help with proper/proximal placement of NFs on-demand. Otherwise, would they become 2 separate requests and as a tenant you will need to find out where to spawn an NF. The complete specification of an NF is challenging, we are considering only minimal resource related information.



[phil] I’m not sure if we agree.

“The complete specification of an NF is challenging, we are considering only minimal resource related information”. I certainly agree with the first half of this sentence, and agree this is out of scope (although the BoF material suggests it’s in scope). But I don’t think COMS should try and assess how much resource is needed for particular VNFs – it strikes me that this is a job for the VNF designer & user - to understand how much connectivity & compute resources the VNF needs and then to request this resource via the COMS interface. There are some open questions about what detail is needed in the information model (such as where (geographically) connectivity is needed) – these can be discussed during the work.


I’m unclear if COMS should work on “the related YANG model”. I don’t think we should work on specific data models, but ok if Yang is the way of recording the information model. (In RFC3444 terms, we should “model managed objects at a conceptual level, independent of any specific implementations or protocols used to transport the data” and not on something “intended for implementors and include protocol-specific constructs”)
I think the CSI & SDI interfaces should be the same. I couldn’t find a clear description of them – but as I understand it, the high-level architecture has two interfaces, a Service Delivery Interface (SDI) and Customer Service Interface (CSI). The SDI is between the network provider and orchestrator, and also between hierarchical orchestrators. The CDI is between the customer (‘tenant’) and provider. For me these interfaces are the same – in the same way that the network provider wants to request resources from an orchestrator (or understand what resources are available),similarly the tenant wants to request resources (or understand what’s available) from the network provider.

[KM] Think of them being separated by as-a-consumer and as-a-provider type roles. Actually, for a homogenous hierarchy example you have in mind of service providers, it could work, but think of it in terms of a service. What if you want to create different type of services and tenant will have different operations/information for each type of service. In addition, I think aggregation of telemetry/ stats and disaggregation for resource mappings will be simpler to understand in terms of SDI and CSI roles. If we combine them, it will be one bloated interface.

Thanks

Kiran



[phil] from the point of view of resources, it should be the same information model at all levels – it’s the same types of resource. Of course different service providers may offer different types of service to their customers, and the way they describe those offers will depend on what their customers are like, but this is outside the IETF’s scope.

Re Telemetry and stats – as a user of a slice (or network), if I want to be certain what service I’m getting from the slice /network provider, then I need to make my own measurements. It may be that I choose to rely on measurements provided by the slice /network provider to me, but this raises some issues, such as how much I trust what I’m told and how many measurements do I get (the slice /network provider will make more measurements than I’m interested in, and some will be private information they won’t share). I think this is quite a tricky topic, which could be delayed to a second round of work.

--


An objective for us (BT) is to enable hierarchical service providers (ie a service provider can devolve part, or even all, of its network & compute to another provider). This should be much simpler to achieve if the interface is recursive, therefore I’d have this as a specific objective.
As well as COMS defining the interface and information model, I think a preliminary step is to agree the high-level description for these (ie something equivalent to a protocol model https://tools.ietf.org/html/rfc4101).
A comment was made, I think by Ignas, that ‘one universal interface is a nice vision, but isn’t practical’. I think that in practice existing domains will have their existing orchestrators, so an adaptor is needed to ‘match’ to the standardised SDI - but it is still valuable to have that single, standardised interface. (The high-level architecture should show these adaptors.)
I also note that the scope is no longer specific to slicing (this is good) – but how to coordinate orchestrators, so that aspects of a deployment can be devolved to other providers. Devolution is easiest if there is a common interface with a common understanding of what types of resource there are and how to describe them.
Whilst there are several standards bodies with an interest in this topic (of information model & interface), personally I think the IETF could play a useful role.
Best wishes,
Phil/