Re: FCIP -03 comments (part 2)

[Ralph Weber <ralphoweber@compuserve.com>]

David,

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

Black_David@emc.com wrote:

..snip (see part 1)..

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

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.

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

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

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

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.

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

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

> -- Section 6.6.1
>
> Please add a diagram of the whole header in addition to the
> 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.

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

Will do

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

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

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

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.

> -- Section 6.6.2.3
>
> Changes to this section were discussed as part of the Annex
> E discussion.

This section is heavily revised in rev 04.

> -- Section 6.6.2.4
>
> This section will change as part of the forthcoming synchronization
> revisions noted above.

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

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

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

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

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

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

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

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

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