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

From: "Arvind Murching" <[email-masked]>
Date: Wed, 16 Jan 2002 11:36:19 -0800

You do need the GID in case you are crossing IB subnets.

Monitoring devices do not -need- to see a LID in the ARP response, it is
only implementations that are attempting to avoid an SM/SA lookup that
are interested in the LID. We shouldn't add redundant/relatively
transient values in the link layer address.

- Arvind

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]] 
Sent: Wednesday, January 16, 2002 11:31 AM
To: Arvind Murching
Cc: Vivek Kashyap; [email-masked]
Subject: Re: [Ipoverib] What's inside an IPoIB link layer address?

        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

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 16 Jan 2002 12:09:15 -0800 (PST)

Arvind, 

        Multiple pros/cons for both have been suggested over the last
        few days. As noted earlier let us allow for all solutions that
        people want. 

	So include LID and GID both.

Vivek

> You do need the GID in case you are crossing IB subnets.

        Why are you doing that ? Why are you supporting IP subnets
        spanning IB subnets ? Advantages ?

> transient values in the link layer address.
	
        Depends on what you have in mind. Other reasons have been put
        forth in the last note and in previous discussions.

---

From: Yaron Haviv <[email-masked]>
Date: Thu, 17 Jan 2002 03:41:59 +0200

Arvind, Vivek

I'm sure we must have the GID as the primary address
There is a need for IP spanning IB this is what I hear from many of the data
centers I visit, As noted in few of the emails there are also few other
reasons for GID
lets first agree on that !,
Vivek the key for including the LID is that people will have a primary (GID)
address that determine the route, to avoid interoperability issues
(I'm sure this was also the consensus in LWG befor we went to IETF)

We need to maintain the tables by the GID, however I support taking the LID
to return the answer to the caller (avoiding the SM as the main reason)
I'm not sure that we could take the LID from the packet since someone might
Forward it somehow (test tools, ARP server or something like that)
And we don't want a broken spec

No one mentioned in the arguments the additional latency caused by going to
The SM (for the LID)
As a central resource that probably has queuing it might take time
Not to mention the latency in IP span IB case (needing to resolve all the
Path first)

lets go for the LID in the header, and specify that the GID is the primary
address

Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Vivek Kashyap
Sent: Wednesday, January 16, 2002 10:09 PM
To: Arvind Murching
Cc: Vivek Kashyap; [email-masked]
Subject: Re: [Ipoverib] What's inside an IPoIB link layer address?

Arvind,

Vivek

---

From: Michael Krause <[email-masked]>
Date: Thu, 17 Jan 2002 08:52:00 -0800

At 03:41 AM 1/17/2002 +0200, Yaron Haviv wrote:
>address that determine the route

A GID does not determine the route used between any two endnodes - it only 
identifies the port.  Within an IB subnet, the LID is used to identify the 
path taken this is why we have the base LID and LMC concept in order to 
support multi-path.  Applications must supply an address vector which is 
composed of several elements which are then translated into a specific 
tuple used by the fabric for packet switching, i.e. <DLID, SL>.

The GID prefix is used by the IB routing protocol as one of the inputs 
required to identify a path to take as it crosses one or more IB subnets 
between the two endnodes.  The router uses some or all of these same inputs 
to determine how to map a given DGID to a local <DLID, SL> for final 
delivery to the destination endnode port.

>, to avoid interoperability issues

If you cannot trust what is available from the IB packet headers for the 
above reasons, you will not be able to use something included within the 
link address either unless you take the step to consult the SM/SA for the 
appropriate value which was the step that was supposed to be eliminated by 
the proposals put forth to date.

>No one mentioned in the arguments the additional latency caused by going 
>to The SM (for the LID) As a central resource that probably has queuing it 
>might take time Not to mention the latency in IP span IB case (needing to 
>resolve all the Path first)

The latency can be eliminated depending upon how one distributes the GID / 
<LID, SL> mapping data and whether one makes use of the IB Notify 
mechanisms to note fabric event changes.   With some minor improvements, 
many implementations will only traverse to the SA once upon initial contact 
of another endnode and then only refresh upon a notification of a fabric 
event.  I fail to see the validity of the arguments presented to date 
concerning SA performance and their negative impact of fabric convergence 
upon a failure / merge / etc. event.  I also will contend that fabric 
events do not happen that often and with again some intelligence in terms 
of use of existing IB management definitions, the scalability / performance 
/ convergence issues can be dealt with quite well.

Mike