Subject: Re: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4

From: Ajoy C Siddabathuni <[email-masked]>
Date: Thu, 11 Apr 2002 13:56:24 -0700 (PDT)

Jerry,

>To keep 4-byte alignment I suggest to have Ethertype residing in the
>lower (network byte-ordering) 2 bytes with the upper 16 bits marked
>as reserved. It'd use the values for ARP, IPv4 and IPv6 from the
>"EtherType" defined by IANA. Beyond these three protocols I'm not
>sure we (IPoIB WG) want or even can say much.

Would this by definition allow implementations to use LLC/SNAP headers if
required?  In the cIPoverATM (see rfc2225) world, the LLC/SNAP
is the default packet format for IP datagrams.

I dont necessarily have an opinion one way or the other, but having the
alignment definetly helps.

~Ajoy

>Date: Thu, 11 Apr 2002 13:34:54 -0700 (PDT)
>From: "H.K. Jerry Chu" <[email-masked]>
>Subject: Re: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4
>To: [email-masked], [email-masked]
>MIME-Version: 1.0
>Content-MD5: GenAJUOSmMHlgivkPxdJZA==
>X-Mailman-Version: 1.0
>List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
>X-BeenThere: [email-masked]
>
>>X-Sender: [email-masked]
>>Date: Thu, 11 Apr 2002 06:33:06 -0700
>
><snip>
>
>>>Last week I asked people to bring "new, convincing evidence" when
>>>arguing for or against EtherType. But unfortunately in the past few
>>>days all I heard was either old arguments, or people reiterating their
>>>positions. Since no one has brought forward any new, convincing
>>>evidence against EtherType, and in both the mailing list and the
>>>f2f meeting Bill and I feel there have been more people for EtherType
>>>than against it, plus a number of people requesting EtherType are
>>>actually working on real implementation, I hereby declare EtherType
>>>to be the rough consensus of the WG to be included in the UD payload
>>>of every IPoIB packet.
>>
>>What is the specification of Ethertype other than it is 16-bits of space 
>>followed by the next set of headers?
>
>To keep 4-byte alignment I suggest to have Ethertype residing in the
>lower (network byte-ordering) 2 bytes with the upper 16 bits marked
>as reserved. It'd use the values for ARP, IPv4 and IPv6 from the
>"EtherType" defined by IANA. Beyond these three protocols I'm not
>sure we (IPoIB WG) want or even can say much.
>
>>Is an implementation required to 
>>process this field if it does not want to do so?
>
>IMO the sender MUST incorporate EtherType correctly in all the
>outgoing ARP/IPv4/IPv6 pkts (including both unicast and multicast).
>The receiver SHOULD but is not required to demux based on EtherType.
>This is partly implementation detail. If a receiver can correctly
>demux without examining EtherType, why do we care?
>
>>Is Ethertype required for 
>>all IB transport services that may support IP traffic - it seems that it 
>>must be to remain consistent from an implementation point of view.
>
>Agreed. But since the consensus call was made specifically for UD,
>for non-UD people can speak up if they have a different opinion.
>
>>
>>>Over the past couple of days a couple of senior IBTA members have
>>>reiterated their positions against EtherType. But in my opinion the
>>>decision of including EtherType in the UD payload is at least partly
>>>as the result of the IBTA failing to address people's need to have a
>>>field in IB identifying the type of the data being encapsulated in
>>>the UD payload.
>>
>>In essence, the consensus is that the IP over IB workgroup is defining the 
>>official Raw protocol on behalf of the IBTA since in many people's opinion 
>>the IBTA screwed up.  As such, it would be beneficial to simply write a 
>>draft with this as the stated goal so that anyone can use it independent of 
>>IP over IB's charter for such purposes and then have the IP over IB 
>>specification reference said draft.
>
>Agreed. But since the draft will address a generic IB issue rather than
>IPoIB issue, IBTA seems to be the right place for such a document, not
>IETF.
>
>>  This will be much cleaner and at least 
>>make everyone who may want to implement such a service not have to go 
>>searching within an IP over IB specification to find this non-IP focused 
>>functionality.
>
>Agreed.
>
>>
>>>Some argued that the QP is supposed to serve that
>>>purpose, but we are not even doing that for IPv4, ARP/RARP and IPv6.
>>>I think the argument is rather weak.
>>
>>Just as weak as hijacking one spec to include functionality that has 
>>nothing to do with the stated charter of this workgroup.  Consensus has 
>>been reached so I'll let it die.
>
>Had IBTA fixed raw datagram to be used by IPoIB as the default IB
>transport, or had we adopted SIDR to map ARP/IPv4/IPv6 to different
>QPs, we wouldn't have gone down this path. Failing both, Ethertype
>seemed inevitable.
>
>Jerry
>
>>
>>Mike
>>
>
>
>_______________________________________________
>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: "H.K. Jerry Chu" <[email-masked]>
Date: Fri, 12 Apr 2002 17:18:11 -0700 (PDT)

