I apologize for the terribly short notice, but I returned only yesterday from my vacation. Please find below the draft of the minutes of the San Diego meeting. I would welcome comments as soon as possible, but I need to submit a first version by Friday. We can make corrections in the coming two weeks if something is very wrong, as I understand.
Thanks and Regards,
Dan
IETF60 - HUBMIB Minutes (Draft)
--------------------------------
General/Intro - Dan Romascanu
.3ah recently was finalized, but not yet publicized. The IDs of this
group are out in last call, but still have many comments. Therefore,
it is likely we'll have to change the current schedule. Ideally, the
authors will put out another last call by early September timeframe
(current last call ends 8/15). Hoping that hubmib will not meet at
the next IETF meeting.
There is a question as to handle the new Ethernet physical layers and
the MAU MIB. General idea is to pull the MAU type information into an
IANA registry. To do so, we'd have to pull the MAU types and
descriptions out of the MAU MIB and into a registry. General
feel of the room was that this is a good thing. Will be brought up on
the list. EdB volunteered to edit this work item.
IETF is recommending to the IEEE that it take on its own MIB work.
802.1 has been doing a good job recently, 802.3 hasn't taken the
steps. Needs to be prodded along further.
-------------------------------
OAM MIB - Matt Squire
1) Relationship to other MIBs. There was a comment to add more verbiage on the entirety of the EFM project to this MIB. After a little discussion, it seemed like the consensus would be to add some text in the overview/background sections, but do not include anything in the actual MIB itself.
2) Row status. There were several tables with row status (dot3OamTable, dot3OamPeerTable). This was commented as unnecessary and will be removed while adding an inactive state object.
3) Special stuff for EPON. A question was asked if anything special is needed for using OAM on EPON. In general, EPON looks like a collection of p2p links to higher layer applications, OAM included but not special in that regard. The suggestion at the end was to add a brief sentence somewhere that indicates EPON has an architecture for higher layer applications like OAM, reference the EPON MIB, but not go into any detail here.
4) Loopback control. A comment was made that the OAM loopback control isn't secure. In the end, the commenter misunderstood the intent/workings of the OAM loopback control objects and withdrew the comment after some discussion. It was decided that OAM should not allow loopback commands from the peer by default (dot3OamLoopbackIgnoreRx=true by default).
5) Event configuration. A question was raised as to whether OAM should have a configurable number of re-tries for the event replication. The idea would be to allow the administrator to configure whether an event should be sent once, twice, etc., in order to control the tradeoff between utilization and reliability (as OAM events are not confirmed or guaranteed). Some discussion but no consensus, so if you have an opinion, pass it on. If no proposals show up, the current scheme remains as is.
6) Event status table. Currently, event information is stored as a TLV (e.g. an octet array). The individual field are not pulled out and exposed. A question was raised as to whether this is good or bad. The positive aspects are that it results in fewer fields, but on the other side, the fields are probably useful and need to be exposed for a manager. There seemed to be consensus that the fields should be pulled out of the TLV. And that we might be able to create a generic event table rather than one row per event type.
7) Event compliance. There was a question as to whether the compliance table should require implementation of all events, or if each event can be its own compliance group. The justification for individual compliance groups for different events are that some can be implemented easier than others (e.g. remote fault may require hardware changes, frame error thresholds would not). So the general feeling seemed to be that we can keep the individual event compliance groups, with better explanation of the motivation in the text.
-------------------------------
EPON MIB - Lior Khermosh
General changes had to do with aligning the ID with D3.3 of EFM.
Still MIB compiling issues (editorial, mostly worked out) that need to
be finished. Also added relations to the current MIBs (epon, optics,
bridge, etc.) to better clarify relationships among entities.
Another change is that the EPON MIBs have been partitioned into
1) control
2) stats
3) LLID Mac addresses
4) events
5) event logs
for simpler understanding/logic.
Also added to this revision is that more event information has been
added - event state, event enable, event logs.
Finally, removed overlap with OAM MIB.
Issues:
1) There were some font problems. Will be fixed.
2) MAU changes. Suggested changes to MAU as talked about earlier
(separate IANA controlled registry).
3) How is dot3MpcpId determined/set? Currently unclear in draft,
needs better description.
4) Admin state looks like an oper state? Which do you mean? Note the
EFM doc consistently (mpcp, oam, flow control) uses AdminControl to
change admin state, and makes AdminState read-only.
4) Device separation. This came up in the context of some counters,
but generally the MIB needs to better define which objects are
applicable to ONU, OLT, both, etc. Its not clear in the current
draft.
5) In general, need to clearly define what units used, how units
represented, possible values, etc. Theme shows up in several comments
against the draft (e.g. eponDeviceObjctReportThreshold).
6) Need to specify that eponDeviceRemoteMacAddressLLDTable can be
erased on a re-set, and in general, the description needs to be
improved (hard to understand).
7) eponDeviceEventsLogTable is not described well. The intent is a
MAC level event log (set of events to when they happened). A question
was asked if this is useful (some thought it would be). Another
question on whether it would be better/useful if OAM had one, and/or
if they shared a common event log.
----------------------------------
EFMCu MIB - Ed Beili
Changes from draft -00 include
- Some restructuring of tables, map to D3.3 better.
- Available stack table - r/o, system sets is abilities
- Added target bandwidth, target SNR margin
- Added profile table
- New notifications (low bandwidth), enable/disable each notification
Open issues:
1) Relation to shds/vdsl MIBs. At previous meeting, decided to NOT
import other MIBs but to duplicate where needed. Many reasons
- many not available in .3ah
- simpler , name consistency
- unifies 2b/10p as much as possible
- ieee is a frozen set of ITU capabilties
Some in room agreed, but needs to go to the list to discuss further.
2) efmCuAvaialbeStackTable describes x-connect capability (read-only)
- should it be generalized/moved into its own thing? This is common
with (possibly) ITU and ANSI work in progress? Consensus was to
re-name it to appear more generic (e.g. ifAvailableStackTable) but
to keep it in the current EFMCu MIB.
3) Notifications - currently have a few, could add more
- errored seconds, ses, uas, ...
VDSL/SHDSL MIBs have more, but they're relatively unused in practice.
Can we not copy that model? Hope is yes, but take it to the list.
4) ifSpeed - what should it be (aggregate & PME)? There are some
concerns/questions on what the ifSpeed of the interface should be.
Most Etehrnet PHYs use "net data rate of the MII". This includes
frames, preamble, ipg, etc. Preamble, IPG aren't carried on EFMCu,
64/65 overhead and bonding overhead may be added. So there's an open
question on how to set ifSpeed and if we need anything else. Thought
was to contact IEEE (via mailing lists) to get their opinion.
Generaly doesn't feel right to say EFMCus are all 100Mbps because
thats what the MAC is running at. Take it to the list (TITTL)...
5) Target SNR margin overlooked in .3ah, seems like we should keep it,
question whether it should be stored in the profile or if we should
store it at the PCS or at the PME or something else? TITTL...
6) C30 deficiencies. Do we need to take a position on addressing C30
deficiencies? Its missing many (?) expected objects for control, and
we're directly referencing C45 registers instead of C30 attributes.
Will take to mailing list to determine if enough people agree things
need to be added to C30 to address deficiencies. TITTLL...
Notes taken by Matt Squire and Dan Romascanu
RSS Feed