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

Ross Callon <rcallon@juniper.net> Thu, 16 January 2014 22:32 UTC

Return-Path: <rcallon@juniper.net>
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 665891A1F76; Thu, 16 Jan 2014 14:32:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 XQ3yua-8N6Xc; Thu, 16 Jan 2014 14:32:39 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 46EE61A1F62; Thu, 16 Jan 2014 14:32:38 -0800 (PST)
Received: from mail136-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE021.bigfish.com (10.43.70.78) with Microsoft SMTP Server id 14.1.225.22; Thu, 16 Jan 2014 22:32:26 +0000
Received: from mail136-ch1 (localhost [127.0.0.1]) by mail136-ch1-R.bigfish.com (Postfix) with ESMTP id 8B542C0116; Thu, 16 Jan 2014 22:32:26 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -26
X-BigFish: VPS-26(z579ehz98dI9371I936eI15bfK542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h9a9j1155h)
Received-SPF: pass (mail136-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(51704005)(377454003)(377424004)(55674002)(24454002)(199002)(189002)(13464003)(81686001)(33646001)(81816001)(79102001)(56776001)(80976001)(46102001)(77982001)(59766001)(66066001)(49866001)(47736001)(80022001)(47976001)(50986001)(63696002)(4396001)(65816001)(54356001)(54316002)(76482001)(19580395003)(51856001)(19580405001)(83322001)(53806001)(76796001)(76786001)(76576001)(85852003)(83072002)(92566001)(93136001)(74706001)(31966008)(47446002)(74502001)(74662001)(90146001)(93516002)(56816005)(2656002)(81542001)(87936001)(81342001)(74316001)(74366001)(85306002)(87266001)(69226001)(74876001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail136-ch1 (localhost.localdomain [127.0.0.1]) by mail136-ch1 (MessageSwitch) id 1389911544490974_30073; Thu, 16 Jan 2014 22:32:24 +0000 (UTC)
Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail136-ch1.bigfish.com (Postfix) with ESMTP id 707C938004A; Thu, 16 Jan 2014 22:32:24 +0000 (UTC)
Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 16 Jan 2014 22:32:24 +0000
Received: from CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 16 Jan 2014 22:32:23 +0000
Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) with Microsoft SMTP Server (TLS) id 15.0.851.11; Thu, 16 Jan 2014 22:32:20 +0000
Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0851.011; Thu, 16 Jan 2014 22:32:20 +0000
From: Ross Callon <rcallon@juniper.net>
To: "Eggert, Lars" <lars@netapp.com>
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: AQHPB81jtn8uxkZO2EiBZeT7DEf4ppp6pziAgAK2KYCAAFQ7gIAAckaAgAAJRICAAAZDAIAD31WAgABWkACAAHXPgIAAN0wAgAEJtoCAACSWAIAAC2+AgAAH1ACAABCvgIAAAQmAgAABlACAAz/IAIAAA6wAgABUpZA=
Date: Thu, 16 Jan 2014 22:32:19 +0000
Message-ID: <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com>
References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <CAPv4CP-iwoHEiV=xtNAd7qT4r8OYvfE1ZjnKE=wWY5VVcQ3x8w@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <A1F82D9D-F9D0-46C1-B666-0C13DB79A845@netapp.com> <52D40B91.8040101@joelhalpern.com> <CAPv4CP9R-6Dv9O_H8Ox_-uLWMSzqpx7Gn97TF8jceFkVKPLWTw@mail.gmail.com> <52D518D9.7010703@cisco.com> <CAPv4CP-eNJuOKv4vWxGkiUPUTMkYyqY4cbTmj8M4sn+jXzmCkw@mail.gmail.com> <CAPv4CP-DnNdSoVEFTg9N53xP=yOd6pNe97WxmXJeGHBPKC2h6w@mail.gmail.com> <52D547B2.1060302@cisco.com> <DB6CF60F-FFBA-47DA-9FD6-7288CCB260A6@netapp.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com>
In-Reply-To: <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.11]
x-forefront-prvs: 0093C80C01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "EXT - joelja@bogus.com" <joelja@bogus.com>, "mpls@ietf.org" <mpls@ietf.org>, 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: Thu, 16 Jan 2014 22:32:41 -0000

>> These tunnels are stateless
>
> yep. (But they don't have to be.)

The tunnels strictly speaking do not have to be stateless. However, if you want routers to actually implement them, and you want to scale in both forwarding speed and number of tunnels, then yes they do have to be stateless. 

Ross
(speaking only as an individual contributor) 

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars
Sent: Thursday, January 16, 2014 12:20 PM
To: EXT - joelja@bogus.com
Cc: mpls@ietf.org; IETF discussion list
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Hi,

On 2014-1-16, at 18:06, joel jaeggli <joelja@bogus.com> 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