Subject: [Ipoverib] SMA MIB

From: "Anderson, Bill" <[email-masked]>
Date: Fri, 28 Sep 2001 14:52:24 -0400

Hi Bill
  Great to see your MIB.  This willl save me alot of typing.  A couple
of comments and questions I had follow.  
 
1.  I wonder about the choice of IfIndex for the port related tables.  I
believe we should use something locally defined such as an IBPortIndex
so that we don't break implementations that allow for hot insertion of
modules/interfaces.
It is not uncommon to see a ifTable implemenatation that creates hole in
the IfIndex numbering due to board type changes.
We probably don't want these holes leaking over to the IBA Port number
space.  Vendors would probably want to provide lookup tables to
facilitate mapping between the two index domains.
 
2.  Several of the table such as the Weight table and xxxForwarding
table show the data in a very raw IBA format.
 IMHO I would like to see the data broken out into seperate table rows
based on a user meaningful index.  As an
example I would prefer to see the linear forwarding table something like
the following.  Given that that I would only show entries which had a
valid port (not 0xFF) assigned this approach might actually improve
performance on small to medium size Subnets.
 
3. I think that the P_Key Table needs a second index (a simple integer
n) to allow for Multiple Keys to be assigned to the same port.
 
4. It might be nice to see a Forwarding Error Table which would expose
the IBA defined DLIDMapping, VLMapping, and Looping Errors.
 
Bill A.

   ----------------------------------------------------------- 
   -- Linear Forwarding Table 
   ----------------------------------------------------------- 
   smaLftTable     OBJECT-TYPE 
       SYNTAX      SEQUENCE OF SmaLftTableEntry 
       MAX-ACCESS  not-accessible 
       STATUS      current 
       DESCRIPTION 
          "A tale to contain Linear forwarding table entries." 
       ::= { smaLft  1 } 
    
   smaLftTableEntry OBJECT-TYPE 
       SYNTAX       SmaLftTableEntry 
       MAX-ACCESS   not-accessible 
       STATUS       current 
       DESCRIPTION  
          ""
       INDEX { smaLftTableBlockIndex }  
       ::= { smaLftTable 1} 
    
   SmaLftTableEntry ::= SEQUENCE { 
        LinDestDLID                OCTET STRING, 
        LinForwEgressPort       Integer32
   }  
 
iswLinDestDLID     OBJECT-TYPE
    SYNTAX       OCTET STRING (SIZE(2))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
       "Identifies Destination Local Identifier (DLID) that the
        forwarding entry refers to."
    ::= { smaLftTableEntry 1 }
 
LinForwEgressPort OBJECT-TYPE
    SYNTAX       Integer32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION
       "The port to which packets with the LID corresponding to this
        entry are to be forwarded."
    ::= { smaLftTableEntry 2 }         

Bill Anderson                      [email-masked]
<mailto:[email-masked]> 
InfiniSwitch, Corp.             Phone: (508) 599-6336
134 Flanders Road            www.infiniswitch.com
Westborough, MA 01581  fax:(508) 870-3146 

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

---

From: "Bill Swortwood" <[email-masked]>
Date: Fri, 28 Sep 2001 14:05:10 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Anderson, Bill
Sent: Friday, September 28, 2001 11:52 AM
To: [email-masked]
Cc: Harnedy, Sean
Subject: [Ipoverib] SMA MIB

Hi Bill

[whs] Thanks. I think we have a lot more typing to do, as I am looking
to have all IB management modeled in SNMP.
--

[whs] As I am an admitted SNMP neophyte, I am certainly game for a
better way of doing this.

My local SNMP experts believe that either indexing scheme
can be made to work with hot swap, but we are not dug in on current indexing
position.

--

[whs] Expanding this out to human readable format would make these more
human palatable, certainly. I am not sure that I'd argue that it would
be more efficient than passing all the data as fairly raw data, but that
is not all that important, either. I get your basic point, and agree that
these should be more pre-digested.
--

[whs] A couple of comments on "why I did this the way I did" :

1) To expose or not to expose - there are those in the IBTA who might
have a problem with this instrumentation being exposed. Part of this
is to get that discussion done and over with.

2) The 64 octet string was to hold a vector of pkey assignments that
would be considered a "reasonable maximum" per port. While there is
an architectural 32K limitation, for performance reasons there is an
rational limit of 16-32 of these per port. There are discussions to
cap the upper limit per port.

3) Yes, they are all jammed together in a less desirable format.

It is good to find someone else on the 'expose' camp. I'd just
assume to make this more humanly readable, and drop issue (2).
--

[whs] Were these SMA specific counters, as programmed to the SMI, I would.
Performance management, device management, baseboard management, connection
management agent information I am leaving in their respective classes to
avoid the slippery slope of "why isn't X in your MIB".

cheers -

Bill S.

---------------

cheers,

Bill A.