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

Re: [802.3_DMLT] Comments on proposed managed objects for IET (was Re: [802.3_DMLT] [IEEE 802.3br IET] Agenda and presentations for San Diego)



Pat,

 

It is very hard for me to follow the suggested changes for “aMACMergeStatusRx” and “aMACMergeStatusTx” – I would very much appreciate writeup in the attached document and not just comments – these are very hard to follow.

 

As far as “oMACMergeFrameMfcsErrorCount” – if the carried MFCS does not match the calculated MFCS, that does not necessarily mean it is CRC – it can be just bit error in a fragment and assembling such a frame is pointless. Seems that if we just rely on matching MFCS to indicate whether it is a fragment or not, we can have a situation where we have an error in MFCS, merge layer assumes it is the end of the frame and then we push incomplete MAC frame to MAC. This would generate errors, decreasing link reliability.

 

I am not OK dropping ”oMACMergeFragCountOutOfOrderRx”. For debug purposes, it is better to have more data to see what kind of link problems we have, rather than just have one bin that says something went wrong.

 

I can make all changes needed to “oMACMergeFragCountRx and oMACMergeFragCountTx” – I just need to have more to work on. Please suggest specific text changes – that would make discussion simpler. Thanks

 

I think the description of “aMACMergeHoldCOunt” is clear – “A count of times MM_CTL.request(HOLD) primitive was asserted, interrupting transmission of a preemptable MAC frame”, i.e., we count only times it is asserted during a transmission of preemptable frame. Other assertions would not be counted.

 

Marek

 

From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx]
Sent: August 01, 2014 5:20 PM
To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: [802.3_DMLT] Comments on proposed managed objects for IET (was Re: [802.3_DMLT] [IEEE 802.3br IET] Agenda and presentations for San Diego)

 

Resending with the subject modified to reflect the email contents.

 

From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx]
Sent: Friday, August 01, 2014 2:16 PM
To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DMLT] [IEEE 802.3br IET] Agenda and presentations for San Diego

 

Thank you for making a good start on adding MACMerge managed objects.

 

My comments:

 

IEEE 802.3 uses a<attribute name>, not o<attribute name> for attributes.

 

This may need to be discussed at the meeting:

Since we decided that the express and premptable MACs each appear in management as regular MACs, do we need something to indicate which premptable MAC is associated with the express MAC? Or is that handled by just indicating it in an entity relationship diagram?  Should we add MAC Merge to 30.3 or do a separate figure for it?

 

For oMACMergeStatusRx,

If you support MAC Merge, the MAC Merge sublayer is always enabled including the receive processing function.  The status that would be useful to report is whether SMDs other than 0xD5 have been received. (That means that the link partner has enabled preemption transmission and there is nothing in the way that has interfered with receiving the non-SFD SMD values.)

 

For oMACMergeStatusTx,

I prefer the suggestion we got from someone at the meeting (Peter Jones?) of enabled and active instead of enabling and enabled – enabled means that preemption has been enabled but it isn’t yet operational and active means that preemption has been enabled and verified so that it is operational.

 

Also, I think Tx should be separated into a writable attribute used to configure enabling/disabling MACMerge and a read only attribute used to indicate state. States could be disabled, verifying and active.

 

We may not need oMACMergeFrameMfcsErrorCount. My view of it is that the MAC Merge sublayer checks whether the last 4 bytes match the computed Mfcs for the fragment. If they don’t match, it assumes the last 4 bytes contain a CRC and this is the end of the frame. The MAC then checks the frame CRC and it counts the error if there is a CRC error.

 

oMACMergeFragCountOutOfOrderRx – we already count reassembly errors. Do we need to also count this specific type of reassembly error? I’d suggest dropping this counter.

 

oMACMergeFragCountRx and oMACMergeFragCountTx – express frames, whole premptable frames and fragments are all mframes. It is unclear from the description whether the intent is to count mframes or only mframes containing fragments. We can know the number of frames transmitted and received from the MAC statistics. How about replacing these with counts of non-initial fragments transmitted and received which will indicate how often preemption is occurring?

 

