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