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

From: Raj Bhagwat <[email-masked]>
Date: Tue, 1 Dec 1998 09:39:51 -0800

Jon,

My feeling is that Inverse ARP  feature will not be very useful if we make
responding to Inverse ARP Request optional. This is true for any feature in
general. If there is no guarantee that a station would respond to Inverse
ARP Request, I will be less inclined to use it because it cannot be a true
alternative to using ARP.

My belief is that we first need to get the standards specified and
implementations will follow. Even if Windows NT and UNIX IP stacks don't
support Inverse ARP currently, they will eventually if there is a need.

Regards,

Raj Bhagwat
Gadzoox Networks, Inc.

> -----Original Message-----
> From: Infante, Jon [mailto:[email-masked]]
> Sent: Monday, November 30, 1998 3:05 PM
> To: 'Baldwin, Dave'; 'Raj Bhagwat'
> Cc: [email-masked]'
> Subject: RE: Last Call: IP and ARP over Fibre Channel to Proposed
> Standard
> 
> 
> 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,
> 
> 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.
> 
>
>

---

From: "Infante, Jon" <[email-masked]>
Date: Tue, 1 Dec 1998 11:55:36 -0800

Raj,

< My belief is that we first need to get the standards specified and
< implementations will follow.Even if Windows NT and UNIX IP stacks don't
< support Inverse ARP currently, they will eventually if there is a need.

My opinion is if InARP support is manditory, initial implementations
will either be

1) Poor performance because they have to check every packet they
    recieve to see if its an InARP packet.  or be
2) non compliant because the information needed to implement InARP
    is not available to a driver.

I feel the standard we specify needs to reflect what is out there in the real 
world today.  Waiting for Windows NT and UNIX IP stacks to accomidate
our fcip standard could be a loooong wait. 

Also, at this stage in the standards process, lets make it easier for 
initial implementations to get out. Manditory InARP support opens
an implementation can of worms that will hamper us in the 
standardization process.

Jon Infante
Emulex