ietf
[Top] [All Lists]

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

2014-01-16 11:35:46
On 16/01/2014 17:19, Eggert, Lars wrote:
Hi,

On 2014-1-16, at 18:06, joel jaeggli <joelja(_at_)bogus(_dot_)com> wrote:
These tunnels are stateless
yep. (But they don't have to be.)
Ah, they do if they are to scale. State at speed is really hard. The sort
of systems we are talking about do things like pipeline counters
and it is loooooots of packets later before the counter is actually
incremented.
  The endpoints not the encapsulators have visibility into the
end-to-end loss latency properties of the path.
Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 domains - 
where not reacting to congestion may be OK - can now go over the wider 
Internet, where this is not OK.

I'd be great if those apps would change. But in the meantime, it's the duty of 
the encapsulator - who enables this traffic to break out of an L2 domain and go 
over the wider net - to make sure the traffic it emits conforms to our BCPs.

  the encapsulator is an intermediate hop, similar to any other router
in the path.
It's not. For the rest of the network, that encapsulator is indistinguishable 
from any other app that sends UDP traffic.

UDP is a transport-layer protocol, and we have practices how it is to be used 
on the net. If you want to use it for encapsulation, you bind yourself to these 
BCPs.

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.
The root cause of the problem here is that UDP, has bifurcated into
a general purpose encapsulation.

Stewart

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