RE: FCIP Annex E

[Black_David@emc.com]

Picking up on the Annex E issues, a general theme running
through my comments is that while much of the currently
proposed text is sufficient to convey what's going on to a
Fibre Channel expert, I think the FCIP spec should be
accessible to someone who isn't.  This means someone
who hasn't waded through the various specs (at least half
a dozen specs, easily over 1000 pages) and figured out
which pieces are important vs. those that should be
ignored (e.g., Class 1 service).

I agree that detailed specification
of Fibre Channel aspects (e.g., DLY_LIM calculation)
belongs in FC-BB-2, but (non-normative) explanations
of the purpose and rationale for inclusion of functionality
in FCIP is in order for the FCIP spec, and such
explanations will have to touch on FC concepts
(e.g., an explanation of DLY_LIM is much clearer
if it explains what R_A_TOV is and why violating it
is a *really bad thing* in a Fibre Channel fabric).

So, here are my comments going section by section:

> > In at attempt to make sure that we don't lose anything
> > important in removing this text from the FCIP draft,
> > here are some suggestions:
> >
> > E-4.3 FCIP's Interaction with FC and TCP {partial}

The proposed text additions look ok.

> > E-5.3 TCP Connection Management
> > E-5.5 Multiple Connection Management
>
> No changes have been made in FCIP in response to this comment.
> 
> I am loath to add FC Port to the FCIP glossary.  I can find
> nothing in the first paragraphs of E-5.3 and E-5.5 that
> are not covered in suitably general terms in section 8.

I think Section 9 was intended.  The concern I have is a that the
coverage is a bit too general, e.g., what are "appropriate policies
for mapping FC Frames to these connections"?  It's not necessary
to specify how to do this, but at least note what FC's frame
ordering requirements are and provide an example of how to
meet them across multiple connections.

> > E-5.4.1 Determining loss of connectivity {partial}
> >
> > Somewhere, possibly in Annex D, making the FC entity
> > responsible for checking for loss of TCP connectivity
> > ought to be enhanced by giving the HLO SW_ILS as an
> > example of how this could be done without requiring it
> > to be used.
> 
> No changes have been made in FCIP in response to this comment.
> 
> This is 100% a Fibre Channel issue.  If Fibre Channel does
> not want to test connectivity, that is Fibre Channel's business.
> If Fibre Channel wants to invent a replacement for the HLO
> SW_ILS (perhaps even one suited specifically to FCIP) why
> should it be the place of FCIP to mandate use of HLO?

I didn't say "mandate", I said "as an example".  The general
point is that FC may have a keep-alive mechanism such as HLO
that would obviate the need for any such mechanism at this
level, and it should be made in the FCIP spec.  Referencing
HLO and the version of FC-SW that defines it *as an example*
would help get the point across, without requiring any use
of HLO (that sort of requirement is FC's business).

> > E-8.3 Corruption {partial}
> >
> > Most of this seems to be covered in 6.6.2.2, but noting that
> > FC has the option to begin transmitting a frame and terminate
> > that with an EOF invalidating the partially transmitted frame
> > should be added.
>
> I believe that sufficient discussion of EOFa appears in
> section 6.6.2.4.

6.6.2.4 has very little on EOFa.  I'd add essentially the above sentence
so that the result is intelligible to someone who isn't already a Fibre
Channel expert, and put in the appropriate section reference to the
definition of EOFa in FC-PH (17.6.3).

> > E-8.4 Timeouts {partial}

> It is intended that 04 change the usage of R_A_TOV to some other
> variable name, perhaps DLY_LIM (delay limit).  The burden for
> computing DLY_LIM will be placed on the FC Entity, and DLY_LIM
> will be nothing more than the value enforced by the FCIP_DE
> as per 6.6.2.3.

That's a good approach, but I would still add non-normative
text to point out the existence and purpose of R_A_TOV, which has
to be considered by the FC Entity in this computation.  Again this is
explanatory text - FC-BB-2 is the place to specify details of how to
calculation DLY_LIM from inputs such as R_A_TOV, but FCIP
should explain why DLY_LIM exists.

> > E-10.1 Flow control on FC network
> >
> > Section 7.4 covers this topic, but calling out FC
> > Buffer-to-Buffer flow control as an example of how
> > arrival of frames from the fabric can be controlled
> > at the bottom of p.21 would improve readability.
> 
> This will be carried forward as a note to the FCIP Authors.

I would recommend putting in the example.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------