SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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.
    


Home

Last updated: Wed Nov 14 09:17:44 2001
7810 messages in chronological order