Subject: RE: [Ipoverib] IPoIB advanced capabilities (fwd)

From: Vivek Kashyap <[email-masked]>
Date: Fri, 11 Jan 2002 22:30:20 -0800 (PST)

Forwarding to mailing list. I erroneously sent it to a
non-existent address rather than to [email-masked].

Vivek

Forwarded message:
> From [email-masked]  Fri Jan 11 17:27:33 2002
> X-MimeOLE: Produced By Microsoft Exchange V6.0.6115.0
> Content-Class: urn:content-classes:message
> MIME-Version: 1.0
> Content-Type: text/plain;
> 	charset="us-ascii"
> Subject: RE: [Ipoverib] IPoIB advanced capabilities
> Date: Fri, 11 Jan 2002 17:25:27 -0800
> Message-ID: <[email-masked]>
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [Ipoverib] IPoIB advanced capabilities
> thread-index: AcGbB2uP7LMdmQs8SI+CjzxrhR0N9AAAJkog
> From: "Arvind Murching" <[email-masked]>
> To: "Vivek Kashyap" <[email-masked]>
> Cc: <[email-masked]>
> X-OriginalArrivalTime: 12 Jan 2002 01:25:27.0758 (UTC) FILETIME=[045186E0:01C19B08]
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by eng4.beaverton.ibm.com id g0C1RXV03039
> 
> Okay, I should read this in more detail. I got the impression that the
> draft does not specify details of encapsulation/communication for the
> other modes.
> 
> Thanks
> Arvind
> 
> -----Original Message-----
> From: Vivek Kashyap [mailto:[email-masked]] 
> Sent: Friday, January 11, 2002 5:23 PM
> To: Arvind Murching
> Cc: [email-masked]
> Subject: Re: [Ipoverib] IPoIB advanced capabilities
> 
>         No, service IDs are explained in section 4.0. If it is unclear
>         I can add more details.
> 
>         Wrt decision of the host I have said that if A and B want to
>         talk. A gets to know B has the capability and vice versa after
>         address resolution. However, it is A's (say the client)
>         decision on whether it talks to B (say the server) using a
>         particular mode. I don't think we should mandate a particular
>         choice- that is upto the application and the user.
> 
> Vivek
> 
> > 
> > This is a multi-part message in MIME format.
> > 
> > --------------InterScan_NT_MIME_Boundary
> > Content-Type: multipart/alternative;
> > 	boundary="----_=_NextPart_001_01C19B05.7C49D496"
> > 
> > ------_=_NextPart_001_01C19B05.7C49D496
> > Content-Type: text/plain;
> > 	charset="us-ascii"
> > Content-Transfer-Encoding: quoted-printable
> > 
> > Vivek, two issues regarding the capabilities flags:
> > 
> > (a) From a purist point of view, the link layer address is not the
> right
> > place to specify end-node capabilities.
> > 
> > (b) Section 3.2 says:
> > 
> > 	  The method by which a host decides it wants to use
> > 	  the IPoIB-RC/UC/RD services is beyond the scope
> >         of this specification.
> > 
> > However, this means that two nodes that conform to this specification,
> > and decide to use the capability bits, can easily fail to
> interoperate.
> > This is because this document does not specify how they, for example,
> > set up RC/UC connections (what service ID is used etc). We should
> either
> > fully specify the encapsulation and connection mechanisms for these
> > other transport methods (if time permits), or simply label the bits
> used
> > for this purpose as "Reserved" in this spec, and require all
> conformant
> > implementations to set this to 0 on transmit and ignore on receive.
> > Later versions of this spec can define these bits, along with details
> of
> > how they are used.
> > 
> > - Arvind
> > 
> > -----Original Message-----
> > From: Vivek Kashyap [mailto:[email-masked]]=20
> > Sent: Friday, January 11, 2002 4:34 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [Ipoverib] IPoIB advanced capabilities
> > 
> > Folks,
> >         We have discussed IP over non-UD links a few times on this
> >         mailing list.The capability-flags in the address-resolution
> >         packets provide the necessary hook to implementing such
> >         solutions in an interoperable way. I presented a solution at
> >         the IPoIB WG meeting at SLC earlier this month.
> > 
> >         Attached is a draft that I submitted a few days back. It
> >         hasn't been announced yet but I thought that we need to move
> >         forward. The draft and the solution is completely disjoint
> >         from the encapsulation draft except for the capability-bits
> >         being included in the address resolution packet.
> > 
> > 	I look forward to your comments.=20
> > 
> > Vivek
> > <snip>
> > 
> > ------_=_NextPart_001_01C19B05.7C49D496
> > Content-Type: text/html;
> > 	charset="us-ascii"
> > Content-Transfer-Encoding: quoted-printable
> > 
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > <HTML>
> > <HEAD>
> > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> > charset=3Dus-ascii">
> > <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> > 6.0.6115.0">
> > <TITLE>RE: [Ipoverib] IPoIB advanced capabilities</TITLE>
> > </HEAD>
> > <BODY>
> > <!-- Converted from text/rtf format -->
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">Vivek,</FONT><FONT SIZE=3D2 FACE=3D"Courier =
> > New"></FONT></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2
> FACE=3D"Courier =
> > New">two issues</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
> > FACE=3D"Courier New"> regarding the capabilities =
> > flags</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier
> =
> > New">:</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">(a) From a purist point of view, the link layer address is not
> the =
> > right place to specify end-node capabilities.</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">(</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2
> FACE=3D"Courier =
> > New">b</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2
> FACE=3D"Courier =
> > New">)</FONT> <FONT SIZE=3D2 FACE=3D"Courier New">S</FONT></SPAN><SPAN
> =
> > LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">ection 3.2 =
> > says:</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN =
> > LANG=3D"en-us">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT
> SIZE=3D2 =
> > FACE=3D"Courier New">&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT =
> > SIZE=3D2 FACE=3D"Courier New">The method by which a host decides =
> > it</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New"></FONT></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2
> FACE=3D"Courier =
> > New">wants to use</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN =
> > LANG=3D"en-us">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT
> SIZE=3D2 =
> > FACE=3D"Courier New">&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT =
> > SIZE=3D2 FACE=3D"Courier New">the IPoIB-RC/UC/RD services is beyond
> the =
> > scope</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of this =
> > specification.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">However, this means that two</FONT></SPAN><SPAN LANG=3D"en-us"> =
> > <FONT SIZE=3D2 FACE=3D"Courier New">nodes</FONT></SPAN><SPAN =
> > LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New"> that conform to =
> > this</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier
> =
> > New"> specification,</FONT> <FONT SIZE=3D2 FACE=3D"Courier =
> > New">and</FONT> <FONT SIZE=3D2 FACE=3D"Courier New">decide to use the
> =
> > capability</FONT><FONT SIZE=3D2 FACE=3D"Courier New"> =
> > bits,</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2
> FACE=3D"Courier =
> > New">can easily</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
> > FACE=3D"Courier New"> fail to interoperate</FONT></SPAN><SPAN =
> > LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">. This =
> > is</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New"> because this document does not specify how</FONT></SPAN><SPAN =
> > LANG=3D"en-us"> <FONT SIZE=3D2 FACE=3D"Courier =
> > New">th</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2
> FACE=3D"Courier =
> > New">ey</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2
> FACE=3D"Courier =
> > New">, for example, set up RC/UC connections</FONT></SPAN><SPAN =
> > LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New"> (what service ID
> is =
> > used etc)</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
> > FACE=3D"Courier New">.</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT
> SIZE=3D2 =
> > FACE=3D"Courier New">We should either fully specify the =
> > encapsulation</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
> > FACE=3D"Courier New"> and</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT =
> > SIZE=3D2 FACE=3D"Courier New">connection mechanisms for these other =
> > transport methods</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
> > FACE=3D"Courier New"> (if time permits)</FONT></SPAN><SPAN =
> > LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">, =
> > or</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 FACE=3D"Courier =
> > New">simply label the bits used for this purpose as
> &quot;Reserved&quot; =
> > in this spec, and require all conformant implementations to set this
> to =
> > 0 on tr</FONT><FONT SIZE=3D2 FACE=3D"Courier New">ansmit and ignore on
> =
> > receive.</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
> > FACE=3D"Courier New">Later versions of this spec can define these
> bits, =
> > along with details of how they are used.</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">- Arvind</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">-----Original Message-----<BR>
> > </FONT><FONT SIZE=3D2 FACE=3D"Courier New">From:</FONT><FONT SIZE=3D2
> =
> > FACE=3D"Courier New"> Vivek Kashyap [<A =
> >
> HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
> > </FONT><FONT SIZE=3D2 FACE=3D"Courier New">Sent:</FONT><FONT SIZE=3D2
> =
> > FACE=3D"Courier New"> Friday, January 11, 2002 4:34 PM<BR>
> > </FONT><FONT SIZE=3D2 FACE=3D"Courier New">To:</FONT><FONT SIZE=3D2 =
> > FACE=3D"Courier New"> [email-masked]<BR>
> > </FONT><FONT SIZE=3D2 FACE=3D"Courier New">Cc:</FONT><FONT SIZE=3D2 =
> > FACE=3D"Courier New"> [email-masked]<BR>
> > </FONT><FONT SIZE=3D2 FACE=3D"Courier New">Subject:</FONT><FONT
> SIZE=3D2 =
> > FACE=3D"Courier New"> [Ipoverib] IPoIB advanced =
> > capabilities</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">Folks,</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We have discussed IP =
> > over non-UD links a few times on this</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mailing list.The =
> > capability-flags in the address-resolution</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packets provide the =
> > necessary hook to implementing such</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; solutions in an =
> > inter</FONT><FONT SIZE=3D2 FACE=3D"Courier New">operable way. I =
> > presented a solution at</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the IPoIB WG meeting
> at =
> > SLC earlier this month.</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Attached is a draft
> that =
> > I submitted a few days back. It</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hasn't been announced
> =
> > yet but I thought that we need to move</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; forward. The =
> > draf</FONT><FONT SIZE=3D2 FACE=3D"Courier New">t and the solution is =
> > completely disjoint</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from the encapsulation
> =
> > draft except for the capability-bits</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; being included in the
> =
> > address resolution packet.</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN =
> > LANG=3D"en-us">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT
> SIZE=3D2 =
> > FACE=3D"Courier New">I look forward to your comments.
> </FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">Vivek</FONT></SPAN></P>
> > 
> > <P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
> > New">&lt;snip&gt;</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>
> > 
> > </BODY>
> > </HTML>
> > ------_=_NextPart_001_01C19B05.7C49D496--
> > 
> > --------------InterScan_NT_MIME_Boundary--
> > 
> > 
> 
> 
> -- 
> 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)

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