RE: Additional FC MIBs proposed

["Julian Satran" <Julian_Satran@il.ibm.com>]

It looks more and more like interesting
parties want us (IETF) to rubber-stamp their flavor of FC management.
I do not think that this particular
WG is qualified to handle FC related MIBs.
As I said several time we are the IP
storage WG. And FC belongs to T11.

Julo

"Mike O'Donnell" <mike.o'donnell@mcdata.com>

26/06/03 01:39

To	"Bill Strahm" <bill@strahm.net>, Julian Satran/Haifa/IBM@IBMIL
cc	<ips@ece.cmu.edu>
Subject	RE: Additional FC MIBs proposed

All,

I have reviewed the proposal for the 9 MIB's suggested by the authors.
  I have no opinion on where the MIB definition should reside (IETF
vs. T11) - which is the debate below.

However, in both cases, my assumptions are that the underlying FC protocols
needed to support the management MIB would have already been accepted (or
be close to it) by the FC Switch vendor community at a minimum.  That
activity is chartered under T11 (for which I can assume there is no debate).

My feedback follows:

1.  The authors suggest standardizing a MIB as it relates to VSAN
awareness. The author's are correct in stating that the "concept"
has been introduced to 'T11'.  However, there is considerable work
and needed agreement by T11 membership that VSAN-like technology is a requirement
for Fibre Channel (and hence any resulting interoperable ANSI Fibre Channel
protocols).  To date the only information that has been presented
to T11 has been a power-point presentation.  This is far from what
is needed to insure an agreed upon interoperable solution for FC SAN's.
 As such, and until the underlying ANSI Standard FC protocols are
defined and accepted for inclusion into an ANSI standard, I would recommend
any such MIB definition would be very premature. 

2. Ditto the proposed 'Fibre Element' which introduces TE_ports which are
not defined in current ANSI standards.

3. Virtual Fabrics  (see #1 above).

4. Domain Manager.  To the extent it abides by definitions and protocols
defined in FC-SW-3, I have no comments

5. FSPF.  I am unclear what a 'region id' is as it relates to FSPF.
Autonomous regions are defined in FC-SW-3 but widely acknowleged as woefully
inadequate for practicial implementation.  I would need to understand
the authors' intent with respect to 'configuring' an FSPF attribute that
is not defined in FC today before I could comment futher on this MIB.

6. Routing Information. To the extent it abides by definitions and protocols
defined in FC-SW-2, I have no comments

7. Name Server. To the extent it abides by definitions and protocols defined
in FC-SW-2, I have no comments

8. Registered State Change Notification. To the extent it abides by definitions
and protocols defined in FC-SW-2, I have no comments

9. Zone Server.  There is still considerable consternation in T11
with respect to alignment of zoning operations.  Per the suggested
MIB, the authors describes several items that are NOT defined in current
approved FC-SW-2 or FC-GS-3 nor are they in any proposed standard.("operative
status, administrative status...".  I would need to understand
the authors intent of the new status and how it aligns with current approved
ansi standards before I could further comment.

Regards,

Mike O

======================
  Michael E. O'Donnell
Director Software Architecture
  McDATA Corporation
 4 McDATA Parkway
 Broomfield, Colorado 80021
  720.558.4142 (office)
  303.570.3631 (cel)
   mike.o'donnell@mcdata.com
======================




-----Original Message-----
From: Bill Strahm [mailto:bill@strahm.net]
Sent: Wednesday, June 25, 2003 3:37 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: Additional FC MIBs proposed


Ok, I remember these coming into the IPS working group about two years
ago.  
Unfortunately I am about 2 laptop from there, and have not archived mail
for 
that period of time.

I remember the history about like Keith does, looking at the MIBs and going
these are a piece of junk, how did they get standardized... (then being
told
to implement them anyway, because they were "correct")

Lets not fight over where they belong.  Frankly most of the storage
people
in the IETF hang out here, so here is as good a place as any to get these
corrected

Bill
On Wed, Jun 25, 2003 at 09:26:46PM +0300, Julian Satran wrote:
> Keith,
> 
> I do not recall the IPS working group having a FC MIB in it's charter,
nor 
> having being asked to extend the charter to include it by a popular
vote 
> or the IESG.
> 
> I do not know how the MIB draft got to have the name draft-ietf-ips...
> that implies a working group work item and I follow this group work
from 
> its inception.
> 
> David asked a question to which the answer was silence or NO.  IPFC
- or 
> the designated trustees of it's documents are the place to take this.
> 
> Julo
> 
> 
> 
> 
> 
> 
> 
> 
> Keith McCloghrie <kzm@cisco.com> 
> Sent by: owner-ips@ece.cmu.edu
> 25/06/03 20:14
> 
> To
> pat_thaler@agilent.com
> cc
> Black_David@emc.com, ips@ece.cmu.edu
> Subject
> Re: Additional FC MIBs proposed
> 
> 
> 
> 
> 
> 
> The issue with doing the MIBs in T11 is that T11 has, in the past,
not
> had the appropriate amount of MIB expertise.  My understanding
is that
> T11 themselves acknowledged this by the submission of the "Fibre
> Alliance MIB" as draft-ietf-ipfc-fcmgmt-int-mib.  However,
as and when
> the IPFC WG had completed all other items in its charter, it had been
> unable to reach consensus on that MIB.  So, to allow the IPFC
WG to
> conclude, the unfinished work item was moved to the IP Storage WG.
> After abortive attempts to get changes in draft-ietf-ipfc-fcmgmt-int-mib,
> I created draft-ietf-ips-fcmgmt-mib as a MIB which: a) meets IETF's
> standards, b) replaces both draft-ietf-ips-fcmgmt-mib and the overlapping
> RFC 2837, and c) details the problems with those previous MIBs.
> 
> Meanwhile, T11 has published on its website a copy of one version
(I'm
> not sure if it's the latest version) of draft-ietf-ips-fcmgmt-mib.
> Since that MIB is widely implemented in the industry, I agreed that
> such publication would be appropriate *if* T11's publication indicated
> that the MIB is already being deprecated by the IETF's definition
of
> draft-ietf-ips-fcmgmt-mib.  The last time I looked, T11 had failed
to
> do that; rather, T11 seem to have published draft-ietf-ips-fcmgmt-mib
> as if it were the definitive standard for a Fibre Channel MIB.
> (However, the MIB was still in its Internet-Draft format, and perhaps
> T11 intended that as an indication that the MIB was just a draft,
as
> ephemeral as all Internet-Drafts are, by definition).  These
recent
> actions of T11 suggest to me that they still do not have the
> appropriate amount of MIB expertise.
> 
> The bottom line is that a bad MIB was widely implemented in the industry,
> and I believe that network management of Fibre Channel devices suffered
> because of that.  A better MIB for Fibre Channel has been defined
in the
> IP Storage WG, who have already discussed the definition of further
FC 
> MIBs
> (see http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09473.html),
but
> deferred them as future work.
> 
> Keith.
> 
> 
> > It doesn't appear that any of these MIBs are in scope for us.
They
> > don't deal with IP storage. They are all very specific to Fibre
Channel
> > and deal mostly with fabric issues. T11 would be more appropriate.
> > 
> > Pat
> > 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Monday, June 23, 2003 6:55 AM
> > To: ips@ece.cmu.edu
> > Subject: Additional FC MIBs proposed
> > 
> > 
> > Everyone,
> > 
> > This Internet-Draft describes a number of MIBs that the authors
> > would like the IPS WG to take up.  The WG chairs are seeking
> > input on the level interest in standardization and use of these
> > MIBs, the appropriateness of working on them here (vs. T11) and
> > prioritization (which ones to take up first, as all 9 in parallel
> > is not likely).
> > 
> > Send comments/opinions/etc. to the list or directly to Elizabeth
> > (ElizabethRodriguez@ieee.org) and myself (black_david@emc.com).
> > 
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX:
+1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978)
394-7754
> > ----------------------------------------------------
> > 
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Friday, June 20, 2003 2:28 PM
> > Subject: I-D ACTION:draft-gai-fc-mibs-00.txt
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > 
> > 
> >                Title
                     
    : MIBs Standardization 
