Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibif-mib-00.txt

From: [email-masked]
Date: Fri, 12 Oct 2001 07:10:14 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over InfiniBand Working Group of the IETF.

	Title		: Definitions of Managed Objects Infiniband Interface 
                          Type
	Author(s)	: B. Anderson
	Filename	: draft-ietf-ipoib-ibif-mib-00.txt
	Pages		: 21
	Date		: 11-Oct-01
	
InfiniBand Architecture (IBA) specifies a high speed, channel
based, switched fabric architecture to deliver scalable
performance in data centers.
This memo defines a portion of Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing IBA defined 
Infiniband interfaces.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibif-mib-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipoib-ibif-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipoib-ibif-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Paceline Systems" <[email-masked]>
Date: Tue, 30 Oct 2001 10:26:47 -0500

Hi Bill,

I have read over the latest version of the InfiniBand Interface MIB and have
some comments. The main ones relate to issues brought up previously in the
area of optional InfiniBand (IBA) counters being made mandatory in this MIB
and in the compliance/conformance area of this MIB.

Perhaps I do not understand the compliance/conformance statements in the
MIB, but I can't tell whether ibIfStatGroup is mandatory or optional. This
group does contain the following optional InfiniBand counters:
PortRcvErrDetails.PortLocalPhysicalErrors (ibIfPortStatLocalPhyErrs),
PortRcvErrDetails.PortMalformedPacketErrors (ibIfPortStatMalPktErrs),
PortXmitDiscardDetails.PortInactiveDiscards (ibIfPortStatInactDiscards),
PortXmitDiscardDetails.PortNeighborMTUDiscards
(ibIfPortStatNeighMTUDiscards), PortXmitDiscardDetails.
PortSwLifetimeLimitDiscards (ibIfPortStateSwLifetimeDiscards), and
PortXmitDiscardDetails.PortSwHOQLimitDiscards
(ibIfPortStatHOQLifetimeDiscards). Regardless of whether this group is
mandatory or optional, I think there is an issue here as it contains a mix
of both mandatory and optional IBA counters.

According to RFC 2580 "Conformance Statements for SMIv2", a group can either
be mandatory or optional.
p. 15 5.4.1. Mapping of the MANDATORY-GROUPS clause
The MANDATORY-GROUPS clause, which need not be present, names the one or
more object or notification groups within the correspondent MIB module which
are unconditionally mandatory for implementation. If an agent claims
compliance to the MIB module, then it must implement each and every object
and notification within each conformance group listed. That is, if an agent
returns a noSuchObject exception in response to a management protocol get
operation [4] for any object within any mandatory conformance group for
every possible MIB view, or if the agent cannot generate each notification
listed in any conformance group under the appropriate circumstances, then
that agent is not a conformant implementation of the MIB module.
5.4.2. Mapping of the GROUP clause
The GROUP clause, which need not be present, is repeatedly used to name each
object and notification group which is conditionally mandatory for
compliance to the MIB module. The GROUP clause can also be used to name
unconditionally optional groups. A group named in a GROUP clause must be
absent from the correspondent MANDATORY- GROUPS clause. Conditionally
mandatory groups include those which are mandatory only if a particular
protocol is implemented, or only if another group is implemented. A GROUP
clause's DESCRIPTION specifies the conditions under which the group is
conditionally mandatory. A group which is named in neither a
MANDATORY-GROUPS clause nor a GROUP clause, is unconditionally optional for
compliance to the MIB module.

A noSuchObject cannot be returned for an object in a mandatory group.

One alternative is for this group (ibIfStatGroup) to be split into two
groups: a group based on the mandatory IBA counters and another based on the
optional ones. Another, less optimal solution, would be to make that group
optional. Perhaps others can think of other possible solutions. I would
prefer the former (a mandatory and an optional group).

