Subject: RE: [Ipoverib] Meeting minutes from the 12/10/01 meeting As ASCII text

From: "Bill Strahm" <[email-masked]>
Date: Fri, 4 Jan 2002 20:37:51 -0800

Two requests for this... so here are minutes from the Monday meeting in
ASCII text.

Thanks
Bill

Minutes from IPoIB meeting on 12/10/01.  Reported by Jim Pinkerton -
Microsoft Corp.

Bill reviewed the agenda.

Shawn has taken over from the original author for the IPoIB MIBS.
IANA has defined an IBMIB as experimental 117.The IB MIBs need to be
assigned hierarchically from there.

Bill Strahm asked whether IANA object Ids can be informally assigned or does
each need to go to IANA. Bill recommends Shawn be the designee for assigning
IANA MIB numbers. There were no objections.

Bill summarizes the IPoIB MIBS that are required:
	- Bill comments that the sample counters are not useful.
	- Channel adapter MIB
	- specify  baseboard management MIB
	- device and switch MIBs

Bill asked that the textual conventions be pulled out separately. This would
allow the conventions to be defined independently of the MIBs. Bill walked
briefly through the high level textual conventions to give a flavor for the
approach. Comment from the floor was that the language in RFC2578 is
"SHOULD" language, so if there is a good reason to do zero-based indexing
you can. The concern is that using a one-based offset doesn't match the
hardware. Thus zero-based indexing is now deemed "acceptable".

Bill then walked through the subnet interface MIB. Talked about the
iblfStatGroup and iblfVLTrafficGroup and the types of stats in each. Textual
convention MIB was removed from this document. Authors have transitioned on
this doc. Bill then walked through the main differences in the update to
the -00 version. Open issues:

- should 32-bit error counters be made 64-bit (counter wrap frequency
analysis)? Jeff Young claims that software stacks are implementing 64 bit
counters. Point was made that the analysis could be led by what is the
fastest rate that these counters can increment? RFC2578 has some insight
into this.

- consensus question on this mib - they are concerned about the level of
review that has occurred. Bill is not ready to call consensus on this
document because of the level of review. Bill believes the document is
close, but needs additional review.

Carl Yang presented the IB Subnet Management MIB.

He first reviewed the possible roles that SNMP can play in managing an IB
network. Missed first option. Second option is to enable device management
over SNMP by allowing the subnet manager to change the values. But not all
variables are defined through the current MIB (e.g. multicast group creation
and deletion). Third is to enable SNMP to configure and monitor IB subnets
by communicating with the SM. The third approach is the primary focus of
this MIB. Point was made that with the SMA MIB, only one variable is
actually writable.

One of the main differences between the SM MIB and the SMA MIB is that the
SMA only deals with one value of a variable whereas the SM MIB deals with a
series of values. There was some discussion of how to document this. One
suggestion was to document the MIB for the SMA, but use an index and only
allow the SMA to use index zero, for example. Then the SM can reference
this.

There were some questions on the exact transport mechanism. Does the SM
proxy this. Bill commented that he'd like to enable a range of
implementations. There was concern that there not be a requirement for an IB
out-of-band management solution. Bill pointed out that there are a variety
of solutions possible - from doing it on top of UDP on IB, to tunneled, to
many other solutions.

There is some concern about whether the management key should be exposed or
should it be a secret? Bill claims since the management key is sent in the
clear, it's not a crypto key, and thus it's okay to expose it. Bill asks for
consensus. Jeff Young was concerned. There was a proposal that the SNMP
interface could be to have the variable read/write, where the read always
returns a zero. Bill pointed out that it's fairly easy to snoop the value,
thus not clear it needs to be protected. Another statement pointed out that
if SNMP is used over the internet and this really is a sensitive value,
maybe it shouldn't be visible by SNMP. Jeff said that clearly there needs to
be a mechanism to set the M_KEY. Not clear that it needs to be through SNMP.

On the configuration table, the number for row status - what is the
persistence of this information? Walked through the three possibilities - no
persistence, persistence, and allowing another variable to control the
persistence. Bill asked the crowd on why we would want SM state to not be
persistent across. No one came up with a reason or objected (after some
discussion and a walk through of a few scenarios).

Carl continued to do a brief overview of the ID. Comment Switch Info
PortStateChange should be a Boolean - only one value is currently defined.
Bill asked whether exposing P_Keys is a problem. Jeff Young said he has the
opposite opinion. They'll take it off line.

There is a problem with the trap. <insert text here>. See RFC2576.

Next steps
	- modify to use IB MIB textual convention
	- can we consildate SMA MIAB and SM MIB?
	-	- some MIBS are identical, other than their index
	- add missing MIBs
		- ServiceRecord, LinkRecord, and RenageRecord
	- Security consdertions
	- more trap definitions
	- compliance statements
Bill comments that because of the outstanding issues, there needs to be at
least one more draft. This draft is currently an individual contribution.
Bill's concern is whether this MIB could be collapsed with the next MIB
(SMA) being presented (from Bill Swortwood).

Bill Strahm presented Bill Swortwood's SMA proposal.

This is a working group item. Next steps are:
	- creation of compliance/required/optional groups
		- HCAs normally do not need wswitch groups
	- Addition of some references
	- <other stuff>

Point was made that this MIB has the same problem around TRAPs as the last
one.
Bill points out that this does not allow management - it allows monitoring
the network because you can't set the values of the variables.

Question was asked why you wouldn't just do this through the SA? It was
pointed out that there was really two proposals on the table - Bill's
proposal and Carl's proposal. Bill's addresses the SMA, Carl's addresses the
SA and SM.

Bill outlined three options - keep it as it is, single MIB that has
compliance statements separately for SM and SMA, third is to have a single
SMA MIB, with an SM MIB that includes the SMA and extends it for SM unique
issues.  A fourth option is to leverage the existing IB Management
infrastructure to the SA and map that to SNMP.

Bill Strahm presented Bill Swortwood's Device management MIB.

Bill overviews the proposal. Focused on monitoring hosts with IB device
management agents. It is missing baseboard management.

Next steps:
	- Creation of compliance statements
	- Addition of some references
	- Any other rational changes

Bill Strahm presented Connection MIB.

This is just an initial draft. Missing security consideration section and
need better explanatory text. The purpose is to model IB connections, but
this is not directly modeled after connection manager.

The point was made that it should be either an "all or none" access to
sensitive tables. A partial controlled access is much more complex.

Questions:
	- Objects that aren't in the IB spec
	- Is this a WG item
	- Does this cover the WG Item for Channel adapter MIB - should we  rename
the WG item?

Bill stated his opinion that he'd prefer to keep the separate MIBs separate
because it allows focused discussion and focused iteration. It also allows
the initial MIBs to get out to last call faster.

There was a proposal to have an interim meeting co-located with the next
IBTA management-working group to get better attendance. It was noted that
the management-working group is currently meeting monthly. Another
possibility is to request the IBTA management-working group to co-locate at
the next IETF. Bill will formally ask the Management co-chairs to work this
out with him.

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 1:25 PM
To: Bill Strahm
Subject: Re: [Ipoverib] Meeting minutes from the 12/10/01 meeting

Bill,

Do you have the minutes in the form of plain text instead of a word
document?
Much easier for me to read.

  Erik

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