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

[Dan Romascanu <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>
>