RE: FC Management MIB - proposed changes

[Black_David@emc.com]

Folks,

For simplicity, I would propose keeping the initial revision focused
on structural and format changes only - i.e., make no functional
changes that aren't required to bring the MIB into line with the
overall architecture of MIBs, use of SMIv2, and the like.  Comments on
this, keyed to Keith's issue numbers:

1.  The trap table doesn't match up with RFC 2573 - I presume
	correcting this is part of the conversion to SMIv2.

3.  Let's keep the replacement of RFC 2837 as (a) a proposal
	and (b) Keith's recommendation to the WG as MIB Advisor,
	but not formally adopt that approach until we have a version
	of the MIB draft that would replace RFC 2837 available for
	review by the WG.

5.  I think there's a misunderstanding here.  There is only one
	name service in any FC fabric, period.  The term "Simple Name
	Service" is historical and refers to the current approach
	to Fibre Channel fabric name service by contrast to the
	originally-proposed X.500 directory-based approach (see the
	original FC-GS) - the meaning of "Simple" should now be
	obvious, as it's by comparison to X.500 ;-).

	Both the Zoned and Unzoned name services are simple name services.
	The same objects can be used to represent both, as only one is
	active at any time, and the communication interfaces/protocols
	are identical.  Client access to the name service is the same
	in both cases; zoned vs. unzoned only affects server behavior
	in terms of what is returned to a query.  In addition the name
	service objects are described to represent only entities
	"known to this unit".  So, in a zoned fabric, I would expect
	the table in a switch to be completely populated, but the table
	in an HBA to contain only the entries in that HBA's zone
	because the HBA doesn't "know" about any others.

	The name server objects need to be retained - these are quite
	important for fabric management visibility.  Whether the fabric
	is zoned or not and how the nameserver behaves can be determined
	from the zone objects (i.e., for a switch, the nameserver objects
	contain everything and the zone objects have to be consulted to
	figure out what a query from a particular client to the nameserver
	will return).

7.  I would definitely take out Class 1 support, and reference FC-MI
	(which prohibits Class 1 service) as an authority for doing so.

8.  For the initial version, I would only carry forward the zone
	objects existing in the current MIB and not define any new
	functionality - that can be done in revisions after -00.

9.  I'd prefer that the -00 version contain no additional functional
	changes beyond those required to support the necessary
	structure and format changes.  Once we have that -00 baseline,
	functional changes can be made from there.

2, 4, and 6 look fine to me, as does the new draft name.

Comments?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Thursday, November 08, 2001 1:43 PM
> 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.
>