Subject: RE: [Ipoverib] Summary of the IPoIB link layer address debate (proxy Arp)

From: "Culley, Paul" <[email-masked]>
Date: Wed, 16 Jan 2002 08:12:54 -0600

Forgive me for perhaps not understanding how proxy ARP works; but I was
under the impression that a proxy ARP device was two way.  That is, if
some device was "fronting" for the actual device, then it would provide
the ARP service, including ARP replies, and ALSO, pass the data comm
packets through that interface to another network.

If such a device were to be used for IB, it seems to me that it would
behave properly.  When replying to ARP, the unicast ARP response's
SLID/SL would point back to the proxy device, which is also responsible
for passing the data packet to some other interface.

On another subject, Use of any sort of LID in the ARP response; I have
these comments:

1) Unless the ARP Requestor has some (IB approved) way to find an
appropriate SL, it must still do the PathRecord lookup.  So providing
only LID seems inadequate.

2) While IB does not yet have routers finished, it will someday.  Unless
you prohibit multiple IB subnets per IP subnet, when that day arrives,
the ARP Responder will have NO IDEA on what an appropriate LID is to
place in the body of the ARP Response.  If the idea of using SLID/SL is
accepted, then the router will be modifying that field as the ARP
response passes through, so that it will point back to the router, and
thus be suitable for communication.

3) If you decide to include the LID in the ARP response body, please
point out to implementers when it may not be valid; for instance, it
should be considered invalid whenever the GID prefix in the ARP response
does not match the GID prefix of the ARP requestor.

Paul R. Culley
Compaq Sr. Fellow
281-514-5543

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 12:55 AM
To: Culley, Paul
Cc: Vivek Kashyap; Roger Ronald; [email-masked]
Subject: Re: [Ipoverib] Summary of the IPoIB link layer address debate

        Sure, the received SL can be used. It is allowed and
        guaranteed by the IBTA spec to work when using UD. The
        response should be going back to the sender though. The LID
        could also be picked. However, for ARP this won't work since
        it doesn't work with proxy ARP. The sender is fronting for
        someone else. 

	Vivek

