Subject: [Hubmib] FW: RFC 2665 comments

From: Dan Romascanu <[email-masked]>
Date: Wed, 14 Mar 2001 00:23:46 +0200

Randy Presuhn did a reading of RFC 2665, in search for editorial and
technical issues that we might want to deal with in the review process of
this document. Please find below his findings.

Regards,

Dan

> -----Original Message-----
> From:	Randy Presuhn [SMTP:[email-masked]]
> Sent:	Tue March 13 2001 3:17
> To:	[email-masked]
> Subject:	RFC 2665 comments
> 
> Hi Dan -
> 
> As you requested, I've taken a look at RFC 2665.
> Here are the nits I found:
> 
>         page 1+: expand abbreviations on first use, e.g. "Mb/s"
>         page 2:  change "MIB:" to "MIB,"
>         page 4:  the list of ifType values doesn't match the
>                  more extensive list that appears in the text
>                  on page 7, and the usage recommendation would
>                  lead one to conclude that the list might even
>                  be more extensive.
>         page 4:  change "Kastenholz then" to "Kastenholz, then"
>         page 5:  it seems odd that an Editor's note remains in
>                  the RFC text
>         page 5:  presumably the last paragraph will need substantial
>                  changes
>         page 7:  will the ifMtu need any changes?
>         page 7:  here and in other places, it would be nice if
>                  there were a reference for the MAU MIB.
>         page 25: the description of dot3StatsSymbolErrors makes
>                  it sounds like this should be a Counter64, but
>                  that's probably not realistic.
>         page 26: I couldn't parse "media is non-idle a carrier event";
>                  I think some words or punctuation are missing.
>         page 29: has 802.3x been merged into more recent versions?
> 
> I hope this is useful; feel free to forward appropriately.
> 
>  -------------------------------------------------------
>  Randy Presuhn           [email-masked]
>  Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
>  Fax:   +1 408 965-0359  2141 North First Street
>  http://www.bmc.com/     San José, California 95131  USA
>  -------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  -------------------------------------------------------

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

---

From: John Flick <[email-masked]>
Date: Tue, 13 Mar 2001 17:41:54 -0800

>>                  lead one to conclude that the list might even

If I remember correctly, what we were trying to say was that an
Ethernet interface, regardless of speed or flavor, should be
returning 'ethernetCsmacd' as its ifType.  I believe I originally
wrote MUST here, but Dan convinced me to soften it to a SHOULD for
the sake of implementations that had already shipped with some
other value.

A number of additional types were registered by individuals
directly with IANA, without any WG review.  Several discussions
that spanned this WG and ifmib and rmonmib back in 1996-1997
reached the conclusion that we just wanted a single ifType, and 
those other registrations should be deprecated.  The information
on what speed of ethernet you are running is in ifSpeed, and the
physical media info is in the MAU MIB, so there was no reason to
overload ifType with that info.

Obviously, we need to say this more clearly.

>>         page 5:  it seems odd that an Editor's note remains in

This editor's note actually was present in RFCs 1623, 1643, 1650,
2358, and 2665.  We need to decide if we want to say anything more
definite about cases where layering with Ethernet interfaces shows
up in ifStackTable. One case is with link aggregation.  Another that
I have seen in implementations is in layer 2/3 switches where a
VLAN can be treated as a router interface.  I have seen this
represented as an IP forwarding interface stacked over the physical
ports that are members of the VLAN.

This may be a good topic for an implementation survey to determine
how existing implementations are using ifStackTable with Ethernet.
If we could say something in this document, it would certainly
help NMS developers.

>>         page 5:  presumably the last paragraph will need substantial

Agreed.  At the time this was written, the ifmib working group was
working on the system and interface test MIB that would have replaced
the ifTestTable from RFC 1573 (which was itself a replacement for the
ifExtnsTestTable from RFC 1229).  That work seems to have died, so we
should probably just remove this section, and obsolete the
OBJECT-IDENTITY definitions for the tests.

>>                  that's probably not realistic.

If your error counters are increasing so quickly that a Counter32
is too small, counter rollover is the least of your worries :-)

>>                  I think some words or punctuation are missing.

Should be: "media is non-idle (a carrier event)" - the left paren
was missing.

John

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 13 Mar 2001 20:56:44 -0500

>is too small, counter rollover is the least of your worries :-)

        Problem is that if one polls at relatively long intervals
and is concurrently having a lot of problems (so the counter
is rolling over relatively quickly), having a small counter can 
make it look like there is only a small problem when the problem 
is actually huge.

Ran
[email-masked]

---

From: John Flick <[email-masked]>
Date: Wed, 14 Mar 2001 11:36:16 -0800

> make it look like there is only a small problem when the problem

The criteria mandated by RFC 2578 for when to use a Counter64 is
when a Counter32 would roll in less than 1 hour.

Unfortunately, at 10Gig, that is true of several of the error
counters in this MIB.  (The IEEE document states that the maximum
increment rate for the error counters is 160,000 counts per second
on a 100Mbit/sec link.  That equates to 16,000,000 counts per
second on a 10Gbit/sec link, or 57,600,000,000 counts per hour,
which is well beyond the limits of a 32-bit counter).

The counters that are of concern would be:
    dot3StatsFCSErrors
    dot3StatsSymbolErrors
    dot3StatsInternalMacTransmitErrors
    dot3StatsInternalMacReceiveErrors

We would also need to spin up the ifmib WG to add 64-bit versions
of ifInErrors and ifOutErrors, since those counters would also
increase when the specific error counters in Ethernet MIB increase.
HC-RMON would probably also need to add 64-bit error counters.

Note that no other link layer MIBs that I know of have 64-bit
error counters.

One could argue that if you are really seeing so many errors that
a 32-bit would roll in less than an hour, the link is basically
unusable, no real traffic will be getting through, and you don't
really need the error counters to tell you that you have a serious
problem.  You could also use the RMON alarmTable to monitor the
counter over a shorter interval locally on the device, and send a
notification when a threshold is exceeded.

Of course, adding 64-bit error counters to the Ethernet MIB would
probably mean cycling at Proposed, so we would probably need to
put them in a supplemental document - which has its own problems.
Do we think this is worth it?

John

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 14 Mar 2001 14:44:21 -0500

>Note that no other link layer MIBs that I know of have 64-bit

        OC-192 SONET and its SDH equivalent are almost the
same speed and will have the same issues, for the ifMib 
and so forth (rather than for the Ethernet MIB), so this isn't 
just a 10 GigE problem.  Vendors are looking into 40 Gbps products, 
which are probably available for SONET/SDH within 12 months.

>put them in a supplemental document - which has its own problems.

        Recycling at Proposed wouldn't necessarily be such
a bad thing, IMHO.  Reality is that both vendors and operators
care that a MIB is in a standards-track RFC, not which level 
of standard.  In fact, my own personal view is that MIBs ought 
to be BCP anyway,  because advancing MIBs is such a dark mystery 
to most of us.

>Do we think this is worth it?

        I do, both for the Ethernet MIB and the other affected
MIBs.  10 GigE products are really going to ship from many
vendors in a few months.  They will likely deploy very fast,
because they will probably be a whole lot cheaper than SONET/SDH
at the same speed.  Once deployed, operators will need to be able 
to manage 10 GigE without excessively frequent polling of devices.

Cheers,

Ran
[email-masked]