Re: [CCAMP] [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap
Dan Romascanu <dromasca@gmail.com> Thu, 23 March 2017 16:41 UTC
Return-Path: <dromasca@gmail.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 756A1129ACC; Thu, 23 Mar 2017 09:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: 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 9fqAIQvR2ZK2; Thu, 23 Mar 2017 09:41:03 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 9158C129A58; Thu, 23 Mar 2017 09:40:40 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id n21so180421682qta.1; Thu, 23 Mar 2017 09:40:40 -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=Twp1LPRX+0L978OV8gesPMcVA95lbu943UKYt/O6Zas=; b=miGm32MiMu8fWBoGuqvWwytsj/NH+M+g0ItXBL0Wz77+dZ1dQkIQ8XGNEydNFMUBYd QOAt/RUyaqm9yShhWK3Gz6J2kC4vj9Wmp5nJw51AhxUBjUrJmeZQOCaosemUzdicAqgP 324+CuX7I46hNadaonNqIH45EE9zkX8JAHl/rBOkvx2R8b30BbsEUmNUCXN9ZvcxhZn0 +f5Hb+pFiA+sLkzbbiHQGO6cYZyuhpaF/PsKbzW8kOLfU9g2UElM63SKCMg23YnoP538 G+gJ8OTImERHIILvjGGNyopwf37QBLDAAmNd6uZ37JtUwx1DGynv4Wcmk1KNn+oZ2V0B Wl8A==
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=Twp1LPRX+0L978OV8gesPMcVA95lbu943UKYt/O6Zas=; b=tMocEk3mvYNZB0Qb54aJTOL/yCJ85SXyu0LKUM2hJBJUaehzK/BfF3TkeLHqmAEkYZ FwT0QEmxtVTMsUix5tkh6ekHzLRGi2dzQPiYF9MT7V/8KWBjIQ+DR/wZR8EGSsBMelHU NYRnczPAwLMue8Yrcw+FatG3wYPkfPrt+HEy8gu2LMzn4wVEwkzUOngkngf1v38h+8TD fD/KZ6zFraX3m/Q+Oe5vDisnZ87nHTR7VZwkB3hiwVlWrxn+gZDduuPYFp34+acfLxoJ 3HTS+1y9rMD7UAi3tnnDh63z35qNys0gHAjcW86RxHgu8yhVDj3H5H4wgqnIa8waFoDp 1XIg==
X-Gm-Message-State: AFeK/H0QLvWJ7BfTfgpM3p1CDvCiXR6Ry3jps1IBU/0kYpWM5Abmn7/aZhDcYUTFkF0DQK8GeMNq74Uzmyd4cA==
X-Received: by 10.200.51.199 with SMTP id d7mr3197651qtb.94.1490287239579; Thu, 23 Mar 2017 09:40:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.41.170 with HTTP; Thu, 23 Mar 2017 09:40:39 -0700 (PDT)
In-Reply-To: <aa45fd47-76d8-da0b-3606-be76610f88ea@cisco.com>
References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> <CAFgnS4XRa7AkUdJ7eevN2Ja-wC9WbZwEroVKjouTbG=NNwa-0A@mail.gmail.com> <aa45fd47-76d8-da0b-3606-be76610f88ea@cisco.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Thu, 23 Mar 2017 18:40:39 +0200
Message-ID: <CAFgnS4V2wv7nEGJTanJsdVk7YzjKNHKPYtfaC4nYUTHAw1whgA@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: netmod@ietf.org, ccamp@ietf.org, Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="001a114541de87afe1054b688981"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/ePjaX2nUpXYzqA6NCIhSyqsA5uE>
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 16:41:07 -0000
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> 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> 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 >> >> > >
- [CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF ov… Robert Wilton
- Re: [CCAMP] [netmod] 802.3 Ethernet YANG (802.3cp… Mahesh Jethanandani
- [CCAMP] 答复: 802.3 Ethernet YANG (802.3cp) and IET… Fatai Zhang
- Re: [CCAMP] [netmod] 802.3 Ethernet YANG (802.3cp… Dan Romascanu
- Re: [CCAMP] 答复: 802.3 Ethernet YANG (802.3cp) and… Robert Wilton
- Re: [CCAMP] [netmod] 802.3 Ethernet YANG (802.3cp… Robert Wilton
- Re: [CCAMP] [netmod] 802.3 Ethernet YANG (802.3cp… Dan Romascanu
- Re: [CCAMP] [netmod] 802.3 Ethernet YANG (802.3cp… Robert Wilton
- Re: [CCAMP] [netmod] 802.3 Ethernet YANG (802.3cp… Zhuangyan (Yan)
- Re: [CCAMP] 802.3 Ethernet YANG (802.3cp) and IET… Zhuangyan (Yan)