> 
> As has been pointed out several times in the past, a unicast ARP
> response packet already includes the LID and an SL, both of which are
> guaranteed (by IBA Spec) to be valid for sending (small) packets back
to
> the source of the ARP response packet.
> 
> Since this is already present in the IB Datagram header (LRH:SLID,
> LRH:SL) and can be easily retrieved by HCAs built to the IB
> Specification, I cannot see any point in adding a LID to the unicast
> response.
> 
> Paul R. Culley
> Compaq Sr. Fellow
> 281-514-5543
> 
> 
> -----Original Message-----
> From: Vivek Kashyap [mailto:[email-masked]]
> Sent: Tuesday, January 15, 2002 4:30 PM
> To: Roger Ronald
> Cc: Vivek Kashyap; [email-masked]
> Subject: Re: [Ipoverib] Summary of the IPoIB link layer address debate
> 
> 
> > 
> > It seems like the general debate that's raging is trying to answer 
> > a single question:
> > 
> > "Is it wise to include the LID in order to enable a
> > shortcut that allows bypassing a trip to the SM/SA?"
> > 
> > My read is that second party dissemination of LIDs is not 
> > something that is prohibited (per the IBTA rules), but it is a
> > shortcut that the IBTA architects weren't expecting
> > and are uncomfortable seeing. Various objections
> > about PathRecords, rate control, SL, and MTU have
> > been mentioned, but don't seem to make for a conclusive
> > decision point.
> > 
> > In the end, the tradeoff seems to be simplicity versus
> > flexibility. Leaving out the LID makes the header
> > smaller and the processing is always done in one
> > way. Putting the LID into the header allows
> > skipping a step under (at least) some circumstances.
> 
> Leaving out the GID makes the header a lot less smaller. I am not sure
> what process is done in one way ? If you are talking about spanning IB
> subnets with a single IPoIB subnet the process is definitely not done
> in a single way. It is more easily a single way if the LID is used.
> This is noted in my note below.
> 
> 
> > > applies all over IB components and is not limited to LIDs/GIDs.
> > > 
> > > Let us first answer the question of why IPoIB subnets must span IB
> > > subnets ? We don't know why we need such a setup ? We don't know
> when
> > > such a setup will be possible ? We do know that IPoIB subnets
within
> > > an IB subnets can be setup easily with the current specification.
> > > 
> > > 
> > > Secondly, if you step back you'll realise that LID is hardly an
> issue
> > > when resolving across subnets. Unlike what has been postulated the
> > > process is not the same when resolving within the IB subnet and
when
> > > resolving across the IB subnet. 
> > > 
> > > Assumption: at IP level- a multicast request; receive a unicast
> reply
> > > 
> > >         Now, when sending the broadcast the sender doesn't know
> where
> > >         the responder is. So he includes his LID/GID. The receiver
> > >         gets it across multiple subnets. It gets sees a different
> > >         GID-prefix and hence replaces the LID with its default
> router
> > >         when recording the address. The same happens on the
> response.
> > > 
> > >         It works fine for both situations - IPoIB subnets
> > >         within/across IB subnets. You can easily have it that if
the
> > >         GID is local the routing lookup will return the local LID.
> > >         Single process.
> > > 
> > >         In the case of not including the LID you do the same
thing.
> If
> > >         the GID prefix is local you go to the SM/SA to get the
LID.
> If
> > >         the GID prefix is different you record your default
router's
> > >         LID. So the process for across the subnet is the same but
> you
> > >         shortchange the implementation that is more likely - the
one
> > >         whithin the subnet.
> > > 
> > >         For within the subnet you use a different method - going
to
> > >         The SA always. Not the same as going to the routing
> > >         infrastructure. 
> > > 
> > > However, I would still like to know what is the use of IPoIB
> spanning
> > > multiple subnets. Why do you think that is a requirement ?
> > > 
> > > 
> > > Vivek
> > > -- 
> > > Vivek Kashyap
> > > Linux Technology Center, IBM
> > > [email-masked] 
> > > [email-masked] 
> > > 503 578 3422 (o)
> > > -- 
> > > Vivek Kashyap
> > > Linux Technology Center, IBM
> > > [email-masked] 
> > > [email-masked] 
> > > 503 578 3422 (o)
> > > 
> > > _______________________________________________
> > > IPoverIB mailing list
> > > [email-masked]
> > > http://www.ietf.org/mailman/listinfo/ipoverib
> > > 
> > > 
> > 
> > 
> > _______________________________________________
> > IPoverIB mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/ipoverib
> > 
> 
> 
> -- 
> Vivek Kashyap
> Linux Technology Center, IBM
> [email-masked] 
> [email-masked] 
> 503 578 3422 (o)
> 
> _______________________________________________
> IPoverIB mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/ipoverib
> 

-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)

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

---

From: "Roger Ronald" <[email-masked]>
Date: Wed, 16 Jan 2002 08:41:23 -0600

Your question/point #3 is actually answered by your introduction :-)

The local LID of a bridging device may be a valid local address 
to use for a distant IB subnet (or bridged Ethernet). So
the shortcut of using the LID from an ARP reply 
is not necessarily invalid even if the destination is not local.

Perhaps the ARP reply should contain a field for LID that is zero'ed
if the source knows that a LID will not work, but is filled in if the source
knows that using the LID will work. With this behavior, either the source
or the destination can disallow the shortcut and the shortcut will
only be possible if BOTH sides agree it will work.

RR
----- Original Message ----- 
From: "Culley, Paul" <[email-masked]>
Sent: Wednesday, January 16, 2002 8:12 AM
Subject: RE: [Ipoverib] Summary of the IPoIB link layer address debate (proxy Arp)

<snip>
> if some device was "fronting" for the actual device, then it would provide
<snip> 

> does not match the GID prefix of the ARP requestor.
<snip>