| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi all, I agree with Richard’s said, it’s better to list them at Clause 30.13, and then some devices can use these objects to set the same mode with those legacy devices (may not support
802.3cx), e.g., the delay measurement point (SFP vs FIRST_SYMBOL), and set another mode with new devices (support 802.3cx). Finally, the time error of this link between the new device and the legacy device has a better accuracy. Thanks, Best regards, Jingfei From: Richard Tse [mailto:0000117d24f8db68-dmarc-request@xxxxxxxxxxxxxxxxx]
In my understanding, the managed objects (listed below) in clause 30.13 only represent the result of the configurations contained in the TimeSync registers in clause 45. They don’t currently allow a MIB to configure
these objects (e.g., the sum of the delays is given in a management object, but the MIB cannot configure the individual component delays through these same management objects).
I believe that George’s suggestion earlier of adding new management objects for the sub-nanosecond delays is appropriate since the capability to support this is independent from that of the nanosecond resolution delays.
Also, the INTEGER value of their aTimeSyncDelayTX/RXmin/max objects have different units (2-16 nanoseconds vs nanoseconds). I also believe the other new 802.3cx functions (listed in the bullet list below) are just as important as the above delay functions and, thus, deserve equal representation as management objects. If we follow the same structure as the delay management objects, we should have an item for the capability and for the configured operation for each of the following functions:
As a result, I suggest that we provide following management objects, where the ones in
red need modification and the ones in
blue are new:
The availability of these management objects allows a management function to determine the capabilities and the operating status of an 802.3 instance. From this determination, it could set up its network to get the best
timestamping performance.
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
Marek (bringing our conversation back to the reflector) ? So, we agree that clause 30 objects are not necessary, because the “real” MIB now lives in 802.3.1 and 802.3.2. So that means that at the top level, the Task Force has a choice ? whether to take the management out or
to leave in the clause 30 ? as a way of showing the intended structure of the management objects. Clause 30 is used by most projects that I am aware of in exactly this way ? to add necessary management objects (and amend others), and serve as a template, a proxy, if you will, for the work that needs to be done in
the 802.3.1 (and 802.3.2 YANG) documents. That way we aren’t amending 2 (or 3) documents at once, and can still get a unified look at the management. It is true that sometimes you get stuff in the 802.3.1 and 802.3.2 docs that just reference the registers,
but usually our projects update Clause 30 so that we have a template to look at. Until Clause 30 is deprecated I suggest we continue the practice. Further, it would be bad form, IMHO, to amend clause 30 partially - updating existing objects with the new
information while leaving out new ones that were intended. So, my dog not really being in the fight ? I’ll ask those intending to use 802.3cx ? do you intend new management objects to indicate which reference is being used for the timestamp (SFD or FIRST SYMBOL), and whether
fine resolution delay is supported. (I’m assuming these are independent features, because they appear to be independently controlled) If no, then we should delete 30.13.1.7 and be done with it. That can then be the response to all the comments ? but please consider this and don’t go back and THEN write a mib later into the 802.3.1 and 802.3.2 ? it
will make the 802.3 amendment process misleading, because reviewers will consider this information that you don’t need to pass up to the management system when reviewing the document. Also, reviewers may not know know how to parse 30.13.1.3 & 4: to consider
30.13.1.3 and 30.13.1.4 as an exact number with zero on the new ‘sub-ns fraction’ which has been added, or as simply the less-precise legacy value. If, however, you want these features captured in a MIB, then we should rewrite 30.13.1.7, and comments my comment 294 & 295 along with Richard Tse’s 306 point us in the right direction. Richard’s makes me think we want
two, not one new parameters. Now that I’m starting to understand this draft better, I think you’re actually adding two independent features (shifting the delay point and fine resolution), that are independently determined and controlled ? if that is right,
the structure of the original 30.13.1.7 as a single parameter saying ‘.3cx or legacy’ didn’t really work anyways, and furthermore, you may need the MIB to be able to SET the data delay point. I would suggest writing 30.13.1.7 as aTimeSyncResolution, which has two values (like the current 30.13.1.7): NANOSECOND or SUBNANOSECOND (with meanings Capable of nanosecond resolution or capable of subnanosecond resolution)
? and with text determining it pretty much like the existing one, but mapping to registers .2 and .3 (see my comment 295 for the edit to the description ? the rest is just a name change and changing the attributes) The second parameter, which would be 30.13.1.8, I’d suggest as aTimeSyncMeasurementPoint. I’ll need some help to write aTimeSyncMeasurementPoint correctly, because you want it to be meaningful for legacy devices too,
and I’m not sure, but I think you might also need an action to SET the measurement point (or should we uplevel it and just make the attribute the unit/change?) -george From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Dear colleagues, Just a reminder that we have several unresolved comments associated with a managed object specificized in 30.13.1.7. At this time, the proposal on the table is to remove this object altogether, but there were concerns
about this course of action. I would like to solicit any alternative proposals to have the text in this subclause revised. Since 6 out of remaining 18 comments are associated with this particular topic, it would be really handy to have a solid proposal
available tomorrow. Regards Marek To unsubscribe from the STDS-802-3-ITSA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ITSA&A=1
To unsubscribe from the STDS-802-3-ITSA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ITSA&A=1
To unsubscribe from the STDS-802-3-ITSA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ITSA&A=1
To unsubscribe from the STDS-802-3-ITSA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ITSA&A=1 |