Subject: RE: FC Management MIB - proposed changes

From: Kevin Gibbons <[email-masked]>
Date: Thu, 8 Nov 2001 16:01:51 -0800

If there is sufficient interest, it would be possible to add FC Zone
information to the iSNS MIB.

The iSNS MIB already provides an ability to manage iSCSI/iFCP Discovery
Domains and iSCSI/iFCP Discovery Domain Sets.  These are similar to FC Zones
and Zone Sets.

There are already situations where an iSCSI/iFCP Discovery Domain maps to an
equivalent FC Zone.  For example, when a FC to iSCSI/iFCP switch is used,
and a Discovery Domain with native FC devices is created in the iSNS, then
an equivalent FC Zone is created in the Fibre Channel Name Service to
support this.  

If added to the iSNS MIB, the conformance section could indicate that a
switch only supporting Fibre Channel only implements FC specific sections.

Kevin

-----Original Message-----
From: Keith McCloghrie [mailto:[email-masked]]
Sent: Thursday, November 08, 2001 12:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: FC Management MIB - proposed changes

If the iSNS editors think they can do this, then I think it's
a good idea.

Keith.
 
> Keith,
> 
> On the topic of Simple Name Service, would it be possible to make this
> generic enough to work within the iSNS MIB.  I would like to see the iSNS
> MIB be able to cover both iSCSI and FC if it is at all possible.  Any
> reasons this can't be done ?  Does the iSNS editors want to try to
> incorporate this into their design (how hard would it be, is it even
> possible ?)
> 
> Bill
> +========+=========+=========+=========+=========+=========+=========+
> Bill Strahm     Software Development is a race between Programmers
> Member of the   trying to build bigger and better idiot proof software
> Technical Staff and the Universe trying to produce bigger and better
> [email-masked] idiots.
> (503) 601-0263  So far the Universe is winning --- Rich Cook
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Keith McCloghrie
> Sent: Thursday, November 08, 2001 10:43 AM
> To: [email-masked]
> Cc: Keith McCloghrie
> Subject: FC Management MIB - proposed changes
> 
> <snip>
> 
> 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).
> 
> <snip>
> 
> Keith.
> 
>

---

From: Kha Sin Teow <[email-masked]>
Date: Fri, 9 Nov 2001 13:16:14 -0800

Hi,

I just got back from the T10 meeting and saw
a flurry of discussion on this topic.

I think Dave's comments are mostly in line with mine.
Some more in-line comments below ...

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]]
| Sent: Thursday, November 08, 2001 12:51 PM
| To: [email-masked]; [email-masked]
| Subject: RE: FC Management MIB - proposed changes
| 
| 
| 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.

Absolutely.
It's not a good idea to start opening up at this stage
for more functionalities.

|  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.

agree.
let me add Keith's point 3 here (preceded with ">") with my
comments.

> - 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.

I'm not sure if I follow the argument above as a good reason
to replace RFC2837. It started out as an effort to define MIB for
FC switches (not FC hub, HBA or other FC interconnect elements as
in to be re-worked FC-Mgmt MIB).

I'm open to suggestion that if RFC2837 needs revision to
line up with other MIBs due to overlaps (such as Entity MIB).
If that means that RFC2837 will be obsoleted some time in future
by the new FC-Mgmt MIB, I'm ok with it.
However, we need to be careful that we don't try to fold everything into
the new MIB in one go.
If we need to fix the sink, please don't think about doing a new roof.-)

> - it should have extended the ifTable, rather than overlapping with it,

Unfortunately, at the time, the adivsor didn't raise the issue with
the working group; 
I agree it's an area to improve.

> - it should not have defined the fcFeModuleTable, which overlaps with
>   the Entity MIB.

At the time, the Entity MIB was work in progress.
I didn't quite see how it fits in then.
Given the state of Entity MIB, I agree that this is another area to improve.

> - and it should have specified (at least) its octet counters as Counter64.

as Predrag pointed out, FC standards doesn't specify 64bit counters.
As far as I'm aware, most current FC implementations only support 32-bit
counters.
Therefore we should be cautious about specifying 64bit counter
(which would require an agent to maintain a set of software counters).

... 

| 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
| [email-masked]       Mobile: +1 (978) 394-7754
| ---------------------------------------------------
| 
| > -----Original Message-----
| > From: Keith McCloghrie [mailto:[email-masked]]
| > Sent: Thursday, November 08, 2001 1:43 PM
| > To: [email-masked]
| > Cc: [email-masked]
| > Subject: FC Management MIB - proposed changes
| > 
...

Kha Sin/

---

From: [email-masked]
Date: Tue, 13 Nov 2001 14:06:27 -0500

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

> From: Ken Hirata [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 12:52 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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
> 
> [email-masked] 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: [email-masked]
> 
>