Hi Lars,
I think that " The whole point of running MPLS is to create networks in which
paths are provisionable, so this is usually not an issue." is only partially
correct. LDP-based MPLS network is not provisionable and LSPs follow IP best
route selection. Explicit signaling of LSP is achievable in (G)MPLS by using
RSVP(-TE) signaling.
Regards,
Greg
-----Original Message-----
From: mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Eggert, Lars
Sent: Friday, January 10, 2014 8:10 AM
To: Joel Halpern
Cc: mpls(_at_)ietf(_dot_)org; IETF
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
MPLS in UDP) to Proposed Standard
Hi,
On 2014-1-10, at 16:36, Joel M. Halpern <jmh(_at_)joelhalpern(_dot_)com> wrote:
Maybe I am completely missing things, but this looks wrong.
If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion
control will make it more likely that the service won't work. Is that
really the goal?
We do not perform congestion control on MPLS LSPs.
Assuming that a UDP tunnel is carrying just MPLS and was established
just for MPLS, why would we expect it to behave differently than an
MPLS LSP running over the exact same path, carrying the exact same traffic?
we've been rehashing this discussion several times over the years, e.g., for
PWE, AMT, etc. In order to carry fixed-rate or otherwise
non-congestion-controlled traffic over unprovisioned general Internet paths,
there needs to be some sort of basic congestion control mechanism, like a
circuit breaker.
The whole point of running MPLS is to create networks in which paths are
provisionable, so this is usually not an issue. But if you start sticking MPLS
inside of UDP, those packets can go anywhere on the net, so you need mechanisms
to control the rate of that traffic if it causes congestion, or at the very
least you need to be able to stop the traffic if it creates severe congestion.
Lars