RE: FW: [ipcdn] FW: Dscp and DscpOrAny TCs

Rich,

I, and others in the Diffserv work including John, I believe, have
always held a belief in a "null" or "no quality of service" PHB, aka the
bit-bucket. Some of us even thought about writing a draft to describe
this behaviour, recommending that its default DSCP value should be
"everything else". Such a PHB implements part of the "defense against
... class of theft- and denial-of-service attacks" described by RFC
2474. With such a concept in place, there is no need for any additional
filtering configuration: filtering becomes just a special case of the
general Diffserv behaviour of a node.

<slight detour>
I have also argued, mostly during development of RFC 3290 in the
Diffserv WG, that the QoS treatment that a packet receives is likely to
be layer-independent (the differences between a L2 bridge, a L3 router,
a L4-L7 load balancing switch etc. are mostly to do with the addresses
on which a node makes switching/routing decisions, not the queueing
treatment that packets receive). This implies that you may well need two
classifiers on a packet, one to decide what QoS treatment, one to decide
where to route it - the packet only goes through if both the routing and
the QoS decide not to bit-bucket it. I think that "administrative
bit-bucketing based on packet contents" is much more of a "QoS" thing
than a "routing" thing: administrative controls on routing (e.g. BGP
filters) are typically placed on the distribution of reachability of
address information, not on data packet contents (other than the
relevant address field(s)) themselves.
<end detour>

Having said that, at least for nodes defending the edge of a Diffserv