IETF Logo Mail Archive

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

Ross Callon <rcallon@juniper.net> Wed, 22 January 2014 02:40 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 2859A1A025F; Tue, 21 Jan 2014 18:40:12 -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 n8sAdxCtsrrY; Tue, 21 Jan 2014 18:40:09 -0800 (PST)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3746A1A0152; Tue, 21 Jan 2014 18:40:09 -0800 (PST)
Received: from mail52-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 22 Jan 2014 02:40:08 +0000
Received: from mail52-am1 (localhost [127.0.0.1]) by mail52-am1-R.bigfish.com (Postfix) with ESMTP id 3774AE0144; Wed, 22 Jan 2014 02:40:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -23
X-BigFish: VPS-23(z579ehzbb2dI98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h1033IL1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach9a9j1155h)
Received-SPF: pass (mail52-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(13464003)(24454002)(377454003)(51704005)(479174003)(19580405001)(86362001)(83322001)(51856001)(50986001)(33646001)(74876001)(66066001)(2656002)(74706001)(4396001)(80022001)(47736001)(47976001)(83072002)(65816001)(49866001)(46102001)(54356001)(53806001)(19580395003)(74316001)(81686001)(92566001)(93136001)(90146001)(2171001)(93516002)(74366001)(80976001)(76482001)(87936001)(74662001)(56816005)(85852003)(74502001)(85306002)(47446002)(81342001)(81542001)(81816001)(79102001)(63696002)(87266001)(31966008)(76576001)(59766001)(77982001)(54316002)(56776001)(76796001)(76786001)(69226001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail52-am1 (localhost.localdomain [127.0.0.1]) by mail52-am1 (MessageSwitch) id 139035840584948_19187; Wed, 22 Jan 2014 02:40:05 +0000 (UTC)
Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.248]) by mail52-am1.bigfish.com (Postfix) with ESMTP id 106AA46004C; Wed, 22 Jan 2014 02:40:05 +0000 (UTC)
Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 22 Jan 2014 02:40:04 +0000
Received: from CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Wed, 22 Jan 2014 02:40:02 +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; Wed, 22 Jan 2014 02:40:00 +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; Wed, 22 Jan 2014 02:40:00 +0000
From: Ross Callon <rcallon@juniper.net>
To: Joe Touch <touch@isi.edu>, "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/IAIAAA6wAgABUpZCACArNAIAAFXLw
Date: Wed, 22 Jan 2014 02:40:00 +0000
Message-ID: <c3c178b033114a4eba7c226293f451c1@CO2PR05MB636.namprd05.prod.outlook.com>
References: <20140102151419.4692.48031.idtracker@ietfa.amsl.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> <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> <52DF1AC4.7080007@isi.edu>
In-Reply-To: <52DF1AC4.7080007@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.13]
x-forefront-prvs: 00997889E7
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: "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: Wed, 22 Jan 2014 02:40:12 -0000

If the upper layers (the thing that runs over the tunnel) involves applications over TCP over IP, or if it is otherwise responding to congestion in the same way that we expect anything running over IP to respond to congestion, then we don't want the tunnel to also independently try to respond to congestion (two independent cooks cooking the same meal does not necessarily lead to success). 

If the upper layer does not respond to congestion, then perhaps it shouldn't be running over the open Internet (with or without a tunnel), unless the *total* bandwidth that could be used is inherently quite low. On the other hand, it might want to run within a data center or internally to a service provider network with appropriate provisioning. 

Ross

-----Original Message-----
From: Joe Touch [mailto:touch@isi.edu] 
Sent: Tuesday, January 21, 2014 8:12 PM
To: Ross Callon; Eggert, Lars
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



On 1/16/2014 2:32 PM, Ross Callon wrote:
>>> 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.

There's clearly a problem though:

	- tunnels must be stateless to be efficiently implemented

	- transport layer tunnels must have congestion control

Saying that the only way we can make tunnels cheap is to make them break 
the Internet isn't a good solution.

Maybe it's time to expect something that's inherently costly to end up 
being expensive?

Joe

v2.23.0 | Report a Bug | By Email