Subject: [Ipoverib] ARP vs SIDR

From: "H.K. Jerry Chu" <[email-masked]>
Date: Wed, 6 Mar 2002 18:18:44 -0800 (PST)

Roy,

I believe we've made a conscientious choice to use ARP/ND instead of
SIDR in order to be more compatible with IP semantics and implementations.
E.g. if we were to use SIDR instead of ARP, one would have to simulate
ARP flushes (gratuitous ARP) and proxy ARP in SIDR. It can be quite
a headache. It may also require a lot of changes to the existing IP
stack implementation to support IPoIB, which is unacceptable to
most OS vendors.

Jerry

>> > At 11:28 AM 2/26/2002 -0800, Vivek Kashyap wrote:
>> > >         Please comment soon so that the encapsulation draft can be
>> > >         updated and submitted before the cut off of march 2nd.
>> > >
>> > >         For that matter please send in your comments on 
>> the draft(s)
>> > >         in general in the next couple of days so that they can be
>> > >         included before the cut off.
>> > 
>> > For a UD-based IP over IB implementation, Ethertype isn't 
>> required if the 
>> > rest of the IB infrastructure has its act together to allow 
>> non-IP services 
>> > to be properly identified. Hence, I don't have a problem 
>> with it not being 
>> > included within the specification.
>> > 
>> > Mike
>> 
>> Yes, you are right. Ethertype is also not required for RC (or other
>> mode) IP over IB implementations.
>
>But of course, I would assume we wouldn't be using ARP for RC (or other
>modes) either so I'm not sure how this is relevant.  ARP is at the root of
>this "evil".  The IBTA defined SIDR to deal with the situation but we chose
>not to use it.  For connected modes, we'll have to use well-known service
>IDs.  So the logical question readers of our work might ask is, if well-know
>service IDs are be good enough for all the other IPoIB modes, why aren't
>they good enough for UD?  
>
>Now don't get me wrong. I'm *not* asking the group to consider changing the
>UD address resolution mechanism at this late date.  Just pointing out that
>when you stray from using the services provided by the link architecture, it
>causes some awkward and inconsistent design choices.  I think encapsulating
>the LSAP designated by the sender is a way of redeeming the choice of ARP
>because it means the IPoIB protocol becomes self-contained and doesn't rely
>on peeking and interpreting user payload data.
>
>Roy
>
>> 
>> Vivek
>> 
>> > 
>> > 
>> > _______________________________________________
>> > IPoverIB mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/ipoverib
>> > 
>> 
>> 
>> -- 
>> Vivek Kashyap
>> Linux Technology Center, IBM
>> [email-masked] 
>> [email-masked] 
>> 503 578 3422 (o)
>> 
>> _______________________________________________
>> IPoverIB mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipoverib
>> 

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib