Dear colleagues,
As a follow-up from the discussion on YANG models for 802.3 at the last interim session in Atlanta, GA, USA (see http://www.ieee802.org/3/ad_hoc/ngrates/public/16_01/index.html, session #2 for materials), I would like to start email discussion regarding some of the aspects of the future YANG model for IEEE 802.3 interfaces, and specifically the relationship between individual elements from Clause 30, relationship between them, and exposing them in YANG model. Below is the copy of Figure 30-3, which demonstrates relationship between individual managed entities we use for DTE modelling. The list of questions / observations follows:
- The objects oAggregator, oAggregationPort, oAggPortStats and oAggPortDebugInformation are deprecated by IEEE Std 802.1AX-2008. Would it make sense to exclude all LAG-related managed objects from 802.3 YANG model and assume they will be handled by 802.1 when and if 802.1AX-2008 model is created? This would simplify the Ethernet interface model and avoid overlap with potential future 802.1AX work. In the end, 802.1AX model would combine multiple Ethernet interface instances + additional management objects to control the 802.1AX LAG, so I believe we should be fine in this respect.
- The relationship between oMACEntity and oPHYEntity is 1-to-many, as shown in the figure above. Are there any specific examples of PHYs in 802.3 today where a single MAC entity speaks to multiple PHYs at the same time? What was the original reason to model it in this fashion? I would like to simplify the YANG model by assuming 1:1 relationship for now and I was wondering whether it would be acceptable
- Managed objects aPhyType and aPhyTypeList provides a long list of PHYs. Is there any interest in having all legacy PHY types supported or we could rather prune the list starting from – say – 100BASE-T onwards and support only newer PHY types?
- The initial development effort would be focused on properties common to all Ethernet PHYs, while specific extensions to support EFM OAM, PON, etc. will be added later on, by extending base common model
- Is there any interest in modelling repeater (based on Figure 30–4) or midspan (based on Figure 30–5)? These are very simple devices, but at this time I was planning to focus on DTE only (aka Ethernet interface definition)
A general observation that I would like to start working under is that (1) the future 802.3 YANG model will need to interoperate with 802.1 YANG models to create functional bridge models, using 802.3 YANG interface definitions, and (2) the future 802.3 YANG model will be developed focusing on the management view of Ethernet interfaces rather than PHY view of Ethernet interfaces. In practice, my intention is to expose all necessary counters, statistics, etc. as well as configuration parameters typically used by operators to manage Ethernet interfaces, while allowing vendors implement translation from YANG model into internal hardware registers in the vendor-specific manner.
Please let me know if there is anything else that I might have missed. I am CCing Dialog reflector to reach people that might be interested in YANG for 802.3 and that are not currently registered on ECDC reflector.
Regards
Marek Hajduczenia, PhD, CCNA CSCO12874393
Network Architect, Principal Engineer
Bright House Networks
Office +1-813-295-5644
Cell +1-813-465-0669
