Subject: [Hubmib] HUBMIB/AToMMIB joint mtg - IETF 51st preliminary minutes

From: Nathan Kohn <[email-masked]>
Date: Wed, 08 Aug 2001 19:50:19 -0400

here are the minutes for the joint  HUBMIB/AToMMIB meeting tue aug-07-01 at the
51st IETF.  let us know what is missing?  give john flick credit for what
accurate and myself the credit for what isn't.

nathan

HUBMIB (Ether)/AToMMIB Joint Session
 chaired by Dan Romascanu <[email-masked]> & Nathan Kohn <[email-masked]>

Minutes by John Flick & Nathan Kohn

Attendance about 20, mostly hubmib.

Objective: Discuss cooperated efforts in defining a MIB that will cover 802.3ae WAN interface  sublayer.  Data rate and format compatible with SONET STS-192c.

   - Discuss the potential for next revision of RFC 2558 to cover
   - Or a new MIB that will cover both SONET and 10 Gbs Ethernet interfaces using
     SONET

Current internet draft: draft-ietf-hubmib-wis-mib-00.txt

This draft generated several comments both from SONET community and IEEE. Dan presented both the IEEE and HUBMIB status and schedules. IEEE began work in January 2000, scheduled to finish work in March, 2002. Ethernet MIB WG would like to be ready with MIBS at roughly the same time as IEEE finishes its standard.  Dan is a voting memeber of IEEE and feels that work can be done effeciently in parallel.

 IEEE Status:
   - Draft D3.1 published, draft D3.2 to be published in the next few weeks
   - Dan can provide passwords to our WG members to access the IEEE drafts
   - Next ballot with all 802 members
   - Content quite stable, reduced number of open issues
   - Dan met with IEEE folks at last plenary that resulted in a set of inputs
     to the hubmib

Independently, Mike Heard and Kaj Tesnik have issued an alternate individual internet-draft for WIS.  Unfortunately, neither was able to attend this meeting.

Dan asked how many had read WIS draft – very few hands went up

Mike Ayers reviews current draft – current draft was primarily to get comments. WIS is somewhat of a challenge because it has its feet in both the LAN world and the WAN (SONET) world.  Many of the things in the SONET MIB were just copied into the WIS MIB.  Draft was based on IEEE D3.0, did not include updates from D3.1.

 Two major questions:
   - If this is manageable as both Ethernet and SONET, how do we arrange the MIB to be usable by both Ethernet and SONET management systems simultaneously, without confusing either.  WIS is similar, but not exactly SONET.
   - IfStack usage: one proposal is etherCsmacd/sonetPath/sonet: would we confuse
     SONET managers if we did this, since you cannot configure multiple paths in WIS?
   - Several questions about specific management objects; example, is the SONET object SONET-SES-OTHER-SET, which allows four different ways of collecting stats.  The question was whether it was prescriptive or descriptive.  After discussion it was decided that it is descriptive. However we need to address the top-level question of how we represent the interface first

Need input from management app developers of how various representations would  affect them. 

Current document does not provide mapping to IEEE objects.  Dan  asked if we had gone thru the exercise of mapping between the IEEE clause 30 objects and 2558 objects.  Mike answered that we need to understand the differences between the IEEE objects and SONET objects.  An example is the reset and power options - are they only applicable for the section?  Should these objects only be for WIS?  Another 

 Dan summarized 3 main issues:
   - Need to describe our interface model, what the stack layerslooks like, and how it
 is managed.
   - Need to map IEEE clause 30 objects to SONET and/or WIS objects.  Are all necessary, are any missing?
   - How do we reconcile counter models used by Ethernet world and SONET world.  How are the statistics for counters veiwed from the higher layers?

Need input from SONET folks on this.  Particularly on the future direction for SONET MIBs, i.e. provisioning.

Can we put together a design team with current WIS editors along with Mike and Kaj to have them come up with answers to these three major issues.

