FCIP: review comments-1

["Mallikarjun C." <cbm@rose.hp.com>]

Some comments on rev9, excuse me if some/all these were earlier
discussed by the design team.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

> 2. Purpose, Motivation and Objectives
.....
>    Network. Since Fibre Channel and IP Networking technologies are
>    compatible, 

I am not sure what's implied by this sentence....

Generally, I would think that the motivation to extend an FC SAN using 
IP networks is based on the ubiquity of the IP networks.

>    The fundamental assumption made in this specification is that the
>    Fibre Channel traffic is carried over the IP Network in such a
>    manner that the Fibre Channel Fabric and all Fibre Channel devices
>    on the Fabric are unaware of the presence of the IP Network. 

Can someone please comment on the protocol interactions that result in 
the failure to set up an FCIP Link if this latency expectation is not met?

>    2)  apply the mechanism described in 1) to an FC Fabric using an IP
>        network as an interconnect for two or more islands in an FC
>        Fabric.

S/b "an" w/ "the"; S/b "for" w/ "between"

> 3. Relationship to Fibre Channel Standards
.....
>    FC is standardized under American National Standard for Information
>    Systems of the National Committee for Information Technology
>    Standards (ANSI-NCITS) in its T11 technical committee.

I believe ANSI stands for Americal National Standards Institute.  Also, 
NCITS had been changed to INCITS last year.

 >    FC-BB and FC-BB-2 describe the relationship between an FC Fabric and
>    interconnect technologies not defined in by Fibre Channel standards
>    (e.g., ATM and SONET). FC-BB-2 is the natural Fibre Channel home for
>    describing relationships to TCP/IP and FCIP.

This is the first instance of FCIP's usage as a *protocol*.  It would be best 
preceded by a definition of what FCIP means as a protocol.  The previous text 
only describes the objectives of the document, but not the protocol.

> 3.2 This Specification and Fibre Channel Standards
.....
>    No attempt is being made to define a specific API between an FCIP
>    Entity and an FC Entity at this time because doing so risks
>    compromising the performance and efficacy of the resulting products.

I am somewhat concerned that the names are implying an incorrect distribution 
of functionality between "FC Entity" and "FCIP Entity"....  

From the name, I had assumed that FC Entity is simply a standard FC fabric 
element with no FCIP-isms.  But further reading of the document made me realize 
that it in fact knows about the TCP connections and even actively participates in 
QoS and authentication decisions.

As a first time reader, it appears to me that retaining only the FC E_Port functionality 
perhaps additionally providing timestamp and flow control services to the FCIP Entity
(and dropping everything else into the FCIP Entity) may be a lot cleaner distribution 
of functionality.  At any rate, I would like to understand the current distribution rationale.

BTW, can someone please clarify if the expected "role" of the FC Entity on
the FC side is indeed an E_Port?  It appears so from the requirement that FCIP
be totally transparent to the FC fabric, but I don't see it called out in Annex G.

>....fully functional and compliant
>    products can be built provided they contain both an FCIP Entity and
>    an FC Entity. The only products that cannot be built are those that
>    contain only one or the other.

The last sentence seems to stress the obvious at first glance, but I would 
think that products with just the FC Entity should be able to be built (not
that one would...) to act as regular fabric elements with no FCIP features?

Also, I take it that products with two FC Entities and one FCIP Entity 
for ex. are disallowed - but the last sentence seems to imply otherwise.

> 4. Terminology
....

>    FCIP Entity - The principal FCIP interface point to the IP Network
>    (see section 6.4).

This doesn't sound right to me....this definition is more appropriate for FCIP_LEP.
This can perhaps be described as "the entity responsible for the FCIP protocol
exchanges on the IP Network and which encompasses FCIP_LEP(s) and FCIP Control 
& Services module".

> 5. Protocol Summary
...
>    2)  Viewed from the IP Network perspective, FCIP Entities are peers
>        and communicate using TCP/IP. Each FCIP Entity is a TCP endpoint
>        in the IP-based network.

The second sentence seems a little context-sensitive, since each FCIP Entity
can be the TCP endpoint for several TCP connections. 

> 
>    3)  Viewed from the FC Fabric perspective, pairs of FCIP Entities,
>        in combination with their associated FC Entities, serve as an FC
>        Frame transmission component of the FC Fabric. The FC End Nodes
>        are unaware of the existence of the FCIP Link.

