Subject: [Ipoverib] partial comments on section 5 of ibif

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 15:50:27 -0700

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-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: "bill" <[email-masked]>
Date: Wed, 8 Oct 2003 16:20:50 -0700

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-masked] [mailto:[email-masked]] On Behalf
Of Randy Presuhn
Sent: Wednesday, October 08, 2003 3:50 PM
To: [email-masked]
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.

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:

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.

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.

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:  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

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-masked] https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 17:33:59 -0700

Hi -

> From: "bill" <[email-masked]>
> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Cc: "'Bert Wijnen'" <[email-masked]>
> Sent: Wednesday, October 08, 2003 4:20 PM
> Subject: RE: [Ipoverib] partial comments on section 5 of ibif
...
> different.  I do not believe there are IBTA counters to monitor what

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."

> 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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 17:37:06 -0700

Hi -

Just a bit more on this one...

...
...

Based on Bill Strahm's clarification, I think it would make sense
to get rid of "unless proprietary counters implemented", since
it's irrelevant to the behaviour of these objects and confusing
to non-experts like me.

Randy

---

From: Vandana Rao <[email-masked]>
Date: Thu, 09 Oct 2003 08:11:11 -0700

>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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Oct 2003 10:26:05 -0700

Hi -

> From: "Vandana Rao" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Thursday, October 09, 2003 8:11 AM
> Subject: Re: [Ipoverib] partial comments on section 5 of ibif
...
> 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.

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.

...

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.

Randy

---

From: Vandana Rao <[email-masked]>
Date: Thu, 09 Oct 2003 12:17:04 -0700

Hi Randy,

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

<snip>

>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.

>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.

>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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Oct 2003 13:12:22 -0700

Hi -

> Sent: Thursday, October 09, 2003 12:17 PM
...
> 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?

> 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.

> 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.

...

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

---

From: Vandana Rao <[email-masked]>
Date: Thu, 09 Oct 2003 14:14:16 -0700

Hi Randy,
>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.

>implementation.  I can't condone language in the ibif i-d to let them

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Oct 2003 14:49:48 -0700

Hi -

> Sent: Thursday, October 09, 2003 2:14 PM
...
...

If managed systems do not know when they've processed multicast traffic,
then those systems should not instantiate the multicast-related counters for
those interfaces in the interfaces MIB, and, consequently, their vendors
should not claim they conform to RFC 2863.   This is how this kind of
situation has been handled since the earliest days of SNMP. The ibif
document should specify the *correct* behavior for those counters in
the context of what can happen in the InfiniBand protocol, not any particular
chip's implementation.  This seems simple enough to me.

Randy

---

From: Vandana Rao <[email-masked]>
Date: Thu, 09 Oct 2003 21:15:40 -0700

>chip's implementation.  This seems simple enough to me.

The "correct" behavior for those counters in the context of IB would be to 
be set to 0.
Looking at the ibif draft some more, I think that would be the right choice 
as the draft specifies that the
mcast and unicast packets are counted in the unicast counters as is done in IB.
-Vandana

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Oct 2003 21:45:53 -0700

Hi -

> Sent: Thursday, October 09, 2003 9:15 PM
...
...

That's another problem; thanks for catching it.

We're going in circles here.  I've done my job by informing the WG that
I believe that what's in the ibif -05- i-d isn't going to fly.  You can try to
find someone else to review it, but I'm confident that any other MIB
reviewer will tell you just what I've told you: instantiating a counter
from RFC 2863 and not adhering to the semantics of that object
definition simply isn't an option.  The references in a document to
the various objects in the interfaces MIB are supposed to *elaborate*
on what they mean in the context of a particular interface type, not
contradict them.

Randy

---

From: "bill" <[email-masked]>
Date: Thu, 9 Oct 2003 22:31:01 -0700

Randy, (let me take my WG Chair hat off)

I don't want to disagree with your opinion of many of the interesting
objects that are giving us fits (multicast packet counting)