Chairs of hubmib and atommib will put together list of questions for design team, which will consist of current hubmib editors, Mike and Kaj who submitted counter-proposal.  Kam Lam (co-author of the optical mib in AToMMIB) also volunteered for design team.  This will be a joint design team which will feed back to both WGs.  HUBMIB and AToMMIB are both meeting on thursday and will discuss the proposal within each WG.

Here are the proposed questions (supplied by Dan after the meeting):

	1. What is the layers model for the Ethernet-WIS interfaces, 
	   and how will this model map tothe Interfaces MIB? 

	2. What is the proposed mapping of the management objects 
	   in IEEE 802.3ae in the WIS MIB, and SONET MIB? 

	3. What is the proposed solution for supporting the performance counters 
	   in a manner that would be satisfy both users / applications using 
	   Ethernet/RMON, and SONET methods of performance monitoring?

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 16 Aug 2001 16:15:34 -0700 (PDT)

On Wed, 8 Aug 2001, Nathan Kohn wrote:

> here are the minutes for the joint  HUBMIB/AToMMIB meeting tue
> aug-07-01 at the 51st IETF.  let us know what is missing?  give
> john flick credit for what accurate and myself the credit for
> what isn't.

Thanks for posting these minutes.  There are a several comments I'd like
to make in response to some of the points raised in the meeting.  In
what follows I've re-wrapped the lines of quoted text for readability.

> Objective: Discuss cooperated efforts in defining a MIB that will
> cover 802.3ae WAN interface  sublayer.  Data rate and format
> compatible with SONET STS-192c.
> 
>    - Or a new MIB that will cover both SONET and 10 Gbs Ethernet
>      interfaces using SONET
> 
> This draft generated several comments both from SONET community and
> IEEE.  Dan presented both the IEEE and HUBMIB status and schedules.
> IEEE began work in January 2000, scheduled to finish work in March,
> 2002.  Ethernet MIB WG would like to be ready with MIBS at roughly the
> same time as IEEE finishes its standard.  Dan is a voting memeber of
> IEEE and feels that work can be done effeciently in parallel.
> 
>  IEEE Status:
>    - Dan met with IEEE folks at last plenary that resulted in a set of
>      inputs to the hubmib
> 
> Independently, Mike Heard and Kaj Tesink have issued an alternate
> individual internet-draft for WIS.  Unfortunately, neither was able to
> attend this meeting.
> 
> Dan asked how many had read WIS draft  very few hands went up
> 
> Mike Ayers reviews current draft  current draft was primarily to get
> comments.  WIS is somewhat of a challenge because it has its feet in
> both the LAN world and the WAN (SONET) world.  Many of the things in
> the SONET MIB were just copied into the WIS MIB.  Draft was based on
> IEEE D3.0, did not include updates from D3.1.

The draft that Kaj and I posted was motivated largely by the fact
that we objected to copying objects from the SONET-MIB rather than
incorporating them by reference.

> Two major questions:
>    - If this is manageable as both Ethernet and SONET, how do we
> arrange the MIB to be usable by both Ethernet and SONET management
> systems simultaneously, without confusing either.  WIS is similar,
> but not exactly SONET.

WIS is supposed to be SONET-compatible, and from my reading of D3.1 it
certainly appears that it is.  My take is that it is possible to
reconcile the differences between WIS and ordinary SONET by providing
supplemental MIB objects.

>    - IfStack usage: one proposal is etherCsmacd/sonetPath/sonet: would
> we confuse SONET managers if we did this, since you cannot configure
> multiple paths in WIS?

Many SONET interfaces currently exist that do not permit configuration
of multiple paths -- e.g., any fixed-rate ATM over SONET or PPP over
SONET line card (these are very common on routers).  An Ethernet
interface incorporating the WIS should be neither more nor less
difficult to deal with than one of those interfaces.

>    - Several questions about specific management objects; example, is
> the SONET object SONET-SES-OTHER-SET, which allows four different ways
> of collecting stats.  The question was whether it was prescriptive or
> descriptive.  After discussion it was decided that it is descriptive.
> However we need to address the top-level question of how we represent
> the interface first

