this draft should be about mpls in TCP - a TCP tunnel. That will fix all congestion concerns. I look forward to reading justification of why TCP checksums can be turned off. Lloyd Wood http://about.me/lloydwood ________________________________________ From: mpls [mpls-bounces@xxxxxxxx] On Behalf Of Curtis Villamizar [curtis@xxxxxxxxxxxxxx] Sent: 15 January 2014 01:00 To: Eggert, Lars Cc: mpls@xxxxxxxx; Scott Brim; IETF discussion list Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard In message <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@xxxxxxxxxx> "Eggert, Lars" writes: > Hi, > > On 2014-1-14, at 16:23, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote: > > Isn't that basically the problem of the inner traffic sender, not the > > problem of the tunnel that is carrying the traffic? > > no, because the sender of the inner traffic may be blasting some > L2traffic, for an L2 where that is OK behavior. But that traffic is > nowbeing encapsulated inside UDP and can hence go anywhere on the > net*without the sender being aware of this*. That application would be a PW application and it would be more appropriate to fix that in PW if there is consensus for a need to do so, which afaik there is not. > > Asking tunnel's to solve the problem of applications with > > undesirablebehavior seems backwards. > > It is the *tunnel* that performs the encapsulation and allows > thattraffic to go places it couldn't before. And so it's the > tunnel'sresponsibility to make sure that the traffic it injects into > theInternet complies with the BCPs we have on congestion control. > > Lars If it is a service provider encapsulating traffic within their own network, then they know what they are doing. That is the anticipated use and among that community there is no consensus for need for congestion control. If it is some hostile hosts trying to send MPLS over UDP over IP, they, being hostile, are going to disable any congestion control. Besides, no hostile host has a T1 to tunnel over the Internet so they would be sending the same traffic they would normally just send of UDP over IP. Anything made up of frames (Ethernet, ATM, FR) over PW over MPLS is carrying IP and if frames drop, the IP applications see the drop and behave just as they would for any drop. (ATM shreadding thread to /dev/null please). If congestion aware or using a congestion aware transport, the top level applications are still congestion aware. If congestion ignoreant, they are still congestion ignoreant. If hostile, they are still hostile. Back to draft-ietf-mpls-in-udp. I think the most recent text proposed by the author is fine. Curtis _______________________________________________ mpls mailing list mpls@xxxxxxxx https://www.ietf.org/mailman/listinfo/mpls