From l.wood@surrey.ac.uk Wed Jan 8 12:59:13 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E4B1AE19F; Wed, 8 Jan 2014 12:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DfNcPG_8kwJ3; Wed, 8 Jan 2014 12:59:11 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.115]) by ietfa.amsl.com (Postfix) with ESMTP id 603861AE100; Wed, 8 Jan 2014 12:59:10 -0800 (PST) Received: from [193.109.255.147:15484] by server-11.bemta-14.messagelabs.com id A6/64-20576-41CBDC25; Wed, 08 Jan 2014 20:59:00 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-72.messagelabs.com!1389214739!13084435!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5931 invoked from network); 8 Jan 2014 20:59:00 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-15.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 8 Jan 2014 20:59:00 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Wed, 8 Jan 2014 20:58:03 +0000 From: To: Date: Wed, 8 Jan 2014 20:58:01 +0000 Thread-Topic: [tsvwg] Milestones changed for tsvwg WG Thread-Index: Ac8McOrPAmy3B+wRTqai/gWVt+nHRAAPUE6Y Message-ID: <290E20B455C66743BE178C5C84F1240847E63346AC@EXMB01CMS.surrey.ac.uk> References: <20140107202040.22438.54920.idtracker@ietfa.amsl.com> <290E20B455C66743BE178C5C84F1240847E63346AB@EXMB01CMS.surrey.ac.uk>, <9e9147aa7183c016db4888691f1ef46d.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <9e9147aa7183c016db4888691f1ef46d.squirrel@www.erg.abdn.ac.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: lisp@ietf.org, jnc@mit.edu, tsvwg@ietf.org, ietf@ietf.org Subject: Re: [lisp] [tsvwg] Milestones changed for tsvwg WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:59:13 -0000 Zero UDP checksums are being selected for convenience, without an appreciat= ion of the overall effects and costs on other traffic. I see this is occurring= in both tsvwg and lisp, and it's probably happening elsewhere: >From the recently adopted by tsvwg draft: http://tools.ietf.org/html/draft-yong-tsvwg-gre-in-udp-encap-02 To simplify packet processing at the tunnel egress, packets destined to this assigned UDP destination port [TBD] SHOULD have their UDP checksum and Sequence flags set to zero because the egress tunnel only needs to identify this protocol. Although IPv6 [RFC2460] restricts the processing a packet with the UDP checksum of zero, [RFC6935] and [RFC6936] relax this constraint to allow the zero UDP checksum. from http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 The UDP checksum is zero because the inner packet usually already has a end-end checksum, and the outer checksum adds no value. [Saltzer] (That's a misreading of Saltzer - the UDP checksum is also protecting again= st misdelivery and pseudoheader corruption, and 'usually' is not a good defenc= e. For shame, Noel.) After all, the best examples of end2end systems failure are with zero check= sums at the endhosts. The TCP and UDP checksums catch significant numbers of errors, e.g. Stone's work: http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf and some of those errors will appear in the headers, where they will send the data to other ports and destinations. The potential for polluting other ports and applications because there is no pseudoheader demultiplexing sanity check is there. IPv6 leaving this check implemented on a per-transport basis has opened th= e door, and rewriting that section of RFC2460 in RFC6935 has taken the door off its= hinges. These RFCs break the minimal multiplexing pseudoheader sanity check that RF= C2460 offered; IPv6 is a mess in so many ways, but making it worse?=20 I think publishing RFC6935 and 6936 and letting in zero checksums again to = IPv6 was a mistake, frankly. (alas, I wasn't paying much attention at the time -= moving countries etc.) A strong recommendation that UDP-Lite covering headers offers minimal compu= tation overhead on tunnelled packets while protecting against polluting other port= s is one solution, while acknowledging deployment limitations. Section 2.4 of RFC696= is mostly there. But zero UDP checksums should always come with copious warnings on the effe= cts not on the carried traffic, which can have its own payload checks, but on traffic shar= ing the network with traffic delivered with zero UDP checksums. Drafts relying on zero checksums should be discouraged, not adopted by workgroups. It's a tragedy of the commons, but the I'm-alright-Jack engineers who want= =20 zero udp checksums for their traffic, and do protect against the effects of= zero checksums on their own payloads, won't care about effects on other traffic. Hey, maybe this should be treated as an attack, which falls under perpass? = That should get it attention... tsvwg needs to give (or get) some careful input on the implications here. Lloyd Wood http://about.me/lloydwood ________________________________________ From: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk] Sent: 08 January 2014 12:55 To: Wood L Dr (Electronic Eng) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Milestones changed for tsvwg WG Lloyd, Here is a little context... which could help. The IETF agreed to update the UDP checksum behaviour for IPv6 in RFC 6935, but only subject to the applicability specified in RFC 6936. One of the reasons why a simple encapsulation like this needs to be done in tsvwg is to minimise the end-to-end implications on other traffic. Sure, using a zero checksum has such implications, and my own first concern is that the new GRE-in-UDP work follows the applicability statement in RFC 6936. To me, it seems the authors are heading this way - but maybe more help is needed. It would be no bad thing to highlight the implications of using zero checksums on other traffic. Gorry > Am I the only one who finds putting zero checksums in proposed standards > to be a worrying > trend? > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: tsvwg [tsvwg-bounces@ietf.org] On Behalf Of IETF Secretariat > [ietf-secretariat-reply@ietf.org] > Sent: 07 January 2014 20:20 > To: tsvwg@ietf.org > Subject: [tsvwg] Milestones changed for tsvwg WG > > Added milestone "Submit 'Specification of GRE in UDP encapsulation' to > IESG as a PS RFC", due December 2014. > > URL: http://datatracker.ietf.org/wg/tsvwg/charter/ > From farinacci@gmail.com Wed Jan 8 13:51:18 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916251ACC84; Wed, 8 Jan 2014 13:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 j98PBs1n47hA; Wed, 8 Jan 2014 13:51:17 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCB01A1F71; Wed, 8 Jan 2014 13:51:17 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id up15so2111744pbc.24 for ; Wed, 08 Jan 2014 13:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6CfPUAZfFn/+/opiIcjKVXjHh8IQgudBOfNV5wM4OiA=; b=nrW/c63QVJBhHBh1qYret4T1rRzu08NCWOPfnLQJQovYfurSMyePbif82szCrr4kaC gHUXtYJRpBtm9sYPNGlYCB6YCvI/BZQkwIvGDuxfYVw55YsRUzaSkHvvmXabEibJi0aB P8ext7dtAYxiCTcR8lc2RQU2qG7ghxQNs7+c0yYQd5C6zbB3iTMDJxBPCSGajlygX7wt z8M5yUEkPWSHjIfQXoNNWoWl3gmwSzztBRfWuxNMujn8gsNRhUfPoVYFDEHpjQ67VY8c i5iSR9fJI4jvxhccos4roYOzhJUdC3ON8ds+O+mfIM3tBrIPQ6uakv95ylcQqLFE+moG RYXA== X-Received: by 10.66.27.42 with SMTP id q10mr12093722pag.65.1389217868320; Wed, 08 Jan 2014 13:51:08 -0800 (PST) Received: from [172.21.60.107] ([167.235.252.130]) by mx.google.com with ESMTPSA id yi10sm6076992pab.8.2014.01.08.13.51.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 13:51:06 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Dino Farinacci In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346AC@EXMB01CMS.surrey.ac.uk> Date: Wed, 8 Jan 2014 13:51:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6F2165C4-3322-416F-913D-1443C4443E81@gmail.com> References: <20140107202040.22438.54920.idtracker@ietfa.amsl.com> <290E20B455C66743BE178C5C84F1240847E63346AB@EXMB01CMS.surrey.ac.uk>, <9e9147aa7183c016db4888691f1ef46d.squirrel@www.erg.abdn.ac.uk> <290E20B455C66743BE178C5C84F1240847E63346AC@EXMB01CMS.surrey.ac.uk> To: l.wood@surrey.ac.uk X-Mailer: Apple Mail (2.1827) Cc: gorry@erg.abdn.ac.uk, ietf@ietf.org, jnc@mit.edu, LISP mailing list list , tsvwg@ietf.org Subject: Re: [lisp] [tsvwg] Milestones changed for tsvwg WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 21:51:18 -0000 > Zero UDP checksums are being selected for convenience, without an = appreciation > of the overall effects and costs on other traffic. I see this is = occurring in both tsvwg > and lisp, and it's probably happening elsewhere: For the LISP working group, or at least for this author, Zero UDP = checksums were selected out of practicality, performance practicality. Dino From jnc@mercury.lcs.mit.edu Wed Jan 8 15:32:47 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58B01ADBCE; Wed, 8 Jan 2014 15:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 A_402t1afOl9; Wed, 8 Jan 2014 15:32:45 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id AA4201ADBCD; Wed, 8 Jan 2014 15:32:45 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1651018C15B; Wed, 8 Jan 2014 18:32:36 -0500 (EST) To: ietf@ietf.org, lisp@ietf.org, tsvwg@ietf.org Message-Id: <20140108233236.1651018C15B@mercury.lcs.mit.edu> Date: Wed, 8 Jan 2014 18:32:36 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [tsvwg] Milestones changed for tsvwg WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 23:32:47 -0000 > From: > from http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 > > The UDP checksum is zero because the inner packet usually already has > a end-end checksum, and the outer checksum adds no value. [Saltzer] > (That's a misreading of Saltzer - the UDP checksum is also protecting > against misdelivery and pseudoheader corruption If the content above the UDP header in this case were that of some sort of application, you'd be right. But it's not. The UDP, outer and inner IP headers of LISP _together_ are effectively a layer three header ('get the packet from the source host to the destination host - and that's all, ffffolks - no reliability of any kind'). So the fact that it's not providing protection against misdelivery is... _exactly_ like the service that bare IPvN provides. In fact, since IPv6 doesn't even _have_ a header checksum, UDP in LISP is doing exactly what IPv6 does. Are you now claiming that IPv6 is fundamentally defective because it doesn't have a header checksum to guard against packet mis-delivery? > and 'usually' is not a good defence To say it at slightly greater length, 'the inner packet _either_ already has an end-end checksum (the usual case), in which case adding another one is of little or no value, _or_ the sender deliverately sent their packet _without_ an end-end checksum, in which case they are _no worse off_ than they were before the packet was encapsulated'. It's not the internetwork layer's job to second-guess the users; we can assume that if someone sent a packet without an end-end checksum, they must have worked out that for whatever they are doing, it's OK to leave it out. Note that I am solely answering regarding the omission of UDP checksums when UDP is used as part of the internetworking layer, for encapsulating traffic. I have not considered, and make no statement about, use of zero checksums in other ways/places. Noel From l.wood@surrey.ac.uk Wed Jan 8 18:35:57 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AC91ADFBB; Wed, 8 Jan 2014 18:35:57 -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 a64W_Uos6myx; Wed, 8 Jan 2014 18:35:54 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) by ietfa.amsl.com (Postfix) with ESMTP id ADBCF1ADFE3; Wed, 8 Jan 2014 18:35:53 -0800 (PST) Received: from [85.158.137.99:37087] by server-4.bemta-3.messagelabs.com id 91/31-10414-FFA0EC25; Thu, 09 Jan 2014 02:35:43 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-217.messagelabs.com!1389234942!20866842!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18408 invoked from network); 9 Jan 2014 02:35:42 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-14.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jan 2014 02:35:42 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Thu, 9 Jan 2014 02:35:41 +0000 From: To: , , , Date: Thu, 9 Jan 2014 02:35:41 +0000 Thread-Topic: [tsvwg] Milestones changed for tsvwg WG Thread-Index: Ac8MyfzxG8ethIThS5asfP1FdUu3hwAFvWo7 Message-ID: <290E20B455C66743BE178C5C84F1240847E63346AD@EXMB01CMS.surrey.ac.uk> References: <20140108233236.1651018C15B@mercury.lcs.mit.edu> In-Reply-To: <20140108233236.1651018C15B@mercury.lcs.mit.edu> 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 Subject: Re: [lisp] [tsvwg] Milestones changed for tsvwg WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 02:35:57 -0000 Noel, I'm claiming that IPv6 has only the pseudoheader checksum to prevent misdel= ivery, as the header checksum was removed from v6 (rather than simply covering non= -mutable fields, and leaving out TTL). When a UDP checksum is set to zero, there is a risk to the payload traffic = carried - which, as you point out, is protected against for the carried traffic if it has it= s own checksum, which is at a higher layer and more end-to-end. However (and this is the subtle point), while the carried traffic is protec= ted against corruption if the packet is delivered to LISP, any IP/UDP header corruption= goes undetected at the endhost because the pseudoheader checksum has been disabl= ed. This does not matter for your application; the header corruption takes the packet to some other destination/port, so you don't see it; it's just a= drop as far as you are concerned. But it matters for whatever actually receives that corrupted packet on e.g. an altered port value. How do they detect and= reject it from their stream? Bare IPv4 has the header checksum, so at least you can tell the endhost is = probably right. But sans UDP checksum, there's no (weak) ports check. IPv6 has no header checksum, so unchecked corruption to header or ports can= take the packet anywhere. > It's not the internetwork layer's job to second-guess the users; we can a= ssume > that if someone sent a packet without an end-end checksum, they must have > worked out that for whatever they are doing, it's OK to leave it out. For what they're doing, but not for what everyone else is doing. Sure, LISP= or tunnels are fine, but odd behaviour on other applications at the same endpo= ints (or, with IPv6, in the same network) caused by missent packets with corrupt= ed UDP packets? Hey, not your problem. Hey, you're working just fine. It's pollution and tragedy of the commons, basically. When you send with a zero UDP checksum, it's possible for the packet to be received and processed anywhere. Secondguessing users who don't understand the problems they create IS the internetwork layer's job. Lloyd Wood http://about.me/lloydwood ________________________________________ From: ietf [ietf-bounces@ietf.org] On Behalf Of Noel Chiappa [jnc@mercury.l= cs.mit.edu] Sent: 08 January 2014 23:32 To: ietf@ietf.org; lisp@ietf.org; tsvwg@ietf.org Cc: jnc@mercury.lcs.mit.edu Subject: RE: [tsvwg] Milestones changed for tsvwg WG > From: > from http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 > > The UDP checksum is zero because the inner packet usually already h= as > a end-end checksum, and the outer checksum adds no value. [Saltzer= ] > (That's a misreading of Saltzer - the UDP checksum is also protecting > against misdelivery and pseudoheader corruption If the content above the UDP header in this case were that of some sort of application, you'd be right. But it's not. The UDP, outer and inner IP headers of LISP _together_ are effectively a layer three header ('get the packet from the source host to the destination host - and that's all, ffffolks - no reliability of any kind'). So the fact that it's not providing protection against misdelivery is... _exactly_ like the service that bare IPvN provides. In fact, since IPv6 doesn't even _have_ a header checksum, UDP in LISP is doing exactly what IPv6 does. Are you now claiming that IPv6 is fundamental= ly defective because it doesn't have a header checksum to guard against packet mis-delivery? > and 'usually' is not a good defence To say it at slightly greater length, 'the inner packet _either_ already ha= s an end-end checksum (the usual case), in which case adding another one is o= f little or no value, _or_ the sender deliverately sent their packet _without= _ an end-end checksum, in which case they are _no worse off_ than they were before the packet was encapsulated'. It's not the internetwork layer's job to second-guess the users; we can ass= ume that if someone sent a packet without an end-end checksum, they must have worked out that for whatever they are doing, it's OK to leave it out. Note that I am solely answering regarding the omission of UDP checksums whe= n UDP is used as part of the internetworking layer, for encapsulating traffic= . I have not considered, and make no statement about, use of zero checksums in other ways/places. Noel From jmh@joelhalpern.com Wed Jan 8 18:47:36 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309241AE032; Wed, 8 Jan 2014 18:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 dvCP_TO1Ywd5; Wed, 8 Jan 2014 18:47:34 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD581AE02D; Wed, 8 Jan 2014 18:47:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 346FA1D4E59; Wed, 8 Jan 2014 18:47:25 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-71.clppva.east.verizon.net [70.106.134.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8ED6E1C5CC1; Wed, 8 Jan 2014 18:47:23 -0800 (PST) Message-ID: <52CE0DB9.50408@joelhalpern.com> Date: Wed, 08 Jan 2014 21:47:21 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, jnc@mercury.lcs.mit.edu, ietf@ietf.org, lisp@ietf.org, tsvwg@ietf.org References: <20140108233236.1651018C15B@mercury.lcs.mit.edu> <290E20B455C66743BE178C5C84F1240847E63346AD@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346AD@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] [tsvwg] Milestones changed for tsvwg WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 02:47:36 -0000 Rather than repeat the arguments, might I ask that you read RFCs 6935 and 6936, which represent the IETFs conclusion about this topic? The LISP work complies with the requirements of those RFCs. Yours, Joel On 1/8/14 9:35 PM, l.wood@surrey.ac.uk wrote: > Noel, > > I'm claiming that IPv6 has only the pseudoheader checksum to prevent misdelivery, > as the header checksum was removed from v6 (rather than simply covering non-mutable fields, > and leaving out TTL). > > When a UDP checksum is set to zero, there is a risk to the payload traffic carried - which, > as you point out, is protected against for the carried traffic if it has its own checksum, > which is at a higher layer and more end-to-end. > > However (and this is the subtle point), while the carried traffic is protected against > corruption if the packet is delivered to LISP, any IP/UDP header corruption goes > undetected at the endhost because the pseudoheader checksum has been disabled. > This does not matter for your application; the header corruption takes > the packet to some other destination/port, so you don't see it; it's just a drop as > far as you are concerned. But it matters for whatever actually receives > that corrupted packet on e.g. an altered port value. How do they detect and reject it > from their stream? > > Bare IPv4 has the header checksum, so at least you can tell the endhost is probably > right. But sans UDP checksum, there's no (weak) ports check. > IPv6 has no header checksum, so unchecked corruption to header or ports can take > the packet anywhere. > >> It's not the internetwork layer's job to second-guess the users; we can assume >> that if someone sent a packet without an end-end checksum, they must have >> worked out that for whatever they are doing, it's OK to leave it out. > > For what they're doing, but not for what everyone else is doing. Sure, LISP or > tunnels are fine, but odd behaviour on other applications at the same endpoints > (or, with IPv6, in the same network) caused by missent packets with corrupted UDP > packets? Hey, not your problem. Hey, you're working just fine. > > It's pollution and tragedy of the commons, basically. > > When you send with a zero UDP checksum, it's possible for the packet to be > received and processed anywhere. > > Secondguessing users who don't understand the problems they create IS > the internetwork layer's job. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: ietf [ietf-bounces@ietf.org] On Behalf Of Noel Chiappa [jnc@mercury.lcs.mit.edu] > Sent: 08 January 2014 23:32 > To: ietf@ietf.org; lisp@ietf.org; tsvwg@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [tsvwg] Milestones changed for tsvwg WG > > > From: > > > from http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 > > > > The UDP checksum is zero because the inner packet usually already has > > a end-end checksum, and the outer checksum adds no value. [Saltzer] > > > (That's a misreading of Saltzer - the UDP checksum is also protecting > > against misdelivery and pseudoheader corruption > > If the content above the UDP header in this case were that of some sort of > application, you'd be right. > > But it's not. > > The UDP, outer and inner IP headers of LISP _together_ are effectively a > layer three header ('get the packet from the source host to the destination > host - and that's all, ffffolks - no reliability of any kind'). So the fact > that it's not providing protection against misdelivery is... _exactly_ like > the service that bare IPvN provides. > > In fact, since IPv6 doesn't even _have_ a header checksum, UDP in LISP is > doing exactly what IPv6 does. Are you now claiming that IPv6 is fundamentally > defective because it doesn't have a header checksum to guard against packet > mis-delivery? > > > and 'usually' is not a good defence > > To say it at slightly greater length, 'the inner packet _either_ already has > an end-end checksum (the usual case), in which case adding another one is of > little or no value, _or_ the sender deliverately sent their packet _without_ > an end-end checksum, in which case they are _no worse off_ than they were > before the packet was encapsulated'. > > It's not the internetwork layer's job to second-guess the users; we can assume > that if someone sent a packet without an end-end checksum, they must have > worked out that for whatever they are doing, it's OK to leave it out. > > > Note that I am solely answering regarding the omission of UDP checksums when > UDP is used as part of the internetworking layer, for encapsulating traffic. > I have not considered, and make no statement about, use of zero checksums > in other ways/places. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From l.wood@surrey.ac.uk Wed Jan 8 18:54:05 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113901ADFB8; Wed, 8 Jan 2014 18:54:05 -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 OtXIixq79gKm; Wed, 8 Jan 2014 18:54:02 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) by ietfa.amsl.com (Postfix) with ESMTP id 72B961ADF9B; Wed, 8 Jan 2014 18:54:01 -0800 (PST) Received: from [195.245.231.67:2938] by server-13.bemta-5.messagelabs.com id D3/2F-11357-F3F0EC25; Thu, 09 Jan 2014 02:53:51 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-7.tower-82.messagelabs.com!1389236031!27740369!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29235 invoked from network); 9 Jan 2014 02:53:51 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-7.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jan 2014 02:53:51 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Thu, 9 Jan 2014 02:53:50 +0000 From: To: , , , , Date: Thu, 9 Jan 2014 02:50:12 +0000 Thread-Topic: [lisp] [tsvwg] Milestones changed for tsvwg WG Thread-Index: Ac8M5SfFwysDKxJjT0ik/TWXtnegxAAAFyaP Message-ID: <290E20B455C66743BE178C5C84F1240847E63346AF@EXMB01CMS.surrey.ac.uk> References: <20140108233236.1651018C15B@mercury.lcs.mit.edu> <290E20B455C66743BE178C5C84F1240847E63346AD@EXMB01CMS.surrey.ac.uk>, <52CE0DB9.50408@joelhalpern.com> In-Reply-To: <52CE0DB9.50408@joelhalpern.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 Subject: Re: [lisp] [tsvwg] Milestones changed for tsvwg WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 02:54:05 -0000 Joel, I'd already read them, I explicitly referenced them in my mail that prompte= d Noel's reply (text not included below, I see - copy at http://www.ietf.org/mail-archive/web/ietf/current/msg85351.html ) and I have explained where those RFCs have gone wrong. Those proposed standards are written from the perspective of the tunnel use= r, not the rest of the network. Tunnel user is fine and unaffected, rest of the network bears the pollution= costs. regards Lloyd Wood http://about.me/lloydwood ________________________________________ From: Joel M. Halpern [jmh@joelhalpern.com] Sent: 09 January 2014 02:47 To: Wood L Dr (Electronic Eng); jnc@mercury.lcs.mit.edu; ietf@ietf.org; li= sp@ietf.org; tsvwg@ietf.org Subject: Re: [lisp] [tsvwg] Milestones changed for tsvwg WG Rather than repeat the arguments, might I ask that you read RFCs 6935 and 6936, which represent the IETFs conclusion about this topic? The LISP work complies with the requirements of those RFCs. Yours, Joel On 1/8/14 9:35 PM, l.wood@surrey.ac.uk wrote: > Noel, > > I'm claiming that IPv6 has only the pseudoheader checksum to prevent misd= elivery, > as the header checksum was removed from v6 (rather than simply covering n= on-mutable fields, > and leaving out TTL). > > When a UDP checksum is set to zero, there is a risk to the payload traffi= c carried - which, > as you point out, is protected against for the carried traffic if it has = its own checksum, > which is at a higher layer and more end-to-end. > > However (and this is the subtle point), while the carried traffic is prot= ected against > corruption if the packet is delivered to LISP, any IP/UDP header corrupti= on goes > undetected at the endhost because the pseudoheader checksum has been disa= bled. > This does not matter for your application; the header corruption takes > the packet to some other destination/port, so you don't see it; it's just= a drop as > far as you are concerned. But it matters for whatever actually receives > that corrupted packet on e.g. an altered port value. How do they detect a= nd reject it > from their stream? > > Bare IPv4 has the header checksum, so at least you can tell the endhost i= s probably > right. But sans UDP checksum, there's no (weak) ports check. > IPv6 has no header checksum, so unchecked corruption to header or ports c= an take > the packet anywhere. > >> It's not the internetwork layer's job to second-guess the users; we can = assume >> that if someone sent a packet without an end-end checksum, they must hav= e >> worked out that for whatever they are doing, it's OK to leave it out. > > For what they're doing, but not for what everyone else is doing. Sure, LI= SP or > tunnels are fine, but odd behaviour on other applications at the same end= points > (or, with IPv6, in the same network) caused by missent packets with corru= pted UDP > packets? Hey, not your problem. Hey, you're working just fine. > > It's pollution and tragedy of the commons, basically. > > When you send with a zero UDP checksum, it's possible for the packet to b= e > received and processed anywhere. > > Secondguessing users who don't understand the problems they create IS > the internetwork layer's job. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: ietf [ietf-bounces@ietf.org] On Behalf Of Noel Chiappa [jnc@mercury= .lcs.mit.edu] > Sent: 08 January 2014 23:32 > To: ietf@ietf.org; lisp@ietf.org; tsvwg@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [tsvwg] Milestones changed for tsvwg WG > > > From: > > > from http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 > > > > The UDP checksum is zero because the inner packet usually alread= y has > > a end-end checksum, and the outer checksum adds no value. [Salt= zer] > > > (That's a misreading of Saltzer - the UDP checksum is also protect= ing > > against misdelivery and pseudoheader corruption > > If the content above the UDP header in this case were that of some sort o= f > application, you'd be right. > > But it's not. > > The UDP, outer and inner IP headers of LISP _together_ are effectively a > layer three header ('get the packet from the source host to the destinati= on > host - and that's all, ffffolks - no reliability of any kind'). So the fa= ct > that it's not providing protection against misdelivery is... _exactly_ li= ke > the service that bare IPvN provides. > > In fact, since IPv6 doesn't even _have_ a header checksum, UDP in LISP is > doing exactly what IPv6 does. Are you now claiming that IPv6 is fundament= ally > defective because it doesn't have a header checksum to guard against pack= et > mis-delivery? > > > and 'usually' is not a good defence > > To say it at slightly greater length, 'the inner packet _either_ already = has > an end-end checksum (the usual case), in which case adding another one is= of > little or no value, _or_ the sender deliverately sent their packet _witho= ut_ > an end-end checksum, in which case they are _no worse off_ than they were > before the packet was encapsulated'. > > It's not the internetwork layer's job to second-guess the users; we can a= ssume > that if someone sent a packet without an end-end checksum, they must have > worked out that for whatever they are doing, it's OK to leave it out. > > > Note that I am solely answering regarding the omission of UDP checksums w= hen > UDP is used as part of the internetworking layer, for encapsulating traff= ic. > I have not considered, and make no statement about, use of zero checksums > in other ways/places. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From l.wood@surrey.ac.uk Wed Jan 8 19:00:00 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0EA1AE094 for ; Wed, 8 Jan 2014 19:00:00 -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 nnna0nZwhyZy for ; Wed, 8 Jan 2014 18:59:58 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) by ietfa.amsl.com (Postfix) with ESMTP id 89C201AE08C for ; Wed, 8 Jan 2014 18:59:57 -0800 (PST) Received: from [195.245.231.67:5848] by server-6.bemta-5.messagelabs.com id 0C/C9-16310-3A01EC25; Thu, 09 Jan 2014 02:59:47 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-82.messagelabs.com!1389236387!35269059!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27475 invoked from network); 9 Jan 2014 02:59:47 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-12.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jan 2014 02:59:47 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Thu, 9 Jan 2014 02:59:29 +0000 From: To: , Date: Thu, 9 Jan 2014 02:59:28 +0000 Thread-Topic: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Thread-Index: AQHPDObQGmJ4SKwhQk6QfMrFWtjgXA== Message-ID: <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.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: ietf@ietf.org, mpls@ietf.org, jnc@mit.edu, lisp@ietf.org, tsvwg@ietf.org Subject: [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 03:00:00 -0000 Thanks, David. Apart from the pollute-other-ports aspect that I've discussed in other mails, MPLS itself is not self-checking (GRE is for header and payload - if its optional checksum is used.) Without checking, corrupt the MPLS label, send it to another tunnel. Without checking, corrupt the UDP port, send the packet elsewhere and pollute another port and stream. I see L. Yong and X. Xu, who are coauthors of=20 draft-yong-tsvwg-gre-in-udp-encap, are also authors of draft-ietf-mpls-in-udp which again plays fast and loose with UDP checksums. This is clearly a widespread problem, and the reliability of the internet i= s being undermined. We can class UDP zero checksum use as an attacks on other streams and services, if that helps. Reliability is an unfashionable topic, but an atta= ck? That must be mitigated immediately. Because they specify zero UDP checksums,=20 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. regards Lloyd Wood http://about.me/lloydwood ________________________________________ From: Black, David [david.black@emc.com] Sent: 08 January 2014 23:20 To: Wood L Dr (Electronic Eng); gorry@erg.abdn.ac.uk Cc: lisp@ietf.org; jnc@mit.edu; tsvwg@ietf.org; ietf@ietf.org Subject: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG= ) Lloyd, This is only at the draft adoption stage - the tsvwg WG gets to take a hard look at the zero checksum conditions in the gre-in-udp-encap draft and make sure that they're right (the WG could even remove the support for zero checksums) - that's among the good reasons for adopting the draft in tsvwg as opposed to elsewhere. Speaking of elsewhere, draft-ietf-mpls-in-udp is in IETF Last Call and has language allowing zero UDP checksums - I might suggest that you (and anyone else who cares about this topic) go read that draft and consider whether making Last Call comments would be appropriate. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of l.wood@surrey.ac= .uk > Sent: Wednesday, January 08, 2014 3:58 PM > To: gorry@erg.abdn.ac.uk > Cc: lisp@ietf.org; jnc@mit.edu; tsvwg@ietf.org; ietf@ietf.org > Subject: Re: [tsvwg] Milestones changed for tsvwg WG > > Zero UDP checksums are being selected for convenience, without an appreci= ation > of the overall effects and costs on other traffic. I see this is occurri= ng in > both tsvwg > and lisp, and it's probably happening elsewhere: > > From the recently adopted by tsvwg draft: > http://tools.ietf.org/html/draft-yong-tsvwg-gre-in-udp-encap-02 > To simplify packet processing at the tunnel egress, packets destined > to this assigned UDP destination port [TBD] SHOULD have their UDP > checksum and Sequence flags set to zero because the egress tunnel > only needs to identify this protocol. Although IPv6 [RFC2460] > restricts the processing a packet with the UDP checksum of zero, > [RFC6935] and [RFC6936] relax this constraint to allow the zero UDP > checksum. > > from http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 > The UDP checksum is zero because the inner packet usually already has > a end-end checksum, and the outer checksum adds no value. [Saltzer] > > (That's a misreading of Saltzer - the UDP checksum is also protecting aga= inst > misdelivery and pseudoheader corruption, and 'usually' is not a good defe= nce. > For shame, Noel.) > > After all, the best examples of end2end systems failure are with zero > checksums > at the endhosts. > > The TCP and UDP checksums catch significant numbers of errors, e.g. Stone= 's > work: > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pd= f > and some of those errors will appear in the headers, where they will send > the data to other ports and destinations. > > The potential for polluting other ports and applications because > there is no pseudoheader demultiplexing sanity check is there. > > IPv6 leaving this check implemented on a per-transport basis has opened = the > door, > and rewriting that section of RFC2460 in RFC6935 has taken the door off i= ts > hinges. > These RFCs break the minimal multiplexing pseudoheader sanity check that > RFC2460 > offered; IPv6 is a mess in so many ways, but making it worse? > > I think publishing RFC6935 and 6936 and letting in zero checksums again t= o > IPv6 > was a mistake, frankly. (alas, I wasn't paying much attention at the time= - > moving countries etc.) > > A strong recommendation that UDP-Lite covering headers offers minimal > computation > overhead on tunnelled packets while protecting against polluting other po= rts > is one > solution, while acknowledging deployment limitations. Section 2.4 of RFC6= 96 is > mostly there. > But zero UDP checksums should always come with copious warnings on the ef= fects > not on the > carried traffic, which can have its own payload checks, but on traffic sh= aring > the network > with traffic delivered with zero UDP checksums. Drafts relying on zero > checksums should be discouraged, not adopted by workgroups. > > It's a tragedy of the commons, but the I'm-alright-Jack engineers who wan= t > zero udp checksums for their traffic, and do protect against the effects = of > zero > checksums on their own payloads, won't care about effects on other traffi= c. > Hey, maybe this should be treated as an attack, which falls under perpass= ? > That > should get it attention... > > tsvwg needs to give (or get) some careful input on the implications here. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk] > Sent: 08 January 2014 12:55 > To: Wood L Dr (Electronic Eng) > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] Milestones changed for tsvwg WG > > Lloyd, > > Here is a little context... which could help. The IETF agreed to update > the UDP checksum behaviour for IPv6 in RFC 6935, but only subject to the > applicability specified in RFC 6936. > > One of the reasons why a simple encapsulation like this needs to be done > in tsvwg is to minimise the end-to-end implications on other traffic. > Sure, using a zero checksum has such implications, and my own first > concern is that the new GRE-in-UDP work follows the applicability > statement in RFC 6936. To me, it seems the authors are heading this way - > but maybe more help is needed. It would be no bad thing to highlight the > implications of using zero checksums on other traffic. > > Gorry > > > Am I the only one who finds putting zero checksums in proposed standard= s > > to be a worrying > > trend? > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: tsvwg [tsvwg-bounces@ietf.org] On Behalf Of IETF Secretariat > > [ietf-secretariat-reply@ietf.org] > > Sent: 07 January 2014 20:20 > > To: tsvwg@ietf.org > > Subject: [tsvwg] Milestones changed for tsvwg WG > > > > Added milestone "Submit 'Specification of GRE in UDP encapsulation' to > > IESG as a PS RFC", due December 2014. > > > > URL: http://datatracker.ietf.org/wg/tsvwg/charter/ > > > > From l.wood@surrey.ac.uk Thu Jan 9 00:09:16 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52A71AE06F; Thu, 9 Jan 2014 00:09:15 -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 gG1Cmobgtscu; Thu, 9 Jan 2014 00:09:13 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) by ietfa.amsl.com (Postfix) with ESMTP id CCA661AE06D; Thu, 9 Jan 2014 00:09:12 -0800 (PST) Received: from [195.245.230.131:54618] by server-16.bemta-3.messagelabs.com id 39/23-26128-E195EC25; Thu, 09 Jan 2014 08:09:02 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-78.messagelabs.com!1389254942!29878430!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31345 invoked from network); 9 Jan 2014 08:09:02 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-15.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jan 2014 08:09:02 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Thu, 9 Jan 2014 08:09:01 +0000 From: To: Date: Thu, 9 Jan 2014 08:06:57 +0000 Thread-Topic: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Thread-Index: Ac8ND6LbmabIHemQQc6QHOWUwU/54gAAiHqr Message-ID: <290E20B455C66743BE178C5C84F1240847E63346B5@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk>, In-Reply-To: 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, ietf@ietf.org, david.black@emc.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 08:09:16 -0000 Randy, okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get con= sensus on it. And then the authors can adopt that consensus for mpls-in-ud= p, 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: [tsv= wg] 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 curre= nt 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 From adrian@olddog.co.uk Thu Jan 9 02:22:07 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C701AE1AE; Thu, 9 Jan 2014 02:22:07 -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] 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 PVl5ZX95-Aw7; Thu, 9 Jan 2014 02:22:04 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3AF1AE23A; Thu, 9 Jan 2014 02:22:04 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09ALoZl029262; Thu, 9 Jan 2014 10:21:50 GMT Received: from 950129200 (15.21.90.92.rev.sfr.net [92.90.21.15]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09ALjKd029119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 10:21:48 GMT From: "Adrian Farrel" To: , References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F1240847E63346B5@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346B5@EXMB01CMS.surrey.ac.uk> Date: Thu, 9 Jan 2014 10:21:44 -0000 Message-ID: <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLp3cWoqiSzZKGjmFXJEPC82F9z6gH14gYaAYJCBgICOkjTg5gY93Xw Content-Language: en-gb 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: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:22:07 -0000 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 From stbryant@cisco.com Thu Jan 9 02:59:23 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598A31AE135; Thu, 9 Jan 2014 02:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ZAx0xcNlXw_k; Thu, 9 Jan 2014 02:59:21 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 81E0A1AE215; Thu, 9 Jan 2014 02:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=399; q=dns/txt; s=iport; t=1389265152; x=1390474752; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Qbe2VRt6TGgmdKkwK0vrwchK/iSeGfGGNd3cr1ckZPM=; b=EO/vraLAtH2nDac172HbQ2TDFlN02f4DmnCrHJqkVioUI1jQsn84Vnk1 fK/OaPU/lMpgniKE//8hSFdp+pOXCUXQlWRxN6lBmilOL50soeCMsXGVo fYQJuSyS65zUyPh569yL7IjwaRZYktZDplPX7s6H7jmeUFcuwWe9aMH2Q w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHWAzlKQ/khL/2dsb2JhbABZDoJ9ulOBEBZ0giUBAQEEOEABEAsYCRYECwkDAgECAUUHDAEFAgEBiADFEBePBQeENwEDmBeSFYFvfz8 X-IronPort-AV: E=Sophos;i="4.95,630,1384300800"; d="scan'208";a="3380445" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 09 Jan 2014 10:59:10 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s09Ax9RB017045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 10:59:10 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s09Ax8Lc029902; Thu, 9 Jan 2014 10:59:08 GMT Message-ID: <52CE80FC.9060306@cisco.com> Date: Thu, 09 Jan 2014 10:59:08 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, david.black@emc.com, gorry@erg.abdn.ac.uk References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, tsvwg@ietf.org, jnc@mit.edu, ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:59:23 -0000 On 09/01/2014 02:59, l.wood@surrey.ac.uk wrote: > MPLS itself is not self-checking (GRE is for header and > payload - if its optional checksum is used.) Without checking, corrupt > the MPLS label, send it to another tunnel. Lloyd I would be interested in what operators are observing in their network, because I have never heard a concern expressed that this was happening. - Stewart From stbryant@cisco.com Thu Jan 9 04:08:58 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7861AE092; Thu, 9 Jan 2014 04:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 1MiTxQP-0ggZ; Thu, 9 Jan 2014 04:08:56 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 855E01ADF52; Thu, 9 Jan 2014 04:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=478; q=dns/txt; s=iport; t=1389269326; x=1390478926; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6TFNL/i3NO0Be9C+OxWBBxbGoqGq75F7IjQQAg9OjH4=; b=Mp8Vka/qzKqcutS+2Pd23V2bUukZ6qLqQR7wJ4qn8m3NglHWIXTtf2va sGOZLT2MpmzfOEG4AwKtdQsiAakKlXRBFSY2z9Ka5+BnQvXAxV2kERbdr UKnHxD2dbmJ6J2LGaMW9NwSrQLWm4qBqK3KPS/STuJflI8UOZNpff82/5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPCQzlKQ/khM/2dsb2JhbABZgwu3S4MIgREWdIIlAQEBBDhAARALGAkWDwkDAgECAUUHDAEHAQGIAMR4F48FB4Q3AQOYF5IVgy0 X-IronPort-AV: E=Sophos;i="4.95,630,1384300800"; d="scan'208";a="3383896" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 09 Jan 2014 12:08:45 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s09C8iYO006013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 12:08:45 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s09C8h6p005115; Thu, 9 Jan 2014 12:08:43 GMT Message-ID: <52CE914B.7070506@cisco.com> Date: Thu, 09 Jan 2014 12:08:43 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mark.tinka@seacom.mu, mpls@ietf.org References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> <52CE80FC.9060306@cisco.com> <201401091303.53239.mark.tinka@seacom.mu> In-Reply-To: <201401091303.53239.mark.tinka@seacom.mu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, ietf@ietf.org, david.black@emc.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 12:08:58 -0000 On 09/01/2014 11:03, Mark Tinka wrote: > On Thursday, January 09, 2014 12:59:08 PM Stewart Bryant > wrote: > >> I would be interested in what operators are observing in >> their network, because I have never heard a concern >> expressed that this was happening. > You mean for native MPLS, or for encapsulated MPLS? > > Mark. Hi Mark, Either or both. I am interested in how often in practice MPLS packets get misdelivered due to label corruption. - Stewart From jnc@mercury.lcs.mit.edu Thu Jan 9 08:16:12 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29621AE045; Thu, 9 Jan 2014 08:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 E1D3k685dDqi; Thu, 9 Jan 2014 08:16:11 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 699851ADF7D; Thu, 9 Jan 2014 08:16:11 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 73C8D18C0BF; Thu, 9 Jan 2014 11:16:01 -0500 (EST) To: ietf@ietf.org Message-Id: <20140109161601.73C8D18C0BF@mercury.lcs.mit.edu> Date: Thu, 9 Jan 2014 11:16:01 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: tsvwg@ietf.org, jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] [tsvwg] Milestones changed for tsvwg WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 16:16:13 -0000 > From: > any IP/UDP header corruption goes undetected at the endhost because the > pseudoheader checksum has been disabled. .. the header corruption takes > the packet to some other destination/port, so you don't see it; it's > just a drop as far as you are concerned. But it matters for whatever > actually receives that corrupted packet on e.g. an altered port value. > ... > odd behaviour on other applications at the same endpoints (or, with > IPv6, in the same network) caused by missent packets with corrupt ed > UDP packets? Hey, not your problem. Hey, you're working just fine. > It's pollution and tragedy of the commons, basically. > When you send with a zero UDP checksum, it's possible for the packet to > be received and processed anywhere. Outlawing use of non-checksummed UDP for tunnels isn't going to _guarantee_ that such packets never show up at a host: malicious or buggy software could also generate them - as could whatever is hypothetically damaging non-checksummed UDP tunnel packets. So hosts have to be able to deal with such packets anyway. The only question left, then, is 'is this happening often enough to present a significant processing load to the innocent bystanders' (which I agree would be problematic). But here I echo Stewart Bryant: what data is there that this is actually happening often enough to be a problem? And along those lines, I'm looking at the 'incoming traffic' light on my cable modem, and it's blinking constantly - port scanners and such, I assume. A few stray tunnel packets would be lost in that flood. Noel From david.black@emc.com Wed Jan 8 15:21:25 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF061AD939; Wed, 8 Jan 2014 15:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 TdoKzYCdpBhx; Wed, 8 Jan 2014 15:21:23 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E62051AD948; Wed, 8 Jan 2014 15:21:21 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s08NL9TS002915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jan 2014 18:21:10 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s08NL9TS002915 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1389223270; bh=OUxIZcRUGquTocbJ0OIOXDvQn5k=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=enVMQYqyAJkvLwHELR9jIkRaA7GAWkd1Ff+wO8FLRisgUshou14CNHU79+He2m/Wa y9ydupMrfmH7RNRGFQ1gaq/OGeU0aloP+dTcmw4QSbsL5qponoChqsxm/fOQMdf02J rUoWK5zPeS6RjPYFfc8Vdjbdx0YNiFavT4EyWu7I= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s08NL9TS002915 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 8 Jan 2014 15:20:55 -0800 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s08NKsDh028930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 18:20:54 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Wed, 8 Jan 2014 18:20:53 -0500 From: "Black, David" To: "l.wood@surrey.ac.uk" , "gorry@erg.abdn.ac.uk" Date: Wed, 8 Jan 2014 18:20:52 -0500 Thread-Topic: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Thread-Index: Ac8MyEHqITdMSvN0R8qKanlihQAy2g== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Thu, 09 Jan 2014 09:56:51 -0800 Cc: "ietf@ietf.org" , "jnc@mit.edu" , "lisp@ietf.org" , "tsvwg@ietf.org" Subject: [lisp] gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 23:21:25 -0000 Lloyd, This is only at the draft adoption stage - the tsvwg WG gets to take a hard look at the zero checksum conditions in the gre-in-udp-encap draft and make sure that they're right (the WG could even remove the support for zero checksums) - that's among the good reasons for adopting the draft in tsvwg as opposed to elsewhere. =20 Speaking of elsewhere, draft-ietf-mpls-in-udp is in IETF Last Call and has language allowing zero UDP checksums - I might suggest that you (and anyone else who cares about this topic) go read that draft and consider whether making Last Call comments would be appropriate. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of l.wood@surrey.ac= .uk > Sent: Wednesday, January 08, 2014 3:58 PM > To: gorry@erg.abdn.ac.uk > Cc: lisp@ietf.org; jnc@mit.edu; tsvwg@ietf.org; ietf@ietf.org > Subject: Re: [tsvwg] Milestones changed for tsvwg WG >=20 > Zero UDP checksums are being selected for convenience, without an appreci= ation > of the overall effects and costs on other traffic. I see this is occurri= ng in > both tsvwg > and lisp, and it's probably happening elsewhere: >=20 > From the recently adopted by tsvwg draft: > http://tools.ietf.org/html/draft-yong-tsvwg-gre-in-udp-encap-02 > To simplify packet processing at the tunnel egress, packets destined > to this assigned UDP destination port [TBD] SHOULD have their UDP > checksum and Sequence flags set to zero because the egress tunnel > only needs to identify this protocol. Although IPv6 [RFC2460] > restricts the processing a packet with the UDP checksum of zero, > [RFC6935] and [RFC6936] relax this constraint to allow the zero UDP > checksum. >=20 > from http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 > The UDP checksum is zero because the inner packet usually already has > a end-end checksum, and the outer checksum adds no value. [Saltzer] >=20 > (That's a misreading of Saltzer - the UDP checksum is also protecting aga= inst > misdelivery and pseudoheader corruption, and 'usually' is not a good defe= nce. > For shame, Noel.) >=20 > After all, the best examples of end2end systems failure are with zero > checksums > at the endhosts. >=20 > The TCP and UDP checksums catch significant numbers of errors, e.g. Stone= 's > work: > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pd= f > and some of those errors will appear in the headers, where they will send > the data to other ports and destinations. >=20 > The potential for polluting other ports and applications because > there is no pseudoheader demultiplexing sanity check is there. >=20 > IPv6 leaving this check implemented on a per-transport basis has opened = the > door, > and rewriting that section of RFC2460 in RFC6935 has taken the door off i= ts > hinges. > These RFCs break the minimal multiplexing pseudoheader sanity check that > RFC2460 > offered; IPv6 is a mess in so many ways, but making it worse? >=20 > I think publishing RFC6935 and 6936 and letting in zero checksums again t= o > IPv6 > was a mistake, frankly. (alas, I wasn't paying much attention at the time= - > moving > countries etc.) >=20 > A strong recommendation that UDP-Lite covering headers offers minimal > computation > overhead on tunnelled packets while protecting against polluting other po= rts > is one > solution, while acknowledging deployment limitations. Section 2.4 of RFC6= 96 is > mostly there. > But zero UDP checksums should always come with copious warnings on the ef= fects > not on the > carried traffic, which can have its own payload checks, but on traffic sh= aring > the network > with traffic delivered with zero UDP checksums. Drafts relying on zero > checksums should be discouraged, not adopted by workgroups. >=20 > It's a tragedy of the commons, but the I'm-alright-Jack engineers who wan= t > zero udp checksums for their traffic, and do protect against the effects = of > zero > checksums on their own payloads, won't care about effects on other traffi= c. > Hey, maybe this should be treated as an attack, which falls under perpass= ? > That > should get it attention... >=20 > tsvwg needs to give (or get) some careful input on the implications here. >=20 > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk] > Sent: 08 January 2014 12:55 > To: Wood L Dr (Electronic Eng) > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] Milestones changed for tsvwg WG >=20 > Lloyd, >=20 > Here is a little context... which could help. The IETF agreed to update > the UDP checksum behaviour for IPv6 in RFC 6935, but only subject to the > applicability specified in RFC 6936. >=20 > One of the reasons why a simple encapsulation like this needs to be done > in tsvwg is to minimise the end-to-end implications on other traffic. > Sure, using a zero checksum has such implications, and my own first > concern is that the new GRE-in-UDP work follows the applicability > statement in RFC 6936. To me, it seems the authors are heading this way - > but maybe more help is needed. It would be no bad thing to highlight the > implications of using zero checksums on other traffic. >=20 > Gorry >=20 > > Am I the only one who finds putting zero checksums in proposed standard= s > > to be a worrying > > trend? > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: tsvwg [tsvwg-bounces@ietf.org] On Behalf Of IETF Secretariat > > [ietf-secretariat-reply@ietf.org] > > Sent: 07 January 2014 20:20 > > To: tsvwg@ietf.org > > Subject: [tsvwg] Milestones changed for tsvwg WG > > > > Added milestone "Submit 'Specification of GRE in UDP encapsulation' to > > IESG as a PS RFC", due December 2014. > > > > URL: http://datatracker.ietf.org/wg/tsvwg/charter/ > > >=20 >=20 From randy@psg.com Wed Jan 8 23:51:55 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB51AE11A; Wed, 8 Jan 2014 23:51:55 -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 oANByb7vVI-F; Wed, 8 Jan 2014 23:51:54 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 154B21AE08E; Wed, 8 Jan 2014 23:51:54 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W1AOt-0007Zj-Ra; Thu, 09 Jan 2014 07:51:36 +0000 Date: Thu, 09 Jan 2014 16:51:33 +0900 Message-ID: From: Randy Bush To: In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Thu_Jan__9_16:51:26_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 Jan 2014 09:56:50 -0800 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: [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 07:51:55 -0000 --pgp-sign-Multipart_Thu_Jan__9_16:51:26_2014-1 Content-Type: text/plain; charset=US-ASCII > 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 --pgp-sign-Multipart_Thu_Jan__9_16:51:26_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJSzlUEAAoJEMzMBey4OgLtpjYH/iM5qSYEPIFoK6ay0D9mYB/t gqH8nCOV6Kw+E9VWgwfPs2fwtuLboUrxn4aJF3M84FCDcg1pFks7d6g2d3EDx5wJ KLcpcq9Kg+hAdU+oWYAkmT+aA3HtEdCysVqMlo15G4Cm46TI2VycKEBAzhCGe1ue C8j66MfVUCIrIqLeZEAb6mzXUsqpzZnNKaGBtatHp/4TGMWGllwCVC/va46IvKWE 6aYtgxWUDO4g07Iu/c7SdJQcQHUh58o785Nyc7jhuEXTV6DTJe6Rtte+aXOr0hmU blDwmEf5ixrkuT4YO+mPoKpgmwMk4VLxcpt22pe29VRmS9DDiVtckX3KXgoPJsc= =IiRO -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Jan__9_16:51:26_2014-1-- From mark.tinka@seacom.mu Thu Jan 9 03:04:33 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AED91AE26D; Thu, 9 Jan 2014 03:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no 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 0OVBMb7fXizw; Thu, 9 Jan 2014 03:04:30 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id DD01E1AE262; Thu, 9 Jan 2014 03:04:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W1DOz-0002Gm-N2; Thu, 09 Jan 2014 13:03:53 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org, stbryant@cisco.com Date: Thu, 9 Jan 2014 13:03:52 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> <52CE80FC.9060306@cisco.com> In-Reply-To: <52CE80FC.9060306@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6950898.q6vmhhEH7r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401091303.53239.mark.tinka@seacom.mu> X-Mailman-Approved-At: Thu, 09 Jan 2014 09:56:50 -0800 Cc: gorry@erg.abdn.ac.uk, lisp@ietf.org, tsvwg@ietf.org, david.black@emc.com, jnc@mit.edu, ietf@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 11:04:34 -0000 --nextPart6950898.q6vmhhEH7r Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, January 09, 2014 12:59:08 PM Stewart Bryant=20 wrote: > I would be interested in what operators are observing in > their network, because I have never heard a concern > expressed that this was happening. You mean for native MPLS, or for encapsulated MPLS? Mark. --nextPart6950898.q6vmhhEH7r Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJSzoIZAAoJEGcZuYTeKm+Gxx8QAImaR5aEcX9avA5B3dKrYbe4 AeGqeUKtVCjkZt9/p91LkMPXcRd9QcQzjfprDRwW0LT6PT9tkFWS/N6dep6ZZQ8x UytAYCUVqEngI3El7p+LvSt97JW+n97/9aFRA6hD65av/PwOG4Y1M97rEP2qsnGu pXG4TrZ+uJ28bjtXwahgHnhjKgF2Wu5rTSrdWpfShRRlYPsrMjFAw2gkOqGqwQGH D1CUFnv8e3V2hj+rS9sWRf+qjGsqm5I273kLn6ryX6XBdjE+qZTDptdIXo43+/2I qJsemitPOydyM4y8qCYL33dyLYUlFTMhW6IOakX4lzNPCPgcoTIqeJvjZHECT1hn IcHZGgMDxVlbQgLIoGqmdHGLN5BQsHUfIWIkZLbn4ftaJ8oqFm8ZhWvGgLgxiZ2I 1p/87+rm9/6hnYPWdZOY2XlZ8yKEQbEQs6zalpvselUq7Ydk20JxtF74v5nuUIfx N+WtjEYqGIhNCbiN68MRxyHWj1Ojlojo0W45raE+Cz5vmkQM6O4vpKUXue0BbLkR 2l3EjbusFbnJMzTR5B2qHFALS+EADIuoSxfdqSfUNQTYR1/K/z/te8g5fQbci6VW WcP28pMwG48YGE8N2pyk/Rsk0wISDgtJ9Vu+mOzsDllAkQmMKRyDUpJKc2VepmhF zgaLCG2+5qg/tLsKEs9G =nW7X -----END PGP SIGNATURE----- --nextPart6950898.q6vmhhEH7r-- From mark.tinka@seacom.mu Thu Jan 9 04:37:35 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C601AE215; Thu, 9 Jan 2014 04:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no 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 udwRene6NZUG; Thu, 9 Jan 2014 04:37:34 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id BD7E31AD8CD; Thu, 9 Jan 2014 04:37:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W1ErA-00037O-Os; Thu, 09 Jan 2014 14:37:04 +0200 From: Mark Tinka Organization: SEACOM To: stbryant@cisco.com Date: Thu, 9 Jan 2014 14:36:56 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> In-Reply-To: <52CE914B.7070506@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2216786.Gj6lG7fHB8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401091437.04245.mark.tinka@seacom.mu> X-Mailman-Approved-At: Thu, 09 Jan 2014 09:56:50 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 12:37:35 -0000 --nextPart2216786.Gj6lG7fHB8 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant=20 wrote: > Either or both. I can only speak to native MPLS, as I've never run tunneled=20 MPLS. > I am interested in how often in practice MPLS packets get > misdelivered due to label corruption. Well, first of all, routers would need to report corrupted=20 MPLS frames so operators can glean this data. This isn't=20 something I've come across, but it would be good to find=20 some kind of way to count this across interfaces, if the=20 routers can detect and report them. The known issue about mis-delivery of MPLS frames is poorly- sized MTU interfaces. I have no empirical data as to how=20 this can corrupt successive MPLS frames that may fit into=20 the transit MTU. But in this case, as with any Layer 2=20 traffic, not enough MTU =3D dropped frame. Mark. --nextPart2216786.Gj6lG7fHB8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJSzpfwAAoJEGcZuYTeKm+G5SAQALfNbYG3PYHbT7QCKV8dprMp ryTPEndCuPuAlpjpfqZDscQSjn0K4F2wIofJN48CBDHC7ivhfBCuQUpNFbP+jYln 04mV9pEhM6urzKZQUgpq/GdMmUVG03loq8TPhZV6gT+3+hO26SnDwl8VzqdafaGi K/e0qSuuwmlVKnN+ywhHTOwd+5r3mJPE6fZpSHByjjRz1EDPIgUptg8Cf5Wcz3uP QlC0DM0drEYwZn+jzOOScv6Zvb+8/Z7e3zdFmLHIWYAi4xM89lWCNShU7bQNDwvp Wc6gIFMaPY0A8Vj2gy1x61jf/PCXk69xSXt7n4tPTn4oRSMSfKFShInklxWmVtsq wmM6D2QieXMB0lRrXzXSSnjJMvsNuhICqNy7FwI9MFfJEXFo/nsc13xZHnHf0VKV tdCnlQheOehwK3qmZyg4OQiBIoQ10MRK4e/qgU9hyXJQrzResVAmf5HpiE1ZFIQH AtQdcfd3PBvxrTO6p8NLRja7hPZ9CLu554Sz6Z2DA12mD/KZAkTbpz5bef4/fTSH IPRz9VBwLeJEJQr1yg4aIK8p46TPNwMKvJjLsowydmb6PUo70JVmYKUPolbCYs8A 9KpuLtPk4miCEbIpRNLYOVFnJGCqnOsH0WmkDJFqCV0G+jESv7hZWnbU4nCnmtnO lwX81Wa/2rU7Z/g6WUnW =MplW -----END PGP SIGNATURE----- --nextPart2216786.Gj6lG7fHB8-- From loa@pi.nu Thu Jan 9 08:17:21 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A941AD68A; Thu, 9 Jan 2014 08:17:21 -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 mjlRICDVIyjD; Thu, 9 Jan 2014 08:17:19 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 104661AE373; Thu, 9 Jan 2014 08:17:19 -0800 (PST) Received: from [192.168.1.5] (unknown [119.95.157.254]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CD075180145E; Thu, 9 Jan 2014 17:17:04 +0100 (CET) Message-ID: <52CECB7B.3090200@pi.nu> Date: Fri, 10 Jan 2014 00:16:59 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mark.tinka@seacom.mu, stbryant@cisco.com References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> <201401091437.04245.mark.tinka@seacom.mu> In-Reply-To: <201401091437.04245.mark.tinka@seacom.mu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 Jan 2014 09:56:51 -0800 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: [lisp] misdelivered mpls packets - Was: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 16:17:21 -0000 Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled > MPLS. > >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted > MPLS frames so operators can glean this data. This isn't > something I've come across, but it would be good to find > some kind of way to count this across interfaces, if the > routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- > sized MTU interfaces. I have no empirical data as to how > this can corrupt successive MPLS frames that may fit into > the transit MTU. But in this case, as with any Layer 2 > traffic, not enough MTU = dropped frame. > > Mark. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From gregory.mirsky@ericsson.com Thu Jan 9 09:30:40 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6752D1AE453; Thu, 9 Jan 2014 09:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 58YQRyTm8sna; Thu, 9 Jan 2014 09:30:38 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 47A731AE3DC; Thu, 9 Jan 2014 09:30:38 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-26-52cedcb16bbb Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E5.D8.23183.1BCDEC25; Thu, 9 Jan 2014 18:30:26 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0347.000; Thu, 9 Jan 2014 12:30:28 -0500 From: Gregory Mirsky To: Loa Andersson , "mark.tinka@seacom.mu" , "stbryant@cisco.com" Thread-Topic: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Thread-Index: AQHPDVZPwlV5fcTOlUKeWNcLbDwLU5p8pA3g Date: Thu, 9 Jan 2014 17:30:27 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B743FDC@eusaamb103.ericsson.se> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> <201401091437.04245.mark.tinka@seacom.mu> <52CECB7B.3090200@pi.nu> In-Reply-To: <52CECB7B.3090200@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLonUHfTnXNBBj928FhsPbyW3eJ122xG i2cb57NYvP23gdViyll1i39z5zBb3Fu7mN3i1tKVrBbnns5htDj25i6bA5fHlN8bWT2OHJnN 4tHz+QWTx5IlP5k8ms4cZfaYNb2NzaPz2kT2APYoLpuU1JzMstQifbsEroyFx8+yFCwUqDix 5jlbA+Mnni5GTg4JAROJhklrmSBsMYkL99azdTFycQgJHGGU2PPhFDOEs4xR4uNOiCo2ASOJ Fxt72EFsEYFKiV/TdoF1MAu0M0lcWrsULCEskCWx/MwUIJsDqChb4uVSf4h6I4knX9sZQWwW ARWJ+5fug9m8Ar4Ssz4cg9p8k1Hi5/x7YHM4BVQlnh2aAGYzAp33/dQasCOYBcQlbj2ZD3W2 gMSSPeeZIWxRiZeP/7FC2MoS3+c8YoGo15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2C8nY WUhaZiFpmYWkZQEjyypGjtLi1LLcdCODTYzASD0mwaa7g3HPS8tDjNIcLErivF/eOgcJCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYLQqtLg5+02N5cIWkw+vvas/s66qeqbzTmWD16e8W89e Nbn9rZit/tq4a7rK3B9xHoGxv1h3TWb8tCJykWN++PVNu623PGY9LRp/cPe+NqaJDw6fK2D7 cv5SgfgG5VeT2xqU22wDJV0T3P+zq+9pnKzD1rxcWVmzNGlzx6kXFzc/+PH1T+lb9yVKLMUZ iYZazEXFiQBNPZh5ogIAAA== X-Mailman-Approved-At: Thu, 09 Jan 2014 09:56:51 -0800 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: [lisp] [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:30:40 -0000 Hi Loa, et al., I think that you're referring to Connectivity Verification in MPLS-TP (RFC = 6428). It would only detect mis-connection but would not count leaked in fr= ames. Such problem may be more apparent in Segment Routing (SPRING WG). Perhaps C= V should be a requirement in SR OAM. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, January 09, 2014 8:17 AM To: mark.tinka@seacom.mu; stbryant@cisco.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: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp= was RE: gre-in-udp draft Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled MPLS. > >> I am interested in how often in practice MPLS packets get=20 >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted MPLS frames=20 > so operators can glean this data. This isn't something I've come=20 > across, but it would be good to find some kind of way to count this=20 > across interfaces, if the routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- sized MTU=20 > interfaces. I have no empirical data as to how this can corrupt=20 > successive MPLS frames that may fit into the transit MTU. But in this=20 > case, as with any Layer 2 traffic, not enough MTU =3D dropped frame. > > Mark. > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From l.wood@surrey.ac.uk Thu Jan 9 20:22:23 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34CB1AE001; Thu, 9 Jan 2014 20:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jxwNkA2w2dQi; Thu, 9 Jan 2014 20:22:20 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.118]) by ietfa.amsl.com (Postfix) with ESMTP id D307E1ADF5C; Thu, 9 Jan 2014 20:22:19 -0800 (PST) Received: from [193.109.255.147:34109] by server-14.bemta-14.messagelabs.com id E5/D4-12628-1757FC25; Fri, 10 Jan 2014 04:22:09 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-8.tower-72.messagelabs.com!1389327728!11897647!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2107 invoked from network); 10 Jan 2014 04:22:09 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-8.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jan 2014 04:22:09 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 10 Jan 2014 04:22:08 +0000 From: To: , Date: Fri, 10 Jan 2014 04:19:24 +0000 Thread-Topic: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Thread-Index: Ac8Nqj4MGzqvYffaRlKHQ/vzzrnSnQAEObyx Message-ID: <290E20B455C66743BE178C5C84F1240847E63346B8@EXMB01CMS.surrey.ac.uk> References: Your message of "Thu, 09 Jan 2014 20:26:27 +0000." , <201401100217.s0A2Hv4I081006@maildrop2.v6ds.occnc.com> In-Reply-To: <201401100217.s0A2Hv4I081006@maildrop2.v6ds.occnc.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, tsvwg@ietf.org, lisp@ietf.org Subject: Re: [lisp] [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 04:22:23 -0000 The origin of this discussion is zero UDP checksums and http://www.ietf.org/mail-archive/web/ietf/current/msg85354.html I suggest reading Jonathan Stone's papers and PhD thesis for a good understanding of where errors can come from. Lloyd Wood http://about.me/lloydwood ________________________________________ From: mpls [mpls-bounces@ietf.org] On Behalf Of Curtis Villamizar [curtis@i= pv6.occnc.com] Sent: 10 January 2014 02:17 To: David Allan I Cc: mpls@ietf.org; tsvwg@ietf.org; lisp@ietf.org; ietf@ietf.org Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-= mpls-in-udp was RE: gre-in-udp draft Since we are all top posting ... For counting dropped packets LM OAM is what you need. CV doesn't do that. Direct LM will give best results on a per LSP basis but requires forwarding chip support to do so. I also don't know the origin of this discussion. >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. Not very often if ever at least for major vendor products. I don't know if second tier or third tier players have bugs. (Very often circa 2000 or earlier particularly with one specific vendor and with one provider who made things much worse by mucking with the ILM through management plane, but that is ancient history). Bit rot in TCAM or SRAM is very rare. Bit rot in circa 1980s DRAM was a problem. Bit rot in modern non-ECC DRAM is rare. Bit rot in modern ECC DRAM is very rare. Therefore to have a bad ILM you need bugs. Curtis In message David Allan I writes: Hi (trimmed received list) I'm not sure what the starting point of this dialog is, but I can at least = say Greg is right on the CV front, it only detects and does not measure mis= direction. The only other possibility to count anything is a "no ILM" condition where = the label value is unrecognized by the receiving LSR, which IMO could not b= e made authoritative if it is label values in either the frame or the NHLFE= and not exclusively next hops that is corrupted. Cheers D -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, January 09, 2014 9:30 AM To: Loa Andersson; mark.tinka@seacom.mu; stbryant@cisco.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; davi= d.black@emc.com; jnc@mit.edu; tsvwg@ietf.org Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in= -udp was RE: gre-in-udp draft Hi Loa, et al., I think that you're referring to Connectivity Verification in MPLS-TP (RFC = 6428). It would only detect mis-connection but would not count leaked in fr= ames. Such problem may be more apparent in Segment Routing (SPRING WG). Perhaps C= V should be a requirement in SR OAM. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, January 09, 2014 8:17 AM To: mark.tinka@seacom.mu; stbryant@cisco.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: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp= was RE: gre-in-udp draft Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled MPLS. > >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted MPLS frames > so operators can glean this data. This isn't something I've come > across, but it would be good to find some kind of way to count this > across interfaces, if the routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- sized MTU > interfaces. I have no empirical data as to how this can corrupt > successive MPLS frames that may fit into the transit MTU. But in this > case, as with any Layer 2 traffic, not enough MTU =3D dropped frame. > > Mark. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Thu Jan 9 09:59:07 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3916B1AE037; Thu, 9 Jan 2014 09:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 i1w5ISvsAUPS; Thu, 9 Jan 2014 09:59:05 -0800 (PST) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7D1ADF8C; Thu, 9 Jan 2014 09:59:04 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id h10so1618109eak.16 for ; Thu, 09 Jan 2014 09:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/vxgliJ4X1BuIFdyXzXCO5LYDKB3JmRy977VfMjxC08=; b=Qvy5cbOwTeQylcAQEAQy1Y9jxlAyMpOL5lHPHMRL5/6PYHD2n9rLnBZXszwVqj3L2n x2Sdv+5vZEhOrVF4F2ZBS8CkAIj1yaikwWLX319/ehTNukfKDlwKBY6hAtr7cmmTp52W oq9IckDe5Wv6OrQ2uquUx0BukzkIWv8qyGu/TpbFefMsUqp23SZMXWvtCKtUPAhgliMY nP+IFp9iNRh4W3N3zW5N+iddX20XQsYVGWH5mJptPp8EHOCJfRO+cM+2cOa3FFRrkAKw FcNXGzHFpS/Vg6D9BzdMiNX69HKBZS5FqN6+m3B0C2Pst1HBpTctxYRpDq7+zd6dH9gj 6r/w== X-Received: by 10.14.5.194 with SMTP id 42mr4690805eel.100.1389290335030; Thu, 09 Jan 2014 09:58:55 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id v1sm7582058eef.9.2014.01.09.09.58.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jan 2014 09:58:54 -0800 (PST) Message-ID: <52CEE358.1050309@gmail.com> Date: Thu, 09 Jan 2014 18:58:48 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gregory Mirsky References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> <201401091437.04245.mark.tinka@seacom.mu> <52CECB7B.3090200@pi.nu> <7347100B5761DC41A166AC17F22DF1121B743FDC@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B743FDC@eusaamb103.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 10 Jan 2014 08:19:54 -0800 Cc: "mpls@ietf.org" , "tsvwg@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" Subject: Re: [lisp] [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:59:07 -0000 Hello Greg, You wrote: > I think that you're referring to Connectivity Verification in > MPLS-TP (RFC 6428). It would only detect mis-connection > but would not count leaked in frames. Indeed. However, there is the Loss Measurement tool which can be used to count dropped and mis-delivered packets. Note that the CV tool in G.8113.1 includes packet loss counting. > Such problem may be more apparent in Segment Routing (SPRING WG). > Perhaps CV should be a requirement in SR OAM. Indeed. Regards, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From mark.tinka@seacom.mu Thu Jan 9 10:48:49 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F401AE525; Thu, 9 Jan 2014 10:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no 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 jXsUnWvkCvLP; Thu, 9 Jan 2014 10:48:47 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 192301AE52B; Thu, 9 Jan 2014 10:48:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W1KeO-0005FL-Qh; Thu, 09 Jan 2014 20:48:16 +0200 From: Mark Tinka Organization: SEACOM To: Loa Andersson Date: Thu, 9 Jan 2014 20:48:15 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091437.04245.mark.tinka@seacom.mu> <52CECB7B.3090200@pi.nu> In-Reply-To: <52CECB7B.3090200@pi.nu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7202981.cQ0BC7dWJg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401092048.16168.mark.tinka@seacom.mu> X-Mailman-Approved-At: Fri, 10 Jan 2014 08:19:52 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, david.black@emc.com, tsvwg@ietf.org, stbryant@cisco.com, jnc@mit.edu, ietf@ietf.org Subject: Re: [lisp] misdelivered mpls packets - Was: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 18:48:49 -0000 --nextPart7202981.cQ0BC7dWJg Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, January 09, 2014 06:16:59 PM Loa Andersson=20 wrote: > This would be possible to do with MPLS-TP OAM, wouldn't > it? Sorry, no experience.=20 I don't personally like MPLS-TP :-), but happy to hear of=20 any experiences from those that do. Mark. --nextPart7202981.cQ0BC7dWJg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJSzu7wAAoJEGcZuYTeKm+GfxkP/ArGFtdiH9YpCn6vMqW+OJ5k mIhR4Hhpu7DUOXHXVwUw1f24fUU/RrMdPvveiLFo6LJmWLo/w8D7fY9IvP+KXlu/ XFSth1OZOKHRQw27LHHm9iZKURnreMitSZnJ+dFyAsZHTOAyPHshBvDY1oYbKvbK qcPASfq+BXrQ2PfAkfWCXWYVHthS47FxFpcTxDOzLffnjhcAgxbb/eR75ieU34TY wa+tGlvgrb4D4THEJ5gHZiOWBR4Mtt/4bsNRAL8FKlX4UtcYYiuF++xYNQhPpQnB 0IJ/OFCWOb4/cB71hpe4STjrE2++CayAXExFM5f6Ypi+woNdynKOq56V36E2gOZe F32sX23IJ8cvU2yEOjYRkLtGnrsYGHlcl9kSh/t1gs5mCxq6yMiJFkwYyzrsv6Nz gTPmE4V16jpBQMb7Ojx3fJ1td0ltOlbJS32ITvbH0AWrlbCeybzn5NjDtNiDtIJO F+s21T3YPyII8xP7CELn5i06HxQKo81BuahYAv9cI8Nom6FsPUEAAMMe9Si43sLg tgbqtrfC2hox9xH83SiN4wboJZs/QeTeaaKSwgRBVtiM+rI1dVZahSBwSTKpCoxH fgG/fU1ssPcPdnuq2C7/UUMB5dYqfAwGugimChhJcnmEAMwYbeyoEu9WNq0cyHCC L43oBc1rSsXS51qjJLZW =aFJ/ -----END PGP SIGNATURE----- --nextPart7202981.cQ0BC7dWJg-- From agmalis@gmail.com Thu Jan 9 12:12:50 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5CF1AE049; Thu, 9 Jan 2014 12:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 DqN6D8ojfnmc; Thu, 9 Jan 2014 12:12:47 -0800 (PST) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D37071AE10B; Thu, 9 Jan 2014 12:12:46 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so808264qaq.15 for ; Thu, 09 Jan 2014 12:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LX/HdHP0vU4UfmPFt9sL8qmvL7+dWijc3NcyMBigIq0=; b=GJkU5aztNSdOByof9ww/pNN0+ndJZVX2SbcKG2xcqv/mRlQswQaYiehnqeW8bZ6IxB Dhj2dJ59Ut7RXDW5pw2+4YoYjLPivWqCV3EPwBQlpK22wiD8J2l9RQ4MPd1PbwTm4z+Y exALqeeveVSTv5Ad1u0r51Aud3+tzRK1y8nzwFtyL+MHTEkXJQQ+T7saAuLDBkMjFBxV Gf2YnEEHAy/wxsHDTwTYJ9lUpimIi5+hiV4Cq10V+SaFv3Zd1jUcsVkHzEdCzSv9+5BN ast+lwlMZD5/G9Hwm5rQBecYfkRZw8s5S4GeVXXJz9CalhLSIACWclOjNaD2yj/1RVQ3 f5cg== X-Received: by 10.224.72.81 with SMTP id l17mr298105qaj.88.1389298356984; Thu, 09 Jan 2014 12:12:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.120.130 with HTTP; Thu, 9 Jan 2014 12:12:16 -0800 (PST) In-Reply-To: <201401091437.04245.mark.tinka@seacom.mu> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> <201401091437.04245.mark.tinka@seacom.mu> From: "Andrew G. Malis" Date: Thu, 9 Jan 2014 15:12:16 -0500 Message-ID: To: mark.tinka@seacom.mu Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 10 Jan 2014 08:19:53 -0800 Cc: gorry@erg.abdn.ac.uk, "mpls@ietf.org" , LISP mailing list list , david.black@emc.com, tsvwg@ietf.org, Stewart Bryant , jnc@mit.edu, IETF Discussion Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 20:12:50 -0000 I suspect the only way that we can count "misdelivered" MPLS packets is by looking for missing packets at the receiver, such as by using the sequence number in the PW control word, TCP, or UDP header, depending on the MPLS LSP payload. Thinking about the consequences of an MPLS label somehow becoming corrupted in transit, nothing will happen until the corrupted label reaches the top of the stack. At that time, either the packet will be dropped because the corrupted label isn't in the local LIB, or it is in the database and the packet will be most likely forwarded out of the wrong interface, to be dropped at the next label pop because the label now at the top of the stack is most likely not in that router's LIB. Eventually, the packet will most likely be dropped in the network, or there is a small but nonzero probability that it will be delivered to an incorrect non-MPLS external interface after the last label has been popped. If the payload was a globally routable IP packet (not in an IP VPN) and PHP is in use, then the IP forwarding lookup in the LER may get the packet to the right place (which will most probably be not on that particular LER). Even if PHP isn't in use, if the external interface happens to be to another router in the same IP address space, then again IP forwarding may get the packet to the right place. Of course, it could be a PW control word that gets corrupted, in which case the packets would reach the PW termination point, but would fail the sequence number check if the sequence number is in use and that's the part of the CW that was corrupted. I don't think anything really bad happens if an entropy label is corrupted. An interesting thought experiment. Cheers, Andy On Thu, Jan 9, 2014 at 7:36 AM, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled > MPLS. > >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted > MPLS frames so operators can glean this data. This isn't > something I've come across, but it would be good to find > some kind of way to count this across interfaces, if the > routers can detect and report them. > > The known issue about mis-delivery of MPLS frames is poorly- > sized MTU interfaces. I have no empirical data as to how > this can corrupt successive MPLS frames that may fit into > the transit MTU. But in this case, as with any Layer 2 > traffic, not enough MTU = dropped frame. > > Mark. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From david.i.allan@ericsson.com Thu Jan 9 12:26:46 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA701AE425; Thu, 9 Jan 2014 12:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8avMEAKu9fRr; Thu, 9 Jan 2014 12:26:44 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 18DCF1AE411; Thu, 9 Jan 2014 12:26:44 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-25-52cf05f6cddf Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A7.B2.23183.6F50FC25; Thu, 9 Jan 2014 21:26:31 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0347.000; Thu, 9 Jan 2014 15:26:28 -0500 From: David Allan I To: Gregory Mirsky , "mpls@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Thread-Index: AQHPDVZP/GN/wtlIskG6flItphhfHpp8+h2A///ZBGA= Date: Thu, 9 Jan 2014 20:26:27 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> <201401091437.04245.mark.tinka@seacom.mu> <52CECB7B.3090200@pi.nu> <7347100B5761DC41A166AC17F22DF1121B743FDC@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B743FDC@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyuXRPoO531vNBBn+/2Fg82zifxWLKWXWL W0tXsloce3OXzYHFY8mSn0wBjFFcNimpOZllqUX6dglcGac3rGUuOCtR0XnmKnMD41vhLkYO DgkBE4mNU3y7GDmBTDGJC/fWs3UxcnEICRxhlJjU/ZkVwlnGKLG9eQ0rSBWbgIHEnv9fGEES IgK7GCXuHp7PApIQFsiSWH5mCjvIVBGBbImXS/1BwiICVhKrLpxmB7FZBFQklk7bzAhi8wr4 Snze/B9q21wmif8Lf4Et4BTwk3i5YyaYzQh00vdTa5hAbGYBcYlbT+YzQZwqILFkz3lmCFtU 4uXjf6wQtrLE9zmPWCDqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsoqRo7Q4tSw33chgEyMwLo5JsOnuYNzz0vIQozQHi5I475e3zkFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGK13Jj+/q3D3CuvaH6GzePcUJ4YsSD8e9vmMu4rwlU8eGTUd+1pLTET2 XJ706sDkAEc+TpnvZ+rebPgYzHXUy/3qzbXtlif2TxIImFamcj3n9/2KrOCQ8z5Fts3iQos/ 1Mmuc/gWs+ZOBUPe5IKbIvNY5lq13bv2RidlQsXD+isrLRMPL5OynabEUpyRaKjFXFScCABg f1O7WQIAAA== X-Mailman-Approved-At: Fri, 10 Jan 2014 08:19:53 -0800 Subject: Re: [lisp] [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 20:26:46 -0000 Hi (trimmed received list) I'm not sure what the starting point of this dialog is, but I can at least = say Greg is right on the CV front, it only detects and does not measure mis= direction.=20 The only other possibility to count anything is a "no ILM" condition where = the label value is unrecognized by the receiving LSR, which IMO could not b= e made authoritative if it is label values in either the frame or the NHLFE= and not exclusively next hops that is corrupted. Cheers D -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, January 09, 2014 9:30 AM To: Loa Andersson; mark.tinka@seacom.mu; stbryant@cisco.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; davi= d.black@emc.com; jnc@mit.edu; tsvwg@ietf.org Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in= -udp was RE: gre-in-udp draft Hi Loa, et al., I think that you're referring to Connectivity Verification in MPLS-TP (RFC = 6428). It would only detect mis-connection but would not count leaked in fr= ames. Such problem may be more apparent in Segment Routing (SPRING WG). Perhaps C= V should be a requirement in SR OAM. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, January 09, 2014 8:17 AM To: mark.tinka@seacom.mu; stbryant@cisco.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: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp= was RE: gre-in-udp draft Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled MPLS. > >> I am interested in how often in practice MPLS packets get=20 >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted MPLS frames=20 > so operators can glean this data. This isn't something I've come=20 > across, but it would be good to find some kind of way to count this=20 > across interfaces, if the routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- sized MTU=20 > interfaces. I have no empirical data as to how this can corrupt=20 > successive MPLS frames that may fit into the transit MTU. But in this=20 > case, as with any Layer 2 traffic, not enough MTU =3D dropped frame. > > Mark. > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Thu Jan 9 18:18:18 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3653D1ADF8A; Thu, 9 Jan 2014 18:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 J6UI_-fdkPL0; Thu, 9 Jan 2014 18:18:15 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7F1ADF65; Thu, 9 Jan 2014 18:18:14 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0A2Hv4I081006; Thu, 9 Jan 2014 21:17:57 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401100217.s0A2Hv4I081006@maildrop2.v6ds.occnc.com> To: David Allan I From: Curtis Villamizar In-reply-to: Your message of "Thu, 09 Jan 2014 20:26:27 +0000." Date: Thu, 09 Jan 2014 21:17:57 -0500 X-Mailman-Approved-At: Fri, 10 Jan 2014 08:19:53 -0800 Cc: Gregory Mirsky , "mpls@ietf.org" , "tsvwg@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" Subject: Re: [lisp] [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 02:18:18 -0000 Since we are all top posting ... For counting dropped packets LM OAM is what you need. CV doesn't do that. Direct LM will give best results on a per LSP basis but requires forwarding chip support to do so. I also don't know the origin of this discussion. >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. Not very often if ever at least for major vendor products. I don't know if second tier or third tier players have bugs. (Very often circa 2000 or earlier particularly with one specific vendor and with one provider who made things much worse by mucking with the ILM through management plane, but that is ancient history). Bit rot in TCAM or SRAM is very rare. Bit rot in circa 1980s DRAM was a problem. Bit rot in modern non-ECC DRAM is rare. Bit rot in modern ECC DRAM is very rare. Therefore to have a bad ILM you need bugs. Curtis In message David Allan I writes: Hi (trimmed received list) I'm not sure what the starting point of this dialog is, but I can at least say Greg is right on the CV front, it only detects and does not measure misdirection. The only other possibility to count anything is a "no ILM" condition where the label value is unrecognized by the receiving LSR, which IMO could not be made authoritative if it is label values in either the frame or the NHLFE and not exclusively next hops that is corrupted. Cheers D -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, January 09, 2014 9:30 AM To: Loa Andersson; mark.tinka@seacom.mu; stbryant@cisco.com 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] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Hi Loa, et al., I think that you're referring to Connectivity Verification in MPLS-TP (RFC 6428). It would only detect mis-connection but would not count leaked in frames. Such problem may be more apparent in Segment Routing (SPRING WG). Perhaps CV should be a requirement in SR OAM. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, January 09, 2014 8:17 AM To: mark.tinka@seacom.mu; stbryant@cisco.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: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled MPLS. > >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted MPLS frames > so operators can glean this data. This isn't something I've come > across, but it would be good to find some kind of way to count this > across interfaces, if the routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- sized MTU > interfaces. I have no empirical data as to how this can corrupt > successive MPLS frames that may fit into the transit MTU. But in this > case, as with any Layer 2 traffic, not enough MTU = dropped frame. > > Mark. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From l.wood@surrey.ac.uk Sat Jan 11 18:59:58 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@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: To: , 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>, <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: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 check= sum 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 acro= ss 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 leav= e 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: R= E: [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 wit= h tsvwg work, but the review came back "clean". Of course, such a review is j= ust one person, so this conversation is good. Wrt zero checksum, where do you stand on nested checksums? There is some cl= aim 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 motivation= s 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 s= weep of "I am opposed". You should probably look at the NVGRE and VXLAN work (wh= ich I think is lurking around the NVO3 working group) because that is also lookin= g 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.u= k > 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.c= om; > 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.o= rg; > jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org > Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [t= svwg] > 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 cur= rent > 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 From l.wood@surrey.ac.uk Sun Jan 12 13:27:07 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242AF1ACC85; Sun, 12 Jan 2014 13:27:07 -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 ytbGuU5rCF86; Sun, 12 Jan 2014 13:27:04 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDA91A1DFA; Sun, 12 Jan 2014 13:27:03 -0800 (PST) Received: from [195.245.231.67:56026] by server-11.bemta-5.messagelabs.com id 75/AE-23268-B9803D25; Sun, 12 Jan 2014 21:26:51 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-9.tower-82.messagelabs.com!1389562011!29053243!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6226 invoked from network); 12 Jan 2014 21:26:51 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-9.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 12 Jan 2014 21:26:51 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sun, 12 Jan 2014 21:26:50 +0000 From: To: Date: Sun, 12 Jan 2014 21:22:58 +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: Ac8PwWaHPFhUsU0dTLGXrrfKJuvBpAAGxCQx Message-ID: <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> References: Your message of "Sun, 12 Jan 2014 02:59:41 +0000." <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk>, <201401121809.s0CI91Y1053969@maildrop2.v6ds.occnc.com> In-Reply-To: <201401121809.s0CI91Y1053969@maildrop2.v6ds.occnc.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: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 21:27:07 -0000 Curtis I suggest reading Stone's work, particularly ''When The CRC and TCP Checksum Disagree' for discussion of corruption. Particularly its conclusions: 'In the internet, that means we are sending large volumes of incorrect data without anyone noticing'. The Layer-2 check is per link, not end-to-end. That matters. The MPLS assumption is that it crosses a link with a frame checksum. Putting MPLS over UDP breaks that assumption. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 12 January 2014 18:09 To: Wood L Dr (Electronic Eng) Cc: adrian@olddog.co.uk; randy@psg.com; gorry@erg.abdn.ac.uk; mpls@ietf.org= ; lisp@ietf.org; ietf@ietf.org; david.black@emc.com; jnc@mit.edu; tsvwg@iet= f.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: R= E: [tsvwg] Milestones changed for tsvwg WG) In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > 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 che= cksum > 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 ac= ross > 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 b= it > 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 le= ave out). > > Nothing else checks that scope. The scope is wider, and affects the netwo= rk > as a whole. Errors in these unchecked fields lead to misdirection and lea= d to > misdelivery. Or pollution of other ports. > > The MPLS assumption is that it's protected and checked by a strong link C= RC 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. That UDP would be running over IP over Ethernet or POS or GFP or ... There is no layer-2 currently in use that does not have a robust FCS, generally a 32 FCS and therefore the MPLS assumption of checking at a lower layer is still valid. Curtis > "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.c= om; 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 cal= ls, so > thanks for the comments. > > We did take the precaution of sending this I-D for an early TSV Directora= te > review because of the concern about a number of factors and the overlap w= ith > 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 whe= n 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 fo= r > software implementations (as have been claimed to be some of the motivati= ons 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 look= ing 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 (wa= s: 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 c= urrent > > 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 strongl= y > > 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 From l.wood@surrey.ac.uk Sun Jan 12 13:34:38 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5221ACC85; Sun, 12 Jan 2014 13:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_82=0.6, 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 rVmWS-M1eOCv; Sun, 12 Jan 2014 13:34:37 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) by ietfa.amsl.com (Postfix) with ESMTP id 122891A1DFA; Sun, 12 Jan 2014 13:34:35 -0800 (PST) Received: from [85.158.137.99:24782] by server-16.bemta-3.messagelabs.com id DD/1B-26128-F5A03D25; Sun, 12 Jan 2014 21:34:23 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-10.tower-217.messagelabs.com!1389562463!21261411!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1644 invoked from network); 12 Jan 2014 21:34:23 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-10.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 12 Jan 2014 21:34:23 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Sun, 12 Jan 2014 21:34:23 +0000 From: To: , Date: Sun, 12 Jan 2014 21:32:28 +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: Ac8PkY4DGIVCbttAQXqJ2uFOHpC4TAATD1BS Message-ID: <290E20B455C66743BE178C5C84F1240847E63346BE@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk>, <201401121426.23719.mark.tinka@seacom.mu> In-Reply-To: <201401121426.23719.mark.tinka@seacom.mu> 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, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, ietf@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 21:34:38 -0000 > Right, which is probably why routers today can count badly > checksum'ed Ethernet frames, but don't have the equivalent > for MPLS. If Ethernet frames keep failing the check, you know you have a local problem that needs fixing. That's why it's instrumented. Do any routers count TCP/UDP checksum failures, much less expose the count via SNMP? Lloyd Wood http://about.me/lloydwood ________________________________________ From: Mark Tinka [mark.tinka@seacom.mu] Sent: 12 January 2014 12:26 To: mpls@ietf.org Cc: Wood L Dr (Electronic Eng); adrian@olddog.co.uk; randy@psg.com; gorry@= erg.abdn.ac.uk; 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: R= E: [tsvwg] Milestones changed for tsvwg WG) On Sunday, January 12, 2014 04:59:41 AM l.wood@surrey.ac.uk wrote: > 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. Right, which is probably why routers today can count badly checksum'ed Ethernet frames, but don't have the equivalent for MPLS. > I'm sorry, when was MPLS cheap? Current-generation ASIC's have no problem forwarding MPLS frames at wire rate. One could go so far as to say that MPLS has allowed vendors to make cheaper line cards also because IP FIB's and traffic queues can be scaled down dramatically (not that I'd every buy such line cards, but...). Mark. From farinacci@gmail.com Sun Jan 12 13:37:16 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6C11AE013; Sun, 12 Jan 2014 13:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 vNZFc2qXT733; Sun, 12 Jan 2014 13:37:15 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1F34B1ADFF3; Sun, 12 Jan 2014 13:37:15 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb1so303109pad.38 for ; Sun, 12 Jan 2014 13:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Hy0NAgTRz5/l6EPUl9CUfcPwWnRgwo5S+Vd1yW7irlc=; b=c8QwbDetVyvewmjJIiDiUYhvNHCiLfTxZB7CtqMNvpxZxqmYZkYKl84QQFvqtEEe0t 7dzxqYXB/uW/eFmIioRTk426DyS+ueO/YgRHQVZFXXsGW/gTaTvfe6TglpQiHi3kLTHE 3NFrhiSIxOvk8jbcZRl81d3/QSmmnOfRjbMPBPmI8wsT+T/hkEKJfxHFsh25wap674HF iuM+H4Hixw9gpGMLwVrHz3KpTGiz+CmSnx4ET7cYaFcDyaScl/TrwoKQyJWEi1i6bdWN xYOoUieMBixPWhu+Aoe1JuneE/h4qmMMrjm5j4J1GvsUzklLeBIN3n6XEaNT30Yu+9s7 6O1w== X-Received: by 10.66.136.107 with SMTP id pz11mr26215058pab.118.1389562624528; Sun, 12 Jan 2014 13:37:04 -0800 (PST) Received: from [192.168.1.15] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id sy10sm42330439pac.15.2014.01.12.13.37.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Jan 2014 13:37:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11B554a) In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346BE@EXMB01CMS.surrey.ac.uk> Date: Sun, 12 Jan 2014 13:37:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> <201401121426.23719.mark.tinka@seacom.mu> <290E20B455C66743BE178C5C84F1240847E63346BE@EXMB01CMS.surrey.ac.uk> To: "" Cc: "" , "" , "ietf@ietf.org" , "lisp@ietf.org" , "gorry@erg.abdn.ac.uk" , "david.black@emc.com" , "randy@psg.com" , "jnc@mit.edu" , "tsvwg@ietf.org" Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 21:37:16 -0000 > Do any routers count TCP/UDP checksum failures, much less > expose the count via SNMP? Typically they do but only for packets destined to them. Much like hosts wou= ld check the header checksum.=20 Dino= From l.wood@surrey.ac.uk Sun Jan 12 16:48:05 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EEE1ACCD9; Sun, 12 Jan 2014 16:48:05 -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 zu0P8HFOgrYa; Sun, 12 Jan 2014 16:48:02 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id D3F281ACC91; Sun, 12 Jan 2014 16:48:01 -0800 (PST) Received: from [195.245.231.67:64589] by server-17.bemta-5.messagelabs.com id 32/F2-19152-6B733D25; Mon, 13 Jan 2014 00:47:50 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-9.tower-82.messagelabs.com!1389574069!29061545!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27567 invoked from network); 13 Jan 2014 00:47:49 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-9.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jan 2014 00:47:49 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Mon, 13 Jan 2014 00:47:48 +0000 From: To: Date: Mon, 13 Jan 2014 00:45:52 +0000 Thread-Topic: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Thread-Index: Ac8P3nEsYE8Z6DG8TdaYBKdC9S/GqwAGl7Nt Message-ID: <290E20B455C66743BE178C5C84F1240847E63346BF@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> <201401121426.23719.mark.tinka@seacom.mu> <290E20B455C66743BE178C5C84F1240847E63346BE@EXMB01CMS.surrey.ac.uk>, In-Reply-To: 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: mark.tinka@seacom.mu, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, gorry@erg.abdn.ac.uk, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 00:48:05 -0000 Really, you'd want to expose the pseudoheader check at endhosts; a well-ins= trumented Linux box could tell you a lot about checksum failures. But in this case, a router would be decapping UDP/MPLS tunnels as an endpoi= nt, so could report on checksum failures - if the checksum wasn't zero. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Dino Farinacci [farinacci@gmail.com] Sent: 12 January 2014 21:37 To: Wood L Dr (Electronic Eng) Cc: ; ; gorry@erg.abdn.ac.uk; lisp@iet= f.org; david.black@emc.com; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; iet= f@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft = (was: RE: [tsvwg] Milestones changed for tsvwg WG) > Do any routers count TCP/UDP checksum failures, much less > expose the count via SNMP? Typically they do but only for packets destined to them. Much like hosts wo= uld check the header checksum. Dino From mark.tinka@seacom.mu Sun Jan 12 04:26:51 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BAA1AE071; Sun, 12 Jan 2014 04:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_82=0.6] autolearn=no 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 K1oiHRm9zhHE; Sun, 12 Jan 2014 04:26:50 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0544D1AE06E; Sun, 12 Jan 2014 04:26:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2K7U-0007Rm-A2; Sun, 12 Jan 2014 14:26:24 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org Date: Sun, 12 Jan 2014 14:26:23 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2145601.e0txlHMqRJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401121426.23719.mark.tinka@seacom.mu> X-Mailman-Approved-At: Mon, 13 Jan 2014 09:00:17 -0800 Cc: gorry@erg.abdn.ac.uk, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, ietf@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 12:26:51 -0000 --nextPart2145601.e0txlHMqRJ Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sunday, January 12, 2014 04:59:41 AM l.wood@surrey.ac.uk=20 wrote: > 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. Right, which is probably why routers today can count badly=20 checksum'ed Ethernet frames, but don't have the equivalent=20 for MPLS. > I'm sorry, when was MPLS cheap? Current-generation ASIC's have no problem forwarding MPLS=20 frames at wire rate. One could go so far as to say that MPLS=20 has allowed vendors to make cheaper line cards also because=20 IP FIB's and traffic queues can be scaled down dramatically=20 (not that I'd every buy such line cards, but...). Mark. --nextPart2145601.e0txlHMqRJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS0onvAAoJEGcZuYTeKm+GO5YQAKFRVfaAIFXCOBY/gYZEQwQ4 iqdsoVfKH8J2qPY4ESdk/Z5CCABTXCQDSFSUicGPXZirZX0kQNF6aIOEbBhob6D9 dV8Hmg9Wn20xRMhhseBU1MSWld1W+TV00fxFGfkUUm34FP+ijm/qbyMaJxnugYqz QAtb7BDpI2PG3TiinXyWgmBrc3qKNEvSpkn/HIA9VWKlQmIoXEWXc+l6s9BzfC86 c2WrExvW2iEHfIwcJkcnX1hIQ9NVsVjzrj95XVYBb9oiyknhjrDGrsmBSyyvAgRB 6dTY/4o2hPK7gBr98srtaK+C35ak7aLvezj0PBfHbgQ2lF7Bk6fe3tN+ps4BKthg zsAn4+6qR+XOdZhzXx2kyaZe/PfFdFU/kKqVAQejn7BG4/etiWFm1pGSqSoVDMtc zqvN6tNyIYMNRSZGNZl6UZdX5ACG3Ta1T/WKTy/sO17SGES9gNxIZ8my7xH/FBeo Abxq3RVs6eAzgV05pDX92LBNvD94PxVbmQmKvWOWNl6VZpjV5h+mO4mKGdeR+p7G OVTQx1IR9zDYO5eJPz7v4n62P/BfIwzeVLlJBYFpmQNRvhtFLrn5R3u72WOahhZO JPZPAHqkLcfB/ScR3ulmt7zzUUr9zYUXsAzsINaGPDOekoVllVt5eNKOjKNw3Z45 IJ2hUIVy2S2BkNc2rk6+ =A+bb -----END PGP SIGNATURE----- --nextPart2145601.e0txlHMqRJ-- From curtis@ipv6.occnc.com Sun Jan 12 10:09:22 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209DE1ADF7D; Sun, 12 Jan 2014 10:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 kmWCUiK9SE2P; Sun, 12 Jan 2014 10:09:19 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 183821ADF7C; Sun, 12 Jan 2014 10:09:18 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0CI91Y1053969; Sun, 12 Jan 2014 13:09:01 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401121809.s0CI91Y1053969@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Sun, 12 Jan 2014 02:59:41 +0000." <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> Date: Sun, 12 Jan 2014 13:09:01 -0500 X-Mailman-Approved-At: Mon, 13 Jan 2014 09:00:17 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 18:09:22 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > 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. That UDP would be running over IP over Ethernet or POS or GFP or ... There is no layer-2 currently in use that does not have a robust FCS, generally a 32 FCS and therefore the MPLS assumption of checking at a lower layer is still valid. Curtis > "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 From curtis@ipv6.occnc.com Sun Jan 12 10:37:37 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBCD1AE00C; Sun, 12 Jan 2014 10:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_82=0.6, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 pJnoHHCrCFIc; Sun, 12 Jan 2014 10:37:36 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id BB9AB1ADFE6; Sun, 12 Jan 2014 10:37:35 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0CIbGKE054334; Sun, 12 Jan 2014 13:37:16 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401121837.s0CIbGKE054334@maildrop2.v6ds.occnc.com> To: mark.tinka@seacom.mu From: Curtis Villamizar In-reply-to: Your message of "Sun, 12 Jan 2014 14:26:23 +0200." <201401121426.23719.mark.tinka@seacom.mu> Date: Sun, 12 Jan 2014 13:37:16 -0500 X-Mailman-Approved-At: Mon, 13 Jan 2014 09:00:17 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: [lisp] OT was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 18:37:37 -0000 In message <201401121426.23719.mark.tinka@seacom.mu> Mark Tinka writes: > On Sunday, January 12, 2014 04:59:41 AM l.wood@surrey.ac.uk > wrote: > > > 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. > > Right, which is probably why routers today can count badly > checksum'ed Ethernet frames, but don't have the equivalent > for MPLS. > > > I'm sorry, when was MPLS cheap? > > Current-generation ASIC's have no problem forwarding MPLS > frames at wire rate. One could go so far as to say that MPLS > has allowed vendors to make cheaper line cards also because > IP FIB's and traffic queues can be scaled down dramatically > (not that I'd every buy such line cards, but...). > > Mark. Perhaps if you actully worked for a company that made line cards you would not make the above statement. Many of the big router vendors use the same TCAM hardware for MPLS lookups as they do for IP lookups. Doing the lookup is not the rate limiting factor even in hardware that has an ILM SRAM table and some form of radix based lookup. All of the hardwre I've seen in the last 15 years or so forwards MPLS and IP at the same rate. ... Except IPv6 before they decided to waste the lower half of the address space with 40 quintilion host in a bridged subnet and you really did have to look at the whole 128 bits. Back when forwarding was done in software (circa 1995) your statement would have been true if MPLS preceeded forwarding ASICs which it did not. Also the statement "Current-generation ASIC's have no problem forwarding MPLS frames at wire rate" is not true for most (or all) hardware with 40 byte payloads (even with plus 4 with TCP SACK plus 4 if MPLS) and 100 Gb/s interfaces. It is true for "average packet size" traffic and on most hardware only true if bursts of 40 byte packets are very limited in duration. Curtis From mark.tinka@seacom.mu Sun Jan 12 11:05:13 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C2B1AE013; Sun, 12 Jan 2014 11:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no 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 OQSton2cP-ZI; Sun, 12 Jan 2014 11:05:10 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id C693A1AE012; Sun, 12 Jan 2014 11:05:09 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2QKz-0000ia-1E; Sun, 12 Jan 2014 21:04:45 +0200 From: Mark Tinka Organization: SEACOM To: curtis@ipv6.occnc.com Date: Sun, 12 Jan 2014 21:04:40 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <201401121837.s0CIbGKE054334@maildrop2.v6ds.occnc.com> In-Reply-To: <201401121837.s0CIbGKE054334@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1564113.ZqtHiklPLi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401122104.44370.mark.tinka@seacom.mu> X-Mailman-Approved-At: Mon, 13 Jan 2014 09:00:17 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [lisp] OT was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 19:05:13 -0000 --nextPart1564113.ZqtHiklPLi Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sunday, January 12, 2014 08:37:16 PM Curtis Villamizar=20 wrote: > Perhaps if you actully worked for a company that made > line cards you would not make the above statement. I work for an operator that pays real money to deploy and=20 use those line cards, and I make it my business to know what=20 I'm paying for. > Many of the big router vendors use the same TCAM hardware > for MPLS lookups as they do for IP lookups. Doing the > lookup is not the rate limiting factor even in hardware > that has an ILM SRAM table and some form of radix based > lookup. All of the hardwre I've seen in the last 15 > years or so forwards MPLS and IP at the same rate. Which was exactly my point - unless you somehow missed that. > ... > Except IPv6 before they decided to waste the lower half > of the address space with 40 quintilion host in a > bridged subnet and you really did have to look at the > whole 128 bits. It is no secret that forwarding of IPv6 packets on some=20 vendor equipment is about half the rate of IPv4 or MPLS. But=20 then again, because MPLS control planes are IPv4-driven=20 today, I'm hoping I didn't have to be explicit about not=20 including IPv6 in that group, on this list. > Back when forwarding was done in > software (circa 1995) your statement would have been > true if MPLS preceeded forwarding ASICs which it did > not. You might not know that line cards from C like the LSP=20 (Label Switch Processor) and much of the PFE from J's PTX=20 are forwarding engines that have been made cheaper by=20 reducing the IP FIB on the assumption that all traffic will=20 be carried in MPLS. This is, obviously, an assumption I do=20 not support because: - I run IPv6 natively, and at the moment, there are no production-grade IPv6 control planes for MPLS. - It assumes providers will run 6PE (in which case, IPv6 traffic enjoys MPLS and IPv6 wire rate forwarding speeds). I do not buy such line cards because for anyone running=20 native IPv6, you could potentially run out of FIB slots to=20 host IPv6 routes. That is why I say MPLS has allowed vendors to put out=20 cheaper line cards compared to the costs of those which have=20 large IPv4/IPv6 scale. Because MPLS forwarding is so=20 mainstream, there is no additional cost associated with=20 forwarding rates similar to IPv4. So much of the cost of=20 line cards is in QoS queues and routing FIB slots (and MPLS- biased line cards are stripped of that, hence making them=20 cheaper). > Also the statement "Current-generation ASIC's have no > problem forwarding MPLS frames at wire rate" is not true > for most (or all) hardware with 40 byte payloads (even > with plus 4 with TCP SACK plus 4 if MPLS) and 100 Gb/s > interfaces. It is true for "average packet size" > traffic and on most hardware only true if bursts of 40 > byte packets are very limited in duration. C'mon, Curtis. Everybody knows this already. Moreover, real=20 world IP traffic is not all 40 bytes. If operators have doubts about what forwarding engines can=20 do below 128 bytes, that is what PoC labs are for before you=20 buy. And even then, several operators accept the=20 restrictions up to a certain point, because the lab and real=20 life vary significantly. Mark. --nextPart1564113.ZqtHiklPLi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS0udMAAoJEGcZuYTeKm+GxhUQAKZAROVv7BygnH/5UIS6z5Zz 2NMk2GFbUL3p4hFWjOVwBSqhi6FVc6KRWpBynXlBTDJBaJIZfkD5HjBT7ZSr6m94 jYQLXeznNF1GnDMii8nA+n5kOQFahbOR21aKzm/GI/DUyH7dsqckHnZYy+K8m7cO ZmCPDuNV5BAba5Gsi7vFXFHak6z8dLqQWKzeUt7/im2HGCOphGQOhUXWuqqvgUFH lhh5H2JIntXJniCGsibbqBy5lTNviZ4qH2smXeFHjmPOyBzfRpBoYn82KJz6avry vunb+Ki1G0si+PPpbSv+rq8NE+i2RbH5/4cHjwPMhtNYYwu9LAEgZn2tLEialh56 TAui8DVpNZIJlH16IOn1gvIoEaridKeZsf4aT+0NwGr1jkc+P1AWEq6xse8o5Vqq XmnS/YmGLuCdknuzQzuIHzmmhdscDsw5LoCmd+Hel4tY3CvbcdGzMsaCWolADPke 69UX7tMuH8N8E499aiorT377kOn5yfOdSXEx8O4hRpPMoEbtQ4L1Q10XWrTJij3l 1tq7v0wy+TnZUGWzltMj+OWbCbfrwGx8j6KY3MjK29UkTtSswsR2s8WPHdoANlt+ oyk7v8XVbHt0/obgA3R1aPlrOHOx2U81LkBn4D+NlvAOeD5SbS7V+4l+NLgD6BZ0 6WmISwj1cO2CivbvsM38 =tmsD -----END PGP SIGNATURE----- --nextPart1564113.ZqtHiklPLi-- From stbryant@cisco.com Tue Jan 14 06:18:04 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB721ADFB6; Tue, 14 Jan 2014 06:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Ua1uMtRFCfyR; Tue, 14 Jan 2014 06:18:02 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 94CBA1AE0CC; Tue, 14 Jan 2014 06:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1432; q=dns/txt; s=iport; t=1389709071; x=1390918671; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xplMTCVHK+awtKhL4j4qiFjX/qRtqYJJ+mcb0t8TCPQ=; b=MuL0HLKsGkW5uirCYPkznboY49qOHPXgW1qQEDK9jvECFkZim4P5dFQj gYywe5wX3lfnKFI3dNFamUDHbJVbDZhWgxMvrEYJqm/AxRzXdIMbZ45kw qgFso1FA2vyhLudcRmcx+rG63QMVHt7/jE5OTI6tBoaMTFmxkuBSDuwgP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FACVG1VKQ/khL/2dsb2JhbABaDoJ9uFeDDoESFnSCJgEBBDhAARALIRYECwkDAgECAUUHDAEHAQGIAMQrF48HB4Q3AQOYHpIVgW9/Pw X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="3611960" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 14 Jan 2014 14:17:49 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0EEHnZI012590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 14:17:49 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0EEHkTl019554; Tue, 14 Jan 2014 14:17:47 GMT Message-ID: <52D5470A.9020002@cisco.com> Date: Tue, 14 Jan 2014 14:17:46 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, curtis@ipv6.occnc.com References: Your message of "Sun, 12 Jan 2014 02:59:41 +0000." <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk>, <201401121809.s0CI91Y1053969@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:18:04 -0000 Lloyd I have just read the Stone paper and I have some significant concerns about its validity with modern h/w. Certainly it is hard to credit the notion that the error rate is in the range 1:1000 to 1:32000 as reported by the authors. The paper was written in 2000 with hardware that would have have been designed in the mid 1990s. In that era, h/w was far more marginal, with performance traded against signal integrity, and indeed a lot less signal integrity measurement and simulation took place at both board and chip level. This was also the era where metastability was just beginning to become widely understood, and its lack of understanding would be a possible source of DMA errors. I therefore do not think we should place much reliance on this paper, but should instead look at the rather more modern statistics. Such statistics ought to be readily available by looking at the tcp/udp c/s error stats in hosts and routers. As a tiny and perhaps erroneous sample I looked at three Macs in the office here and the tcp c/s error stats were 313/29144518, 0/3000000, 0/5000000. Only one of those three systems got within a factor of 3 of the lowest error rate reported by Stone. Bottom line, it seems that we could use more recent data and then an understanding of how important these low background error rates are in the tunneling application that we are considering here. - Stewart From stbryant@cisco.com Tue Jan 14 10:27:06 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6831AE101; Tue, 14 Jan 2014 10:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 PJ9XYVg8YGXD; Tue, 14 Jan 2014 10:27:03 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id B34301AE06C; Tue, 14 Jan 2014 10:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9804; q=dns/txt; s=iport; t=1389724012; x=1390933612; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=buqbYsHxbFMGj5If0RKN8HQZ1bI9G1YZmgKQfkEtu+U=; b=D7OWqqQoq5EtZSzcvA/g8OnQP3PVO+/BKJZSS+1ncu4+fvcNSXNXMkj4 XtQqqPjqlZag4UMglgIZbRtZjqJJNuy6fS401+6re7VpTrPfk7iHUXVtj SVc7/pkH3ANj4Z8PZwgwEBcbATFRVA0XVrrlfMU1tkRRWSQSoot+chwle Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4FAPKA1VKQ/khN/2dsb2JhbABQCg6CfThQumSBFRZ0giUBAQECAgEBATUwBgoBDAQLEQQBAQEJFgQEBwkDAgECARUfAwEFCAcJAwEFAgEBiAAIBcQoF44rOiIHBoQxBJgegTCLLYU4gW9/Pw X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="3622779" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 14 Jan 2014 18:26:50 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0EIQnea003901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 18:26:50 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0EIQm2s008555; Tue, 14 Jan 2014 18:26:48 GMT Message-ID: <52D58168.9060800@cisco.com> Date: Tue, 14 Jan 2014 18:26:48 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com, l.wood@surrey.ac.uk References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> In-Reply-To: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [lisp] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:27:07 -0000 I agree the paper is now obsolete. Stewart On 14/01/2014 17:06, Curtis Villamizar wrote: > Lloyd, > > Maybe you should reread the paper too before citing it as evidence. > Check the date on it. Check the cited causes of errors. > > Packet traces from 1998 and 1999 are prehaps not so relevante today, > particularly wrt error rates due to hosts, router memories, and link > error rates. Look at the cited caused of errors and realize that many > things have changed. > > The largest single error in the paper (paerhaps as high as 99.9% of > the errors) was the ACK-of-FIN bug in Windows NT. They may have fixed > that by now. Other large causes were host hardware and host software > bugs (sent bad data in the first place). > > One fifth of campus errors were caused by two hosts. This is cited as > a bug in Mac OS on Powermac 8100, fixed at the time of publication. > > A lot of host software errors are discussed, where the checksums are > sent bad and therefore will pass any router link FCS. > > Sending host hardware errors were thought to be in large part caused > by no data integrity check on host DMA transfers. I think progress > has been made on that front. You can check PCIe. It has a 32bit CRC > per lane in the link layer and retransmits on error. > > Router memory errors was thought to play a large role in the non-host > part of the error rate in the paper. Routers use ECC now. Going that > far back they didn't always have parity RAM (and sometimes ran parity > disabled to avoid parity error reloads). > > VJHC software errors? Anyone still use VJHC? Those errors should be > gone. > > IP over HDLC over T1 missed a few errors at the link layer in those > days. That could be true and occurances dependent on the providers. > In the paper that was thought to be a very small contributor. > > Both HDLC and PPP had an option for 16 bit or 32 bit FCS. Often 16 > bit was used. Some HDLC equipment could be and was configured to > count errors and send the packets on their way on the assumption that > it was better to count errors and deliver bad packets rather than > deliver no packet. Perhaps also to hide packet loss. Today all of > the link layers in use have 32 bit FCS and count and toss errored > packets. In most equipment all of the memories have ECC and all of > the buses ECC or FCS if serialized. > > It is now 14 years since that paper was published in Signcomm and 16 > years since some of the observations. Things have changed. Nice bit > of nostangia but that paper may no longer be relevant. > > Curtis > > reference - > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf > > In message <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: >> Curtis >> >> I suggest reading Stone's work, particularly >> ''When The CRC and TCP Checksum Disagree' >> for discussion of corruption. >> >> Particularly its conclusions: 'In the internet, that means >> we are sending large volumes of incorrect data without >> anyone noticing'. >> >> The Layer-2 check is per link, not end-to-end. That matters. >> >> The MPLS assumption is that it crosses a link with a frame >> checksum. Putting MPLS over UDP breaks that assumption. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Curtis Villamizar [curtis@ipv6.occnc.com] >> Sent: 12 January 2014 18:09 >> To: Wood L Dr (Electronic Eng) >> Cc: adrian@olddog.co.uk; randy@psg.com; 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) >> >> In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> >> l.wood@surrey.ac.uk writes: >> >>> 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. >> >> That UDP would be running over IP over Ethernet or POS or GFP or ... >> >> There is no layer-2 currently in use that does not have a robust FCS, >> generally a 32 FCS and therefore the MPLS assumption of checking at a >> lower layer is still valid. >> >> Curtis >> >> >>> "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 > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From l.wood@surrey.ac.uk Tue Jan 14 13:57:46 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C391AE2B8; Tue, 14 Jan 2014 13:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 26j5X6uQdZK2; Tue, 14 Jan 2014 13:57:44 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0E41AE2AF; Tue, 14 Jan 2014 13:57:43 -0800 (PST) Received: from [193.109.255.147:47627] by server-10.bemta-14.messagelabs.com id D6/81-20752-BC2B5D25; Tue, 14 Jan 2014 21:57:31 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-72.messagelabs.com!1389736650!13624939!3 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13873 invoked from network); 14 Jan 2014 21:57:30 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-14.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 14 Jan 2014 21:57:30 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Tue, 14 Jan 2014 21:57:21 +0000 From: To: , Date: Tue, 14 Jan 2014 21:57:20 +0000 Thread-Topic: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) Thread-Index: Ac8RVjUkh7p2kMNVSGWEekhrdASM3gAHBvko Message-ID: <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com>, <52D58168.9060800@cisco.com> In-Reply-To: <52D58168.9060800@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: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [lisp] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 21:57:46 -0000 I don't think sayng 'oh, that error source is no longer a problem' disprove= s Stone's overall point about undetected errors, though the examples he uses from the technology of the day are necessarily dated. Dismissing the overall point because the examples use obsolete technology is throwing the baby out with the bathwater; a host-to-host error check catches things that intermediate checks cannot. Measuring error rates across end-to-end Internet traffic is something that= has not received much attention , as error detection is not instrumented well - hence citing Stone's published work, in the absence of awareness of anything newer (and as high profile/immediately recognisabl= e as sigcomm) in the area. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: 14 January 2014 18:26 To: curtis@ipv6.occnc.com; Wood L Dr (Electronic Eng) Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; lisp@ietf.org; davi= d.black@emc.com; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu Subject: Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp d= raft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) I agree the paper is now obsolete. Stewart On 14/01/2014 17:06, Curtis Villamizar wrote: > Lloyd, > > Maybe you should reread the paper too before citing it as evidence. > Check the date on it. Check the cited causes of errors. > > Packet traces from 1998 and 1999 are prehaps not so relevante today, > particularly wrt error rates due to hosts, router memories, and link > error rates. Look at the cited caused of errors and realize that many > things have changed. > > The largest single error in the paper (paerhaps as high as 99.9% of > the errors) was the ACK-of-FIN bug in Windows NT. They may have fixed > that by now. Other large causes were host hardware and host software > bugs (sent bad data in the first place). > > One fifth of campus errors were caused by two hosts. This is cited as > a bug in Mac OS on Powermac 8100, fixed at the time of publication. > > A lot of host software errors are discussed, where the checksums are > sent bad and therefore will pass any router link FCS. > > Sending host hardware errors were thought to be in large part caused > by no data integrity check on host DMA transfers. I think progress > has been made on that front. You can check PCIe. It has a 32bit CRC > per lane in the link layer and retransmits on error. > > Router memory errors was thought to play a large role in the non-host > part of the error rate in the paper. Routers use ECC now. Going that > far back they didn't always have parity RAM (and sometimes ran parity > disabled to avoid parity error reloads). > > VJHC software errors? Anyone still use VJHC? Those errors should be > gone. > > IP over HDLC over T1 missed a few errors at the link layer in those > days. That could be true and occurances dependent on the providers. > In the paper that was thought to be a very small contributor. > > Both HDLC and PPP had an option for 16 bit or 32 bit FCS. Often 16 > bit was used. Some HDLC equipment could be and was configured to > count errors and send the packets on their way on the assumption that > it was better to count errors and deliver bad packets rather than > deliver no packet. Perhaps also to hide packet loss. Today all of > the link layers in use have 32 bit FCS and count and toss errored > packets. In most equipment all of the memories have ECC and all of > the buses ECC or FCS if serialized. > > It is now 14 years since that paper was published in Signcomm and 16 > years since some of the observations. Things have changed. Nice bit > of nostangia but that paper may no longer be relevant. > > Curtis > > reference - > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pd= f > > In message <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.a= c.uk> > l.wood@surrey.ac.uk writes: >> Curtis >> >> I suggest reading Stone's work, particularly >> ''When The CRC and TCP Checksum Disagree' >> for discussion of corruption. >> >> Particularly its conclusions: 'In the internet, that means >> we are sending large volumes of incorrect data without >> anyone noticing'. >> >> The Layer-2 check is per link, not end-to-end. That matters. >> >> The MPLS assumption is that it crosses a link with a frame >> checksum. Putting MPLS over UDP breaks that assumption. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Curtis Villamizar [curtis@ipv6.occnc.com] >> Sent: 12 January 2014 18:09 >> To: Wood L Dr (Electronic Eng) >> Cc: adrian@olddog.co.uk; randy@psg.com; 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) >> >> In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.= ac.uk> >> l.wood@surrey.ac.uk writes: >> >>> 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 c= hecksum >>> matters. >>> >>> But here, we are not solely checking the payload, but information on ho= w 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 I= P >>> 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 processin= g >>> 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 net= work >>> as a whole. Errors in these unchecked fields lead to misdirection and l= ead 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; her= e, >>> in a path context, with zero UDP checksums MPLS has no checking at all. >> >> That UDP would be running over IP over Ethernet or POS or GFP or ... >> >> There is no layer-2 currently in use that does not have a robust FCS, >> generally a 32 FCS and therefore the MPLS assumption of checking at a >> lower layer is still valid. >> >> Curtis >> >> >>> "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 (wa= s: 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 c= alls, so >>> thanks for the comments. >>> >>> We did take the precaution of sending this I-D for an early TSV Directo= rate >>> 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 som= e claim >>> that they represent a waste of processing. I am not convinced by that w= hen each >>> layer is using dedicated hardware (that can presumably process checksum= s 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 motiva= tions 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 bro= ad 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 lo= oking 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.a= c.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@em= c.com; >>>> tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org >>>> Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (w= as: RE: >>>> [tsvwg] Milestones changed for tsvwg WG) >>>> >>>> Randy, >>>> >>>> okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's ge= t >>>> 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@iet= f.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 c= urrent >>>> 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 strong= ly >>>> see wg adoption as how we get to discuss and work on a document, not a= s >>>> approval of the document. as david said, i think we need to discuss i= t >>>> 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 > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From wes@mti-systems.com Tue Jan 14 14:07:54 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F322B1AE2B9 for ; Tue, 14 Jan 2014 14:07:53 -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] autolearn=unavailable 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 LS4IMVIiufS0 for ; Tue, 14 Jan 2014 14:07:52 -0800 (PST) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7DD1AE2B8 for ; Tue, 14 Jan 2014 14:07:51 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s0EM7cYQ026796 for ; Tue, 14 Jan 2014 17:07:38 -0500 Received: (qmail 28498 invoked by uid 0); 14 Jan 2014 22:07:38 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.107?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 14 Jan 2014 22:07:38 -0000 Message-ID: <52D5B524.5080408@mti-systems.com> Date: Tue, 14 Jan 2014 17:07:32 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, stbryant@cisco.com, curtis@ipv6.occnc.com References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com>, <52D58168.9060800@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 22:07:54 -0000 On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: > I don't think sayng 'oh, that error source is no longer a problem' disproves > Stone's overall point about undetected errors, though the > examples he uses from the technology of the day are necessarily > dated. Dismissing the overall point because the examples use obsolete > technology is throwing the baby out with the bathwater; a host-to-host > error check catches things that intermediate checks cannot. > > Measuring error rates across end-to-end Internet traffic is something that has > not received much attention , as error detection is not > instrumented well - hence citing Stone's published work, in the absence > of awareness of anything newer (and as high profile/immediately recognisable > as sigcomm) in the area. > +1 ... the message in the paper is applicable to layered systems and internetworks in general. Changes in the link technology since then don't invalidate it, especially since we know that the technology not only changes rapidly, but also is always growing in diverse directions, such that there things almost universally true today may be turned on their heads tomorrow. Designs for stacking layers need to follow solid general principles in order to be robust to changes (above and below). -- Wes Eddy MTI Systems From stbryant@cisco.com Tue Jan 14 14:46:31 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5EF1AE1DA; Tue, 14 Jan 2014 14:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 FL7ahKNLKCyc; Tue, 14 Jan 2014 14:46:30 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id B44B91ADFF3; Tue, 14 Jan 2014 14:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2042; q=dns/txt; s=iport; t=1389739579; x=1390949179; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b+SywIMTAblM9fWu2hAcy5jAKn01lzQaY41AddoBwHw=; b=cOu1uNj5AxFHOfLYjoNWnyhK4w0jOorac2i426vRM9UorERgDlLV9WXA xIkEVty/4owA6YAy1Gw00wMRxrPMEGJkeGM/ThzPb0ghWPjyOfMr/ayYy vIpmSj/F4iiyhhVJT9PzfAVmBiRPCcehQqUEQgQOA5B/yZY9o+CLAihhy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAAq91VKQ/khR/2dsb2JhbABaDoJ9u32BGRZ0giUBAQEEODwEARALDgoJFgQLCQMCAQIBRQYBDAEFAgEBiADEHxePBweENwEDlDiDZpIVgW9/Pw X-IronPort-AV: E=Sophos;i="4.95,659,1384300800"; d="scan'208";a="3628620" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 14 Jan 2014 22:46:17 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0EMkHAi001167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 22:46:17 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0EMkFsF021730; Tue, 14 Jan 2014 22:46:15 GMT Message-ID: <52D5BE37.4070301@cisco.com> Date: Tue, 14 Jan 2014 22:46:15 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Wesley Eddy , l.wood@surrey.ac.uk, curtis@ipv6.occnc.com References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com>, <52D58168.9060800@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> <52D5B524.5080408@mti-systems.com> In-Reply-To: <52D5B524.5080408@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 22:46:32 -0000 On 14/01/2014 22:07, Wesley Eddy wrote: > On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: >> I don't think sayng 'oh, that error source is no longer a problem' disproves >> Stone's overall point about undetected errors, though the >> examples he uses from the technology of the day are necessarily >> dated. Dismissing the overall point because the examples use obsolete >> technology is throwing the baby out with the bathwater; a host-to-host >> error check catches things that intermediate checks cannot. >> >> Measuring error rates across end-to-end Internet traffic is something that has >> not received much attention , as error detection is not >> instrumented well - hence citing Stone's published work, in the absence >> of awareness of anything newer (and as high profile/immediately recognisable >> as sigcomm) in the area. >> > > +1 ... the message in the paper is applicable to layered systems > and internetworks in general. Changes in the link technology > since then don't invalidate it, especially since we know that > the technology not only changes rapidly, but also is always > growing in diverse directions, such that there things almost > universally true today may be turned on their heads tomorrow. > > Designs for stacking layers need to follow solid general > principles in order to be robust to changes (above and below). > Note that it is not only the link layer technology that has moved on, the signal integrity of the h/w at all stages of the design and implementation process has moved on. Can we agree that the statistics in the paper are discredited? If not, why not? What is the error rate in modern h/w and network systems? Is this significant in the application under consideration? Finally if we are really concerned that we do actually need a c/s (I am not in tunnel applications) why are we still happy to use what is frankly a pathetic check in modern terms? Why for example are we not moving to something like the Fletcher 64 bit c/s? Stewart From l.wood@surrey.ac.uk Tue Jan 14 15:05:58 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBBF1AE2D2; Tue, 14 Jan 2014 15:05: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 xqvsxLNQq3Rn; Tue, 14 Jan 2014 15:05:56 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.161]) by ietfa.amsl.com (Postfix) with ESMTP id 58F8E1AE2B1; Tue, 14 Jan 2014 15:05:55 -0800 (PST) Received: from [195.245.230.131:34421] by server-1.bemta-3.messagelabs.com id 15/81-29598-5C2C5D25; Tue, 14 Jan 2014 23:05:41 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-78.messagelabs.com!1389740738!32661185!3 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10751 invoked from network); 14 Jan 2014 23:05:41 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-12.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 14 Jan 2014 23:05:41 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Tue, 14 Jan 2014 23:05:14 +0000 From: To: , , Date: Tue, 14 Jan 2014 23:05:14 +0000 Thread-Topic: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) Thread-Index: Ac8RenDjEgxt8NsvTwOY15/OAFCPrwAAX68d Message-ID: <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com>, <52D58168.9060800@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> <52D5B524.5080408@mti-systems.com>,<52D5BE37.4070301@cisco.com> In-Reply-To: <52D5BE37.4070301@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: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 23:05:58 -0000 Stewart, your 'I'm not in tunnel applications' suggests you've misunderstood the argument here. The point is not to protect the tunnel traffic (which can quite happily checksum itself), it is to protect everything else on the network from misdelivery. It's not the tunnel application, it's every application sharing the internet with the tunnel which has UDP checksums turned off. See all of RFC 6936 section 3.1. Tunnel is fine, sideeffects of misdelivery do not affect tunnel. And in IPv4 and IPv6, the pseudo-header checksum built into TCP and UDP is all we have. IPv6 deliberately copied v4 here. > What is the error rate in modern h/w and network systems? No-one measures end-to-end misdelivery. No-one knows. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: 14 January 2014 22:46 To: Wesley Eddy; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvw= g@ietf.org; jnc@mit.edu; lisp@ietf.org Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-= in-udp draft (was: RE: Milestones changed for tsvwg WG)) On 14/01/2014 22:07, Wesley Eddy wrote: > On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: >> I don't think sayng 'oh, that error source is no longer a problem' dispr= oves >> Stone's overall point about undetected errors, though the >> examples he uses from the technology of the day are necessarily >> dated. Dismissing the overall point because the examples use obsolete >> technology is throwing the baby out with the bathwater; a host-to-host >> error check catches things that intermediate checks cannot. >> >> Measuring error rates across end-to-end Internet traffic is something t= hat has >> not received much attention , as error detection is not >> instrumented well - hence citing Stone's published work, in the absence >> of awareness of anything newer (and as high profile/immediately recognis= able >> as sigcomm) in the area. >> > > +1 ... the message in the paper is applicable to layered systems > and internetworks in general. Changes in the link technology > since then don't invalidate it, especially since we know that > the technology not only changes rapidly, but also is always > growing in diverse directions, such that there things almost > universally true today may be turned on their heads tomorrow. > > Designs for stacking layers need to follow solid general > principles in order to be robust to changes (above and below). > Note that it is not only the link layer technology that has moved on, the signal integrity of the h/w at all stages of the design and implementation process has moved on. Can we agree that the statistics in the paper are discredited? If not, why not? What is the error rate in modern h/w and network systems? Is this significant in the application under consideration? Finally if we are really concerned that we do actually need a c/s (I am not in tunnel applications) why are we still happy to use what is frankly a pathetic check in modern terms? Why for example are we not moving to something like the Fletcher 64 bit c/s? Stewart= From l.wood@surrey.ac.uk Tue Jan 14 21:21:44 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A249E1AE2ED for ; Tue, 14 Jan 2014 21:21:44 -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 Re1ic0Jgg9gF for ; Tue, 14 Jan 2014 21:21:41 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4A75A1AE2BE for ; Tue, 14 Jan 2014 21:21:41 -0800 (PST) Received: from [195.245.231.67:43619] by server-6.bemta-5.messagelabs.com id E9/73-16310-8DA16D25; Wed, 15 Jan 2014 05:21:28 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-6.tower-82.messagelabs.com!1389763287!33356230!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19034 invoked from network); 15 Jan 2014 05:21:27 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-6.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 15 Jan 2014 05:21:27 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 15 Jan 2014 05:21:27 +0000 From: To: Date: Wed, 15 Jan 2014 05:20:27 +0000 Thread-Topic: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) Thread-Index: Ac8RpAQNDX8cAMV9TnqV5Ulgc44euAADXwfJ Message-ID: <290E20B455C66743BE178C5C84F1240847E63346C7@EXMB01CMS.surrey.ac.uk> References: Your message of "Tue, 14 Jan 2014 23:05:14 +0000." <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk>, <201401150343.s0F3hqwR007521@maildrop2.v6ds.occnc.com> In-Reply-To: <201401150343.s0F3hqwR007521@maildrop2.v6ds.occnc.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: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, stbryant@cisco.com Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 05:21:44 -0000 That's robustness _for the tunnelled traffic_. Not for anything else sharing the network - that hasn't been instrumented a= nd measured. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 15 January 2014 03:43 To: Wood L Dr (Electronic Eng) Cc: stbryant@cisco.com; wes@mti-systems.com; curtis@ipv6.occnc.com; gorry@e= rg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvwg@ietf.org;= jnc@mit.edu; lisp@ietf.org Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-= in-udp draft (was: RE: Milestones changed for tsvwg WG)) Lloyd, The part about RFC 6936 section 3.1 most relevant might be: There is extensive experience with deployments using tunnel protocols in well-managed networks (e.g., corporate networks and service provider core networks). This has shown the robustness of methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS that do not employ a transport protocol checksum and that have not specified mechanisms to protect from corruption of the unprotected headers (such as the VPN Identifier in MPLS). Reasons for the robustness may include: If the rate of undetected modified packets is extremely low in "well-managed networks", as we beleive is the case, then UDP checksums won't change the situration much. So why *not* make them optional if experience has shown they are not needed in the types of deployments we are talking about. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > > Stewart, > > your 'I'm not in tunnel applications' suggests you've misunderstood > the argument here. The point is not to protect the tunnel traffic > (which can quite happily checksum itself), it is to protect everything > else on the network from misdelivery. It's not the tunnel application, > it's every application sharing the internet with the tunnel which > has UDP checksums turned off. See all of RFC 6936 section 3.1. > Tunnel is fine, sideeffects of misdelivery do not affect tunnel. > > And in IPv4 and IPv6, the pseudo-header checksum built into > TCP and UDP is all we have. IPv6 deliberately copied v4 here. > > > What is the error rate in modern h/w and network systems? > > No-one measures end-to-end misdelivery. No-one knows. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: 14 January 2014 22:46 > To: Wesley Eddy; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; ts= vwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gr= e-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > > On 14/01/2014 22:07, Wesley Eddy wrote: > > On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: > >> I don't think sayng 'oh, that error source is no longer a problem' dis= proves > >> Stone's overall point about undetected errors, though the > >> examples he uses from the technology of the day are necessarily > >> dated. Dismissing the overall point because the examples use obsolete > >> technology is throwing the baby out with the bathwater; a host-to-host > >> error check catches things that intermediate checks cannot. > >> > >> Measuring error rates across end-to-end Internet traffic is something= that has > >> not received much attention , as error detection is not > >> instrumented well - hence citing Stone's published work, in the absen= ce > >> of awareness of anything newer (and as high profile/immediately recogn= isable > >> as sigcomm) in the area. > >> > > > > +1 ... the message in the paper is applicable to layered systems > > and internetworks in general. Changes in the link technology > > since then don't invalidate it, especially since we know that > > the technology not only changes rapidly, but also is always > > growing in diverse directions, such that there things almost > > universally true today may be turned on their heads tomorrow. > > > > Designs for stacking layers need to follow solid general > > principles in order to be robust to changes (above and below). > > > Note that it is not only the link layer technology that has moved on, > the signal integrity of the h/w at all stages of the design and > implementation process has moved on. > > Can we agree that the statistics in the paper are discredited? > > If not, why not? > > What is the error rate in modern h/w and network systems? > > Is this significant in the application under consideration? > > Finally if we are really concerned that we do actually need a > c/s (I am not in tunnel applications) why are we still happy to > use what is frankly a pathetic check in modern terms? Why > for example are we not moving to something like > the Fletcher 64 bit c/s? > > Stewart From stbryant@cisco.com Wed Jan 15 03:02:40 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503701AE343; Wed, 15 Jan 2014 03:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ht8tehBTC2RA; Wed, 15 Jan 2014 03:02:38 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id BEF471AE061; Wed, 15 Jan 2014 03:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12079; q=dns/txt; s=iport; t=1389783746; x=1390993346; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=ajcuDD8h7TBbs+OZZLo3Di3WoXtXcZR7hQVGnmaIaS4=; b=DyKNNHxL4EpK3YHIeZSImEcUoJB5eij8kG32fxysWZCWS/B1HzWJcSub FCqcrc8vQHBRfyymx57rKot3NN9faDuyMtynQ5EOf8OdQhoDwPhHJIk04 bt4To4k1KYX8TWBzncoBXo8NwzKzF4SjdE+L0npDCx2YAwhSmF1lYOg5s k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAO9p1lKQ/khM/2dsb2JhbABaDoI5RDhQuwKBFhZ0giUBAQEDAXQFBQsLEQQBAQEJGgsPAj4IBwwBBQIBAYd4CAgFxAAXjmUiBwaEMQSUOINmgTCLLYU4gW9/Pw X-IronPort-AV: E=Sophos;i="4.95,662,1384300800"; d="scan'208,217";a="3655006" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 15 Jan 2014 11:02:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0FB2Ns5010692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jan 2014 11:02:23 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0FB2K4m022493; Wed, 15 Jan 2014 11:02:21 GMT Message-ID: <52D66ABC.40606@cisco.com> Date: Wed, 15 Jan 2014 11:02:20 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, wes@mti-systems.com, curtis@ipv6.occnc.com References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com>, <52D58168.9060800@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> <52D5B524.5080408@mti-systems.com>, <52D5BE37.4070301@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> Content-Type: multipart/alternative; boundary="------------090007090508030409010602" Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 11:02:40 -0000 This is a multi-part message in MIME format. --------------090007090508030409010602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sent from my iPad > On 14 Jan 2014, at 23:05,"l.wood@surrey.ac.uk" wrote: > > Stewart, > > your 'I'm not in tunnel applications' suggests you've misunderstood > the argument here. The point is not to protect the tunnel traffic > (which can quite happily checksum itself), it is to protect everything > else on the network from misdelivery. It's not the tunnel application, > it's every application sharing the internet with the tunnel which > has UDP checksums turned off. See all of RFC 6936 section 3.1. > Tunnel is fine, sideeffects of misdelivery do not affect tunnel. > > And in IPv4 and IPv6, the pseudo-header checksum built into > TCP and UDP is all we have. IPv6 deliberately copied v4 here. Lloyd, With the significant improvements in h/w design methodology and the addressing of the s/w bugs that Curtis and I have been explaining to you, it would seem that the fundamental paper that underpins your argument is without credibility, and by your own admission below, it seems that there are no valid statistics for the current Internet to sustain your case. Unless you can show that the misdelivery rate from this effect exceeds the current rather high unwanted packet rate that hosts need to fend off, I cannot see any basis to maintain your assertion that the c/s is required in tunnel applications to protect the rest of the net. With regard to the IPv4, the IP checksum, which, in all router implementations I have seen, is checked at every hop and only incrementally changed, there is surely adequate protection against misdelivery to another endpoint. With regard to IPv6, I find it difficult to understand that the threat is of any significance given that absence of demand for the retrofit of a similar checksum in MPLS to protect PEs and prevent the incorrect egress of traffic. >> What is the error rate in modern h/w and network systems? > No-one measures end-to-end misdelivery. No-one knows. The upper bound is the packet loss rate less the congestion discard rate. Do we have a figure for that? Stewart > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: 14 January 2014 22:46 > To: Wesley Eddy; Wood L Dr (Electronic Eng);curtis@ipv6.occnc.com > Cc:gorry@erg.abdn.ac.uk;mpls@ietf.org;ietf@ietf.org;randy@psg.com;tsvwg@ietf.org;jnc@mit.edu;lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > >> On 14/01/2014 22:07, Wesley Eddy wrote: >>> On 1/14/2014 4:57 PM,l.wood@surrey.ac.uk wrote: >>> I don't think sayng 'oh, that error source is no longer a problem' disproves >>> Stone's overall point about undetected errors, though the >>> examples he uses from the technology of the day are necessarily >>> dated. Dismissing the overall point because the examples use obsolete >>> technology is throwing the baby out with the bathwater; a host-to-host >>> error check catches things that intermediate checks cannot. >>> >>> Measuring error rates across end-to-end Internet traffic is something that has >>> not received much attention , as error detection is not >>> instrumented well - hence citing Stone's published work, in the absence >>> of awareness of anything newer (and as high profile/immediately recognisable >>> as sigcomm) in the area. >> +1 ... the message in the paper is applicable to layered systems >> and internetworks in general. Changes in the link technology >> since then don't invalidate it, especially since we know that >> the technology not only changes rapidly, but also is always >> growing in diverse directions, such that there things almost >> universally true today may be turned on their heads tomorrow. >> >> Designs for stacking layers need to follow solid general >> principles in order to be robust to changes (above and below). > Note that it is not only the link layer technology that has moved on, > the signal integrity of the h/w at all stages of the design and > implementation process has moved on. > > Can we agree that the statistics in the paper are discredited? > > If not, why not? > > What is the error rate in modern h/w and network systems? > > Is this significant in the application under consideration? > > Finally if we are really concerned that we do actually need a > c/s (I am not in tunnel applications) why are we still happy to > use what is frankly a pathetic check in modern terms? Why > for example are we not moving to something like > the Fletcher 64 bit c/s? > > Stewart . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------090007090508030409010602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Sent from my iPad


On 14 Jan 2014, at 23:05, "l.wood@surrey.ac.uk" <l.wood@surrey.ac.uk> wrote:

Stewart,

your 'I'm not in tunnel applications' suggests you've misunderstood
the argument here. The point is not to protect the tunnel traffic
(which can quite happily checksum itself), it is to protect everything
else on the network from misdelivery. It's not the tunnel application,
it's every application sharing the internet with the tunnel which
has UDP checksums turned off. See all of  RFC 6936 section 3.1.
Tunnel is fine, sideeffects of misdelivery  do not affect tunnel.

And in IPv4 and IPv6, the pseudo-header checksum built into
TCP and UDP is all we have. IPv6 deliberately copied v4 here.

Lloyd,

With the significant improvements in h/w design methodology
and the addressing of the s/w bugs that Curtis and I have been
explaining to you, it would seem that the fundamental
paper that underpins your argument is without credibility, and
by your own admission below, it seems that there are no 
valid statistics for the current Internet to sustain your case.

Unless you can show that the misdelivery rate from this effect
exceeds the current rather high unwanted packet rate that
hosts need to fend off, I cannot see any basis to maintain 
your assertion that the c/s is required in tunnel applications 
to protect the rest of the net.

With regard to the IPv4, the IP checksum, which, in all router
implementations I have seen, is checked at every hop and
only incrementally changed, there is surely adequate 
protection against misdelivery to another endpoint.

With regard to IPv6, I find it difficult to understand that
the threat is of any significance given that absence of demand
for the retrofit of a similar checksum in MPLS to protect
PEs and prevent the incorrect egress of traffic.


What is the error rate in modern h/w and network systems?

No-one measures end-to-end misdelivery. No-one knows.

The upper bound is the packet loss rate less the congestion
discard rate. Do we have a figure for that?

Stewart


Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Stewart Bryant [stbryant@cisco.com]
Sent: 14 January 2014 22:46
To: Wesley Eddy; Wood L  Dr (Electronic Eng); curtis@ipv6.occnc.com
Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org
Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))


