ietf
[Top] [All Lists]

Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

2014-01-28 10:27:46
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.

Attachment: signature.asc
Description: This is a digitally signed message part.

<Prev in Thread] Current Thread [Next in Thread>