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

From: "H.K. Jerry Chu" <[email-masked]>
Date: Sat, 12 Jan 2002 21:28:29 -0800 (PST)

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

---

From: "Ashwin Kamath" <[email-masked]>
Date: Mon, 14 Jan 2002 11:42:46 -0600

I agree with using GID both for longevity and scope. What about using
SIDR(Private Data) for communicating all the capability bits and any other
extras? If it is not too late for this, I have some new feedback.

For ARP on an IB subet one would require that
a. IB Switches support multicast. (This is true in most cases today.)
b. IP addresses used in an infiniband subnet are unique for use by IPoIB.
(This is an important constraint which gets rid of the ethertype field)
c. Some issues related to Multicast over IB need to be resolved (like
multiple consumers using multicast resources.)

Requirement (b) was addressed by defining a multicast group and the IP
address format. One would still have to deal with the GID, LID and the IP
address. Including the LID in the ARP Response will be difficult to deal
with because
 a. LID Assignments change.
 b. ARP might have to traverse a router, for IP Subnets spanning IB Subnets
(a) might not really be an issue because ARP entries are aged. In ethernet,
the ethernet topology might change and MAC Addresses can change on server
reboots (by way of using a different MAC or by assigning a MAC Address.) The
current ARP implementations do take these scenarios into account. Moreover
Path record lookups alone would not help resolve the issue of changing LIDs.
The locally cached path record will not be valid if the LID changes. For a
true solution, there has to be some way of using IB Traps to get information
about topology changes as and when it happens. An end node can subscribe for
a trap, but the end node will have to do something like,
 * Tell me when all the switches on the path to this node report a state
change on such and such a port.
 This will not work very well right now because one will have to subscribe
for traps on all switches leading to the end node, which implies that an end
node interested in the existence of another end node will need to have
knowledge of the complete IB topology. This is probably something worth
considering in the Infiniband WGs.

On the same token, if you use the globally unique GID, information about the
GID will not be maintained by the local subnet's subnet administration and
hence a path record lookup based on the GID would fail. So if the GID lookup
fails, one would send the ipoib packet to the designated IB router (as is
done with ethernet today, albiet based on netmasks). But what if you have an
IP subnet spanning IB Subnets. The designated router exists for an IP Subnet
and the local subnet IB administration will not have information about all
the IP nodes, because they could exist on another IB Subnet.

 The following IB transactions are required before sending any IPoIB data
over the subnet (assuming the multicast join is already done and we use GIDs
as link layer addresses)
 1. IpoIB ARP.
 2. Path record lookup.
 3. SIDR

In all this, the existence of the ARP is questionable. The same
functionality can be achieved using 2 and 3 above.
If you use GIDs as the IP addresses ,you can use a Path record lookup and
then use SIDR to get all the information to use IPoIB. The advantages are
evident, for eg,
 a. Traversing a router. Assuming that the path record lookup fails, one
will redirect all the related ipoib packets to the Gateway/router. Since ARP
does not exist, one does not have to worry about the issues involved by ARP
traversing a router, or the router proxying for end nodes on the same IP
Subnet but different IB Subnets. IP and IB Subnets will be one and the same.
 b. Debate on using the ether-type field vanishes. The Service ID will be
unique to IPoIB and will be assigned by some WG. You could potentially use
two Service IDs (might be an overkill), one for IPv6 packets and another for
IPv4.
 c. No special format for IP addresses is required (I have not thought this
through very well.)
 d. Switches are not required to support Multicast.
 e. There are no issues with multiple consumers using the same multicast
resources.
 f. Multicast could be used by an IB Gateways only to avoid multi-unicast.

In this scenario the IP subnet is the same as an IB Subnet, since the same
network addresses are used.

-Ashwin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of H.K. Jerry Chu
Sent: None
To: [email-masked]
Subject: [Ipoverib] What's inside an IPoIB link layer address?

GID
QPN

Discussions:

Comment?

Jerry

---

From: "Ashwin Kamath" <[email-masked]>
Date: Mon, 14 Jan 2002 11:55:40 -0600

A small correction,
 IB and IP Subnets need not be the same. IB routers will be used to traverse
IB Subnets and the SIDR is transparent to existence of such routers.
 Also this is only an alternative, ARP by itself could completely solve the
