RE: questions/suggestions on <draft-ietf-ips-fcovertcpip-06.txt>

[Robert Snively <rsnively@Brocade.COM>]

> 1. section 4->4) Class 1 FC frames( and some signals) are not 
> transmitted
> across an FCIP link. Since purpose of FCIP is to replace 
> end-to-end fiber.
> So, how these frames will be transferred ?

Class 1 is connection oriented and requires 100% guaranteed
bandwidth the whole length of the link.  TCP/IP cannot support
that behavior reliably.  This did not hurt anybody's feelings
because class 1 is principally a legacy implementation.

> 
> 2. section 5.2 , fig. 2 FCIP Link Model is little bit 
> confusing. Instead of
> writing FCIP on one side and Link on other side, it will be 
> good if FCIP
> Link is written both side.
> 

The intent here is that the IP network as well as the two
wires to the FC Fabric be interpreted as a single link.

> 3. section 5.6.2.1 and 5.6.2.2. If someone is doing TCP 
> checksum validation,
> is it required to do 5.6.2.2 checks ? At least test j) is not 
> required ?
> 

The required checking is specified because the TCP checksum
validation (which of course is assumed to be present) has proven
less than perfectly reliable in some environments.  The tests
are required according to the explanations.  Verification of
length and length redundancy is required.  At least some other
verifications are a very good idea.

> 4. Once TCP payload will have only one FC frame or it can 
> have multiple FC
> frame ? Its not mentioned anywhere, but from the section 
> 5.6.2.2 and 5.6.2.3
> it seems to me that it can have multiple FC frame ? 

There is no relationship between a TCP payload or segment and the
FC frame boundaries.  That is the nice thing about TCP.  It simply
delivers a string of reasonably well checked bytes in the proper
order and lets the upper layers choose what to do with them.
As a result, a TCP payload may have a fraction of a frame,
fractions of two frames, fractions of two frames and one or more
whole frames, exactly one whole frame, or multiple whole frames.
FCIP does not care, as long as the transmission of a TCP payload 
is not unduly held up waiting for enough information to make it
a certain size.  Realistically, I would expect that many implementations
will at least start a TCP segment on an encapsulated frame boundary, 
but only end on a frame boundary if there was no additional information to
throw into the segment, but that is NOT part of the architecture.