Subject: RE: [Ipoverib] draft-ietf-ipoib-ip-over-infiniband-00.txt

From: "Larsen, Roy K" <[email-masked]>
Date: Tue, 26 Feb 2002 15:47:44 -0800

> -----Original Message-----
> From: Vivek Kashyap [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 1:36 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Ipoverib] draft-ietf-ipoib-ip-over-infiniband-00.txt
> 
> 
> > 
> > At 11:28 AM 2/26/2002 -0800, Vivek Kashyap wrote:
> > >         Please comment soon so that the encapsulation draft can be
> > >         updated and submitted before the cut off of march 2nd.
> > >
> > >         For that matter please send in your comments on 
> the draft(s)
> > >         in general in the next couple of days so that they can be
> > >         included before the cut off.
> > 
> > For a UD-based IP over IB implementation, Ethertype isn't 
> required if the 
> > rest of the IB infrastructure has its act together to allow 
> non-IP services 
> > to be properly identified. Hence, I don't have a problem 
> with it not being 
> > included within the specification.
> > 
> > Mike
> 
> Yes, you are right. Ethertype is also not required for RC (or other
> mode) IP over IB implementations.

But of course, I would assume we wouldn't be using ARP for RC (or other
modes) either so I'm not sure how this is relevant.  ARP is at the root of
this "evil".  The IBTA defined SIDR to deal with the situation but we chose
not to use it.  For connected modes, we'll have to use well-known service
IDs.  So the logical question readers of our work might ask is, if well-know
service IDs are be good enough for all the other IPoIB modes, why aren't
they good enough for UD?  

Now don't get me wrong. I'm *not* asking the group to consider changing the
UD address resolution mechanism at this late date.  Just pointing out that
when you stray from using the services provided by the link architecture, it
causes some awkward and inconsistent design choices.  I think encapsulating
the LSAP designated by the sender is a way of redeeming the choice of ARP
because it means the IPoIB protocol becomes self-contained and doesn't rely
on peeking and interpreting user payload data.

Roy

> 
> Vivek
> 
> > 
> > 
> > _______________________________________________
> > IPoverIB mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ipoverib
> > 
> 
> 
> -- 
> Vivek Kashyap
> Linux Technology Center, IBM
> [email-masked] 
> [email-masked] 
> 503 578 3422 (o)
> 
> _______________________________________________
> IPoverIB mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipoverib
> 

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

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 26 Feb 2002 17:23:04 -0800 (PST)

> modes) either so I'm not sure how this is relevant.  ARP is at the root of

The comment has nothing to do with ARP. It has to do with
encapsulating protocols with a header containing a type or not.

When IP over RC is done, the two endpoints know exactly what they are
exchanging - it is an IB connection exchanging IP packets (no ARP as
you note). So, in the RC case also there is no need of a header/type
encapsulating the IP packet.

Vivek