Subject: RE: [Ipoverib] encapsulation issues

From: "Larsen, Roy K" <[email-masked]>
Date: Wed, 16 Jan 2002 17:18:22 -0800

> 
> 1.      We have been arguing over the inclusion of LID/GID or both for
>         a while now. Examples and advantages of including either have
>         been espoused often enough. However, there is an agreement, I
>         think, on the architecture not forcing a limited solution on
>         any set of aspirations.
> 
>         As noted earlier the inclusion of both the identifiers does
>         not handicap or restrict any solution. 
> 	
> 	Let us include both.
> 
> 
> 2. 	I believe based on the recent set of mails that the consensus no
>         longer favours inclusion of the 'ethertype'. Is there a
>         disagreement ?

There were many that said that an Ethertype was desirable and useful in
their implementations.  Your counter argument was that it was not needed
because it could be inferred through other means so why add an additional
mechanism.  If you would allow us to use the same logic used in #1 above
("the architecture not forcing a limited solution on any set of
aspirations"), then I would like an Ethertype defined as part of the
payload.  As noted earlier, the inclusion of an Ethertype does not handicap
or restrict any solution.

Roy

> 
> 
> 3. 	As many have noted in the last couple of days that using IB
>         over non-UD modes or utilising QPNs mapped to specific
>         endpoints is desirable. A complete, interoperable solution has
>         been presented in
>         draft-kashyap-ipoib-advanced-capabilities-00.txt. 
> 
> 	Please review and comment. 
> 
> Vivek
> 
> 
> 	
> 
> -- 
> 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

---

From: "Culley, Paul" <[email-masked]>
Date: Thu, 17 Jan 2002 08:04:59 -0600

If you insist on including the LID (presumably in the body of the ARP
Response) then I have the following thoughts:

1) Include a means where the ARP Requestor can decide when not to use
that LID.  For example, if IP across multiple IB subnets someday becomes
feasible, any time the subnet prefixes between the ARP Requestor and ARP
Responder are different, the LID (in the body of the response) will be
invalid.  There may also be circumstances where the ARP Responder knows
that the LID is not valid; in that case there should be a defined method
of indicating such.

2) Since the LID alone in the body of the ARP Response is not sufficient
to route packets, also provide the SL.  IB provides NO WAY to select an
SL, based only on the LID, unless the ARP requestor already has that LID
and an SL cached or is willing to look it up with the SA.  Since one of
the reasons for including the LID at all is to avoid this lookup, the
solution is not complete without SL.  [Please don't respond that some
implementation specific mechanism can be chosen to select SL; there is
no way for an endnode implementation to determine the SA policies for SL
usage at this time, so it is not possible for the endnode to reliably
chose an SL without asking the SA (or caching a LID/SL derived from the
SA).

3) A potential solution to the above problems that seems like it would
satisfy everyone would be to use both the SLID and SL from the IB
Header.  Since there may be some circumstances where the ARP Responder
KNOWs that this won't work (odd 3rd party ARP thingies have been
suggested), include a flag that indicates that the SLID/SL is invalid.
The GID is available in this case, or for those devices that want more
than a "best effort" path; it can be used for PathRecord Lookup.  This
will work properly for normal devices in the subnet, IB routers (when
they appear), and Proxy ARP types of routing.

Paul R. Culley
Compaq Sr. Fellow
281-514-5543

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 5:57 PM
To: [email-masked]
Subject: [Ipoverib] encapsulation issues

	
	Let us include both.

Vivek

---

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

>they appear), and Proxy ARP types of routing.

If the group can only reach consensus on this issue through the addition of 
these fields , then the above list seems like a reasonable starting point 
for such compromise.

Mike

---

From: "Arvind Murching" <[email-masked]>
Date: Thu, 17 Jan 2002 08:56:46 -0800

Proposal #3 below looks attractive.

Thanks
Arvind

-----Original Message-----
From: Michael Krause [mailto:[email-masked]] 
Sent: Thursday, January 17, 2002 8:33 AM
To: [email-masked]
Subject: RE: [Ipoverib] encapsulation issues

>they appear), and Proxy ARP types of routing.

If the group can only reach consensus on this issue through the addition
of 
these fields , then the above list seems like a reasonable starting
point 
for such compromise.

Mike

---

From: "H.K. Jerry Chu" <[email-masked]>
Date: Thu, 17 Jan 2002 10:45:14 -0800 (PST)

Paul,

Using additional bits to flag something being optional seems like an
attractive compromise in order to suite everybody's need. But there is
a constraint in IPv4 due to the broadcast nature of the ARP requests.
A node must advertise the same MAC addr to all the other nodes on the
link. In other words the response can not be requester dependent.
(If I tell node A don't use this field, I'd better tell node B the
same.) IPv6 doesn't have this constraint so it provides more flexibility.
But v4 is still dominating so we must find a solution for it.

It looks like for Proxy ARP the above won't be a problem though.
For IB router it could be a problem. (But the driver has the knowledge
to do the right thing. Oh, I just discover it requires driver snooping
ARP pkts, not the best soluion one would hope for.)

Also I'm very concerned about the refresh of the pathrecord cache (for
attributes like LID, SL, static rate, LMC...), most likely maintained
by the driver. Does IBA provide solid mechanism for one to build an
reliable event notification mechanism that anyone can register for
attribute changes, either local or remote?

We can (and should) only rely on ARP/ND to flush attributes that are part
of IPoIB link layer addrs. For the rest of attributes IBA must provide
a solution.

Rgds,

Jerry