Ajoy,

This sounds reasonable to me. But someone needs to make a concrete
proposal here, e.g., writing a draft. (Mike?)

Jerry

---

From: "Vivek Kashyap" <[email-masked]>
Date: Tue, 16 Apr 2002 01:21:16 -0700

To me the reasoning is very simple.

 The intelligence we need is the protocol type of the data stream.

No header: we get the intelligence from the QPN and/or from the first 4
bits of the payload.  We get the necessary intelligence without adding any
additional signal. I would say this is the best option.

2 byte header: Signal is 2 bytes. Intelligence is carried by both the
bytes. If all DMA or system architecture can be considered to be able to
copy the payload to a  4*n+2 byte boundary then this would be the next best
option.

4 byte header:Signal is 4 bytes but intelligence is only in 2
bytes(ethertype). Only half of the signal provides any information.

LLC/SNAP: Signal is 8 bytes but intelligence is only in 2 bytes. So we get
25% return. We have added another 4 bytes with no increase in intelligence.

Hence a '4-byte ethertype' is better than the 8 byte LLC/SNAP.

Also, I don't think you are right in dismissing non-LLC/SNAP use. LLC/SNAP
is not the favored mode in general - just look at 802.3 vs. DIX ethernet.

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

                      Ajoy C                                                                                                       
                      Siddabathuni             To:       [email-masked], [email-masked]                          
                      <Ajoy.Siddabathun        cc:       [email-masked], [email-masked], [email-masked],            
                      [email-masked]>                [email-masked]                                                                  
                      Sent by:                 Subject:  Re: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4            
                      ipoverib-admin@ie                                                                                            
                      tf.org                                                                                                       

                      04/15/2002 03:52                                                                                             
                      PM                                                                                                           
                      Please respond to                                                                                            
                      Ajoy C                                                                                                       
                      Siddabathuni                                                                                                 

>It takes another 4 bytes and provides no new information. The issues
>you indicate above are equally addressed by a 'type' field.

Ofcourse it provides no new information - if you are running IPoIB
in vacum. It is much cleaner than putting a 4 byte header with reserved
fields. Also expect (in a few years) that there will be multi-protocol
routers that will be sitting at the edges of an
IB-Ethernet-osi-apple-network.
They would definetly like to handle packets in a std way - especially when
cp'ing pkts from one kind of "link" to another. They dont need to handle
cases such as - "oh by the way, if this link was an IPoIB link..I needed to
strip the top 4bytes...and not interpret the next 16 bits before I look at
the eth-type".

>
>'No header case' is disallowed as per WG consensus. Otherwise, the
>4-byte ethertype field is equally viable as the 8 byte LLC/SNAP field.
>It has the advantage of being 4 bytes smaller.

I would'nt consider "4 bytes smaller" as an advantage. Especially if you
are
working with IB header lengths upto 68 bytes. And then if you are working
with
TCP/IPv4/v6 add upto 60+.

>
>How about RFC2734 ? There is nothing standard about this.
Well - time to learn from another's mistakes.

Here is my summary -

 - Having no-header at all will give you alignment. No ethtype to mux on.
   But you could have always figured out all IP'ish types from the
