Re: partial comments on section 5 of ibif

Hi Randy,
At 01:12 PM 10/9/2003 -0700, Randy Presuhn wrote:
>Hi -
>
> > From: "Vandana Rao" <[email protected]>
> > To: "Randy Presuhn" <[email protected]>; <[email protected]>
> > Cc: "'Bert Wijnen'" <[email protected]>
> > Sent: Thursday, October 09, 2003 12:17 PM
> > Subject: Re: [Ipoverib] partial comments on section 5 of ibif
>...
> > >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
>
>I don't understand the logic here.  If system processes multicast packets,
>it certainly should know that it is doing so.  Whether the IBTA defined such a
>counter is irrelevant, as far as I can see.  What am I missing?

It again boils down to what you mean by system. In IB, the device (h/w) 
does most of the processing
and hence, the system may not be involved in the processing of multicast 
packets. So, if IBTA does not specify such a counter, IB devices may not 
maintain such a counter.

> > 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.
>
>The behaviour of a standard object such as ifInMulticastPkts shouldn't
>vary from vendor to vendor.  If vendor claims they're implementing
>the interfaces MIB and instantiates this object, but doesn't count
>multicast, that vendor is lying, both in the advertising and the
>implementation.  I can't condone language in the ibif i-d to let them
>off the hook.

I'm not sure how this should be addressed then. I do understand your point, 
but there is no way
that we can mandate this on IB devices without obsoleting existing h/w.

-Vandana

> > This is why I suggested that what is defined currently is right.
>
>I simply am not able to read 2863 in a way that would support such
>a practice, and, as a MIB reviewer, believe that defining a counter
>that may or may not count a meaningful protocol event, depending
>on which chipset was used, is contrary to the whole point of writing
>a MIB module in the first place.
>
> > > >   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.
>...
>
>I misunderstood what you (and the document)  meant by "proprietary counters".
>
>The document should not be talking about implementation decisions at that
>level.   Whether a counter is implemented in hardware, firmware, software,
>or some combination is not normally relevant to the MIB definition.  It
>may be helpful, in *non-normative text* to provide implementation hints
>that would alert a developer to IBTA-defined interfaces which can provide
>the basis for a (sub-)agent to maintain the values for various objects, or
>via REFERENCE clauses as a source of further information.
>
>Randy
>
>
>
>_______________________________________________
>IPoverIB mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ipoverib