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

Curtis Villamizar <curtis@ipv6.occnc.com> Wed, 15 January 2014 01:00 UTC

Return-Path: <curtis@ipv6.occnc.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3901D1AE008; Tue, 14 Jan 2014 17:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.84
X-Spam-Level:
X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYBy_y0qPvtu; Tue, 14 Jan 2014 17:00:26 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id B20381ADFDD; Tue, 14 Jan 2014 17:00:25 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F10C7J005674; Tue, 14 Jan 2014 20:00:12 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401150100.s0F10C7J005674@maildrop2.v6ds.occnc.com>
To: "Eggert, Lars" <lars@netapp.com>
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Tue, 14 Jan 2014 15:29:38 +0000." <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com>
Date: Tue, 14 Jan 2014 20:00:12 -0500
Cc: "mpls@ietf.org" <mpls@ietf.org>, Scott Brim <scott.brim@gmail.com>, IETF discussion list <ietf@ietf.org>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 01:00:27 -0000

In message <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com>
"Eggert, Lars" writes:
 
> Hi,
>  
> On 2014-1-14, at 16:23, Joel M. Halpern <jmh@joelhalpern.com> 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