oMACMergeHoldCount – MM_CTL.request(HOLD) can be received without interrupting a premptable MAC frame. I.e. the HOLD came when there was no frame in progress so there was no preemption but there may be premptable frames that would have been started that are held off by it. I think we should just count how many times the primitive was asserted without regard to whether it caused a preemption.

 

 

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Friday, August 01, 2014 12:58 PM
To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DMLT] [IEEE 802.3br IET] Agenda and presentations for San Diego

 

Alon,

 

Thank you for the comments. I acted on items 1, 2, and 3, and provide updated document. Item 4 is a bit unclear, since I am not really sure how we can measure reliably indicated times. It is not clear also what purpose these would serve.

 

I would suggest that we discuss these at the next meeting, and then add them to the draft

 

Regards

Marek Hajduczenia, PhD
Network Architect, Principal Engineer
Bright House Networks
Office +1-813-295-5644
Cell +1-813-465-0669

 

From: Alon Regev [mailto:aregev@xxxxxxxxxxx]
Sent: July 25, 2014 12:24 PM
To: Marek Hajduczenia; STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_DMLT] [IEEE 802.3br IET] Agenda and presentations for San Diego

 

Here is my quick feedback on both the clause 30 attributes (as well as some aspects of the current draft):

 

1.       In Beijing (March Plenary) it was decided to use auto-negotiation according to http://www.ieee802.org/3/br/public/2014-03%20Beijing%20CN/8023-IET-TF-1403_Barrass_Negotiation_r1.pdf .  I wasn't in the Beijing meeting, but as I interpret this, preemption can be enabled separately in each direction (all IET capable link partners need to be able to Rx IET frames, but Tx can be enabled separately in each direction).  I think this implies that we need a separate oMACMergeStatusRx and oMACMergeStatusTx.  Here is my proposal

a.       oMACMergeStatusRx should have one of the following values

                                                               i.      no capabilities tlv received – Additional Ethernet Capabilities TLV has not yet been received from the Link Partner since the Link went up.  This is most likely due to the partner not supporting preempting.

                                                             ii.      disabled – Received Additional Ethernet Capablities TLV indicating that link partner does not have MACMerge Tx enabled

                                                            iii.      enabling – Received Additional Ethernet Capablities TLV indicating that link partner has MACMerge Tx Enabled, but preemption operation has not been verified yet

                                                           iv.      enabled – Preemption operation has been verified

b.      oMACMergeStatusTx should have the following values

                                                               i.      disabled – MAC Merge Tx is disabled.

                                                             ii.      no capabilities tlv received – Additional Ethernet Capabilities TLV has not yet been received from the Link Partner since the Link went up.  This is most likely due to the partner not supporting preempting.

                                                            iii.      enabling – MAC Merge Tx function is in the process of being enabled

                                                           iv.      enabled – Preemption operation has been verified and the MAC Merge Tx function is enabled

c.       oMACMergeStatusRx should only support GET operations

d.      oMACMergeStatusTx should support GET and SET.

2.       I think we need a counter for “aMacMergeMFCSErrorsRx” to count the number of fragments rejected due to an invalid MFCS.

3.       Should we have a counter for “aMacMergeSMDErrorsRx” to count fragments/frames rejected due to an unrecognized SMD value?

4.       I think we should have some statistics that measure timing values.  Here are my proposals:

a.       oMACMergeHoldTimeTx – Total amount of time the Hold signal has been active (you can divide this by oMACMergeHoldCount to get the average amount of each hold) since preemption was enabled

b.      oMACMergeNoHoldTimeTx – Total amount of time the Hold signal has been inactive since preemption was enabled

c.       oMACMergePMacHoldNoEMacFrameTimeTx –Total time when pMAC frames were available, but not transmitted due to MM_CTL.request = HOLD when no frames are available from the eMAC.

 

Regards,

Alon Regev

Senior Director

Ixia

Phone: 1-818-983-2438

Fax: 1-818-981-1805

Email: aregev@xxxxxxxxxxx

 

-----Original Message-----
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Friday, July 25, 2014 6:33 AM
To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DMLT] [IEEE 802.3br IET] Agenda and presentations for San Diego

 

Any comments on these? I'd like to know which direction to move forward ...

 

Regards

 

Marek Hajduczenia, PhD