problem but there are issues it has within the IB subnet. This is an attempt
to work around the issues by suggesting an alternative.

-Ashwin.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Ashwin Kamath
Sent: Monday, January 14, 2002 11:43 AM
To: [email-masked]
Subject: RE: [Ipoverib] What's inside an IPoIB link layer address?

-Ashwin

-----Original Message-----

GID
QPN

Discussions:

Comment?

Jerry

---

From: Vivek Kashyap <[email-masked]>
Date: Mon, 14 Jan 2002 14:45:43 -0800 (PST)

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 most recent discussion is what I presented at the SLC
       last december. (I certainly felt that the room was in agreement
       - no queries, objection etc.) 

       I believe the following link-description provides the best
       assimilation of all the choices that have been put forth. If we
       step back and restart the whole discussion again we are likely
       to come back to the following - so here is a brief compilation
       of issues.

	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)

             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).

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

       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.

	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.

                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.

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

---

From: Yaron Haviv <[email-masked]>
Date: Tue, 15 Jan 2002 06:58:23 +0200

Vivek,

I agree with your assumptions
We need them all: LID + capability flags + GID + QPN
Mikes remark that you could extract the LID from the incoming packet however
looks interesting (as long as we make sure that people don't play with it,
e.g. redirect traffic etc')

As far as I understand the only open issues currently are (if someone thinks
there are more please respond):
LID: Yes/No
Ethertype
Capability flags

As for the why LID:
I think that going to the SM is not so efficient given the fact that it is a
central resource and all the nodes in the subnet go to if we could avoid it
why not
When IP will span IB the problem becomes more serious: Unlike IP routers
which has a default route entry, currently IB has explicit entries for each
path this might require doing too many PathRecord operations, which are also
currently very slow when going outside an IB subnet
(I had posted a proposal to the MSO team trying to resolve those issues
somehow however it is under discussion)
I would tend to send this info anyway since the extra 16 bits wouldn't harm
anyone, one might choose not to use them if he wants to go to the SM, this
way everybody will be happy and over time people will use the best solution

As for the Ethertype:
After giving Vivek a hard time on this issue I accept his proposal
Not because of the performance issues raised (since I don't think they are
real)
But because it is not really needed, and if it simplifies things, why not

As for the capability bits:
Avoiding the SIDR is a smart move
I'm not sure if the UC option will be used, if using connection why not
reliable connection
I just wanted to add SDP (Socket Direct Protocol) bit, Again ones might
choose not to use it, for the one that do it really simplifies the process a
lot

I'm hoping we get a quick convergence on those issues so we would move
forward
The issues are not serious and I think if an alternative enable someone to
do something he wants without violating the other's ability to do what they
want just ignoring the extra info, we should go for it

Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Vivek Kashyap
Sent: Tuesday, January 15, 2002 12:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ipoverib] What's inside an IPoIB link layer address?

Folks,

       Why the LID?

       Why the GID ?

        GUID

        Why the QPN:

                *****

        Capability flags :

Result:

Vivek

---

From: Michael Krause <[email-masked]>
Date: Tue, 15 Jan 2002 09:25:04 -0800

>central resource and all the nodes in the subnet go to if we could avoid it

How often do people really think they are going to the SM/SA for any of 
this information?  This isn't the Internet; it is a data center fabric.  So 
with the exception of a reboot of an individual node and fabric state 
events, most implementations will be able to cache their respective IP to 
IB mappings for very long periods of time.  This means that the actual 
packet rate for IP implementations to the SM/SA will be quite low.

>somehow however it is under discussion)

IBTA proposals remain confidential within the IBTA and should not be 
discussed within the IETF.  Currently, the IB router protocol is under 
development and as such is not for open discussion.  As to whether the IB 
router protocol will modified to support default route entries, uses 
explicit route entries, etc. that has not been finalized and is subject to 
member review, etc.

Again, I will argue that the rate of endnode change within the IP view is 
rather slow and thus the inquiry rate to the SM/SA even for a global view 
will not present scalability problems with an intelligent implementation.

>way everybody will be happy and over time people will use the best solution

It is unnecessary data that could cause confusion and interoperability 
problems.