On 14/01/2014 22:07, Wesley Eddy wrote:

On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote:
I don't think sayng 'oh, that error source is no longer a problem' disproves
Stone's overall point about undetected errors, though the
examples he uses from the technology of the day are necessarily
dated. Dismissing the overall  point because the examples use obsolete
technology is throwing the baby out with the bathwater; a host-to-host
error check catches things that intermediate checks cannot.

Measuring error rates across end-to-end  Internet traffic is something that has
not received much attention , as error detection is not
instrumented well - hence citing Stone's published work,  in the absence
of awareness of anything newer (and as high profile/immediately recognisable
as sigcomm) in the area.

+1 ... the message in the paper is applicable to layered systems
and internetworks in general.  Changes in the link technology
since then don't invalidate it, especially since we know that
the technology not only changes rapidly, but also is always
growing in diverse directions, such that there things almost
universally true today may be turned on their heads tomorrow.

Designs for stacking layers need to follow solid general
principles in order to be robust to changes (above and below).

Note that it is not only the link layer technology that has moved on,
the signal integrity of the h/w at all stages of the design and
implementation process has moved on.

Can we agree that the statistics in the paper are discredited?

If not, why not?

What is the error rate in modern h/w and network systems?

Is this significant in the application under consideration?

Finally if we are really concerned that we do actually need a
c/s (I am not in tunnel applications) why are we still happy to
use what is frankly a pathetic check in modern terms? Why
for example are we not moving to something like
the  Fletcher 64 bit c/s?

