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

From: "Vivek Kashyap" <[email-masked]>
Date: Mon, 14 Jan 2002 12:50:06 -0800

Folks,
      It is close to the last call. In this regard I would like to state
that we have been discussing this issue for a long time now. The ARP
outline, as discussed in the thread .... has been presented to the WG since
July last. It was restated in december on the mailing list and at the WG
meeting. I feel that it provides the best compromise we are likely to get
and we should not step back in time and restart the whole process. I really
do have a complaint - it has been a few months that we

      The Identifier:

      LID:
            People said they want the 'link-address' to be 48 bits. ( LID +
QPN + cap_flags is 48 bits).

            People said they don't want to go to the SM if possible (LID
allows for that)

            People said they want the process to end in small number of
messages (LID allows a query/response to settle the issue. As noted one
doesn't necessarily have to go to the SM to get the SL).

            LID is always needed.

      GID:
            People want to cross subnet boundaries. Mind you, we are
stretching here since such implementations are not possible yet.

      GUID:
            People want to keep a permanent address. (GUID can be made part
of GID and also got from the SM via the LID for those interested).

      Given the above reasons LID+GID is a good compromise. It allows for
all the conditions and doesn't shortchange anyone. Let us not rehash the
whole process again.

      The ARP process:

      We want it to be like RFC826. A broadcast is sent out and a reply
received.

            * People want it to be a single step process.
            * People want to avoid the SM
            * Peopel want to consult the SM

            All the above conditions are easily achieved as has been
discussed for some time now.

            Receive the LID+cap_flags+QPN + GID of the peer.

            If you like one step/avoiding the SM things are set. If you
don't you are free to consult the SM using the LID or the GID.  You always
get the IP QPN - that is not kept with the SM. The ones that want to go
back to the peer go into the advanced capabilities mode.

      If the remote sets the QPN flag then it supports SIDR. The SIDR and
you can resolve the packet that way. If the QPN flag is not set then we are
at the basic set and we c

   --
   Vivek Kashyap
   Linux Technology Center, IBM
   [email-masked]
   [email-masked]
   Ph: 503 578 3422 T/L: 775 3422

                      "H.K. Jerry Chu"                                                                                            
                      <[email-masked]        To:       [email-masked]                                                        
                      n.com>                   cc:                                                                                
                      Sent by:                 Subject:  [Ipoverib] What's inside an IPoIB link layer address?                    
                      ipoverib-admin@ie                                                                                           
                      tf.org                                                                                                      

                      01/12/2002 09:28                                                                                            
                      PM                                                                                                          
                      Please respond to                                                                                           
                      "H.K. Jerry Chu"                                                                                            

While proposals beyond the basic IPoIB over UD started showing up,
I still don't think we've reached a rough consensus on some basic
questions such as what the IPoIB link layer address should contain.
Again I'd like to apologize for not being there at the SLC meeting
last month. Perhaps a consensus was reached there but i've missed
the boat. In that case please let me know what it is and I'll shut
up.

What I'd like to see included in the IPoIB link layer address is

GID
QPN

and I'd like to allow QPN field to be 0.

What I don't like to see included is LID.

Discussions:

There has been a consensus of using GID, not LID as the basic
IB address identifying the port hosting an IP address. GID is
sufficiently stable, not subject to change across a node reboot
or subnet merge (IB level) like LID is. Also people don't want
to exclude the possibility of IPoIB link spanning more than
one IB subnet. GID supports scope beyond local link so it's
suitable for that purpose.

Multiple GIDs with different scopes may have been assigned to a CA.
It is required that a CA returns the GID with a scope no less than
the one for the IPoIB link. E.g. if an IPoIB link covers multiple
IB subnets, but a CA uses a link-local GID as part of its IPoIB
link layer address, it's not going to work well.

I don't see any value of including LID besides GID as proposed
by Vivek. I believes a lookup of PathRecord is always needed
in order for a node to retrieve complete path info before sending
unicast pkts to another node. The destination LID is part of
the PathRecord so including it in the link layer address returned
from ARP/ND doesn't save work. But you have all the drawbacks that
swayed people away from using LID - it adds volatility to the link
address. LID changing due to subnet merge or other reasons requires
potentially new mechanism being added to IP/driver implementation
to trigger ARP/ND flush. Lastly, what should be the LID if the IP
node is in a different IB subnet? Obviously it can't be the LID of
an intermediate IB router.

For QPN I'd like to suggest one thing. Since SIDR is a required
feature by IBA, the QPN field is allowed to be zero. What that
means is that the requester must use SIDR to retrieve the remote
QPN, given the GID of a remote IP address.

This feature allows the support of static/persistent "MAC addr"
wrt node reboot by removing the volatile part of the link layer
address - the QPN. In many implementations the QPN allocated for
a CA may change across node reboot. Support of static "MAC addr"
has been considered desirable by a number of people.

I don't like to add additional requirement such as SIDR to IPoIB,
and was trying to make the above feature "optional". Ideally nodes
can express whether they'd like QPN to be returned by embedding
some flags, such as "I don't talk SIDR so please return QPN" in
their IPoIB link layer addresses. But the broadcast nature of
IPv4/ARP forbids the use of different "MAC addrs" for the same IP
address, so my attempt failed.

Comment?

Jerry

_______________________________________________
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: Vivek Kashyap <[email-masked]>
Date: Mon, 14 Jan 2002 13:03:59 -0800 (PST)

Sorry, for the incomplete mail.

My mailer died I thought and the message went out while I was on the
phone talking to Arvind Murching before I could complete, review and
send it out. Will send the mail out in a while. I was trying to update
the points based on things Arvind and I were discussing. Remind me not
to do two things at once.

Vivek

503 578 3422 (o)