On Jun 10, 2013, at 12:31 AM, Brian E Carpenter <[email protected]> wrote:
> On 10/06/2013 04:49, Tom Taylor wrote: >> On 09/06/2013 9:42 AM, Fernando Gont wrote: > > ... >>> I guess having a L4-pointer would have helped quite a lot. >>> >>> Cheers, >>> >> Would it be practical to define a HBH option that has an L4 pointer and >> assign a fixed order to it? > > http://tools.ietf.org/html/draft-zhang-6man-offset-option-01 > > It didn't fly in this WG at the time. The issue is that, in order to be able to see header X you need to push all the bits up to header X onto the forwarding engine. Having a header that says "The L4 header is at byte 142" simply pushes the L4 out by another 8 bytes, exacerbating the problem. This issue is: 1: In order to make a decision on header X the forwarding / filtering engine needs to see header X 2: This require pushing at least <number of bytes from start of packet to end of header X> up to the forwarding engine in a "cell". 3: Bandwidth into the forwarding engine is expensive / limited, and storage on the forwarding engine is expensive (this is not DRAM ;-)) 4: As you don't know (until you've looked) how far into the packet header X is, you need to choose some number and ship that many bytes to the forwarding engine. 5: Having a header that points at the L4 info doesn't help -- by the time you can see it you've already sucked the bits onto the engine. 6: Having additional logic that "prescreens" the packets looking for a pointer header *could* possibly work, but that is much of the forwarding engine logic - see #3. Choosing the optimum cell size is the tricky bit. If you increase the cell size you vastly increase cost -- if your competitors don't do the same, you've priced yourself out of the market. We are planning on updating the long-headers draft / publishing another "implementers guide" draft that suggests 128 or 256 bytes (as a straw man). This will hopefully be something that major vendors will sign up for. W > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
