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

From: The IESG <[email-masked]>
Date: Thu, 04 Feb 1999 15:27:30 -0500

The IESG has received a request from the IP Over Fibre Channel Working
Group to consider IP and ARP over Fibre Channel
<draft-ietf-ipfc-fibre-channel-04.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by February 18, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipfc-fibre-channel-04.txt

---

From: Rajeev Atluri <[email-masked]>
Date: Mon, 8 Feb 1999 11:00:02 -0800

Date: Sat, 6 Feb 1999 11:56:57 -0800 (PST)
From: "C. M. Heard/VVNET, Inc." <[email-masked]>
X-Sender: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: Last Call: IP and ARP over Fibre Channel to Proposed Standard
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello,

There are a couple of problems with <draft-ietf-ipfc-fibre-channel-04.txt>
that really should be corrected before it is published as a proposed
standard.

On Page 7 it says:

  3.2.2 Maximally Minimum IPv4 Packet

-    In order to avoid fragmentation in FC, it is useful to specify a
-    minimum size FC Payload size.  This is relevant when a minimum size
-    IP Packet with a fixed size IP Header and a zero byte IP Payload is
-    carried in the FC Payload. More importantly is the case when, the FC
-    Payload carries a maximally minimum size IP Packet, which is defined
-    as an IP packet with a zero byte payload, a fixed size IP Header (20
-    bytes), and the maximum size optional IP Header (48 bytes) [19].

The definition of a maximally minimum size IP Packet is incorrect.  The
marked text ought to say something like:

+    In order for IP fragmentation and reassembly to work properly it is
+    necessary that every implementation of IP be able to transport a
+    maximally minimum size IP Packet without fragmentation.  A maximally
+    minimum size IP Packet is an IP packet with an 8 byte payload (the
+    smallest possible non-zero payload size for a fragment) and a 60 byte
+    header (the largest possible, consisting of a 20 byte fixed part that
+    is always present and a maximum size option field of 40 bytes) [19].

[ ... ]

On Page 9 it says:

  3.4 FC Payload Format

     FC Payload with IP:

     The payload of a FC sequence carrying an IP and ARP packet shall use
     the formats shown in Fig. 4 and 5 respectively. Both formats use the
     8-byte LLC/SNAP header.

-    +-----------------+-----------+------------+-------------//----------+
-    | LLC/SNAP Header | IP Header | Opt. IPHdr.|         IP Data         |
-    |   (8 bytes)     | (20 bytes)| (48 bytes  | (65280 -IP Header       |
-    |                 |           |   Max)     |   - Opt. Hdr.) bytes    |
-    +-----------------+-----------+------------+-------------//----------+

               Fig. 4 Format of FC Sequence Payload carrying IP

The diagram needs to be changed to something like this:

+    +-----------------+-----------+------------+-------------//----------+
+    | LLC/SNAP Header | IP Header | IP Header  |         IP Data         |
+    |   (8 bytes)     | fixed part| options (40|   (65280 bytes less     |
+    |                 | (20 bytes)| bytes max) |    size of IP Header)   |
+    +-----------------+-----------+------------+-------------//----------+

[ ... ]

I grant that these issues are ancillary to the main body of the spec, but
it would be somewhat embarassing for the IETF to publish a standards-track
document that contains misinformation about rather basic IP stuff.

Cordially,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: "Black, David" <[email-masked]>
Date: Mon, 15 Feb 1999 21:28:37 -0500

My apologies for not catching this in WG last call.

> 5.6 FARP Support Requirements
> 
>    Responder action - FARP-REPLY and/or Port Login - for a successful
>    MATCH_WW_PN is always required.
> 
>    Support for all other match Address Code Points is optional and a
>    silent behavior from the Responder is valid when it is not supported.
>    Recipients of the FARP-REQ ELS shall not issue a Service Reject
>    (LS_RJT) if FARP options are not supported
> 
>    In all cases if there are no matches, then a silent behavior is
>    valid.
> 
>    If an implementation issues a FARP-REQ with a Match Address Code
>    Point that is optional, and fails to receive a response, then it may
>    conclude that this particular option is either not supported or there
>    are no address matches.
> 
>    If it concludes, that this Match Address Code Point may not be
>    supported then, it may reattempt the FARP-REQ with the MATCH_WW_PN
>    Code Point.

I think the "may"s in the above two paragraphs are too weak.  They appear
to allow an implementation to issue an optional FARP, get no reply, and
conclude that the respondent is not there, thereby failing to interoperate
with
a compliant implementation.  A possible rewrite is:

   If an implementation issues a FARP-REQ with a Match Address Code
   Point that is optional, and fails to receive a response, then it MUST
   reattempt the FARP-REQ with the MATCH_WW_PN Code Point.

It would be ok to retry the optional FARP on the theory that the first one
was dropped, but eventual reversion to the mandatory codepoint is necessary
for
interoperability.

I believe this reflects the discussion on this point in Orlando.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]
---------------------------------------------------

---

From: Murali Rajagopal <[email-masked]>
Date: Tue, 16 Feb 1999 09:20:08 -0800

I have no problem with David's "intent" but two minor comments:

1.	Can we really mandate a FARP-REQ?
2.	There are other options that the Requester may want to exhaust
before reverting to the MATCH_WW_PN. This might have been implied by the
comment. Right?

-Murali
		-----Original Message-----
		From:	Black, David [mailto:[email-masked]]
		Sent:	Monday, February 15, 1999 6:29 PM
		To:	[email-masked]'
		Cc:	[email-masked]
		Subject:	RE: Last Call: IP and ARP over Fibre Channel
to Proposed Standard

		>    supported then, it may reattempt the FARP-REQ with the
MATCH_WW_PN

		I think the "may"s in the above two paragraphs are too weak.
They appear
		to allow an implementation to issue an optional FARP, get no
reply, and
		conclude that the respondent is not there, thereby failing
to interoperate
		with
		a compliant implementation.  A possible rewrite is:

		   If an implementation issues a FARP-REQ with a Match
Address Code
		   Point that is optional, and fails to receive a response,
then it MUST
		   reattempt the FARP-REQ with the MATCH_WW_PN Code Point.

		It would be ok to retry the optional FARP on the theory that
the first one
		was dropped, but eventual reversion to the mandatory
codepoint is necessary
		for
		interoperability.

		I believe this reflects the discussion on this point in
Orlando.

		--David