Let me try to change specification and implementation issues - we should
specify multicast packets in/out whatever.  Then it is up to the
implementation to provide a value for the counter - not implement the
object (NO SUCH INSTANCE, NO SUCH OBJECT for V1) or return 0 - on an
implementation decision.  I realize the IETF does not specify
implementations, or provide conformance testing (This implementations
fully supports RFC X)

Your objections are that we are specifying implementation behavior,
rather than what an ideal specification.  It is then up to the
implementations to implement these counters in some way

Bill
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randy Presuhn
Sent: Thursday, October 09, 2003 9:46 PM
To: [email-masked]
Cc: 'Bert Wijnen'
Subject: Re: [Ipoverib] partial comments on section 5 of ibif

Hi -

...
> The "correct" behavior for those counters in the context of IB would 
> be to be set to 0. Looking at the ibif draft some more, I think that 
> would be the right choice as the draft specifies that the
...

We're going in circles here.  I've done my job by informing the WG that
I believe that what's in the ibif -05- i-d isn't going to fly.  You can
try to find someone else to review it, but I'm confident that any other
MIB reviewer will tell you just what I've told you: instantiating a
counter from RFC 2863 and not adhering to the semantics of that object
definition simply isn't an option.  The references in a document to the
various objects in the interfaces MIB are supposed to *elaborate* on
what they mean in the context of a particular interface type, not
contradict them.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Oct 2003 23:09:30 -0700

Hi -

> To: "'Randy Presuhn'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, October 09, 2003 10:31 PM

> object (NO SUCH INSTANCE, NO SUCH OBJECT for V1)

so far, I am in total agreement with you.

>                                                  or return 0 - on an

No, returning a constant zero is *NOT* an option.  If multicast can happen,
then the choice is between implementing a counter that actually counts, or
not implementing it at all.  A counter that doesn't count the events it is
supposed to count is a bug, with the unfortunate potential of misleading
management systems to draw false conclusions about the network's
operation or performance.

> implementations, or provide conformance testing (This implementations

You're right that we don't do the actual conformance tests.
However, we *do* define what it means to conform to a MIB module.
That's what RFC 2580  is all about.

...

Agreed.  Thanks for restating my point so clearly.

Randy

---

From: "bill" <[email-masked]>
Date: Thu, 9 Oct 2003 23:20:38 -0700

Ok,

Now I REALLY understand what Randy is saying...

I think the answer is that we will specify that we will report 64 bit
octet/packet counters as is required.  We will also specify the
multicast counters.

If an implementation is not capable of reporting these values out - the
implementation can return NOSUCHINSTANCE from snmpv2 and beyond or
NOSUCHOBJECT for v1.  

What are the objections to this - can you please get your objections to
this by the end of Last Call, or this will be concensus.

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randy Presuhn
Sent: Thursday, October 09, 2003 11:10 PM
To: [email-masked]
Subject: Re: [Ipoverib] partial comments on section 5 of ibif

Hi -

> Let me try to change specification and implementation issues - we 
> should specify multicast packets in/out whatever.  Then it is up to 
> the implementation to provide a value for the counter - not implement 
> the object (NO SUCH INSTANCE, NO SUCH OBJECT for V1)

>                                                  or return 0 - on an

No, returning a constant zero is *NOT* an option.  If multicast can
happen, then the choice is between implementing a counter that actually
counts, or not implementing it at all.  A counter that doesn't count the
events it is supposed to count is a bug, with the unfortunate potential
of misleading management systems to draw false conclusions about the
network's operation or performance.

> implementations, or provide conformance testing (This implementations 

You're right that we don't do the actual conformance tests. However, we
*do* define what it means to conform to a MIB module. That's what RFC
2580  is all about.

...

Randy

---

From: Vandana Rao <[email-masked]>
Date: Fri, 10 Oct 2003 09:40:42 -0700

>this by the end of Last Call, or this will be concensus.

As long as we clearly specify that unicast and multicast counters require 
to adhere to the object definitions of RFC 2863
without any exceptions, I'm fine with this. Basically, what we are saying 
here is that for IB implementations all the unicast/multicast counters will 
return  "no support"
-Vandana