[j-nsp] CoS Marking/Rewrite Theory - Update!

[Chris Evans]

I asked for this years ago but was blown off.  Basically got the 'that is
the way it is' statement.  As stated the current implementation is very
limiting.

Cisco has had this feature since I can remember on all of their platforms.
> On Thursday, September 02, 2010 06:44:23 am Michel de
> Nostredame wrote:
>
>> It looks like can only perform the TOS bit to TOS bit
>> translation.
>
> Not quite.
>
> My understanding (I can't test this yet) - and from my
> discussions with Juniper - is that the Translation tables
> actually rewrite the ToS field based on a user-defined
> value.
>
> So yes, ingress remarking is supported by this.
>
>> However the most useful function will need
>> to leverage firewall filter to perform the "TOS bit
>> marking" on the ingress.
>
> This is actually supported, but has a number of limitations:
>
> - the JUNOS firewall filters support then 'then
> dscp' action, but it's only works on the Trio-
> based line cards.
>
> - if your router has DPC-based line cards, you'd
> need to apply this to the Loopback interface,
> which means traffic is switched in software (not
> good - but haven't tried it to prove).
>
> - at this time, it looks like JUNOS only supports
> DSCP for IPv4 in the firewall filters; I don't see
> support for DSCP for IPv6 or EXP bits.
>
> - I know the M320 or larger supports remarking of
> ingress traffic, but only to DSCP 0; I'm uncertain
> whether newer code provides similar support for
> additional bit values as in the case of the Trio-
> based cards, or more importantly, which PIC's are
> supported with this enhancement.
>
>> It is very difficult to perform all those sophisticated
>> marking on the egress interface
>> by only leverage lame rewrite function.
>
> I agree - egress-based remarking (which is the classical way
> JUNOS has historically implemented this) is not terribly
> flexible.
>
> For cases where we've deployed boxes in a P/PE role, egress
> remarking is a real pain when interfaces act as transit
> links for both customer-sourced/destined and core traffic.
>
> Ingress remarking is more elegant here, as the different
> interfaces in a P/PE-based router are uniquely independent
> from a QoS marking and classification perspective.
>
>> For example, depends on PIC we have today, there are only
>> 4~8 forwarding-class can be used.
>
> 16 forwarding-classes, but yes, still 8 queues (can be a bit
> confusing for the uninitiated, since forwarding-classes and
> queues can many times be referred to as the same thing).
>
>> However, there are
>> more TOS type we can mark onto a packet. By leveraging
>> the policy statement together with egress firewall
>> filters, we can control
>> the bandwidth consumptions; if under some criteria (ex,
>> exceed usage), we can "re-mark" this packet to another
>> TOS (or drop it, or something else.)
>
> A lot of use-cases for being able to able to remark traffic
> as early as possible, i.e., on ingress.
>
>> What I requested to my Juniper SE is to make ingress
>> firewall filter able to "mark"
>> each packet TOS bit on the "then" section.
>
> See my comments as above.
>
> Beyond that, it doesn't look like Juniper are going to be
> doing much more than this, particularly because of the new
> Translation tables feature. I hope I'm wrong.
>
> My beef with Juniper on this is making the cards so
> "weirdly" that features that appear basic in nature can
> easily NOT be supported by the hardware when much-needed
> enhancements appear in later code. It boggles my mind, but
> could lend itself - in explanation - to the Services modules
> (MS-PIC, AS-PIC, MS-DPC) concept.
>
> Aaarggh, I dunno...
>
>> For those J series software router, it should be easy to
>> roll out these functions
>> compares to those hardware based box (theoretically...)
>
> Yes, theoretically - but then we still have to deal with all
> the Flow mode nonsense and all that, just to get new
> features. It's always something :-\.
>
> But I digress...
>
> Cheers,
>
> Mark.