Are there any concerns about what Ed suggests? If not, I will go ahead and implement this change in the next draft version fo the Yang module itself.
Marek
From: Edwin Mallette [mailto:edwin.mallette@xxxxxxxxx]
Sent: Monday, February 08, 2016 9:53 AM
To: Marek Hajduczenia; 'Geoff Thompson'; STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx
Cc: 'Zhuangyan (Yan)'; 'Pat Thaler'; Cook, Jeff L.; 'Holness, Marc'; 'George Zimmerman'
Subject: Re: [YANG for 802.3] Clause 30 modelling assumptions
Hi Marek,
Comments below:
From: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx>
Date: Friday, February 5, 2016 at 1:14 PM
To: Edwin Mallette <edwin.mallette@xxxxxxxxx>, 'Geoff Thompson' <thompson@xxxxxxxx>, <STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx>
Cc: "'Zhuangyan (Yan)'" <zhuangyan.zhuang@xxxxxxxxxx>, 'Pat Thaler' <pat.thaler@xxxxxxxxxxxx>, "Cook, Jeff L." <Jeff.Cook@xxxxxxxxxxxxxxxxx>, "'Holness, Marc'" <mholness@xxxxxxxxx>, 'George Zimmerman' <george@xxxxxxxxxxxxxxxxxxxx>
Subject: RE: [YANG for 802.3] Clause 30 modelling assumptions
OK, so then we need two objects, i.e.,
· mac-giant-threshold - I assume range 64 … 2000 is acceptable here, and fits the target range defined in the spec for aMaxFrameLength. I could narrow it down but I think added flexibility might be welcome. Is there any concern about capping it at 2k frame size?
[EJM] My 2c is that there’s little benefit in capping this value unless we like revisiting this when the the Ethernet standard supports frame sizes larger than 2000 bytes. I know there are many edits required were that to take place, so maybe not a concern but I personally wouldn’t overly constrain the objects.
A new object, e.g., mac-frame-size, which would map into MTU you referred to before. This would be capped only by uint64 object range to the 65 … 2^64-1 bytes. Alternatively, we could cap it at some number, but I am not sure what the range would be acceptable. I do know there are implementations supporting MTU well past 2k, so I think we need to support them in the management model
[EJM] I concur.
Thoughts?
Marek
From: Edwin Mallette [mailto:edwin.mallette@xxxxxxxxx]
Sent: Friday, February 05, 2016 12:29 PM
To: Marek Hajduczenia; 'Geoff Thompson'; STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx
Cc: 'Zhuangyan (Yan)'; 'Pat Thaler'; Cook, Jeff L.; 'Holness, Marc'; 'George Zimmerman'
Subject: Re: [YANG for 802.3] Clause 30 modelling assumptions
I agree that this is not the object I’m looking for. Even if it were it is too tightly coupled to the standard frame sizes and doesn’t appear to allow for management of super compliant Ethernet Interfaces (i.e. Ethernet interfaces that support a max frame length larger than 2000 bytes.)
Ed
From: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx>
Date: Thursday, February 4, 2016 at 2:39 PM
To: Edwin Mallette <edwin.mallette@xxxxxxxxx>, 'Geoff Thompson' <thompson@xxxxxxxx>, <STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx>
Cc: "'Zhuangyan (Yan)'" <zhuangyan.zhuang@xxxxxxxxxx>, 'Pat Thaler' <pat.thaler@xxxxxxxxxxxx>, "Cook, Jeff L." <Jeff.Cook@xxxxxxxxxxxxxxxxx>, "'Holness, Marc'" <mholness@xxxxxxxxx>, 'George Zimmerman' <george@xxxxxxxxxxxxxxxxxxxx>
Subject: RE: [YANG for 802.3] Clause 30 modelling assumptions
Thanks, Ed,
The only item that I can find is the following one, 30.3.1.1.37, which drives the aFramesTooLong counter. I *believe* this is not an MTU from your email below …
Regards
Marek Hajduczenia, PhD, CCNA CSCO12874393
Network Architect, Principal Engineer
Bright House Networks
Office +1-813-295-5644
Cell +1-813-465-0669
From: Edwin Mallette [mailto:edwin.mallette@xxxxxxxxx]
Sent: Thursday, February 04, 2016 10:24 AM
To: Marek Hajduczenia; 'Geoff Thompson'; STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx
Cc: 'Zhuangyan (Yan)'; 'Pat Thaler'; Cook, Jeff L.; 'Holness, Marc'; 'George Zimmerman'
Subject: Re: [YANG for 802.3] Clause 30 modelling assumptions
In general, this model makes sense. I do notice that the maximum transmission unit is absent here, unless it’s covered by the mac-giant-threshold.
My understanding is that the mac-giant-threshold, in most shipping products that I’m aware of is generally a fixed value attached to the legacy frame size of Ethernet (i.e. 1514B, 1522B) to classify a received frame as a giant. In other words if my Ethernet interface were configured with an MTU of 9KB, my interface transmit/receive counters would count the number of frames with size > ~1514B as giants. The management entity would only count and drop frame sizes > interface MTU. So the mac-giant-threshold would essentially set the frame size at which a frame is classified as a giant, if I understand it correctly.
We should add a configurable MTU to provide the capability to set per-Ethernet interface MTU sizes, as I don’t believe the mac-giant-threshold provides that function.
If I’m missing something, please let me know.
Thanks!
Ed
From: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx>
Date: Thursday, February 4, 2016 at 8:00 AM
To: 'Geoff Thompson' <thompson@xxxxxxxx>, "STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx" <STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx>
Cc: "'Zhuangyan (Yan)'" <zhuangyan.zhuang@xxxxxxxxxx>, 'Pat Thaler' <pat.thaler@xxxxxxxxxxxx>, "Cook, Jeff L." <Jeff.Cook@xxxxxxxxxxxxxxxxx>, Edwin Mallette <edwin.mallette@xxxxxxxxxxxxxxxxx>, "'Holness, Marc'" <mholness@xxxxxxxxx>, 'George Zimmerman' <george@xxxxxxxxxxxxxxxxxxxx>
Subject: [YANG for 802.3] Clause 30 modelling assumptions
Here is the view of the first version of the YANG tree – it has three major pieces, as shown below. Apologies for pasting images, but there is no good way to represent a YANG in a graphical form without going through a lot of manual work. This is work in progress, so any comments on naming, organization, etc. would be most welcome. At this time, I have implemented all objects from 30.3.1 (MAC entity), most from 30.3.2 (PHY Device, excluding ones that make very little sense and are related with very old PHYs), 30.3.4 (PAUSE), and 30.3.8 (EXTENSION). Please let me know if anybody is interested in raw YANG code for this …
· extension to ietf:interfaces/interface (configuration parameters, i.e., all management parameters that need write access)
· extension to ietf:interfaces-state/interface (global read-only state parameters, excluding statistics)
· extension to ietf:interfaces-state/interface/statistics (read-only statistics)
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Thursday, February 04, 2016 7:33 AM
To: 'Geoff Thompson'; STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx
Cc: 'Zhuangyan (Yan)'; 'Pat Thaler'; Cook, Jeff L. (Jeff.Cook@xxxxxxxxxxxxxxxxx); Mallette, Edwin J.; 'Holness, Marc'; 'George Zimmerman'
Subject: RE: [802.3_DIALOG] [802.3_NGECDC] [YANG for 802.3] Clause 30 modelling assumptions
I guess I will need to split individual topics J Inline as well, in red, with [mh0204] tag.
Also, per request, cutting out DIALOG reflector – please consider subscribing to ECDC reflector (http://www.ieee802.org/3/ad_hoc/ngrates/index.html) J
From: Geoff Thompson [mailto:thompson@xxxxxxxx]
Sent: Thursday, February 04, 2016 12:59 AM
To: STDS-802-3-DIALOG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DIALOG] [802.3_NGECDC] [YANG for 802.3] Clause 30 modelling assumptions
My comments are in-line with the tag [GeoffT]
On Feb 3, 2016, at 7:39 PMPST, Zhuangyan (Yan) <zhuangyan.zhuang@xxxxxxxxxx> wrote:
A few comments with [Yan].
Best Regards,
Yan
发件人: Pat Thaler [mailto:pat.thaler@xxxxxxxxxxxx]
发送时间: 2016年2月4日 8:32
收件人: STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx
主题: Re: [802.3_NGECDC] [YANG for 802.3] Clause 30 modelling assumptions
My comments in line with [pat] tag
On Wed, Feb 3, 2016 at 3:10 PM, Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx> wrote:
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 (seehttp://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:
<image001.jpg>
===========================================================================
- 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.
[pat] Agree
[GeoffT] I agree or maybe even more, to be discussed below.
[mh0204] Seems that we have at least consensus on this item for now
===========================================================================
- 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.
[pat] The reason it is one to many isn't because many are active at the same time. It is because something that uses auto-negotiation is modeled as having autonegotiation plus all the individual PHYs present even though at most one of the PHYs is active based on the result of negotiation (or configuration). One could alternatively model it as having the PHY capabilities (which belong to autonegotiation) but only one PHY instantiated and therefore only one PHY manageable at any given time. The only reason to do otherwise would be if one needed to configure the inactive PHYs or read information from them. I can't recall anything in the PHYs that needs that.
[Yan] Then it should be a 1-1 mapping between MAC and PHY. But we can provide several ‘cases’ for multiple data rates, to the PHY bound with a MAC.
[GeoffT] George, it doesn't have anything to do with CSMA/CD. At the time the concept was of a bussed MII with multiple PHYs present, but only one active. The fact that a PHY was inactive did not remove it from a desire to read and/or write its status and control functions. Needles to say, the bussed MII concept never got traction so I think we can discard the concept this time around. There is, of course the new problem that breaks the 1-1 relationship that comes with IET.
[mh0204] Yes, the IET does mess things up, as shown below. It does add a secondary MAC (pMAC) with its own set of counters and properties, etc., however, it is not tied to PHY in any way, so as far as I am concerned, there is till 1:1 relationship between MAC and PHY. It is a good topic to discuss down the road I’m sure, but if we could agree with 1:1 relationship for now, it would help the things going
===========================================================================
- 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.
[pat] I would prune by status of the PHY in the standard, not by age. That is by whether the PHY has the "not recommended for new installations" note. (By "deprecated" I will mean the devices that have this note.) We should keep 10BASE-T in. When we did EEE, there was significant input that people wanted the change that lowered the 10BASE-T power so it is still being implemented. Since it goes into multispeed PHYs, it can still be implemented in a new PHY. I think it is the only 10 Mb/s PHY that is still in the picture so it isn't much burden to include the one PHY. One could also prune out the other deprecated PHYs. 100BASE-T4 isn't used today (and I don't think it ever had significant deployment.) It is deprecated. That the PHYs are deprecated is a pretty easy uniform bar to use in deciding what to include.
[GeoffT] I agree with Pat that 10BASE-T stays on the list. I would even argue that we should have both 10BASE-T and 10BASE-Te since they have different characteristics and different reaches. Again, I agree with Pat that we can drop 100BASE-T4 and 100BASE-T2. There was substantial deployment of 100BASE-T4 by 3Com in the mid 90s. But it has been truly gone for years. 100BASE-T2 was never fabricated in more than prototype quantities. We should be able to dispense with 1BASE5, 10BASE2, 10BASE5, 10BROAD36, FOIRL, 10BASE-FP, and 10BASE-FB. I am not sure about 10BASE-FL.
[mh0204] OK, that should give me a decent starting point for creating enumeration for PHY types connected to MAC instance. Thank you
===========================================================================
- 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.
[pat] The repeaters have all been deprecated for a long time and aren't in current use. Therefore, we shouldn't include them. There is no point. For midspans, is anyone making a manageable midspan device? If they are currently being made, they probably should be included, but even then, I think they are relatively low priority.@GZ, the existing model, Figure 30-5, models a midspan as a device containing multiple PSEs, not a single port. A PSE could have an Ethernet port to access the management in addition to its PSEs.
[Yan] For a midspan, it doesn’t have data link function, but only powering circuit, while a PSE switch could be managed by YANG for the configuration/monitoring of the powering feature.
[GeoffT] Again, the repeater has been gone for a long time. It went away with CSMA/CD when Moore's Law shrank a bridge core to the same finished chip size as a repeater. Also, it is formally deprecated so we do not need to consider it. The midspan is a different issue. It is entirely plausible to have a managed mid-span. However, management of such a device would probably not be integratabtle with other network management as the device would be supplied by the cabling hardware industry with its own network management. It is more likely a candidate for integration with cabling management software.
[mh0204] All right, I hear decent consensus to stick with DTE for the time being and worry (potentially) about midspan down the road, if at all needed.
===========================================================================
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?
[Yan] Agree. We’re aiming for easy management of Ethernet interfaces to operators. One question here, since our work will be providing management interface (which are YANG models of Ethernet interfaces) to upper users (that are operators) based on managed objects in Clause 30, while the MDIO in Clause 45 are on assigning registers according to objects to manage lower layer PHYs. If so, the low-level knobs are already hidden behind objects defined in the spec, which we don’t have to bother more. Is that right?
[GeoffT] There are two basic views of a network, top-down which goes NOC-Router(s)-Bridge-MAC-PHY and the bottoms-up model which goes cabling management, PHY, MAC, Box. We just need to make sure that what we do is suitable as an interface on either a bridge or a router to support the top-down view.
I believe that we could simplify things significantly if we separated point-to-point systems from point-to-multipoint systems and did separate trees for each of the two systems. Shouldn't be a problem because the reality it that there isn't really any shared hardware.
[mh0204] That is kind of the plan, Geoff. P2P interfaces get done first and P2MP get derived from P2P through extension. I was looking at it already and it does not seem we need anything in P2P model apart from a simple capability toggle flag, indicating whether it is a P2P or P2MP interface, something that I think we can agree is trivial
===========================================================================
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<image002.gif>