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

Robert Wilton <rwilton@cisco.com> Wed, 22 March 2017 15:21 UTC

Return-Path: <rwilton@cisco.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 9F76C129494; Wed, 22 Mar 2017 08:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4V_DVo-yr5ik; Wed, 22 Mar 2017 08:21:23 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC424126C22; Wed, 22 Mar 2017 08:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=97889; q=dns/txt; s=iport; t=1490196082; x=1491405682; h=from:subject:to:message-id:date:mime-version; bh=0mTDkIe4MNq8Xit2pqKRwH10RTRb5LkZXTfrz5mCyK4=; b=WSuOMmoy4BbtSrvzPPd8xdnBFaqfkstOrPe6upNyWudJZLaz6cj6Yh/a BwTSSQoneVGK6m+aTk5Bpvdq7unBr1OqhiL751kwdOBMrg2v1PYCaaPl9 yKm5/vMcLq7cP/Y++rDRfU/aKPMmHlQ9L9aNEZdVFA8CFH31XXNpqEXXf o=;
X-Files: wilton_8023cf_ethernet_interface_statistics_3.pptx : 64597
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C+BAC0ldJY/xbLJq1eHAEBBAEBCgEBgm6BRIRsig9zkFCQN4Mggg+CDiqJYhgBAgEBAQEBAQFrKIU/gTMCBFwJAwgBAYoADqsagiYrihMBAQEHAQEBAQEBARIKBYZOggUIgVmFLxEBAoMggl8FnFGDeoMAi02KWYZWi02IEx84Pj4IJBYIFxWDB4QSQIgIgi4BAQE
X-IronPort-AV: E=Sophos;i="5.36,205,1486425600"; d="xml'?pptx'72,48?scan'72,48,72,145,208,48,217?jpeg'72,48,72,145,208,48,217,145?rels'72,48,72,145,208,48,217,145"; a="650607418"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2017 15:21:19 +0000
Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2MFLI7c017221; Wed, 22 Mar 2017 15:21:18 GMT
From: Robert Wilton <rwilton@cisco.com>
To: netmod@ietf.org, ccamp@ietf.org
Message-ID: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com>
Date: Wed, 22 Mar 2017 15:21:18 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------17B56203044C4D1245555027"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Po1EMvtFRU3puHVMYXS9eRSMsMA>
Subject: [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: Wed, 22 Mar 2017 15:21:27 -0000

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