Subject: [Ipoverib] Bounced message

From: "Bill Strahm" <[email-masked]>
Date: Wed, 12 Dec 2001 18:15:42 -0800

I bounced this message, but it should be posted as well (hopefully Arvind
won't resend it immediately)...

From: "Arvind Murching" <[email-masked]>
To: <[email-masked]>
X-OriginalArrivalTime: 13 Dec 2001 01:20:22.0769 (UTC)
FILETIME=[56236610:01C18374]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id
UAA25702

I am not very confident that the IPNG (or whatever WG) will entertain a
proposal to curtail the IP version numbering space because of an IP over
Foo RFC.

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Wednesday, December 12, 2001 3:58 PM
To: Arvind Murching
Cc: [email-masked]
Subject: Re: [Ipoverib] IPoIB architecture/encapsulation

Arvind,
        Yes, it is. The largest hardware type assigned at present is
        0x31. We are likely to get 0x32 or something near that value.
        The hardware type is a 16 bit field. So we get 0 in the higher
        4 bits.

Vivek

>
> Vivek, one of the implications of demux'ing based on the first few
bits
> is that we (IP over IB) would need to be assigned a hardware type
value
> by IANA that is guaranteed to not match a valid IP version number. Is
> this feasible?
>
> Thanks
> Arvind
>
> -----Original Message-----
> From: Vivek Kashyap [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 11:01 AM
> To: Larsen, Roy K
> Cc: [email-masked]
> Subject: Re: [Ipoverib] IPoIB architecture/encapsulation
>
> Roy,
>         That is not how it is.
>
>         Other IB protocols and data streams are not going to follow
>         IPoIB rules. So your comparison to existing standards -
>         ethernet for example - is not correct. In ethernet every
>         protocol follows the type specification. In our case the rules
>         apply to IPv4/ARP and IPv6 only. No one else is bound by
>         them.
>
>         Therefore there is no difference between looking at the first
>         4 bits or first 4 bytes or 40 bytes conceptually except that
>         looking at the first 4 bits gives you a simpler implementation
>         and avoids a pseudo-header.
>
>         The protocol is explicitly defined by the first 4 bits in the
>         header. The interface will be asked to distinguish between
>         only only 1 (IPv6) or maximum two (IPv4/ARP) packets at the
>         QP. Any other packets would be illegal by the virtue of the
>         QP's association to specific protocols. So anything else can
>         be dropped. Why should I invest in 4 bytes of header which is
>         put in the payload - it has to be added when sending the
>         packet and removed when receiving. It provides no further
>         utility than the 4 bits - it is disambiguating only two
>         protocols.
>
>         Also note that the patent idea that you mention is the one
>         that includes the payload identifier in the BTH header, the
>         link header. The 'signature' solution will easily work
>         interoperably in such a situation. Thus that solution is
>         compatible with the best solution that will come in the
>         future. That is not the case with other solutions mentioned.
>
>
> Vivek
>

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

---

From: "Vivek Kashyap" <[email-masked]>
Date: Wed, 12 Dec 2001 22:00:06 -0800

Arvind,
     The version number space is 4 bits long only. It is 0 to 15 with most
of them allocated. Only 1 to 3 and 10 to 14 are unassigned. Similarly the
hardware type is a 16 bit field with values assigned in the order in which
they are asked. One could ask for a given value with sufficient reasoning.
There is no clash and no curtailing of either of the version numbers is
required. The only condition is that IB not be assigned a value greater
than 0xFFF i.e. 4095. We can certainly get that.  Like I said the current
allocated values are till 31. So there is no restriction on IP version
number allocation from IB.

Vivek

--
Vivek Kashyap
Linux Technology Center, IBM
[email-masked]
[email-masked]
Ph: 503 578 3422 T/L: 775 3422

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Wednesday, December 12, 2001 3:58 PM
To: Arvind Murching
Cc: [email-masked]
Subject: Re: [Ipoverib] IPoIB architecture/encapsulation

Arvind,

Vivek

bits
value