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

joel jaeggli <joelja@bogus.com> Fri, 17 January 2014 20:43 UTC

Return-Path: <joelja@bogus.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 CA1121AC829; Fri, 17 Jan 2014 12:43:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 LE5mSixiKu7f; Fri, 17 Jan 2014 12:43:26 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 432D71AC3FA; Fri, 17 Jan 2014 12:43:26 -0800 (PST)
Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0HKh3Od046197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Jan 2014 20:43:04 GMT (envelope-from joelja@bogus.com)
Message-ID: <52D995D2.8080301@bogus.com>
Date: Fri, 17 Jan 2014 12:42:58 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0
MIME-Version: 1.0
To: stbryant@cisco.com, "Eggert, Lars" <lars@netapp.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> <52D8185D.1010902@cisco.com>
In-Reply-To: <52D8185D.1010902@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="GuGkHp4QL3d7iFsdeIdh6Hbc3lHN8oka2"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 17 Jan 2014 20:43:04 +0000 (UTC)
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: Fri, 17 Jan 2014 20:43:28 -0000

On 1/16/14, 9:35 AM, Stewart Bryant wrote:

>> 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.

One observation with respect to general purpose use of UDP as an mpls
encapsulation on the internet as a whole that seems to have been missed
in this discussion is the rather dire prospects for MTU and potential for
fragmentation. Effectively, assuring, that you do not need to fragment
requires as certain amount of coordination.

1500 mtu hops pretty effectively (imho) preclude the use of this
encapsulation on the internet as a whole (if encapsulated traffic is not
aware of a correspondingly lower MTU) this is especially true for L2vpn
where you don't have recourse to PMTUD). As the document notes (section 4)
preventing fragmentation is rather important.


> Stewart
>