Re: [CCAMP] MEF services

Mahesh Jethanandani <> Wed, 18 July 2018 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10ECD130E28; Wed, 18 Jul 2018 07:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I2kBO7Oh2yZ5; Wed, 18 Jul 2018 07:36:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A22D9130DC7; Wed, 18 Jul 2018 07:36:15 -0700 (PDT)
Received: by with SMTP id p4-v6so4454464itf.2; Wed, 18 Jul 2018 07:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nrGevsRrUGKJDg7v+K8ZGayKWhhg4VZS2NfqnnXbZRQ=; b=qgHs9xM2BTLQJxF4SlJJlHxw6b/A5KJxTFwppYgF2Nrf1nu6K2oLACJ78bod9X/bzn BZ9R4RnkPVFhdVgiViAnzCM1M04ITyZRgw+4Io2DlstAL05B0axehYly1QLLo4fd+5oO 1i5Z17sQXbyzha9NBAZYWBZYd9B5AopzjIMxEKxqUKAaA21Dd01M6gopSOFKPAuXnTw5 0xiRSWNfuySisa/JmJ8nvUjS44fUy/hKzye9VRIyeirHTVZYcs29YIDqX1rrvTdCePyX MEsTxH4sXSaGovxhEuGxHFc+Xkf591A11s1Roio7tGYOqMTjAX62LdlwZ26a32DK6J8y I3Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nrGevsRrUGKJDg7v+K8ZGayKWhhg4VZS2NfqnnXbZRQ=; b=QDauCyd/3A9g/7txFKgFnT7N5wsG8sppi3j9D38aJf4TduloC8S7BlYFNNtaKhG+J+ N0jOyt9pOlT9nq1oBSufy8z6+kpFsLmBGLr+5QlNI9VprWrF4eMAOQdtx+lq8CHKimk5 s0WZ4+FeMA6/VkjymCHIBz8v1blMFJETwHs4D1lH0gCnhunGcBw8PieKiu3fpskpG7bN l6qSvSACEc3IjnlJ3922acPLcB50ccQpXq+qytQkvtynAw4cgQ2wm4k8Kn5FGS6PoFxo CGoKVmlpXIx7R1szNn1KLQuczvSDqiruDNh95oxdPWPFKalRj8HsMvV0CCAiPKB4wOxQ eKDg==
X-Gm-Message-State: AOUpUlExMCn+j6zm4gklZV12JVDNljOG/o3fm0ZkZa+jcnofmswSe3xD ERCQB7g8bC4xUZ82TFpkoNY=
X-Google-Smtp-Source: AAOMgpfFEfHoG8w3lBe3xLEPudNAt9XhnXtKgcttnN89uZQZ7qsDuydh8WI2DE379hYBrhdEeg1mcw==
X-Received: by 2002:a02:5684:: with SMTP id u4-v6mr5670085jad.36.1531924574946; Wed, 18 Jul 2018 07:36:14 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:4482:63ff:735d:5394? ([2001:67c:1232:144:4482:63ff:735d:5394]) by with ESMTPSA id 3-v6sm1825920itz.2.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 07:36:13 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A498692A-6C94-47AB-B933-2C1202BBE467"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Wed, 18 Jul 2018 10:36:19 -0400
In-Reply-To: <>
Cc: "" <>, "" <>
To: Leeyoung <>
References: <> <>
X-Mailer: Apple Mail (2.3445.8.2)
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 14:36:24 -0000

Hi Young,

> On Jul 17, 2018, at 11:07 PM, Leeyoung <> 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 [] 
> Sent: Tuesday, July 17, 2018 4:33 PM
> To:
> Cc:
> 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 <> for what I am talking about. For the latest set of models, you can see them here <>.  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
> <>
Mahesh Jethanandani