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

Robert Wilton <rwilton@cisco.com> Thu, 23 March 2017 17:45 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5EC129B09; Thu, 23 Mar 2017 10:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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, URIBL_BLOCKED=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 0qQM6ULmeTw9; Thu, 23 Mar 2017 10:45:34 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1D4129B55; Thu, 23 Mar 2017 10:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24670; q=dns/txt; s=iport; t=1490291129; x=1491500729; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=sU0IFJP3oIFPK5FvL+9kfs/BPuYUY4zcOTCtyXZGvS0=; b=RLI5bcM1gVYjjE0STalNWUv8i8TVbjfOyGSWCB3JwdUV8HTdH6efWU9/ uikv+xDSZjsywv5zPIGx0TXxnbfczRK5MLuyyvcxpnELyJiua1OxkdtYQ 0mjJI/bc7me6aYmKGauRfzdDutgEYZhiU7+KQUNgZKGFpXmO8mY90picP Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DhAQDICNRY/xbLJq1eGQEBAQEBAQEBAQEBBwEBAQEBhDKBC4Niig9zkFyVSYIOHwEKhS5KAoNVGAECAQEBAQEBAWsohRUBAQEBAgEBASFLBAcQCw4KIAcDAgInHxEGCgMGAgEBiXoIDqokgiYrihIBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZOggWBYYEJhCYRAQJGglqCXwWJMYxYhkyGe4MpiCaBe4UqgzSGVotPiBMfOD4+CCQWCBcVQYQfgjlANYdbgi4BAQE
X-IronPort-AV: E=Sophos;i="5.36,210,1486425600"; d="scan'208,217";a="651656564"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 17:45:27 +0000
Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2NHjQZ3017666; Thu, 23 Mar 2017 17:45:26 GMT
To: Dan Romascanu <dromasca@gmail.com>
References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> <CAFgnS4XRa7AkUdJ7eevN2Ja-wC9WbZwEroVKjouTbG=NNwa-0A@mail.gmail.com> <aa45fd47-76d8-da0b-3606-be76610f88ea@cisco.com> <CAFgnS4V2wv7nEGJTanJsdVk7YzjKNHKPYtfaC4nYUTHAw1whgA@mail.gmail.com>
Cc: netmod@ietf.org, ccamp@ietf.org, Russ Housley <housley@vigilsec.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <fa7c975c-c434-15db-dac9-ec54ff0801dc@cisco.com>
Date: Thu, 23 Mar 2017 17:45:24 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAFgnS4V2wv7nEGJTanJsdVk7YzjKNHKPYtfaC4nYUTHAw1whgA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------67BA97E327E9B410164DC730"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/uRZO27SoSSCiFsI7kM4ZyS-1xVk>
Subject: Re: [CCAMP] [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 17:45:37 -0000

Hi Dan,

Thanks for the advice.  Thankfully, David Law has been attending the 
802.3cf task meetings, so he very much aware of the proposal to add new 
definitions to clause 30, and has offered to help find the best way 
through the 802.3 process to achieve the right technical goals.

Thanks,
Rob


On 23/03/2017 16:40, Dan Romascanu wrote:
> Hi Robert,
>
> Thank you for the answer.
>
> If the current IEEE 802.3 project (cp) is not chartered to make 
> changes in Clause 30 - these cannot be done, and you need a new 
> project for this purpose. Take this into consideration, as this may 
> become a dependency and a gating issue for the project timelines. I 
> suggest that you discuss this with the IEEE 802.3 chair David Law. I 
> am also copying Russ who is now in charge with the IETF - IEEE 
> relationship to make sure that he is aware about the issue.
>
> Regards,
>
> Dan
>
>
> On Thu, Mar 23, 2017 at 5:36 PM, Robert Wilton <rwilton@cisco.com 
> <mailto:rwilton@cisco.com>> wrote:
>
>     Hi Dan,
>
>
>     On 23/03/2017 07:56, Dan Romascanu wrote:
>>     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.
>     Unfortunately, yes there are differences.
>
>>     What is the approach that you propose to take?
>     I'm trying to rationalize them all together (at least for the
>     parts of the MIB that we want to carry forward into YANG).
>
>     Please see attached for a spreadsheet that shows the relationship
>     between the proposed 802.3 YANG counters, the existing MIBs
>     (IFMIB, RMON, and ETHERNET-LIKE), and 802.3 clause 30.  This
>     doesn't yet cover the counters that I plan on adding to
>     draft-ietf-netmod-intf-ext-yang-04 (Drop due to invalid
>     destination MAC, of RMON style histogram counters).
>
>     There will also be some text added to the 802.3cf draft that
>     should explain the relationship, possibly some of it may be lifted
>     directly from 802.3.1.
>
>
>
>>     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?
>
>     A bit of both - mostly the former approach, but with a few missing
>     counters hopefully added to clause 30.
>
>     Specifically, I hoping that the following counters can be added to
>     clause 30:
>      Row 17: In PFC frames (used in  ETHERLIKE MIB dot3HCInPFCFrames)
>      Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames)
>      Row 19: Total Octets received (good & bad) (used in RMON MIB
>     etherStatsOctets)
>      Row 25: Frames dropped as being too short. (combined value of two
>     RMON MIB counters (etherStatsUndersizePkts + etherStatsFragments))
>
>     I think that in principal there is some support for adding these
>     to clause 30, and the appropriate folks in 802.3 will work out the
>     easiest/best mechanism to achieve this.
>
>     Thanks,
>     Rob
>
>
>>
>>     Regards,
>>
>>     Dan
>>
>>
>>     On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton <rwilton@cisco.com
>>     <mailto: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 <mailto:netmod@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/netmod
>>         <https://www.ietf.org/mailman/listinfo/netmod>
>>
>>
>
>