Subject: Re: [Ipoverib] RE: ARP vs SIDR

From: "H.K. Jerry Chu" <[email-masked]>
Date: Sun, 10 Mar 2002 01:28:44 -0800 (PST)

Vivek,

>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. 

Agreed. But some new perspective of the use of SIDR for IPoIB/UD hasn't
been discussed in the past.

>
>
>> 
>> 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...)
>
>I think the basic mode should have only one method. The 'advanced'
>features are optional but must interoperate with the basic mode.

Agreed.

>
>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

Yup. That is where I got stuck.

>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.
>
>
>> 
>> 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.)
>
>Isn't what you are proposing the same/similar as the QPN flag that I
>have described in advance-capabilities draft ?

Similar but not quite. I was trying to allow the optional use of SIDR
for the resolution of the QPN used in the *base ARP/ND*. Again the
motivation is to support a persistent/static MAC addr, and a number
of people have asked for this feature.

One solution I can think of is to use a "SIDR supported" flag (or
to extend the meaning of your QPN flag) but also ALWAYS include the
QP # in the hardware address. But this requires hacks on the requester
side to zero-out the QPN from the responder's hardware address when
both sides support SIDR. I don't know if this "hack" is worth pursuing.

Jerry

>
>Vivek
>
>> 
>> 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
>> 
>
>
>-- 
>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