Re: FCIP -03 comments

[Ralph Weber <ralphoweber@compuserve.com>]

David,



Black_David@emc.com wrote:

..snip..

> -- Section 2.1
>
> 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.  The seriousness with which
this opinion is held can be seen in the T11 refusal to
internationalize FC-PH.  For this reason, FC-PH does
not belong in FCIP.

FC-PI describes electrical and optical interconnect
technologies as they apply to Fibre Channel.  It does
not belong in FCIP.

FC-FS is in the list in section 2.1, as well it should
be, since it is where the FC Frame format is defined.

> Given the number of FC documents referenced,
> a few sentences describing their contents and
> relationship would be useful.

Will do

> -- Section 2.2
>
> I don't like the tone of the first paragraph in Section
> 2.2.  Can this be rephrased to talk about logical division
> of the problem between carrying FC frames over TCP/IP
> (IETF) vs. integration of TCP/IP that carry FC frames
> into FC fabrics and fabric operation/behavior over such
> links (T11)?

Will do

> The list of requirements for correct operation of an FC
> entity with an FCIP entity in Annex D needs to be exhaustive
> from the viewpoint of the FCIP entity (i.e., everything that
> the FCIP entity needs MUST be listed).

It will be.

In rev 04, the sentence at issue will read:

"The requirements placed on an FC Entity by this specification 
to achieve proper delivery of FC Frames are summarized in annex D."

..snip..

> In the next to last paragraph, in Section 2.2, please use
> the term "programming interface" rather than just "interface"

In response to previous comments on this topic, "API" has
replaced several phrases such as the one mentioned above
in the last two paragraphs of 2.2.  Hopefully, rev 04 will
meet with your approval.

> -- Section 4 Open Issues
>
> Based on an offline discussion with some of the authors, please
> add a note here that the synchronization recovery material,
> including the algorithm in Annex A is known to need revision.
>
> Indicate that the QoS/diffserv wording still needs revision.

The total rewrite of the QoS section is nearing completion and
in all probability will appear in rev 04.

> -- Section 5
>
> Reword 2) and 3) to avoid implying that every FCIP entity is
> connected to every other reachable FCIP entity.  That need not
> be the case in general.

It appears to me that this is achieved by deleting "all" from 2)
and changing "each pair" to "a pair" in 3).  If this not sufficient
more comments will arrive against rev 04.

> In connection with 10), someone needs to take a "to do" item to
> write the SLP templates and procedures.  See the iSCSI SLP
> draft for an example.

Dave Peterson has started but not completed this task.  Or
possibly, Dave has completed the task but the FCIP Authors
have not yet completed the review necessary to incorporate
in FCIP.  In any case, this is in progress and will be done,
but not in time for rev 04.

> Delete 12 b).  If an FCIP entity is operating with an external
> security gateway, only the interface on the public side of the
> gateway is compliant with this specification.  The interface
> between the FCIP entity and the gateway is not compliant because
> it is lacking required security features - the FCIP entity
> *includes* the security gateway in this structure.  Also,
> please use the word "confidentiality" rather than "privacy"
> to avoid confusion.

Please post this as a separate issue because several of the
FCIP Authors believe it is appropriate for FCIP and I cannot
represent their opinions.

> Item 13) is not the entire story when more than one TCP connection
> is being used.  This needs to be expanded to explain who's responsible
> for what in that case.

Unless the FCIP Authors over rule me, "On one TCP connection, ..."
will be added at the beginning of the statement in 13).

> -- Section 6.3
>
> I think this section really needs a discussion about what the
> combination of an FCIP entity with an FC entity linked to a
> pair of corresponding peer entities could be from a Fibre
> Channel viewpoint.  This is the place to say that:
> - it could be an inter-switch link, mentioning B
>         and E ports with a possible reference to FC-BB2
> - it could be a node to fabric link, N port to F port, with
>         a reference to FC-PH
> - it could not be a link in an Arbitrated Loop because FCIP
>         does not support the additional primitive signals
>         and sequences required for an Arbitrated Loop with a
>         reference Section 6 of FC-AL and FC-AL2.

I will propose the following text to the FCIP Authors:

"In general, the combination of an FCIP Link and FC and FCIP Entities 
is intended to replace a Fibre Channel defined connection between 
Fibre Channel components.  For example, this combination can be used 
in place of a hardwire connection between two Fibre Channel switches.  
There are limitations on the generally intended usage of the combination 
shown in figure 3.  For example, the combination cannot be used to 
replace cable in a Fibre Channel Arbitrated Loop because loop primitive 
signals cannot be encapsulated for transmission over TCP.

..snip..

Owing to time constraints, I cannot process the comments beyond
this point right now.  Rather than delay the response, I am
closing the message here.

Ralph...