>real) But because it is not really needed, and if it simplifies things, 
>why not
>

Capability discovery has to work as a separate inquiry method as noted in 
my previous response.  Having two methods for a given task is a waste and 
creates potential interoperability problems.  It is simpler for the spec to 
only specify one method and let implementations do likewise.

>want just ignoring the extra info, we should go for it

Mike

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 15 Jan 2002 13:07:41 -0800 (PST)

> There has been a consensus of using GID, not LID as the basic

I don't think there has been any consensus on this issue.

> link layer address, it's not going to work well.

        Let us look into this issue in detail first. It has not been
        pointed out what one gains by spanning IB subnets. Let us
        first make or break the case for IP subnets spanning IB
        subnets. What is the gain ?

        As for things being stable - GID scopes, GID prefix changes,
        subnet merges etc. effect GIDs as much as LIDs. Once the node
        is up it will have a constant LID. SMs are also likely to keep
        the LID constant across reboots. But one point to note is that
        LIDs are always necessary. Whether they change or not you need
        to determine them. GIDs are not necessary. So this leaves us
        neither here nor there. They are just link addresses with the
        LID always required and GID an optional value.

> in order for a node to retrieve complete path info before sending

        As noted elsewhere there is no need to to always access the
        pathrecord. Even if the information is required it doesn't
        mean that one needs to determine the information from the path
        record when LID is to be determiend. Determining the LID is
        not tied to that. They are disjoint processes. Also, one can
        look up the path record using the LID/GID or GUID.

> an intermediate IB router.

LID changing or GID changing (in scope in case of merger or
renumbering) etc. are issues that will have other effects and are
equally connected to any flushing or more drastic effects that will
have on the SM and the subnet. IBTA has not solved SM merges, P_Key
merges and management and various such issues. Such a disruption
applies all over IB components and is not limited to LIDs/GIDs.

Let us first answer the question of why IPoIB subnets must span IB
subnets ? We don't know why we need such a setup ? We don't know when
such a setup will be possible ? We do know that IPoIB subnets within
an IB subnets can be setup easily with the current specification.

Secondly, if you step back you'll realise that LID is hardly an issue
when resolving across subnets. Unlike what has been postulated the
process is not the same when resolving within the IB subnet and when
resolving across the IB subnet. 

	Assumption: at IP level- a multicast request; receive a unicast reply

        Now, when sending the broadcast the sender doesn't know where
        the responder is. So he includes his LID/GID. The receiver
        gets it across multiple subnets. It gets sees a different
        GID-prefix and hence replaces the LID with its default router
        when recording the address. The same happens on the response.

        It works fine for both situations - IPoIB subnets
        within/across IB subnets. You can easily have it that if the
        GID is local the routing lookup will return the local LID.
        Single process.

        In the case of not including the LID you do the same thing. If
        the GID prefix is local you go to the SM/SA to get the LID. If
        the GID prefix is different you record your default router's
        LID. So the process for across the subnet is the same but you
        shortchange the implementation that is more likely - the one
        whithin the subnet.

        For within the subnet you use a different method - going to
        The SA always. Not the same as going to the routing
        infrastructure. 

However, I would still like to know what is the use of IPoIB spanning
multiple subnets. Why do you think that is a requirement ?

Vivek
-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)
-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)

---

From: "Roger Ronald" <[email-masked]>
Date: Tue, 15 Jan 2002 15:38:45 -0600

It seems like the general debate that's raging is trying to answer 
a single question:

"Is it wise to include the LID in order to enable a
shortcut that allows bypassing a trip to the SM/SA?"

My read is that second party dissemination of LIDs is not 
something that is prohibited (per the IBTA rules), but it is a
shortcut that the IBTA architects weren't expecting
and are uncomfortable seeing. Various objections
about PathRecords, rate control, SL, and MTU have
been mentioned, but don't seem to make for a conclusive
decision point.

In the end, the tradeoff seems to be simplicity versus
flexibility. Leaving out the LID makes the header
smaller and the processing is always done in one
way. Putting the LID into the header allows
skipping a step under (at least) some circumstances.