Stewart

.




-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------090007090508030409010602-- From stbryant@cisco.com Wed Jan 15 03:31:34 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1E31AE35F; Wed, 15 Jan 2014 03:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 sUOUCgwX97T5; Wed, 15 Jan 2014 03:31:33 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4D41A1AE35E; Wed, 15 Jan 2014 03:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1164; q=dns/txt; s=iport; t=1389785481; x=1390995081; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=up0UvBh6yHD7U+HgE9fAGIoHx81lC42/wIrmS7ggc90=; b=bulh0VR/VA9c110y44jV9LGZvY7ZEJagtPMVi3LPwz7RekcalnbmeYVc p01qfycr18VloSHVRsIFpsFLqSF7l1UTHTXNSSAScADzqGJqXqOKFCWMa +jvFNgeUJV/ja3UkgcsN4wOaqkNLI9PFRcPsndwBEvPWRVY0swpz9U3Oo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAJNw1lKQ/khR/2dsb2JhbABagwu4fIMOgRcWdIIlAQEBBDgxAQ4BEAsYCRYECwkDAgECAUUGDQEHAQGIAMQRF48HB4Q3AQOYHpIVgW+BPg X-IronPort-AV: E=Sophos;i="4.95,662,1384300800"; d="scan'208";a="2986762" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 15 Jan 2014 11:31:20 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0FBVJnF019333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jan 2014 11:31:20 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0FBVIHK024290; Wed, 15 Jan 2014 11:31:18 GMT Message-ID: <52D67186.8080008@cisco.com> Date: Wed, 15 Jan 2014 11:31:18 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Randy Bush References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, tsvwg@ietf.org, jnc@mit.edu, curtis@ipv6.occnc.com Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 11:31:34 -0000 On 15/01/2014 11:08, Randy Bush wrote: > [ you insist on cc:ing me, so you get to endure my opinions ] > >> it seems that there are no valid statistics for the current Internet >> to sustain your case. > as we discussed privately, there seem to be no real measurements to > sustain any case. this is all conjecturbation. > > what i do not understand is why, given the lack of solid evidence that > we are in a safe space, you and others are not willing to spend a few > euro cents to have a reasonable level of assurance at this layer. > > randy Randy, It is not a few cents, it is likely the re-engineering of a lot of silicon. The reason that UDP is of interest is that the on path silicon knows how to process it, for example it knows how to to ECMP it. The reason that the UDP c/s is a problem for a tunneler is that it needs to have access to the whole pkt to calculate the c/s, but as you know the silicon optimised that access away a long time ago. The alternative would be UDP-lite, but the ability of on path silicon to process that as competently and as completely as it processes UDP is by no means clear. - Stewart From l.wood@surrey.ac.uk Wed Jan 15 04:00:52 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE881AE35A; Wed, 15 Jan 2014 04:00:52 -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 WXLAwN-sOj12; Wed, 15 Jan 2014 04:00:50 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1E10F1AE099; Wed, 15 Jan 2014 04:00:48 -0800 (PST) Received: from [85.158.136.51:52908] by server-4.bemta-5.messagelabs.com id 1A/93-26791-46876D25; Wed, 15 Jan 2014 12:00:36 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-10.tower-49.messagelabs.com!1389787235!29314441!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16991 invoked from network); 15 Jan 2014 12:00:35 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-10.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 15 Jan 2014 12:00:35 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 15 Jan 2014 12:00:35 +0000 From: To: , Date: Wed, 15 Jan 2014 11:57:18 +0000 Thread-Topic: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) Thread-Index: Ac8R5VMR2UUHMLGDRP+DhjlaFb7ztAAA52BF Message-ID: <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk> References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> ,<52D67186.8080008@cisco.com> In-Reply-To: <52D67186.8080008@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: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, tsvwg@ietf.org, wes@mti-systems.com, curtis@ipv6.occnc.com, jnc@mit.edu, ietf@ietf.org Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 12:00:52 -0000 you've got the perfect application to encourage UDP lite adoption and deplo= yment here. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: 15 January 2014 11:31 To: Randy Bush Cc: Wood L Dr (Electronic Eng); wes@mti-systems.com; curtis@ipv6.occnc.com= ; gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; jnc@m= it.edu; lisp@ietf.org Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-= in-udp draft (was: RE: Milestones changed for tsvwg WG)) On 15/01/2014 11:08, Randy Bush wrote: > [ you insist on cc:ing me, so you get to endure my opinions ] > >> it seems that there are no valid statistics for the current Internet >> to sustain your case. > as we discussed privately, there seem to be no real measurements to > sustain any case. this is all conjecturbation. > > what i do not understand is why, given the lack of solid evidence that > we are in a safe space, you and others are not willing to spend a few > euro cents to have a reasonable level of assurance at this layer. > > randy Randy, It is not a few cents, it is likely the re-engineering of a lot of silicon. The reason that UDP is of interest is that the on path silicon knows how to process it, for example it knows how to to ECMP it. The reason that the UDP c/s is a problem for a tunneler is that it needs to have access to the whole pkt to calculate the c/s, but as you know the silicon optimised that access away a long time ago. The alternative would be UDP-lite, but the ability of on path silicon to process that as competently and as completely as it processes UDP is by no means clear. - Stewart From curtis@ipv6.occnc.com Mon Jan 13 11:11:39 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAA41AE005; Mon, 13 Jan 2014 11:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 M6kaCCNyruBj; Mon, 13 Jan 2014 11:11:37 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id A52B91AE008; Mon, 13 Jan 2014 11:11:36 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0DJBC1o079251; Mon, 13 Jan 2014 14:11:12 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401131911.s0DJBC1o079251@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Mon, 13 Jan 2014 00:45:52 +0000." <290E20B455C66743BE178C5C84F1240847E63346BF@EXMB01CMS.surrey.ac.uk> Date: Mon, 13 Jan 2014 14:11:12 -0500 X-Mailman-Approved-At: Wed, 15 Jan 2014 08:15:42 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:11:39 -0000 One of the reasons that IPv6 (rfc2460) dropped the header checksum that was in IPv4 is that with link layers all doing FCS it served no purpose. For the same reason TCP and UDP checksums server no purpose. The link layer checksum fails and the packet is dropped. Since this is usually not at the last hop (often a local Ethernet) but instead in a WAN link, the packet never arrives at the destination for anything to count IP header or TCP or UDP checksum errors. Also all of the following handle both data integrity and congestion avoidance the same way: UDP over IP over Ethernet UDP over IP over MPLS over Ethernet UDP over IP over MPLS over UDP over IP over Ethernet s/Ethernet/{POS,GFP,etc}/ for all of the above s/^UDP over IP/PW/ for all of the above In all of the above cases data integrity is handled by the link layer. In all of the above cases congestion avoidance is handled by the application (or not at all). Whether MPLS is carried directly over a link layer or over UDP/IP over a link layer makes no difference. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346BF@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > Really, you'd want to expose the pseudoheader check at endhosts; a well-instrumented Linux box could tell you a lot > about checksum failures. > > But in this case, a router would be decapping UDP/MPLS tunnels as an endpoint, so could report on checksum failures - > if the checksum wasn't zero. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Dino Farinacci [farinacci@gmail.com] > Sent: 12 January 2014 21:37 > To: Wood L Dr (Electronic Eng) > Cc: ; ; gorry@erg.abdn.ac.uk; lisp@ietf.org; david.black@emc.com; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; ietf@ietf.org > Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) > > > Do any routers count TCP/UDP checksum failures, much less > > expose the count via SNMP? > > Typically they do but only for packets destined to them. Much like hosts would check the header checksum. > > Dino > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gorry@erg.abdn.ac.uk Mon Jan 13 12:32:00 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0031AE000; Mon, 13 Jan 2014 12:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 DqlW6hSFAr4Q; Mon, 13 Jan 2014 12:31:56 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB0B1AE1A0; Mon, 13 Jan 2014 12:31:56 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8F1972B41C8; Mon, 13 Jan 2014 20:31:43 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 13 Jan 2014 20:31:43 -0000 Message-ID: In-Reply-To: <201401131911.s0DJBC1o079251@maildrop2.v6ds.occnc.com> References: <201401131911.s0DJBC1o079251@maildrop2.v6ds.occnc.com> Date: Mon, 13 Jan 2014 20:31:43 -0000 From: gorry@erg.abdn.ac.uk To: curtis@ipv6.occnc.com User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Wed, 15 Jan 2014 08:15:41 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, ietf@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 20:32:00 -0000 > > One of the reasons that IPv6 (rfc2460) dropped the header checksum > that was in IPv4 is that with link layers all doing FCS it served no > purpose. > For the same reason TCP and UDP checksums server no purpose. > That's not what I understood, it is needed for endpoint delivery verification. But in this case, TCP & UDP checksums incorporate the IP address info in the pseudo header, and this was thought sufficient. > The link layer checksum fails and the packet is dropped. Since this > is usually not at the last hop (often a local Ethernet) but instead in > a WAN link, the packet never arrives at the destination for anything > to count IP header or TCP or UDP checksum errors. > Again, that presumes that everything above the link works flawlessly, which isn't always the case. > Also all of the following handle both data integrity and congestion > avoidance the same way: > > UDP over IP over Ethernet > UDP over IP over MPLS over Ethernet > UDP over IP over MPLS over UDP over IP over Ethernet > s/Ethernet/{POS,GFP,etc}/ for all of the above > s/^UDP over IP/PW/ for all of the above > > In all of the above cases data integrity is handled by the link layer. > In all of the above cases congestion avoidance is handled by the > application (or not at all). Whether MPLS is carried directly over a > link layer or over UDP/IP over a link layer makes no difference. > RFC 6936 section 3.1 says more about what happens when packets happen to be mis-delivered to the wrong host or socket. > Curtis > Gorry > In message > <290E20B455C66743BE178C5C84F1240847E63346BF@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > >> Really, you'd want to expose the pseudoheader check at endhosts; a >> well-instrumented Linux box could tell you a lot >> about checksum failures. >> >> But in this case, a router would be decapping UDP/MPLS tunnels as an >> endpoint, so could report on checksum failures - >> if the checksum wasn't zero. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Dino Farinacci [farinacci@gmail.com] >> Sent: 12 January 2014 21:37 >> To: Wood L Dr (Electronic Eng) >> Cc: ; ; gorry@erg.abdn.ac.uk; >> lisp@ietf.org; david.black@emc.com; randy@psg.com; tsvwg@ietf.org; >> jnc@mit.edu; ietf@ietf.org >> Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp >> draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) >> >> > Do any routers count TCP/UDP checksum failures, much less >> > expose the count via SNMP? >> >> Typically they do but only for packets destined to them. Much like hosts >> would check the header checksum. >> >> Dino >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From curtis@ipv6.occnc.com Tue Jan 14 07:51:17 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1BE1AE09C; Tue, 14 Jan 2014 07:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 NTFsiqOmpGvp; Tue, 14 Jan 2014 07:51:14 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 395E81AE0DF; Tue, 14 Jan 2014 07:51:14 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0EFojHp098066; Tue, 14 Jan 2014 10:50:46 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401141550.s0EFojHp098066@maildrop2.v6ds.occnc.com> To: mark.tinka@seacom.mu From: Curtis Villamizar In-reply-to: Your message of "Sun, 12 Jan 2014 21:04:40 +0200." <201401122104.44370.mark.tinka@seacom.mu> Date: Tue, 14 Jan 2014 10:50:45 -0500 X-Mailman-Approved-At: Wed, 15 Jan 2014 08:15:43 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, curtis@ipv6.occnc.com Subject: Re: [lisp] OT was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:51:17 -0000 In message <201401122104.44370.mark.tinka@seacom.mu> Mark Tinka writes: > On Sunday, January 12, 2014 08:37:16 PM Curtis Villamizar=20 > wrote: > > > Perhaps if you actully worked for a company that made > > line cards you would not make the above statement. > > I work for an operator that pays real money to deploy and=20 > use those line cards, and I make it my business to know what=20 > I'm paying for. > > > Many of the big router vendors use the same TCAM hardware > > for MPLS lookups as they do for IP lookups. Doing the > > lookup is not the rate limiting factor even in hardware > > that has an ILM SRAM table and some form of radix based > > lookup. All of the hardwre I've seen in the last 15 > > years or so forwards MPLS and IP at the same rate. > > Which was exactly my point - unless you somehow missed that. What you said was "Current-generation ASIC's have no problem forwarding MPLS frames at wire rate". Since you didn't mention IP packets I assumed you were making the 20 year old argument that MPLS forwarding was faster than IP. > > ... > > Except IPv6 before they decided to waste the lower half > > of the address space with 40 quintilion host in a > > bridged subnet and you really did have to look at the > > whole 128 bits. > > It is no secret that forwarding of IPv6 packets on some=20 > vendor equipment is about half the rate of IPv4 or MPLS. But=20 > then again, because MPLS control planes are IPv4-driven=20 > today, I'm hoping I didn't have to be explicit about not=20 > including IPv6 in that group, on this list. None of the equipment I have worked on (a while back) or the chips we evaluated recently had such a problem for IPv6 using only the top 64 bits for forwarding. An argument was made in the early 2000s (by me and others) that if we allocated global routes only from the top 64 bits all equipment at that time could forward at essentially the same rate as for IPv4. The reaction from the IPv6 community was to completely throw away the bottom half of the address and make it the host part. There are chips for which looking at a 32 bit prefix or a 64 bit prefix is done within the same pipeline and therefore takes the same amount of time. Other chips which parallelize packet handling budget enough microengines to get the job done (only a part of which is the MPLS ILM or IP destination lookup). > > Back when forwarding was done in > > software (circa 1995) your statement would have been > > true if MPLS preceeded forwarding ASICs which it did > > not. > > You might not know that line cards from C like the LSP=20 > (Label Switch Processor) and much of the PFE from J's PTX=20 > are forwarding engines that have been made cheaper by=20 > reducing the IP FIB on the assumption that all traffic will=20 > be carried in MPLS. This is, obviously, an assumption I do=20 > not support because: Those line cards (and designs I was recently involved in) assume what has historically been called a BGP-free core. Only the IGP routes are carried in the core. BGP is mapped onto the IGP routes. MPLS carries traffic across the core. The core has no BGP routes and therefore needs a lot fewer entries and the ILM can be put into SRAM rather than use a TCAM and only a small set of IP routes needs to be supported. That is done to eliminate a need for large external DRAM or TCAM which itself and the SERDES needed to go off chip produces heat and requires power, board space, and cooling and therefore reduces density. Putting more simple filters in the core also helps increase density. It is more a power to operate and floor space per Gb/s issue. For the most part IP/MPLS transport equipment seems to be going this way, though some people are stuck on MPLS-TP and trying to build a L2 overlay. If you go back to before 2000 at least one provider built a BGP-free core over Frame Relay, but FR itself soon died and the overlay didn't scale well. Some providers wanted to do this over MPLS but the RSVP-TE restoration times were too long and the fallback to IP routing was still needed to make up for that. > - I run IPv6 natively, and at the moment, there are > no production-grade IPv6 control planes for MPLS. > > - It assumes providers will run 6PE (in which case, > IPv6 traffic enjoys MPLS and IPv6 wire rate > forwarding speeds). > > I do not buy such line cards because for anyone running=20 > native IPv6, you could potentially run out of FIB slots to=20 > host IPv6 routes. Unless you run a BGP-free core, whether IPv4 or IPv6. Then you have plenty of FIB space. > That is why I say MPLS has allowed vendors to put out=20 > cheaper line cards compared to the costs of those which have=20 > large IPv4/IPv6 scale. Because MPLS forwarding is so=20 > mainstream, there is no additional cost associated with=20 > forwarding rates similar to IPv4. So much of the cost of=20 > line cards is in QoS queues and routing FIB slots (and MPLS- > biased line cards are stripped of that, hence making them=20 > cheaper). You put forwarding at full rate and cheaper line cards in the same paragraph with no mention of smaller FIB size due to eliminating the BGP routes. > > Also the statement "Current-generation ASIC's have no > > problem forwarding MPLS frames at wire rate" is not true > > for most (or all) hardware with 40 byte payloads (even > > with plus 4 with TCP SACK plus 4 if MPLS) and 100 Gb/s > > interfaces. It is true for "average packet size" > > traffic and on most hardware only true if bursts of 40 > > byte packets are very limited in duration. > > C'mon, Curtis. Everybody knows this already. Moreover, real=20 > world IP traffic is not all 40 bytes. > > If operators have doubts about what forwarding engines can=20 > do below 128 bytes, that is what PoC labs are for before you=20 > buy. And even then, several operators accept the=20 > restrictions up to a certain point, because the lab and real=20 > life vary significantly. > > Mark. OK ... so this is all interesting but I've lost the connection between this discussion and draft-ietf-mpls-in-udp. Hence the OT in the subject. Would you please remind me what that connection was. Curtis From mark.tinka@seacom.mu Tue Jan 14 08:10:33 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED6D1AE125; Tue, 14 Jan 2014 08:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_82=0.6] autolearn=no 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 VqBBn0Qgq4sF; Tue, 14 Jan 2014 08:10:28 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id A97D51AE10D; Tue, 14 Jan 2014 08:10:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W36Ye-0001n8-K5; Tue, 14 Jan 2014 18:09:40 +0200 From: Mark Tinka Organization: SEACOM To: curtis@ipv6.occnc.com Date: Tue, 14 Jan 2014 18:09:36 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <201401141550.s0EFojHp098066@maildrop2.v6ds.occnc.com> In-Reply-To: <201401141550.s0EFojHp098066@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2936459.czVGkbzpV0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401141809.40038.mark.tinka@seacom.mu> X-Mailman-Approved-At: Wed, 15 Jan 2014 08:15:42 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [lisp] OT was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:10:35 -0000 --nextPart2936459.czVGkbzpV0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday, January 14, 2014 05:50:45 PM Curtis Villamizar=20 wrote: > None of the equipment I have worked on (a while back) or > the chips we evaluated recently had such a problem for > IPv6 using only the top 64 bits for forwarding. An > argument was made in the early 2000s (by me and others) > that if we allocated global routes only from the top 64 > bits all equipment at that time could forward at > essentially the same rate as for IPv4. The reaction > from the IPv6 community was to completely throw away the > bottom half of the address and make it the host part. Agree. > There are chips for which looking at a 32 bit prefix or a > 64 bit prefix is done within the same pipeline and > therefore takes the same amount of time. Other chips > which parallelize packet handling budget enough > microengines to get the job done (only a part of which > is the MPLS ILM or IP destination lookup). Agree. > Those line cards (and designs I was recently involved in) > assume what has historically been called a BGP-free > core. Only the IGP routes are carried in the core. BGP > is mapped onto the IGP routes. MPLS carries traffic > across the core. The core has no BGP routes and > therefore needs a lot fewer entries and the ILM can be > put into SRAM rather than use a TCAM and only a small > set of IP routes needs to be supported. Yes, but a "proper" BGP-free core is only true for IPv4. If you are running a native IPv6 backbone, you can't support=20 a BGP-free core for IPv6 (I'll just call it a BGPv6-free=20 core, for typing brevity). The only way you can have a BGPv6-free core is to do 6PE,=20 and like I mentioned before, I don't like tunneled IPv6 (but=20 lots of other providers do it, good for them). > That is done to eliminate a need for large external DRAM > or TCAM which itself and the SERDES needed to go off > chip produces heat and requires power, board space, and > cooling and therefore reduces density. Putting more > simple filters in the core also helps increase density. > It is more a power to operate and floor space per Gb/s > issue. All good and well, but where do my native BGPv6 routes go? > For the most part IP/MPLS transport equipment seems to be > going this way, though some people are stuck on MPLS-TP > and trying to build a L2 overlay. I think MPLS-TP is a way for the incumbents to migrate to=20 Ethernet and still keep their ITU point-to-point-everything=20 way of life that they know and love, but let's not digress=20 :-)... C have had the LSP forwarding engine for about three years=20 now. I've never once considered buying it (and I always=20 support new tech.), and most of my friends that I know=20 closely haven't either. I have no doubt that some operators=20 have bought it, but I have no empirical data to know how=20 quickly it's flying off the shelves. J's PTX and C's new NCS will continue this trend, but=20 without implementing IPv6 control planes for MPLS (and the=20 requisite data plane support), those of us that run native=20 IPv6 will never have a BGPv6-free core. So I can only afford line cards and forwarding engines that=20 don't skimp on FIB, so I can sleep at night knowing my IPv6=20 network won't fall over. > If you go back to before 2000 at least one provider built > a BGP-free core over Frame Relay, but FR itself soon > died and the overlay didn't scale well. Some providers > wanted to do this over MPLS but the RSVP-TE restoration > times were too long and the fallback to IP routing was > still needed to make up for that. Was before my time, but I can appreciate that :-). > Unless you run a BGP-free core, whether IPv4 or IPv6.=20 > Then you have plenty of FIB space. Again, without 6PE, no-can-do for BGPv6. > You put forwarding at full rate and cheaper line cards in > the same paragraph with no mention of smaller FIB size > due to eliminating the BGP routes. Because without FIB's, where will the native BGPv6 routes=20 go? > OK ... so this is all interesting but I've lost the > connection between this discussion and > draft-ietf-mpls-in-udp. Hence the OT in the subject.=20 > Would you please remind me what that connection was. I agree, this is quickly getting off topic, but the source=20 was: ***** On Sunday, January 12, 2014 04:59:41 AM l.wood@surrey.ac.uk=20 wrote: > 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. Right, which is probably why routers today can count badly=20 checksum'ed Ethernet frames, but don't have the equivalent=20 for MPLS. > I'm sorry, when was MPLS cheap? Current-generation ASIC's have no problem forwarding MPLS=20 frames at wire rate. One could go so far as to say that MPLS=20 has allowed vendors to make cheaper line cards also because=20 IP FIB's and traffic queues can be scaled down dramatically=20 (not that I'd every buy such line cards, but...). Mark. ***** Cheers, Mark. --nextPart2936459.czVGkbzpV0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS1WFDAAoJEGcZuYTeKm+G12UP/0I3a8sOQVTRN8GjYlxB/IgO qaxNAchFW+dmsGEMWa5WC2V3LRsmBpUQwREBm8E6ADbULv2CdP7ixqnIVgSirESR 6JSX0MkRsiqW34VaOEa7u77c4+6iIuMS/O7lskPiKYjBZdjg3up2Xd5xlDUe+1OH 8N0MDRooTem/2HI3BFxeFD6Y5ulVNVTVahAA/Qj4juSR9OicRjWTAiBiWBowNxyP sasLrnjZZHtD5rBYPSzGlEwaOcx3kfBaop2KBETIfPWNtJyRwkdA01Ad7O9M27kv 0lzt/EJESlL0wueAlKP6kjhNPMm6C8ZlVwPW6LiU+C24BWrP0e2tdLTAN0mSzqVy ChLQERyaO0m1qOHRa+VZ1zZv/GwzRNjU4nEZqKsVaqhOSKpYT6/fI+fKGA8aRjGS hChWOmui0lI/4WsJ9otSNxq+/3TCXcP3ySVHNifik1a+6mU24GGkiWJpAGP1/CPT javmyEYsSRa7OGoSw34W9+SLhDBh99960fLhWaLIo3LMhEss48NZQJK7ybALh2DE wzItalLP6MSJhGVhKU16hSWZsCys7kGh7f16g3EbLwH27MzXIa1eDsIQmOCSyWd1 j7NXyEzOHUHrp18tFlbGeOwYGE9iFPXzLFIEedGFYoLMozpJ/gz1zHpmTgxFoJaR v6AhFuv/Q8w8gax0TQjA =uf6R -----END PGP SIGNATURE----- --nextPart2936459.czVGkbzpV0-- From curtis@ipv6.occnc.com Tue Jan 14 09:06:40 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D00F1AE129; Tue, 14 Jan 2014 09:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 FV6exKOHUBXZ; Tue, 14 Jan 2014 09:06:37 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id CDDC21AE0FF; Tue, 14 Jan 2014 09:06:36 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0EH6Fbo099057; Tue, 14 Jan 2014 12:06:15 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Sun, 12 Jan 2014 21:22:58 +0000." <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> Date: Tue, 14 Jan 2014 12:06:15 -0500 X-Mailman-Approved-At: Wed, 15 Jan 2014 08:15:43 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, curtis@ipv6.occnc.com Subject: [lisp] OT (was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:06:40 -0000 Lloyd, Maybe you should reread the paper too before citing it as evidence. Check the date on it. Check the cited causes of errors. Packet traces from 1998 and 1999 are prehaps not so relevante today, particularly wrt error rates due to hosts, router memories, and link error rates. Look at the cited caused of errors and realize that many things have changed. The largest single error in the paper (paerhaps as high as 99.9% of the errors) was the ACK-of-FIN bug in Windows NT. They may have fixed that by now. Other large causes were host hardware and host software bugs (sent bad data in the first place). One fifth of campus errors were caused by two hosts. This is cited as a bug in Mac OS on Powermac 8100, fixed at the time of publication. A lot of host software errors are discussed, where the checksums are sent bad and therefore will pass any router link FCS. Sending host hardware errors were thought to be in large part caused by no data integrity check on host DMA transfers. I think progress has been made on that front. You can check PCIe. It has a 32bit CRC per lane in the link layer and retransmits on error. Router memory errors was thought to play a large role in the non-host part of the error rate in the paper. Routers use ECC now. Going that far back they didn't always have parity RAM (and sometimes ran parity disabled to avoid parity error reloads). VJHC software errors? Anyone still use VJHC? Those errors should be gone. IP over HDLC over T1 missed a few errors at the link layer in those days. That could be true and occurances dependent on the providers. In the paper that was thought to be a very small contributor. Both HDLC and PPP had an option for 16 bit or 32 bit FCS. Often 16 bit was used. Some HDLC equipment could be and was configured to count errors and send the packets on their way on the assumption that it was better to count errors and deliver bad packets rather than deliver no packet. Perhaps also to hide packet loss. Today all of the link layers in use have 32 bit FCS and count and toss errored packets. In most equipment all of the memories have ECC and all of the buses ECC or FCS if serialized. It is now 14 years since that paper was published in Signcomm and 16 years since some of the observations. Things have changed. Nice bit of nostangia but that paper may no longer be relevant. Curtis reference - http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf In message <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > Curtis > > I suggest reading Stone's work, particularly > ''When The CRC and TCP Checksum Disagree' > for discussion of corruption. > > Particularly its conclusions: 'In the internet, that means > we are sending large volumes of incorrect data without > anyone noticing'. > > The Layer-2 check is per link, not end-to-end. That matters. > > The MPLS assumption is that it crosses a link with a frame > checksum. Putting MPLS over UDP breaks that assumption. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 12 January 2014 18:09 > To: Wood L Dr (Electronic Eng) > Cc: adrian@olddog.co.uk; randy@psg.com; 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) > > In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > 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. > > That UDP would be running over IP over Ethernet or POS or GFP or ... > > There is no layer-2 currently in use that does not have a robust FCS, > generally a 32 FCS and therefore the MPLS assumption of checking at a > lower layer is still valid. > > Curtis > > > > "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 From curtis@ipv6.occnc.com Tue Jan 14 19:30:06 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94431AE261; Tue, 14 Jan 2014 19:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 PEO0_74N9T4p; Tue, 14 Jan 2014 19:30:02 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 37E571AE25B; Tue, 14 Jan 2014 19:30:01 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F3TX9p007369; Tue, 14 Jan 2014 22:29:34 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401150329.s0F3TX9p007369@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 21:57:20 +0000." <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> Date: Tue, 14 Jan 2014 22:29:33 -0500 X-Mailman-Approved-At: Wed, 15 Jan 2014 08:15:43 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, stbryant@cisco.com, jnc@mit.edu, curtis@ipv6.occnc.com Subject: Re: [lisp] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 03:30:07 -0000 Lloyd, At this point in time those who would know what error rates are for current technologies are likely to be people who work for transport vendors, router vendors, and operators and those are the type of people you have been arguing with. You don't really think that no one has thought about improving error rates in 15 years, right? That said, if an academic can do a direct measurement *today* the results might add something to the discussion. A paper that old adds little for this particualar topic because too much has changed. I anyone thought today's rates of undetectable errors were a problem they would be adding something more robust such as a 64 bit CRC to important link layers. [Some bandwidth would be chewed up. TCP ACK packets would get bigger. Mpps rates for "small packets" would be easier to hit. What's not to like. :-) ] Curtis In message <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: I don't think sayng 'oh, that error source is no longer a problem' disproves Stone's overall point about undetected errors, though the examples he uses from the technology of the day are necessarily dated. Dismissing the overall point because the examples use obsolete technology is throwing the baby out with the bathwater; a host-to-host error check catches things that intermediate checks cannot. Measuring error rates across end-to-end Internet traffic is something that has not received much attention , as error detection is not instrumented well - hence citing Stone's published work, in the absence of awareness of anything newer (and as high profile/immediately recognisable as sigcomm) in the area. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: 14 January 2014 18:26 To: curtis@ipv6.occnc.com; Wood L Dr (Electronic Eng) Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; lisp@ietf.org; david.black@emc.com; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu Subject: Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) I agree the paper is now obsolete. Stewart On 14/01/2014 17:06, Curtis Villamizar wrote: > Lloyd, > > Maybe you should reread the paper too before citing it as evidence. > Check the date on it. Check the cited causes of errors. > > Packet traces from 1998 and 1999 are prehaps not so relevante today, > particularly wrt error rates due to hosts, router memories, and link > error rates. Look at the cited caused of errors and realize that many > things have changed. > > The largest single error in the paper (paerhaps as high as 99.9% of > the errors) was the ACK-of-FIN bug in Windows NT. They may have fixed > that by now. Other large causes were host hardware and host software > bugs (sent bad data in the first place). > > One fifth of campus errors were caused by two hosts. This is cited as > a bug in Mac OS on Powermac 8100, fixed at the time of publication. > > A lot of host software errors are discussed, where the checksums are > sent bad and therefore will pass any router link FCS. > > Sending host hardware errors were thought to be in large part caused > by no data integrity check on host DMA transfers. I think progress > has been made on that front. You can check PCIe. It has a 32bit CRC > per lane in the link layer and retransmits on error. > > Router memory errors was thought to play a large role in the non-host > part of the error rate in the paper. Routers use ECC now. Going that > far back they didn't always have parity RAM (and sometimes ran parity > disabled to avoid parity error reloads). > > VJHC software errors? Anyone still use VJHC? Those errors should be > gone. > > IP over HDLC over T1 missed a few errors at the link layer in those > days. That could be true and occurances dependent on the providers. > In the paper that was thought to be a very small contributor. > > Both HDLC and PPP had an option for 16 bit or 32 bit FCS. Often 16 > bit was used. Some HDLC equipment could be and was configured to > count errors and send the packets on their way on the assumption that > it was better to count errors and deliver bad packets rather than > deliver no packet. Perhaps also to hide packet loss. Today all of > the link layers in use have 32 bit FCS and count and toss errored > packets. In most equipment all of the memories have ECC and all of > the buses ECC or FCS if serialized. > > It is now 14 years since that paper was published in Signcomm and 16 > years since some of the observations. Things have changed. Nice bit > of nostangia but that paper may no longer be relevant. > > Curtis > > reference - > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf > > In message <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: >> Curtis >> >> I suggest reading Stone's work, particularly >> ''When The CRC and TCP Checksum Disagree' >> for discussion of corruption. >> >> Particularly its conclusions: 'In the internet, that means >> we are sending large volumes of incorrect data without >> anyone noticing'. >> >> The Layer-2 check is per link, not end-to-end. That matters. >> >> The MPLS assumption is that it crosses a link with a frame >> checksum. Putting MPLS over UDP breaks that assumption. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Curtis Villamizar [curtis@ipv6.occnc.com] >> Sent: 12 January 2014 18:09 >> To: Wood L Dr (Electronic Eng) >> Cc: adrian@olddog.co.uk; randy@psg.com; 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) >> >> In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> >> l.wood@surrey.ac.uk writes: >> >>> 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. >> >> That UDP would be running over IP over Ethernet or POS or GFP or ... >> >> There is no layer-2 currently in use that does not have a robust FCS, >> generally a 32 FCS and therefore the MPLS assumption of checking at a >> lower layer is still valid. >> >> Curtis >> >> >>> "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 > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From curtis@ipv6.occnc.com Tue Jan 14 19:44:11 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60CC1AE1EF; Tue, 14 Jan 2014 19:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 K2fVlAnyRXIR; Tue, 14 Jan 2014 19:44:09 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 952DB1AE1E2; Tue, 14 Jan 2014 19:44:09 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F3hqwR007521; Tue, 14 Jan 2014 22:43:52 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401150343.s0F3hqwR007521@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 23:05:14 +0000." <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> Date: Tue, 14 Jan 2014 22:43:52 -0500 X-Mailman-Approved-At: Wed, 15 Jan 2014 08:15:43 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, stbryant@cisco.com, jnc@mit.edu, curtis@ipv6.occnc.com Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 03:44:12 -0000 Lloyd, The part about RFC 6936 section 3.1 most relevant might be: There is extensive experience with deployments using tunnel protocols in well-managed networks (e.g., corporate networks and service provider core networks). This has shown the robustness of methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS that do not employ a transport protocol checksum and that have not specified mechanisms to protect from corruption of the unprotected headers (such as the VPN Identifier in MPLS). Reasons for the robustness may include: If the rate of undetected modified packets is extremely low in "well-managed networks", as we beleive is the case, then UDP checksums won't change the situration much. So why *not* make them optional if experience has shown they are not needed in the types of deployments we are talking about. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > Stewart, > > your 'I'm not in tunnel applications' suggests you've misunderstood > the argument here. The point is not to protect the tunnel traffic > (which can quite happily checksum itself), it is to protect everything > else on the network from misdelivery. It's not the tunnel application, > it's every application sharing the internet with the tunnel which > has UDP checksums turned off. See all of RFC 6936 section 3.1. > Tunnel is fine, sideeffects of misdelivery do not affect tunnel. > > And in IPv4 and IPv6, the pseudo-header checksum built into > TCP and UDP is all we have. IPv6 deliberately copied v4 here. > > > What is the error rate in modern h/w and network systems? > > No-one measures end-to-end misdelivery. No-one knows. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: 14 January 2014 22:46 > To: Wesley Eddy; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > > On 14/01/2014 22:07, Wesley Eddy wrote: > > On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: > >> I don't think sayng 'oh, that error source is no longer a problem' disproves > >> Stone's overall point about undetected errors, though the > >> examples he uses from the technology of the day are necessarily > >> dated. Dismissing the overall point because the examples use obsolete > >> technology is throwing the baby out with the bathwater; a host-to-host > >> error check catches things that intermediate checks cannot. > >> > >> Measuring error rates across end-to-end Internet traffic is something that has > >> not received much attention , as error detection is not > >> instrumented well - hence citing Stone's published work, in the absence > >> of awareness of anything newer (and as high profile/immediately recognisable > >> as sigcomm) in the area. > >> > > > > +1 ... the message in the paper is applicable to layered systems > > and internetworks in general. Changes in the link technology > > since then don't invalidate it, especially since we know that > > the technology not only changes rapidly, but also is always > > growing in diverse directions, such that there things almost > > universally true today may be turned on their heads tomorrow. > > > > Designs for stacking layers need to follow solid general > > principles in order to be robust to changes (above and below). > > > Note that it is not only the link layer technology that has moved on, > the signal integrity of the h/w at all stages of the design and > implementation process has moved on. > > Can we agree that the statistics in the paper are discredited? > > If not, why not? > > What is the error rate in modern h/w and network systems? > > Is this significant in the application under consideration? > > Finally if we are really concerned that we do actually need a > c/s (I am not in tunnel applications) why are we still happy to > use what is frankly a pathetic check in modern terms? Why > for example are we not moving to something like > the Fletcher 64 bit c/s? > > Stewart From randy@psg.com Wed Jan 15 03:08:44 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF32C1AE34D; Wed, 15 Jan 2014 03:08:44 -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 L-R--m2BjUPl; Wed, 15 Jan 2014 03:08:43 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5FD1AE078; Wed, 15 Jan 2014 03:08:43 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W3OKV-0005Bp-1G; Wed, 15 Jan 2014 11:08:16 +0000 Date: Wed, 15 Jan 2014 17:08:09 +0600 Message-ID: From: Randy Bush To: Stewart Bryant In-Reply-To: <52D66ABC.40606@cisco.com> References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_Jan_15_17:08:04_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 15 Jan 2014 08:15:41 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, tsvwg@ietf.org, jnc@mit.edu, curtis@ipv6.occnc.com Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 11:08:45 -0000 X-List-Received-Date: Wed, 15 Jan 2014 11:08:45 -0000 --pgp-sign-Multipart_Wed_Jan_15_17:08:04_2014-1 Content-Type: text/plain; charset=US-ASCII [ you insist on cc:ing me, so you get to endure my opinions ] > it seems that there are no valid statistics for the current Internet > to sustain your case. as we discussed privately, there seem to be no real measurements to sustain any case. this is all conjecturbation. what i do not understand is why, given the lack of solid evidence that we are in a safe space, you and others are not willing to spend a few euro cents to have a reasonable level of assurance at this layer. randy --pgp-sign-Multipart_Wed_Jan_15_17:08:04_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJS1mwYAAoJEMzMBey4OgLt1G8H/1ADrpB+HoSbUN8FTgBHlpk2 GeozioIalHzyBniV8tmqiBFYHwJZC35ylMPig8bCFuVXLpaiYPCUMcQQDb5w9Ck9 OKHupmxO5AiIbPR0PaTLCYzCHU/jNmhz+xMfAarlf8eJ3Nl0p9SdsNVn21GV7i1V z3+OhlPPDojCxjjQj/9dUW6Cc1PKufrM9ius+eXGUO7iaWd34V5de2laJrM39lr6 yRtmQX9zdZKzfMqNztwAFOl5oK0696k2JlVQi5i2NcSRb6P/GrFZ4aFOgy+18yQ4 LB8gDRgaQ4IhhyVfPrZOZoL3Feukxm7cgRTnEHqJKz+0jhVzEIvmKNfDMe1A+m4= =4bC4 -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Jan_15_17:08:04_2014-1-- From Alexander.Vainshtein@ecitele.com Wed Jan 15 03:54:33 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68F01AE099; Wed, 15 Jan 2014 03:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 IOlBlzvmBw69; Wed, 15 Jan 2014 03:54:31 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id A4AF21AE085; Wed, 15 Jan 2014 03:54:30 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) with Microsoft SMTP Server (TLS) id 15.0.851.11; Wed, 15 Jan 2014 11:54:17 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Wed, 15 Jan 2014 11:54:17 +0000 From: Alexander Vainshtein To: "stbryant@cisco.com" Thread-Topic: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) Thread-Index: AQHPEeVeWllrh86W50KmWq92akl6n5qFqI4g Date: Wed, 15 Jan 2014 11:54:17 +0000 Message-ID: References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> <52D67186.8080008@cisco.com> In-Reply-To: <52D67186.8080008@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(252514010)(51704005)(13464003)(24454002)(199002)(189002)(377454003)(479174003)(77982001)(65816001)(74662001)(80022001)(66066001)(79102001)(74366001)(92566001)(74876001)(76786001)(76576001)(76796001)(74502001)(63696002)(47446002)(31966008)(59766001)(81686001)(74316001)(56776001)(87266001)(85852003)(69226001)(54356001)(85306002)(76482001)(87936001)(56816005)(90146001)(83072002)(2656002)(46102001)(47976001)(81816001)(15975445006)(81342001)(50986001)(74706001)(93136001)(53806001)(51856001)(80976001)(83322001)(4396001)(54316002)(19580395003)(93516001)(49866001)(81542001)(19580405001)(47736001)(33646001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB532; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:147.234.56.21; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-Mailman-Approved-At: Wed, 15 Jan 2014 08:15:41 -0800 Cc: "gorry@erg.abdn.ac.uk" , "mpls@ietf.org" , "ietf@ietf.org" , "tsvwg@ietf.org" , "wes@mti-systems.com" , Randy Bush , "jnc@mit.edu" , "lisp@ietf.org" Subject: Re: [lisp] [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 11:54:33 -0000 Stewart, and all, I fully agree that UDP checksums is not a real-life issue with the protocol= in question. They could probably help to check corrupted packets if corrup= tion happens when a packet passes thru a router (i.e. when the ingress data= link FCS has already been terminated and the egress data link FCS has not = been generated yet). But this is hopefully rare - and since MPLS does not c= are about it, why should the MPLS encapsulator care? I also do not think that congestion control is a serious issue for this pro= tocol, not in the least because the primary purpose of this protocol is ECM= P. But I would like to understand whether this protocol can really result in r= easonable distribution of traffic. "Reasonable" means that (a) there is suf= ficient entropy and (b) that the order in specific micro-flows is preserved= . The draft skips this issue (unless you consider a recommendation to use a= fixed randomly selected source port value if the tunnel does not need ECM= P a valid answer) . Any ideas as to how reasonable distribution of traffic can be achieved wit= h this protocol?=20 Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Wednesday, January 15, 2014 1:31 PM > To: Randy Bush > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; > wes@mti-systems.com; tsvwg@ietf.org; jnc@mit.edu > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gr= e-in- > udp draft (was: RE: Milestones changed for tsvwg WG)) >=20 > On 15/01/2014 11:08, Randy Bush wrote: > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > >> it seems that there are no valid statistics for the current Internet > >> to sustain your case. > > as we discussed privately, there seem to be no real measurements to > > sustain any case. this is all conjecturbation. > > > > what i do not understand is why, given the lack of solid evidence that > > we are in a safe space, you and others are not willing to spend a few > > euro cents to have a reasonable level of assurance at this layer. > > > > randy > Randy, >=20 > It is not a few cents, it is likely the re-engineering of a lot of silico= n. >=20 > The reason that UDP is of interest is that the on path silicon knows how = to > process it, for example it knows how to to ECMP it. >=20 > The reason that the UDP c/s is a problem for a tunneler is that it needs = to > have access to the whole pkt to calculate the c/s, but as you know the si= licon > optimised that access away a long time ago. >=20 > The alternative would be UDP-lite, but the ability of on path silicon to = process > that as competently and as completely as it processes UDP is by no means > clear. >=20 > - Stewart >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Wed Jan 15 08:58:22 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4031B1AE0D4; Wed, 15 Jan 2014 08:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 WGXl277OMqp3; Wed, 15 Jan 2014 08:58:19 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7AF1AE017; Wed, 15 Jan 2014 08:58:19 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FGvsQ9019368; Wed, 15 Jan 2014 11:57:54 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401151657.s0FGvsQ9019368@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 05:20:27 +0000." <290E20B455C66743BE178C5C84F1240847E63346C7@EXMB01CMS.surrey.ac.uk> Date: Wed, 15 Jan 2014 11:57:54 -0500 X-Mailman-Approved-At: Thu, 16 Jan 2014 09:08:24 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, curtis@ipv6.occnc.com, jnc@mit.edu, stbryant@cisco.com Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 16:58:22 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346C7@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > That's robustness _for the tunnelled traffic_. > > Not for anything else sharing the network - that hasn't been > instrumented and measured. > > Lloyd Wood > http://about.me/lloydwood The reason that MPLS and PWE3 are successfully deployed is that this traffic is carried over "well-managed networks" as RFC 6936 puts it. If a UDP and IP encapsulation is added, then nothing changes. If the UDP encapsulation occurs on a lower end router, it is likely that the whole packet is available on which to perform a checksum. On a really low end router the checksum is likely to be done in software. If it occurs on a high end router then the part of the hardware that can today modify checksums only, doesn't even have access to the packet to do a checksum and put it into the front of the packet. There are two reasons for this. 1. A lot of high end routers split off the top 128-256 bytes and send it to a decision engine which can call for header modifications. The rest of the packet takes another path and is later concatonated before sending out. This works fine for checksum modifications but does not work for creating a new checksum. 2. A lot of high end hardware, particularly hardware intended for high end enterprise and data centers, uses a technique called "cut-through". The first 128-256 bytes go to a decision engine and get processed before the packet has been entirely received. The decision and header modifications are done and if there is no standing output queue, the header starts going out before all of the packet has been received. This is done to reduce latency. In these implementations if the incoming FCS is bad, an outgoing runt packet occurs. In the second case the UDP header is sent before the bytes over which the UDP header is computed are received. That is a consequence of putting the UDP checksum before the data. L2 encapsulation put the FCS after the data for this reason. So what you are asking, a UDP checksum on a fresh new encapsulation is impossible for some hardware. [ps - thanks to an offline discussion with Joel Halpern for bringing this up.] Perhaps we need a new UDP with a robust FCS at the back of the packet, but without that making a UDP checksum manditory for MPLS over UDP is guarenteed to be ignored in some deployments and with no adverse consequences. Is that what we want? Perhaps there can be discussion added to the draft to indicate why a UDP checksum is desirable and why in some circumstances it may be impossible to generate or difficult to check. This along with a SHOULD use a UDP checksum might be the best course of action. Curtis > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 15 January 2014 03:43 > To: Wood L Dr (Electronic Eng) > Cc: stbryant@cisco.com; wes@mti-systems.com; curtis@ipv6.occnc.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > > Lloyd, > > The part about RFC 6936 section 3.1 most relevant might be: > > There is extensive experience with deployments using tunnel > protocols in well-managed networks (e.g., corporate networks and > service provider core networks). This has shown the robustness of > methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS > that do not employ a transport protocol checksum and that have not > specified mechanisms to protect from corruption of the unprotected > headers (such as the VPN Identifier in MPLS). Reasons for the > robustness may include: > > If the rate of undetected modified packets is extremely low in > "well-managed networks", as we beleive is the case, then UDP checksums > won't change the situration much. > > So why *not* make them optional if experience has shown they are not > needed in the types of deployments we are talking about. > > Curtis > > > In message <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > > Stewart, > > > > your 'I'm not in tunnel applications' suggests you've misunderstood > > the argument here. The point is not to protect the tunnel traffic > > (which can quite happily checksum itself), it is to protect everything > > else on the network from misdelivery. It's not the tunnel application, > > it's every application sharing the internet with the tunnel which > > has UDP checksums turned off. See all of RFC 6936 section 3.1. > > Tunnel is fine, sideeffects of misdelivery do not affect tunnel. > > > > And in IPv4 and IPv6, the pseudo-header checksum built into > > TCP and UDP is all we have. IPv6 deliberately copied v4 here. > > > > > What is the error rate in modern h/w and network systems? > > > > No-one measures end-to-end misdelivery. No-one knows. > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Stewart Bryant [stbryant@cisco.com] > > Sent: 14 January 2014 22:46 > > To: Wesley Eddy; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > > > > On 14/01/2014 22:07, Wesley Eddy wrote: > > > On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: > > >> I don't think sayng 'oh, that error source is no longer a problem' disproves > > >> Stone's overall point about undetected errors, though the > > >> examples he uses from the technology of the day are necessarily > > >> dated. Dismissing the overall point because the examples use obsolete > > >> technology is throwing the baby out with the bathwater; a host-to-host > > >> error check catches things that intermediate checks cannot. > > >> > > >> Measuring error rates across end-to-end Internet traffic is something that has > > >> not received much attention , as error detection is not > > >> instrumented well - hence citing Stone's published work, in the absence > > >> of awareness of anything newer (and as high profile/immediately recognisable > > >> as sigcomm) in the area. > > >> > > > > > > +1 ... the message in the paper is applicable to layered systems > > > and internetworks in general. Changes in the link technology > > > since then don't invalidate it, especially since we know that > > > the technology not only changes rapidly, but also is always > > > growing in diverse directions, such that there things almost > > > universally true today may be turned on their heads tomorrow. > > > > > > Designs for stacking layers need to follow solid general > > > principles in order to be robust to changes (above and below). > > > > > Note that it is not only the link layer technology that has moved on, > > the signal integrity of the h/w at all stages of the design and > > implementation process has moved on. > > > > Can we agree that the statistics in the paper are discredited? > > > > If not, why not? > > > > What is the error rate in modern h/w and network systems? > > > > Is this significant in the application under consideration? > > > > Finally if we are really concerned that we do actually need a > > c/s (I am not in tunnel applications) why are we still happy to > > use what is frankly a pathetic check in modern terms? Why > > for example are we not moving to something like > > the Fletcher 64 bit c/s? > > > > Stewart From curtis@ipv6.occnc.com Wed Jan 15 12:02:29 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2231AE1A6; Wed, 15 Jan 2014 12:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 BFERJXjAteJ6; Wed, 15 Jan 2014 12:02:28 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 30DF71AE199; Wed, 15 Jan 2014 12:02:28 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FK28cx022175; Wed, 15 Jan 2014 15:02:08 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401152002.s0FK28cx022175@maildrop2.v6ds.occnc.com> To: Randy Bush From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 17:08:09 +0600." Date: Wed, 15 Jan 2014 15:02:07 -0500 X-Mailman-Approved-At: Thu, 16 Jan 2014 09:08:24 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, tsvwg@ietf.org, Stewart Bryant , jnc@mit.edu, curtis@ipv6.occnc.com Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:02:29 -0000 In message Randy Bush writes: > > [ you insist on cc:ing me, so you get to endure my opinions ] Not a problem (this time). :-) > > it seems that there are no valid statistics for the current Internet > > to sustain your case. > > as we discussed privately, there seem to be no real measurements to > sustain any case. this is all conjecturbation. > > what i do not understand is why, given the lack of solid evidence that > we are in a safe space, you and others are not willing to spend a few > euro cents to have a reasonable level of assurance at this layer. > > randy Randy, See http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html for reasons why routers would want to avoid having to fill in a checksum. It would have been more feasible for an FCS at the end of the packet for these cases but the UDP checksum is in the front. This entire discussion is over putting in a SHOULD rather than a MUST in two places, UDP checksum and congestion control, plus deferring defining the congestion control for MPLS over UDP until deployments show a need for it. Curtis From curtis@ipv6.occnc.com Wed Jan 15 12:05:53 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2C1AE389; Wed, 15 Jan 2014 12:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 AVnar5yR1lmb; Wed, 15 Jan 2014 12:05:52 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5B50A1AE373; Wed, 15 Jan 2014 12:05:52 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FK5VIU022303; Wed, 15 Jan 2014 15:05:31 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401152005.s0FK5VIU022303@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 11:57:18 +0000." <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk> Date: Wed, 15 Jan 2014 15:05:31 -0500 X-Mailman-Approved-At: Thu, 16 Jan 2014 09:08:24 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, stbryant@cisco.com, jnc@mit.edu, curtis@ipv6.occnc.com Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:05:54 -0000 Or perhaps UDP heavy with a FCS at the end and no checksum at all. You do make a good point that perhaps UDP lite should be mentioned in MPLS over UDP as an option. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > you've got the perfect application to encourage UDP lite adoption and > deployment here. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: 15 January 2014 11:31 > To: Randy Bush > Cc: Wood L Dr (Electronic Eng); wes@mti-systems.com; curtis@ipv6.occnc.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > > On 15/01/2014 11:08, Randy Bush wrote: > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > >> it seems that there are no valid statistics for the current Internet > >> to sustain your case. > > as we discussed privately, there seem to be no real measurements to > > sustain any case. this is all conjecturbation. > > > > what i do not understand is why, given the lack of solid evidence that > > we are in a safe space, you and others are not willing to spend a few > > euro cents to have a reasonable level of assurance at this layer. > > > > randy > Randy, > > It is not a few cents, it is likely the re-engineering of a lot > of silicon. > > The reason that UDP is of interest is that the on path silicon > knows how to process it, for example it knows how to to ECMP it. > > The reason that the UDP c/s is a problem for a tunneler is that > it needs to have access to the whole pkt to calculate the > c/s, but as you know the silicon optimised that access away > a long time ago. > > The alternative would be UDP-lite, but the ability of on path > silicon to process that as competently and as completely as it > processes UDP is by no means clear. > > - Stewart From gorry@erg.abdn.ac.uk Wed Jan 15 12:18:26 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FFB1AE19A; Wed, 15 Jan 2014 12:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 Tprr68sz72YW; Wed, 15 Jan 2014 12:18:24 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 119351AE112; Wed, 15 Jan 2014 12:18:24 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7E0802B4230; Wed, 15 Jan 2014 20:18:11 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 15 Jan 2014 20:18:11 -0000 Message-ID: In-Reply-To: <201401152005.s0FK5VIU022303@maildrop2.v6ds.occnc.com> References: <201401152005.s0FK5VIU022303@maildrop2.v6ds.occnc.com> Date: Wed, 15 Jan 2014 20:18:11 -0000 From: gorry@erg.abdn.ac.uk To: curtis@ipv6.occnc.com User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Thu, 16 Jan 2014 09:08:24 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, stbryant@cisco.com Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:18:26 -0000 You may care to reference this to Section 2.2 of RFC 6936, which provides some background to where UDP-Lite may help, and some of the potential pitfalls. Gorry > > Or perhaps UDP heavy with a FCS at the end and no checksum at all. > > You do make a good point that perhaps UDP lite should be mentioned in > MPLS over UDP as an option. > > Curtis > > > In message > <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > >> you've got the perfect application to encourage UDP lite adoption and >> deployment here. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Stewart Bryant [stbryant@cisco.com] >> Sent: 15 January 2014 11:31 >> To: Randy Bush >> Cc: Wood L Dr (Electronic Eng); wes@mti-systems.com; >> curtis@ipv6.occnc.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; >> ietf@ietf.org; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org >> Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: >> gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) >> >> On 15/01/2014 11:08, Randy Bush wrote: >> > [ you insist on cc:ing me, so you get to endure my opinions ] >> > >> >> it seems that there are no valid statistics for the current Internet >> >> to sustain your case. >> > as we discussed privately, there seem to be no real measurements to >> > sustain any case. this is all conjecturbation. >> > >> > what i do not understand is why, given the lack of solid evidence that >> > we are in a safe space, you and others are not willing to spend a few >> > euro cents to have a reasonable level of assurance at this layer. >> > >> > randy >> Randy, >> >> It is not a few cents, it is likely the re-engineering of a lot >> of silicon. >> >> The reason that UDP is of interest is that the on path silicon >> knows how to process it, for example it knows how to to ECMP it. >> >> The reason that the UDP c/s is a problem for a tunneler is that >> it needs to have access to the whole pkt to calculate the >> c/s, but as you know the silicon optimised that access away >> a long time ago. >> >> The alternative would be UDP-lite, but the ability of on path >> silicon to process that as competently and as completely as it >> processes UDP is by no means clear. >> >> - Stewart > From curtis@ipv6.occnc.com Wed Jan 15 12:34:59 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413911AE19A; Wed, 15 Jan 2014 12:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 cb0wpl-l9VAq; Wed, 15 Jan 2014 12:34:57 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1EB1AE0D5; Wed, 15 Jan 2014 12:34:57 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FKYYKO022696; Wed, 15 Jan 2014 15:34:34 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401152034.s0FKYYKO022696@maildrop2.v6ds.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 11:54:17 +0000." Date: Wed, 15 Jan 2014 15:34:34 -0500 X-Mailman-Approved-At: Thu, 16 Jan 2014 09:08:24 -0800 Cc: "gorry@erg.abdn.ac.uk" , "mpls@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" , "wes@mti-systems.com" , Randy Bush , "stbryant@cisco.com" , "jnc@mit.edu" , "ietf@ietf.org" Subject: Re: [lisp] [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:34:59 -0000 In message Alexander Vainshtein writes: > > Stewart, and all, > > I fully agree that UDP checksums is not a real-life issue with the > protocol in question. They could probably help to check corrupted > packets if corruption happens when a packet passes thru a router > (i.e. when the ingress data link FCS has already been terminated and > the egress data link FCS has not been generated yet). But this is > hopefully rare - and since MPLS does not care about it, why should the > MPLS encapsulator care? Why the MPLS over UDP encapsulation cares is in http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html > I also do not think that congestion control is a serious issue for > this protocol, not in the least because the primary purpose of this > protocol is ECMP. The chips I had worked with all did a lookup and retrieved a next-hop index. That could point to a single hop or and entry into the multipath hardware gunk (tables for some not so good implementations). My guess is Stewart is concerned about hardware than can lookup an IP adddress and do multipath but not do an MPLS ILM lookup and then do multipath. [I find that hard to believe since it would be tough to do MPLS over a LAG. Most chips that had not anticipated this could do this with firmware changes because there was enough flexibility in the hardware intended for LAG to get the job done. Some might have limitations with ECMP where component links of the ECMP were LAG. OTOH the further you go back in time the more severe chip limitations you will run into.] IMHO the draft should remove the ECMP motivation from the introduction and then there would be no need to debate this. The draft need only define the protocol. > But I would like to understand whether this protocol can really result > in reasonable distribution of traffic. "Reasonable" means that (a) > there is sufficient entropy and (b) that the order in specific > micro-flows is preserved. The draft skips this issue (unless you > consider a recommendation to use a fixed randomly selected source port > value if the tunnel does not need ECMP a valid answer) . > > Any ideas as to how reasonable distribution of traffic can be achieved > with this protocol? ECMP has been around for a long time and providers carefully tune IGP metrics to get a better but often not very good load balance with ECMP. With other multipath methods you can get non-equal load balance and remove the equal cost limitiation but that might need more recent hardware than Steward and others are faced with. ECMP is a blunt tool. > Regards, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 Curtis > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > > Sent: Wednesday, January 15, 2014 1:31 PM > > To: Randy Bush > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; > > wes@mti-systems.com; tsvwg@ietf.org; jnc@mit.edu > > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in- > > udp draft (was: RE: Milestones changed for tsvwg WG)) > > > > On 15/01/2014 11:08, Randy Bush wrote: > > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > > > >> it seems that there are no valid statistics for the current Internet > > >> to sustain your case. > > > as we discussed privately, there seem to be no real measurements to > > > sustain any case. this is all conjecturbation. > > > > > > what i do not understand is why, given the lack of solid evidence that > > > we are in a safe space, you and others are not willing to spend a few > > > euro cents to have a reasonable level of assurance at this layer. > > > > > > randy > > Randy, > > > > It is not a few cents, it is likely the re-engineering of a lot of silicon. > > > > The reason that UDP is of interest is that the on path silicon knows how to > > process it, for example it knows how to to ECMP it. > > > > The reason that the UDP c/s is a problem for a tunneler is that it needs to > > have access to the whole pkt to calculate the c/s, but as you know the silicon > > optimised that access away a long time ago. > > > > The alternative would be UDP-lite, but the ability of on path silicon to process > > that as competently and as completely as it processes UDP is by no means > > clear. > > > > - Stewart From curtis@ipv6.occnc.com Wed Jan 15 12:49:07 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848D51AE248; Wed, 15 Jan 2014 12:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 reuQK5rr6cLn; Wed, 15 Jan 2014 12:49:05 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9DA1AE0D5; Wed, 15 Jan 2014 12:49:04 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FKmlsn022848; Wed, 15 Jan 2014 15:48:48 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401152048.s0FKmlsn022848@maildrop2.v6ds.occnc.com> To: gorry@erg.abdn.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 20:18:11 +0000." Date: Wed, 15 Jan 2014 15:48:47 -0500 X-Mailman-Approved-At: Thu, 16 Jan 2014 09:08:24 -0800 Cc: mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, curtis@ipv6.occnc.com, jnc@mit.edu, stbryant@cisco.com Subject: Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:49:07 -0000 In message gorry@erg.abdn.ac.uk writes: > > You may care to reference this to Section 2.2 of RFC 6936, which provides > some background to where UDP-Lite may help, and some of the potential > pitfalls. > > Gorry The right tool for the job but ... Expect some pushback because older hardware looks at TCP and UDP in the protocol field and then checks port numbers for ECMP load balance. That older hardware will not do this for UDP-Lite. With MPLS over UDP, only the dest port number matters and the src port number can be used like the MPLS Entropy Label. That is about the only thing that would not work in some networks with UDP-Lite. IMHO it would be advantageous to provide the option to use UDP-Lite rather than UDP with no checksum at all. The section in RFC 6936 could be cited. The limitation I mentioned could also be cited. Curtis > > Or perhaps UDP heavy with a FCS at the end and no checksum at all. > > > > You do make a good point that perhaps UDP lite should be mentioned in > > MPLS over UDP as an option. > > > > Curtis > > > > > > In message > > <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk> > > l.wood@surrey.ac.uk writes: > > > >> you've got the perfect application to encourage UDP lite adoption and > >> deployment here. > >> > >> Lloyd Wood > >> http://about.me/lloydwood > >> ________________________________________ > >> From: Stewart Bryant [stbryant@cisco.com] > >> Sent: 15 January 2014 11:31 > >> To: Randy Bush > >> Cc: Wood L Dr (Electronic Eng); wes@mti-systems.com; > >> curtis@ipv6.occnc.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; > >> ietf@ietf.org; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > >> Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: > >> gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > >> > >> On 15/01/2014 11:08, Randy Bush wrote: > >> > [ you insist on cc:ing me, so you get to endure my opinions ] > >> > > >> >> it seems that there are no valid statistics for the current Internet > >> >> to sustain your case. > >> > as we discussed privately, there seem to be no real measurements to > >> > sustain any case. this is all conjecturbation. > >> > > >> > what i do not understand is why, given the lack of solid evidence that > >> > we are in a safe space, you and others are not willing to spend a few > >> > euro cents to have a reasonable level of assurance at this layer. > >> > > >> > randy > >> Randy, > >> > >> It is not a few cents, it is likely the re-engineering of a lot > >> of silicon. > >> > >> The reason that UDP is of interest is that the on path silicon > >> knows how to process it, for example it knows how to to ECMP it. > >> > >> The reason that the UDP c/s is a problem for a tunneler is that > >> it needs to have access to the whole pkt to calculate the > >> c/s, but as you know the silicon optimised that access away > >> a long time ago. > >> > >> The alternative would be UDP-lite, but the ability of on path > >> silicon to process that as competently and as completely as it > >> processes UDP is by no means clear. > >> > >> - Stewart From internet-drafts@ietf.org Fri Jan 17 05:26:58 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8341AE0BE; Fri, 17 Jan 2014 05:26:57 -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] 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 UnXikiB8U-Vt; Fri, 17 Jan 2014 05:26:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A72131AE0CD; Fri, 17 Jan 2014 05:26:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140117132655.12242.79987.idtracker@ietfa.amsl.com> Date: Fri, 17 Jan 2014 05:26:55 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-deployment-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 13:26:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP Network Element Deployment Considerations Authors : Lorand Jakab Albert Cabellos-Aparicio Florin Coras Jordi Domingo-Pascual Darrel Lewis Filename : draft-ietf-lisp-deployment-12.txt Pages : 28 Date : 2014-01-17 Abstract: This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since. This memo represents one stable point in that evolution of understanding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-deployment/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-deployment-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-deployment-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From curtis@ipv6.occnc.com Fri Jan 17 12:28:35 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771411AC3FA; Fri, 17 Jan 2014 12:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 tEyVjjnDGtlV; Fri, 17 Jan 2014 12:28:33 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7021A802D; Fri, 17 Jan 2014 12:28:32 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HKSJP6065706; Fri, 17 Jan 2014 15:28:19 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401172028.s0HKSJP6065706@maildrop2.v6ds.occnc.com> To: Saku Ytti From: Curtis Villamizar In-reply-to: Your message of "Fri, 17 Jan 2014 18:33:07 +0200." <20140117163307.GA4577@pob.ytti.fi> Date: Fri, 17 Jan 2014 15:28:19 -0500 Cc: mpls@ietf.org, lisp@ietf.org, tsvwg@ietf.org, ietf@ietf.org Subject: Re: [lisp] [mpls] [tsvwg] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 20:28:35 -0000 In message <20140117163307.GA4577@pob.ytti.fi> Saku Ytti writes: > On (2014-01-13 14:11 -0500), Curtis Villamizar wrote: > > > One of the reasons that IPv6 (rfc2460) dropped the header checksum > > that was in IPv4 is that with link layers all doing FCS it served no > > purpose. For the same reason TCP and UDP checksums server no purpose. > > One datapoint from today. Peering router has 4xLACP to core and in one of > these LACP members it is sometimes mangling packets during send and FCS is > being calculated for this mangled data. > All egress PE boxes start logging errors (maybe 1 error per 30min), because > they check IP checksum, which is now incorrect. > > Router is latest generation service provider router from major vendor running > recent software and affected router is logging no errors. Can't imagine > when, if ever, would this issue have been found without IP checksums. > > -- > ++ytti > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls This sounds like a router acting as a host for the given packet. The forwarding data paths in routers are usually protected. If the router was forwarding and mangled packets, that speak well for the router vendor since the major vendors claim to protect their data paths from this sort of thing. Less so for the path from the route processor. If this was originated at the router it would also be caught if AH was enabled. Were these unauthenticated control plane packets? You've made a good anecdotal case for keeping TCP and UDP checksums. Curtis From saku@ytti.fi Fri Jan 17 08:33:28 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263611AE158 for ; Fri, 17 Jan 2014 08:33:28 -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] 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 qe2ApP1VEBk4 for ; Fri, 17 Jan 2014 08:33:25 -0800 (PST) Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1693B1AE12F for ; Fri, 17 Jan 2014 08:33:24 -0800 (PST) Received: by mail-bk0-f41.google.com with SMTP id u12so1581926bkz.14 for ; Fri, 17 Jan 2014 08:33:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=fOExXz/vu7Y2EmPTN7KeV7eiMgKQomSy+C+1ovhn/KA=; b=lSD05TX3LMNyzJSjxD/z6b/1w4dSRpV9p6AwxtfcjJIPYX103H4HZuHxLcLx0D1iBm Yv7X2R789jGckGeWyL7wt6jkPYq3tJRgaAK4EaRYW1I2D7i0HapJ8BXk6BEwYBwvX6aF 51W7Xy9oEOd8+jJkfmon01FxmOYSuDoN7W/BlqSWVy7eLkOrYBXaNXjYSydi03Q54msF jl5OnkNNGo70igtuZnoI1uwW3CagA6h+bfgqic4udvfBqzbs5cEXDNxdSKeaHE5/8WGj qZ3NFxbv+sv30OWlICKGk5yL0N79DDZBnxCLXuyeVxOMrZig7ZGcKDHbQRzeELSTe8uh ++uQ== X-Gm-Message-State: ALoCoQmR3tRdoFMkTXtALuK6cNNkRLsD8SB9eHo8YzAms1YOEw94qr7uyDDvjq7fO3SkZCmSYyR5 X-Received: by 10.205.67.199 with SMTP id xv7mr15190bkb.149.1389976391762; Fri, 17 Jan 2014 08:33:11 -0800 (PST) Received: from pob.ytti.fi (up.ip.fi. [2001:6e8:288::d]) by mx.google.com with ESMTPSA id d5sm10022809bkc.9.2014.01.17.08.33.09 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 Jan 2014 08:33:10 -0800 (PST) Date: Fri, 17 Jan 2014 18:33:07 +0200 From: Saku Ytti To: tsvwg@ietf.org, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org Message-ID: <20140117163307.GA4577@pob.ytti.fi> References: <290E20B455C66743BE178C5C84F1240847E63346BF@EXMB01CMS.surrey.ac.uk> <201401131911.s0DJBC1o079251@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401131911.s0DJBC1o079251@maildrop2.v6ds.occnc.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 18 Jan 2014 09:06:39 -0800 Subject: Re: [lisp] [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 16:33:28 -0000 On (2014-01-13 14:11 -0500), Curtis Villamizar wrote: > One of the reasons that IPv6 (rfc2460) dropped the header checksum > that was in IPv4 is that with link layers all doing FCS it served no > purpose. For the same reason TCP and UDP checksums server no purpose. One datapoint from today. Peering router has 4xLACP to core and in one of these LACP members it is sometimes mangling packets during send and FCS is being calculated for this mangled data. All egress PE boxes start logging errors (maybe 1 error per 30min), because they check IP checksum, which is now incorrect. Router is latest generation service provider router from major vendor running recent software and affected router is logging no errors. Can't imagine when, if ever, would this issue have been found without IP checksums. -- ++ytti From saku@ytti.fi Fri Jan 17 14:33:03 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EEA1ACCED for ; Fri, 17 Jan 2014 14:33:03 -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] autolearn=unavailable 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 NhUfmenNRMdy for ; Fri, 17 Jan 2014 14:33:01 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B186A1ACAD7 for ; Fri, 17 Jan 2014 14:33:00 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id mz12so121546bkb.3 for ; Fri, 17 Jan 2014 14:32:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ghRO5DRJKlNVgt4RvXMoNoXDkyNXVZev0O5yIWKwBnU=; b=VXmWkWL4VS6dKDVw1pf5vYfbwYNlWYFZwhdKIHIiY0cj8+qfzj1Uc0NPiOdb2wU70w nYbNBBKgij/W+wmAUSmCNY+9QpU3PVyxGccBvVqFoCOyYElbnAQxbl11EBgat/if2jWA dhggtv1ZPUka4SxZGlhJmcn82So9DN53JR/Y6CdEOykpudsOJQehOeQB4vJ9Sts1wj80 7cOyvnt7LU1wAtpSMaJ/WCUkVLmjdaszMH5BNpbRoNit9y7ydtjOtOZc/f0O9GUsloeo gHd1qrfiTyIK4cxqZJqbkh7H9IsDTtG0zPQXNTynXc8CN7nRnv39dBAbD7qrsLyD7Ksy o1mg== X-Gm-Message-State: ALoCoQlPelOkHkoiPYtAjUJuZm3gNOeaTf1EFdN5VfMdC638O5YSvinZFqmKE7Jve5jBaz/5wzc4 X-Received: by 10.205.10.66 with SMTP id oz2mr21880bkb.142.1389997966847; Fri, 17 Jan 2014 14:32:46 -0800 (PST) Received: from pob.ytti.fi (up.ip.fi. [2001:6e8:288::d]) by mx.google.com with ESMTPSA id d5sm10751384bkc.9.2014.01.17.14.32.45 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 Jan 2014 14:32:45 -0800 (PST) Date: Sat, 18 Jan 2014 00:32:43 +0200 From: Saku Ytti To: Curtis Villamizar Message-ID: <20140117223243.GA21841@pob.ytti.fi> References: <20140117163307.GA4577@pob.ytti.fi> <201401172028.s0HKSJP6065706@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401172028.s0HKSJP6065706@maildrop2.v6ds.occnc.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 18 Jan 2014 09:06:39 -0800 Cc: mpls@ietf.org, lisp@ietf.org, tsvwg@ietf.org, ietf@ietf.org Subject: Re: [lisp] [mpls] [tsvwg] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 22:33:03 -0000 On (2014-01-17 15:28 -0500), Curtis Villamizar wrote: > This sounds like a router acting as a host for the given packet. The > forwarding data paths in routers are usually protected. If the router This was transit packets ingressing as IP packet, egressing as MPLS packet. Consequently the peer router needed to touch TTL and checksum. Then generate new L2 frame. MPLS core obviously need not to worry about packet being broken, as frame is fine. > was forwarding and mangled packets, that speak well for the router > vendor since the major vendors claim to protect their data paths from Are such claims realistic or practical? I think it sounds like snakeoil when someone claims such absolutes. > this sort of thing. Less so for the path from the route processor. This was forwarding plane. > You've made a good anecdotal case for keeping TCP and UDP checksums. This would actually require IP checksum specifically, otherwise we would have probably never found it. If each egress PE suffers from it maybe once 30min, each customer suffers from it less than once a month, even if everyone would catch it and open trouble ticket, we couldn't correlate the cases to any single peering router, without having historic routing data for each egress PE. Disclaimer, I'm not for or against checksum/FCS in any particular layer, I've not thought about the matter deeply. It was just extremely timely thing in real-life network I wanted to share. -- ++ytti From ggx@gigix.net Mon Jan 20 03:12:37 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4BF1A0118 for ; Mon, 20 Jan 2014 03:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] 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 xVQ9yhxS5kkT for ; Mon, 20 Jan 2014 03:12:35 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCCC1A0112 for ; Mon, 20 Jan 2014 03:12:35 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id e4so4251767wiv.2 for ; Mon, 20 Jan 2014 03:12:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=l7G5/aUI0RXragdvx0UtHrM2cjS3No7tI/IY3Sw70ak=; b=R5/4k++UpvtHV5Amz5Y4cpbrjXDVBQDCbvWNtBtVsfXMXfoa6JRkQPf8hDTMRc7y24 zxC9b9Yz6/l4FzB5F62rWWTkh2pVwOIIcKcN4fn+liQvbtC9fEPU7/nRiWQR4d+iVC4d /iDMo0yxPFQMPP5U38ORyd7GTa9h2bNgbjmvFmFuc/4Ht21CpQAaZljsVkTWlr6c4znO UhWjLIXxi26SX5Dce8KBfQlb2IL35CTHhzasBW1SdEhBCN70WDJxDS3Rran5ULAtDFuu zwFtFxemaAKHTLW+lMTkgIPijjLUmNXAyX8i9gvDCNCWAdoFo5pN1DwnaazhmVJYWZlH CgYA== X-Gm-Message-State: ALoCoQlOZYTF/IZ2Fm2aml6eNQ3g+I/KU841nWBIfulEtaiDyVs7s8kc9dEuafqcBI2nMyOPm6VM X-Received: by 10.180.188.230 with SMTP id gd6mr9549593wic.15.1390216355210; Mon, 20 Jan 2014 03:12:35 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:ed8a:a5b4:1886:c222? ([2001:660:330f:a4:ed8a:a5b4:1886:c222]) by mx.google.com with ESMTPSA id fp9sm1736342wib.8.2014.01.20.03.12.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Jan 2014 03:12:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Luigi Iannone In-Reply-To: <8492967c05d74f468201b8d500403d49@CO2PR05MB636.namprd05.prod.outlook.com> Date: Mon, 20 Jan 2014 12:12:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> <46CB916D-F1E3-48E5-8CE3-93F9F0F5B7AB@steffann.nl> <8492967c05d74f468201b8d500403d49@CO2PR05MB636.namprd05.prod.outlook.com> To: LISP mailing list list X-Mailer: Apple Mail (2.1827) Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 11:12:37 -0000 Hi All, The LC for this document has expired a while ago and my personal take is = that there is some text to adjust before going forward. Section 4 will have the following text (reviewed by Geoff): To provide reachability from the non-LISP Internet EID prefix may = be restrictively announced in the BGP routing infrastructure by one = or more=20 PITR(s) as more specifics. The intended scope of these more = specific=20 prefix advertisements may be deliberated limited by the PITR to = reflect=20 local routing policies. The EID block must be used for LISP experimentation and must not = be=20 advertised in the form of more specific route advertisements in = the=20 non-LISP inter-domain routing environment. Interworking between = the=20 EID block sub-prefixes and the non-LISP Internet is done = according to=20 [RFC6832] and [I-D.ietf-lisp-deployment]. Any further amendments on these two paragraphs? Second point to finalise is about PITRs. There was a nice discussion on = this topic nicely summarised by Ron Bonica in http://www.ietf.org/mail-archive/web/lisp/current/msg04981.html So, the options on the table are: a) Nice discussion but PITR deployment model has no place in this = document. b) Extend section 4 (Expected Use) to include a summary of the = discussion. please express your opinion. ciao Luigi On 6 Dec. 2013, at 20:04 , Ross Callon wrote: >> ... and to make it usable we cannot expect each and every ISP to run = a PITR for their own customers >=20 > Yes indeed. A problem with all service providers offering PITR service = to=20 > their own customers only is that for quite a while not all service = providers > will choose to do anything related to LISP. Thus in the intermediate = term if=20 > some service providers offer and use LISP, and others do not, there = needs to=20 > be some way for customers from the "no LISP" service providers to send = traffic=20 > to customers using LISP from the "I support LISP" service providers. >=20 > Thus to me it seems that service providers who support LISP for their=20= > customers are going to need to supply the PITRs to reach their = customers.=20 > Of course it is possible that you could be right and this could be one > global provider who can offer service in many parts of the world = (assuming > that someone chooses to be that provider).=20 >=20 > Ross >=20 > -----Original Message----- > From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Sander Steffann > Sent: Friday, December 06, 2013 4:10 AM > To: Geoff Huston > Cc: LISP mailing list list > Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >=20 > Hi Geoff, >=20 > I was more thinking of one or more large (glibal) transit providers to = include LISP PITR services as an official managed service with anycast = nodes around the world. I definitely don't want to repeat the 6to4 = disaster where there are a few sparsely distributed volunteer nodes, and = to make it usable we cannot expect each and every ISP to run a PITR for = their own customers. Certainly not while it is experimental. >=20 > Transit providers actually get paid for the traffic they handle, so = for them it can be economically interesting to offer well performing = PITR services. >=20 > Met vriendelijke groet, > Sander Steffann >=20 > Op 5 dec. 2013 om 21:04 heeft Geoff Huston het = volgende geschreven: >=20 >>> Sander, >>>=20 >>> I think that what you are saying is true. Do folks agree? >>=20 >> agree, yes. But at the same time I should point out that this = approach >> has some serious downside risk. >>=20 >> This limited advertisement scope was the theory behind the intended = routing >> scope of 2002::/16. The theory was that every provider would = advertise >> 2002::/16 to its customers, and noone would need to take the unfunded = transit >> traffic hit of advertising this gateway prefix globally. >>=20 >> And some providers did precisely that. However most folk did = absolutely nothing, >> so reachability into the 2002::/16 space was erratic, unmanaged and = non-functional. >> The approach described below by Sander could be seen as a replay of = this >> same piecemeal limited scope advertisement scenario, and has the same = risk. >>=20 >> What's the risk? >>=20 >> Again 2002::/16 has some clues. >>=20 >> While the experiment is of small scale and the traffic levels are = insignificant >> some folk will advertise the /32 prefix globally and absorb the = unfunded >> transit traffic as part of the experiment. This sounds great, but it = has >> some serious downsides. >>=20 >> The consequent routing from the non-LISP world to the LISP world may = well >> have highly inefficient and lengthy paths for many, as the "closest" = gateway >> may well be on the other side of the planet. (e.g. from Australia I = still >> send most of my Teredo traffic via Amsterdam - obviously performance = sucks when this >> happens!) >>=20 >> The consequent impact on performance of these extended "dog leg" = paths that need >> to head to the PITR gateway to transit between the LISP and non-LISP = routing domains >> which may well have some negative impact on the perceptions of LISP = performance >> in the context of this experiment. i.e. it appears that the negative = 6to4 perceptions were >> not only due to widespread use of local protocol 41 filters, but also = due to the >> asymmetric and highly erratic transit paths between end users and the = sparsely deployed >> 6to4 gateways. >>=20 >> Geoff >>=20 >>=20 >>=20 >>=20 >>> On 6 Dec 2013, at 3:06 am, Ronald Bonica = wrote: >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Sander Steffann [mailto:sander@steffann.nl] >>>> Sent: Thursday, December 05, 2013 2:02 AM >>>> To: Dino Farinacci >>>> Cc: Ronald Bonica; Luigi Iannone; Geoff Huston; LISP mailing list = list >>>> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >>>>=20 >>>> Hi, >>>>=20 >>>>> As I said before, the /32 advertisements of an EID-block are >>>> advertised within an ISP towards the edges of the network. Those = edges >>>> are towards its customers so its customers, as sources in non-LISP >>>> sites, can reach destinations in LISP sites. >>>>=20 >>>> So if it is only done this way, that means for global reachability = of >>>> the LISP prefix at least one global transit provider has to run = PITRs. >>>> They wouldn't mind attracting the traffic from their customers. = That is >>>> what they are paid for :-) That would make it work, *if* we can >>>> convince the big transit(s). >>>>=20 >>>> Cheers, >>>> Sander >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ietf@bartschnet.de Tue Jan 21 08:13:48 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8A01A0384 for ; Tue, 21 Jan 2014 08:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.148 X-Spam-Level: * X-Spam-Status: No, score=1.148 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 bSK-gxka9scv for ; Tue, 21 Jan 2014 08:13:46 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id DBE1D1A0378 for ; Tue, 21 Jan 2014 08:13:45 -0800 (PST) Received: from [80.67.16.118] (helo=www.premium-webmail.de) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1W5dxQ-0000Jk-St for lisp@ietf.org; Tue, 21 Jan 2014 17:13:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 Jan 2014 17:13:44 +0100 From: Rene Bartsch To: lisp@ietf.org Message-ID: X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: [lisp] Replacing Dual-Stack Lite with LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 16:13:48 -0000 Hi, are there any approaches (drafts, RFCs) to replace Dual-Stack Lite with LISP by adding Carrier-Grade-NAT to the PxTRs? That way any LISP-capable router could provide IPv4 connectivity without the need of an additional Dual-Stack Lite stack. -- Best regards, Rene Bartsch, B. Sc. Informatics Current Bitcoin Exchange Rate: https://www.bitcoin.de/de/r/mwfngu From ietf@bartschnet.de Tue Jan 21 09:00:07 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E944B1A016D for ; Tue, 21 Jan 2014 09:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.152 X-Spam-Level: X-Spam-Status: No, score=-0.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 auB7ArQG1VLE for ; Tue, 21 Jan 2014 09:00:04 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB11A0181 for ; Tue, 21 Jan 2014 09:00:04 -0800 (PST) Received: from [80.67.16.118] (helo=www.premium-webmail.de) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1W5egF-0001bq-P3 for lisp@ietf.org; Tue, 21 Jan 2014 18:00:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 Jan 2014 18:00:03 +0100 From: Rene Bartsch To: lisp@ietf.org In-Reply-To: References: Message-ID: X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: Re: [lisp] Replacing Dual-Stack Lite with LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:00:08 -0000 @Darrel It seem's to be pretty simple: 1. Setup an IPv4 NAT-router providing one private IPv4 network (EIDs) for each customer natted to one public IPv4 IP (or multiple private IPv4 networks (EIDs) natted to one public IPv4 IP). 2. Connect a LISP-PxTR to the IPv4 NAT-router which encapsulates the private IPv4 networks (EIDS) into public IPv6 LISP-tunnels (RLOCs). 3. Provide a closed Map-server/-resolver setup mapping private IPv4 EIDs to public IPv6 RLOCs The only problem I see is to exchange NAT mapping tables/connection tracking between multiple NAT-routers when using multiple PITRs/PETRs. If you just use one NAT-router and one PxTR it should work out of the box with standard LISP solutions. Or did I miss something? -- Best regards, Rene Bartsch, B. Sc. Informatics Current Bitcoin Exchange Rate: https://www.bitcoin.de/de/r/mwfngu From farinacci@gmail.com Mon Jan 27 10:24:51 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E861A001E for ; Mon, 27 Jan 2014 10:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.403 X-Spam-Level: **** X-Spam-Status: No, score=4.403 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FILL_THIS_FORM=0.001, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, MANGLED_LIPS=2.3, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no 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 8_OyQwvibGkt for ; Mon, 27 Jan 2014 10:24:40 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 10E5E1A028B for ; Mon, 27 Jan 2014 10:24:38 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id p10so6049354pdj.29 for ; Mon, 27 Jan 2014 10:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=gGu0vbp8auPF+Ox0xwBvdhYrhmsFdLKdvh3+ylmsTB4=; b=VHwuYZ82DmaLNF7xu0XM5RR2wX3eGIu8NDFJz1GN0L8fYnRxZlXTdkL+dXQnlMuPdQ 90d1bvUoZ2yT7tiFRga3VM1SfRHEVePyRsU4N/8v/pjvWGk+6BWvjeoAlFnoS3ivLZCz 8iD+Ta2ZEC9yvCgG+XxFwK4NeJVngrR0WPhYCtVezdrCh968/ZIYUH4CZejcXSr6QhZp Ack6RMbQYuuv3k3uBnJP5W1whUQUWfGqdE1lS9r+TOpqDYn3T8W0Kj1CvMZ+CZOtisGR TxI4p4u/Luh9zEZ7eySlJP5vPVZzA1k3tcqcBw3Y17KEJaB9ie1xP1p5GsPW4KVsZawG 93JQ== X-Received: by 10.66.149.37 with SMTP id tx5mr31306600pab.81.1390847075637; Mon, 27 Jan 2014 10:24:35 -0800 (PST) Received: from [192.168.1.243] ([207.145.253.66]) by mx.google.com with ESMTPSA id fk4sm90499996pab.23.2014.01.27.10.24.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 10:24:34 -0800 (PST) From: Dino Farinacci Content-Type: multipart/mixed; boundary="Apple-Mail=_0C40D60C-3756-44B6-9D43-88F9154083DD" Date: Mon, 27 Jan 2014 10:24:27 -0800 Message-Id: To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Cc: Michael Kowal , Parantap Lahiri , David Meyer Subject: [lisp] Proposed changes to draft-ietf-lisp-lcaf-04 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 18:24:52 -0000 --Apple-Mail=_0C40D60C-3756-44B6-9D43-88F9154083DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The implementors of LISP-TE draft that uses the "Explciit Locator Path" = (ELP) LCAF type have agreed that the AFI value should be adjacent with = the address encoded in the ELP-node list. The change makes obvious sense = to make the ELP address encoding consistent with address encodings in = other LCAF types. See attached diffs. We have all agreed there should not be any backward compatibility issues = since ELP deployment is early. Thanks, Dino --Apple-Mail=_0C40D60C-3756-44B6-9D43-88F9154083DD Content-Disposition: attachment; filename=rfcdiff-ietf-lisp-lcaf-03-to-04.html Content-Type: text/html; name="rfcdiff-ietf-lisp-lcaf-03-to-04.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-lcaf-03.txt draft-ietf-lisp-lcaf-04.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                               lispers.net
Intended status: Experimental                                   D. Meyer
Expires: March 20, July 31, 2014                                           Brocade
                                                             J. Snijders
                                                       Hibernia Networks
                                                      September 16, 2013
                                                        January 27, 2014

                  LISP Canonical Address Format (LCAF)
                        draft-ietf-lisp-lcaf-03
                        draft-ietf-lisp-lcaf-04

