Re: FCIP Annex E

[Ralph Weber <ralphoweber@compuserve.com>]

Black_David@emc.com wrote:

..snip..

> 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}
>
> This is about what happens when FCIP drops an FC frame
> for some reason (one of the checks in 6.6.2.2 failed).
> Annex D needs to place responsibility for recovery from
> this event on the FC entity, which may defer to something
> else (e.g., the FC entity may ignore this in favor of
> FCP or SCSI retry).  A sentence in 6.6.2.2. pointing
> out where the responsibility for recovery lies and
> giving possible examples would be a useful addition to
> the last paragraph.

The following sentence has been added at the end of
6.6.2.2:

The burden for recovering from discarded data falls on 
the FC Entity and other components of the FC Fabric and 
is outside the scope of this specification.

The following sentence has been added at the end of
6.6.2.3:

The burden for recovering from discarded FCIP Frames falls 
on the FC Entity and other components of the FC Fabric and 
is outside the scope of this specification.

The following sentence has been added at the end of
6.6.2.4:

The burden for recovering from the discarding of FCIP Frames 
during the optional resynchronization process described in 
this section falls on the FC Entity and other components of 
the FC Fabric and is outside the scope of this specification.
 
> E-5.3 TCP Connection Management
> E-5.5 Multiple Connection Management
>
> Some of the information in these sections probably needs to
> be in both FCIP and FC-BB-2.  FCIP should contain information
> describing how TCP connections may be mapped to FC port
> connections (Section 7 in -03 is silent on this topic).
> The first paragraph of E-5.3 and most of E-5.5
> fall into this category, although they should be generalized to
> avoid references to ISLs, E ports and B ports.  The connection
> setup material in E-5.3 seems to be adequately covered in 7.1
> and its subsections.

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.

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

> E-5.6 Multi Virtual ISL Management
>
> This looks like an FC fabric topology issue, and hence
> moving it to FC-BB-2 makes sense (IMHO).
>
> 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.  Annex D does not appear to capture
> the possible interactions between the FC and FCIP entities
> in this area - some more explanation of possibilities and
> responsibilities is needed.

I believe that sufficient discussion of EOFa appears in
section 6.6.2.4.

> E-8.4 Timeouts {partial}
>
> The mechanism to deal with this is covered in 6.6.2.3, but
> that section would be considerably more readable if it included
> an explanation of what R_A_TOV and E_D_TOV govern and why only
> R_A_TOV needs to be enforced in FCIP.

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.

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

Thanks.

Ralph...