Subject: RE: [Ipoverib] BOOTP/DHCP chaddr field

From: "Culley, Paul" <[email-masked]>
Date: Sun, 17 Mar 2002 07:03:55 -0600

embedded...

Paul Culley
Compaq Sr. Fellow
281-514-5543

-----Original Message-----
From: H.K. Jerry Chu [mailto:[email-masked]]
Sent: Saturday, March 16, 2002 11:37 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ipoverib] BOOTP/DHCP chaddr field

Vivek,

...
<snip>
>> >Alas, a LID-based hardware address would be my first choice too.
>> 
>> Or keep GID but drop QPN and use SIDR as you've mentioned too.
>> 
>
>I am more open to using LID + QPN rather than GID + SIDR.
>
>For example a simple issue with SIDR and DHCP:
>
>        As noted by Akihiko, and I agree, there may be multiple IPoIB
>        interfaces over the same port but these interfaces would have
>        different QPNs. Greater than one IPoIB interface per port and
>        the server or the client side CM have no way to determine the
>        QPN to send back; server doesn't have a good distinguishing
>        value to give to the client CM.

I think it's a stretch to use different QPs to build multiple
"virtual" interfaces. P_Key is the perfect mechanism for that.
<prc> If there are multiple P_Keys in use for IPoIB on a single port
(quite possible in my opinion), then they must be using different QPs.
Only one P_Key to a QP, remember?
<endprc>

 If one
wants multiple interfaces out of the same node to the same IP link,
one add multiple HCAs/ports. Different QPs attched to the same HCA
port has the same hardware failure domain so I don't see what value
it buys. If this is for load-balancing purpose one will probably have
to resort to SIDR like you have suggested anyway. Using GID leaves no
room for any additional flag in the hardware address. But since SIDR
must be consulted now, all the advanced functions can be moved there.

The above is just some of my own preliminary thoughts. I hate to go
down this route of debating hardware address format again unless we
decide against the broadcast flag workaround.
<prc> The broadcast work around seems quite adequate to me <endprc>

I'm glad this DHCP issue is brought up now, not later (thanks Roy!).
I wonder how many other issues are lurking out there. I encourage
everyone to go through the current draft proposals very carefully
(speaking as a co-chair now :-) so we don't have to go through the
pain of respin the design later.

Jerry

>Vivek

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

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

---

From: Vivek Kashyap <[email-masked]>
Date: Sun, 17 Mar 2002 09:55:44 -0800 (PST)

> Only one P_Key to a QP, remember?

Good point. Hadn't thought of that. Looks like the broadcast bit
should do. Anything else will conflict with existing assumptions. For
example: LID with cross IB subnet IP subnets, SIDR with multiple
interfaces etc.

Vivek

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

---

From: Jerry Chu <[email-masked]>
Date: Tue, 19 Mar 2002 01:15:06 -0800

Paul,

My comments are embeded below

>Only one P_Key to a QP, remember?

I was alluding to multiple QPs in the same IB partition. For multiple 
P_Keys, each P_Key/
IB partitions defines a unique IP link, which is usually served by a 
different DHCP server.
Different interfaces on different IP links can possess the same hardware 
address. This is
similar to IP/Ethernet.

>wants multiple interfaces out of the same node to the same IP link,
Note again I was talking about "the same IP link", i.e. the same P_Key. 
I don't see the value
of providing multiple "virtual" interfaces on the same IB partition by 
using the same HCA,
same port, but only different QPs.

><prc> The broadcast work around seems quite adequate to me <endprc>
If the WG comes to a consensus on this then the above discussion about 
QPs is moot.

Rgds,

Jerry