FCIP -03 comments

[Black_David@emc.com]

As promised, comments from a detailed review of the
-03 version of FCIP.  This is sufficiently extensive
that I don't expect all of them to be addressed in
the -04 version that is expected in the next two days.

--David

-- Section 2.1

Add at least FC-PH to the list of referenced documents
Given the number of FC documents referenced,
a few sentences describing their contents and
relationship would be useful.

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

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).
Having split this between an FC entity and FCIP entity, this
spec needs to be clear about who does what and how they
interact.  If this is not done, it will not be possible
to independently evolve the IETF and T11 documents.  It's
ok to not list everything that the FC entity must do to
work with the FC fabric, and pointing to FC documents in
T11 for that info is fine.

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

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

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

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.

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.

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.

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

-- Section 6.4

   An FC Fabric to IP Network interface product SHALL
   contain one FCIP Entity for each IP Address assigned to the product.

This looks overspecified for a couple of reasons -- it prevents
multiple FCIP entities on different TCP ports at the same IP
address and it appears to force implementation of an FCIP entity
on an interface intended solely for management traffic.  Needless
to say, this is overspecified - I'm guessing that the real requirement
is that an FCIP entity MUST NOT span multiple IP addresses, but
more than one FCIP entity MAY share an IP address by using
different TCP ports.  This has some slight effects on wording
elsewhere, but I fail to see the reason for forbidding two FCIP
entities behind a single IP address.

-- Section 6.5

Last sentence needs to explain what "coordinate flow control"
means, possibly by providing a (non-normative) example, or
a pointer to Section 7.4.

-- Figures 4-6

Should probably have an additional figure that shows
at least one FCIP Entity, FC_LEP, and FC_DE in a single
diagram.

-- Section 6.6

Last sentence:

   Data bytes arriving at the Encapsulated Frame Receiver Portal
   SHOULD be transmitted to the FC Transmitter Portal as described in
   steps 5 through 7, but this MAY NOT always be the case.

In its current form this does not express a useful requirement
and hence the "SHOULD" and "MAY NOT" need to be lower case.  I
think words are needed here to say "MUST be transmitted in the
absence of errors" and note that error detection and recovery
MAY result in discarding frames without errors as a consequence
of an error detected in an earlier frame.

-- Section 6.6.1

Please add a diagram of the whole header in addition to the
protocol-specific fields.

-- Section 6.6.2.1

What is being said here is correct, but needs to be reworded.
Reference the TCP RFC, note that it REQUIRES in order delivery,
generation of TCP checksums and checking of TCP checksums, then
say that hence any traffic passed from TCP to the FC_LEP will
be in order and free of errors detectable by the TCP checksum.

-- Section 6.6.2.2

   Bytes delivered through the Encapsulated Frame Receiver Portal that
   are not correctly delimited as defined by the FC Frame Encapsulation
   [23] SHOULD NOT be forwarded on to the FC Entity.

This sounds like a "MUST NOT" rather than a "SHOULD NOT".  Is it ever
acceptable to deliver malformed traffic to the FC Entity? 

   Synchronization SHALL be verified by checking the validity
   and positioning of any combination of the following FC Frame
   Encapsulation information:

"any combination of" is much too weak - checking only that
the timestamp fields are plausible could result in the delivery
of complete garbage.  Some words may be needed here about the
various error checks done at the FCIP entity, FC entity, and
FC frame receiver (e.g., frame CRC).  Use this to state the
functional requirement of what the FCIP entity MUST check as
as a minimum to ensure correct operation, and then offer the
others as SHOULDs or MAYs.

-- Section 6.6.2.3

Changes to this section were discussed as part of the Annex
E discussion.

-- Section 6.6.2.4

This section will change as part of the forthcoming synchronization
revisions noted above.

-- Section 7.1.1, and 7.1.2

It looks like the FCIP Entities are signaling/negotiating some
parameters over a newly created TCP connection; the details of how this
is done and requirements for doing it need to be specified.  Some of this
interaction is a bit funky - if some of these parameters are passed inband
over the TCP connection, the result is that one has to accept the TCP
connection request in order to get the parameters to decide whether to
accept the TCP connection request.  That wasn't what was intended, and
hence some rewording is needed.

-- Section 7.2 and subsections, Section 7.3

Think very carefully about how many of these are actually involved
in FCIP interoperability, and delete the ones that aren't (e.g.,
7.2.5).  The standards status of TCP options can change independent
of TCP, hence this sort of dependency needs to be minimized.  If 7.2.4
remains, some explanation and/or reference to how to implement this
is needed.  Move the timeout "SHOULD" in Section 7.3 to the section
on timeout management and delete the rest of 7.3.

-- Section 7.4

Need an example of *how* an FC Entity could reduce the rate of
FC Frame arrival (non-normative).  I'm concerned that the last sentence
of this section could be read as a modification to TCP's specified
behavior.  This discussion might be better phrased in terms of buffer
resources available to a TCP connection - when the FC Entity can't
accept frames at their initial arrival rate, the buffer fills up
and TCP's window shrinks accordingly because the advertised window
is based on the size of the buffer.

-- Sections 8.2 and 8.4

Delete and/or modify these in accordance with the comment that
if an external security gateway is used, it is logically a part
of the FCIP Entity because the interface between the FCIP implementation
and the security gateway will not conform to the security requirements
of this specification.

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