Subject: FCIP Annex E

From: [email-masked]
Date: Tue, 10 Jul 2001 10:35:01 -0400

> Please examine the title and first paragraph of Annex C
> (which encompasses pages 39 to 44).
> 
> "ANNEX E - FC-BB-2 Inputs
> 
>   "This annex contains text from previous FCIP drafts that,
>   because of the new model structure, probably belongs in
>   FC-BB-2 [4]. As soon as the correctness of this annex is
>   agreed, its contents will be transferred to a T11 document
>   do be used in the development of FC-BB-2."
> 
> The correctness of the annex (such as it is) has been agreed
> among the FCIP authors and the content of the annex can now
> be found at:
> 
>     ftp://ftp.t11.org/t11/pub/fc/bb-2/01-342v0.pdf
> 
> The annex will not appear in FCIP revision 04.
> > 
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.

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.

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.

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

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.

Thanks,
--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: Tue, 17 Jul 2001 05:46:30 -0600

[email-masked] wrote:

..snip..

> giving possible examples would be a useful addition to

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.
 
> setup material in E-5.3 seems to be adequately covered in 7.1

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.

> example of how this could be done without requiring it

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?

> responsibilities is needed.

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

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

> at the bottom of p.21 would improve readability.

This will be carried forward as a note to the FCIP Authors.

Thanks.

Ralph...