Re: partial comments on section 5 of ibif

At 05:33 PM 10/8/2003 -0700, Randy Presuhn wrote:
>Hi -
>
> > From: "bill" <[email protected]>
> > To: "'Randy Presuhn'" <[email protected]>; <[email protected]>
> > Cc: "'Bert Wijnen'" <[email protected]>
> > Sent: Wednesday, October 08, 2003 4:20 PM
> > Subject: RE: [Ipoverib] partial comments on section 5 of ibif
>...
> > 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.
>
>OK, so these counters should simply not change because the event
>they would count is physically impossible.  It probably wouldn't hurt
>to say something like "Since multicast is not defined for InifiniBand,
>there is nothing for this counter to count."

IBTA does define multicast , however, there are no IBTA counters defined 
for multicast packets.
I think the description for  ifInMulticastPkts and the other mcast counters 
should be left as defined,
  as it is possible for implementations to provide proprietary counters 
which count multicast packets.

-Vandana

> > 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)
>...
>
>The MIB module shouldn't  specify the implementation mechanism, but since
>the underlying data clearly *is* available, specifying  that these 64-bit
>counters should be zero would be incorrect.  The data rates of this interface
>type and the availability of underlying (34-bit) hardware make it pretty
>clear to me that the 64-bit counters (properly implemented to actually
>*count*  :-) are a MUST.
>
>Thanks for the clarifications, I'll return to grinding through the rest of
>of the document.
>
>Randy
>
>
>
>_______________________________________________
>IPoverIB mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ipoverib