One additional comment, regarding pruning and what to prune.
– equipment with 10BASE-T isn’t necessarily old or EOL. It is the bottom end speed often found on gigabit switches. However, 100BASE-T4 or 100BASE-T2 are just plain not used. So, pruning is good, but it isn’t
necessarily by age of the spec.
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Wednesday, February 03, 2016 3:11 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx
Cc: STDS-802-3-dialog@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_NGECDC] [YANG for 802.3] Clause 30 modelling assumptions
Thank you George.
Inline as well, in red, with
[mh0203] tag.
Marek
From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, February 03, 2016 5:11 PM
To: STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGECDC] [YANG for 802.3] Clause 30 modelling assumptions
Marek – thanks for taking this up. Some thoughts in response to the questions you ask, inline below. (marked GZ>>>)
-george
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Wednesday, February 03, 2016 1:10 PM
To: STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGECDC] [YANG for 802.3] Clause 30 modelling assumptions
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.
GZ>>> Completely agree. Deprecating functions means you DON’T DO FURTHER WORK ON THEM. Add to that the bonus that it simplifies the model, and its clear this is the right thing to do. Continuing to evolve
a deprecated function is really bad precedent.
[mh0203] Thank you, that also makes sense to me, and if nobody expresses any concerns about my proposed approach, I will work under this assumption going forward, at least to get the initial model created.
-
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
GZ>>> I don’t know why the relationships are modeled that way in Clause 30, but Clause 4, which describes the MAC is written entirely from the point of view that it is a 1-to-1 mapping. For example, as far as
I can tell, it always refers to “the Physical Layer” and singular transmissions and receptions, never to “a Physical Layer”. Thinking back to the bad old days of CSMA/CD (sure to get a comment from Geoff Thompson on that one
J ) handling a 1-to-many MAC-to-PHY mapping would be problematic, and would require additional machinery in the description of Clause 4. Love to hear from some of the
early crowd if they understand where and how a multi-PHY MAC fits into Clause 4.
[mh0203] Yes, that is also where I had problems putting things together, and my only thought was about multi-rate PHYs (10/100/1000BASE-T for example), but as far as I understand, they
are not described in the standard in this fashion, so the 1:1 mapping would still apply nonetheless.
-
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?
GZ>>> I think pruning is a good idea, but I wouldn’t prune by age. We have a bunch of PHYs, some of which have been formally deprecated, some of which maybe should be. Some of the old PHYs are still around
(take 10BASE-T – it just won’t die). I understood from the presentation at the ECDC, however, there was an automated way to do the YANG translation, so maybe pruning is more work?
[mh0203] Actually, we tried to emphasize that we would not do automated conversion
J I guess this message needs to be emphasized more in the future. Automatic conversion does mapping from MIB to YANG, but it leaves plenty of ‘leftovers’ and clean up is then
needed, leading to development from scratch being much faster.
My suggestion to start off from 100BASE PHYs was that it is unlikely that vendors would be putting YANG support on very old equipment. I would expect newer products to support it in
the future, but not legacy, end-of-life equipment. We will need to draw the line at some point, but what it is – I am open to suggestions.
-
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)
GZ>>> I think managing all these entities is goodness, but how would you model a midspan from a dot-3 perspective ? (remember, our specs are written single port) Without its own datalink, that question has been
elusive.
[mh0203] That is also something that I was wondering, but it might be that we would build a ‘device’ model, extending the existing ‘system’ model. I wonder though what the value is, given that bridges / switches
are way more popular these days and for these to work, we just need a generic 802.3 interface model.
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.
GZ>>> Not sure what you’re getting at “will be developed focusing on the management view of Ethernet interfaces rather than PHY view of Ethernet interfaces”
[mh0203] For PHY view of Ethernet interface, think Clause 45 registers, with all the low-level knobs to control aspects of the PHY. For management-view, think of what an operator sees on a managed switch, when logging
into CLI: speed, duplex, statistical counters, etc., while all the low-level knobs are hidden. Does it make sense?
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
