Re: FCIP Annex E

[Ralph Weber <ralphoweber@compuserve.com>]

David,

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

Thanks.

Ralph...

Black_David@emc.com wrote:

>
> 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 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.

> 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).

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..

> 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.

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.

> > > 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).

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.

> > > 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).

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.

> > > 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.

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

..snip..