RE: FCIP -03 comments and Annex E

[Black_David@emc.com]

Three remaining things, although this is after the -04
deadline and hence these'll have to go in -05.

> > Add at least FC-PH to the list of referenced documents
> 
> T11 adamantly holds the opinion that the combination of
> FC-PI and FC-FS replaces FC-PH. 

Ok.  We'll deal with what versions of those documents to
reference when we get to/through WG Last Call.

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

Yes, that's good.
 
> 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 cross-dependence of the standards does not occur if
R_A_TOV is mentioned as a non-normative example and cited
to the section of the document that currently defines it.

I think specific examples are useful in helping people
navigate back and forth between the two sets of specs.
R_A_TOV is also fairly well embedded into fabric operation;
I don't think there's much of a risk of it going away.

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

It's not "expected".  IMHO, this is analogous to the previous
issue - FC has a requirement to detect loss of connectivity for
correct operation of the fabric, and has mechanisms to do so,
such as HLO.  I'm not sure that the HLO example is as important
as the R_A_TOV one above.

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