Re: [CCAMP] MEF services

Leeyoung <> Wed, 18 July 2018 03:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3789F130E6F; Tue, 17 Jul 2018 20:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZhMe4HfNSJgm; Tue, 17 Jul 2018 20:07:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18D89130E51; Tue, 17 Jul 2018 20:07:53 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id E7C186F327DF4; Wed, 18 Jul 2018 04:07:49 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 18 Jul 2018 04:07:51 +0100
Received: from ([]) by ([]) with mapi id 14.03.0399.000; Tue, 17 Jul 2018 20:07:47 -0700
From: Leeyoung <>
To: Mahesh Jethanandani <>, "" <>
CC: "" <>
Thread-Topic: MEF services
Thread-Index: AQHUHhW/fWdxlrLMskScZCEBrPIz3KSUS8nQ
Date: Wed, 18 Jul 2018 03:07:46 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E173D03D396sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [CCAMP] MEF services
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Jul 2018 03:07:55 -0000

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.


From: Mahesh Jethanandani []
Sent: Tuesday, July 17, 2018 4:33 PM
Subject: MEF services


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<> for what I am talking about. For the latest set of models, you can see them here<>rd>.  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.


Mahesh Jethanandani<>