Abstract

   This draft defines a canonical address format encoding used in LISP
   control messages and in the encoding of lookup keys for the LISP
   Mapping Database System.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 20, July 31, 2014.

Copyright Notice

   Copyright (c) 2013 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   3.  LISP Canonical Address Format Encodings  . . . . . . . . . . .  5
   4.  LISP Canonical Address Applications  . . . . . . . . . . . . .  7
     4.1.  Segmentation using LISP  . . . . . . . . . . . . . . . . .  7
     4.2.  Carrying AS Numbers in the Mapping Database  . . . . . . .  8
     4.3.  Convey Application Specific Data . . . . . . . . . . . . .  9
     4.4.  Assigning Geo Coordinates to Locator Addresses . . . . . . 10
     4.5.  Generic Database Mapping Lookups . . . . . . . . . . . . . 12
     4.6.  NAT Traversal Scenarios  . . . . . . . . . . . . . . . . . 13
     4.7.  PETR Admission Control Functionality . . . . . . . . . . . 15
     4.8.  Multicast Group Membership Information . . . . . . . . . . 16
     4.9.  Traffic Engineering using Re-encapsulating Tunnels . . . . 18
     4.10. Storing Security Data in the Mapping Database  . . . . . . 19
     4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . . 20
     4.12. Replication List Entries for Multicast Forwarding  . . . . 21
     4.13. Data Model Encoding  . . . . . . . . . . . . . . . . . . . 22
     4.14. Encoding Key/Value Address Pairs . . . . . . . . . . . . . 23
     4.15. Applications for AFI List Type . . . . . . . . . . . . . . 23
       4.15.1.  Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 23
       4.15.2.  Layer-2 VPNs  . . . . . . . . . . . . . . . . . . . . 25
       4.15.3.  ASCII Names in the Mapping Database . . . . . . . . . 25
       4.15.4.  Using Recursive LISP Canonical Address Encodings  . . 26
       4.15.5.  Compatibility Mode Use Case . . . . . . . . . . . . . 27
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 30
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 30
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 32
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 33
     B.1.  Changes to draft-ietf-lisp-lcaf-03.txt draft-ietf-lisp-lcaf-04.txt . . . . . . . . . . 33
     B.2.  Changes to draft-ietf-lisp-lcaf-02.txt draft-ietf-lisp-lcaf-03.txt . . . . . . . . . . 33
     B.3.  Changes to draft-ietf-lisp-lcaf-01.txt draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 33
     B.4.  Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 33
     B.5.  Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 35

