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

From: The IESG <[email-masked]>
Date: Tue, 17 Nov 1998 13:30:55 -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-03.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 December 1, 1998.

Files can be obtained via
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfc-fibre-channel-03.txt

---

From: "Talluto, Dennis" <[email-masked]>
Date: Fri, 20 Nov 1998 10:46:37 -0500

Sorry for the duplication if you have already received, but I did not see
the original come across the reflector.

Dennis Talluto
EDS/Infrastructure Systems Templates
office: 248.853.3521
email:  [email-masked]

> ----------
> From: 	Talluto, Dennis
> Sent: 	Thursday, November 19, 1998 11:11 AM
> To: 	'Ryohei Nakayama'
> Cc: 	'ipfc reflector'; [email-masked]'; [email-masked]'
> Subject: 	Re: Last Call: IP and ARP over Fibre Channel to Proposed
> Standard
> Importance: 	High
> 
> Nakayama-san,
> 
> I am forwarding your comments to the appropriate industry reflectors
> ([email-masked]; [email-masked]; [email-masked]).
> 
> Please feel free to submit comments directly to the reflectors yourself.
> In this manner, others will receive the messages directly, and will be
> able to respond directly to you as well.  Feel free to pass this message
> along to others in FCA-Japan as well.
> 
> Thank you for your comments.
> 
> Regards,
> 
> Dennis Talluto
> EDS/Infrastructure Systems Templates
> office: 248.853.3521
> email:  [email-masked]
> 
> 
> ----------
> From: 	Ryohei Nakayama[SMTP:[email-masked]]
> Sent: 	Wednesday, November 18, 1998 11:36 PM
> To: 	Talluto, Dennis
> Subject: 	[fcaj] ??????????
> 
> Dear Mr. Dennis Talluto
> 
>   The following is my comments about the specifications of IETF-IPFC-Fibre
> Channel-03.
> (1) "Sequence streaming" should be allowed to avoid the degradation of the
> throughput in the long disance transmission, especially between FC
> networks
> through a wide area network defined by FC-BB.
> (2) In addition to ABTS_LS, "Discard a single Sequence" Abort condition
> should be allowed, because each IP packet is composed of a single Sequence
> and IP packets can be retransmitted by TCP protocol.
> 
>   I am a principal member of Fibre Channel Association, and I am very
> interested in the standardization of IP over FC. If you will have the
> meeting that is open to any companies, please let me know. I am ready to
> attend that meeting.
> 
>   Best regards,
> 
> Ryohei Nakayama
> 
> Communication Assessment Laboratory
> NTT Multimedia Networks Laboratories
> 9-11, Midori-Cho 3-Chome, Musashino-Shi, Tokyo 180-8585 Japan
> Voice: +81 422 59 2015
> FAX:   +81 422 59 2829
> E-mail : [email-masked] 
> 
> >  
> >  I encourage all companies with a vested interest in IP/FC to review the
> >  Proposed Standard, and ensure that the documentation meets industry
> >  expectations for a solid specification.
> >  
> >  Dennis Talluto
> >  EDS/Infrastructure Systems Templates
> >  office: 248.853.3521
> >  email:  [email-masked]
> >  
> 
>

---

From: "Talluto, Dennis" <[email-masked]>
Date: Thu, 19 Nov 1998 11:11:42 -0500

Nakayama-san,

Please feel free to submit comments directly to the reflectors yourself.  In
this manner, others will receive the messages directly, and will be able to
respond directly to you as well.  Feel free to pass this message along to
others in FCA-Japan as well.

Regards,

Dennis Talluto

---

From: Raj Bhagwat <[email-masked]>
Date: Mon, 23 Nov 1998 15:07:11 -0800

I would like to submit a request to include Inverse ARP capability to the
IPFC draft. I think it will be very useful in certain environments as
described below.

In a private loop environment devices typically do extensive polling to
discover other devices. As part of the discovery, they PLOGI into each
device and find out the World Wide Port Name & Port Id among other things
for each device. However, as part of the discovery, it is not possible to
learn the IP address of the device. If we could do this somehow, then the
device can build a table for IP_Addr to WWPN mapping and use it later
without resorting to sending ARP request through Open Replicate.

Inverse ARP is extensively used in WANs, especially Frame Relay. It is easy
to implement. The frame format is exactly similar to ARP Request/Reply. Only
the opcodes are different. The requesting station fills the hardware address
field with the WWPN of the target device and leaves the protocol address
field as zero. The request is sent to a specific station that has the
matching WWPN. The receiving station will fill in its IP address in the
target protocol address field and send the response back.

