> joel jaeggli <mailto:joe...@bogus.com>
> 10 June 2013 22:04
> On 6/10/13 9:35 PM, Ray Hunter wrote:
>>> Christopher Morrow <mailto:christopher.mor...@gmail.com>
>>> 10 June 2013 20:59
>>> On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter <v6...@globis.net> wrote:
>>>>> Christopher Morrow <mailto:christopher.mor...@gmail.com>
>>>>> 10 June 2013 17:22
>>>>> On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins
>>>>>
>>>>> Some of the discussion already had talks about ordering and optimum
>>>>> method to find X in the header chain. What happens in these
>>>>> situations
>>>>> when someone sends 'lots' of packets with 'bad ordering' of the
>>>>> header
>>>>> bits? Will the devices in the path behave 'well'? or will I get
>>>>> degraded forwarding performance because of bad ordering? or will the
>>>>> packets be dropped? or ?
>>>>>
>>>>> it's worth thinking about what can go wrong with this requirement to
>>>>> order EH bits in certain ways.
>>>>>
>>>>> -chris
>>>>>
>>>> I purposefully left that particular can unopened, because I
>>>> consider it
>>>> unlikely that we will obtain rough consensus on it.
>>> :)
>>>
>>>> IMHO it's better to have an informational RFC that says "if you obey
>>>> these simple formatting rules, your packet is likely to be transported
>>>> (fast)" than nothing at all.
>>> right, but you're also asking HW manufacturers to optomize on a
>>> certain ordering (sort of), that's going to lead to: 1, 2, 3 ordering
>>> works great!
>> Yes. Better than today.
>>
>>>   but: 3,2,1 == slow-path :(
>>>
>>> or COULD lead to that.
>> Same as today. So they'll continue to make their own decision on whether
>> to deploy slow path or drop.
> Understand that there is no slow path in high capacity devices.
>
> There is fast path or no path.
>
> If slow path exists it becomes a bottleneck or a dos target.
>
I understand exactly.

Which is why I am studiously ignoring the issue. :)

regards,
RayH


>>
>>>> I just searched draft-ietf-v6ops-6204bis-12 for requirements on
>>>> extension headers. Nada AFAICS.
>>>>
>>>> I also just tested my own home CPE for outbound transmission of
>>>> extension headers (with and without firewall configured):
>>>> HBH EH: tick
>>>> Destination Options EH: tick
>>>> Fragment EH: looks like they're always dropped
>>> neat... how about proto-59? (noext-headers)? :)
>> Untested (no test source yet)
>>
>> regards,
>> RayH
>>
>
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to