1.  Introduction

   The LISP architecture and protocols [RFC6830] introduces two new
   numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
   (RLOCs) which are intended to replace most use of IP addresses on the
   Internet.  To provide flexibility for current and future
   applications, these values can be encoded in LISP control messages
   using a general syntax that includes Address Family Identifier (AFI),
   length, and value fields.

   Currently defined AFIs include IPv4 and IPv6 addresses, which are
   formatted according to code-points assigned in [AFI] as follows:

   IPv4 Encoded Address:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Encoded Address:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 2            |       IPv6 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv6 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This document describes the currently-defined AFIs the LISP protocol
   uses along with their encodings and introduces the LISP Canonical
   Address Format (LCAF) that can be used to define the LISP-specific
   encodings for arbitrary AFI values.

2.  Definition of Terms

   Address Family Identifier (AFI):  a term used to describe an address
      encoding in a packet.  An address family currently defined for
      IPv4 or IPv6 addresses.  See [AFI] and [RFC1700] for details.  The
      reserved AFI value of 0 is used in this specification to indicate
      an unspecified encoded address where the the length of the address
      is 0 bytes following the 16-bit AFI value of 0.

   Unspecified Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 0            |    <nothing follows AFI=0>    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains a destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an egress
      tunnel router (ETR).  It is the output of a EID-to-RLOC mapping
      lookup.  An EID maps to one or more RLOCs.  Typically, RLOCs are
      numbered from topologically aggregatable blocks that are assigned
      to a site at each point to which it attaches to the global
      Internet; where the topology is defined by the connectivity of
      provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