This mechanism would accommodate stations that don't support Open
Replicates.

Raj Bhagwat
Gadzoox Networks

>
> -----Original Message-----
> From:	The IESG [mailto:[email-masked]] 
> <mailto:[mailto:[email-masked]]>
> Sent:	Tuesday, November 17, 1998 10:31 AM
> Cc:	[email-masked]
> Subject:	Last Call: IP and ARP over Fibre Channel to 
> Proposed Standard
> 
>

---

From: Raj Bhagwat <[email-masked]>
Date: Tue, 24 Nov 1998 18:13:49 -0800

Dave,

I agree with you. All stations should be able to receive ARP and FARP
Requests sent as broadcast. I am proposing Inverse ARP as an alternative to
sending ARP Request for address resolution. Some devices may prefer this
approach. They are still required to respond to ARP and FARP Requests sent
by others. Hope this clarifies what I was trying to describe.

Regards,

Raj.

> From: Baldwin, Dave [mailto:[email-masked]]
> Sent: Tuesday, November 24, 1998 10:15 AM
> To: 'Raj Bhagwat'
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: Last Call: IP and ARP over Fibre Channel to Proposed
> Standard
> 
> 
> Raj,
> 
> You state "This mechanism would accommodate stations that 
> don't support Open
> Replicates.". I strongly object to this statement. All FC-AL 
> devices are required to support Open Replicate to the extent 
> that they pass the frame on to the next device. If you are 
> suggesting that a device can comply with the IPFC standard 
> without properly responding to a FARP-REQ (MATCH_WW_PN), this 
> will lead to serious interoperability problems.
> 
> I don't have any problem with allowing Inverse ARP in the 
> IPFC standard as an optional behavior, as long as all 
> compliant devices are required to handle the FARP-REQ mechanism.
> 
> Best regards,
> Dave Baldwin
> Emulex Network Systems
>

---

From: Raj Bhagwat <[email-masked]>
Date: Mon, 30 Nov 1998 13:36:01 -0800

Dave,

Yes, responding to Inverse ARP Requests should be a requirement. This
requirement applies only if the target device supports IP. Otherwise, it
does not have to respond.

If we don't make this a requirement, then the requesting station has no way
of knowing whether the target device does not support IP or if it simply
chose not to respond even when it supports IP.

Regards,

Raj.

> Sent: Monday, November 30, 1998 12:30 PM
> To: 'Raj Bhagwat'
> Cc: [email-masked]'
> One thing you have not answered:
> 
> Will responding to Inverse ARP be a requirement, or is it an 
> optional behavior?
> 
> Best regards,
> Dave Baldwin
> 
> ----------
> From: 	Raj Bhagwat
> Sent: 	Tuesday, November 24, 1998 6:13 PM
> To: 	'Baldwin, Dave'
> Cc: 	[email-masked]'
> Subject: 	RE: Last Call: IP and ARP over Fibre Channel to 
> Proposed Standard
> 
> Dave,
>

---

From: "Baldwin, Dave" <[email-masked]>
Date: Mon, 30 Nov 1998 12:30:03 -0800

Raj,

Will responding to Inverse ARP be a requirement, or is it an optional behavior?

Best regards,
Dave Baldwin

----------
From: 	Raj Bhagwat
Sent: 	Tuesday, November 24, 1998 6:13 PM
To: 	'Baldwin, Dave'
Cc: 	[email-masked]'
Subject: 	RE: Last Call: IP and ARP over Fibre Channel to Proposed Standard

Dave,

Regards,

Raj.

---

From: "Infante, Jon" <[email-masked]>
Date: Mon, 30 Nov 1998 15:05:10 -0800

Raj,

   I agree with Dave in that it should be optional.

   Its pretty safe to to assume all target devices that support IP
   also support ARP.  Assuming that everyone also supports InARP
   is not safe to do.  In some of the  environments (Windows NT,
   AIX, Unixware, Solaris) that our driver runs in, I can't be sure if
   InARP is supported or not??  Are you suggesting the driver needs
   to look at the data for InARP packets in operating environments
   that don't support InARP or have InARP configured?

Jon Infante

----------
From: 	Raj Bhagwat
Sent: 	Monday, November 30, 1998 1:36 PM
To: 	'Baldwin, Dave'
Cc: 	[email-masked]'
Subject: 	RE: Last Call: IP and ARP over Fibre Channel to Proposed Standard

Dave,

Regards,

Raj.