RE: partial comments on section 5 of ibif

Randy,  

For the multicast in packets, as I am remembering my IBTA days - IBTA
doesn't really have multicast - just broadcast, which is subtly
different.  I do not believe there are IBTA counters to monitor what
this OID maps into.

For link packet/octet counters...

IBTA defines a 32 bit counter of 4byte words (in otherwords a 34 bit
counter) for physical link packets.

So the best you can do is get a 34 bit count of octets/packets out for a
8Gbit link (yes, I have been complaining about this for 3 years now)...

Unless you implement a software process that querries the hardware every
10 seconds, and keeps a 64 bit counter - there is no way of keeping the
64 bit counters (yes they can roll every 16 seconds)

Bill

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Randy Presuhn
Sent: Wednesday, October 08, 2003 3:50 PM
To: [email protected]
Cc: Bert Wijnen
Subject: [Ipoverib] partial comments on section 5 of ibif


Hi -

Here are my partial review comments on sections 5 and 6 of
draft-ietf-ipoib-ibif-mib-05.txt;  I need some clarification before I go
further in the review.

First, however,a global comment:

Typographical:
The document is inconsistent in use of spaces after period.
The guidelines are clear that there should be TWO spaces
after a period at the end of a sentence.  I recommend fixing this sooner
rather than later, as it can be a very annoying source of deltas to be
reconciled during the AUTH48 period.

Specific comments:
Typographical:

page 4: "portions there of" -> "portions thereof"
page 4: '"physical lanes" .' -> '"physical lanes."'
        (I won't object to the more logical but less correct
        '"physical lanes".')

page 4: this line (also appears elsewhere) looks really odd:
       infiniband(ianaIfType 199)   -- Assigned by IANA

wouldn't it be simpler to just say "IANA has assigned
the ifType value 199 to identify Infiniband media."?
similar changes would be appropriate in the other locations where this
appears.

page 4: bottom: replace ianaIfType-TBD etc. with
       "199"

page 5: "over constraining" -> "over-constraining"

page 5, 5.2.4: "address," -> "address"

page 6 "in affect" -> "in effect"

consistency: section 5.0 says "Thus no exposure to per physical lane
information is defined.", yet 5.2.6 does just that for ifDescr, though
very loosely.

page 6/7: ifSpeed: "should" -> "MUST", and "must" -> "MUST"

page 7: ifAdminStatus: "should" -> "SHOULD"

page 7: ifInOctets: "should" -> "MUST"

pages 7-8: ifInUnkownProtos, ifInMulticastPkts, ifOutMulticastPkts,
ifInBroadcastPkts, ifOutBroadcastPkts, ifHCINBroadcastPkts,
ifHCOutBroadcastPkts, etc.:  The "always 0" isn't appropriate for a
counter type.  It should simply say that they never change because these
events can't occur on this medium.  (If these events *can* occur, then
there's a more serious problem here. For example, I'd be really
surprised if an Unknown Protocol is
impossible.)

page 8: ifOutOctets: "should" -> "MUST"

page 8:  I'm puzzled by the last sentence of this description. Could
someone explain to me why the implementation of a proprietary counter
would affect the behaviour of this counter?
      ifInMulticastPkts          Refer to [RFC2863]. Note, that this
                                 does not include link packets, since
                                 link control packets are consumed by
                                 the interface layer and are not passed
                                 to any higher layer protocol. Always 0
                                 unless proprietary counters are
                                 implemented.

Ditto ifOutMulticastPkts

Page 8:  Something sounds seriously broken here:
      ifHCInUcastPkts            64-bit versions of packet counters.
      ifHCInMulticastPkts        Required for interfaces
      ifHCOutUcastPkts           that are capable of operating at
      ifHCOutMulticastPkts       640Mbit/sec or faster, even if the
                                 interface is currently operating at
                                 less than 640Mbit/sec. Always 0
                                 unless proprietary counters
                                 implemented.

Before I go further into a tarpit of misunderstanding, could someone
tell me what's going on with these objects?

Randy




_______________________________________________
IPoverIB mailing list
[email protected] https://www1.ietf.org/mailman/listinfo/ipoverib