Many of the basic mandatory IF-MIB counters are based on optional IBA
counters as well. I am not sure how to deal with these. ifInOctets is based
on PortCounters.PortRcvData, PortCounters.PortRcvPkts, and
PortFlowCtlCounters.PortRcvFlowPkts. ifInUcastPkts is based on
PortCounters.PortRcvPkts, and PortFlowCtlCounters.PortRcvFlowPkts.
ifOutUcastPkts is based on PortCounters.PortXmitData,
PortCounters.PortXmitPkts, and PortFlowCtlCounters.PortXmitFlowPkts.
ifOutOctets is based on PortCounters.PortXmitData and
PortFlowCtlCounters.PortXmitFlowPkts. I do not think that returning a 0 for
an unsupported IBA counter is IETF conformant.

I think it would be useful to make it clear which IF-MIB counters are based
on a mandatory or optional or
combination of mandatory and optional IBA counters to make the above
extremely clear.

The remainder are smaller issues:

p.4 2.0 second paragraph states that:
"The functions performed by IBA Subnet Manager(SM) and Subnet
Management Agents (SMA) in the managed devices include but are not limited
to device configuration, fault detection, performance monitoring and device
configuration persistence."

It is a collection of managers and agents which accomplish the functions
listed. Some of the functions mentioned require more than SM/SMA.

This might be better as something like "The functions performed by
the InfiniBand managers and agents, including the IBA Subnet Manager(SM) and
Subnet Management Agents (SMA) in the managed devices include but are not
limited to device configuration, fault detection, performance monitoring and
device configuration persistence."

p.8-9 ifInMulticastPkts, ifOutMulticastPkts, ifHCInMulticastPkts, and
ifHCOutMulticastPkts
indicate something like "Always 0 unless proprietary counters implemented."

p.10 2.3 (typos in two places) statics should be statistics

p.10 2.4 states "Note that the mapping does not fully address the handling
of IF-MIB
Multicast related objects since no equivalent IBA counters are currently
defined."
Lates, p. 13 more accurately states "Again it should be noted that since no
Multicast
counters are defined by the IBA specification they are not covered here."

2.4 should state something like "Note that since multicast counters have not
been
defined by the IBA specification, IF-MIB multicast counters should be set to
0
(in the absence of any proprietary IBA multicast counters). Also, based on
the
IBA counter definitions, multicast (packets and bytes) will be part of the
IF-MIB
unicast counters."

p.10-11 2.4 Since PortCounters.PortXmitData, PortCounters.PortRcvData,
PortCounters.PortXmitPkts, and PortCounters.PortRcvPkts are optional and all
return 0 if not implemented, ifInOctets, ifInUcastPkts,
ifOutOctets, and ifOutUcastPkts may be 0 as a result of this. [IETF
conformance issue with this].

p.11 (typo) IF-MIB:ibIfPortStatLinkIntergrityErrs s.b.
ibIfPortStatLinkIntegrityErrs

p.18 Not sure the conformance syntax is proper. Should it be OBJECT-GROUP
rather than OBJECT-TYPE ?

Thanks.

-- Hal Rosenstock
   Paceline Systems
   [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 12, 2001 7:10 AM
Cc: [email-masked]
Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibif-mib-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP over InfiniBand Working Group of the
IETF.

Send a message to:
	[email-masked].
In the body type:

_______________________________________________
IPoverIB mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipoverib

---

From: "Bill Anderson" <[email-masked]>
Date: Wed, 31 Oct 2001 09:32:15 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Paceline Systems
Sent: Tuesday, October 30, 2001 10:27 AM
To: [email-masked]
Cc: 'Wijnen, Bert (Bert)'
Subject: RE: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibif-mib-00.txt

Hi Bill,

[Bill A Comment]
  My intent was to make the whole group optional, but I like the idea of
breaking it up into two groups. One Mandatory - One optional.
[end]

[Bill A comment]
  I think that the IF-MIB actually says you should return NO-SUCH-OBJECT
[end]

[Bill A comment]
Maybe we can just put an "*" next to optional quantities in the case
diagram?
[end]

[Bill A comment]
  Same as above I guess you would return NO-SUCH-OBJECT
[end]

[Bill A comment]
Ok
[end]

[Bill A comment]
it looks broke to me too.
[end]

Thanks.

-- Hal Rosenstock
   Paceline Systems
   [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 12, 2001 7:10 AM
Cc: [email-masked]
Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ibif-mib-00.txt

Send a message to:
	[email-masked].
In the body type: