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

[Mark Tinka]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100902/19b72377/attachment.bin>