> for Fibre Channel
> >                Author(s)
              : S. Gai et al.
> >                Filename
               : draft-gai-fc-mibs-00.txt
> >                Pages
                     
    : 9
> >                Date  
                     
   : 2003-6-20
> > 
> > Fibre Channel (FC) is a high speed serial interface technology
that 
> > supports several Upper Layer Protocols including Small Computer
> > System Interface (SCSI) and IP. Fibre Channel is standardized
by the 
> > INCITS T11 Technical Committee. Fibre Channel Standards include
> > Framing and Signaling protocols [FC-FS], Generic Services protocols
> > [FC-GS-3], Switch Fabric protocols [FC-SW-2], etc.
> > The management of a Fibre Channel network requires to monitor
and set 
> > many parameters related to these protocols and this may be 
> > accomplished defining a proper set of MIBs.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-gai-fc-mibs-00.txt
> > 
> > To remove yourself from the IETF Announcement list, send a message
to 
> > ietf-announce-request with the word unsubscribe in the body of
the 
> message.
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with
the 
> username
> > "anonymous" and a password of your e-mail address.
After logging in, 
> type
> > "cd internet-drafts" and then
> >                "get
draft-gai-fc-mibs-00.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> >                mailserv@ietf.org.
> > In the body type:
> >                "FILE
/internet-drafts/draft-gai-fc-mibs-00.txt".
> > 
> > NOTE:          The mail server at ietf.org
can return the document in
> >                MIME-encoded
form by using the "mpack" utility.  To use 
> this
> >                feature,
insert the command "ENCODING mime" before the 
> "FILE"
> >                command.
 To decode the response(s), you will need 
> "munpack" or
> >                a MIME-compliant
mail reader.  Different MIME-compliant 
> mail readers
> >                exhibit
different behavior, especially when dealing with
> >                "multipart"
MIME messages (i.e. documents which have been 
> split
> >                up into
multiple messages), so check your local 
> documentation on
> >                how to
manipulate these messages.
> > 
> > 
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of
the
> > Internet-Draft.
> > 
> 

SPECIAL NOTICE 
All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of confidential
and privileged information is prohibited. If the reader of this message
is not the intended recipient(s) or the employee or agent responsible for
delivering the message to the intended recipient(s).

You may not distribute or copy the confidential and privileged portion
of this communication to another. Anyone who receives confidential and
privileged information in error should notify us immediately by telephone
and mail the original message to us at the above address and destroy all
copies.

To the extent any portion of this communication contains public information,
no such restrictions apply to that information. (gate01)