3.  LISP Canonical Address Format Encodings

   IANA has assigned AFI value 16387 (0x4003) to the LISP architecture
   and protocols.  This specification defines the encoding format of the
   LISP Canonical Address (LCA).

   The first 4 bytes of an LISP Canonical Address are followed by a
   variable length of fields:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       |     Rsvd2     |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Rsvd1:  this 8-bit field is reserved for future use and MUST be
      transmitted as 0 and ignored on receipt.

   Flags:  this 8-bit field is for future definition and use.  For now,
      set to zero on transmission and ignored on receipt.

   Type:  this 8-bit field is specific to the LISP Canonical Address
      formatted encodings, values are:

     Type 0:  Null Body Type

     Type 1:  AFI List Type

     Type 2:  Instance ID Type

     Type 3:  AS Number Type

     Type 4:  Application Data Type

     Type 5:  Geo Coordinates Type

     Type 6:  Opaque Key Type

     Type 7:  NAT-Traversal Type

     Type 8:  Nonce Locator Type

     Type 9:  Multicast Info Type
     Type 10:  Explicit Locator Path Type

     Type 11:  Security Key Type

     Type 12:  Source/Dest Key Type

     Type 13:  Replication List Entry Type

     Type 14:  JSON Data Model Type

     Type 15:  Key/Value Address Pair Type

   Rsvd2:  this 8-bit field is reserved for future use and MUST be
      transmitted as 0 and ignored on receipt.

   Length:  this 16-bit field is in units of bytes and covers all of the
      LISP Canonical Address payload, starting and including the byte
      after the Length field.  So any LCAF encoded address will have a
      minimum length of 8 bytes when the Length field is 0.  The 8 bytes
      include the AFI, Flags, Type, Reserved, and Length fields.  When
      the AFI is not next to encoded address in a control message, then
      the encoded address will have a minimum length of 6 bytes when the
      Length field is 0.  The 6 bytes include the Flags, Type, Reserved,
      and Length fields.

