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

Greg Daley <gdaley@au.logicalis.com> Fri, 24 January 2014 03:38 UTC

Return-Path: <gdaley@au.logicalis.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 9ED461A012A; Thu, 23 Jan 2014 19:38:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.442
X-Spam-Level:
X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.535, SPF_PASS=-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 kSGdqo_qWe88; Thu, 23 Jan 2014 19:38:48 -0800 (PST)
Received: from smtp2.au.logicalis.com (smtp2.au.logicalis.com [203.8.7.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0721A0117; Thu, 23 Jan 2014 19:38:48 -0800 (PST)
Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only
Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only
Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp2.au.logicalis.com with ESMTP; 24 Jan 2014 14:38:47 +1100
Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0347.000; Fri, 24 Jan 2014 14:38:45 +1100
From: Greg Daley <gdaley@au.logicalis.com>
To: "'Joel M. Halpern'" <jmh@joelhalpern.com>, Joe Touch <touch@isi.edu>, Edward Crabbe <edc@google.com>
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: AQHPF5eBZzPPQlRcgk6ua2U45NfiYJqQTqiAgAHKKoCAAL8zyf//mUCAgAC+CKA=
Date: Fri, 24 Jan 2014 03:38:44 +0000
Message-ID: <72381AF1F18BAE4F890A0813768D992817FD35E1@sdcexchms.au.logicalis.com>
References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <CACKN6JFzaGkiCzJgcd0BEHeWi5x0ReemJOv4ASuXAnz36RA-fg@mail.gmail.com> <52E18BF1.1040004@isi.edu> <52E1D093.8040603@joelhalpern.com>
In-Reply-To: <52E1D093.8040603@joelhalpern.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.196.183]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 24 Jan 2014 05:10:23 -0800
Cc: "mpls@ietf.org" <mpls@ietf.org>, Noel Chiappa <jnc@mercury.lcs.mit.edu>, 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
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: Fri, 24 Jan 2014 03:38:51 -0000

Hi Joel, 

> -----Original Message-----
> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Friday, 24 January 2014 1:32 PM
> To: Joe Touch; Edward Crabbe
> Cc: mpls@ietf.org; Noel Chiappa; IETF discussion list
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
> MPLS in UDP) to Proposed Standard
> 
> Joe, while your argument is internally consistent, it is not consistent with
> history.  We have not demanded that tunnel entries behave fully like source
> hosts for any of the other myriad kinds of tunnels we have done over the years.


Actually, many of the tunnel protocols on the standards track have been either for upper-layer IP or Transport protocols or require congestion mitigation:


RFC 4448 for EoMPLS, and 5994 for Ethernet pseudowires over MPLS each ask that tunnelled protocols support congestion mechanisms,
RFC5085 and 5586:  VCCV and BFD with VCCV define congestion considerations for pseudowire tunnels.
RFC 4719 updated by RFC 5641: Ethernet pseudowires over L2TP (a UDP encapsulated protocol)  permit packet loss indications to take down the active circuit. 
RFC 4454: ATM over L2TPv3 indicates that inelastic flows are stopped when congestion occurs.

They (ATM over L2TPv3 and Ethernet PW over L2TPv3) also require usage over a traffic engineered network.

RFC 4817 MPLS over L2TPv3 requires non-IP upper layer protocols not to exceed the offered load of a typical TCP application on the same path.


For those protocols which have IP, UDP, TCP, SCCP or DCCP this is just passing the buck to the upper layer protocol (which is OK, so long as the application protocol in UDP has congestion measures). For environments where this cannot be relied upon, additional protocol specification and applicability statements have previously been applied.

> If we take your logic as stated, then the usage of IPSec over UDP would be
> required to apply congestion control unless it knew that all the content traffic
> was TCP.  Is that really your intent?

Actually, one of the compelling use cases for running MPLS over UDP (or L2TPv3) would be to encapsulate the traffic in ESP in order to combat passive snooping.

For ESP I believe the implicit assumption (via the Traffic Selectors in IKE) was that the upper layer protocol is IP or in transport mode another protocol such as TCP, UDP etc.

Sincerely, 

Greg Daley
gdaley@au.logicalis.com