Subject: [Ipoverib] RE: ARP vs SIDR

From: "H.K. Jerry Chu" <[email-masked]>
Date: Fri, 8 Mar 2002 04:39:22 -0800 (PST)

Roy,

To use SIDR one must obtain the remote IB node address (GID or LID)
first. THerefore an "IP to IB" address resolution protocol is still
required. (It'd be a two steps resolution process: ARP/ND for GID
followed by SIDR for UD-QPN.)

I've proposed the *optional* use of SIDR for resolving the UD-QPN. This
way we can exclude QPN from the "IPoIB link layer addr" thereby
providing some additional property such as static hardware addr
(one that doens't change across system reboot). But I couldn't figure
out a way to make the use of SIDR truly optional (e.g. if node A decides
to use SIDR, it may require all the remote nodes communicating with
itself to also use SIDR...)

If enough people think the above is useful and the requiring of SIDR
for IPoIB is acceptable, we can still pursue it. (It only requires
a flag "use-SIDR" being added to the hardware addr.)

Rgds,

Jerry

>From: "Larsen, Roy K" <[email-masked]>
>To: "'H.K. Jerry Chu'" <[email-masked]>
>Cc: [email-masked]
>Subject: RE: ARP vs SIDR
>Date: Thu, 7 Mar 2002 09:34:40 -0800 
>MIME-Version: 1.0
>
>But then, 20 byte hardware addresses, PathRecord lookups in the ARP path,
>and peeking into network headers don't fit well in existing network stacks
>either.  But alas, I joined the reflector too late to participate in the
>early address resolution discussion, and as my mail said, I was *not*
>attempting to have this group change its address resolution method.  Just a
>cautionary note about straying from long standing network practices and
>underlying link architecture.
>
>Roy
>
>-----Original Message-----
>From: H.K. Jerry Chu [mailto:[email-masked]]
>Sent: Wednesday, March 06, 2002 6:19 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: ARP vs SIDR
>
>
>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

---

From: Vivek Kashyap <[email-masked]>
Date: Fri, 8 Mar 2002 17:22:19 -0800 (PST)

Roy, Jerry,

I don't think we need to go down this path again. The WG has agreed on
a process for address resolution, the reasoning can be found in the
archives. 

> itself to also use SIDR...)

I think the basic mode should have only one method. The 'advanced'
features are optional but must interoperate with the basic mode.

Keeping this in mind, I have defined a mode in
draft-kashyap-ipoib-advanced-capabilities-00.txt that I call the
IPoIB-QPN. This mode allows for exchanging the QPNs using SIDR. The
ARP process as defined in the encapsulation draft MUST be supported
though. The QPN capability flag tells the other end if the SIDR
process is supported by the peer for IP ServiceIDs. The
advanced-capabilities draft also describes the serviceIDs and how the
QPNs would be resolved. BTW, SIDR is an optional feature as per IBA.

Merely, providing a flag and not exchanging the QPN will cause
incompatibilities with the implementations not supporting 'advanced
features'. The capability-flags allow the nodes with the 'advanced'
features to follow SIDR or setup RC/other connections as desired and
supported by the two nodes. The whole process still interoperates
seamlessly with IPoIB over UD mode that we have been discussing.

> a flag "use-SIDR" being added to the hardware addr.)

Isn't what you are proposing the same/similar as the QPN flag that I
have described in advance-capabilities draft ? 

Vivek