Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)
<l.wood@surrey.ac.uk> Sun, 12 January 2014 02:59 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 550E71ACCF8; Sat, 11 Jan 2014 18:59:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 E7Cl-HXCPHrL; Sat, 11 Jan 2014 18:59:56 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0441AD8EB; Sat, 11 Jan 2014 18:59:54 -0800 (PST)
Received: from [195.245.231.67:12094] by server-17.bemta-5.messagelabs.com id 91/A7-19152-F1502D25; Sun, 12 Jan 2014 02:59:43 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-13.tower-82.messagelabs.com!1389495582!35539380!1
X-Originating-IP: [131.227.200.35]
X-StarScan-Received:
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24692 invoked from network); 12 Jan 2014 02:59:42 -0000
Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-13.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 12 Jan 2014 02:59:42 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Sun, 12 Jan 2014 02:59:42 +0000
From: l.wood@surrey.ac.uk
To: adrian@olddog.co.uk, randy@psg.com
Date: Sun, 12 Jan 2014 02:59:41 +0000
Thread-Topic: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)
Thread-Index: AQLp3cWoqiSzZKGjmFXJEPC82F9z6gH14gYaAYJCBgICOkjTg5gY93XwgAQ4kWA=
Message-ID: <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk>
References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk>, <m2d2k1a8ze.wl%randy@psg.com> <290E20B455C66743BE178C5C84F1240847E63346B5@EXMB01CMS.surrey.ac.uk>, <012801cf0d24$9b80b180$d2821480$@olddog.co.uk>
In-Reply-To: <012801cf0d24$9b80b180$d2821480$@olddog.co.uk>
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: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, david.black@emc.com, jnc@mit.edu, tsvwg@ietf.org
Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)
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: Sun, 12 Jan 2014 02:59:58 -0000
On nested checksums, the question is how they are nested; it's a matter of scope. With a bunch of checksums checking only a payload and any inner checksums like Russian Matryoshka dolls, the end-to-end argument tells us that for reliable receipt of the payload, only the innermost checksum matters. But here, we are not solely checking the payload, but information on how to deliver and identify that payload - and while an outer Ethernet CRC is across the last link, the UDP checksum, though weak, provides a check on the IP addresses and UDP ports (via the pseudoheader check) and MPLS stack from UDP/IP source to UDP/IP destination (and the payload, which is the bit everyone focuses on as the performance hit as redundant and a processing cost when the payload has its own check, and the bit that UDP-Lite can leave out). Nothing else checks that scope. The scope is wider, and affects the network as a whole. Errors in these unchecked fields lead to misdirection and lead to misdelivery. Or pollution of other ports. The MPLS assumption is that it's protected and checked by a strong link CRC like Ethernet, and checked/regenerated by stack processing between hops; here, in a path context, with zero UDP checksums MPLS has no checking at all. "consequences for cheap hardware and for software implementations" I'm sorry, when was MPLS cheap? Lloyd Wood http://about.me/lloydwood ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: 09 January 2014 10:21 To: Wood L Dr (Electronic Eng); randy@psg.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org Subject: RE: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Lloyd and Randy, With respect to draft-ietf-mpls-in-udp, this is why we have IETF last calls, so thanks for the comments. We did take the precaution of sending this I-D for an early TSV Directorate review because of the concern about a number of factors and the overlap with tsvwg work, but the review came back "clean". Of course, such a review is just one person, so this conversation is good. Wrt zero checksum, where do you stand on nested checksums? There is some claim that they represent a waste of processing. I am not convinced by that when each layer is using dedicated hardware (that can presumably process checksums at line speed), but I am interested in the consequences for cheap hardware and for software implementations (as have been claimed to be some of the motivations for this work). Other TSV-related issues that surely pop up are: - allocation of ports for foo-in-UDP - congestion control Please note that there are a number of I-Ds that you missed in your broad sweep of "I am opposed". You should probably look at the NVGRE and VXLAN work (which I think is lurking around the NVO3 working group) because that is also looking at UDP encaps of a tunnelling protocol. Thanks, Adrian Health warnings: I am responsible AD for draft-ietf-mpls-in-udp I am a co-author of the gre-in-udp draft. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk > Sent: 09 January 2014 08:07 > To: randy@psg.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; > tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: > [tsvwg] Milestones changed for tsvwg WG) > > Randy, > > okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get > consensus on it. And then the authors can adopt that consensus for mpls-in-udp, > which overlaps in authorship... > > thanks, > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Randy Bush [randy@psg.com] > Sent: 09 January 2014 07:51 > To: Wood L Dr (Electronic Eng) > Cc: david.black@emc.com; gorry@erg.abdn.ac.uk; ietf@ietf.org; mpls@ietf.org; > jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org > Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] > Milestones changed for tsvwg WG) > > > Because they specify zero UDP checksums, > > I oppose publication of draft-ietf-mpls-in-udp in its current form > > I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its current > form. > > I oppose the IETF lisp documents. > > lloyd, > > i think i understand your position. but i disagree with preventing wg > adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly > see wg adoption as how we get to discuss and work on a document, not as > approval of the document. as david said, i think we need to discuss it > so we can decide if it should be fixed. to do so, we have to adopt it. > > randy > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls
- [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp … l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Randy Bush
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Adrian Farrel
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Stewart Bryant
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Stewart Bryant
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Mark Tinka
- [mpls] misdelivered mpls packets - Was: Re: draft… Loa Andersson
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Gregory Mirsky
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Huub van Helvoort
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Andrew G. Malis
- Re: [mpls] misdelivered mpls packets - Was: Re: d… David Allan I
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Curtis Villamizar
- Re: [mpls] misdelivered mpls packets - Was: Re: d… l.wood
- [mpls] OT was Re: draft-ietf-mpls-in-udp was RE: … Curtis Villamizar
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Curtis Villamizar
- Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was … Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … l.wood
- Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was… l.wood
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Wesley Eddy
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … Dino Farinacci
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … gorry
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was … Curtis Villamizar
- Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was … Mark Tinka
- [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE:… Curtis Villamizar
- Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… l.wood
- Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… l.wood
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Randy Bush
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Alexander Vainshtein
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… l.wood
- Re: [mpls] mpls-in-udp entropy Eric Rosen
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… gorry
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein
- Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp … Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Curtis Villamizar
- Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp … Saku Ytti
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein
- Re: [mpls] mpls-in-udp entropy Curtis Villamizar
- Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp … Saku Ytti
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein