Subject: [Gen-art] Re: Gen-ART review of draft-ietf-imss-fc-rtm-mib-03.txt

From: Keith McCloghrie <[email-masked]>
Date: Mon, 24 Apr 2006 09:15:03 -0700 (PDT)

Spencer,
 
Thnaks for the comments.

> I was selected as General Area Review Team reviewer for this specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Summary: This document is almost ready for publication as a Proposed 
> Standard. I do have a question on Section 5.3, listed below.
> 
> I also identified two editorial comments (not part of the Gen-ART review for 
> Brian). I hope this is useful.
> 
> Thanks,
> 
> 1.  Introduction
> 
>    This memo defines a portion of the Management Information Base (MIB)
>    for use with network management protocols in the Internet community.
>    In particular, it describes managed objects for information related
>    to the Fibre Channel network's Routing Table for routing within a
>    Fabric.  Managed objects specific to particular routing protocols,
>    such as FSPF, are not specified in this MIB module.
> 
> Spencer (NIT): FSPF is not exanded until later in the document (and should 
> have the reference to [FC-SW-4] that doesn't appear until Section 4). 
> Suggest "... such as Fabric Shortest Path First (FSPF) protocol [FC-SW-4], 
> ..." as replacement text.
 
Thanks for catching that.

> 5.3.  Fabric Index
> 
>    The latest standard for an interconnecting Fabric containing multiple
>    Fabric Switch elements is [FC-SW-4] (which replaces the previous
>    revision [FC-SW-3]).  [FC-SW-4] specifies the operation of both a
>    single Fabric in a physical infrastructure, as well as the support of
>    multiple Virtual Fabrics operating within one (or more) physical
>    infrastructures.  Whether operating on a physical Fabric (i.e.,
>    without Virtual Fabrics) or within a Virtual Fabric, the operation of
>    FSPF within a Fabric is identical.  Therefore, this MIB defines all
>    Fabric-related information in tables which are INDEX-ed by an
>    arbitrary integer, named a "Fabric Index", the syntax of which is
>    IMPORTed from the T11-TC-MIB.  When a device is connected to a single
>    physical Fabric, without use of any virtual Fabrics, the value of
>    this Fabric Index will always be 1.  In an environment of multiple
>    virtual and/or physical Fabrics, this index provides a means to
>    distinguish one Fabric from another.
> 
> Spencer: I can guess what a Virtual Fabric is, but I'm guessing and the term 
> hasn't been introduced yet, and there's no reference for it. Not a critical 
> problem, but since there's a nice overview in Section 3, maybe it could have 
> a sentence or two that introduces the concept, before it appears in Section 
> 5.3?

Adding [FC-SW-4] as a reference is easy, and I can also include an
extra paragraph to mention Virtual Fabrics at the end of section 3.
I hope it will be sufficient to do so by lifting some text out of
FC-SW-4, even though FC-SW-4's definitions are somewhat circular --
specifically, a Virtual Fabric is defined in terms of Virtual Switches,
which are defined in terms of a "Core Switch" for which the definition
includes Virtual Fabric :-(.

> 5.5.  The t11FcRouteTable's INDEX
> 
>    Providing the same useful feature in the MIB in this document,
>    results in having an unusually large number (ten) of objects in the
>    t11FcRouteTable's INDEX clause.  However, all ten are either integers
>    or strings of length 0 or 3 octets.  Thus, the aggregate number of
>    sub-identifiers to be appended to an OBJECT-TYPE's OID when naming an
>    instance of an object in this table, is at most 22 sub-identifiers,
>    i.e., less than the *minimum* number to be appended for the
>    inetCidrRouteTable table.  In other words, while ten is an unusually
>    large number of objects in an INDEX clause, the resultant OIDs are
>    not unusually large.
> 
> Spencer (more than a NIT): This paragraph is really tortured, until you get 
> to the last sentence, which seems all that's needed anyway (suggest "While 
> this useful feature results in an unusually large number (ten) of objects in 
> the t11FcRouteTable's INDEX clause, all ten are all ten are either integers 
> or strings of length 0 or 3 octets, so the resulting OIDs are not unusually 
> large."). But the reason I flagged this as "more than a nit" was that 
> "length 0 or 3 octets" was confusing - the point is, "maximum length of 3 
> octets", isn't it? FC people are very aware of FCAddressIdentifier 
> structure, but no one else is, so "0 or 3 octets" is a distraction, and the 
> wordy paragraph just made it worse. 
 
Yes, that will be an improvement (minus the typo that you caught in your
subsequent message).

Thanks,
Keith.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 24 Apr 2006 11:31:13 -0500

Hi, Keith,

The changes you propose would would for me.

Thanks especially for your proposed change to 5.3. I don't think a lot of 
description is required, just enough to clearly identify what's being 
discussed.

Spencer

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 27 Apr 2006 13:37:36 -0700 (PDT)

Dan,

The ID-State-Tracker says that this I-D is in the "Waiting for Writeup"
state, and thus the state diagram says that after your writeup and
"Go-Ahead", it will enter the "IESG evaluation" state.

So, do you want me to make the changes (outlined below) now and submit an
updated draft-ietf-imss-fc-rtm-mib-04.txt, or wait until later ??

Thanks,
Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 28 Apr 2006 08:27:57 -0700 (PDT)

Spencer,

> description is required, just enough to clearly identify what's being 
 
I've done the editing that I believe addresses your points.  Before I
submit the new version, please could you sanity-check these changed
paragraphs:

  1.  Introduction

     This memo defines a portion of the Management Information Base (MIB)
     for use with network management protocols in the Internet community.
     In particular, it describes managed objects for information related
     to the Fibre Channel network's Routing Table for routing within a
     Fabric.  Managed objects specific to particular routing protocols,
!    such as the Fabric Shortest Path First (FSPF) protocol [FC-SW-4], are
!    not specified in this MIB module.

  ...

  3.  Short Overview of Fibre Channel

         ... the best link by which to forward that frame towards its
     destination.

+    The latest standard for an interconnecting Fabric containing multiple
+    Fabric Switch elements is [FC-SW-4] (which replaces the previous
+    revision [FC-SW-3]).  [FC-SW-4] carries forward the existing
+    specification for the operation of a single Fabric in a physical
+    infrastructure, augmenting it with the definition of Virtual Fabrics
+    and with the specification of how multiple Virtual Fabrics can
+    operate within one (or more) physical infrastructures.  The use of
+    Virtual Fabrics provides for each frame to be tagged in its header to
+    indicate which one of several Virtual Fabrics that frame is being
+    transmitted on.  All frames entering a particular "Core Switch"
+    [FC-SW-4] (i.e., a physical switch) on the same Virtual Fabric are
+    processed by the same "Virtual Switch" within that Core switch.

  4.  Relationship to Other MIBs

  ...

  5.3.  Fabric Index

-    Whether operating on a physical Fabric (i.e., without Virtual
     Fabrics) or within a Virtual Fabric, the operation of FSPF within a
     Fabric is identical.  Therefore, this MIB defines all Fabric-related
     information in tables which are INDEX-ed by an arbitrary integer,
     named a "Fabric Index", the syntax of which is IMPORTed from the
     T11-TC-MIB.  When a device is connected to a single physical Fabric,
     without use of any virtual Fabrics, the value of this Fabric Index
     will always be 1.  In an environment of multiple virtual and/or
     physical Fabrics, this index provides a means to distinguish one
     Fabric from another.

  ...

        ... in the ipCidrRouteTable [RFC2096], and more recently, the
     inetCidrRouteTable in [RFC2096bis].

!    While this useful feature results in an unusually large number (ten)
!    of objects in the t11FcRouteTable's INDEX clause, all ten are either
!    integers or strings of length 3 (or zero) octets, so the resulting OIDs
!    are not unusually large.  [Specifically, the aggregate number of sub-
!    identifiers to be appended to an OBJECT-TYPE's OID, when naming an
!    instance of an object in the t11FcRouteTable, is at most 22
!    sub-identifiers, i.e., less than the *minimum* number to be appended
!    for the inetCidrRouteTable table.]

Thanks,
Keith.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 28 Apr 2006 10:45:07 -0500

Hi, Keith,

These work for me. It looks like you added the comparison to 
inetCidrRouteTable back into 5.5, which I think is actually very helpful (I 
just left it out of my suggested text, since the paragraph was getting long 
again, but it's clear with your text in).

Thanks,

Spencer