Re: [CCAMP] MEF services

[Mahesh Jethanandani <[e-mail]>]

Hi Young,

> On Jul 17, 2018, at 11:07 PM, Leeyoung <[e-mail]> wrote:
> 
> Hi Mahesh,
>  
> As we discussed off line, service-types defined in L1CSM model is not the same meaning of “services” you are referring to. In L1CSM we are using the term service type in the context of connectivity services; in particular, the UNI access link attributes.

In that case, do you want to call them connectivity-services?

>  
> Thanks.
> Young
>  
> From: Mahesh Jethanandani [mailto:[e-mail]] 
> Sent: Tuesday, July 17, 2018 4:33 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: MEF services
>  
> Authors,
>  
> I wanted to clarify on my comment on the mike regarding aligning with the YANG model definitions in MEF for services. First of all, for reference, please see MEF 58 <https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_58.pdf> for what I am talking about. For the latest set of models, you can see them here <https://github.com/MEF-GIT/YANG-public/tree/master/src/model/standard>.  You will notice that MEF 58 is talking about services as defined at the Legato layer in the LSO Reference Architecture of MEF. This may not correspond to what you are trying to define as a “service” at Layer 1. If that is the case, you can ignore my comment. But do realize that as you do define new service types, that the definition of a service aligns with what is defined in Section 2.1 of RFC 8199 and how MEF views service level models. In particular RFC 8199 says:
>  
>    Network Service YANG Modules describe the characteristics of a
>    service, as agreed upon with consumers of that service.  That is, a
>    service module does not expose the detailed configuration parameters
>    of all participating network elements and features but describes an
>    abstract model that allows instances of the service to be decomposed
>    into instance data according to the Network Element YANG Modules of
>    the participating network elements.
>  
>  
> A very cursory read of the model tells me that you are talking about ‘coding function’, 'optical_interface’ or ‘uni-list’. Why would a consumer of a service care about a ‘uni-list’ that a service provider maintains, or what ‘optical_interface’ is used.
>  
> In either case, a liaison statement from IETF to MEF would be nice to make sure that both parties are aware of each others work.
>  
> Thanks.
>  
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>
Mahesh Jethanandani
[e-mail]