Subject: RE: [Ipoverib] What's inside an IPoIB link layer address?

From: "Larsen, Roy K" <[email-masked]>
Date: Thu, 17 Jan 2002 12:59:36 -0800

Jerry,

Yes, this could be a issue for the OS.  But since the dynamic nature of LIDs
is integral to IBA, they are just going to have to find a way to deal with
it.   As I suggested, perhaps with gratuitous ARP.  Anyway, would you agree
it is outside the scope of IPoIB.

Roy

-----Original Message-----
From: H.K. Jerry Chu [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 12:49 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Ipoverib] What's inside an IPoIB link layer address?

Roy,

Sorry I didn't explain it well. The potential issue I was trying to
point out is inside a local node that has its LID change. The question
is how will the LID change be propergated up to the IP stack. Many IP 
implementations never expect a local NIC's  MAC address can change on
the fly, all by itself. This poses a potential implementation problem.

Jerry

>From: "Larsen, Roy K" <[email-masked]>
>To: "'H.K. Jerry Chu'" <[email-masked]>,
[email-masked], 
[email-masked]
>Cc: [email-masked]
>Subject: RE: [Ipoverib] What's inside an IPoIB link layer address?
>Date: Thu, 17 Jan 2002 11:42:20 -0800
>MIME-Version: 1.0
>
>Jerry,
>
>Ok, your concern is a mechanism for notifying a node that a LID change has
>occurred regardless of how the LID was initially obtained.  I'm no SM
expert
>but seem to recall asking my resident expert about this a while back and he
>said there wasn't.  However, if the LID was included in the ARP, wouldn't
>sending a gratuitous ARP when the link comes up solve the problem? 
>
>Roy
>
>-----Original Message-----
>From: H.K. Jerry Chu [mailto:[email-masked]]
>Sent: Wednesday, January 16, 2002 7:28 PM
>To: [email-masked]; [email-masked];
>[email-masked]
>Cc: [email-masked]
>Subject: RE: [Ipoverib] What's inside an IPoIB link layer address?
>
>
>Roy,
>
>Thanks for the info. A comment on your statement of volatility of LID
having
>no bearing on whether LID should be included in ARP reply. Yes it does. One
>of the goal of IPoIB is to minimize the changes to the existing IP stack
>implementations. Note that I stated it as a goal, not a constraint. If we
>must do it then we should.
>
>Yes no matter what, LID is cached somewhere and must be flushed. The
>difference
>is whether one must modify the existing stack code to add a facility to
>support
>mac addr change, or do the necessary chore in a complete new IPoIB driver.
>The former requires an upgrade of OS release that can take a long time. The
>latter doesn't have such a problem since it's brand new.
>
>One can also hope that LID flushing through SM can be made more reliable
>than
>gratuitous ARP. But I don't know the SM archtecture enough to make such a
>claim.
>
>To be fair I don't really know how many OSes lack support for mac add
>change. The two that I know, one supports it, one doesn't.
>
>I'm assuming there are solid facility in IBA to support the notification of
>attribute changes to interested parties. Otherwise not only we should
>include
>LID, but also all the rest in the link addr.
>
>Jerry
>
>>From: "Larsen, Roy K" <[email-masked]>
>>To: "'H.K. Jerry Chu'" <[email-masked]>,
>[email-masked], [email-masked]
>>Cc: [email-masked]
>>Subject: RE: [Ipoverib] What's inside an IPoIB link layer address?
>>Date: Wed, 16 Jan 2002 18:42:31 -0800
>>MIME-Version: 1.0
>>
>>> -----Original Message-----
>>> From: H.K. Jerry Chu [mailto:[email-masked]]
>>> Sent: Wednesday, January 16, 2002 6:13 PM
>>> To: [email-masked]; [email-masked]
>>> Cc: [email-masked]
>>> Subject: Re: [Ipoverib] What's inside an IPoIB link layer address?
>>> 
>>> 
>>> All the proxy ARP usages that I know of use the proxy's mac 
>>> addr in the
>>> ARP response. I believe the flavor of the proxy ARP you 
>>> alluded below is
>>> rare, and won't work very well anyway if the link address includes any
>>> non-persistent component like LID and QPN because it will 
>>> require another
>>> protocol between the clients and their proxy to constantly update the
>>> proxy database containing clients mac addrs, which may change quite
>>> often.
>>> 
>>> That is also why I wanted to provide an option to not include QPN.
>>> (But I haven't succeeded w/o requiring SIDR or something equivalent.)
>>> 
>>> If LID is included as part of link addr and if it ever changes on
>>> a live node due to subnet merge...etc, the driver must inform its IP
>>> stack about such change. I believe many stacks don't have such a
>>> facility. (FOr most IP stacks the assumption is that its own MAC
>>> addresses just don't change on the fly.) In that case you're totally
>>> hosed. Can someone comment on how likely a LID assignment gets
>>> rescinded?
>>
>>It is possible anytime the link goes down and comes back up again and when
>>the fabic is reconfigured.  This can happen on reboot or simply
>>unplugging/plugging in a link.  It is ultimately a function of the SM and
>>how much trouble the implementation wants to go through to keep LIDs
>>constant.
>>
>>But of course, that has no bearing on whether the LID is contained in the
>>ARP.  You always need the LID.  Unless you want to do a pathrecord lookup
>>each time your implementation is given a packet to send, you're going to
>use
>>a cached LID no matter if it came in the ARP or a pathrecord lookup on the
>>GID.  If it becomes stale, it may take an ARP cache flush timeout to
>>recover.  
>>
>>Roy
>> 
>>> 
>>> Jerry
>>> 
>>> >        A device can always respond for another. The LID of 
>>> the sender
>>> >        is not the same as the LID for which it has 
>>> responded. It also
>>> >        allows any network monitoring/debugging device to work
>>> >        independently. This is the reason why none of the other media
>>> >        does anything like this. You don't pick ethernet source
>>> >        address from the frame but take it from the ARP/ND packet.
>>> >
>>> >        [ If it was ok we wouldn't need anything except QPN/cap_flags
>>> >        - get the LID from response, consult SA using LID for GID if
>>> >        you want that, and you are done. ]
>>> >
>>> >Vivek
>>> >
>>> >> 
>>> >> Why do we need to include the LID inside the link layer 
>>> address when it
>>> >> is already available in the SLID field? Previous 
>>> discussions indicate
>>> >> that the SLID value works for proxy ARP/bridge implementations.
>>> >> 
>>> >> - Arvind
>>> >> 
>>> >> -----Original Message-----
>>> >> From: Vivek Kashyap [mailto:[email-masked]] 
>>> >> Sent: Wednesday, January 16, 2002 10:29 AM
>>> >> To: [email-masked]
>>> >> Cc: [email-masked]
>>> >> Subject: Re: [Ipoverib] What's inside an IPoIB link layer address?
>>> >> 
>>> >> Ashwin,
>>> >> Ashwin,
>>> >> 
>>> >>         I agree that you get more flexibility if you 
>>> include the LID.
>>> >>         If we include the GID along with the LID we allow all
>>> >>         implementations the choice to create different 
>>> solutions. We
>>> >>         don't tie them down to one thing. Choosing one or the other
>>> >>         (LID or GID) blocks out various advantages that different
>>> >>         implementations seek. Hence I suggested that let us include
>>> >>         both and move on.
>>> >> 
>>> >> Vivek
>>> >> 
>>> >> <snip>
>>> >> 
>>> >> _______________________________________________
>>> >> 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

---

From: "Bill Strahm" <[email-masked]>
Date: Thu, 17 Jan 2002 13:41:21 -0800

Roy,

Gratuitous ARP does not help here... I do I send a gratuitous ARP if I can
not change my MAC address in my ARP module...

The easiest solution is to not put LID into the MAC address, then you don't
have to worry about the problem at all on the sender side.  On the receiver
side I believe you have to do the same work regardless...

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Larsen, Roy K
Sent: Thursday, January 17, 2002 1:00 PM
To: 'H.K. Jerry Chu'
Cc: [email-masked]
Subject: RE: [Ipoverib] What's inside an IPoIB link layer address?

Jerry,

Roy

-----Original Message-----
From: H.K. Jerry Chu [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 12:49 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Ipoverib] What's inside an IPoIB link layer address?

Roy,

Jerry

expert
having

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