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

From: "H.K. Jerry Chu" <[email-masked]>
Date: Mon, 14 Jan 2002 16:55:36 -0800 (PST)

My comments are interspersed below:

...
<snip>

>
>
>	Suggested Link description to be used in address resolution:
>
>		LID + capability flags + GID + QPN
>
>
> 
>       Why the LID?
>
>             People said they don't want to go to the SM if possible
>             (LID allows for that. As noted here and LWG the SL can be
>             determined based on QoS or other parameters. The SL may
>             also be determined from the SA/SM)

I don't think pathrecord lookup can be avoided or should be skipped.
You're proposing something that IMHO is beyond my understanding of
how things work in IBA. Can you get an experienced IBTA member
to substantiate your statements here?

And what's the real benefit of saving just a lookup out of an already
infrequent operation like ARP due to cacheing?

>
>             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. (you can't escape it).

There are a number of issues of including LID as I've pointed out in
another mail.

>
>             BTW, people said they want the 'link-address' to be 48 bits.
>             (LID + QPN + cap_flags is 48 bits).

I'm confused. Aren't you proposing to include GID as well. Where does
this 48 bits come from?

>
>
>       Why the GID ?
>       
>                People want IP to span across IB subnets. We are
>                stretching stretching here since such implementations
>                are not possible yet.
>                However, we can define it such that it will work in
>                the future. Therefore include the GID.

You're ignoring all the other good reasons of using GID as I and many
have pointed out before (recently in another mail).

>
>	GUID
>
>		Can be made part of the GID.
>
>
>	Why the QPN: 
>
>                1) There is only one other way to get the QPN. That is
>                the SIDR protocol. However, this has a drawback.
>
>		SIDR is NOT REQUIRED by IBTA.
>
>                I had raised this point last August 'Feasibility of
>                SIDR': 
>
>                ***** Section 12.11 essentially states that SIDR is
>                optional. As the specification states:
>
>               << GSAs shall support this protocol if non-management
>               services are pro-vided on the Channel Adapter at other
>               than fixed QPNs. If this protocol is *not supported*,
>               the status "The method/attribute combination is not
>               sup-ported" shall be returned, as described in section
>               Table 101 MAD Common Status Field Bit Values >>
>
>		*****
>
>                That still holds. SIDR is NOT required by IBTA. A
>                device can always choose to provide all non-management
>                services at fixed QPNs. It may just choose to provide
>                IP and nothing else at a particular QP and hence won't
>                do SIDR.
>
>                That is why I propose that the QPN be always included
>                for the default case. SIDR usage is gated through the
>                QPN flag and is in the realm of the advanced
>                capabilities draft as has been suggested by many on
>                this mailing list. And I agree.

I agree in general that SIDR should not be required by IPoIB.
I'd second what Arvind said, before we can fully define what
these capability are meant to work, let's mark these bits as
simply reserved.

Jerry
 
>
>
>                2) Address resolution that returns the QPN is done in
>                one request/reply exchange. Any other method, while
>                talking to the same endpoint, requires 6 messages. 2
>                for ARP/ND and 2 each for each of the lower layer
>                request/reply. IT is wasteful, more complicated,
>                more time consuming wrt fast failover etc.
>
>
>	Capability flags :
>
>                Multiple people have opined that they would prefer in
>                certain cases to map the protocol/ULP endpoints to
>                specific QPs. People also want to use IP over RC mode
>                (and others maybe) due to the advantages of larger MTU
>                and Automatic path failover etc.
>
>                The capability flags allow for interoperation between
>                the default/dumb devices and the more sophisticated
>                devices. IT also allows the endpoints to avoid
>                unnecessary trial and error/to and fro when trying to
>                utilise these features. The flag indicates the
>                advanced capabilities supported and the receiver can
>                choose to utilies them.

I'd second what Arvind said, before we have a consensus that
including these capability flags in the link addr is a good thing
and have their meaning fully defined, let's mark these bits as
simply reserved.

Jerry

>
>
>Result:
>
>        We cannot depend on SIDR. We need to include the default QPN.
>        We should not force implementations to go to the SA/SM (IBTA
>        does not) and so allow LID/GID to be determined from the
>        remote host. The default case works with :
>
>	LID+Capability flags(all set to 0)+QPN+GID
>
>
>Vivek
>
>
>

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

---

From: Michael Krause <[email-masked]>
Date: Mon, 14 Jan 2002 17:28:43 -0800

>to substantiate your statements here?

An endnode may acquire the path record to determine the appropriate SL to 
use when communicating to another endnode.  Given SL is set on a per IB 
subnet basis, there is no fixed method to determine the appropriate SL to 
use within a given subnet.   Work is under consideration to develop a QoS 
mapping function that will allow an endnode to use the IB TClass field to 
communicate the QoS requirements at a global level. This would then allow 
each IB subnet to transparently map the IB TClass to an SL without 
requiring the application to explicitly set this field.

>infrequent operation like ARP due to cacheing?

Unclear.  One has to deal with IP subnets that span multiple IB subnets so 
having a single mechanism used all of the time seems more practical.

>I'm confused. Aren't you proposing to include GID as well. Where does

Perhaps someone is trying to re-use an existing Ethernet MAC structure but 
that is perhaps strictly an implementation objective outside the scope of 
this specification.

> >               Can be made part of the GID.

Only if using GID 0 which may not always be the case for an endnode that 
supports multiple GID per port.

Mike