[openib-general] [RFC] OpenSM Interactive Console

Wed Oct 26 23:03:57 PDT 2005

Yes this MIB needs some cleanup.
I would love to hear from the community some feedback regarding SM MIB
usefulness.

In the past we did not get any push for interactive SM or online
configurable SM so I did not see any reason to work on it. 

I do not think it is a huge task to make SM MIB work with OpenSM. At least
not the 90% of it that I glanced through.

Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL

> -----Original Message-----
> From: Hal Rosenstock [mailto:halr at voltaire.com]
> Sent: Wednesday, October 26, 2005 7:44 PM
> To: Eitan Zahavi
> Cc: Troy Benjegerdes; openib-general at openib.org
> Subject: RE: [openib-general] [RFC] OpenSM Interactive Console
> 
> Hi Eitan,
> 
> I sit corrected. There are R/W parameters in the SM MIB as you indicate. I
was
> thinking of all the other IPoIB MIBs. It's been a while since I looked at
the SM MIB.
> 
> Also, the SM MIB (draft-ietf-ipoib-subnet-manager-mib-00) expired a while
ago. At a
> minimum, it needs to be dusted off. That would include updating it for IBA
1.2.
> 
> -- Hal
> 
> ________________________________
> 
> From: Eitan Zahavi [mailto:eitan at mellanox.co.il]
> Sent: Tue 10/25/2005 5:19 AM
> To: Hal Rosenstock
> Cc: Troy Benjegerdes; openib-general at openib.org
> Subject: Re: [openib-general] [RFC] OpenSM Interactive Console
> 
> 
> 
> Hal Rosenstock wrote:
> > On Mon, 2005-10-24 at 14:38, Eitan Zahavi wrote:
> >
> >>Hal Rosenstock wrote:
> >>
> >>>On Mon, 2005-10-24 at 03:08, Eitan Zahavi wrote:
> >>>
> >>>
> >>>>I would suggest to use SNMP for the tasks below. IETF IPoIB group
> >
> > has
> >
> >>>>defined an SNMP MIB that can support the required functionality
> >
> > below.
> >
> >>>
> >>>The IETF SNMP MIBs are one way of presenting the information to the
> >>>outside world. There are other possible management interfaces. The
> >
> > SNMP
> >
> >>>MIB instrumentation would need to use lower layer APIs to get this
> >>>information out of the SM.
> >>
> >>Yes but the IETF SM MIB is the only one that is close to a standard
> >
> > way.
> >
> >>It does not require low level interface if it will integrate into the
> >
> > OpenSM code.
> >
> >>One way to do it is buy extending OpenSM with an AgentX interface.
> >>
> >>IMO one clear advantage of using SNMP for SM integration is that the
> >
> > code will work with any SM that is IETF compliant.
> >
> >>Also if you want to write a "client server" type of application on top
> >
> > of an SM you
> >
> >>can either stick to sending MADs which translate into SA client based
> >
> > application or
> >
> >>you better stay with some known protocol for management (like SNMP)
> >
> > and not develop yet another protocol for
> >
> >>doing exactly the same things as SNMP already supports.
> >
> >
> > There are limitations in the SNMP MIBs. One is that they are RO so they
> > are more for monitoring. Also, many environments do not use SNMP. It is
> > unclear how much of a requirement it is to manage any SM or how many
> > other SMs support the SM MIB. (There are other IB associated MIBs too).
> 
> SNMP MIBs are certainly not just RO a simple example from the SM MIB:
>    ibSmPortInfoLMC           OBJECT-TYPE
>        SYNTAX              Unsigned32(0..7)
>        MAX-ACCESS          read-write
>        STATUS              current
>        DESCRIPTION
>           "LID mask for multipath support.  User should take extra caution
>           when setting this value, since any change will effect packet
>           routing."
>        ::= { ibSmPortInfoEntry 19 }
> 
> 
> I agree that it is possible that currently no SM is supporting the SM MIB.
> But it does make sense to have ALL of the them support it. Such that they
can
> be activated/deactivated and configured in the manner.
> 
> Most unix distributions and windows box have standard SNMP agent and
client
> included in them
> So it does not take more then simple bash or C code to interact with the
SM if it
> supports SNMP.
> 
> >
> >
> >>>>Everything but the dynamic partitioning (OpenSM does not have
> >>>>partition manager to this moment)
> >>>
> >>>
> >>>What Troy meant by partitioning is not necessarily IB partitioning.
> >>
> >>How are you sure about that? Troy - please comment.
> >
> >
> > I think you missed an email on this.
> >
> >
> >>>>and forwarding of Performance
> >>>>Monitoring traps (which are generated by the PM) can be done through
> >>>>osmsh or through SA client today.
> >>>
> >>>
> >>>What PerfMgr are you referring to ?
> >>
> >>No specific one. But the specification does not require the SM too.
> >
> >
> > Huh ? What spec ? An SM is required in a subnet. There is no subnet
> > without this. There is a subnet without a PerfMgr.
> Yes its a typo I meant PM. SM is a requirement. You know I did not mean
that.
> >
> >
> >>For various reasons (like load) it might make more sense to have the
> >
> > PM distributed.
> >
> > Sure. Also, the PerfMgr need not be colocated with the SM anyhow.
> >
> >
> >>Anyway, my point is that the SM is not the owner of PM trap reporting.
> >
> > It is the PM that
> >
> >>should support Reporting (I.e  InformInfo registration and Trap
> >
> > forwarding) for PM traps.
> >
> >>But the spec does not define such traps anyway.
> >
> >
> > My point was that the PerfMgr is beyond the IBA spec. It is only the PMA
> > that is defined and has no traps so these will all need synthesis by the
> > PerfMgr.
> Agree.
> >
> > -- Hal
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051027/5d53660e/attachment.html>