On 2018-11-26 12:01, Christian Huitema wrote:
>
> On 11/25/2018 2:11 PM, Nick Hilliard wrote:
>> Christian Huitema wrote on 25/11/2018 20:40:
>>> Nick made that point, probably unintentionally, when he wrote that
>>> "transit operators would generally take the view that any data-plane
>>> packet which needs to be put through a slow path will be rate limited
>>> up to 100% loss". Last I checked, data plane processing is
>>> implemented in specialized components that are designed for speed.
>>
>> I was talking specifically about dfz transit routers, not edge devices
>> or firewalls. There are exceptions to fast-path processing where
>> data-plane packets are punted to management plane CPUs for generalised
>> processing rather than being forwarded by the ASIC / NPU due to
>> hardware inability to process the packets correctly (e.g. gigantic EH
>> chains), or by protocol specification (e.g. hbh). What I said
>> previously referred to control plane rate limiting of these types of
>> data plane packets.
>
> I understand the limitation. My point is simply that a DFZ router with
> such limitations has little business implementing filtering by payload
> type. It is more likely to generate trouble tickets because
> communication broke rather than praise because some unwanted traffic was
> filtered in transit, rather than at ingress or egress.
In that case it seems that this section of the draft needs attention:
2.2. Applicability Statement
This document provides advice on the filtering of IPv6 packets with
EHs at transit routers for traffic *not* explicitly destined to such
transit routers, for those cases in which such filtering is deemed as
necessary.
Brian
