Re: draft-ietf-ipoib-subnet-manager-mib-00.txt

Hi Cheng,

Thanks for the response. I have some follow ups embedded below.

-- Hal

----- Original Message -----
From: "Cheng Yang" <[email protected]>
To: "Hal Rosenstock" <[email protected]>
Cc: "Edwin Tsang" <[email protected]>; "Carl Yang" <[email protected]>; "Bill
Strahm" <[email protected]>; <[email protected]>
Sent: Wednesday, March 17, 2004 9:00 PM
Subject: Re: [Ipoverib] draft-ietf-ipoib-subnet-manager-mib-00.txt


> Hal,
>
> Sorry for the late reply.  Thank you so much for the valuable input.
> Here are my comments:
>
> Cheng Yang
>
>
> Hal Rosenstock wrote:
>
> >Hi Cheng,
> >
> >Looks good. I have some comments on this MIB:
> >
> >Here are some general comments and questions:
> >
> >It is not just a subnet manager but also subnet administration MIB.
Should
> >it be noted that it includes support for SA as well as SM in the overview
> >(section 4) ?
> >
> >
> Ok, that can be added.  We include some "essential" SA management
> features in this MIB.
>
> >Should Reversible be included in (both) the path and multipath request ?
> >
> >
> It should behave the same as SA operations.  So reversible path should
> be there.
>
> >It appears that service associations are creatable and deletable via SNMP
> >management. Isn't this at odds with IB ?
> >
> >
> As we understand, service associations creation and deletion are being
> managed by out-of-band
> applications instead of IB nodes itself.  The IB spec never specified
> how service assication records are
> being created.  So it's up to the SM/SA to set this thing up to restrict
> the use of ServiceRecord.
> see page 795 of the IB spec v1.1.

OK. I was viewing this in the context of symmetry with IB and forgot about
this. You are correct.

> >Should the ability to create/delete multicast groups/members be supported
by
> >management (proxy) ?
> >
> >
> IB spec here never specified how MC groups are being created.  We'll
> keep this thing open for discussion for now.

MC groups are both created and destroyed (as well as members joining and
leaving) via
the MCMemberRecord. It provides a proxy component for third party (e.g.
management)
effected operations. Based on some of your comments below, exposing this may
be a question
of answering which application(s) require this. Alternatively, it could be
viewed that since
multicast is being exposed, this should be.

>
> >An inform info information group to see what nodes are subscribed to what
> >traps/notices might be useful.
> >
> >
> Do you have an application which can utilize this information?  We are
> not trying to include all management
> elements of SM/SA in the MIB, because it's simply too much.  If you can
> find an application that "requires"
> this information, we can consider adding it.  Otherwise, we hate to
> design/implement something that no one's going
> to use.

This would be useful to a management application (which needs "diagnostic"
visibility into IB).

>
> >Should there be a LEDInfo information group ?
> >
> >
> >
> Same as above.

A management application might want to toggle LEDInfo in order for a
technician to ensure the correct IB device.

> >Despite the current lack of interest, shouldn't the CA SL to VL map
table,
> >Switch SL to VL map table and VL arbitration table be included so this
MIB
> >won't need to be rev'd in the future when these become of interest ?
> >
> >
> Same as above.

While this is not being used now, this may be more important as IB networks
become more highly utilized. This may need to be revisited in time for IB
1.1. It will certainly be important for IB 2.0 (and there will be more to
support).

> >Here are some nits:
> >
> >Should ibSmPortInfoCapMask (p.16,17) isConnectionManagerSupported be
named
> >IsCommunicationManagementSupported ?
> >
> >
> >
> Corrected in next version.
>
> >Should ibSmPortInfoOperVL (p. 23) have a 0 (no change) value ?
> >
> >
> Could you please educate me why this is a fix 0 value?  Maybe I'm
> missing something in the spec.

IB provides for a write only value for a number of components
(PortInfo::OperationalVLs being one of them (p.740 line 16)) to not change
the state so one doesn't need to read then write this component.

>
> >Should valid values for ibSmSwitchInfoLinearFdbCap and
> >ibSmSwitchInfoRandomFdbCap (p. 28) be 0...49151 rather than 0..65535 ?
> >Similarly for ibSmSwitchInfoLinearFdbTop (p. 29)
> >
> >
> >
> Corrected in next version.
>
> >Should valid values for ibSmSwitchInfoMcastFdbCap (p.29) be 0...16383
rather
> >than 0...65535 ?
> >
> >
> >
> Corrected.
>
> >typo comparion should be comparison in ibSmPartitionLastChange (p. 33)
> >
> >
> Corrected.
>
> >Should the description of ibSmPathReqTable (p. 45) say
> >"A table used to list all the path entries that satisfy the path request"
> >rather than
> >"A table used to list all the path entries that satisfy the multi path
> >request"
> >
> >
> >
> Corrected.
>
> >-- Hal
> >
> >----- Original Message -----
> >From: "Cheng Yang" <[email protected]>
> >To: <[email protected]>; <[email protected]>
> >Cc: "Edwin Tsang" <[email protected]>; "Carl Yang" <[email protected]>;
"Bill
> >Strahm" <[email protected]>
> >Sent: Friday, March 05, 2004 1:15 PM
> >Subject: [Ipoverib] draft-ietf-ipoib-subnet-manager-mib-00.txt
> >
> >
> >
> >
> >>Dear Internet-Drafts Administrator,
> >>
> >>Attached is draft-ietf-ipoib-subnet-manager-mib-00.txt as an
> >>IP over IB workgroup submission.
> >>
> >>Please publish it.
> >>
> >>Thank you,
> >>
> >>Cheng Yang
> >>Edwin Tsang
> >>Carl Yang
> >>
> >>
> >>
> >>
> >
> >
> >_______________________________________________
> >IPoverIB mailing list
> >[email protected]
> >https://www1.ietf.org/mailman/listinfo/ipoverib
> >
> >
>
>