I'm willing to live with either approach. I am
not as ambivalent about Vivek's last email that
questions the inclusion of GID. While I'm not too
concerned about supporting a single IP subnet over
multiple IB subnets, I do think that the GID is
required to support any sort of bridging devices. If only a 
16-bit LID is used, one would never be able to build
a useful bridge to important fabrics like Ethernet.

RR

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 15 Jan 2002 13:57:35 -0800 (PST)

> 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?

        There has been some discussion on this issue. As noted SL
        certainly doesn't require going to the SM/SA. The path-rate
        support is mandatory if sending > 2.5Gbps but not determining
        it from SM/SA. To my knowledge IBTA is actively pursuing a
        dynamic congestion management solution that would not depend
        on static path rate. So this is not an argument to tie down
        LID determination to the SA.

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

        I would like to know what is the drawback that you see that
        you don't want one to go ahead with it? ARP is repeated every
        so often and happens quite often. It also happens on failover
        - it is preferable that these operations be simple, fast and
        error-free. 

        Secondly, things are more complicated the way you propose.
        Note that the first level address would be first determined.
        This completes ARP/ND. However, address resolution is not
        complete. The packet is sent as far as IP is concerned and now
        the SA/SM is consulted to get the LID etc. This has very
        strong shades of ATM VCs. IP thought it had sent the packet
        since the ARP/ND was complete - it took a while before the
        lower layer completed the determination. The driver of course
        keeps a GID to LID table too since the LID is a separate
        entity. More complication.

	Include LID in the resolution - fast/simple/error-free.

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

	I have just responded to an earlier mail of yours on these points.

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

        I was pointing out another issue that many have raised.
        In general I am ok with dropping GID since it is for the
        future. IT buys us nothing as of now. So if we dropped GID we
        can work with these 48 bits. When IPoIB in reality starts
        spanning multiple IPoIB subnets (not for a long time) we can
        include GID. Then the hardware length will become 22 bytes as
        against 6 bytes. One can still interoperate quite easily.

	Wouldn't that work for all ? 

        I included the GID because many want to put in the hooks for
        the future case of IPoIB spanning IB subnets. I would though
        like a valid reason specified for why do we need IP subnets to
        span IB subnets. Isn't IP subnetting enough?

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

	I have covered those in another mail I sent some time back.

> 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.

        The advanced capabilities draft describes how these bits are
        supposed to work. I have also described it in the IETF slides
        and on this mailing list in item 9 of the thread 'ipoib
        architecture/encapsulation'. 

        The default case is IPoIB-UD with QPN included in the ARP/ND
        packets. If the QPN/RC flag is set then the sender is
        advertising its support for SIDR-QPN and RC. A base
        implementation ignores these flags and always sets them to
        zero on send.

> 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.

        I urge you to review the draft I have submitted. A few WG
        members have already written that they like the idea. It
        interoperates with the default case seamlessly and allows
        optimised solutions to be supported within the same subnet.

Vivek

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 15 Jan 2002 14:30:11 -0800 (PST)

> skipping a step under (at least) some circumstances.

Leaving out the GID makes the header a lot less smaller. I am not sure
what process is done in one way ? If you are talking about spanning IB
subnets with a single IPoIB subnet the process is definitely not done
in a single way. It is more easily a single way if the LID is used.
This is noted in my note below.

---

From: Michael Krause <[email-masked]>
Date: Tue, 15 Jan 2002 15:22:04 -0800

>         LID determination to the SA.

Congestion management would be optional functionality given the V1.0 
specification has been public for over a year now.  As such, it cannot be 
relied upon to solve any problems only to improve a solution over 
time.  Further discussion into the details is not permitted due to the IBTA 
confidentiality rules but it is fair to state that injection rate control 
is one lever used by congestion management but congestion management does 
not lead to injection rate control which may be driven more by QoS 
requirements which go beyond the scope of congestion management.

The IP over IB spec should define the architectural minimums needed to 
implement a credible IP over IB solution and leave optimizations such as 
what have been debated these last few days to vendors to solve.  If the 
optimizations prove worthwhile after experience has been gained in real 
customer deployment situations such that a subsequent spec should be 
generated, then the workgroup can provide a new spec that provides an 
interoperable solution using these new techniques.

>         - it is preferable that these operations be simple, fast and

No one is arguing with any of these assertions.   The issue is strictly 
what is the architectural minimum the spec should define and what should be 
left for future spec or vendor implementation to solve.

