RE: FC Management MIB - proposed changes

[Black_David@emc.com]

A couple more comments on the traps:

- The thing that's going away is the trap registration table.
	The existing traps become notifications.  This is what
	I was expecting.
- One of the things hiding in the existing trap registration
	table is the ability to register for traps by severity.
	Since the existing traps have severity specified
	statically (trap X always has severity Y), this looks
	like it can be handled by the filters in the notification
	MIB, although filter configuration will be somewhat
	more complex (but also much more flexible) than the
	existing severity mechanism.  Does that sound right?

Proposed course of action on RFC 2837 (include sufficient elements
in new MIB to replace it, even though decision as to whether to
replace has not been made) is fine.

Thanks,
--David

> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Sunday, November 11, 2001 6:11 PM
> To: Black_David@emc.com
> Cc: kzm@cisco.com; ips@ece.cmu.edu
> Subject: Re: FC Management MIB - proposed changes
> 
> 
> > 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.  
> 
> Agreed.  Even so, almost everything in the MIB will be affected.
> 
> > 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.
>  
> With SNMPv2c/SNMPv3, a Trap became one of the two forms by which a
> notification is transmitted; the other form is an InformRequest.
> SMIv2 MIBs don't define traps - they define notifications (with the
> NOTIFICATION-TYPE macro).  With SNMPv2c/SNMPv3, agents generate
> notifications, not traps.  The destinations to which a notification is
> sent is determined by the tables in the two MIBs defined in RFC 2573:
> the SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB.  The snmpNotifyType
> object in RFC 2573 determines in which form the notification is
> tranmsitted to a destination; it's possible for the same notification
> generated by an agent to be sent as a trap to one destination, and as
> an inform to another destination.  Thus, the trap table is a
> relic of the SNMPv1-only days; it is: a) insufficient for
> SNMPv2c/SNMPv3, and b) a duplicate of a subset of RFC 2573.  It should
> be deleted without replacement.
> 
> > 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.
> 
> We can postpone the decision on what happens to 2837.   However, 2837
> contains information on FC interfaces.  The FC-MGMT MIB also contains
> information on FC interfaces.  Most of the information will be the
> same, and should be defined once; I propose in the new FC-MGMT MIB.
> There are a few pieces of information which are specific to Fabric
> Elements.  I'll include those in the FC-MGMT MIB for the time being,
> until the postponed decision is made.
> 
> > 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).
> 
> OK.
> 
> > 7.  I would definitely take out Class 1 support, and reference FC-MI
> > 	(which prohibits Class 1 service) as an authority for doing so.
>  
> OK.
> 
> > 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.
>  
> OK.
> 
> > 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.
>  
> OK.
> 
> > 2, 4, and 6 look fine to me, as does the new draft name.
>  
> Thnaks,
> Keith.
>