Subject: RE: [Ipoverib] Summary of the IPoIB link layer address debate (using SLID/SL)

From: "Culley, Paul" <[email-masked]>
Date: Wed, 16 Jan 2002 07:49:22 -0600

When we get out the next version of the IB spec, I think the language
will state that using a multicast SL for unicast need not be supported
by all SMs.  As such, the ARP responder must do a path lookup to make
the unicast response (or somehow know what the SM is up to).  Given
that, the requestor could avoid its own path lookup by using the
SLID/SL.

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

-----Original Message-----
From: Joe Pelissier [mailto:[email-masked]]
Sent: Tuesday, January 15, 2002 7:02 PM
To: [email-masked]
Subject: Re: [Ipoverib] Summary of the IPoIB link layer address debate

Hi Paul,

Here's an interesting question...
For sending the multicast ARP request, I know which SL and MLID to use
since
I am a member of the multicast group.

When I respond to the ARP request, I'm sending unicast.  I know the DLID
to
use, but how do I know what SL to use?  While the IB spec does not
prohibit
me from using the SL in the ARP request packet, it also does not
guarantee
that the SL in the ARP multicast request is valid for the ARP unicast
response.  If the SM is using VL to for deadlock avoidance (a perfectly
reasonable usage), then the ARP response could be lost.

As you stated, once the requester receives the response, it does have a
valid SL to use.  But I think the responder is in a bit of a quandary.

Thoughts?
Joe Pelissier

"Culley, Paul" wrote:

> 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
>
> _______________________________________________
> IPoverIB mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/ipoverib

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

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