Re: ip-precedence for management traffic

[Dorn Hetzel <dhetzel () gmail com>]

Marc,

I don't think that's entirely true.

I have in previously run networks that remarked all precedence on inbound
traffic at the borders to particular values (mostly zero except where policy
dictated other) and then accepted the precedence values internally for
priority control.

Customers were allowed to send contracted amounts of higher precedence
traffic, but anything over was marked down (or dropped).  So most traffic
got best effort, but marked traffic got a relatively guaranteed QOS.

This was quite some time ago (2000-2001), so I'm thinking it ought to still
be doable today.  You have to be diligent in remarking inbound traffic at
all boundaries, but it's not rocket science.

Regards,

-Dorn

On Tue, Dec 29, 2009 at 1:17 PM, Sachs, Marcus Hans (Marc) <
marcus.sachs () verizon com> wrote:

> Sorry, your original query got lost behind the smoke of my out-of-the-box
> musings.
>
> My biggest quarrel with any type of IP precedence is that anybody along the
> chain can set or reset these bits.  There is no assurance that a packet's
> priority will remain at the level set by the originator unless you have some
> very well disciplined netadmins between sender and receiver who do not
> fiddle with header bits.  If I knew that I could reliably set ToS bits in
> the IP header and they would remain unchanged then I would add a shim to my
> local stack that sets all of my flows at the highest priority thereby making
> my Internet experience a wee bit faster than somebody who leaves those three
> bits set to 000.
>
> I'm sure others will have widely different opinions.
>
> Marc
>
> -----Original Message-----
> From: Luca Tosolini [mailto:bit.gossip () chello nl]
> Sent: Tuesday, December 29, 2009 1:38 PM
> To: nanog
> Subject: Re: ip-precedence for management traffic
>
> Experts,
> my inquiry was very specific and bounded to the following assumptions:
> - in-band management
> - not possible to filter customer traffic, certainly not for somebody
> else's customer.
> - IP
>
> In this case diffserv can help prioritize management plane traffic over
> user traffic. To do that only ipp6 and ipp7 values are available for non
> user traffic.
> IPP6 is used by default for routing protocols, that is control plane; so
> probably it is better not to mess around with it.
> This leaves to IPP7 for management plane traffic, value that I can not
> recall of having seen used by any application/protocol.
>
> What is the general opinion about this?
>
> Thanks.
>
>
> On Tue, 2009-12-29 at 12:02 +0100, Luca Tosolini wrote:
> > Experts,
> > what is the general opinion of using ipp 7 'network control' for
> > management traffic like: telnet ssh snmp .....
> >
> > The idea is that ipp 0 1 2 3 4 5 are used for user traffic
> > ipp = 6 is used by default by routing protocols like BGP, OSPF, LDP ...
> >
> > this leaves out only ipp 7 for management traffic, on the premise that
> > routing and management should not share the same queue and
> > resources.....
> >
> > Thanks,
> > Luca.