| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 R001.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document