4.  LISP Canonical Address Applications

4.1.  Segmentation using LISP

   When multiple organizations inside of a LISP site are using private
   addresses [RFC1918] as EID-prefixes, their address spaces must remain
   segregated due to possible address duplication.  An Instance ID in
   the address encoding can aid in making the entire AFI based address
   unique.

   Another use for the Instance ID LISP Canonical Address Format is when
   creating multiple segmented VPNs inside of a LISP site where keeping
   EID-prefix based subnets is desirable.

   Instance ID LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 2    | IID mask-len  |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Instance ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IID mask-len:  if the AFI is set to 0, then this format is not
      encoding an extended EID-prefix but rather an instance-ID range
      where the 'IID mask-len' indicates the number of high-order bits
      used in the Instance ID field for the range.

   Length value n:  length in bytes of the AFI address that follows the
      Instance ID field including the AFI field itself.

   Instance ID:  the low-order 24-bits that can go into a LISP data
      header when the I-bit is set.  See [RFC6830] for details.

   AFI = x:  x can be any AFI value from [AFI].

   This LISP Canonical Address Type can be used to encode either EID or
   RLOC addresses.

4.2.  Carrying AS Numbers in the Mapping Database

   When an AS number is stored in the LISP Mapping Database System for
   either policy or documentation reasons, it can be encoded in a LISP
   Canonical Address.

   AS Number LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 3    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           AS Number                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      AS Number field including the AFI field itself.

   AS Number:  the 32-bit AS number of the autonomous system that has
      been assigned either the EID or RLOC that follows.

   AFI = x:  x can be any AFI value from [AFI].

   The AS Number Canonical Address Type can be used to encode either EID
   or RLOC addresses.  The former is used to describe the LISP-ALT AS
   number the EID-prefix for the site is being carried for.  The latter
   is used to describe the AS that is carrying RLOC based prefixes in
   the underlying routing system.

4.3.  Convey Application Specific Data

   When a locator-set needs to be conveyed based on the type of
   application or the Per-Hop Behavior (PHB) of a packet, the
   Application Data Type can be used.

   Application Data LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 4    |     Rsvd2     |             8 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       IP TOS, IPv6 TC, or Flow Label          |    Protocol   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Local Port (lower-range)   |    Local Port (upper-range)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Remote Port (lower-range)   |   Remote Port (upper-range)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      8-byte Application Data fields including the AFI field itself.

   IP TOS, IPv6 TC, or Flow Label:  this field stores the 8-bit IPv4 TOS
      field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow
      Label used in an IPv6 header.

   Local Port/Remote Port Ranges:  these fields are from the TCP, UDP,
      or SCTP transport header.  A range can be specified by using a
      lower value and an upper value.  When a single port is encoded,
      the lower and upper value fields are the same.

   AFI = x:  x can be any AFI value from [AFI].

   The Application Data Canonical Address Type is used for an EID
   encoding when an ITR wants a locator-set for a specific application.
   When used for an RLOC encoding, the ETR is supplying a locator-set
   for each specific application is has been configured to advertise.

4.4.  Assigning Geo Coordinates to Locator Addresses

   If an ETR desires to send a Map-Reply describing the Geo Coordinates
   for each locator in its locator-set, it can use the Geo Coordinate
   Type to convey physical location information.

   Coordinates are specified using the WGS-84 (World Geodetic System)
   reference coordinate system [WGS-84].

   Geo Coordinate LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 5    |     Rsvd2     |            12 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|     Latitude Degrees        |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |E|     Longitude Degrees       |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Altitude                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      8-byte Longitude and Latitude fields including the AFI field
      itself.

   N: When set to 1 means North, otherwise South.

   Latitude Degrees:  Valid values range from 0 to 90 degrees above or
      below the equator (northern or southern hemisphere, respectively).

   Latitude Minutes:  Valid values range from 0 to 59.

   Latitude Seconds:  Valid values range from 0 to 59.

   E: When set to 1 means East, otherwise West.

   Longitude Degrees:  Value values are from 0 to 180 degrees right or
      left of the Prime Meridian.

   Longitude Minutes:  Valid values range from 0 to 59.

   Longitude Seconds:  Valid values range from 0 to 59.

   Altitude:  Height relative to sea level in meters.  This is a signed
      integer meaning that the altitude could be below sea level.  A
      value of 0x7fffffff indicates no Altitude value is encoded.

   AFI = x:  x can be any AFI value from [AFI].

   The Geo Coordinates Canonical Address Type can be used to encode
   either EID or RLOC addresses.  When used for EID encodings, you can
   determine the physical location of an EID along with the topological
   location by observing the locator-set.

4.5.  Generic Database Mapping Lookups

   When the LISP Mapping Database system holds information accessed by a
   generic formatted key (where the key is not the usual IPv4 or IPv6
   address), an opaque key may be desirable.

   Opaque Key LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 6    |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Key Field Num |      Key Wildcard Fields      |   Key . . .   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       . . . Key                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the type's payload.  The value n
      is the number of bytes that follow this Length field.

   Key Field Num:  the number of fields (minus 1) the key can be broken
      up into.  The width of the fields are fixed length.  So for a key
      size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2
      bytes in length.  Valid values for this field range from 0 to 15
      supporting a maximum of 16 field separations.

   Key Wildcard Fields:  describes which fields in the key are not used
      as part of the key lookup.  This wildcard encoding is a bitfield.
      Each bit is a don't-care bit for a corresponding field in the key.
      Bit 0 (the low-order bit) in this bitfield corresponds the first
      field, right-justified in the key, bit 1 the second field, and so
      on.  When a bit is set in the bitfield it is a don't-care bit and
      should not be considered as part of the database lookup.  When the
      entire 16-bits is set to 0, then all bits of the key are used for
      the database lookup.

   Key:  the variable length key used to do a LISP Database Mapping
      lookup.  The length of the key is the value n (shown above) minus
      3.

4.6.  NAT Traversal Scenarios

   When a LISP system is conveying global address and mapped port
   information when traversing through a NAT device, the NAT-Traversal
   LCAF Type is used.  See [LISP-NATT] for details.

   NAT-Traversal Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 7    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       MS UDP Port Number      |      ETR UDP Port Number      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |  Global ETR RLOC Address  ... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       MS RLOC Address  ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          | Private ETR RLOC Address  ... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |      RTR RLOC Address 1 ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |      RTR RLOC Address k ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI addresses that follows
      the UDP Port Number field including the AFI fields themselves.

   MS UDP Port Number:  this is the UDP port number of the Map-Server
      and is set to 4342.

   ETR UDP Port Number:  this is the port number returned to a LISP
      system which was copied from the source port from a packet that
      has flowed through a NAT device.

   AFI = x:  x can be any AFI value from [AFI].

   Global ETR RLOC Address:  this is an address known to be globally
      unique built by NAT-traversal functionality in a LISP router.

   MS RLOC Address:  this is the address of the Map-Server used in the
      destination RLOC of a packet that has flowed through a NAT device.

   Private ETR RLOC Address:  this is an address known to be a private
      address inserted in this LCAF format by a LISP router that resides
      on the private side of a NAT device.

   RTR RLOC Address:  this is an encapsulation address used by an ITR or
      PITR which resides behind a NAT device.  This address is known to
      have state in a NAT device so packets can flow from it to the LISP
      ETR behind the NAT.  There can be one or more NTR addresses
      supplied in these set of fields.  The number of NTRs encoded is
      determined by the LCAF length field.  When there are no NTRs
      supplied, the NTR fields can be omitted and reflected by the LCAF
      length field or an AFI of 0 can be used to indicate zero NTRs
      encoded.

4.7.  PETR Admission Control Functionality

   When a public PETR device wants to verify who is encapsulating to it,
   it can check for a specific nonce value in the LISP encapsulated
   packet.  To convey the nonce to admitted ITRs or PITRs, this LCAF
   format is used in a Map-Register or Map-Reply locator-record.

   Nonce Locator Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 8    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Reserved    |                  Nonce                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      Nonce field including the AFI field itself.

   Reserved:  must be set to zero and ignore on receipt.

   Nonce:  this is a nonce value returned by an ETR in a Map-Reply
      locator-record to be used by an ITR or PITR when encapsulating to
      the locator address encoded in the AFI field of this LCAF type.

   AFI = x:  x can be any AFI value from [AFI].

4.8.  Multicast Group Membership Information

   Multicast group information can be published in the mapping database
   so a lookup on an EID based group address can return a replication
   list of group addresses or a unicast addresses for single replication
   or multiple head-end replications.  The intent of this type of
   unicast replication is to deliver packets to multiple ETRs at
   receiver LISP multicast sites.  The locator-set encoding for this EID
   record type can be a list of ETRs when they each register with "Merge
   Semantics".  The encoding can be a typical AFI encoded locator
   address.  When an RTR list is being registered (with multiple levels
   according to [LISP-RE]), the Replication List Entry LCAF type is used
   for locator encoding.

   This LCAF encoding can be used to send broadcast packets to all
   members of a subnet when each EIDs are away from their home subnet
   location.

   Multicast Info Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 9    |  Rsvd2  |R|L|J|             8 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Instance-ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved           | Source MaskLen| Group MaskLen |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |   Source/Subnet Address  ...  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Group Address  ...      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Reserved:  must be set to zero and ignore on receipt.

   R-bit:  this is the RP-bit that represents PIM (S,G,RP-bit) multicast
      state.  This bit can be set for Joins (when the J-bit is set) or
      for Leaves (when the L-bit is set).  See [LISP-MRSIG] for more
      usage details.

   L-bit:  this is the Leave-Request bit and is used when this LCAF type
      is present in the destination EID-prefix field of a Map-Request.
      See [LISP-MRSIG] for details.

   J-bit:  this is the Join-Request bit and is used when this LCAF type
      is present in the destination EID-prefix field of a Map-Request.
      See [LISP-MRSIG] for details.  The J-bit MUST not be set when the
      L-bit is also set in the same LCAF block.  A receiver should not
      take any specific Join or Leave action when both bits are set.

   Instance ID:  the low-order 24-bits that can go into a LISP data
      header when the I-bit is set.  See [RFC6830] for details.  The use
      of the Instance-ID in this LCAF type is to associate a multicast
      forwarding entry for a given VPN.  The instance-ID describes the
      VPN and is registered to the mapping database system as a 3-tuple
      of (Instance-ID, S-prefix, G-prefix).

   Source MaskLen:  the mask length of the source prefix that follows.

   Group MaskLen:  the mask length of the group prefix that follows.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

4.9.  Traffic Engineering using Re-encapsulating Tunnels

   For a given EID lookup into the mapping database, this LCAF format
   can be returned to provide a list of locators in an explicit re-
   encapsulation path.  See [LISP-TE] for details.

   Explicit Locator Path (ELP) Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 10   |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Rsvd3         |L|P|S|           AFI = x             |           Rsvd3         |L|P|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reencap Hop 1  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Rsvd3         |L|P|S|           AFI = x             |           Rsvd3         |L|P|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reencap Hop k  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

   Lookup bit (L):  this is the Lookup bit used to indicate to the user
      of the ELP to not use this address for encapsulation but to look
      it up in the mapping database system to obtain an encapsulating
      RLOC address.

   RLOC-Probe bit (P):  this is the RLOC-probe bit which means the
      Reencap Hop allows RLOC-probe messages to be sent to it.  When the
      R-bit is set to 0, RLOC-probes must not be sent.  When a Reencap
      Hop is an anycast address then multiple physical Reencap Hops are
      using the same RLOC address.  In this case, RLOC-probes are not
      needed because when the closest RLOC address is not reachable
      another RLOC address can reachable.

   Strict bit (S):  this the strict bit which means the associated
      Rencap Hop is required to be used.  If this bit is 0, the
      reencapsulator can skip this Reencap Hop and go to the next one in
      the list.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

4.10.  Storing Security Data in the Mapping Database

   When a locator in a locator-set has a security key associated with
   it, this LCAF format will be used to encode key material.  See
   [LISP-DDT] for details.

   Security Key Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 11   |      Rsvd2    |             6 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Key Count   |      Rsvd3    | Key Algorithm |   Rsvd4     |R|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Key Length          |       Key Material ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        ... Key Material                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Locator Address ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that start with the Key
      Material field.

   Key Count:  the Key Count field declares the number of Key sections
      included in this LCAF.

   Key Algorithm:  the Algorithm field identifies the key's
      cryptographic algorithm and specifies the format of the Public Key
      field.

   R bit:  this is the revoke bit and, if set, it specifies that this
      Key is being Revoked.

   Key Length:  this field determines the length in bytes of the Key
      Material field.

   Key Material:  the Key Material field stores the key material.  The
      format of the key material stored depends on the Key Algorithm
      field.

   AFI = x:  x can be any AFI value from [AFI].This is the locator
      address that owns the encoded security key.

4.11.  Source/Destination 2-Tuple Lookups

   When both a source and destination address of a flow needs
   consideration for different locator-sets, this 2-tuple key is used in
   EID fields in LISP control messages.  When the Source/Dest key is
   registered to the mapping database, it can be encoded as a source-
   prefix and destination-prefix.  When the Source/Dest is used as a key
   for a mapping database lookup the source and destination come from a
   data packet.

   Source/Dest Key Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 12   |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved           |   Source-ML   |    Dest-ML    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Source-Prefix ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |     Destination-Prefix ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Reserved:  must be set to zero and ignore on receipt.

   Source-ML:  the mask length of the source prefix that follows.

   Dest-ML:  the mask length of the destination prefix that follows.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

   Refer to [LISP-TE] for usage details.

4.12.  Replication List Entries for Multicast Forwarding

   The Replication List Entry LCAF type is an encoding for a locator
   being used for unicast replication according to the specification in
   [LISP-RE].  This locator encoding is pointed to by a Multicast Info
   LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs)
   that are participating in an overlay distribution tree.  Each RTR
   will register its locator address and its configured level in the
   distribution tree.

   Replication List Entry Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 13   |    Rsvd2      |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Rsvd3            |     Rsvd4     |  Level Value  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           RTR/ETR #1 ...      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Rsvd3            |     Rsvd4     |  Level Value  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           RTR/ETR  #n ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Rsvd{1,2,3,4}:  must be set to zero and ignore on receipt.

   Level Value:  this value is associated with the level within the
      overlay distribution tree hierarchy where the RTR resides.  The
      level numbers are ordered from lowest value being close to the ITR
      (meaning that ITRs replicate to level-0 RTRs) and higher levels
      are further downstream on the distribution tree closer to ETRs of
      multicast receiver sites.

   AFI = x:  x can be any AFI value from [AFI].  A specific AFI has its
      own encoding of either a unicast or multicast locator address.
      All RTR/ETR entries for the same level should be combined together
      by a Map-Server to avoid searching through the entire multi-level
      list of locator entries in a Map-Reply message.

4.13.  Data Model Encoding

   This type allows a JSON data model to be encoded either as an EID or
   RLOC.

   JSON Data Model Type Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 14   |    Rsvd2    |B|               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                JSON binary or text encoding ...               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Optional Address ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Rsvd{1,2}:  must be set to zero and ignore on receipt.

   B bit:  indicates that the JSON field is binary encoded according to
      [JSON-BINARY] when the bit is set to 1.  Otherwise the encoding is
      based on text encoding according to [RFC4627].

   JSON field:  a variable length field that contains either binary or
      text encodings.

   AFI = x:  x can be any AFI value from [AFI].  A specific AFI has its
      own encoding of either a unicast or multicast locator address.
      All RTR/ETR entries for the same level should be combined together
      by a Map-Server to avoid searching through the entire multi-level
      list of locator entries in a Map-Reply message.

4.14.  Encoding Key/Value Address Pairs

   The Key/Value pair is for example useful for attaching attributes to
   other elements of LISP packets, such as EIDs or RLOCs.  When
   attaching attributes to EIDs or RLOCs, it's necessary to distinguish
   between the element that should be used as EID or RLOC, and hence as
   key for lookups, and additional attributes.  This is especially the
   case when the difference cannot be determined from the types of the
   elements, such as when two IP addresses are being used.

   Key/Value Pair Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 15   |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Address as Key ...      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Address as Value ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Rsvd{1,2}:  must be set to zero and ignore on receipt.

   AFI = x:  x can be any AFI value from [AFI].  A specific AFI has its
      own encoding of either a unicast or multicast locator address.
      All RTR/ETR entries for the same level should be combined together
      by a Map-Server to avoid searching through the entire multi-level
      list of locator entries in a Map-Reply message.

   Address as Key:  this AFI encoded address will be attached with the
      attributes encoded in "Address as Value" which follows this field.

   Address as Value:  this AFI encoded address will be the attribute
      address that goes along with "Address as Key" which precedes this
      field.

4.15.  Applications for AFI List Type

4.15.1.  Binding IPv4 and IPv6 Addresses

   When header translation between IPv4 and IPv6 is desirable a LISP
   Canonical Address can use the AFI List Type to carry multiple AFIs in
   one LCAF AFI.

   Address Binding LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |         2 + 4 + 2 + 16        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |            AFI = 2            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          IPv6 Address ...                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 24 when IPv4 and IPv6 AFI
      encoded addresses are used.

   This type of address format can be included in a Map-Request when the
   address is being used as an EID, but the Mapping Database System
   lookup destination can use only the IPv4 address.  This is so a
   Mapping Database Service Transport System, such as LISP-ALT
   [RFC6836], can use the Map-Request destination address to route the
   control message to the desired LISP site.

4.15.2.  Layer-2 VPNs

   When MAC addresses are stored in the LISP Mapping Database System,
   the AFI List Type can be used to carry AFI 6.

   MAC Address LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |             2 + 6             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             AFI = 6           |    Layer-2 MAC Address  ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    ... Layer-2 MAC Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 8 when MAC address AFI encoded
      addresses are used.

   This address format can be used to connect layer-2 domains together
   using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN.
   In this use-case, a MAC address is being used as an EID, and the
   locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or
   even another MAC address being used as an RLOC.

4.15.3.  ASCII Names in the Mapping Database

   If DNS names or URIs are stored in the LISP Mapping Database System,
   the AFI List Type can be used to carry an ASCII string where it is
   delimited by length 'n' of the LCAF Length encoding.

   ASCII LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |             2 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             AFI = 17          |      DNS Name or URI  ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes AFI=17 field and the null-terminated
      ASCII string (the last byte of 0 is included).

4.15.4.  Using Recursive LISP Canonical Address Encodings

   When any combination of above is desirable, the AFI List Type value
   can be used to carry within the LCAF AFI another LCAF AFI.

   Recursive LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |         4 + 8 + 2 + 4         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 4    |     Rsvd2     |              12               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   IP TOS, IPv6 QQS or Flow Label              |    Protocol   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Local Port          |         Remote Port           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 18 when an AFI=1 IPv4 address is
      included.

   This format could be used by a Mapping Database Transport System,
   such as LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as
   an EID and placed in the Map-Request destination address by the
   sending LISP system.  The ALT system can deliver the Map-Request to
   the LISP destination site independent of the Application Data Type
   AFI payload values.  When this AFI is processed by the destination
   LISP site, it can return different locator-sets based on the type of
   application or level of service that is being requested.

4.15.5.  Compatibility Mode Use Case

   A LISP system should use the AFI List Type format when sending to
   LISP systems that do not support a particular LCAF Type used to
   encode locators.  This allows the receiving system to be able to
   parse a locator address for encapsulation purposes.  The list of AFIs
   in an AFI List LCAF Type has no semantic ordering and a receiver
   should parse each AFI element no matter what the ordering.

   Compatibility Mode Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |            22 + 6             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 5    |     Rsvd2     |            12 + 2             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|     Latitude Degrees        |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |E|     Longitude Degrees       |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Altitude                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = 0          |           AFI = 1             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          IPv4 Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If a system does not recognized the Geo Coordinate LCAF Type that is
   accompanying a locator address, an encoder can include the Geo
   Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI
   in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in
   the list is encoded with a valid AFI value to identify the locator
   address.

   A LISP system is required to support the AFI List LCAF Type to use
   this procedure.  It would skip over 10 bytes of the Geo Coordinate
   LCAF Type to get to the locator address encoding (an IPv4 locator
   address).  A LISP system that does support the Geo Coordinate LCAF
   Type can support parsing the locator address within the Geo
   Coordinate LCAF encoding or in the locator encoding that follows in
   the AFI List LCAF.

5.  Security Considerations

   There are no security considerations for this specification.  The
   security considerations are documented for the protocols that use
   LISP Canonical Addressing.  Refer to the those relevant
   specifications.

6.  IANA Considerations

   The Address Family AFI definitions from [AFI] only allocate code-
   points for the AFI value itself.  The length of the address or entity
   that follows is not defined and is implied based on conventional
   experience.  Where the LISP protocol uses LISP Canonical Addresses
   specifically, the address length definitions will be in this
   specification and take precedent over any other specification.

   An IANA Registry for LCAF Type values will be created.  The values
   that are considered for use by the main LISP specification [RFC6830]
   will be in the IANA Registry.  Other Type values used for
   experimentation will be defined and described in this document.

7.  References

7.1.  Normative References

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              January 2013.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, January 2013.

7.2.  Informative References

   [AFI]      IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [JSON-BINARY]
              "Universal Binary JSON Specification",
              URL http://ubjson.org.

   [LISP-DDT]
              Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated
              Database Tree", draft-ietf-lisp-ddt-01.txt (work in
              progress).

   [LISP-MRSIG]
              Farinacci, D. and M. Napierala, "LISP Control-Plane
              Multicast Signaling",
              draft-farinacci-lisp-mr-signaling-03.txt (work in
              progress).

   [LISP-NATT]
              Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
              F., and C. White, "NAT traversal for LISP",
              draft-ermagan-lisp-nat-traversal-03.txt (work in
              progress).

   [LISP-RE]  Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
              Maino, F., and D. Farinacci, "LISP Replication
              Engineering", draft-coras-lisp-re-03.txt (work in
              progress).

   [LISP-TE]  Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic
              Engineering Use-Cases", draft-farinacci-lisp-te-03.txt
              (work in progress).

   [WGS-84]   Geodesy and Geophysics Department, DoD., "World Geodetic
              System 1984", NIMA TR8350.2, January 2000, <http://
              earth-info.nga.mil/GandG/publications/tr8350.2/
              wgs84fin.pdf>.

Appendix A.  Acknowledgments

   The authors would like to thank Vince Fuller, Gregg Schudel, Jesper
   Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for
   their technical and editorial commentary.

   The authors would like to thank Victor Moreno for discussions that
   lead to the definition of the Multicast Info LCAF type.

   The authors would like to thank Parantap Lahiri and Michael Kowal for
   discussions that lead to the definition of the Explicit Locator Path
   (ELP) LCAF type.

   The authors would like to thank Fabio Maino and Vina Ermagan for
   discussions that lead to the definition of the Security Key LCAF
   type.

   The authors would like to thank Albert Cabellos-Aparicio and Florin
   Coras for discussions that lead to the definition of the Replication
   List Entry LCAF type.

   Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for
   suggesting new LCAF types.

   Thanks also goes to Terry Manderson for assistance obtaining a LISP
   AFI value from IANA.

Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-lcaf-04.txt

   o  Submitted January 2014.

   o  Agreement among ELP implementors to have the AFI 16-bit field
      adjacent to the address.  This will make the encoding consistent
      with all other LCAF type address encodings.

B.2.  Changes to draft-ietf-lisp-lcaf-03.txt

   o  Submitted September 2013.

   o  Updated references and author's affilations.

   o  Added Instance-ID to the Multicast Info Type so there is relative
      ease in parsing (S,G) entries within a VPN.

   o  Add port range encodings to the Application Data LCAF Type.

   o  Add a new JSON LCAF Type.

   o  Add Address Key/Value LCAF Type to allow attributes to be attached
      to an address.

B.2.

B.3.  Changes to draft-ietf-lisp-lcaf-02.txt

   o  Submitted March 2013.

   o  Added new LCAF Type "Replication List Entry" to support LISP
      replication engineering use-cases.

   o  Changed references to new LISP RFCs.

B.3.

B.4.  Changes to draft-ietf-lisp-lcaf-01.txt

   o  Submitted January 2013.

   o  Change longitude range from 0-90 to 0-180 in section 4.4.

   o  Added reference to WGS-84 in section 4.4.

B.4.

B.5.  Changes to draft-ietf-lisp-lcaf-00.txt

   o  Posted first working group draft August 2012.

   o  This draft was renamed from draft-farinacci-lisp-lcaf-10.txt.

Authors' Addresses

   Dino Farinacci
   lispers.net
   San Jose, CA
   USA

   Email: farinacci@gmail.com

   Dave Meyer
   Brocade
   San Jose, CA
   USA

   Email: dmm@1-4-5.net

   Job Snijders
   Hibernia Networks
   Tupolevlaan 103a
   Schiphol-Rijk,   1119 PA
   NL

   Email: job.snijders@hibernianetworks.com
