Subject: [Hubmib] RFC 2665 Updates

From: John Flick <[email-masked]>
Date: Fri, 09 Mar 2001 16:28:41 -0800

Dan asked me to post some information to the list on what needs to be
changed for our update to RFCs 2665 and 2668, and some options for how
to handle 10G.  Dan mentioned that he would like to see the current
docs advance to Draft Standard (assuming we have sufficient
implementation reports) and put any additional objects needed for
10 Gig in a separate document.

For the most part, I think we should be able to do this.  Here is my
list of outstanding changes for RFC 2665 (none of which should
preclude advancement on the standards track).  I will post separate
messages with RFC 2668 changes, and options for handling the WAN
interface sublayer additions.

1. Update Section 2 and copyright boilerplate to the latest
   approved incantations.

2. Update abstract and Section 1 to say this is new memo obsoletes
   RFC 2665 and mention 10Gig.

3. Add reference in Overview to 802.3ae.

4. Section 3.2.3: Is the last paragraph still true?  There does
   not seem to have been any progress on the interface test MIB
   in the ifmib WG in the last few years.

5. Do we need to expand 3.2.1 on the layering model?  For example,
   should we say anything about link aggregation?  How we choose to
   handle WIS may also affect this section (more on this later).

6. 3.2.7 mapping of ifmib objects: Update ifSpeed and ifHighSpeed to
   reflect 10Gig.  Also, the ifInErrors text is incorrect.  Since
   symbol errors are also counted as FCS errors, the text will
   result in symbol errors being double counted in ifInErrors.
   Fix is to remove dot3StatsSymbolErrors from this list.

7. Section 3.5: Need to mention disposition of new MAC objects from
   802.3ae.  These objects are aRateControlAbility,
   aRateControlStatus, and aStretchRatio.  My inclination is to NOT
   define MIB objects for these attributes.  If an ethernet interface
   doesn't support 10Gig Wan, aRateControlAbility will always be false,
   and aRateControlStatus and aStretchRatio will always be ignored.
   If it is a WAN interface, aRateControlAbility will be true,
   aRateControlStatus must be enabled, and aStretchRatio must be 104.
   I don't think we really want a network admin to be playing with
   these values.

8. Update DEFINITION of dot3StatsAlignmentErrors to replace:
     "This counter does not increment for 8-bit wide group encoding
     schemes."
   with:
     "This counter does not increment for group encoding schemes
      encoding greater than 4 bits per group."

9. Insert the following paragraph in the DESCRIPTION clause of
   dot3StatsSymbolErrors:
     "For operation at 10 Gb/s, it is a count of the number of
      times the receiving media is non-idle (a carrier event) for
      a period of time equal to or greater than minFrameSize, and
      during which there was at least one occurrence of an event
      that causes the PHY to indicate ReceiveError on the XGMII."

10. Add references to 802.3ae and RFC 2665 (as well as any changes
    to update to latest MIB boilerplate.  We also may need to update
    references to base SNMP docs if the SNMPv3 WG finishes their
    updates before we do.

11. Add Changes since 2665 to Change Log appendix.

12. Update Chair's contact info and WG email address.

Note that none of the above add or substantially change any MIB
objects, so should not be a barrier to advancement.

John

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

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 11 Mar 2001 16:53:20 -0500

>   Fix is to remove dot3StatsSymbolErrors from this list.

        Note that 10 Gig Ethernet actually has 2 different
data rates, depending on whether the SONET-compatible PHY
is in use.  Normal 10 Gig Ethernet is really 10 Gbps,
whereas SONET-compatible PHY 10 Gig Ethernet is ~9.5 Gbps.
Both of these should probably be supported, but as distinct
values, IMHO.

>   I don't think we really want a network admin to be playing with

        Perhaps include them, but make them read-only objects ?

Ran
[email-masked]

---

From: John Flick <[email-masked]>
Date: Mon, 12 Mar 2001 12:42:08 -0800

> Both of these should probably be supported, but as distinct

Yes, the ifHighSpeed should represent the line rate, so we would
report 10,000 for a LAN PHY, and 9,580 for a WAN PHY (ifHighSpeed
is in Mbits/sec).  ifSpeed would report 4,294,967,295 (its maximum
value) as defined in RFC 2863.

>         Perhaps include them, but make them read-only objects ?

The values in use should be implicit in the ifMauType (or ifSpeed,
for that matter).  If we add these objects, it would be unlikely we
could advance this document to Draft Standard.  If the objects add
value, then I am all for cycling at Proposed - correctness is more
important than standards track status.  However, If the new objects
don't add value, I don't see the reason to add them and force a cycle
at Proposed.  I can be easily swayed by an argument that indicates what
value these new objects would add.

John

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 12 Mar 2001 17:39:48 -0500

>value these new objects would add.

        Most operations folks don't have the IEEE 802 specs
in front of them or available to them in a handy way, so relying
on the implicit values gets in the way of actually managing
the network.

        From a network ops perspective, it would be useful
to have these objects as read-only so that the folks in the
NOC can easily figure this stuff out when troubleshooting
the network.

        If they really are implicit and if they were specified
as read-only MIB objects, then implementing these new objects 
ought to be quite trivial for vendors.

        I wish I understood the rules for MIB advancement,
but I don't.  Several folks have tried to educate me, but
so far I haven't really understood the rules as explained to me.
Sigh.

Thanks,

Ran
[email-masked]