Subject: [Ipoverib] RE: ARP vs SIDR

From: "Larsen, Roy K" <[email-masked]>
Date: Fri, 8 Mar 2002 10:47:03 -0800

Jerry,

I wouldn't be in favor of providing optional address resolution methods.
One is plenty and I can live with the currently defined method.

Had I been involved when this topic was first explored, my preference would
have been to do address resolution something similar to what you outlined
below.  Use broadcast ARP/ND to discover the endpoint GID (actually I am in
the camp that prefers to stay within the IB subnet so LID would have worked
for me to keep hardware address length reasonable) then use SIDR to lookup
the LSAP of interest.

For IPoIB, the ServiceIDs would have been derived from the well known
ethertypes.  Enhanced transport capabilities, other than UD, could be
derived with a bit oring function to construct their well-known ServiceIDs
so we have one consistent method for obtaining a QPN.  The private data
field provides a mechanism for returning useful information associated with
an enhanced transport.  It keeps the choice of the number of QPs a node
wants to use for IPoIB/UD a local decision.  Since ARP is involved, the OS
network stack is still handling the ARP/neighbor cache and its semantics.
Because it's ServiceID/LSAP based, this is a general facility that could be
used for other non-IP protocols.  

I realize this would involve three transactions, ARP+SIDR+PathRecord lookup.
But, ARP is a relatively low frequency event on a low latency / high
bandwidth link and this is only three out of may thousands of transactions
with the end node so it's lost in the noise.  If someone felt they could
implement the current address resolution scheme without doing a PathRecord
lookup, then this would definitely add complexity.  Since I don't know how
to do that in a generalized fabric, the extra SIDR adds little complexity to
my design.

I want to be clear.  This is not the start of a campaign to change the
current ARP method.  If folks found it compelling, that would be cool but it
was not meant to spark public debate.  It just provides some backdrop to my
views on encapsulating the LSAP in the IPoIB header given the current APR
method.

Roy

-----Original Message-----
From: H.K. Jerry Chu [mailto:[email-masked]]
Sent: Friday, March 08, 2002 4:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: ARP vs SIDR

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