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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
joel jaeggli writes:
 
> On 1/16/14, 9:19 AM, Eggert, Lars wrote:
> > Hi,
> > 
> > On 2014-1-16, at 18:06, joel jaeggli <[e-mail]> wrote:
> >> These tunnels are stateless
> > 
> > yep. (But they don't have to be.)
>  
> They do in-fact have to be stateless with respect to the contents. They
> will no doubt be created in a same distributed forwarding  engines that
> currently do IP-MPLS encapsulation and L2-MPLS encapsulation. likewise
> their decapsulation will occur in such devices.
>  
> > Look at it the other way: if transport area folks would want to send
> > MPLS packets into the network in some problematic way, I'm sure the
> > routing and ops folks would not be amused.

They would never notice since MPLS packets are only passed around
internally and in some cases among peer providers.  If you did try to
do that and succeeded in getting even one packet through there are
some security holes to worry about.  Point is that you can't get MPLS
packets into provider networks unless something is very seriously
wrong and the already persistant attackers would have a picnic.

> Today congestion occurs on MPLS networks. intermediate hops that are
> congested have no choice but to drop packets.

And nothing bad happens because providers that allow any congestion to
occur by provisioning so that it can happen (usually occasionally or
very rarely) carry two kinds of traffic in that network.  One is IP in
MPLS or IP native.  The other is high margin VPN services and emulated
legacy L2 services that are given a different TC value.  What the
providers want to happen on light congestion happens.  Slight drop
gets IP (mostly TCP still to this date) to reduce load.  The high
paying VPN and emulated legacy L2 services are completely unaffected
(as the provider wants given they are paying a lot for that).

So I'm agreeing with you (Joel).

> > Lars

Curtis