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

From: "Arvind Murching" <[email-masked]>
Date: Tue, 16 Oct 2001 14:21:58 -0700

Bill,

Can you explain why the base LID is chosen as the value for
ifPhysAddress? Since the LID is subject to change, it would seem that
the port GID/GUID would have been a more appropriate choice. For
example, an entity that obtained the ifPhysAddress (or for that matter
ifRcvAddressTable) would reasonably expect to send packets using that
ifPhysAddress such that it reaches the desired node. If a LID is chosen,
it is not possible to cater to any such expectations.

Thanks
Arvind Murching

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 12, 2001 4: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.

	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.

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

---

From: "Harnedy, Sean" <[email-masked]>
Date: Wed, 31 Oct 2001 10:09:12 -0500

Hal and Bill,

How about creating two compliances for the implementation. One for basic
compliance, that contains IB Interface counters that are derived from
the mandatory InfiniBand counters (from PortCounters), and a full
compliance that contains IB Interface counters from optional InfiniBand
counters (from PortRcvErrorDetails). The full compliance would also
include the VL Traffic Group. 

Like this:

     --****************************************************************
     -- Compliance Statements
     --****************************************************************

ibIfBasicCompliance MODULE-COMPLIANCE
           STATUS      current
           DESCRIPTION "The basic implementation requirements for
managed 
                        network entities which have Infiniband network
                        interfaces."
            MODULE  -- this module
           -- ibIfStatOptionalPortStatGroup and ibIfVLTrafficGroup are
           -- not required for the basic implementation.
                 MANDATORY-GROUPS { ibIfStatMandatoryPortStatGroup }
     ::= { ibIfCompliances 1 }  

ibIfFullCompliance MODULE-COMPLIANCE
           STATUS      current
           DESCRIPTION "The full implementation requirements for managed

                        network entities which have Infiniband network
                        interfaces."
            MODULE  -- this module
                 MANDATORY-GROUPS { ibIfStatMandatoryPortStatGroup,
                                    ibIfStatOptionalPortStatGroup,
                                    ibIfVLTrafficGroup }
     ::= { ibIfCompliances 2 }  

     --****************************************************************
     -- Units of Conformance
     --****************************************************************

ibIfStatMandatoryPortStatGroup OBJECT-GROUP
    OBJECTS {
       ibIfPortSymbolErrs,
       ibIfPortLinkErrRecovery,
       ibIfPortLinkDowned,
       ibIfPortStatRcvRemPhyErrs,
       ibIfPortStatRcvConstrErrs,
       ibIfPortStatLinkIntergrityErrs,
       ibIfPortStatExcBufOverrunErrs,
       ibIfPortStatVL15Dropped
   }
     STATUS current
     DESCRIPTION
          "Detailed error statistics group for mandatory
Infiniband-based
           Port Statistics counters."
     ::= { ibIfMIBGroups 1 }  

ibIfStatOptionalPortStatGroup OBJECT-GROUP
    OBJECTS {
       ibIfPortStatLocalPhyErrs,
       ibIfPortStatMalPktErrs,
       ibIfPortStatInactDiscards,
       ibIfPortStatNeighMTUDiscards,
       ibIfPortStatSwLifetimeDiscards,
       ibIfPortStatHOQLifetimeDiscards
   }
     STATUS current
     DESCRIPTION
          "Detailed error statistics group for optional Infiniband-based
           Port Statistics counters."
     ::= { ibIfMIBGroups 2 }  

ibIfVLTrafficGroup OBJECT-GROUP
    OBJECTS {
       ibIfVLOutOctets,
       ibIfVLOutPkts,
       ibIfVLInOctets,
       ibIfVLInPkts
   }
     STATUS current
     DESCRIPTION
          "Detailed per VL traffic statistics group"
     ::= { ibIfMIBGroups 3 }  

Thanks,
Sean Harnedy

Principal Software Engineer
InfiniSwitch Corporation.
134 Flanders Road
Westborough, MA 01581.
1-508-599-6388
http://www.infiniswitch.com

-----Original Message-----
From: Paceline Systems [mailto:[email-masked]]
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,

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

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