On Saturday, January 25, 2014 10:47:48 PM Curtis Villamizar
wrote:
Reality check time.
To get the PW over MPLS drafts past the TSV AD there is a
SHOULD regarding congestion control.
AFAIK: No service providers ask for it. No one
implements it. If they did implement it no one would
deploy it.
PW over MPLS is generally carrying relatively low volumes
of high priority traffic. The TC bits (MPLS flavor of
Diffserv DSCP) are used to enforce the higher priority.
If congestion occurs other traffic on that
infrastructure (typically plain old Internet) sees loss.
That is intended. This is the reality of how PW over
MPLS is deployed.
Anyone who knows of implementation or deployment of
congestion control for PW over MPLS can correct me.
And this is what I mentioned several weeks ago. As
operators, we police traffic on ingress and egress (some
operators shape on egress, but the result is the same), and
this is how we control admission to the network.
I have never used intrinsic congestion mechanisms in
protocols (outside of lab fun-time when I'm really bored),
and don't know anyone that has either. Of course, the risk
is that router/switch vendors have all sorts of
implementation as regards policing/shaping; but I can say
that in the past 7x years or so (and especially in the past
year for switches), this is reasonably mature, and no vendor
worth their salt is shipping product that can't police or
shape properly.
Just one point to make, not all traffic being carried over
MPLS is "high priority". Some of it really isn't, and is
treated on a best-effort basis. But, this is all specific to
operators and their customers. General traffic admission
rules still apply all the same.
Personally, if there was congestion mechanisms proposed as
part of the MPLS-in-UDP spec., I would never run them as an
operator. I'd rely on policing at the edge, as usual.
Cheers,
Mark.
signature.asc
Description: This is a digitally signed message part.