IP-hdrtype
   field.

 - Having 4byte "non-std" header will also give you alignment. Gives you
   all the info you need. But yes, there are certain non-std elements in
   the header that implementations would have to be aware of  - especially
   if they were porting an existing stack.

 - Having 8byte std-header will be standards conforming for future
multi-prot-
   col enviroments. Ofcourse, retains alignment.

~Ajoy

>>
>> Frame formats -
>>
>> a) If LLC/SNAP was used then you automatically get a 32bit-word
alignment
>>    for the IP-Datagram.
>>
>>    The frame would look something like --
>>
>>    LRH (8bytes)
>>    GRH (40 bytes)*
>>    BTH (12 bytes)
>>    DETH (8 bytes)
>>                LLC       OUI     EthType
>>    LLC/SNAP <AA-AA-03><00-00-00><xx-xx>   (8bytes)
>>    IPv4/IPv6 Datagram
>>    ICRC
>>    VCRC
>>
>> b) Embedding just the  ethtype - the frame would look like -- also gives
>>    you the alignment - but is a non-std way of doing things (with
reserved
>>    fields etc in the format).
>>
>>    LRH (8bytes)
>>    GRH (40 bytes)*
>>    BTH (12 bytes)
>>    DETH (8 bytes)
>>
>>     Rsvd   EthType
>>    <??-??><xx-xx>  (4bytes)
>>    IPv4/IPv6 Datagram
>>    ICRC
>>    VCRC
>> ----
>>
>> My opinion on this is that if EthType is ever supported, it should be
>> supported using the std mechanism (a) to be consistent with how other
>> IPoverXXX protocols have been defined in the past. (See RFCs -ATM: 2225,
>> 1577, 1483 SMDS:1209 FR:1294)
>
>How about RFC2734 ? There is nothing standard about this.
>
>[ As another example one can even use a 2 byte header if it works out
>for the hardware -i.e. if one can DMA to a 2 byte boundary, the IP
>header will land at a 4 byte boundary. ]
>
>Vivek
>
>>
>> If the WG feels that in the foreseeable future, only IP will ever be
>> supported, then yes there is no need for the Ethtype - ie. leave it
alone,
>> you can still get the IP datagram 32bit aligned right after DETH. On the
>> other hand, if the WG feels that we do it the way our ancestors have
done it
>> there is enough argument already in place for supporting llc/snap hdrs.
>>
>> ~Ajoy
>>
>>
>> >Date: Mon, 15 Apr 2002 10:20:49 -0700
>> >To: Yaron Haviv <[email-masked]>, "'H.K. Jerry Chu'"
>> <[email-masked]>, "[email-masked]'" <[email-masked]>,
>> "[email-masked]'" <[email-masked]>
>> >From: Michael Krause <[email-masked]>
>> >Subject: RE: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4
>> >Mime-Version: 1.0
>> >X-Mailman-Version: 1.0
>> >At 10:31 AM 4/14/2002 +0200, Yaron Haviv wrote:
>> >>Jerry,
>> >>
>> >>We must stop expending the definition somewhere so we get the spec out
>> >>This is IPoIB we are talking about, there is no need for LLC/SNAP, and
we
>> >>just need the Ethertype
>> >
>> >The consensus is that people want to have the full range of Ethertype
>> >values supported.  As such, this needs to be specified independent of
the
>> >IP over IB specification so that everyone may use these values without
>> >requiring them to implement IP over IB.
>> >
>> >Mike
>> >
>> >
>--
>Vivek Kashyap
>Linux Technology Center, IBM
>[email-masked]
>[email-masked]
>503 578 3422 (o)

---

From: Ajoy C Siddabathuni <[email-masked]>
Date: Wed, 17 Apr 2002 11:36:58 -0700 (PDT)

[Resend:attempt-2]

On Tue, 16 Apr 2002, Vivek Kashyap wrote:

