[Ipoverib] IBCA mib comments
bill@strahm.net Fri, 16 September 2005 03:47 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG7Bx-0006dM-4D; Thu, 15 Sep 2005 23:47:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG7Bv-0006dH-0g for ipoverib@megatron.ietf.org; Thu, 15 Sep 2005 23:47:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07251 for <ipoverib@ietf.org>; Thu, 15 Sep 2005 23:47:07 -0400 (EDT)
From: bill@strahm.net
Received: from sub25-177.member.dsl-only.net ([63.105.25.177] helo=strahm.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG7Gp-0007Y2-Rp for ipoverib@ietf.org; Thu, 15 Sep 2005 23:52:17 -0400
Received: (qmail 29582 invoked by uid 514); 15 Sep 2005 20:46:55 -0700
Received: from 127.0.0.1 by homesrv.strahm.net (envelope-from <bill@strahm.net>, uid 512) with qmail-scanner-1.25-st-qms (clamdscan: 0.86.1/974. spamassassin: 3.0.4. perlscan: 1.25-st-qms. Clear:RC:1(127.0.0.1):. Processed in 0.053939 secs); 16 Sep 2005 03:46:55 -0000
X-Antivirus-Strahm.net-Mail-From: bill@strahm.net via homesrv.strahm.net
X-Antivirus-Strahm.net: 1.25-st-qms (Clear:RC:1(127.0.0.1):. Processed in 0.053939 secs Process 29575)
Received: from localhost (HELO mail2.strahm.net) (bill@strahm.net@127.0.0.1) by strahm.net with SMTP; 15 Sep 2005 20:46:55 -0700
Received: from 192.168.1.1 (SquirrelMail authenticated user bill@strahm.net) by mail2.strahm.net with HTTP; Thu, 15 Sep 2005 20:46:55 -0700 (PDT)
Message-ID: <3960.192.168.1.1.1126842415.squirrel@mail2.strahm.net>
In-Reply-To: <6AB138A2AB8C8E4A98B9C0C3D52670E306A264@mtlexch01.mtl.com>
References: <6AB138A2AB8C8E4A98B9C0C3D52670E306A264@mtlexch01.mtl.com>
Date: Thu, 15 Sep 2005 20:46:55 -0700
To: "'ipoverib@ietf.org'" <ipoverib@ietf.org>, Amit Krig <amitk@mellanox.co.il>
User-Agent: SquirrelMail/1.4.5
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 8bit
Cc:
Subject: [Ipoverib] IBCA mib comments
X-BeenThere: ipoverib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipoverib@ietf.org>
List-Help: <mailto:ipoverib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=subscribe>
Sender: ipoverib-bounces@ietf.org
Errors-To: ipoverib-bounces@ietf.org
Some comments from me personally (WG Chair hat off the head sitting way across the desk) inline Bill > Hi all, > > I am Ali Ayoub, and I work for Mellanox technologies. > Welcome to the group. > I've started implementing the IBCA MIB module, and I would like to share a > few comments regarding the MIB definition as it appears in > draft-ietf-ipoib-channel-adapter-mib-07.txt: > Great - glad to hear some of the MIBs are being implemented. > 1. The MIB definition was written according to tables 259 & 260 (Sections > 17.2.1, 17.2.2) of the IB spec, v1 r1.1. However, it does not include > important info from section 11.2.1.2 such as: vendor specific information, > vendor ID, vendor part ID, HW/FW version. This information is important > (from network administrator's point of view). > I would assume such things would belong in the enterprise mib for the particular vendor. However if there are specific GENERIC things that belong in this MIB - write a object up, submit it here and after we look it over Sean can add it into an updated draft > 2. The MIB is almost entirely static in the sense that all the info > supplied > is determined at driver loading, and does not get changed until the next > reboot. An exception to this is "ibCaInterpacketDelayValue" which is > dynamic > according to the current network topology. I suggest to remove this > attribute from the mib to keep it all static (this affects the > implementation data structure too and saves unnecessary queries). > Dynamic info (such as port state) should be moved to the SMA MIB, and the > IBCA MIB definition should become completely static. > Hate to say it... but this seems like an implementation issue. But will take this under advisement... any other implementors out there feel the same way ? > 3. What is the ibCaSupportsSubnetManager object? I couldn't find it in > table > 260 as mentioned there. It is by any chance the ibCa*Is*SubnetManager? > Then > the right place for this object would also be in the SMA MIB. > Sean ? I need to go look at this one closer - but Sean, what was your intention _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib