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



    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
    
    


Home

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