> > I think one must get outside the "try to save some bytes here and there" line
> > of thinking when defining wire protocols and make sure that you dont have to
> > write another rfc next year to obsolete this one. All those RFCs that defined 
the
> 
> 	And why will it become obsolete ? 

Well, if the router vendors come along and discover that it is so
inefficient to convert frames from one format to another - they
might just write a new one.

> 
> > LLC/SNAP headers in them were not mis-guided, would you think? You would'nt 
endup
> 
>         Oh c'mon! you are the one who belittled the most recent RFC in
>         the list: RFC2734. You exhorted us to "learn from others'
>         mistakes" regarding this RFC. My comment was that just because
>         some RFCs used LLC/SNAP, it does not make it a standard but
>         just one way of doing things.

It is a std. when most protocols defined so far chose to do it in that
"one way of doing things" - what more is needed to make a std.
There are already  'n' different standards out there - my  point was to
stick with the one with the highest prevalence and not invent a new one.
I think the WG is also required to look and understand existing  IP encap-
sulation protocols that are in wide use before going ahead and defing a
new format/protocol. I am sure the WG will need to refer back and forth
to the those RFCs when we get to the IPoverIB(RC) - UD is a nobrainer
relative to the complexities of RC.

Most IPoverXXX protocols defined so far went by the book to accomodate
that format. There may be 1 or 2 exceptions, I just dont want us to go
down the path of those exceptions.

> 
>         And I do think that LLC/SNAP is useless - the 3 bytes of LLC
>         provide nothing. Then you have 3 bytes of OUI before getting
>         to the type field. Those 6 bytes might as well not exist.

My point has been that it is, yes, useless when you are only concerned
about IPoverIB and not even consider how this meshes with a multi-protocol
enviroment.

You might come around and tell me, we will deal with it when it becomes
a problem. That is the time for the new rfc.

> 
> 
> > with an IB header of upto 68 bytes for just UD if saving bytes from the 
header
> > was the goal. Recall that at wire speeds of 2-10Gbps these should not matter.
> 
>         Just because one can afford to be lax doesn't mean one should
>         be. What good is deliberately adding bytes that provide
>         nothing? 

IBA already provides a Raw-Datagram format with a RWH, it seems like we
made one full circle to get there - why not just use raw-datagrams  and
get it over with it.

>         You mentioned working with multiprotocols in 'edge routers' -
>         what about the ubiquitous DIX ethernet ? No header at all,
>         what of LLC/SNAP! You mentioned ATM - as far as I know it
>         suggests that the encapsulation format is negotiable. So, you
>         can work with or without LLC/SNAP. LLC/SNAP doesn't seem to be
>         the common encapsulation format.

Infact, LLC/SNAP is the default encapsulation format for Classical IP over
ATM. Also see the other RFCs that I pointed out. This had a lot to do
with how all edge devices such as routers and bridges like to see commonly
understood formats in thier internal memory structures. Beyond that I am
not allowed to speak, the RFCs can speak for themselves.

~Ajoy

> 
>         I, for one, need a lot more convincing before I can support
>         the idea of LLC/SNAP being the common encapsulation in the
>         future.  
> 
> Vivek
> 
> > 
> > 
> > 
> > >
> > >
> > >                                                                                                                                   
> > >                      Ajoy C                                                                                                       
> > >                      Siddabathuni             To:       
> > [email-masked], [email-masked]                          
> > >                      <Ajoy.Siddabathun        cc:       
[email-masked], 
> > [email-masked], [email-masked],            
> > >                      Sent by:                 Subject:  Re: [Ipoverib] 
> > consensus call on EtherType, min MTU and DHCPv4            
> > >                      ipoverib-admin@ie                                                                                            
> > >                      tf.org                                                                                                       
> > >                                                                                                                                   
> > >                                                                                                                                   
> > >                      04/15/2002 03:52                                                                                             
> > >                      PM                                                                                                           
> > >                      Please respond to                                                                                            
> > >                      Ajoy C                                                                                                       
> > >                      Siddabathuni                                                                                                 
> > >                                                                                                                                   
> > >                                                                                                                                   
> > >
> > >
> > >
> > >
> > >