Re: partial comments on section 5 of ibif

Hi Randy,

At 10:26 AM 10/9/2003 -0700, Randy Presuhn wrote:

<snip>

> > >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,
>
>If by "left as defined" you mean what's in RFC 2863, I agree.
>If you mean what's in draft-ietf-ipoib-ibif-mib-05.txt, then I disagree.

I meant left as defined in draft-ietf-ipoib-ibif-mib-05.txt.

>If multicast is defined for this interface type, it seems  clear
>that ifInMulticastPkts must be incremented each time such
>a packet is delivered to a higher sub-layer.  Same reasoning
>goes for the Out and HC counters.

Since IBTA did not define counters for multicast, it is not possible to 
provide this data always in ifInMulticastPkts, and as the ibif draft 
suggested, this counter should be set to 0. If a device vendor provides a 
proprietary (non-IBTA standard) counter for multicast, it should be 
reflected in ifInMulticastPkts.

This is why I suggested that what is defined currently is right.


> >   as it is possible for implementations to provide proprietary counters
> > which count multicast packets.
>...
>
>Putting this information in a vendor-specific MIB, and mandating an
>incorrect implementation of the IF-MIB standard, would seem to me
>to be the worst possible solution.

This was not what I said above. I said that if the device vendor provides a 
proprietary (non-IBTA standard) mechanism for the IF-MIB implementor (it is 
possible that these are different entities) to obtain the multicast 
specific counters, then it should be reflected in ifInMulticastPkts.

-Vandana

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