Subject: Re: Last Call: IP and ARP over Fibre Channel to Proposed Standard

From: Matt Wakeley <[email-masked]>
Date: Thu, 03 Dec 1998 17:51:37 -0800

A few comments on the IP and ARP over Fibre Channel 03
<draft-ietf-ipfc-fibre-channel-03.txt> draft:

Section 3.1, page 5:
There is text "(Care should <be> exercised when this is the case. Note that
the physical temporal ordering of the frames can be different as a result of
traversing through a "Fabric".)"
What is the concern?  If there is a concern, it should be specified, and
remedied.  Especially given the fact that the Network_Header is required
(shall) in the previous sentence.

Section 3.3, page 6:
There is text "In a single port Node, the WW_NN and the WW_PN may be
identical."
This is not true.  The FC community determined that the WW_NN and WW_PN space
must be unique within each other.

Section 3.4, page 7:
There is text "As noted earlier, since FC frames belonging to the same
Sequence can be delivered out of order over a Fabric, the IP Header must
appear in the frame that has relative offset of 0."
This contradicts 8.3 F_CTL which indicates that Relative Offset is "settable"
and 8.8.2 which indicates that RO is optional. Either 3.4 needs to be
modified to be "offset of 0 or the first frame of the sequence (SOFix)" or
the table needs to be modified such that RO is required.

Section 3.5, ARP Packet Format:
Why isn't there support for IPv6? (text says the 'Protocol Addr Length' field
*shall* be 0x04).
Also, wouldn't it be more clear if the phrase "...the 6 byte IEEE MAC
address..." was replaced with "...the lower 6 bytes of the WW_PN..."?

Section 8:
What is the status of items not listed in the tables?  For example, there are
other fields in the F_CTL word that are not listed.  Specifically, the
"ACK_Form" bits should be settable.

Section 8.3, note 1:
The text "For FC-4 frames, each N_Port shall have a dedicated OX_ID for
sending data to each N_Port in the network and a dedicated RX_ID for
receiving data from each N_Port as well." requires a dedicated RX_ID which
contradicts 8.5 which indicates RX_ID is optional.  The text "and a dedicated
RX_ID for receiving data from each N_Port as well" should be deleted.

Section 8.3, note 1 and 8.5, note 4
Note 1 indicates that sequence initiative is not transferred.  However, if an
exchange responder node is running class 3 and requires RX_ID, how is it to
communicate it's RX_ID to the exchange originator if the originator cannot
transfer initiative?  SI transfer should also be allowed for Basic Link
Services.

Section 8.3, note 3:
The is text "For classes 1 and 2, ACK frame is required to be "continuous
sequence"."  "Continuos sequence" is not defined.  I'm assuming you mean
"continue sequence".  But if this is the case, that means that a sequence
recipient has no way to abort a sequence sent to it.  The text should be
deleted, and allow normal FC-2 layer processing to proceed.

Section 8.4
Sequence streaming is prohibited.  It should be allowed if the two nodes are
able to handle it (negotiated via login).  This also contradicts note 1.

Section 8.4, note 7.
Note 7 should indicate that ACK_0 may be used if negotiated at login or is
indicated by the F_CTL ACK_Form bits.

---

From: Matt Wakeley <[email-masked]>
Date: Thu, 03 Dec 1998 17:51:37 -0800

Section 3.1, page 5:

Section 3.3, page 6:

Section 3.4, page 7:

Section 8:

Section 8.3, note 1:

Section 8.3, note 3:

Section 8.4

Section 8.4, note 7.