Can a "FC Frame transmission component" be something other than an E_Port?

>    6)  An FCIP Entity MAY contain multiple FCIP Link Endpoints, 

I would add "each of which MAY service multiple TCP connections, " here...

>but
>        each FCIP Link Endpoint (FCIP_LEP) communicates with exactly one
>        other FCIP_LEP.
> 
>    7)  When multiple FCIP_LEPs with multiple FCIP_DEs are in use,
>        selection of which FCIP_DE to use for encapsulating and
>        transmitting a given FC Frame is outside the scope of this
>        document. FCIP Entities do not actively participate in FC Frame
>        routing.

Couple of comments on this bullet (7) - 

Let's consider the case of multiple FCIP_DEs in one FCIP_LEP.
This draft does not specify how each inbound FC frame from the 
FC fabric is distributed onto one of these FCIP_DEs (TCP connections).   
Where is it specified in wrt routing on TCP connections?  I take it that 
the regular FC fabric routing rules aren't quite applicable in this case.

To stress the obvious, I think we should have some standard covering
this case - else we will end up with frames destined to the same D_ID
being striped on multiple TCP connections, and thus ending up OOO.

>    13) On a given TCP Connection, this specification relies on TCP/IP
>        to deliver a byte stream in the same order that it was sent.

Perhaps we should add - ", but allows confirmation of the same for each 
frame by checking the FCIP and FC CRCs."....

> 6.3 FC Entity
....
>    the combination shown in figure 3. As another example, the
>    combination cannot be used to replace cable connections in a Fibre
>    Channel Arbitrated Loop because loop primitive signals cannot be
>    encapsulated for transmission over TCP.

I am not sure the last sentence is needed since figure 3 is explicit 
about the usage of fabrics.

> 6.4 FCIP Entity
.....

>    The FCIP Entity is the connection interface point for the IP Network

As commented earlier, the "connection interface point" doesn't sound totally
correct - I would suggest "interfacing element" instead.

>    and is the owner of the IP Address and Well Known Port used to form
>    TCP Connections. An FC Fabric to IP Network interface product SHALL
>    provide each FC Entity FCIP Entity pair contained in the product

May I suggest a new term "FC-FCIP Pair" in place of "FC Entity FCIP Entity pair ".
I think it improves the general readability.

>    FC Entity with an interface to key IP Network features. The
>    interfaces to the IP Network features is implementation specific,
>    however, to maintain interoperability, the notable TCP/IP mechanisms
>    used are specified in this document as follows:

I think the last sentence is incorrectly implying interoperability issues
around the (private) FC Entity-FCIP Entity interface.

I would suggest a rewrite for the last sentence as something like -

"The interfaces to the IP Network features are implementation-specific.
  To aid interoperability, this document specifies the notable TCP/IP Network 
  features that are typically used ."

> 6.5 FCIP Link Endpoint (FCIP_LEP)
....

>An FCIP_LEP
>    MAY communicate with its FC Entity counterpart to coordinate flow
>    control.

Suggest adding the phrase "across the domains".

> 6.6 FCIP Data Engine (FCIP_DE)
.....
>    7)  In the absence of errors, the de-encapsulated FC Frame and time
>        stamp SHALL be passed to the FC Transmitter Portal for delivery
>        to the FC Entity.

It is nice to add a sentence about the handling in the presence of errors.
At a minimum, this should provide a cross-reference to the error detection
section.

> 6.6.1 FCIP Encapsulation of FC Frames
....
>    The FCIP Special Frame SHALL only be sent as the first bytes
>    transmitted in each direction on a newly formed TCP Connection and
>    only one FCIP Special Frame SHALL be transmitted in each direction
>    at that time (see section 9.1). After that all FCIP Frames SHALL
>    have the SF bit set to 0.

This para seems slightly out of context here, and perhaps should be moved
to section 9.1.  This usage semantics should ideally be preceded by what *is* 
a Special Frame and its purpose - though I could gather that from the 
usage and format descriptions in the entire document, I don't really find a
place where its purpose is defined...

> 
>    Table 1 summarizes the usage of the pFlags SF and Ch bits.

- It may be useful to add a protocol-specific bit to distinguish originated vs
echoed SF, so the parsing and validation can be self-contained.

- Also, I think a sentence should be added which says that the -pFlags field 
SHALL contain the ones-complement of the pFlags field.