>         entity. More complication.

This is one implementation choice and while it may be used by some, it does 
not require the spec to make this a requirement.

>         Include LID in the resolution - fast/simple/error-free.

It isn't that simple either

>         against 6 bytes. One can still interoperate quite easily.

GID is required because it is the primary way and application determines 
where a service resides on a given port as such not including it makes life 
quite difficult to implement.  GIDs are also used by applications within 
the address vector to identify a given vector to use for a given service 
such as IP.  GIDs cannot be dropped and have value.

LIDs are strictly a local issue that will be learned for all CA / router 
ports participating within a given partition that support IP services.  As 
such, their assignment, management, transitory nature, etc. make them 
unsuited as an architectural minimum to include within the spec.  I see no 
problem with people ascertaining the value and using it for optimizing 
their implementation but this is outside the scope of the specification.

>         span IB subnets. Isn't IP subnetting enough?

IB is viewed as a layer 2 fabric w.r.t. IP so the fact that IB has multiple 
subnets is independent of IP operation.  I see no point in dealing with the 
IB subnet issues within this specification other than to state that a LID 
is not an end-to-end address between two endnode ports and thus should not 
be mandated within the IP over IB spec for address resolution.

Mike

---

From: Yaron Haviv <[email-masked]>
Date: Wed, 16 Jan 2002 01:14:38 +0200

Summarizing the points:

I don't understand why to block people that like having the LID from getting
it
We could deal with the issues around it by defining that a node must always
examine and compare the GID first
And not relay on the LID alone
If there are people who thinks avoiding the SM is important to them, and it
doesn't block the others from doing it, why not
I would like to here strong arguments as for what harm could be done by
adding the LID, and not why it is not needed
(Obviously there are people in this group who think it is needed)

No one responded on the Ethertype issue, I hope there is a consensus around
it

As for the capability issues
Since the working group has agreed to first solve UD.
For now we could specify reserved capability bits that
must-be-zero on transmit and not checked on receive, and then define
those bits in the follow-on RFC
this should satisfy everyone

as for the 1X issues, there is no problem any one could use how much he
needs
the problem as I understand is just around the multicast traffic
which all of you state is low performance
also this 1X could be a default value, and could be changed to support more
if desired
(I wonder way some of the people here are active on iWarp if they believe
plain TCP/IP is so efficient without HW offloading)

Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Michael Krause
Sent: Tuesday, January 15, 2002 7:25 PM
To: [email-masked]
Subject: RE: [Ipoverib] What's inside an IPoIB link layer address?

Mike

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 15 Jan 2002 23:10:15 -0800 (PST)

> interoperable solution using these new techniques.

        The only issue I am pointing out is that there are multiple
        ways to solve the problem - as you yourself point out. The
        architectural minimum should not be defined such that it ties
        down every body to the minimum leaving the optimisations out
        of scope in the future.

        Therefore include LID/GID in the address resolution packets
        and all sorts of implementations can coexist. Remove GID and
        only one set is possible, remove LID and only another set is
        possible. Include both, both are possible and there are no
        negatives for either.

> not require the spec to make this a requirement.

        The assertion against LIDs was that they cause complication. I
        am showing that it is the other way down. This description is
        not part of the spec. but shows that the argument that
        inclusion of LIDs causes more complexity is incorrect. It is
        the GID to LID conversion that is more complicated. Including
        LIDs in address resolution allows for a simple, 2 message,
        fast failover solution.

        I have also noted that the process, in another mail, of
        resolving the IP address is simpler and fits in more with a
        'single method' when LIDs are included than does the process
        when the LID is not. I have not seen a counter example.

> It isn't that simple either

        As shown above it is simpler than getting the GID and the
        answer. I request a corresponding scenario that shows that the
        GID to LID conversion is a better solution. I am not against
        anyone implementing it differently. Allow those that want ot
        implenet it in this way to do so.

> their implementation but this is outside the scope of the specification.

        I don't understand. If those that don't want this information
        just ignore it what is the loss? We can format the link
        description such that the LID is the last element. Those that
        don't want it can drop this piece of information and ignore
        it. Of course those that don't want to use GID can ignore it
        too.