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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 2014-1-16, at 18:06, joel jaeggli <joelja@xxxxxxxxx> wrote:
> These tunnels are stateless

yep. (But they don't have to be.)

>  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.

Lars

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]