Network Architect, Principal Engineer

Bright House Networks

Office +1-813-295-5644

Cell +1-813-465-0669

 

-----Original Message-----

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]

Sent: July 18, 2014 5:43 PM

To: 'Pat Thaler'; 'Peter Jones (petejone)'

Cc: 'STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx'

Subject: RE: [IEEE 802.3br IET] Agenda and presentations for San Diego

 

Pat et al.,

 

Attached please find the first draft of Clause 30 attributes. It would be very helpful if any proposed changes be included as tracked in this document, including any specific comments on any issues with proposed definitions.

 

On the flight back I thought about counters and one simple way to avoid having to repeat all definitions of all MAC, MAC Control, and OAM counters would be to add into oMACMergeEntity pointers to merged MAC, OAM, MAC Control and other sublayers that are merged. That would allow software to identify specific MAC instance (for example) and poll respective counters. I prefer that approach personally much more than repeating pages and pages of counters and attributes with no clear need at all. Note that management software will need to be updated anyway, since oMACMergeEntity will be different and have different capabilities than a typical oMACEntity, hence I do not believe the argument of reuse of software is valid.

 

Regards

 

Marek

 

-----Original Message-----

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]

Sent: July 17, 2014 11:13 PM

To: 'Pat Thaler'; 'Peter Jones (petejone)'

Cc: 'STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx'

Subject: RE: [IEEE 802.3br IET] Agenda and presentations for San Diego

 

Pat,

 

Looking at the model in Clause 30, that would require essential a major overhaul of the model shown in Figure 30-3. Note that multiple MAC instances are already allowed (one-to-many between oAggregator and oMACEntity) so I was thinking about adding oMACMerge with multiple-to-one relationship relative to oMACEntity. We *could* replicate all counters from oMACEntity

(30.3.1) and then indicate that when oMACMerge is present, these counters represent the sum of respective counters from associated oMACEntity entries.

Down the road, that will force a specific implementation of MACMerge in EPON, though, where each instance of express and non-express MAC would have to be bound to a separate instance of MAC Merge sublayer. I am not saying it is a bad thing, just making an observation.

 

Here are the specific attributes that I am thinking of adding to oMACMerge, irrespective of whether we replicate oMACEntity and oMACControlEntity counters and attributes within oMACMerge. Please comment

 

oMACMergeID (sublayer instance id)

oMACMergeSupport (indicating whether MACMerge is supported on the DTE) oMACMergeStatus (indicating enabled / active, I do not see a difference between them ... ) oMACMergeFrameAssErrorCount (number of frames with reassembly errors) oMACMergeFrameAssOkCount (number of frames with correct reassembly - combined with oMACMergeFrameAssErrorCount will give us total number of reassembly events, or fragmented frames) oMACMergeFragCountRx (number of received fragments - any interest?) oMACMergeFragCountOutOfOrderRx (number of received fragments out of order) oMACMergeFragCountTx (number of transmitted fragments - any interest?) oMACMergeHoldCount (number of times MM_CTL.request(HOLD) was asserted) oMACMergeFrameExpressCountTx (number of express frames transmitted) oMACMergeFrameExpressCountRx (number of express frames received)

 

Anything else? I am not sure what other error conditions we can really have here ...

 

Once Clause 30 model is clear, preparing SNMP objects based on these definitions should be a breeze

 

Marek

 

-----Original Message-----

From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx]

Sent: July 17, 2014 5:27 PM

To: Marek Hajduczenia; 'Peter Jones (petejone)'

Cc: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx

Subject: RE: [IEEE 802.3br IET] Agenda and presentations for San Diego

 

What we need to cover in management:

How to deal with having two MACs - this was discussed during the meeting with 802.1 TSN. For compatibility, to allow management to look at the MAC parameters and treat them the same as for other ports, there should be one set of combined MAC parameters (i.e. any counters report the sum of events for the two MACs). Also MAC Control.

 

For separate objects for the two MACs, may be okay to just count frames sent and received by each MAC, rather than duplicating all the objects such as error counters. In that case, perhaps these counters could be in MAC Merge rather than in the MAC.

 

Also need for MAC Merge, objects for:

