Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802.3_ITSA] continued work on managed objects (subclauses 30.13.1.x)



P802.3cx Task Force members:

At our meeting on Jan 25, we agreed to continue working on this issue about managed objects (see email below) and, hopefully, achieve consensus on a solution in this reflector before our March meeting.  To give us sufficient time to finish this work before our March meeting, we should start next week.  If you would like to participate in the drafting of the solution, please send me an email by Feb 8, 2022.

 

Regards,

 

Richard Tse

Sr Technical Staff Engineer – Architect

Microchip Technology

8555 Baxter Place

Burnaby, BC

Canada

V5A 4V7

Phone:  +1-604-415-6015

Email:  Richard.Tse@xxxxxxxxxxxxx

Website:  www.microchip.com

 

 

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, January 25, 2022 3:30 PM
To: STDS-802-3-ITSA@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ITSA] D2.1 comments on 30.13.1.7

 

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

What are you thanking ME for?  Richard took on this big job!

 

 

From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Tuesday, January 25, 2022 3:27 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-ITSA@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_ITSA] D2.1 comments on 30.13.1.7

 

Thank you, George

 

Richard will spearhead the work on new management objects for Clause 30 to be submitted as a comment against D2.2. I hope we can use the reflector for consensus building and simply roll in new objects with the group’s consensus

 

Regards

 

Marek

 

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, January 25, 2022 8:35 AM
To: mxhajduczenia@xxxxxxxxx; STDS-802-3-ITSA@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_ITSA] D2.1 comments on 30.13.1.7

 

Marek – that sounds like a good plan.  You might also consider an editor’s note capturing some general thoughts and soliciting complete proposals for resolution.

 

From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Tuesday, January 25, 2022 6:53 AM
To: STDS-802-3-ITSA@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ITSA] D2.1 comments on 30.13.1.7

 

Richard,

 

The proposed modifications go way beyond the original scope of the comment and I do not think we will be in position to craft individual objects on the fly at the comment resolution. If these indeed are needed, I believe we should have a more complete proposal with a comment against D2.2 once published, and consensus building around it. It would be a major change to Clause 30 material.

 

At this cycle, I suggest we fix the problem with aTimeSyncCapabilityType definition to make it correct, and then use the time of the next recirculation to build a better set of management objects for Clause 30

 

Regards

 

Marek

 

From: Richard Tse <0000117d24f8db68-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, January 24, 2022 7:25 PM
To: STDS-802-3-ITSA@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ITSA] D2.1 comments on 30.13.1.7

 

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).

  • 30.13.1.1:  aTimeSyncCapabilityTX – capability for supporting TX delay
  • 30.13.1.2:  aTimeSyncCapabilityRX – capability for supporting RX delay
  • 30.13.1.3:  aTImeSyncDelayTXmax – the sum of all the configured TX max delays
  • 30.13.1.4:  aTImeSyncDelayTXmin – the sum of all the configured TX min delays
  • 30.13.1.5:  aTImeSyncDelayRXmax – the sum of all the configured RX max delays
  • 30.13.1.6:  aTImeSyncDelayRXmin – the sum of all the configured RX min delays
  • 30.13.1.7:  aTImeSyncCapability – ???

 

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:

  1. data delay measurement point
  2. multilane support
  3. NUM_UNIT_CHANGE

 

 

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:

  • 30.13.1.1:  aTimeSyncCapabilityTX – capability for supporting TX delay (nanoseconds)
  • 30.13.1.2:  aTimeSyncCapabilityRX – capability for supporting RX delay (nanoseconds)
  • 30.13.1.3:  aTImeSyncDelayTXmax – the sum of all the configured TX max delays (nanoseconds)
  • 30.13.1.4:  aTImeSyncDelayTXmin – the sum of all the configured TX min delays (nanoseconds)
  • 30.13.1.5:  aTImeSyncDelayRXmax – the sum of all the configured RX max delays (nanoseconds)
  • 30.13.1.6:  aTImeSyncDelayRXmin – the sum of all the configured RX min delays (nanoseconds)
  •  
  • 30.13.1.7:  aTimeSyncCapabilitySubNsTX – capability for supporting TX delay (sub-nanoseconds), represented by logical AND of all TX fine resolution path data delay ability registers
  • 30.13.1.8:  aTimeSyncCapabilitySubNsRX – capability for supporting RX delay (sub-nanoseconds), represented by logical AND of all TX fine resolution path data delay ability registers
  • 30.13.1.9:  aTImeSyncSubNsDelayTXmax – the sum of all the configured TX max delays (sub-nanoseconds), the sum of all the TX max delays (sub-nanoseconds)
  • 30.13.1.10:  aTImeSyncSubNsDelayTXmin – the sum of all the configured TX min delays (sub-nanoseconds) , the sum of all the TX min delays (sub-nanoseconds)
  • 30.13.1.11:  aTImeSyncSubNsDelayRXmax – the sum of all the configured RX max delays (sub-nanoseconds) , the sum of all the RX max delays (sub-nanoseconds)
  • 30.13.1.12:  aTImeSyncSubNsDelayRXmin – the sum of all the configured RX min delays (sub-nanoseconds) , the sum of all the RX min delays (sub-nanoseconds)
  •  
  • 30.13.1.13:  aTimeSyncSfdDdmpCapability – capability for supporting start of SFD as DDMP – represented by the logical AND of registers 3.1800.13 and 5.1800.13
  • 30.13.1.14:  aTimeSyncSymAfterSfdDdmpCapability – capability for supporting start of first symbol after SFD as DDMP – represented by the AND of registers 3.1800.12 and 5.1800.12
  • 30.13.1.15:  aTimeSyncDDMP – selected DDMP – represented by the AND of registers 3.1813.13 and 5.1813.13 (where the two register bits must be the same value to give a valid result)
  •  
  • 30.13.1.16:  aTimeSyncMultilaneCapability – capability for reporting of multi-PCS lane path data delay – represented by the value of register 3.1800.11
  • 30.13.1.16:  aTimeSyncNumUnitChangeCapability – capability for supporting TX/RX_NUM_UNIT_CHANGE indication – represented by the value register 3.1800.10

 

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.


Rich

 

 

 

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, January 24, 2022 4:53 PM
To: STDS-802-3-ITSA@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ITSA] D2.1 comments on 30.13.1.7

 

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>
Sent: Monday, January 24, 2022 11:57 AM
To: STDS-802-3-ITSA@xxxxxxxxxxxxxxxxx
Subject: [802.3_ITSA] D2.1 comments on 30.13.1.7

 

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


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