Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap

Dan Romascanu <dromasca@gmail.com> Thu, 23 March 2017 07:56 UTC

Return-Path: <dromasca@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4DC1317B6; Thu, 23 Mar 2017 00:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlZo_syLZ5kr; Thu, 23 Mar 2017 00:56:44 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DCC1317C0; Thu, 23 Mar 2017 00:56:44 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id p64so173416844qke.1; Thu, 23 Mar 2017 00:56:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gJr8Bb6jjp49dGxftBkjCACZhzalQhfdpBRlSCKlL2Q=; b=DqD06Vkd+4j9uK8jzceCglXoGu7EhwjczBKW3cfVTRM24Mns+WOjKFn6+wZ91prURT sgKyLHbCndQcm8Amm9//c21mOrt/hWxrsD1wOhOc6w3THYsBoBnVo7nAV00dRrUcjjkq E2FSNKehvZSSzO0DpxSshOT9JEYpXF6oZR0dEUi0xdnJLhg+GQcpc7U5nmDpVNY1Y6XH FJK2SYVaZmukYlRo67rmslQpMfezGDRgr7q+j+3sJlnf7128vqSBNDOFROIGjwCcV3UX MMMzQ20N2zZzchOMDNcSo6Vq5o+a+QrFoBBOnD4qtNOs3TGd1dpgVi4XbaSVCO/Hai7w eEhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gJr8Bb6jjp49dGxftBkjCACZhzalQhfdpBRlSCKlL2Q=; b=AbATf6cbho77PNcus1UshGZ5539nvOUM1pcTigTQelNvo47UtYRKGEVEwxLMIL2XPx KTxOmZ90bwHoPbJiRR2ikTMaQtO1nqLzXf8Xke0xqwOVFNKBPqe94UIJssB4sqItexRl LICE7u3oAB8qL/zBebkMmYHPrZQGpNHf5mtqaDxXDzPFqzx9fJWN9seyW96AXJS/hulZ mJBaxbEr8BcPwad3g3guLL1MKurhEV633gJlPIns9XrMfjaJNFkxOBJm5vFGyrQKF0VH LT/lSCV5VqExXq7mh0kMfBgFF4vYwIH52hvEjkbjgp8zBLhY5yJBmiC2JQanBMqcXnlD gCoA==
X-Gm-Message-State: AFeK/H0UiQhlEMI8EpPSZcPBiCWX545w+g04iUfGe7ut8v9ECKOg7sbgv7/BsxEDVL19LncnzkyHE0WZdtzKAQ==
X-Received: by 10.55.140.199 with SMTP id o190mr942139qkd.46.1490255803130; Thu, 23 Mar 2017 00:56:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.41.170 with HTTP; Thu, 23 Mar 2017 00:56:42 -0700 (PDT)
In-Reply-To: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com>
References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Thu, 23 Mar 2017 09:56:42 +0200
Message-ID: <CAFgnS4XRa7AkUdJ7eevN2Ja-wC9WbZwEroVKjouTbG=NNwa-0A@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: netmod@ietf.org, ccamp@ietf.org
Content-Type: multipart/alternative; boundary="001a114f8cfcc52a78054b6137db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/lDN5iibolCsG4fOI2bE0CN-k9YQ>
Subject: Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 07:56:47 -0000

Hi,

I largely agree with the proposals of the team.

I have only one comment / clarification related to the RMON objects which
are proposed to be transferred under IEEE 802.3cp. As far as I remember
there are some differences between the definitions in the RMON MIB for some
of the objects and the Clause 30 definitions. What is the approach that you
propose to take? Include in IEEE 802.3cp only those objects that strictly
conform to Clause 30 definitions, or modify / add definitions in Clause 30
in order to accommodate all the RMON statistics? If the later approach is
to be taken - is IEEE 802.3cp chartered to make changes or add new
definitions in Clause 30 of IEEE 802.3?

Regards,

Dan


On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton <rwilton@cisco.com> wrote:

> Hi,
>
> I'm participating in the 802.3 task force (802.3cf) to produce standard
> YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3
> Ethernet Working Group.
>
> As part of my involvement with that group, I want to highlight a couple of
> issues that arose in that forum that may be of interest to various WGs in
> IETF.
>
> This email, and accompanying slides, represents my personal views, and do
> not represent any formal IEEE position.  However, both this email and the
> accompanying slides have been reviewed in an 802.3cf task force meeting,
> and there were no objections to the content, or my sending of this email to
> IETF.
>
> I also raised these issues (with an earlier set of slides) as part of the
> IETF/IEEE liaison meeting on 31st January, and the consensus was generally
> supportive of this approach, with the agreed next steps to contact the
> NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email):
>
>
> As part of that YANG modelling work, there is an aim to define a clean
> boundary of what manageability data should be specified within 802.3 and
> what belongs outside the 802.3 specifications.
>
> The definition that the task force is converging on is that everything
> related to Ethernet, covered by 802.3, that can be expressed in terms of
> the 802.3 clause 30 manageability definitions, should be modeled in 802.3.
> I.e. broadly everything that is covered by 802.3.1 today.  But any
> manageability information that cannot be related to clause 30 definitions
> should be specified outside of 802.3.  Note, where appropriate, additional
> clause 30 definitions may be added to fix any mistakes or glaring gaps.
>
>
> To this end, there are a couple of areas between IETF and 802.3 that don't
> necessarily look like they are entirely in the right place, in particular:
>
> 1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related
> content) some Ethernet specific statistics that would be better co-located
> with the Ethernet interface YANG model being defined in 802.3cp.  Hence,
> the proposal is to subsume the appropriate Ethernet statistics from the
> RMON MIB into a single combined reference set defined in 802.3cp.
>
> 2) The RMON MIB also defines some Ethernet specific statistics that can't
> be defined as part of 802.3cf because they don't relate to 802.3 clause 30
> registers, but are still widely supported by vendors, and should be modeled
> in YANG.  The proposal is that definitions related to these counters could
> be added as part of the Ethernet-like module draft-ietf-netmod-intf-ext-
> yang-03
> <https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/>, or
> perhaps a related Ethernet module in the same draft.
>
> 3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from
> RFC 7460), was originally specified in IETF, but ownership later
> transferred to 802.3 (via RFC 7448).  Whilst working on the Power over
> Ethernet YANG model it has become clear that not all of the attributes
> defined in the MIB map to the underlying 802.3 clause 30 definitions.
> Further, it looks like parts of this YANG model would be better defined as
> extensions to the Entity YANG model being defined in NETMOD.  The proposal
> is that the parts of the Power over Ethernet YANG model that can be
> directly related to clause 30 definitions (e.g. *pethPsePortTable*)
> should be defined in 802.3cf, but that the remaining parts (e.g., *pethMainPseObjects
> *) can hopefully be standardized in IETF.
>
>
> Do you have any comments, or concerns, on the 3 proposals above?
>
> Regards,
> Rob Wilton
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>