Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On 6/10/13 7:01 AM, Andrew McGregor wrote: Which is definitely not true in general. Some do that, many do not inspect beyond 128, some go further. The lower bound is probably 53. There's a lowest common denominator problem if you expect to be able to find an l4 header as part of your forward

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

Which is definitely not true in general. Some do that, many do not inspect beyond 128, some go further. On Mon, Jun 10, 2013 at 8:09 AM, Arturo Servin wrote: > > There is another conversation in v6ops that mentioned that > switching > ASICs do not inspect beyond 40 bytes. > > > -as > >

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

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/htm

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

There is another conversation in v6ops that mentioned that switching ASICs do not inspect beyond 40 bytes. -as On 6/9/13 10:46 AM, Fernando Gont wrote: > Ray, > > On 06/08/2013 01:06 PM, Ray Hunter wrote: >> I was thinking something along the lines of: >> >> - The preferred len

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On 06/09/2013 06:49 PM, Tom Taylor 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? 1) I doubt that would fly. 2) IPv6 EHs seem to be so unreliable already,

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On 06/09/2013 06:36 PM, Ray Hunter wrote: >> Fernando Gont >> 9 June 2013 15:46 >> Ray, >> >> I'd say one should enforce a "each EH can be present at most once". >> >> ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even that is >> kind of irrational: 1280

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On 09/06/2013 9:42 AM, Fernando Gont wrote: On 06/08/2013 11:12 AM, joel jaeggli wrote: Or is the complexity of the ASIC implementation of a header chain parser more heavily influenced by the fact that the header chain is defined as a linked list of type-length-value items that can be built up

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

> Fernando Gont > 9 June 2013 15:46 > Ray, > > I'd say one should enforce a "each EH can be present at most once". > > ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even that is > kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be allowing >

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

Ray, On 06/08/2013 01:06 PM, Ray Hunter wrote: > I was thinking something along the lines of: > > - The preferred length of a Hop by Hop extension header for optimized > forwarding in hardware is always 16 octets long. > > - the Hop by Hop EH may be present exactly once, or not present, and is >

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On 06/08/2013 11:12 AM, joel jaeggli wrote: >> >> Or is the complexity of the ASIC implementation of a header chain parser >> more heavily influenced by the fact that the header chain is defined as >> a linked list of type-length-value items that can be built up in any >> number of valid combinatio