sonetSESthresholdSet has a MAX-ACCESS of read-write and a MIN-ACCESS of
read-only.  If an agent implements it as read-write, then it is
prescriptive.  If an agent implements it as read-only, then it is
descriptive.  If only a few discrete sets of thresholds are needed (as
was concluded by the AToMMIB wg when the SONET-MIB was revised in the
1996-1998 time frame), then this object does a reasonable job in either
role (for example, the value ansi1997(5) specifies the P802.3ae D3.1
default values of 8554, 9835, and 2400 for section, line, and path SES
thresholds respectively).  If the full flexibility of the D3.1 threshold
objects is desired, then supplemental MIB objects need to defined, in
which case sonetSESthresholdSet would be assume the value other(1) if a
"non-standard" threshold set was dialed-in or if different interfaces
used different threshold sets.

> representations would affect them.

Agreed.  And we also urgently need the _users_ of the technology to
tell us what they would prefer to see.

> Current document does not provide mapping to IEEE objects.  Dan asked
> if we had gone thru the exercise of mapping between the IEEE clause 30
> objects and 2558 objects. Mike answered that we need to understand the
> differences between the IEEE objects and SONET objects.  An example is
> the reset and power options - are they only applicable for the section?
> Should these objects only be for WIS?  Another [ ... missing text ...]

Both my initial e-mail commenting on <draft-ietf-hubmib-wis-mib-00.txt>
and the alternate individual internet-draft posted by Kaj Tesink and
myself went through that mapping exercise.  Note that the mapping
included not only objects from RFC 2558 but also objects from our
proposed alternate MIB and from the MAU-MIB -- in particular, acResetWIS
is mapped to the ifMauStatus value reset(6).

One point I'd like to make about the reset and power-down options is
that there is no value from the user's point of view in being able to
perform these actions on individual sublayers that have to act as a
unit, as is the case for interface layers that comprise the WIS.  From
the user's point of view the same effect can be obtained by resetting
or powering the entire interface (i.e. all performing the action on all
sublayers simultaneously).  The MAU-MIB already has a means to do this
-- ifMauStatus values reset(6) and shutdown(5) -- and I think that is
quite sufficient to meet all reasonable needs.

>    - Need to describe our interface model, what the stack layerslooks
> like, and how it is managed.

Agreed.  There is one proposal for doing this in my initial e-mail
commenting on <draft-ietf-hubmib-wis-mib-00.txt> and in the the
individual internet-draft posted by Kaj Tesink and myself.  My e-mail
commenting on on <draft-ietf-hubmib-wis-mib-00.txt> also describes what
happens if the interface type is changed from 10GBASE-W to 10GBASE-R or
vice-versa by manipulating the MAU-MIB object ifMauDefaultType.

> Are all necessary, are any missing?

The individual submission by Kaj Tesink and myself did this, and it
provided a mapping for _all_ the clause 30 objects in D3.1 (including
the latched status objects that will be removed in D3.2 -- obviously
that will have to change).  As in <draft-ietf-hubmib-wis-mib-00.txt>
we also included objects to activate the jitter test.  These have no
clause 30 counterparts, but the jitter test is a mandatory function of
clause 50.  Note that the counter mappings are approximate.

>    - How do we reconcile counter models used by Ethernet world and
> SONET world.  How are the statistics for counters veiwed from the
> higher layers?

This is the most important question that we must resolve.  It is
possible, in principle, to reconcile the counter _models_ by providing
something along the lines of RMON's usrHistory group.  Unfortunately,
the usrHistory group does not provide for current interval counts, and
the counters as defined in P802.3ae do not count quite the right things
to satisfy SONET PM requirements.  These points are discussed in more
detail below.  Rather than invent the machinery needed to reconcile both
models -- which would not allow for re-use of existing SONET management
code -- the submission by Kaj Tesink and myself proposes to use the
objects in the SONET-MIB, appropriately supplemented, to manage the WIS.

> Need input from SONET folks on this.  Particularly on the future
> direction for SONET MIBs, i.e. provisioning.
> 
> Can we put together a design team with current WIS editors along with
> Mike and Kaj to have them come up with answers to these three major
> issues.

