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

[Robert Wilton <[e-mail]>]

Hi Fatai,

Thanks for the comments/review.

Sorry, one correction in my email.  The 802.3 YANG project is only 
802.3cf.  Sometimes I have managed to mangle the name together with the 
802.1 YANG project (802.1cp) ...


On 23/03/2017 03:51, Fatai Zhang wrote:
>
> Hi Rob,
>
> Thanks for sharing the information.
>
> I think you are talking about two types of Yang models, one is 
> Ethernet specific statistics, and the other one is Power over Ethernet.
>
We are trying to convert various MIBs that contain Ethernet related 
functionality to YANG.  Generally the MIBS were defined in IETF. Some of 
them have been transferred to IEEE for ownership.

In the process of converting the content from MIBs to YANG we are taking 
the opportunity to refine the contents to better meet current 
requirements.  E.g. CSMA/CD collision counters are generally not of 
relevance on any current Ethernet hardware.

> If my understanding is correct, I think your proposals are that some 
> part of each of them should be defined in 802.3cp or 802.3cf, and the 
> left part of each of them should be defined in IETF.
>
Basically, yes, that is correct.


> I am a little concerned that how people can distinguish and judge 
> which part (e.g., of Ethernet specific statistics or Power over 
> Ethernet) should be defined in IEEE or IEFT?
>
A lot of the 802.3 Ethernet specification concerns functionality that is 
baked into the hardware.  The 820.3 specification defines (via Clause 
30) an internal management API for configuration and retrieval of 
operational parameters from the hardware.

So, the 802.3cf plan is that all of the Ethernet related parts of YANG, 
or MIB, modules that just represent the values defined in clause 30 are 
expected to published as part of the 802.3 Ethernet YANG modules.

However, 802.3cf do not want their standard YANG models to map to 
parameters that are not covered by clause 30 (excepting a few more 
obvious omissions) because that might mean that the YANG module cannot 
be fully supported by current devices (e.g. if they don't have the 
actual hardware present to provide the necessary counters).

So, the proposal is that some parts of the Ethernet statistics get 
standardized in IETF instead (probably via NETMOD).

Concretely, my desire is for the following bits would be standardized in 
IETF:
   1) Histogram packet statistics (from RMON) (because vendors often 
support Ethernet frames up to 9k bytes, but the formal 802.3 
specification only goes up to 2k).  To be added to 
draft-ietf-netmod-intf-ext-yang-04
   2) Some counters that more generally apply to Ethernet-like 
interfaces (e.g. LAG, IRB, or Pseudo-wire head-end interfaces). This 
would include the number of packets dropped because they don't match the 
destination MAC address filter.  To be added to 
draft-ietf-netmod-intf-ext-yang-04.
   3) The parts of power management that relate to power supplies rather 
than Ethernet interfaces.  Yan has submitted a draft to NETMOD for this, 
draft-zhuang-netmod-yang-poe-management-01.  I've not reviewed this 
draft yet, but it may be that it should augment the entity YANG model 
(draft-ietf-netmod-entity-03).



> For example, regarding Ethernet specific statistics, how people can 
> exactly know which information could be better co-located in 802.3cp 
> and which don’t  relate to 802.3?
>
> I think different people might have different understanding and then 
> it will bring confusion to the industry.
>
Possibly this will be true, but once these base models are standardized, 
I'm not sure that they are likely to evolve particularly quickly.  I 
would think that if the work is being done in 802.3 then any associated 
YANG would be standardized there, similarly for IETF.

> How about allow IETF define Yang models for everything of Ethernet 
> specific statistics since RMON MIB was already defined by IETF and 
> IEEE define Yang models for everything of Power over Ethernet (since 
> ownership already transferred to 802.3)?  I personally think this 
> simple approach could make our life easier, J
>
I think that this approach may hit some of the issues above 
(particularly the relationship to hardware and clause 30 registers).

Thanks,
Rob


> Just some loud thinking…
>
> Thanks
>
> Fatai
>
> *发件人:*CCAMP [mailto:[e-mail]] *代表 *Robert Wilton
> *发送时间:*2017年3月22日23:21
> *收件人:*[e-mail]; [e-mail]
> *主题:*[CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF overlap
>
> 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
>