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

<l.wood@surrey.ac.uk> Fri, 17 January 2014 03:06 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 E9F691ADE87; Thu, 16 Jan 2014 19:06:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 TjEAOtZQdtJa; Thu, 16 Jan 2014 19:06:34 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id 3A20A1ADE86; Thu, 16 Jan 2014 19:06:33 -0800 (PST)
Received: from [85.158.136.51:60836] by server-1.bemta-5.messagelabs.com id 28/01-21065-D2E98D25; Fri, 17 Jan 2014 03:06:21 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-16.tower-49.messagelabs.com!1389927980!23311593!1
X-Originating-IP: [131.227.200.35]
X-StarScan-Received:
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26557 invoked from network); 17 Jan 2014 03:06:20 -0000
Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-16.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 17 Jan 2014 03:06:20 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 17 Jan 2014 03:06:20 +0000
From: l.wood@surrey.ac.uk
To: stbryant@cisco.com, lars@netapp.com, joelja@bogus.com
Date: Fri, 17 Jan 2014 03:03:05 +0000
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: Ac8S4Wu6DFHO19nLS4OJGfloEdinxgATzjW0
Message-ID: <290E20B455C66743BE178C5C84F1240847E63346CF@EXMB01CMS.surrey.ac.uk>
References: <20140102151419.4692.48031.idtracker@ietfa.amsl.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>, <52D8185D.1010902@cisco.com>
In-Reply-To: <52D8185D.1010902@cisco.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, 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, 17 Jan 2014 03:06:37 -0000

There's an opportunity to define a simple generic IPv6 encapsulating mechanism a la UDP, but
with a payload checksum of varying coverage (header only, partial payload, full payload)
and with the (stronger than UDP) checksum placed at the end of the packet.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [ietf-bounces@ietf.org] On Behalf Of Stewart Bryant [stbryant@cisco.com]
Sent: 16 January 2014 17:35
To: Eggert, Lars; Joel Jaeggli
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 16/01/2014 17:19, Eggert, Lars wrote:
> 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.)
Ah, they do if they are to scale. State at speed is really hard. The sort
of systems we are talking about do things like pipeline counters
and it is loooooots of packets later before the counter is actually
incremented.
>>   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.
The root cause of the problem here is that UDP, has bifurcated into
a general purpose encapsulation.

Stewart