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

From: "Larsen, Roy K" <[email-masked]>
Date: Wed, 20 Mar 2002 17:47:17 -0800

I never saw this come through the reflector so I'm reposting.  Sorry if this
is a duplicate.

Roy

-----Original Message-----
From: Larsen, Roy K 
Sent: Wednesday, March 20, 2002 1:17 PM
To: 'Culley, Paul'; H.K. Jerry Chu; [email-masked]
Cc: [email-masked]
Subject: RE: [Ipoverib] BOOTP/DHCP chaddr field

Folks,

Unless explicitly restricted by the IPoIB draft, it is perfectly acceptable
for an implementation to present multiple "hardware" interfaces on the same
*IP* subnet.  In the same way that it is perfectly legal for a node to have
4 Ethernet adapters connected to the same IP subnet, since the "hardware"
address for IPoIB is QPN+GID, it perfectly legal to have 4 IPoIB device
interfaces on the same IP subnet provided they each have a different QPN.
The P_Key will be common to all 4 devices.

I don't think this effects the broadcast solution that has been proposed by
Vivek.  I just want to make sure that this group does not make assumptions
about IPoIB configuration unless we explicitly outlaw it in the IPoIB
drafts.

Roy

-----Original Message-----
From: Culley, Paul [mailto:[email-masked]]
Sent: Sunday, March 17, 2002 5:04 AM
To: H.K. Jerry Chu; [email-masked]
Cc: [email-masked]
Subject: RE: [Ipoverib] BOOTP/DHCP chaddr field

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

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

---

From: Michael Krause <[email-masked]>
Date: Wed, 20 Mar 2002 21:03:58 -0800

>about IPoIB configuration unless we explicitly outlaw it in the IPoIB

Agree that the above should be supported and is perfectly legal.

Mike