Subject: FCIP -03 comments

From: [email-masked]
Date: Wed, 18 Jul 2001 20:32:07 -0400

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Ralph Weber <[email-masked]>
Date: Thu, 19 Jul 2001 15:21:46 -0600

David,

[email-masked] wrote:

..snip..

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

> relationship would be useful.

Will do

> into FC fabrics and fabric operation/behavior over such

Will do

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

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

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

> connected to every other reachable FCIP entity.  That need not

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.

> write the SLP templates and procedures.  See the iSCSI SLP

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.

> please use the word "confidentiality" rather than "privacy"

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.

> is being used.  This needs to be expanded to explain who's responsible

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

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

---

From: Ralph Weber <[email-masked]>
Date: Fri, 20 Jul 2001 06:09:35 -0600

David,

This is a continuation of the response started in a
previous message.

..snip (see part 1)..

> entities behind a single IP address.

The FCIP Authors have agreed to review this issue, but are not
able to resolve it in time to meet the cutoff time at the Internet
Drafts office.

> a pointer to Section 7.4.

A cross reference to section 7.4 will be added in rev 04.

> at least one FCIP Entity, FC_LEP, and FC_DE in a single

I don't know how to use stick figures to communicate the
concept that there can be multiple FCIP_LEPs in which there
are multiple FCIP_DEs in the confined line widths of an
Internet Draft.  I believe that any figure that fails to 
communicate that point is a disservice to the reader.

I will add the requested figure only if it is described
as a requirement for approval and then under protest.

> of an error detected in an earlier frame.

The FCIP Authors expressed similar concerns.  In rev 04, they
already have changed the cited sentence to read:

"In the absence of errors, data bytes arriving at the
Encapsulated Frame Receiver Portal SHALL be de-encapsulated and
forwarded to the FC Transmitter Portal as described in steps 5
through 7."

> protocol-specific fields.

I will do this in rev 05 provided it it confirmed that the IETF
practice is to replicate requirements in multiple RFCs so that
a change in one RFC requires several others to be revised
concurrently.

Will do

> acceptable to deliver malformed traffic to the FC Entity?

The FCIP Authors agreed with you and requested that 'SHOULD NOT' be
changed to 'SHALL NOT'.

> others as SHOULDs or MAYs.

The FCIP Authors had similar problems with the cited text be
changed to:

"Synchronization SHALL be verified on each FCIP Frame. The 
validity and positioning of the following FCIP Frame information 
SHOULD be used to verify synchronization:"

There is an open issue among the FCIP Authors regarding the
need for specificity about what constitutes a loss of
synchronization.  This probably will result in additional 
changes in rev 05 (since the Internet Drafts deadline looms 
too close for resolution in 04).

Examples of conditions that may be declared to be indicators
of loss of synchronization are:

a) failure of the comparison between length and -length
b) two consecutive header errors in other fields

There is a reluctance to standardize on one minimum
list of validation criteria because several equally
valid lists have been proposed.  It is the determination
of the FCIP Authors that choices of validation criteria
have no effect on product interoperability and thus
are not an absolute necessity in FCIP.

> Changes to this section were discussed as part of the Annex

This section is heavily revised in rev 04.

> This section will change as part of the forthcoming synchronization

Unfortunately, there will not be time to get these changes in
rev 04.

> hence some rewording is needed.

The FCIP Authors agree with you but have been unable to get that
work to the top of their to do list yet.

> on timeout management and delete the rest of 7.3.

After QoS the largest count of open issues markers for the FCIP Authors
occur in this area.

> is based on the size of the buffer.

I will note this as an open issue for the FCIP Authors.  I will need
their help constructing such an example.

> and the security gateway will not conform to the security requirements

As with the note on 12 b) in section 5, please post this as a separate 
issue because several of the FCIP Authors believe the described behaviors
are appropriate for FCIP and I cannot represent their opinions.

Thanks.

Ralph...