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 <rwil...@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 <rwil...@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 >> >> > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
