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

<l.wood@surrey.ac.uk> Wed, 15 January 2014 05:46 UTC

Return-Path: <l.wood@surrey.ac.uk>
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 D39191AE2D5; Tue, 14 Jan 2014 21:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
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 tzo_5OTM5n58; Tue, 14 Jan 2014 21:46:41 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2645A1AE1BF; Tue, 14 Jan 2014 21:46:41 -0800 (PST)
Received: from [85.158.136.51:38639] by server-13.bemta-5.messagelabs.com id 56/97-11357-5B026D25; Wed, 15 Jan 2014 05:46:29 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-16.tower-49.messagelabs.com!1389764788!23096706!1
X-Originating-IP: [131.227.200.31]
X-StarScan-Received:
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14276 invoked from network); 15 Jan 2014 05:46:28 -0000
Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-16.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 15 Jan 2014 05:46:28 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 15 Jan 2014 05:46:27 +0000
From: l.wood@surrey.ac.uk
To: curtis@ipv6.occnc.com, lars@netapp.com
Date: Wed, 15 Jan 2014 05:45:43 +0000
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: Ac8RjS132P0/ZYvoS3qqFjAC/swR5wAJ9pSN
Message-ID: <290E20B455C66743BE178C5C84F1240847E63346CA@EXMB01CMS.surrey.ac.uk>
References: Your message of "Tue, 14 Jan 2014 15:29:38 +0000." <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com>, <201401150100.s0F10C7J005674@maildrop2.v6ds.occnc.com>
In-Reply-To: <201401150100.s0F10C7J005674@maildrop2.v6ds.occnc.com>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mpls@ietf.org, scott.brim@gmail.com, 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
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 05:46:43 -0000

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@ietf.org] On Behalf Of Curtis Villamizar [curtis@ipv6.occnc.com]
Sent: 15 January 2014 01:00
To: Eggert, Lars
Cc: mpls@ietf.org; 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@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
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls