RE: FC Management MIB - proposed changes

["SPASIC,PREDRAG (HP-Roseville,ex1)" <predrag_spasic@hp.com>]

Keith,

My replies are in line. One additional comment
Point 6:
Use Counter64 only if necessary. Counter32 would be the
preferred solution.
-There are no Counter64s in FC standards that we need in the MIB
-Some existing tools have problems with Counter64 and Unsigned64
-No Gauge64 in SMIv2

Predrag

> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Thursday, November 08, 2001 11:44 AM
> To: predrag_spasic@hp.com
> Cc: kzm@cisco.com; ips@ece.cmu.edu
> Subject: Re: FC Management MIB - proposed changes
> 
> 
> Predrag,
> 
> > Point 8:
> > Although there are quite a few issues around zoning management,
> > most of them revolving around perceived inadequate security of
> > SNMP,
> 
> I assume you mean the inadequate security of SNMPv1 and SNMPv2c,
> i.e., nobody perceives that SNMPv3 is insecure, right ??
Yes, SNMPv3 is secure, but not that many implementations.
> 
> > without this information MIB will not be complete. 
> 
> Are you saying that this MIB will not be complete, or that Fibre
> Channel management will not be complete ?
Management, of course.
> 
> > Zoning management is extensively defined in FC-GS3, is specific
> > to FC, and I do not see any reasons to delay this for some point
> > in the future.
> 
> I see several options:
> 
> 1. have the first version of the new FC-Mgmt MIB include Zoning,
> 
> 2. start work on another MIB to address Zoning in parallel with
> working on the first version of the new FC-Mgmt MIB.
> 
> 3. complete the first version (Internet-Draft) of the new FC-Mgmt
> MIB, and defer the addition of Zoning until a second or subsequent
> Internet-Draft of this MIB, but before its WG Last Call.
> 
> 4. defer the start of work on another MIB to address Zoning until
> after completing the first version (Internet-Draft) of the new
> FC-Mgmt MIB.
> 
> 5. finish the new FC-Mgmt MIB, including having it published as an
> RFC, and only then work on extending it to address Zoning.
Agreed.
Carrying over the zoning objects defined in current MIB version is
sufficient as a first step. This would not add any new functionality
and allow us to focus on the MIB structure. (We might want to define 
trap for zoning configuration change, if not already there)
This approach seems fine, but if we decide to make some of the zoning
objects
write- able, it may not be so easy after MIB reaches RFC status. So as long
as you are not proposing 5, we are OK.

> 
> I'm not proposing #5 (as you may have feared).  Rather, I'm proposing
> that we not do #1 - specifically, that producing the first version of
> the new FC-Mgmt MIB is a large enough task, that we should do it first
> before tackling Zoning.  I also think #2 would require coodination
> between something new and something which is changing, and therefore
> would be more work/more difficult than is 
> warranted/necessary.  So, I'm
> proposing either #3 or #4; at this point, I don't have a feel 
> for which
> would be better.
> 
> What do you think ?
> 
> Keith.
> 
> > Regards
> > 
> > Predrag Spasic,
> > Hewlett Packard
> > Details: https://ecardfile.com/id/predrag_spasic
> >  
> > 
> > > -----Original Message-----
> > > From: Keith McCloghrie [mailto:kzm@cisco.com]
> > > Sent: Thursday, November 08, 2001 10:43 AM
> > > To: ips@ece.cmu.edu
> > > Cc: kzm@cisco.com
> > > Subject: FC Management MIB - proposed changes
> > > 
> > > 
> > > 
> > > Based on the issues that I listed in my previous message 
> > > (yesterday), I
> > > have a set of changes that I'd like to make to the FC-Mgmt MIB,
> > > providing there are no objections from the WG.  These changes (the
> > > first six correspond to the issues list) are:
> > > 
> > > 1. MIB will be written using SMIv2.
> > > 
> > > 2. All objects which apply in non-Fibre Channel 
> environments will be
> > > removed.  (Note that this applies to a large fraction of 
> the objects
> > > defined in this MIB.)
> > > 
> > > 2a. For those objects which will be removed, if there are 
> any which
> > > are: a) not already covered in other MIBs, and b) 
> considered essential
> > > to the management of Fibre Channel-based products, then it will be
> > > necessary to consider whether other MIB(s) need to be 
> modified/created
> > > as a home for them, and if so which WG(s) should 
> undertake such work.
> > > 
> > > 3. With 20x20 hindsight, the following observations can 
> be made with
> > > respect to RFC 2837:
> > > 
> > > - the reason that we now have the issue of how it relates to the
> > >   FC-Mgmt MIB is because it was written as a Fabric Element MIB;
> > >   this issue would not have arisen if it had been written as a
> > >   Fibre Channel interface MIB.
> > > - it should have extended the ifTable, rather than 
> > > overlapping with it,
> > > - it should not have defined the fcFeModuleTable, which 
> overlaps with
> > >   the Entity MIB.
> > > - and it should have specified (at least) its octet counters 
> > > as Counter64.
> > > 
> > > Given these problems, I propose that the new FC-Mgmt MIB 
> be specified
> > > as a replacement for RFC 2837.
> > > 
> > > 4. This MIB will include a media-specific MIB to specify how Fibre
> > > Channel interfaces use the ifTable (see section 4 in RFC 
> 2863).  This
> > > will result in many tables in this MIB being indexed by ifIndex.
> > > 
> > > 5. Regarding the the MIB objects for the "Simple Name Service",
> > > I see two possible solutions:
> > > 
> > > i. retain the MIB objects but focus them on GS-3's Unzoned 
> > > Name Service.
> > > 
> > > ii. remove the MIB objects for the "Simple Name Service" from 
> > > this MIB.
> > >    If there is WG consensus that a MIB is needed for one of 
> > > the GS-3 Name
> > >    Services, and for which one, then the appropriate set of 
> > > MIB objects
> > >    can be defined in a new MIB.
> > > 
> > > Of these two, I propose to investigate solution i), and 
> if it proves
> > > feasible, then to adopt it;  if not, to fall back to solution ii).
> > > 
> > > 6. The Counter32 or Counter64 syntax will be used for counters.
> > > 
> > > 7. In addition to the above, it has been suggested that 
> MIB objects to
> > > support Class 1 are no longer needed.  If I don't hear 
> any objections,
> > > I will assume that I can make this change also.
> > > 
> > > 8. Yesterday, John Nguyen (jnguyen@gadzoox.com) asked in an 
> > > email about
> > > "bringing ZONE into FC Management MIB".  His suggestion 
> would seem to
> > > be in addition to, rather than as a replacement for, anything 
> > > which will
> > > be in the new FC-Mgmt MIB.  Thus, at this point in time, 
> I'd like to
> > > suggest that the changes listed above represent a large 
> enough amount
> > > of work for us to chew on.  Therefore, I propose that our 
> answer to
> > > John's query is to ask him to  re-raise this issue at a 
> point in the
> > > future when the new FC-Mgmt MIB is becoming more stable.
> > > 
> > > 9. Are there any other changes that anyone would like to 
> see at this
> > > time ?
> > > 
> > > Also note that with this MIB now being in a different WG, the 
> > > I-D needs
> > > to have a draft-ietf-ips-xxx name.  I propose to use
> > > draft-ietf-ips-fcmgmt-mib-00.txt.
> > > 
> > > Keith.
> > > 
> > 
>