Subject: RE: FCIP Annex E

From: [email-masked]
Date: Wed, 18 Jul 2001 14:38:07 -0400

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Ralph Weber <[email-masked]>
Date: Thu, 19 Jul 2001 14:32:21 -0600

David,

Depending on how the embedded responses below sit with
you, we may be converging.

Thanks.

Ralph...

> ignored (e.g., Class 1 service).

I do not see how this is possible without adding a
tutorial on Fibre Channel to FCIP.  Most Fibre Channel
tutorials are ten or more pages, and FCIP already has
two pages of tutorial in Annex C.  After all, Class 1
service could refer to an airplane ticket and a 
sentence such as: "Class 1 service can be ignored"
already requires a Fibre Channel expert for there
to be any hope of understanding the meaning.

> is a *really bad thing* in a Fibre Channel fabric).

It seems to me that the simpler rational to explain
is that the Fibre Channel routing and error recovery
protocols require FC Frames to exit a receiving FCIP 
Entity within in a fixed interval from the time they 
entered a sending FCIP Entity, IP Network transit
time included, or never exit the FCIP Entity.

Mentioning the Fibre Channel specifics both obscures the 
matter of concern and obliges Fibre Channel to either 
forever maintain R_A_TOV as the one and only issue of 
merit in this matter or bother the IESG with a new 
revision of FCIP when it does.

The straight forward explanation will be added at 
the beginning of 6.6.2.3 in rev 04.

..snip..

> meet them across multiple connections.

Section 9, heavens no!  Section 9 is undergoing a total rewrite
for rev 04.

Section 7 was intended, specifically the discussion of how
the FCIP Entity maintains its knowledge of multiple connections
in 7.1.1 and 7.1.2.

> of HLO (that sort of requirement is FC's business).

If it is expected that all IETF standards track RFCs must
discuss how they implement a keep-alive mechanism, then
most certainly FCIP needs to explain why it does not
need one.

> definition of EOFa in FC-PH (17.6.3).

In rev 04, a discussion of EOFa (cloned from FC-FS) will be added
to C.1 and a cross reference to C.1 will be added at the sites
where EOFa is used.

> should explain why DLY_LIM exists.

I think the addition to 6.6.2.3 described above handles this
issue in a manner appropriate to FCIP.

..snip..