--Apple-Mail=_0C40D60C-3756-44B6-9D43-88F9154083DD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_0C40D60C-3756-44B6-9D43-88F9154083DD Content-Disposition: attachment; filename=draft-ietf-lisp-lcaf-04.txt Content-Type: text/plain; name="draft-ietf-lisp-lcaf-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental D. Meyer Expires: July 31, 2014 Brocade J. Snijders Hibernia Networks January 27, 2014 LISP Canonical Address Format (LCAF) draft-ietf-lisp-lcaf-04 Abstract This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 31, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Farinacci, et al. Expires July 31, 2014 [Page 1] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 8 4.3. Convey Application Specific Data . . . . . . . . . . . . . 9 4.4. Assigning Geo Coordinates to Locator Addresses . . . . . . 10 4.5. Generic Database Mapping Lookups . . . . . . . . . . . . . 12 4.6. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13 4.7. PETR Admission Control Functionality . . . . . . . . . . . 15 4.8. Multicast Group Membership Information . . . . . . . . . . 16 4.9. Traffic Engineering using Re-encapsulating Tunnels . . . . 18 4.10. Storing Security Data in the Mapping Database . . . . . . 19 4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . . 20 4.12. Replication List Entries for Multicast Forwarding . . . . 21 4.13. Data Model Encoding . . . . . . . . . . . . . . . . . . . 22 4.14. Encoding Key/Value Address Pairs . . . . . . . . . . . . . 23 4.15. Applications for AFI List Type . . . . . . . . . . . . . . 23 4.15.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 23 4.15.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 25 4.15.3. ASCII Names in the Mapping Database . . . . . . . . . 25 4.15.4. Using Recursive LISP Canonical Address Encodings . . 26 4.15.5. Compatibility Mode Use Case . . . . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 32 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 33 B.1. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . . 33 B.2. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . . 33 B.3. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 33 B.4. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 33 B.5. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Farinacci, et al. Expires July 31, 2014 [Page 2] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 1. Introduction The LISP architecture and protocols [RFC6830] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) which are intended to replace most use of IP addresses on the Internet. To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI), length, and value fields. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: IPv4 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 2 | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document describes the currently-defined AFIs the LISP protocol uses along with their encodings and introduces the LISP Canonical Address Format (LCAF) that can be used to define the LISP-specific encodings for arbitrary AFI values. Farinacci, et al. Expires July 31, 2014 [Page 3] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 2. Definition of Terms Address Family Identifier (AFI): a term used to describe an address encoding in a packet. An address family currently defined for IPv4 or IPv6 addresses. See [AFI] and [RFC1700] for details. The reserved AFI value of 0 is used in this specification to indicate an unspecified encoded address where the the length of the address is 0 bytes following the 16-bit AFI value of 0. Unspecified Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Farinacci, et al. Expires July 31, 2014 [Page 4] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 3. LISP Canonical Address Format Encodings IANA has assigned AFI value 16387 (0x4003) to the LISP architecture and protocols. This specification defines the encoding format of the LISP Canonical Address (LCA). The first 4 bytes of an LISP Canonical Address are followed by a variable length of fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Flags: this 8-bit field is for future definition and use. For now, set to zero on transmission and ignored on receipt. Type: this 8-bit field is specific to the LISP Canonical Address formatted encodings, values are: Type 0: Null Body Type Type 1: AFI List Type Type 2: Instance ID Type Type 3: AS Number Type Type 4: Application Data Type Type 5: Geo Coordinates Type Type 6: Opaque Key Type Type 7: NAT-Traversal Type Type 8: Nonce Locator Type Type 9: Multicast Info Type Farinacci, et al. Expires July 31, 2014 [Page 5] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 Type 10: Explicit Locator Path Type Type 11: Security Key Type Type 12: Source/Dest Key Type Type 13: Replication List Entry Type Type 14: JSON Data Model Type Type 15: Key/Value Address Pair Type Rsvd2: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. So any LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Reserved, and Length fields. When the AFI is not next to encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Reserved, and Length fields. Farinacci, et al. Expires July 31, 2014 [Page 6] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4. LISP Canonical Address Applications 4.1. Segmentation using LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces must remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. Another use for the Instance ID LISP Canonical Address Format is when creating multiple segmented VPNs inside of a LISP site where keeping EID-prefix based subnets is desirable. Instance ID LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 2 | IID mask-len | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IID mask-len: if the AFI is set to 0, then this format is not encoding an extended EID-prefix but rather an instance-ID range where the 'IID mask-len' indicates the number of high-order bits used in the Instance ID field for the range. Length value n: length in bytes of the AFI address that follows the Instance ID field including the AFI field itself. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. AFI =3D x: x can be any AFI value from [AFI]. This LISP Canonical Address Type can be used to encode either EID or RLOC addresses. Farinacci, et al. Expires July 31, 2014 [Page 7] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.2. Carrying AS Numbers in the Mapping Database When an AS number is stored in the LISP Mapping Database System for either policy or documentation reasons, it can be encoded in a LISP Canonical Address. AS Number LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 3 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the AS Number field including the AFI field itself. AS Number: the 32-bit AS number of the autonomous system that has been assigned either the EID or RLOC that follows. AFI =3D x: x can be any AFI value from [AFI]. The AS Number Canonical Address Type can be used to encode either EID or RLOC addresses. The former is used to describe the LISP-ALT AS number the EID-prefix for the site is being carried for. The latter is used to describe the AS that is carrying RLOC based prefixes in the underlying routing system. Farinacci, et al. Expires July 31, 2014 [Page 8] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.3. Convey Application Specific Data When a locator-set needs to be conveyed based on the type of application or the Per-Hop Behavior (PHB) of a packet, the Application Data Type can be used. Application Data LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 8 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 TC, or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Application Data fields including the AFI field itself. IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow Label used in an IPv6 header. Local Port/Remote Port Ranges: these fields are from the TCP, UDP, or SCTP transport header. A range can be specified by using a lower value and an upper value. When a single port is encoded, the lower and upper value fields are the same. AFI =3D x: x can be any AFI value from [AFI]. The Application Data Canonical Address Type is used for an EID encoding when an ITR wants a locator-set for a specific application. When used for an RLOC encoding, the ETR is supplying a locator-set for each specific application is has been configured to advertise. Farinacci, et al. Expires July 31, 2014 [Page 9] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.4. Assigning Geo Coordinates to Locator Addresses If an ETR desires to send a Map-Reply describing the Geo Coordinates for each locator in its locator-set, it can use the Geo Coordinate Type to convey physical location information. Coordinates are specified using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]. Geo Coordinate LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Longitude and Latitude fields including the AFI field itself. N: When set to 1 means North, otherwise South. Latitude Degrees: Valid values range from 0 to 90 degrees above or below the equator (northern or southern hemisphere, respectively). Latitude Minutes: Valid values range from 0 to 59. Latitude Seconds: Valid values range from 0 to 59. E: When set to 1 means East, otherwise West. Longitude Degrees: Value values are from 0 to 180 degrees right or left of the Prime Meridian. Farinacci, et al. Expires July 31, 2014 [Page 10] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 Longitude Minutes: Valid values range from 0 to 59. Longitude Seconds: Valid values range from 0 to 59. Altitude: Height relative to sea level in meters. This is a signed integer meaning that the altitude could be below sea level. A value of 0x7fffffff indicates no Altitude value is encoded. AFI =3D x: x can be any AFI value from [AFI]. The Geo Coordinates Canonical Address Type can be used to encode either EID or RLOC addresses. When used for EID encodings, you can determine the physical location of an EID along with the topological location by observing the locator-set. Farinacci, et al. Expires July 31, 2014 [Page 11] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.5. Generic Database Mapping Lookups When the LISP Mapping Database system holds information accessed by a generic formatted key (where the key is not the usual IPv4 or IPv6 address), an opaque key may be desirable. Opaque Key LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 6 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Field Num | Key Wildcard Fields | Key . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the type's payload. The value n is the number of bytes that follow this Length field. Key Field Num: the number of fields (minus 1) the key can be broken up into. The width of the fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 bytes in length. Valid values for this field range from 0 to 15 supporting a maximum of 16 field separations. Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, right-justified in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and should not be considered as part of the database lookup. When the entire 16-bits is set to 0, then all bits of the key are used for the database lookup. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (shown above) minus 3. Farinacci, et al. Expires July 31, 2014 [Page 12] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.6. NAT Traversal Scenarios When a LISP system is conveying global address and mapped port information when traversing through a NAT device, the NAT-Traversal LCAF Type is used. See [LISP-NATT] for details. NAT-Traversal Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 7 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MS UDP Port Number | ETR UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Global ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | MS RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Private ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI addresses that follows the UDP Port Number field including the AFI fields themselves. MS UDP Port Number: this is the UDP port number of the Map-Server and is set to 4342. ETR UDP Port Number: this is the port number returned to a LISP system which was copied from the source port from a packet that has flowed through a NAT device. AFI =3D x: x can be any AFI value from [AFI]. Global ETR RLOC Address: this is an address known to be globally unique built by NAT-traversal functionality in a LISP router. MS RLOC Address: this is the address of the Map-Server used in the destination RLOC of a packet that has flowed through a NAT device. Farinacci, et al. Expires July 31, 2014 [Page 13] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 Private ETR RLOC Address: this is an address known to be a private address inserted in this LCAF format by a LISP router that resides on the private side of a NAT device. RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NTR addresses supplied in these set of fields. The number of NTRs encoded is determined by the LCAF length field. When there are no NTRs supplied, the NTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero NTRs encoded. Farinacci, et al. Expires July 31, 2014 [Page 14] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.7. PETR Admission Control Functionality When a public PETR device wants to verify who is encapsulating to it, it can check for a specific nonce value in the LISP encapsulated packet. To convey the nonce to admitted ITRs or PITRs, this LCAF format is used in a Map-Register or Map-Reply locator-record. Nonce Locator Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the Nonce field including the AFI field itself. Reserved: must be set to zero and ignore on receipt. Nonce: this is a nonce value returned by an ETR in a Map-Reply locator-record to be used by an ITR or PITR when encapsulating to the locator address encoded in the AFI field of this LCAF type. AFI =3D x: x can be any AFI value from [AFI]. Farinacci, et al. Expires July 31, 2014 [Page 15] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.8. Multicast Group Membership Information Multicast group information can be published in the mapping database so a lookup on an EID based group address can return a replication list of group addresses or a unicast addresses for single replication or multiple head-end replications. The intent of this type of unicast replication is to deliver packets to multiple ETRs at receiver LISP multicast sites. The locator-set encoding for this EID record type can be a list of ETRs when they each register with "Merge Semantics". The encoding can be a typical AFI encoded locator address. When an RTR list is being registered (with multiple levels according to [LISP-RE]), the Replication List Entry LCAF type is used for locator encoding. This LCAF encoding can be used to send broadcast packets to all members of a subnet when each EIDs are away from their home subnet location. Multicast Info Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 9 | Rsvd2 |R|L|J| 8 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source MaskLen| Group MaskLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source/Subnet Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Group Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. R-bit: this is the RP-bit that represents PIM (S,G,RP-bit) multicast state. This bit can be set for Joins (when the J-bit is set) or for Leaves (when the L-bit is set). See [LISP-MRSIG] for more usage details. Farinacci, et al. Expires July 31, 2014 [Page 16] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 L-bit: this is the Leave-Request bit and is used when this LCAF type is present in the destination EID-prefix field of a Map-Request. See [LISP-MRSIG] for details. J-bit: this is the Join-Request bit and is used when this LCAF type is present in the destination EID-prefix field of a Map-Request. See [LISP-MRSIG] for details. The J-bit MUST not be set when the L-bit is also set in the same LCAF block. A receiver should not take any specific Join or Leave action when both bits are set. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The use of the Instance-ID in this LCAF type is to associate a multicast forwarding entry for a given VPN. The instance-ID describes the VPN and is registered to the mapping database system as a 3-tuple of (Instance-ID, S-prefix, G-prefix). Source MaskLen: the mask length of the source prefix that follows. Group MaskLen: the mask length of the group prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Farinacci, et al. Expires July 31, 2014 [Page 17] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.9. Traffic Engineering using Re-encapsulating Tunnels For a given EID lookup into the mapping database, this LCAF format can be returned to provide a list of locators in an explicit re- encapsulation path. See [LISP-TE] for details. Explicit Locator Path (ELP) Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 10 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Lookup bit (L): this is the Lookup bit used to indicate to the user of the ELP to not use this address for encapsulation but to look it up in the mapping database system to obtain an encapsulating RLOC address. RLOC-Probe bit (P): this is the RLOC-probe bit which means the Reencap Hop allows RLOC-probe messages to be sent to it. When the R-bit is set to 0, RLOC-probes must not be sent. When a Reencap Hop is an anycast address then multiple physical Reencap Hops are using the same RLOC address. In this case, RLOC-probes are not needed because when the closest RLOC address is not reachable another RLOC address can reachable. Strict bit (S): this the strict bit which means the associated Rencap Hop is required to be used. If this bit is 0, the reencapsulator can skip this Reencap Hop and go to the next one in the list. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Farinacci, et al. Expires July 31, 2014 [Page 18] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.10. Storing Security Data in the Mapping Database When a locator in a locator-set has a security key associated with it, this LCAF format will be used to encode key material. See [LISP-DDT] for details. Security Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that start with the Key Material field. Key Count: the Key Count field declares the number of Key sections included in this LCAF. Key Algorithm: the Algorithm field identifies the key's cryptographic algorithm and specifies the format of the Public Key field. R bit: this is the revoke bit and, if set, it specifies that this Key is being Revoked. Key Length: this field determines the length in bytes of the Key Material field. Key Material: the Key Material field stores the key material. The format of the key material stored depends on the Key Algorithm field. AFI =3D x: x can be any AFI value from [AFI].This is the locator address that owns the encoded security key. Farinacci, et al. Expires July 31, 2014 [Page 19] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.11. Source/Destination 2-Tuple Lookups When both a source and destination address of a flow needs consideration for different locator-sets, this 2-tuple key is used in EID fields in LISP control messages. When the Source/Dest key is registered to the mapping database, it can be encoded as a source- prefix and destination-prefix. When the Source/Dest is used as a key for a mapping database lookup the source and destination come from a data packet. Source/Dest Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 12 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source-ML | Dest-ML | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Destination-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Source-ML: the mask length of the source prefix that follows. Dest-ML: the mask length of the destination prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Refer to [LISP-TE] for usage details. Farinacci, et al. Expires July 31, 2014 [Page 20] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.12. Replication List Entries for Multicast Forwarding The Replication List Entry LCAF type is an encoding for a locator being used for unicast replication according to the specification in [LISP-RE]. This locator encoding is pointed to by a Multicast Info LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs) that are participating in an overlay distribution tree. Each RTR will register its locator address and its configured level in the distribution tree. Replication List Entry Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 13 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. Level Value: this value is associated with the level within the overlay distribution tree hierarchy where the RTR resides. The level numbers are ordered from lowest value being close to the ITR (meaning that ITRs replicate to level-0 RTRs) and higher levels are further downstream on the distribution tree closer to ETRs of multicast receiver sites. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Farinacci, et al. Expires July 31, 2014 [Page 21] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.13. Data Model Encoding This type allows a JSON data model to be encoded either as an EID or RLOC. JSON Data Model Type Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 14 | Rsvd2 |B| n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JSON binary or text encoding ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Optional Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2}: must be set to zero and ignore on receipt. B bit: indicates that the JSON field is binary encoded according to [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is based on text encoding according to [RFC4627]. JSON field: a variable length field that contains either binary or text encodings. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Farinacci, et al. Expires July 31, 2014 [Page 22] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.14. Encoding Key/Value Address Pairs The Key/Value pair is for example useful for attaching attributes to other elements of LISP packets, such as EIDs or RLOCs. When attaching attributes to EIDs or RLOCs, it's necessary to distinguish between the element that should be used as EID or RLOC, and hence as key for lookups, and additional attributes. This is especially the case when the difference cannot be determined from the types of the elements, such as when two IP addresses are being used. Key/Value Pair Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 15 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Key ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2}: must be set to zero and ignore on receipt. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Address as Key: this AFI encoded address will be attached with the attributes encoded in "Address as Value" which follows this field. Address as Value: this AFI encoded address will be the attribute address that goes along with "Address as Key" which precedes this field. 4.15. Applications for AFI List Type 4.15.1. Binding IPv4 and IPv6 Addresses When header translation between IPv4 and IPv6 is desirable a LISP Canonical Address can use the AFI List Type to carry multiple AFIs in one LCAF AFI. Farinacci, et al. Expires July 31, 2014 [Page 23] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 Address Binding LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 4 + 2 + 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | AFI =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI encoded addresses are used. This type of address format can be included in a Map-Request when the address is being used as an EID, but the Mapping Database System lookup destination can use only the IPv4 address. This is so a Mapping Database Service Transport System, such as LISP-ALT [RFC6836], can use the Map-Request destination address to route the control message to the desired LISP site. Farinacci, et al. Expires July 31, 2014 [Page 24] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.15.2. Layer-2 VPNs When MAC addresses are stored in the LISP Mapping Database System, the AFI List Type can be used to carry AFI 6. MAC Address LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 6 | Layer-2 MAC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 8 when MAC address AFI encoded addresses are used. This address format can be used to connect layer-2 domains together using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. In this use-case, a MAC address is being used as an EID, and the locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or even another MAC address being used as an RLOC. 4.15.3. ASCII Names in the Mapping Database If DNS names or URIs are stored in the LISP Mapping Database System, the AFI List Type can be used to carry an ASCII string where it is delimited by length 'n' of the LCAF Length encoding. ASCII LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 17 | DNS Name or URI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires July 31, 2014 [Page 25] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 Length value n: length in bytes AFI=3D17 field and the = null-terminated ASCII string (the last byte of 0 is included). 4.15.4. Using Recursive LISP Canonical Address Encodings When any combination of above is desirable, the AFI List Type value can be used to carry within the LCAF AFI another LCAF AFI. Recursive LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 4 + 8 + 2 + 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 QQS or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port | Remote Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 18 when an AFI=3D1 IPv4 address = is included. This format could be used by a Mapping Database Transport System, such as LISP-ALT [RFC6836], where the AFI=3D1 IPv4 address is used as an EID and placed in the Map-Request destination address by the sending LISP system. The ALT system can deliver the Map-Request to the LISP destination site independent of the Application Data Type AFI payload values. When this AFI is processed by the destination LISP site, it can return different locator-sets based on the type of application or level of service that is being requested. Farinacci, et al. Expires July 31, 2014 [Page 26] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 4.15.5. Compatibility Mode Use Case A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators. This allows the receiving system to be able to parse a locator address for encapsulation purposes. The list of AFIs in an AFI List LCAF Type has no semantic ordering and a receiver should parse each AFI element no matter what the ordering. Compatibility Mode Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 22 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | AFI =3D 1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a system does not recognized the Geo Coordinate LCAF Type that is accompanying a locator address, an encoder can include the Geo Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address. A LISP system is required to support the AFI List LCAF Type to use this procedure. It would skip over 10 bytes of the Geo Coordinate LCAF Type to get to the locator address encoding (an IPv4 locator address). A LISP system that does support the Geo Coordinate LCAF Type can support parsing the locator address within the Geo Coordinate LCAF encoding or in the locator encoding that follows in the AFI List LCAF. Farinacci, et al. Expires July 31, 2014 [Page 27] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 5. Security Considerations There are no security considerations for this specification. The security considerations are documented for the protocols that use LISP Canonical Addressing. Refer to the those relevant specifications. Farinacci, et al. Expires July 31, 2014 [Page 28] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 6. IANA Considerations The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. Where the LISP protocol uses LISP Canonical Addresses specifically, the address length definitions will be in this specification and take precedent over any other specification. An IANA Registry for LCAF Type values will be created. The values that are considered for use by the main LISP specification [RFC6830] will be in the IANA Registry. Other Type values used for experimentation will be defined and described in this document. Farinacci, et al. Expires July 31, 2014 [Page 29] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 7. References 7.1. Normative References [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013. 7.2. Informative References [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, Febuary 2007. [JSON-BINARY] "Universal Binary JSON Specification", URL http://ubjson.org. [LISP-DDT] Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated Database Tree", draft-ietf-lisp-ddt-01.txt (work in progress). [LISP-MRSIG] Farinacci, D. and M. Napierala, "LISP Control-Plane Multicast Signaling", draft-farinacci-lisp-mr-signaling-03.txt (work in progress). [LISP-NATT] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", draft-ermagan-lisp-nat-traversal-03.txt (work in progress). Farinacci, et al. Expires July 31, 2014 [Page 30] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", draft-coras-lisp-re-03.txt (work in progress). [LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic Engineering Use-Cases", draft-farinacci-lisp-te-03.txt (work in progress). [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", NIMA TR8350.2, January 2000, . Farinacci, et al. Expires July 31, 2014 [Page 31] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 Appendix A. Acknowledgments The authors would like to thank Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for their technical and editorial commentary. The authors would like to thank Victor Moreno for discussions that lead to the definition of the Multicast Info LCAF type. The authors would like to thank Parantap Lahiri and Michael Kowal for discussions that lead to the definition of the Explicit Locator Path (ELP) LCAF type. The authors would like to thank Fabio Maino and Vina Ermagan for discussions that lead to the definition of the Security Key LCAF type. The authors would like to thank Albert Cabellos-Aparicio and Florin Coras for discussions that lead to the definition of the Replication List Entry LCAF type. Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for suggesting new LCAF types. Thanks also goes to Terry Manderson for assistance obtaining a LISP AFI value from IANA. Farinacci, et al. Expires July 31, 2014 [Page 32] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-lcaf-04.txt o Submitted January 2014. o Agreement among ELP implementors to have the AFI 16-bit field adjacent to the address. This will make the encoding consistent with all other LCAF type address encodings. B.2. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affilations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. B.3. Changes to draft-ietf-lisp-lcaf-02.txt o Submitted March 2013. o Added new LCAF Type "Replication List Entry" to support LISP replication engineering use-cases. o Changed references to new LISP RFCs. B.4. Changes to draft-ietf-lisp-lcaf-01.txt o Submitted January 2013. o Change longitude range from 0-90 to 0-180 in section 4.4. o Added reference to WGS-84 in section 4.4. B.5. Changes to draft-ietf-lisp-lcaf-00.txt o Posted first working group draft August 2012. Farinacci, et al. Expires July 31, 2014 [Page 33] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. Farinacci, et al. Expires July 31, 2014 [Page 34] =0C Internet-Draft LISP Canonical Address Format (LCAF) January 2014 Authors' Addresses Dino Farinacci lispers.net San Jose, CA USA Email: farinacci@gmail.com Dave Meyer Brocade San Jose, CA USA Email: dmm@1-4-5.net Job Snijders Hibernia Networks Tupolevlaan 103a Schiphol-Rijk, 1119 PA NL Email: job.snijders@hibernianetworks.com Farinacci, et al. Expires July 31, 2014 [Page 35] =0C --Apple-Mail=_0C40D60C-3756-44B6-9D43-88F9154083DD-- From internet-drafts@ietf.org Mon Jan 27 10:31:45 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D20F1A0159; Mon, 27 Jan 2014 10:31:45 -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] 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 TkTd1gVjSGNS; Mon, 27 Jan 2014 10:31:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A504E1A0256; Mon, 27 Jan 2014 10:31:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127183143.28658.92641.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 10:31:43 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-lcaf-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 18:31:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP Canonical Address Format (LCAF) Authors : Dino Farinacci Dave Meyer Job Snijders Filename : draft-ietf-lisp-lcaf-04.txt Pages : 35 Date : 2014-01-27 Abstract: This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-lcaf-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-lcaf-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From david.black@emc.com Sun Jan 19 19:30:38 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531511A0023; Sun, 19 Jan 2014 19:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, 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 5JfuNn8B0eEV; Sun, 19 Jan 2014 19:30:35 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 77D8A1A001F; Sun, 19 Jan 2014 19:30:35 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0K3USCQ012964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jan 2014 22:30:31 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s0K3USCQ012964 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390188631; bh=ghRaPwbG9paVbA4AQIMVTuwKqco=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=tl47hZk9YoCepxFBFavWk7ql6RN9J666YJF4VhgMuVTogAFfEe67v3ccxw2rTXGzd GwNLpF7s1BboR9aGRGmTvGvjxvRRSw6aVaRMxxEmr/+lAlj/3GyPFlsUyYgvpNIfsR 1OC/6AscMgshcMP6RB6VUNgLq/OlcOJ5r9aLbFVw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s0K3USCQ012964 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd53.lss.emc.com (RSA Interceptor); Sun, 19 Jan 2014 22:30:13 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0K3UACp011719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Jan 2014 22:30:12 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Sun, 19 Jan 2014 22:30:10 -0500 From: "Black, David" To: Alexander Vainshtein , "stbryant@cisco.com" Date: Sun, 19 Jan 2014 22:30:08 -0500 Thread-Topic: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp) Thread-Index: Ac8Vj+sUxkixdvZlQDyGimrIKN8dNQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026F047824@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Mon, 27 Jan 2014 10:49:03 -0800 Cc: "mpls@ietf.org" , "lisp@ietf.org" , "Black, David" , Randy Bush , "tsvwg@ietf.org" , "ietf@ietf.org" Subject: [lisp] GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 03:30:38 -0000 Sasha, > But I would like to understand whether this protocol can really result in > reasonable distribution of traffic. "Reasonable" means that (a) there is > sufficient entropy and (b) that the order in specific micro-flows is > preserved. The draft skips this issue (unless you consider a recommendati= on to > use a fixed randomly selected source port value if the tunnel does not n= eed > ECMP a valid answer) . Well, there's a bit more in the draft than just a "randomly selected" value= , as the ability to use ECMP on these tunnels is rather important (text quote= d is from Section 3 in the draft): The ingress device SHOULD set the UDP source port based on flow invariant fields from the payload header, otherwise it should be set to a randomly selected constant value, e.g. zero, to avoid packet flow reordering. How a tunnel ingress generates entropy from the payload is outside the scope of this document. I suppose that more discussion and examples of "flow invariant fields" would be useful, although an attempt at a comprehensive listing would be pointless, IMHO. An important situation is one where the tunnel ingress "knows" (because the network operator actually does know) what the protocol stack(s) is/are for the encapsulated traffic (e.g., HTTP/TCP/IP/GRE/IP) and hence can find the flow-invariant fields that it wants to use for that (those) specific stack(s). With good selection of flow-invariant fields wrt traffic mix, good distribution is possible. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander Vainsh= tein > Sent: Wednesday, January 15, 2014 6:54 AM > To: stbryant@cisco.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; R= andy > Bush; jnc@mit.edu; lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gr= e-in- > udp draft (was: RE: Milestones changed for tsvwg WG)) >=20 > Stewart, and all, > I fully agree that UDP checksums is not a real-life issue with the protoc= ol in > question. They could probably help to check corrupted packets if corrupti= on > happens when a packet passes thru a router (i.e. when the ingress data li= nk > FCS has already been terminated and the egress data link FCS has not been > generated yet). But this is hopefully rare - and since MPLS does not care > about it, why should the MPLS encapsulator care? >=20 > I also do not think that congestion control is a serious issue for this > protocol, not in the least because the primary purpose of this protocol i= s > ECMP. >=20 > But I would like to understand whether this protocol can really result in > reasonable distribution of traffic. "Reasonable" means that (a) there is > sufficient entropy and (b) that the order in specific micro-flows is > preserved. The draft skips this issue (unless you consider a recommendati= on to > use a fixed randomly selected source port value if the tunnel does not n= eed > ECMP a valid answer) . >=20 > Any ideas as to how reasonable distribution of traffic can be achieved w= ith > this protocol? >=20 > Regards, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > > Sent: Wednesday, January 15, 2014 1:31 PM > > To: Randy Bush > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; > > wes@mti-systems.com; tsvwg@ietf.org; jnc@mit.edu > > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: = gre- > in- > > udp draft (was: RE: Milestones changed for tsvwg WG)) > > > > On 15/01/2014 11:08, Randy Bush wrote: > > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > > > >> it seems that there are no valid statistics for the current Internet > > >> to sustain your case. > > > as we discussed privately, there seem to be no real measurements to > > > sustain any case. this is all conjecturbation. > > > > > > what i do not understand is why, given the lack of solid evidence tha= t > > > we are in a safe space, you and others are not willing to spend a few > > > euro cents to have a reasonable level of assurance at this layer. > > > > > > randy > > Randy, > > > > It is not a few cents, it is likely the re-engineering of a lot of sili= con. > > > > The reason that UDP is of interest is that the on path silicon knows ho= w to > > process it, for example it knows how to to ECMP it. > > > > The reason that the UDP c/s is a problem for a tunneler is that it need= s to > > have access to the whole pkt to calculate the c/s, but as you know the > silicon > > optimised that access away a long time ago. > > > > The alternative would be UDP-lite, but the ability of on path silicon t= o > process > > that as competently and as completely as it processes UDP is by no mean= s > > clear. > > > > - Stewart > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Sun Jan 19 21:44:43 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902D11A0034; Sun, 19 Jan 2014 21:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 2pOvGj5Jhxfy; Sun, 19 Jan 2014 21:44:40 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) by ietfa.amsl.com (Postfix) with ESMTP id 91DF11A0023; Sun, 19 Jan 2014 21:44:36 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB531.eurprd03.prod.outlook.com (10.242.109.155) with Microsoft SMTP Server (TLS) id 15.0.851.11; Mon, 20 Jan 2014 05:44:34 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Mon, 20 Jan 2014 05:44:34 +0000 From: Alexander Vainshtein To: "Black, David" , "stbryant@cisco.com" Thread-Topic: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp) Thread-Index: Ac8Vj+sUxkixdvZlQDyGimrIKN8dNQAD35l5 Date: Mon, 20 Jan 2014 05:44:33 +0000 Message-ID: <3568aff546054a748d73d029c110c97b@AM3PR03MB532.eurprd03.prod.outlook.com> References: <8D3D17ACE214DC429325B2B98F3AE712026F047824@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026F047824@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.66.126.123] x-forefront-prvs: 00979FCB3A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(13464003)(51704005)(252514010)(24454002)(189002)(199002)(164054003)(479174003)(377454003)(81686001)(31966008)(87936001)(74876001)(74706001)(90146001)(80022001)(4396001)(47446002)(15202345003)(76576001)(87266001)(83072002)(85852003)(81542001)(74316001)(86362001)(74366001)(93516002)(81342001)(74502001)(51856001)(56816005)(47976001)(69226001)(74662001)(15975445006)(65816001)(66066001)(85306002)(2656002)(19580395003)(83322001)(19580405001)(47736001)(80976001)(92566001)(53806001)(54356001)(79102001)(46102001)(50986001)(76786001)(49866001)(54316002)(76796001)(56776001)(33646001)(93136001)(59766001)(76482001)(63696002)(77982001)(81816001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB531; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:109.66.126.123; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-Mailman-Approved-At: Mon, 27 Jan 2014 10:49:03 -0800 Cc: Randy Bush , "mpls@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" , "tsvwg@ietf.org" Subject: Re: [lisp] GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 05:44:43 -0000 David,=0A= Lots of thanks for a detailed response.=0A= =0A= My original question dealt with the MPLS-in-UDP draft, where the relevant t= ext was quite brief:=0A= =0A= =0A= Source Port of UDP =0A= =0A= This field contains a 16-bit entropy value that is =0A= generated by the ingress PE router. What algorithm is =0A= actually used by the ingress PE router to generate an =0A= entropy value is outside the scope of this doc. In the =0A= case where the flow does not need entropy, this field =0A= SHOULD be set to a randomly selected constant value to =0A= avoid packet reordering. =0A= =0A= =0A= The answer given by Eric Rosen in http://www.ietf.org/mail-archive/web/mpls= /current/msg11277.html (use the hash of the label stack of the packet to be= encapsulated ) resolves, IMO, this issue because the head-end of the UDP t= unnel (the encapsulator) looks at the label stack of the packet to be encap= sulated in any case. Of course other methods are not precluded, but there i= s at least one method that is both reasonably simple and meaningful, especi= ally because it is possible to add entropy to the label stack (RFC 6790).= =0A= =0A= In the case of GRE-in-UDP the text goes into more detail, but, IMHO and FWI= W, these details are not sufficient. AFAIK , the GRE encapsulators in most = cases follows RFC 2784 and not RFC 1701. The reduced GRE header adopted RFC= 2784 does not leave any place for meaningful "flow invariant fields" (unle= ss you count the prtotocol type as such). This means that the head-end of = the UDP tunnel has to look beyond the IP and GRE headers of the packet to b= e encapsulated for these fields - and this is something that, to the best o= f my understanding, GRE tries to prevent.=0A= =0A= My 2c,=0A= Sasha=0A= ________________________________________=0A= From: Black, David =0A= Sent: Monday, January 20, 2014 5:30 AM=0A= To: Alexander Vainshtein; stbryant@cisco.com=0A= Cc: mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; Randy Bush; lisp@ietf.org= ; Black, David=0A= Subject: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was= Re: draft-ietf-mpls-in-udp)=0A= =0A= Sasha,=0A= =0A= > But I would like to understand whether this protocol can really result in= =0A= > reasonable distribution of traffic. "Reasonable" means that (a) there is= =0A= > sufficient entropy and (b) that the order in specific micro-flows is=0A= > preserved. The draft skips this issue (unless you consider a recommendati= on to=0A= > use a fixed randomly selected source port value if the tunnel does not n= eed=0A= > ECMP a valid answer) .=0A= =0A= Well, there's a bit more in the draft than just a "randomly selected" value= ,=0A= as the ability to use ECMP on these tunnels is rather important (text quote= d=0A= is from Section 3 in the draft):=0A= =0A= The ingress device SHOULD set=0A= the UDP source port based on flow invariant fields from the payload=0A= header, otherwise it should be set to a randomly selected constant=0A= value, e.g. zero, to avoid packet flow reordering. How a tunnel=0A= ingress generates entropy from the payload is outside the scope of=0A= this document.=0A= =0A= I suppose that more discussion and examples of "flow invariant fields"=0A= would be useful, although an attempt at a comprehensive listing would be=0A= pointless, IMHO. An important situation is one where the tunnel ingress=0A= "knows" (because the network operator actually does know) what the protocol= =0A= stack(s) is/are for the encapsulated traffic (e.g., HTTP/TCP/IP/GRE/IP) and= =0A= hence can find the flow-invariant fields that it wants to use for that=0A= (those) specific stack(s).=0A= =0A= With good selection of flow-invariant fields wrt traffic mix, good=0A= distribution is possible.=0A= =0A= Thanks,=0A= --David=0A= =0A= > -----Original Message-----=0A= > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander Vainsh= tein=0A= > Sent: Wednesday, January 15, 2014 6:54 AM=0A= > To: stbryant@cisco.com=0A= > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; R= andy=0A= > Bush; jnc@mit.edu; lisp@ietf.org=0A= > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gr= e-in-=0A= > udp draft (was: RE: Milestones changed for tsvwg WG))=0A= >=0A= > Stewart, and all,=0A= > I fully agree that UDP checksums is not a real-life issue with the protoc= ol in=0A= > question. They could probably help to check corrupted packets if corrupti= on=0A= > happens when a packet passes thru a router (i.e. when the ingress data li= nk=0A= > FCS has already been terminated and the egress data link FCS has not been= =0A= > generated yet). But this is hopefully rare - and since MPLS does not care= =0A= > about it, why should the MPLS encapsulator care?=0A= >=0A= > I also do not think that congestion control is a serious issue for this= =0A= > protocol, not in the least because the primary purpose of this protocol i= s=0A= > ECMP.=0A= >=0A= > But I would like to understand whether this protocol can really result in= =0A= > reasonable distribution of traffic. "Reasonable" means that (a) there is= =0A= > sufficient entropy and (b) that the order in specific micro-flows is=0A= > preserved. The draft skips this issue (unless you consider a recommendati= on to=0A= > use a fixed randomly selected source port value if the tunnel does not n= eed=0A= > ECMP a valid answer) .=0A= >=0A= > Any ideas as to how reasonable distribution of traffic can be achieved w= ith=0A= > this protocol?=0A= >=0A= > Regards,=0A= > Sasha=0A= > Email: Alexander.Vainshtein@ecitele.com=0A= > Mobile: 054-9266302=0A= >=0A= > > -----Original Message-----=0A= > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant= =0A= > > Sent: Wednesday, January 15, 2014 1:31 PM=0A= > > To: Randy Bush=0A= > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org;= =0A= > > wes@mti-systems.com; tsvwg@ietf.org; jnc@mit.edu=0A= > > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: = gre-=0A= > in-=0A= > > udp draft (was: RE: Milestones changed for tsvwg WG))=0A= > >=0A= > > On 15/01/2014 11:08, Randy Bush wrote:=0A= > > > [ you insist on cc:ing me, so you get to endure my opinions ]=0A= > > >=0A= > > >> it seems that there are no valid statistics for the current Internet= =0A= > > >> to sustain your case.=0A= > > > as we discussed privately, there seem to be no real measurements to= =0A= > > > sustain any case. this is all conjecturbation.=0A= > > >=0A= > > > what i do not understand is why, given the lack of solid evidence tha= t=0A= > > > we are in a safe space, you and others are not willing to spend a few= =0A= > > > euro cents to have a reasonable level of assurance at this layer.=0A= > > >=0A= > > > randy=0A= > > Randy,=0A= > >=0A= > > It is not a few cents, it is likely the re-engineering of a lot of sili= con.=0A= > >=0A= > > The reason that UDP is of interest is that the on path silicon knows ho= w to=0A= > > process it, for example it knows how to to ECMP it.=0A= > >=0A= > > The reason that the UDP c/s is a problem for a tunneler is that it need= s to=0A= > > have access to the whole pkt to calculate the c/s, but as you know the= =0A= > silicon=0A= > > optimised that access away a long time ago.=0A= > >=0A= > > The alternative would be UDP-lite, but the ability of on path silicon t= o=0A= > process=0A= > > that as competently and as completely as it processes UDP is by no mean= s=0A= > > clear.=0A= > >=0A= > > - Stewart=0A= > >=0A= > >=0A= > > _______________________________________________=0A= > > mpls mailing list=0A= > > mpls@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/mpls=0A= =0A= From david.black@emc.com Mon Jan 20 09:28:00 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46AD1A01B2; Mon, 20 Jan 2014 09:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 pJfcwtG2YSN4; Mon, 20 Jan 2014 09:27:57 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 73EA61A01A2; Mon, 20 Jan 2014 09:27:57 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0KHPgUZ032284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jan 2014 12:25:45 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s0KHPgUZ032284 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390238746; bh=RT/4T7uY/z4f6y23zmetvQNNNGE=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=SmTvDHLET61jTrFQ8/uI2oOJnpXmf0fGcQat+JhguuD9mf8wAVFX1z+Lzf6XTaJsT PLaCyYmlMtTT/PbalgUJwq2KTjXChROpjjW47gY/Fh90innGucbJ1iqB901UMoI0wI cK+DqvbAAuq9V2nyII61o+JD19Y63CT1DFE1Ff70= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s0KHPgUZ032284 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 20 Jan 2014 09:25:32 -0800 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0KHPTsH019845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jan 2014 12:25:31 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Mon, 20 Jan 2014 12:25:28 -0500 From: "Black, David" To: Alexander Vainshtein , "stbryant@cisco.com" Date: Mon, 20 Jan 2014 12:25:28 -0500 Thread-Topic: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp) Thread-Index: Ac8Vj+sUxkixdvZlQDyGimrIKN8dNQAD35l5ABkZW3A= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026F04796A@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712026F047824@MX15A.corp.emc.com> <3568aff546054a748d73d029c110c97b@AM3PR03MB532.eurprd03.prod.outlook.com> In-Reply-To: <3568aff546054a748d73d029c110c97b@AM3PR03MB532.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Mon, 27 Jan 2014 10:49:03 -0800 Cc: "mpls@ietf.org" , "lisp@ietf.org" , "Black, David" , Randy Bush , "tsvwg@ietf.org" , "ietf@ietf.org" Subject: Re: [lisp] GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 17:28:01 -0000 Alex, > In the case of GRE-in-UDP the text goes into more detail, but, IMHO and F= WIW, > these details are not sufficient. AFAIK , the GRE encapsulators in most c= ases > follows RFC 2784 and not RFC 1701. The reduced GRE header adopted RFC 278= 4 > does not leave any place for meaningful "flow invariant fields" (unless y= ou > count the protocol type as such). This means that the head-end of the UD= P > tunnel has to look beyond the IP and GRE headers of the packet to be > encapsulated for these fields - and this is something that, to the best o= f my > understanding, GRE tries to prevent. My understanding of the intent of the GRE in UDP draft is that the encapsul= ator really has to look beyond the GRE header to set the UDP source port in orde= r to get load balancing. E.g., for MPLS/GRE/UDP, the ECMP hash for MPLS would b= e the basis for setting the UDP source port in a fashion analogous to Eric's = message. This requires encapsulators that can do that, and do analogous things for o= ther protocol stacks above GRE (e.g., those that do not use MPLS). Thanks, --David > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, January 20, 2014 12:45 AM > To: Black, David; stbryant@cisco.com > Cc: mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; Randy Bush; lisp@ietf.o= rg > Subject: RE: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] O= T > (was Re: draft-ietf-mpls-in-udp) >=20 > David, > Lots of thanks for a detailed response. >=20 > My original question dealt with the MPLS-in-UDP draft, where the relevant= text > was quite brief: >=20 > > Source Port of UDP >=20 > This field contains a 16-bit entropy value that is > generated by the ingress PE router. What algorithm is > actually used by the ingress PE router to generate an > entropy value is outside the scope of this doc. In the > case where the flow does not need entropy, this field > SHOULD be set to a randomly selected constant value to > avoid packet reordering. > >=20 > The answer given by Eric Rosen in http://www.ietf.org/mail- > archive/web/mpls/current/msg11277.html (use the hash of the label stack o= f the > packet to be encapsulated ) resolves, IMO, this issue because the head-en= d of > the UDP tunnel (the encapsulator) looks at the label stack of the packet = to be > encapsulated in any case. Of course other methods are not precluded, but = there > is at least one method that is both reasonably simple and meaningful, > especially because it is possible to add entropy to the label stack (RFC > 6790). >=20 > In the case of GRE-in-UDP the text goes into more detail, but, IMHO and F= WIW, > these details are not sufficient. AFAIK , the GRE encapsulators in most c= ases > follows RFC 2784 and not RFC 1701. The reduced GRE header adopted RFC 278= 4 > does not leave any place for meaningful "flow invariant fields" (unless y= ou > count the prtotocol type as such). This means that the head-end of the U= DP > tunnel has to look beyond the IP and GRE headers of the packet to be > encapsulated for these fields - and this is something that, to the best o= f my > understanding, GRE tries to prevent. >=20 > My 2c, > Sasha > ________________________________________ > From: Black, David > Sent: Monday, January 20, 2014 5:30 AM > To: Alexander Vainshtein; stbryant@cisco.com > Cc: mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; Randy Bush; lisp@ietf.o= rg; > Black, David > Subject: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (w= as > Re: draft-ietf-mpls-in-udp) >=20 > Sasha, >=20 > > But I would like to understand whether this protocol can really result = in > > reasonable distribution of traffic. "Reasonable" means that (a) there i= s > > sufficient entropy and (b) that the order in specific micro-flows is > > preserved. The draft skips this issue (unless you consider a recommenda= tion > to > > use a fixed randomly selected source port value if the tunnel does not= need > > ECMP a valid answer) . >=20 > Well, there's a bit more in the draft than just a "randomly selected" val= ue, > as the ability to use ECMP on these tunnels is rather important (text quo= ted > is from Section 3 in the draft): >=20 > The ingress device SHOULD set > the UDP source port based on flow invariant fields from the payload > header, otherwise it should be set to a randomly selected constant > value, e.g. zero, to avoid packet flow reordering. How a tunnel > ingress generates entropy from the payload is outside the scope of > this document. >=20 > I suppose that more discussion and examples of "flow invariant fields" > would be useful, although an attempt at a comprehensive listing would be > pointless, IMHO. An important situation is one where the tunnel ingress > "knows" (because the network operator actually does know) what the protoc= ol > stack(s) is/are for the encapsulated traffic (e.g., HTTP/TCP/IP/GRE/IP) a= nd > hence can find the flow-invariant fields that it wants to use for that > (those) specific stack(s). >=20 > With good selection of flow-invariant fields wrt traffic mix, good > distribution is possible. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander > Vainshtein > > Sent: Wednesday, January 15, 2014 6:54 AM > > To: stbryant@cisco.com > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; > Randy > > Bush; jnc@mit.edu; lisp@ietf.org > > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: = gre- > in- > > udp draft (was: RE: Milestones changed for tsvwg WG)) > > > > Stewart, and all, > > I fully agree that UDP checksums is not a real-life issue with the prot= ocol > in > > question. They could probably help to check corrupted packets if corrup= tion > > happens when a packet passes thru a router (i.e. when the ingress data = link > > FCS has already been terminated and the egress data link FCS has not be= en > > generated yet). But this is hopefully rare - and since MPLS does not ca= re > > about it, why should the MPLS encapsulator care? > > > > I also do not think that congestion control is a serious issue for this > > protocol, not in the least because the primary purpose of this protocol= is > > ECMP. > > > > But I would like to understand whether this protocol can really result = in > > reasonable distribution of traffic. "Reasonable" means that (a) there i= s > > sufficient entropy and (b) that the order in specific micro-flows is > > preserved. The draft skips this issue (unless you consider a recommenda= tion > to > > use a fixed randomly selected source port value if the tunnel does not= need > > ECMP a valid answer) . > > > > Any ideas as to how reasonable distribution of traffic can be achieved= with > > this protocol? > > > > Regards, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > > > Sent: Wednesday, January 15, 2014 1:31 PM > > > To: Randy Bush > > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org= ; > > > wes@mti-systems.com; tsvwg@ietf.org; jnc@mit.edu > > > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE= : > gre- > > in- > > > udp draft (was: RE: Milestones changed for tsvwg WG)) > > > > > > On 15/01/2014 11:08, Randy Bush wrote: > > > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > > > > > >> it seems that there are no valid statistics for the current Intern= et > > > >> to sustain your case. > > > > as we discussed privately, there seem to be no real measurements to > > > > sustain any case. this is all conjecturbation. > > > > > > > > what i do not understand is why, given the lack of solid evidence t= hat > > > > we are in a safe space, you and others are not willing to spend a f= ew > > > > euro cents to have a reasonable level of assurance at this layer. > > > > > > > > randy > > > Randy, > > > > > > It is not a few cents, it is likely the re-engineering of a lot of > silicon. > > > > > > The reason that UDP is of interest is that the on path silicon knows = how > to > > > process it, for example it knows how to to ECMP it. > > > > > > The reason that the UDP c/s is a problem for a tunneler is that it ne= eds > to > > > have access to the whole pkt to calculate the c/s, but as you know th= e > > silicon > > > optimised that access away a long time ago. > > > > > > The alternative would be UDP-lite, but the ability of on path silicon= to > > process > > > that as competently and as completely as it processes UDP is by no me= ans > > > clear. > > > > > > - Stewart > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls >=20 From farinacci@gmail.com Mon Jan 27 10:55:43 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDE41A0256 for ; Mon, 27 Jan 2014 10:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 lHGVPztt49Jx for ; Mon, 27 Jan 2014 10:55:42 -0800 (PST) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6401A02A4 for ; Mon, 27 Jan 2014 10:55:42 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id up15so6137540pbc.8 for ; Mon, 27 Jan 2014 10:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=GwSauFF2ysWPJOrf26BQbHK1Br/I5Amoe1nMIE+G/10=; b=jEOxkO9yK1sHwWdLzVwE8wBB+5MHhQssL/E3Rzs4d8z7LeJoLqxIXjxJ9v5U4rDF2k OGI7AbSe5vk3kj/6v+YJTy+cAOygm8P2sePGhS83QdRUb9HOC1LDt1LrdGedMgLAf/4N wWpxCdzljPHIlUfs9InInDgZg9ljLEnXitpdleQZndieBA/lor40tWLixTHl2iTy3g6W nMNjiYxnIjVNeUzutYs7ehruKy7GtENuPwDvy7SgU37j5+Vtj2hV/8/qWCUnFIBO/lof e0zUpB+SSfaAWG1/Oa2OLH2WOQwYna9Q8RppcPCKH4/eAc92rcNYMNCNCHP3WKbczbXh jHwQ== X-Received: by 10.68.245.162 with SMTP id xp2mr4768949pbc.69.1390848940254; Mon, 27 Jan 2014 10:55:40 -0800 (PST) Received: from [192.168.1.243] ([207.145.253.66]) by mx.google.com with ESMTPSA id sy2sm34198743pbc.28.2014.01.27.10.55.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 10:55:39 -0800 (PST) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9676AEAE-6056-4F18-824C-CDCE745096C5@gmail.com> Date: Mon, 27 Jan 2014 10:55:35 -0800 To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [lisp] Request for working group docment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 18:55:43 -0000 Draft draft-farinacci-lisp-rig-02.txt has been previously requested to = be a working group document. There wasn't overwelming conscensus to do = so, so its status was not changed for about a year or so. At this time I would like to request it to be a working group document = (and to actually bring it to last-call). RIG is a tool that seems to be = useful and many are using it to debug and monitor the DDT mapping = database transport system (and have for some time now). I would like to ask the authors to move this to a working group = docuemnt. Thanks, Dino From jmh@joelhalpern.com Mon Jan 27 11:04:14 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C181A027B for ; Mon, 27 Jan 2014 11:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 PZ_izqWiLfoe for ; Mon, 27 Jan 2014 11:04:13 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 286661A0256 for ; Mon, 27 Jan 2014 11:04:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 395A6100B3B for ; Mon, 27 Jan 2014 11:04:11 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id A74CF100B38 for ; Mon, 27 Jan 2014 11:04:10 -0800 (PST) Message-ID: <52E6ADA9.7050609@joelhalpern.com> Date: Mon, 27 Jan 2014 14:04:09 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: LISP mailing list list References: <9676AEAE-6056-4F18-824C-CDCE745096C5@gmail.com> In-Reply-To: <9676AEAE-6056-4F18-824C-CDCE745096C5@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Request for working group docment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:04:14 -0000 Assuming for the moment that the authors are willing, is there support for making this a WG document? Are there folks other than the authors who will undertake to review it? Do folks believe it is an appropriate document for the WG to produce (rather than sending it to the Independent Stream?) Yours, Joel, asking as chair On 1/27/14 1:55 PM, Dino Farinacci wrote: > Draft draft-farinacci-lisp-rig-02.txt has been previously requested to be a working group document. There wasn't overwelming conscensus to do so, so its status was not changed for about a year or so. > > At this time I would like to request it to be a working group document (and to actually bring it to last-call). RIG is a tool that seems to be useful and many are using it to debug and monitor the DDT mapping database transport system (and have for some time now). > > I would like to ask the authors to move this to a working group docuemnt. > > Thanks, > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From internet-drafts@ietf.org Fri Jan 31 05:37:40 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041D31A1F3E; Fri, 31 Jan 2014 05:37:40 -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] 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 z8vbrgmHFYvH; Fri, 31 Jan 2014 05:37:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A493C1A049B; Fri, 31 Jan 2014 05:37:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140131133738.21332.70312.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 05:37:38 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-08.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 13:37:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP EID Block Authors : Luigi Iannone Darrel Lewis David Meyer Vince Fuller Filename : draft-ietf-lisp-eid-block-08.txt Pages : 16 Date : 2014-01-31 Abstract: This is a direction to IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-eid-block-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/