I will be happy to assist.

> Chairs of hubmib and atommib will put together list of questions for
> design team, which will consist of current hubmib editors, Mike and Kaj
> who submitted counter-proposal.  Kam Lam (co-author of the optical mib
> in AToMMIB) also volunteered for design team.  This will be a joint
> design team which will feed back to both WGs.  HUBMIB and AToMMIB are
> both meeting on thursday and will discuss the proposal within each WG.
> 

The individual submission by Kaj and myself addresses this point, and in
my comments on <draft-ietf-hubmib-wis-mib-00.txt> I discuss what happens
to the stack table when the interface type is changed from 10GBASE-W to
10GBASE-R and vice-versa.

>            in IEEE 802.3ae in the WIS MIB, and SONET MIB?

The individual submission by Kaj and myself addresses this point, too,
stating not only what the mapping is but also where it is inexact.
Note that there is precedent for using a pre-existing MIB even when
the objects do not exactly match;  for example, the IF-MIB packet
counters do not count quite the same things as the IEEE 802 clause 30
frame counters.

>         3. What is the proposed solution for supporting the
>            performance counters in a manner that would be satisfy both
>            users / applications using Ethernet/RMON, and SONET methods
>            of performance monitoring?

In my opinion, this is the question to settle first, because the answer
to it will affect the answers to all the others.  The problem is that
SONET performance monitoring methods require an agent to provide
15-minute interval counters as in the SONET-MIB, whereas Ethernet/RMON
performance monitoring methods require an agent to provide rollover
counters (aka generalized nonresetable counters) as in the EtherLike-MIB
or in P802.3ae clause 30, and these methods are not entirely compatible.

Since this point is very important, it is worth providing additional
details.  It might be though that one solution that would satisfy both
sets of users/applications would be to provide rollover counters based
on the objects in P802.3ae clause 30, and then use the User History
Collection Group (usrHistory) from RFC 2021 to provide, as an option,
the interval counters required for SONET performance monitoring.
Unfortunately, this will not meet several key SONET PM requirements.
First, the user history collection machinery does not make available the
value during the current sampling period;  it shows up only after the
sampling period is complete.  SONET PM, however, requires that the value
for the current interval be made available at all times.  Second, the
generalized nonresetable counters defined in P802.3ae clause 30 do not
actually count the statistics that are required to generate the SONET
performance parameters.  Specifically, ANSI T1.231-1997 (which is the
PM standard on which the SONET-MIB is based) states in Section 9.4 that
code violation counts must be inhibited (i.e. not incremented) during
severely errored seconds and that at layers where unavailable time is
defined (i.e. line and path) all parameters except unavailable seconds
must be inhibited during unavailable time.  P802.3ae D3.1 does not
incorporate parameter inhibiting and does not define unavailable time;
in fact, D3.1 Section 50.1.1 specifically exempts the WIS from the PM
requirements in ANSI T1.416-1999 Section 7.7, which incorporates
T1.231-1997 by reference, and does away with interval counters in favor
of generalized nonresetable counters as is the tradition for Ethernet.
These generalized nonresetable counters cannot serve as the "base"
objects for a usrHistory-like solution that complies with SONET PM
requirements.  It appears, then, that the two methods will be very
difficult to reconcile, except by providing two sets of objects.

It is my position that we should standardize only one method, not two.

The individual submission by Kaj and myself assumes that 15-minute
interval counters should be used so that NMS applications developed for
applications like ATM over SONET and PPP over SONET can be re-used for
the SONET-like parts of the WIS.  An alternative would be to define a
new set of MIB objects using rollover counters (aka generalized
nonresetable counters) as in the EtherLike-MIB or in P802.3ae clause 30.
That would simplify the agent by relegating to the manager the job of
collecting historical data, but it would also introduce a departure from
the SONET MIB style management used by existing NMS applications.  I
think that the first job of the design team should be to pick ONE of
these approaches, and settle the other questions after that.

Mike

_______________________________________________
Hubmib mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/hubmib