RE: FC Management MIB - proposed changes

[Black_David@emc.com]

Ah, now I see the confusion.  The "nameservice" that is
actually used by a port attached to a Fibre Channel
fabric in order to locate other ports with which to
communicate is the Directory Service described in Section
5 of FC-GS3.  That's the service for which management
visibility via the MIB is needed.  There's only one instance
of such a service in a fabric, and the interface from
a port to that service is the same independent of whether
zoning is in use.

Section 6 of FC-GS3 defines the Management Service which
is an inband Fibre Channel analogue to SNMP and MIBs (it
is entirely for management).  When the FC management MIB
is implemented in a fabric switch, I would expect the
name service objects in it to report information
equivalent to the Unzoned Name service.  One then
figures out the behavior of the directory service by
retrieving this information plus the zone information.
OTOH, if the MIB is implemented in another device (e.g.,
FC to SCSI bridge that does not contain an embedded
FC switch), the MIB may report only the zoned view of
the directory service that's visible to that device.

Thanks,
--David

> -----Original Message-----
> From: Ken Hirata [mailto:Ken.Hirata@Vixel.com]
> Sent: Tuesday, November 13, 2001 12:52 PM
> To: Black_David@emc.com
> Cc: kzm@cisco.com; ips@ece.cmu.edu
> Subject: Re: FC Management MIB - proposed changes
> 
> 
> David,
> 
> One nit (or misunderstanding).  In item 5 below, Zoned and Unzoned
> name services are simultaneously active.
> 
> My understanding is that Zoned name services present a view to a
> device of all other devices with which it may communicate (same as
> your explanation).
> 
> Unzoned name services are used by a Management application to
> retrieve information about all devices in the Fabric.
> 
>                                             Ken
> 
> Black_David@emc.com wrote:
> 
> > 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
> 
> --
> Kenneth Hirata
> Vixel Corporation
> Irvine, CA 92618
> Phone: (949) 450-6100
> Email: Ken.Hirata@Vixel.com
> 
>