Preemption supported,

Preemption enabled,

Preemption active,

Received frames with reassembly errors

 

Perhaps also

Counter for MM_CTL.request(HOLD) was received (see what was done for PAUSE or PFC) Counter for number of times that preemption of a frame occurred (or number of continuation mFrames sent because that is the same thing) Same for continuation mFrames received

 

That's all I can think of at the moment.

 

Regards,

Pat

 

 

-----Original Message-----

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]

Sent: Thursday, July 17, 2014 10:40 AM

To: 'Peter Jones (petejone)'

Cc: Pat Thaler; STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx

Subject: RE: [IEEE 802.3br IET] Agenda and presentations for San Diego

 

Hi Peter,

 

I "kind of" volunteered for that, given that I was working with Howard on

802.3.1 on similar topics already. Once Pat sends me the list of parameters that we need to cover, I will start working on Clause 30 objects, and then translate that into 802.3.1 SNMP parameters - potentially, with your help if you are willing to put some time into that. I am sure we can get at least the initial version worked out between the two of us and then post for a broader review in the next version of the draft

 

Regards

 

Marek

 

-----Original Message-----

From: Peter Jones (petejone) [mailto:petejone@xxxxxxxxx]

Sent: July 17, 2014 1:31 PM

To: Marek Hajduczenia

Cc: Pat Thaler; STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx

Subject: RE: [IEEE 802.3br IET] Agenda and presentations for San Diego

 

Marek,

 

Did you volunteer (or get volunteered) to work on the "Managed objects"

item?

 

I'm interested in helping with this, but as part of full disclosure, I'm not very familiar with how 802.3 does the "Clause 30" management dance (but I have lots of SNMP experience).

 

Cheers

Peter

_______________________________________________

Peter Jones             Cisco Systems

Principal Engineer      3600 Cisco Way

ENG Switching Software  San Jose, CA, 95134 USA

Tel: +1 408 525 6952    Fax: +1 408 527 4698

Email:                  petejone at cisco.com

Twitter:                @petergjones

_______________________________________________

 

-----Original Message-----

From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx]

Sent: Monday, July 07, 2014 2:27 PM

To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx

Subject: Re: [802.3_DMLT] [IEEE 802.3br IET] Agenda and presentations for San Diego

 

Dear colleagues,

 

As editor, I'd like to mention the remaining areas where additional technical input would help with completing the draft:

 

-              Managed objects - while the SNMP object definitions will be done

when 802.3.1 is revised, we still need to add an object class and objects to Clause 30 for the new capability/sublayer and to 79.4 for the TLV.

 

-              Preemption verification - How to verify that preemption isn't

disrupted by a silent device on the link (e.g. media converter, non-802.1Q compliant switch) that replaces the SMD with an SFD still needs some fleshing out (99.4.2).

 

-              Delay constraints - I've put a first cut at delay constraints in the

draft (99.4.8). Feedback on whether those are reasonable for implementations to meet is needed.  (I also noticed a cut and paste typo on that subclause - the 4th paragraph (not counting Editor's notes) "is held" should be "is not held" (page 30 line 5).

 

Regards,

Pat Thaler

 

-----Original Message-----

From: Winkel, Ludwig [mailto:ludwig.winkel@xxxxxxxxxxx]

Sent: Monday, July 07, 2014 12:32 PM

To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx

Subject: [802.3_DMLT] [IEEE 802.3br IET] Agenda and presentations for San Diego

 

Dear colleagues,

 

Please go to the 802.3br web site to see the Agenda and presentations for San Diego meeting.

Besides the intended work on the draft, there is also a task on a liaison letter to ITU.

Both documents are in the private area (protected).

 

 

Mit freundlichen Gruessen / With best regards, Ludwig Winkel

   Chair of the IEEE P802.3br Task Force

 

Siemens AG , I IA SC FC

Oestliche Rheinbrueckenstr. 50

76187 Karlsruhe, Germany

Tel.: +49 721 595-6098

Mobile: +49 172 6132658

mailto:ludwig.winkel@xxxxxxxxxxx

 

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Klaus Helmrich, Hermann Requardt, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial

registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

Attachment: oMACMerge R003.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document