Subject: RE: [Ipoverib] Summary of the IPoIB link layer address debate

From: "Culley, Paul" <[email-masked]>
Date: Tue, 15 Jan 2002 16:56:11 -0600

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

---

From: Joe Pelissier <[email-masked]>
Date: Tue, 15 Jan 2002 17:02:03 -0800

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

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 15 Jan 2002 22:55:20 -0800 (PST)

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