Hi Joel,

Options are really bad for fast path processing. To find an option,
the entire list of TLV's needs to be parsed, which is really hard
especially when you have a limited number of clock cycles.

For end-to-end processing however options can be considered better
(especially if the traffic is CPU bound and not BFD or some other
application). Though there are issues even there.

Assume a case where we need to prioritize OSPFv3 packets to the CPU,
we need to put multiple such filters for the same, as the OSPFv3
header can come after a bunch of IPv6 headers.

Thanks,
Vishwas

On Thu, Feb 3, 2011 at 7:11 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:
> Lets be a little careful here:
> 1) If we say "No Extension Headers for intermediate processing", and "No Hop
> By Hop Options", then we are saying that we do not want any extensions
> intended to be processed in intermediate routers.  While I personally like
> that, I want to make really sure that we understand that is what we are
> saying.
>
> 2) I have been told that many large rotuers have a setting that causes them
> to ignore the hop by hop options field.  To the degree that is both true and
> turned on, then we need to allow for that in our think (both positive and
> negative.)
>
> Yours,
> Joel
>
> On 2/3/2011 9:57 PM, Christopher Morrow wrote:
>>
>> On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (Kam) Lam<hingka...@gmail.com>
>>  wrote:
>>>
>>> The below white paper from Cisco asserts that most vendors including
>>> Cisco process Hop-by-Hop extension headers in CPU (slow path). Is this
>>> correct?
>>>
>>>
>>> http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html
>>>
>>> If Yes, then we should not add support for more sub options with HBH
>>> header.
>>
>> yes, see notes from me (in particular) about this from the last 2+
>> years... no more HBH header options pls... OR understand that these
>> may/will get dropped (probably the whole packet actually) at some
>> provider edges.
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to