From david.black@emc.com Fri Jan 3 18:04:30 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2041AE00D for ; Fri, 3 Jan 2014 18:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.161 X-Spam-Level: X-Spam-Status: No, score=0.161 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.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 mWglQogi-JXt for ; Fri, 3 Jan 2014 18:04:28 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id E3E391AE024 for ; Fri, 3 Jan 2014 18:04:27 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0424FLb004683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 21:04:16 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0424FLb004683 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1388801056; bh=9eAY6VdjQ1tBmRj6hfCYLa4ke70=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Rwxu3Fnl/iJtrAYhvzGQ72DuHSKY7AVFggGot6XypwZoSn0xI/kMPTkBZ1B49S+bB w1vgshTG4x4a4Xa5wELHaD9lvHcfwF03KXY3Cx4+xKgBErykKzXkPoambPQP0AIo+I DDcM2xHgfNp2mvLDkgd7l5imC1wjUSVhkHiA+gYw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0424FLb004683 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd54.lss.emc.com (RSA Interceptor); Fri, 3 Jan 2014 21:03:57 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0423usX029012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jan 2014 21:03:57 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Fri, 3 Jan 2014 21:03:56 -0500 From: "Black, David" To: "Subha Dhesikan (sdhesika)" , "Nguyen, An P" Date: Fri, 3 Jan 2014 21:03:55 -0500 Thread-Topic: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHO+8aJErlBSAcWG0ODmxKj8FJpKppaNXsAgABwQoCAASIF8IAYIb3Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8E@MX15A.corp.emc.com> References: <52AF0E7B.6030400@erg.abdn.ac.uk> In-Reply-To: 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: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 02:04:30 -0000 I agree with Subha - RFC 5865 (not 5856) absolutely requires admission control for all traffic that uses its capacity-admitted traffic PHB and any associated DSCP. As RTCWeb currently does not currently have mandatory admission control for any of its traffic, use of that PHB and DSCP would be inappropriate. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Subha Dhesikan > (sdhesika) > Sent: Thursday, December 19, 2013 12:34 PM > To: Nguyen, An P; gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > Thanks An Nguyen. I am sure James will share his thoughts but here is wha= t my > thoughts were when I prepared the document: >=20 > I did deliberate on whether the high priority category of the voice traff= ic > should be left aside for admitted EF. I decided against it eventually be= cause > admitted-EF brings with it the requirements of admission control. Since > there is no admission control mechanisms or discussions in this draft, it= led > to my decision to leave it out. >=20 > I believe we can discuss further on the use cases for admitted traffic in > webRTC and if needed, introduce the conditions and marking of traffic wit= h > admitted EF to a separate document. >=20 > Regards, > Subha >=20 > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Nguyen, An P > Sent: Wednesday, December 18, 2013 10:10 AM > To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > James, >=20 > After I quickly scanned through Section 5 - DSCP Mappings of the draft- > dhesikan-tsvwg-rtcweb-qos03, I have a question for you: > I wonder if this section could be expanded to include RFC 5856 - A > Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic? >=20 > Respectfully yours, >=20 > An Nguyen > DHS/OEC ( Formerly known as NCS) >=20 >=20 > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of gorry@erg.abdn.a= c.uk > Sent: Wednesday, December 18, 2013 6:28 AM > To: Ruediger.Geib@telekom.de > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > See a few thoughts in-line (with no chair-hat): >=20 > > Hi Gorry, > > > > my small contribution to discuss the TSVWG input: > > > > draft dhesikan -03 is a rather short document. It is now focused on IP > > DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP > > QCI related discussion has been removed. > > > > The authors of draft dhesikan prefer to support a wide set of DSCPs > > and suggest to support different levels of priority. The introduction > > seems to say, it is largely considered to be applied within LANs, for > > home gateway internal classification and for Wifi. That's fine with me. > > > > In the case of traffic sent to a network provider broadband access > > router / network gateway, I doubt that too many markings make sense. > > I'd expect the network provider routers or gateways not to trust > > DiffServ markings sent by a consumer device. The draft doesn't mention > > that. Adding such a note may be useful. > > > Personally I'd agree - it would be useful to describe this context >=20 > > As I'm known for simplistic approaches, my take is to mark traffic > > sent by a home gateway to a provider policy point by two DSCPs only, > > Best Effort and an AF PHB. I agree however with the authors, that a > > Home Gateway could and should internally apply a much more fine > > grained QoS differentiation for upstream traffic. If all home network > > devices apply proper markings as suggested by the authors, this may hel= p. > > >=20 > I think it would be useful to say that each DSCP by a single app require = a way > for the app or transport to know which work appropriately along that path= . > Especially when traffic is dynamically moved between different PHB groups= . >=20 > The fact that many deployed networks support a small set of DSCPs is wort= h I > think a mention. To me this has some implications, e.g. when the App sets= EF > or CS1 and networks supports just AF and BE - intended precedence would t= hen > rely upon correct treatment or re-marking. If this were not appropriate, = then > the loss will depend upon whether it was before or after the DSCPs were > interpreted as intended. >=20 > > If there's interest to approach the 3GPP community for a discussion on > > a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help. > > This should be documented in a separate draft, as I'd expect this > > inter SDO work to consume a fair amount of time. > > > > Regards and seasonal greetings, > > > > Ruediger > > > > > > > Gorry >=20 >=20 >=20 From gorry@erg.abdn.ac.uk Mon Jan 6 07:33:23 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50391AE042 for ; Mon, 6 Jan 2014 07:33:23 -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 ehywKSq-yYNq for ; Mon, 6 Jan 2014 07:33:22 -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 F06221AE043 for ; Mon, 6 Jan 2014 07:33:21 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id E2C082B44CC; Mon, 6 Jan 2014 15:33:12 +0000 (GMT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 61A5E2B41ED for ; Mon, 6 Jan 2014 15:33:12 +0000 (GMT) Message-ID: <52CACCB8.4020202@erg.abdn.ac.uk> Date: Mon, 06 Jan 2014 15:33:12 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: tsvwg@ietf.org References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] Working Group Adoption of: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 15:33:24 -0000 This email confirms consensus for adoption of draft-yong-tsvwg-gre-in-udp-encap as a basis for work in tsvwg on a UDP encapsulation of GRE: This document describes a method of encapsulating arbitrary protocols within GRE and UDP headers. In this encapsulation, the source UDP port may be used as an entropy field for purposes of load balancing while the payload protocol may be identified by the GRE Protocol Type. Comments were received during the adoption call. These comments need to be incorporated/addressed in the WG -00 version of the document. Best wishes, Gorry (TSVWG Co-Chair) From ietf-secretariat-reply@ietf.org Tue Jan 7 12:20:45 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B4F1AE1AA for ; Tue, 7 Jan 2014 12:20: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 YLCAJlV-qWmE for ; Tue, 7 Jan 2014 12:20:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0A31AE1C8 for ; Tue, 7 Jan 2014 12:20:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140107202040.22438.54920.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2014 12:20:40 -0800 From: IETF Secretariat Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 20:20:45 -0000 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 Wed Jan 8 04:15:12 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7A61AE357; Wed, 8 Jan 2014 04:15:12 -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 kC3z-duMSlUp; Wed, 8 Jan 2014 04:15:09 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.140]) by ietfa.amsl.com (Postfix) with ESMTP id 95F4B1AE34F; Wed, 8 Jan 2014 04:15:08 -0800 (PST) Received: from [85.158.136.51:17945] by server-4.bemta-5.messagelabs.com id 43/52-26791-2414DC25; Wed, 08 Jan 2014 12:14:58 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-8.tower-49.messagelabs.com!1389183297!23877013!2 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9908 invoked from network); 8 Jan 2014 12:14:58 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-8.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 8 Jan 2014 12:14:58 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 8 Jan 2014 12:14:57 +0000 From: To: , Date: Wed, 8 Jan 2014 12:13:29 +0000 Thread-Topic: [tsvwg] Milestones changed for tsvwg WG Thread-Index: Ac8L5fGpGev5JLGlR1aJoU+6Ux09egAhRjy7 Message-ID: <290E20B455C66743BE178C5C84F1240847E63346AB@EXMB01CMS.surrey.ac.uk> References: <20140107202040.22438.54920.idtracker@ietfa.amsl.com> In-Reply-To: <20140107202040.22438.54920.idtracker@ietfa.amsl.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: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 12:15:12 -0000 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-se= cretariat-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 gorry@erg.abdn.ac.uk Wed Jan 8 04:55:40 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360251AE37E for ; Wed, 8 Jan 2014 04:55:40 -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 a6DY3-oJj_7y for ; Wed, 8 Jan 2014 04:55:38 -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 3F5231AE37D for ; Wed, 8 Jan 2014 04:55:38 -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 524042B44A5; Wed, 8 Jan 2014 12:55:28 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 8 Jan 2014 12:55:28 -0000 Message-ID: <1bb72ed9447c817e6ab8409dcbf147df.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346AB@EXMB01CMS.surrey.ac.uk> References: <20140107202040.22438.54920.idtracker@ietfa.amsl.com> <290E20B455C66743BE178C5C84F1240847E63346AB@EXMB01CMS.surrey.ac.uk> Date: Wed, 8 Jan 2014 12:55:28 -0000 From: gorry@erg.abdn.ac.uk To: l.wood@surrey.ac.uk 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 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 12:55:40 -0000 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 gorry@erg.abdn.ac.uk Wed Jan 8 04:55:41 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9154D1AE37B for ; Wed, 8 Jan 2014 04:55:41 -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 azZOgXvEL4YG for ; Wed, 8 Jan 2014 04:55:40 -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 D21F01AE379 for ; Wed, 8 Jan 2014 04:55:39 -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 4453A2B44A5; Wed, 8 Jan 2014 12:55:30 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 8 Jan 2014 12:55:30 -0000 Message-ID: <9e9147aa7183c016db4888691f1ef46d.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346AB@EXMB01CMS.surrey.ac.uk> References: <20140107202040.22438.54920.idtracker@ietfa.amsl.com> <290E20B455C66743BE178C5C84F1240847E63346AB@EXMB01CMS.surrey.ac.uk> Date: Wed, 8 Jan 2014 12:55:30 -0000 From: gorry@erg.abdn.ac.uk To: l.wood@surrey.ac.uk 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 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 12:55:41 -0000 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 l.wood@surrey.ac.uk Wed Jan 8 12:59:13 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 david.black@emc.com Wed Jan 8 15:21:25 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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 Cc: "ietf@ietf.org" , "jnc@mit.edu" , "lisp@ietf.org" , "tsvwg@ietf.org" Subject: [tsvwg] gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 l.wood@surrey.ac.uk Wed Jan 8 18:35:57 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] [lisp] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] [lisp] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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:03 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6501AE09D for ; Wed, 8 Jan 2014 19:00:03 -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=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 g3-9LbgLlNv6 for ; Wed, 8 Jan 2014 19:00:01 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) by ietfa.amsl.com (Postfix) with ESMTP id 636301AE099 for ; Wed, 8 Jan 2014 19:00:00 -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: [tsvwg] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 03:00:03 -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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [tsvwg] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Transport Area Working Group 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 farinacci@gmail.com Wed Jan 8 13:51:18 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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) X-Mailman-Approved-At: Thu, 09 Jan 2014 03:26:40 -0800 Cc: gorry@erg.abdn.ac.uk, ietf@ietf.org, jnc@mit.edu, LISP mailing list list , tsvwg@ietf.org Subject: Re: [tsvwg] [lisp] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 randy@psg.com Wed Jan 8 23:51:55 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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 03:27:47 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [tsvwg] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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 03:27:48 -0800 Cc: gorry@erg.abdn.ac.uk, lisp@ietf.org, tsvwg@ietf.org, l.wood@surrey.ac.uk, jnc@mit.edu, ietf@ietf.org Subject: Re: [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Transport Area Working Group 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 markodia111@gmail.com Fri Jan 3 18:43:13 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4905B1ADFE0 for ; Fri, 3 Jan 2014 18:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 zNsZ9PwJVHCj for ; Fri, 3 Jan 2014 18:43:12 -0800 (PST) Received: from mail-la0-x244.google.com (mail-la0-x244.google.com [IPv6:2a00:1450:4010:c03::244]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5EE1AE02F for ; Fri, 3 Jan 2014 18:43:10 -0800 (PST) Received: by mail-la0-f68.google.com with SMTP id mc6so2770754lab.11 for ; Fri, 03 Jan 2014 18:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tpwtx14CK2NNQPZtBnyps146mRbSbPSejRlI3qSWJDk=; b=bmV18gRmnRVXFYI6zcIz/JM2Zg2bR4JL/SrQqrMgtfbGjJig24T/Vmzpqg2/5UqJ78 M4poJy/psLz+Azw/8b6gSNdFpE+4Sek/5RkB5+B1i9xxPKZQhDq229VPqBygD4LG+L1u FwxliSsqCAR6vyQaqLRp7uu5BuoiCyowj3eiKDJaHEuXLPqZrIFd+BHw8L4tWTkQgeTI xl9v/67+/DczTvFueIiUuK6630riBFfBEKcPLOC/QPbDUj/Z+Kq5EP7WmESJYifRzfIt SWMGQqsSPtQnZnQWxwT5Vwqk++3jk9hkqrtk5HeMd3wjeJQUnSZHcbYazW9ZmJlXLX3v viOA== MIME-Version: 1.0 X-Received: by 10.112.144.69 with SMTP id sk5mr101646lbb.44.1388803382772; Fri, 03 Jan 2014 18:43:02 -0800 (PST) Received: by 10.114.5.104 with HTTP; Fri, 3 Jan 2014 18:43:02 -0800 (PST) Date: Sat, 4 Jan 2014 03:43:02 +0100 Message-ID: From: Mark Odia To: Mark Odia Content-Type: multipart/alternative; boundary=047d7b3432f44b270104ef1bfc72 X-Mailman-Approved-At: Thu, 09 Jan 2014 03:27:48 -0800 Subject: [tsvwg] Investment X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 02:43:13 -0000 --047d7b3432f44b270104ef1bfc72 Content-Type: text/plain; charset=ISO-8859-1 Attention Please ! This is a management placement on behalf of an investor. The investor is interested in a joint partnership venture with you or your company for an investment plan. If you are vast in business and would be capable to handle a capital project, please present your details along with your business plan to enable us review and set up a live meeting with you and our brokers. Upon the receipt of your information, we shall present the agreement covering this transaction for your perusal and signature. I await your co-operation. Regards, Mark Odia --047d7b3432f44b270104ef1bfc72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Attention Please !

This is a management placement o= n behalf of an investor.

The investor is interested in a joint partn= ership venture with you or
your company for an investment plan.

If you are vast in business and would be capable to handle a capital
pro= ject, please present your details along with your business plan to
enabl= e us review and set up a live meeting with you and our brokers.
Upon the= receipt of your information, we shall present the agreement
covering this transaction for your perusal and signature.

I await yo= ur co-operation.

Regards,
Mark Odia
--047d7b3432f44b270104ef1bfc72-- From jnc@mercury.lcs.mit.edu Wed Jan 8 15:32:47 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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) X-Mailman-Approved-At: Thu, 09 Jan 2014 03:27:49 -0800 Cc: jnc@mercury.lcs.mit.edu Subject: Re: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 stbryant@cisco.com Thu Jan 9 04:08:58 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Transport Area Working Group 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 loa@pi.nu Thu Jan 9 08:17:21 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: [tsvwg] misdelivered mpls packets - Was: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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:35:04 -0800 Cc: "gorry@erg.abdn.ac.uk" , "mpls@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" , "jnc@mit.edu" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 mark.tinka@seacom.mu Thu Jan 9 04:37:35 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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:35:05 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Transport Area Working Group 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 jnc@mercury.lcs.mit.edu Thu Jan 9 08:16:12 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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) X-Mailman-Approved-At: Thu, 09 Jan 2014 09:35:05 -0800 Cc: tsvwg@ietf.org, jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 agmalis@gmail.com Thu Jan 9 12:12:50 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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 Cc: gorry@erg.abdn.ac.uk, "mpls@ietf.org" , LISP mailing list list , tsvwg@ietf.org, Stewart Bryant , jnc@mit.edu, IETF Discussion Subject: Re: [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 l.wood@surrey.ac.uk Thu Jan 9 20:22:23 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 internet-drafts@ietf.org Fri Jan 10 05:46:20 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EFB1AE015; Fri, 10 Jan 2014 05:46:20 -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 xeYhbeBJGYIG; Fri, 10 Jan 2014 05:46:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A091ADE72; Fri, 10 Jan 2014 05:46:19 -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: <20140110134619.2217.53215.idtracker@ietfa.amsl.com> Date: Fri, 10 Jan 2014 05:46:19 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 13:46:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Generic UDP Encapsulation for IP Tunneling Authors : Edward Crabbe Lucy Yong Xiaohu Xu Filename : draft-ietf-tsvwg-gre-in-udp-encap-00.txt Pages : 11 Date : 2014-01-09 Abstract: This document describes a method of encapsulating arbitrary protocols within GRE and UDP headers. In this encapsulation, the source UDP port may be used as an entropy field for purposes of loadbalancing while the payload protocol may be identified by the GRE Protocol Type. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-00 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 l.wood@surrey.ac.uk Sat Jan 11 18:59:58 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, ietf@ietf.org Subject: Re: [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 l.wood@surrey.ac.uk Sun Jan 12 16:48:05 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [tsvwg] [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 wwwrun@rfc-editor.org Mon Jan 13 02:08:48 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129251ADFA9; Mon, 13 Jan 2014 02:08:48 -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 E2D0fySfwwTl; Mon, 13 Jan 2014 02:08:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3891AE115; Mon, 13 Jan 2014 02:08:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 749B97FC175; Mon, 13 Jan 2014 02:08:26 -0800 (PST) To: karen.nielsen@tieto.com, randall@lakerest.net From: RFC Errata System Message-Id: <20140113100826.749B97FC175@rfc-editor.org> Date: Mon, 13 Jan 2014 02:08:26 -0800 (PST) Cc: mls.ietf@gmail.com, rfc-editor@rfc-editor.org, iesg@ietf.org, tsvwg@ietf.org Subject: [tsvwg] [Errata Verified] RFC4960 (3788) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 10:08:48 -0000 The following errata report has been verified for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=3788 -------------------------------------- Status: Verified Type: Technical Reported by: Karen Nielsen Date Reported: 2013-11-06 Verified by: Martin Stiemerling (IESG) Section: 8.1 Original Text ------------- An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT chunks. Corrected Text -------------- An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes data retransmissions to all the destination transport addresses of the peer if it is multi-homed),including the number of unacknowledged HEARTBEAT chunks observed on the path which currently is used for data transfer. Unacknowledged HEARTBEAT chunks observed on paths different from the path currently used for data transfer shall not increment the association error counter, as this could lead to association closure even if the path which currently is used for data transfer is available (but idle). Notes ----- RFC4960 Endpoint Failure detection mechanism is deficient in that HB failures on some failing paths may take the association down, even if other paths are working perfectly, but simply at the time no data or HBs are being sent on the working paths. The situation occurs when the association is idle (no data is being transmitted) and the HBI settings on the failing paths are much more aggressive than the HBI set on the working paths. RFC6458 allows for specification of the HBI on a per destination address whereby such in-homogeneous setting of the HBI can occur. The solution proposed to the issue is to demand that HB failures observed on paths different from the path currently used for data transfer do not contribute to the association error counter. HB failures observed on the path currently used for data transfer, when this path is idle, shall contribute to the association error counter. Thereby supporting Endpoint Failure detection when the association is idle. When the association is transmitting data, the fate of the data transmissions and retransmissions will serve to instantiate Endpoint Failure detection. -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From gorry@erg.abdn.ac.uk Mon Jan 13 12:32:00 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, l.wood@surrey.ac.uk, randy@psg.com, tsvwg@ietf.org, farinacci@gmail.com, jnc@mit.edu, ietf@ietf.org Subject: Re: [tsvwg] [mpls] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 stbryant@cisco.com Tue Jan 14 06:18:04 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Transport Area Working Group 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 huubatwork@gmail.com Thu Jan 9 09:59:07 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:10 -0800 Cc: "mpls@ietf.org" , "tsvwg@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" Subject: Re: [tsvwg] [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:10 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, tsvwg@ietf.org, stbryant@cisco.com, jnc@mit.edu, ietf@ietf.org Subject: Re: [tsvwg] misdelivered mpls packets - Was: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Transport Area Working Group 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 curtis@ipv6.occnc.com Thu Jan 9 18:18:18 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:10 -0800 Cc: Gregory Mirsky , "mpls@ietf.org" , "tsvwg@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" Subject: Re: [tsvwg] [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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 randy@psg.com Fri Jan 10 13:32:51 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5757D1AE1F1; Fri, 10 Jan 2014 13:32:51 -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 m8YqSJsXt4R1; Fri, 10 Jan 2014 13:32:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 745E11AE1C4; Fri, 10 Jan 2014 13:32:47 -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 1W1jgm-00052S-IS; Fri, 10 Jan 2014 21:32:25 +0000 Date: Sat, 11 Jan 2014 06:32:22 +0900 Message-ID: From: Randy Bush To: Mark Tinka In-Reply-To: <201401092048.16168.mark.tinka@seacom.mu> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091437.04245.mark.tinka@seacom.mu> <52CECB7B.3090200@pi.nu> <201401092048.16168.mark.tinka@seacom.mu> 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_Sat_Jan_11_06:32:17_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 14 Jan 2014 10:38:10 -0800 Cc: gorry@erg.abdn.ac.uk, ietf@ietf.org, tsvwg@ietf.org, jnc@mit.edu, stbryant@cisco.com Subject: Re: [tsvwg] misdelivered mpls packets - Was: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 21:32:51 -0000 --pgp-sign-Multipart_Sat_Jan_11_06:32:17_2014-1 Content-Type: text/plain; charset=US-ASCII what may scare me most about this discussion is the lack of p in mpls vns. you just sent my very sensitive unencrypted packet to some very bad place. --pgp-sign-Multipart_Sat_Jan_11_06:32:17_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 iQEcBAABCgAGBQJS0GbmAAoJEMzMBey4OgLthBgH/3xr9a04RpbAoDRHj3cRHU3L KE5JoBpvZtM1IlN56nt0/tbAns27BrXBLJkHRTYHYlbsa0U8APC5dNYk964zatiO z+kryHsFOQVjW7x7SdMwjuIDLE6zlYdZd2buReZIF0g1NulJIqEsiSq6NEhFR/Lu 06uoysfaspBKRFU1X7LO312dX8dU7baFhWMrbHlpQs64Nof+pa7L6rJuFKZvVToR NUiqHQrE8UnSB+Gtqki/JqRMHiF5emaGpZqlU6OlS1NXR42WrKM1ITWrJXeqONzf gHJVmXmU10q5bRHbZHyo+mk8gKJ604mCJAk9uXMY7FWz4NqgsO1CCdR/wTm0EHA= =hNpY -----END PGP SIGNATURE----- --pgp-sign-Multipart_Sat_Jan_11_06:32:17_2014-1-- From mark.tinka@seacom.mu Sun Jan 12 04:26:51 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:10 -0800 Cc: gorry@erg.abdn.ac.uk, lisp@ietf.org, l.wood@surrey.ac.uk, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, ietf@ietf.org Subject: Re: [tsvwg] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:10 -0800 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] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:10 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: [tsvwg] OT was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:10 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [tsvwg] OT was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Transport Area Working Group 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 farinacci@gmail.com Sun Jan 12 13:37:16 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: "" X-Mailman-Approved-At: Tue, 14 Jan 2014 10:38:10 -0800 Cc: "" , "" , "ietf@ietf.org" , "lisp@ietf.org" , "gorry@erg.abdn.ac.uk" , "randy@psg.com" , "jnc@mit.edu" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 curtis@ipv6.occnc.com Mon Jan 13 11:11:39 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:11 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, randy@psg.com, tsvwg@ietf.org, farinacci@gmail.com, jnc@mit.edu, lisp@ietf.org Subject: Re: [tsvwg] [mpls] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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 curtis@ipv6.occnc.com Tue Jan 14 07:51:17 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:11 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, curtis@ipv6.occnc.com Subject: Re: [tsvwg] OT was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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:34 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:10 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [tsvwg] OT was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:11 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, curtis@ipv6.occnc.com Subject: [tsvwg] OT (was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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 david.i.allan@ericsson.com Thu Jan 9 12:26:46 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Tue, 14 Jan 2014 10:38:17 -0800 Subject: Re: [tsvwg] [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 l.wood@surrey.ac.uk Tue Jan 14 13:57:46 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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:52 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E191AE2BA for ; Tue, 14 Jan 2014 14:07: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] 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 0vgUCpst-okj for ; Tue, 14 Jan 2014 14:07:51 -0800 (PST) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id DC6B51AE2AA for ; Tue, 14 Jan 2014 14:07:50 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s0EM7c7Q005485 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: [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: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 22:07:52 -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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [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: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [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: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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:49 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D53A1AE2BE for ; Tue, 14 Jan 2014 21:21:49 -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=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 DVxmp6gIUuFL for ; Tue, 14 Jan 2014 21:21:47 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) by ietfa.amsl.com (Postfix) with ESMTP id C3A3B1AE2EC for ; Tue, 14 Jan 2014 21:21:43 -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, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, stbryant@cisco.com 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 05:21:49 -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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [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: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, l.wood@surrey.ac.uk, tsvwg@ietf.org, jnc@mit.edu, curtis@ipv6.occnc.com 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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, curtis@ipv6.occnc.com, jnc@mit.edu, ietf@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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 gorry@erg.abdn.ac.uk Wed Jan 15 12:18:26 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, l.wood@surrey.ac.uk, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, stbryant@cisco.com 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 Tue Jan 14 19:30:06 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Fri, 17 Jan 2014 06:49:18 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, randy@psg.com, tsvwg@ietf.org, stbryant@cisco.com, jnc@mit.edu, curtis@ipv6.occnc.com 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Fri, 17 Jan 2014 06:49:18 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, tsvwg@ietf.org, stbryant@cisco.com, jnc@mit.edu, curtis@ipv6.occnc.com 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Fri, 17 Jan 2014 06:49:18 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, l.wood@surrey.ac.uk, tsvwg@ietf.org, jnc@mit.edu, curtis@ipv6.occnc.com 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Fri, 17 Jan 2014 06:49:18 -0800 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Fri, 17 Jan 2014 06:49:18 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, tsvwg@ietf.org, curtis@ipv6.occnc.com, jnc@mit.edu, stbryant@cisco.com 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Fri, 17 Jan 2014 06:49:18 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, l.wood@surrey.ac.uk, tsvwg@ietf.org, Stewart Bryant , jnc@mit.edu, curtis@ipv6.occnc.com 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Fri, 17 Jan 2014 06:49:18 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, tsvwg@ietf.org, stbryant@cisco.com, jnc@mit.edu, curtis@ipv6.occnc.com 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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 curtis@ipv6.occnc.com Wed Jan 15 12:34:59 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Fri, 17 Jan 2014 06:49:18 -0800 Cc: "gorry@erg.abdn.ac.uk" , "mpls@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" , Randy Bush , "stbryant@cisco.com" , "jnc@mit.edu" , "ietf@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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Fri, 17 Jan 2014 06:49:18 -0800 Cc: mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, l.wood@surrey.ac.uk, randy@psg.com, tsvwg@ietf.org, curtis@ipv6.occnc.com, jnc@mit.edu, stbryant@cisco.com 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)) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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 saku@ytti.fi Fri Jan 17 08:33:28 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216781AE155 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=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 BGyX00BIsfkR for ; Fri, 17 Jan 2014 08:33:25 -0800 (PST) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3181AE12E for ; Fri, 17 Jan 2014 08:33:24 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id e11so742763bkh.39 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=M+kXHFfzfDe3NDcECkC1MRAXh/69y2Rym5+F0fTkMDn79Hgl1unOeglCECbjxs8gmO NNNEHIPk7GlBlf6FRgQKCAHtQoc7hm7YLzUN8TydTH8HZon0s+XQu6JIC+rMFv9lHJIN /WPhU1yC25JW9YGGTNJxNglONBkb8QdFHSExcaTREuKbMSyeK2ZxLBuylzzVRZ7C8Bol sNshg/evjrZlFphSOeupMuyi71p+A5O3JmqGWQpA7PmBzaufTqI4rxAWF+VlmHzKiMLz NhifjVZfb+CM4p5rpIxfCZnaWFOnGZtjbAq70u842YHoLvv2WzkbZc6wBEtjX8UL/MVC Laqg== X-Gm-Message-State: ALoCoQmiAZjljl9iW8nVCL1zweOStn8flbvwzE7tXQjfVvHA2g9z6+Cw87LhLKL4aQy1SqeHD+M/ 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) Subject: Re: [tsvwg] [mpls] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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:04 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7521ACCDF for ; Fri, 17 Jan 2014 14:33:04 -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 GrhOmqnfABli for ; Fri, 17 Jan 2014 14:33:03 -0800 (PST) Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by ietfa.amsl.com (Postfix) with ESMTP id B1B781ACC8B for ; Fri, 17 Jan 2014 14:33:00 -0800 (PST) Received: by mail-bk0-f47.google.com with SMTP id d7so709429bkh.34 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=MfsVAl73Fif2S+e/F58KcNf/Axt47KQh0tXQsJkmHlFk7hT2V59HJ9DBv9/kAdJMW1 mXRpOhAY2XQrku16iqpPoD5PlC1C4dGO9IPlh4doK95STdpcbpcZQRFBP4BF7UwbCHif FF3RLCgfApck3z2kcys5rzRlUy+/wL+waVKnpVpvi6XbLDOFwdoXYRHjyInt5OJTGjnz hoQh9I+sN3HxkIsrFveqlakSAoXMvDu82zDK1c+57S5SNYjiiWwTGJJ+QK121oC1Pxgn WJJz71tEEiAIhDU44blZGIycYWFVNcxn52bwtfyxYjK654PkbJEMEBo75lFjcjA9JNHV GHsw== X-Gm-Message-State: ALoCoQmN6DgrcLE3Okc9eDdG0dAaYQIpVKOJPd1Xt+piUkGFaxWuKXK4aC3q44MuWuxF+LerVI83 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) Cc: mpls@ietf.org, lisp@ietf.org, tsvwg@ietf.org, ietf@ietf.org Subject: Re: [tsvwg] [mpls] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 22:33:04 -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 david.black@emc.com Sun Jan 19 19:30:38 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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 Cc: "mpls@ietf.org" , "lisp@ietf.org" , Randy Bush , "tsvwg@ietf.org" , "ietf@ietf.org" Subject: [tsvwg] GRE in UDP - traffic distribution ( was RE: [mpls] OT (was Re: draft-ietf-mpls-in-udp) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 david.black@emc.com Mon Jan 20 09:28:00 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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 Cc: "mpls@ietf.org" , "lisp@ietf.org" , Randy Bush , "tsvwg@ietf.org" , "ietf@ietf.org" Subject: Re: [tsvwg] GRE in UDP - traffic distribution ( was RE: [mpls] OT (was Re: draft-ietf-mpls-in-udp) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 Ruediger.Geib@telekom.de Mon Jan 20 23:38:04 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1F31A005E; Mon, 20 Jan 2014 23:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 AsUD4zxMU3uX; Mon, 20 Jan 2014 23:38:02 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id F1B491A0058; Mon, 20 Jan 2014 23:38:01 -0800 (PST) Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 21 Jan 2014 08:38:00 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 21 Jan 2014 08:38:00 +0100 From: To: Date: Tue, 21 Jan 2014 08:37:59 +0100 Thread-Topic: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: Ac7ZqeZ/7AQswgk0TByj6KTyywQpeg80Potg Message-ID: References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> In-Reply-To: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org, aqm@ietf.org Subject: Re: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 07:38:05 -0000 Hi Bob, I support the issue being picked up by IETF. What can be done within the bo= unds of IETF responsibility should be done. If ECN is seeing deployment, es= pecially ECN support for IP over VLAN over IP/MPLS may be of interest. Furt= her, ECN over LTE radio Access may be relevant (but my expertise is too lim= ited to judge details). Regards, Ruediger =20 -----Urspr=FCngliche Nachricht----- Von: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] Im Auftrag von = Bob Briscoe Gesendet: Montag, 4. November 2013 23:04 An: tsvwg IETF list; AQM IETF list Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org Betreff: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel = protocols? Folks, Pls respond if you support this being adopted as a work-group item in the I= ETF transport services w-g (tsvwg). The WG chairs need visibility of intere= st. Even better, if you're willing to read / comment / review / implement Guidelines for Adding Congestion Notification to Protocols that Encapsulate= IP Abstract The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. [Cross-posting tsvwg & aqm, just in case] Bob Briscoe, also for co-authors Pat Thaler and John Kaippallimalil ________________________________________________________________ Bob Briscoe, BT=20 From sdhesika@cisco.com Tue Jan 21 09:57:16 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF771A03ED; Tue, 21 Jan 2014 09:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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_HI=-5, RP_MATCHES_RCVD=-0.535, 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 DOpFrxU-79pV; Tue, 21 Jan 2014 09:57:13 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AE9381A0365; Tue, 21 Jan 2014 09:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4046; q=dns/txt; s=iport; t=1390327034; x=1391536634; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qns5iZMICHa5Mcu9oup9RqvJ7sWo57mwu504/W344Q8=; b=BvJ6F8FVQYHBaFtV0PewIZoipstDkdrOtSGWeVTBYWX0/kMjovqhGQEq ZHRiiHIu94MtTTMc5e/hu55tAsTSGQO2Cai55M1jFSLM+no88ogm9HAVQ B0IW6J1zVllICd/QV2unjMLMT8OAO2H95Mvo4pfcskfwCt5G1RAvUFl5w M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAGu03lKtJV2d/2dsb2JhbABZDoJ9OFa7bYEUFnSCJQEBAQMBOjgMBwQCAQgRBAEBCxQJBzIUCQgCBAESCAELh2kIDcNBF45OOAaDHoEUBKo6gm4/gio X-IronPort-AV: E=Sophos;i="4.95,696,1384300800"; d="scan'208";a="298722254" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 21 Jan 2014 17:57:10 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0LHv9nv004216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 17:57:09 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.18]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 11:57:09 -0600 From: "Subha Dhesikan (sdhesika)" To: "gorry@erg.abdn.ac.uk" , "Ruediger.Geib@telekom.de" , "tsvwg@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHO+8aJErlBSAcWG0ODmxKj8FJpKppaNXsAgAGQV8CAM+aC8A== Date: Tue, 21 Jan 2014 17:57:08 +0000 Message-ID: References: <52AF0E7B.6030400@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.24.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:57:16 -0000 A new draft of the QoS document for rtcweb has been posted with the edits s= uggested below. The edits are: - Noted the trust issue and possibility of remarking at network edge - Provided some guidance for networks with reduced number of DSCP classes. http://www.ietf.org/internet-drafts/draft-dhesikan-tsvwg-rtcweb-qos-04.txt Regards, Subha -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Subha Dhesikan (sd= hesika) Sent: Thursday, December 19, 2013 9:28 AM To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de Cc: tsvwg@ietf.org Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos Thank you for your comments, Ruediger and Gorry. Inline as SD: -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of gorry@erg.abdn.ac.= uk Sent: Wednesday, December 18, 2013 3:28 AM To: Ruediger.Geib@telekom.de Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos See a few thoughts in-line (with no chair-hat): > Hi Gorry, > > my small contribution to discuss the TSVWG input: > > draft dhesikan -03 is a rather short document. It is now focused on IP=20 > DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP=20 > QCI related discussion has been removed. > > The authors of draft dhesikan prefer to support a wide set of DSCPs=20 > and suggest to support different levels of priority. The introduction=20 > seems to say, it is largely considered to be applied within LANs, for=20 > home gateway internal classification and for Wifi. That's fine with me. > > In the case of traffic sent to a network provider broadband access=20 > router / network gateway, I doubt that too many markings make sense. > I'd expect the network provider routers or gateways not to trust=20 > DiffServ markings sent by a consumer device. The draft doesn't mention=20 > that. Adding such a note may be useful. > Personally I'd agree - it would be useful to describe this context SD: Sounds good. I will add a statement or two on lack of trust of client = devices and the effect on DSCP marking.=20 In addition, I am expecting there will be some work done on the authorizati= on mechanisms for webrtc traffic that will allow some off-path authorizatio= n of DSCP for particular flows. > As I'm known for simplistic approaches, my take is to mark traffic=20 > sent by a home gateway to a provider policy point by two DSCPs only,=20 > Best Effort and an AF PHB. I agree however with the authors, that a=20 > Home Gateway could and should internally apply a much more fine=20 > grained QoS differentiation for upstream traffic. If all home network=20 > devices apply proper markings as suggested by the authors, this may help. > I think it would be useful to say that each DSCP by a single app require a = way for the app or transport to know which work appropriately along that pa= th. Especially when traffic is dynamically moved between different PHB grou= ps. The fact that many deployed networks support a small set of DSCPs is worth = I think a mention. To me this has some implications, e.g. when the App sets= EF or CS1 and networks supports just AF and BE - intended precedence would= then rely upon correct treatment or re-marking. If this were not appropria= te, then the loss will depend upon whether it was before or after the DSCPs= were interpreted as intended. SD: ack. Yes, it is possible to add an example or two on how the DSCPs defi= ned in this document can be treated in a network that has only 2-4 PHBs. > If there's interest to approach the 3GPP community for a discussion on=20 > a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help. > This should be documented in a separate draft, as I'd expect this=20 > inter SDO work to consume a fair amount of time. SD: I will also participate as needed.=20 Regards, Subha > > Regards and seasonal greetings, > > Ruediger > > > Gorry From david.black@emc.com Tue Jan 21 10:59:42 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633961A01AB; Tue, 21 Jan 2014 10:59:42 -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, 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 1PBMdOg3XkQO; Tue, 21 Jan 2014 10:59:38 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id D602F1A0190; Tue, 21 Jan 2014 10:59:37 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0LIxRsQ031760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jan 2014 13:59:28 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0LIxRsQ031760 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390330768; bh=SQ7w+m1bWcUNpddR9y1W5fpymxQ=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=BBDXBodt0mKRiFZkH990TiP4NWxGuJ1OpFSurCiC71fGPi7c2B9+s7+Z8w2kTFWUm zxaqXH3Rp+L+PVlghMJU2GbLOJ+4gOeSFaNQDWrnnmEnzRoxzgfCxjV3KtQiI2Z7gV cpr4lmA7Y1dfERPvqbk9Q7ssx1LLp8AIr0lRATk8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0LIxRsQ031760 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor); Tue, 21 Jan 2014 13:59:15 -0500 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0LIxEfO011816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 13:59:14 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Tue, 21 Jan 2014 13:58:31 -0500 From: "Black, David" To: "Subha Dhesikan (sdhesika)" , "gorry@erg.abdn.ac.uk" , "Ruediger.Geib@telekom.de" , "tsvwg@ietf.org" , "rtcweb@ietf.org" Date: Tue, 21 Jan 2014 13:59:12 -0500 Thread-Topic: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHO+8aJErlBSAcWG0ODmxKj8FJpKppaNXsAgAGQV8CAM+aC8IAACWcg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026F047C18@MX15A.corp.emc.com> References: <52AF0E7B.6030400@erg.abdn.ac.uk> In-Reply-To: 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: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 18:59:42 -0000 > - Provided some guidance for networks with reduced number of DSCP classes= . That guidance would be (or would start with): If a packet enters a QoS domain that has no support for the above defined Data Types/Application classes, then the network node at the edge SHOULD map the DSCP value to one used by supported classes. Here are a couple of examples: o If a QoS domain supports only one video class, then the packets from the two video classes SHOULD be remarked to use the same DSCP, either AF4 or AF3 whichever is supported. o If a QoS domain supports a single class for all voice and video traffic, then the packets from all the video and voice classes SHOULD be combined and remarked to the single supported DSCP. This draft may not be a good place for that - there are concerns well beyon= d rtcweb that drive these decisions by network architects/operators. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Subha Dhesikan > (sdhesika) > Sent: Tuesday, January 21, 2014 12:57 PM > To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de; tsvwg@ietf.org; > rtcweb@ietf.org > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > A new draft of the QoS document for rtcweb has been posted with the edits > suggested below. The edits are: > - Noted the trust issue and possibility of remarking at network edge > - Provided some guidance for networks with reduced number of DSCP classes= . >=20 > http://www.ietf.org/internet-drafts/draft-dhesikan-tsvwg-rtcweb-qos-04.t= xt >=20 > Regards, > Subha >=20 >=20 > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Subha Dhesikan > (sdhesika) > Sent: Thursday, December 19, 2013 9:28 AM > To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > Thank you for your comments, Ruediger and Gorry. >=20 > Inline as SD: >=20 > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of gorry@erg.abdn.a= c.uk > Sent: Wednesday, December 18, 2013 3:28 AM > To: Ruediger.Geib@telekom.de > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > See a few thoughts in-line (with no chair-hat): >=20 > > Hi Gorry, > > > > my small contribution to discuss the TSVWG input: > > > > draft dhesikan -03 is a rather short document. It is now focused on IP > > DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP > > QCI related discussion has been removed. > > > > The authors of draft dhesikan prefer to support a wide set of DSCPs > > and suggest to support different levels of priority. The introduction > > seems to say, it is largely considered to be applied within LANs, for > > home gateway internal classification and for Wifi. That's fine with me. > > > > In the case of traffic sent to a network provider broadband access > > router / network gateway, I doubt that too many markings make sense. > > I'd expect the network provider routers or gateways not to trust > > DiffServ markings sent by a consumer device. The draft doesn't mention > > that. Adding such a note may be useful. > > > Personally I'd agree - it would be useful to describe this context >=20 > SD: Sounds good. I will add a statement or two on lack of trust of clien= t > devices and the effect on DSCP marking. >=20 > In addition, I am expecting there will be some work done on the authoriza= tion > mechanisms for webrtc traffic that will allow some off-path authorization= of > DSCP for particular flows. >=20 > > As I'm known for simplistic approaches, my take is to mark traffic > > sent by a home gateway to a provider policy point by two DSCPs only, > > Best Effort and an AF PHB. I agree however with the authors, that a > > Home Gateway could and should internally apply a much more fine > > grained QoS differentiation for upstream traffic. If all home network > > devices apply proper markings as suggested by the authors, this may hel= p. > > >=20 > I think it would be useful to say that each DSCP by a single app require = a way > for the app or transport to know which work appropriately along that path= . > Especially when traffic is dynamically moved between different PHB groups= . >=20 > The fact that many deployed networks support a small set of DSCPs is wort= h I > think a mention. To me this has some implications, e.g. when the App sets= EF > or CS1 and networks supports just AF and BE - intended precedence would t= hen > rely upon correct treatment or re-marking. If this were not appropriate, = then > the loss will depend upon whether it was before or after the DSCPs were > interpreted as intended. >=20 > SD: ack. Yes, it is possible to add an example or two on how the DSCPs de= fined > in this document can be treated in a network that has only 2-4 PHBs. >=20 > > If there's interest to approach the 3GPP community for a discussion on > > a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help. > > This should be documented in a separate draft, as I'd expect this > > inter SDO work to consume a fair amount of time. > SD: I will also participate as needed. >=20 > Regards, > Subha > > > > Regards and seasonal greetings, > > > > Ruediger > > > > > > > Gorry >=20 From bob.briscoe@bt.com Tue Jan 21 14:49:48 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25411A0343; Tue, 21 Jan 2014 14:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tnczsPyfm-0s; Tue, 21 Jan 2014 14:49:45 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id 662A81A0256; Tue, 21 Jan 2014 14:49:44 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Jan 2014 22:49:43 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 21 Jan 2014 22:49:43 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Tue, 21 Jan 2014 22:49:41 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.123.72]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s0LMneWw026346; Tue, 21 Jan 2014 22:49:41 GMT Message-ID: <201401212249.s0LMneWw026346@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Jan 2014 22:49:35 +0000 To: Ingemar Johansson S , "Ruediger.Geib@telekom.de" From: Bob Briscoe In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31EC250B@ESESSMB205.ericss on.se> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <81564C0D7D4D2A4B9A86C8C7404A13DA31EC250B@ESESSMB205.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "tsvwg@ietf.org" , "aqm@ietf.org" Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 22:49:49 -0000 Ingemar, 1) Thx for the pointer. We should add this as=20 another example where a lower layer marks the IP=20 header (the example we already have is the L3 switch in the Ethernet world). 2) It doesn't talk about propagation of ECN=20 markings during encap & decap, which is one of=20 the things ecn-encap-guidelines aims to give=20 guidelines on. Do you think a doc like the draft=20 we've done would be useful to help 3GPP in this=20 respect? Do you think a formal liaison would be useful to point it out? 3) 3GPP TS 36.300 is ambiguous whether ECN=20 marking is applied to all packets to "indicate=20 congestion", or whether it is applied with a=20 frequency or probability that depends on an AQM=20 (it doesn't mention AQM, altho obviously it=20 refers to RFC3168 that is based on AQM). Do you=20 know whether it was meant to imply use of AQM? [Ruediger, thx for the supportive words too] Bob At 20:29 21/01/2014, Ingemar Johansson S wrote: >Hi > >Please note that ECN over LTE radio access is=20 >already standardized in 3GPP TS 36.300 (see 11.6=20 >in http://www.3gpp.org/ftp/specs/archive/36_series/36.300/36300-c00.zip ) > >/Ingemar > > -----Original Message----- > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Sent: den 21 januari 2014 08:38 > > To: bob.briscoe@bt.com > > Cc: tsvwg@ietf.org; aqm@ietf.org > > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to= L2 > > or tunnel protocols? > > > > Hi Bob, > > > > I support the issue being picked up by IETF. What can be done within the > > bounds of IETF responsibility should be done. If ECN is seeing= deployment, > > especially ECN support for IP over VLAN over IP/MPLS may be of interest. > > Further, ECN over LTE radio Access may be relevant (but my expertise is= too > > limited to judge details). > > > > Regards, > > > > Ruediger > > > > -----Urspr=FCngliche Nachricht----- > > Von: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] Im Auftrag > > von Bob Briscoe > > Gesendet: Montag, 4. November 2013 23:04 > > An: tsvwg IETF list; AQM IETF list > > Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org > > Betreff: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or= tunnel > > protocols? > > > > Folks, > > > > Pls respond if you support this being adopted as a work-group item in= the > > IETF transport services w-g (tsvwg). The WG=20 > chairs need visibility of interest. > > Even better, if you're willing to read / comment / review / implement > > > > Guidelines for Adding Congestion Notification to Protocols that= Encapsulate > > IP > > > > Abstract > > > > The purpose of this document is to guide the design of congestion > > notification in any lower layer or tunnelling protocol that > > encapsulates IP. The aim is for explicit congestion signals to > > propagate consistently from lower layer protocols into IP. Then the > > IP internetwork layer can act as a portability layer to carry > > congestion notification from non-IP-aware congested nodes up to the > > transport layer (L4). Following these guidelines should assure > > interworking between new lower layer congestion notification > > mechanisms, whether specified by the IETF or other standards bodies. > > > > > > [Cross-posting tsvwg & aqm, just in case] > > > > > > Bob Briscoe, > > also for co-authors Pat Thaler and John Kaippallimalil > > > > > > __________________________________________________________ > > ______ > > Bob Briscoe, BT > > > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT=20 From touch@isi.edu Tue Jan 21 17:21:49 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246D31A03A5; Tue, 21 Jan 2014 17:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 36RhcMFu7HGH; Tue, 21 Jan 2014 17:21:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A18CF1A03A4; Tue, 21 Jan 2014 17:21:47 -0800 (PST) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0M1L41P004531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jan 2014 17:21:05 -0800 (PST) Message-ID: <52DF1D03.9010900@isi.edu> Date: Tue, 21 Jan 2014 17:21:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20140110134619.2217.53215.idtracker@ietfa.amsl.com> In-Reply-To: <20140110134619.2217.53215.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:21:49 -0000 This doc should include some of the recommendations on GRE fragmentation summarized here: draft-bonica-intarea-gre-mtu-03 Ron and I spent quite a while going through the details; it'd be useful to not repeat that work in this doc. Joe On 1/10/2014 5:46 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group Working Group of the IETF. > > Title : Generic UDP Encapsulation for IP Tunneling > Authors : Edward Crabbe > Lucy Yong > Xiaohu Xu > Filename : draft-ietf-tsvwg-gre-in-udp-encap-00.txt > Pages : 11 > Date : 2014-01-09 > > Abstract: > This document describes a method of encapsulating arbitrary protocols > within GRE and UDP headers. In this encapsulation, the source UDP > port may be used as an entropy field for purposes of loadbalancing > while the payload protocol may be identified by the GRE Protocol > Type. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-00 > > > 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 sdhesika@cisco.com Tue Jan 21 19:18:40 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F43D1A01A8; Tue, 21 Jan 2014 19:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 13ElExkFs9D7; Tue, 21 Jan 2014 19:18:38 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id A28891A018E; Tue, 21 Jan 2014 19:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6266; q=dns/txt; s=iport; t=1390360717; x=1391570317; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iFZsPElQ2X+pNhlRh5R7R890WaELiZiyPJcZdLZG1IA=; b=MQJEwLDESPtS8rE2nr2BdQykunGpcU8RDJ+YZrk2xpiXUmEFnOGQEKKB IdyGANRsicnfGLyXxVDz6YEfgXLI1oI20BbRNH4ytdhatZ+Y21MZNKhwN iOf12ai95B8nBZG9ZiLHKGbd7Ew5NsVKxjfmum5JZA//fjSeLY5bGyj25 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAFA331KtJXHB/2dsb2JhbABaDoJ9OFa7b4ESFnSCJQEBAQQ6OBMEAgEIEQQBAQsUCQcyFAkIAgQBEggBC4dxDcJRF45OBjIGgx6BFASqOoJuP4Iq X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208";a="14529542" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-6.cisco.com with ESMTP; 22 Jan 2014 03:18:37 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0M3IahN029810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 03:18:36 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.18]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 21:18:36 -0600 From: "Subha Dhesikan (sdhesika)" To: "Black, David" , "gorry@erg.abdn.ac.uk" , "Ruediger.Geib@telekom.de" , "tsvwg@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHO+8aJErlBSAcWG0ODmxKj8FJpKppaNXsAgAGQV8CAM+aC8IAACWcggACSujA= Date: Wed, 22 Jan 2014 03:18:35 +0000 Message-ID: References: <52AF0E7B.6030400@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712026F047C18@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026F047C18@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.24.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 03:18:40 -0000 David, Please help me understand: Are you suggesting that the whole text should be= removed or reworded to remove guidance and merely say that the DSCP values= may have to be combined based on network policies where application classe= s are fewer. =20 Regards, Subha -----Original Message----- From: Black, David [mailto:david.black@emc.com]=20 Sent: Tuesday, January 21, 2014 10:59 AM To: Subha Dhesikan (sdhesika); gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.= de; tsvwg@ietf.org; rtcweb@ietf.org Cc: Black, David Subject: RE: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos > - Provided some guidance for networks with reduced number of DSCP classes= . That guidance would be (or would start with): If a packet enters a QoS domain that has no support for the above defined Data Types/Application classes, then the network node at the edge SHOULD map the DSCP value to one used by supported classes. Here are a couple of examples: o If a QoS domain supports only one video class, then the packets from the two video classes SHOULD be remarked to use the same DSCP, either AF4 or AF3 whichever is supported. o If a QoS domain supports a single class for all voice and video traffic, then the packets from all the video and voice classes SHOULD be combined and remarked to the single supported DSCP. This draft may not be a good place for that - there are concerns well beyon= d rtcweb that drive these decisions by network architects/operators. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Subha=20 > Dhesikan > (sdhesika) > Sent: Tuesday, January 21, 2014 12:57 PM > To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de; tsvwg@ietf.org;=20 > rtcweb@ietf.org > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > A new draft of the QoS document for rtcweb has been posted with the=20 > edits suggested below. The edits are: > - Noted the trust issue and possibility of remarking at network edge > - Provided some guidance for networks with reduced number of DSCP classes= . >=20 > =20 > http://www.ietf.org/internet-drafts/draft-dhesikan-tsvwg-rtcweb-qos-04 > .txt >=20 > Regards, > Subha >=20 >=20 > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Subha=20 > Dhesikan > (sdhesika) > Sent: Thursday, December 19, 2013 9:28 AM > To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > Thank you for your comments, Ruediger and Gorry. >=20 > Inline as SD: >=20 > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of=20 > gorry@erg.abdn.ac.uk > Sent: Wednesday, December 18, 2013 3:28 AM > To: Ruediger.Geib@telekom.de > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > See a few thoughts in-line (with no chair-hat): >=20 > > Hi Gorry, > > > > my small contribution to discuss the TSVWG input: > > > > draft dhesikan -03 is a rather short document. It is now focused on=20 > > IP DSCP markings suggested for RTCweb traffic. I appreciate that the=20 > > 3GPP QCI related discussion has been removed. > > > > The authors of draft dhesikan prefer to support a wide set of DSCPs=20 > > and suggest to support different levels of priority. The=20 > > introduction seems to say, it is largely considered to be applied=20 > > within LANs, for home gateway internal classification and for Wifi. Tha= t's fine with me. > > > > In the case of traffic sent to a network provider broadband access=20 > > router / network gateway, I doubt that too many markings make sense. > > I'd expect the network provider routers or gateways not to trust=20 > > DiffServ markings sent by a consumer device. The draft doesn't=20 > > mention that. Adding such a note may be useful. > > > Personally I'd agree - it would be useful to describe this context >=20 > SD: Sounds good. I will add a statement or two on lack of trust of=20 > client devices and the effect on DSCP marking. >=20 > In addition, I am expecting there will be some work done on the=20 > authorization mechanisms for webrtc traffic that will allow some=20 > off-path authorization of DSCP for particular flows. >=20 > > As I'm known for simplistic approaches, my take is to mark traffic=20 > > sent by a home gateway to a provider policy point by two DSCPs only,=20 > > Best Effort and an AF PHB. I agree however with the authors, that a=20 > > Home Gateway could and should internally apply a much more fine=20 > > grained QoS differentiation for upstream traffic. If all home=20 > > network devices apply proper markings as suggested by the authors, this= may help. > > >=20 > I think it would be useful to say that each DSCP by a single app=20 > require a way for the app or transport to know which work appropriately a= long that path. > Especially when traffic is dynamically moved between different PHB groups= . >=20 > The fact that many deployed networks support a small set of DSCPs is=20 > worth I think a mention. To me this has some implications, e.g. when=20 > the App sets EF or CS1 and networks supports just AF and BE - intended=20 > precedence would then rely upon correct treatment or re-marking. If=20 > this were not appropriate, then the loss will depend upon whether it=20 > was before or after the DSCPs were interpreted as intended. >=20 > SD: ack. Yes, it is possible to add an example or two on how the DSCPs=20 > defined in this document can be treated in a network that has only 2-4 PH= Bs. >=20 > > If there's interest to approach the 3GPP community for a discussion=20 > > on a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to hel= p. > > This should be documented in a separate draft, as I'd expect this=20 > > inter SDO work to consume a fair amount of time. > SD: I will also participate as needed. >=20 > Regards, > Subha > > > > Regards and seasonal greetings, > > > > Ruediger > > > > > > > Gorry >=20 From david.black@emc.com Wed Jan 22 07:29:04 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43DA1A0136; Wed, 22 Jan 2014 07:29:04 -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, 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 9wxDGlzs8sLx; Wed, 22 Jan 2014 07:29:01 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 508BF1A0139; Wed, 22 Jan 2014 07:29:01 -0800 (PST) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0MFSsfa002003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 10:28:57 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s0MFSsfa002003 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390404537; bh=4IVMF7lEAq+LznMTKyb1h7wx1GU=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=J3QcR7GtoMaG/sZGenEvl0GEtzs+pXCvlEmNw8wgopgP96sODIWI+J7aNzLDCc9gL BXszEm1UQIcQIoW+0+q7smDVej0ASX7wcZJ1GAlM1gG71nXxWJnrnx4HZas99614hk EyCykms9Pgz6ycrh0zVr2isjD3XUijybfljNI+lo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s0MFSsfa002003 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 22 Jan 2014 10:28:32 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0MFSV2K006103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 10:28:31 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Wed, 22 Jan 2014 10:28:31 -0500 From: "Black, David" To: "Subha Dhesikan (sdhesika)" , "gorry@erg.abdn.ac.uk" , "Ruediger.Geib@telekom.de" , "tsvwg@ietf.org" , "rtcweb@ietf.org" Date: Wed, 22 Jan 2014 10:28:30 -0500 Thread-Topic: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHO+8aJErlBSAcWG0ODmxKj8FJpKppaNXsAgAGQV8CAM+aC8IAACWcggACSujCAAMeK8A== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026F047D88@MX15A.corp.emc.com> References: <52AF0E7B.6030400@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712026F047C18@MX15A.corp.emc.com> In-Reply-To: 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: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 15:29:05 -0000 Subha, I think some rewording is needed and reduction in scope. My concern is two= -fold: 1) RTC-Web documents should be focused on the browser and the browser behav= ior. This sort of discussion of traffic conditioning at network boundaries that = may be well away from the browser seems peripheral. Given the strong desire ex= pressed in both public and private by certain parties to get this draft done quickl= y, expanding its scope to non-essential areas seems like a poor move. 2) RTC-Web traffic will not be the only user of these PHBs and DSCPs, and h= ence probably should not be making recommendations on traffic conditioning in general. If there's a way to specifically identify RTC-Web flows (e.g.,=20 distinguish them from other uses of RTP), it could be appropriate to discus= s what a multi-field (MF) classifier and associated traffic conditioning (see RFC 2475) should do to them at network boundaries, but there's no requirement to deploy MF classifiers at network boundaries. Unless there's an impact on how the browser should initially mark traffic, = it may be better to remove this text. Thanks, --David > -----Original Message----- > From: Subha Dhesikan (sdhesika) [mailto:sdhesika@cisco.com] > Sent: Tuesday, January 21, 2014 10:19 PM > To: Black, David; gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de; > tsvwg@ietf.org; rtcweb@ietf.org > Subject: RE: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > David, >=20 > Please help me understand: Are you suggesting that the whole text should = be > removed or reworded to remove guidance and merely say that the DSCP value= s may > have to be combined based on network policies where application classes a= re > fewer. >=20 > Regards, > Subha >=20 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Tuesday, January 21, 2014 10:59 AM > To: Subha Dhesikan (sdhesika); gorry@erg.abdn.ac.uk; Ruediger.Geib@teleko= m.de; > tsvwg@ietf.org; rtcweb@ietf.org > Cc: Black, David > Subject: RE: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos >=20 > >=20 > > - Provided some guidance for networks with reduced number of DSCP class= es. >=20 > That guidance would be (or would start with): >=20 > If a packet enters a QoS domain that has no support for the above > defined Data Types/Application classes, then the network node at the > edge SHOULD map the DSCP value to one used by supported classes. > Here are a couple of examples: >=20 > o If a QoS domain supports only one video class, then the packets > from the two video classes SHOULD be remarked to use the same > DSCP, either AF4 or AF3 whichever is supported. > o If a QoS domain supports a single class for all voice and video > traffic, then the packets from all the video and voice classes > SHOULD be combined and remarked to the single supported DSCP. >=20 > This draft may not be a good place for that - there are concerns well bey= ond > rtcweb that drive these decisions by network architects/operators. >=20 > >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Subha > > Dhesikan > > (sdhesika) > > Sent: Tuesday, January 21, 2014 12:57 PM > > To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de; tsvwg@ietf.org; > > rtcweb@ietf.org > > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos > > > > A new draft of the QoS document for rtcweb has been posted with the > > edits suggested below. The edits are: > > - Noted the trust issue and possibility of remarking at network edge > > - Provided some guidance for networks with reduced number of DSCP class= es. > > > > > > http://www.ietf.org/internet-drafts/draft-dhesikan-tsvwg-rtcweb-qos-04 > > .txt > > > > Regards, > > Subha > > > > > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Subha > > Dhesikan > > (sdhesika) > > Sent: Thursday, December 19, 2013 9:28 AM > > To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de > > Cc: tsvwg@ietf.org > > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos > > > > Thank you for your comments, Ruediger and Gorry. > > > > Inline as SD: > > > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of > > gorry@erg.abdn.ac.uk > > Sent: Wednesday, December 18, 2013 3:28 AM > > To: Ruediger.Geib@telekom.de > > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos > > > > See a few thoughts in-line (with no chair-hat): > > > > > Hi Gorry, > > > > > > my small contribution to discuss the TSVWG input: > > > > > > draft dhesikan -03 is a rather short document. It is now focused on > > > IP DSCP markings suggested for RTCweb traffic. I appreciate that the > > > 3GPP QCI related discussion has been removed. > > > > > > The authors of draft dhesikan prefer to support a wide set of DSCPs > > > and suggest to support different levels of priority. The > > > introduction seems to say, it is largely considered to be applied > > > within LANs, for home gateway internal classification and for Wifi. T= hat's > fine with me. > > > > > > In the case of traffic sent to a network provider broadband access > > > router / network gateway, I doubt that too many markings make sense. > > > I'd expect the network provider routers or gateways not to trust > > > DiffServ markings sent by a consumer device. The draft doesn't > > > mention that. Adding such a note may be useful. > > > > > Personally I'd agree - it would be useful to describe this context > > > > SD: Sounds good. I will add a statement or two on lack of trust of > > client devices and the effect on DSCP marking. > > > > In addition, I am expecting there will be some work done on the > > authorization mechanisms for webrtc traffic that will allow some > > off-path authorization of DSCP for particular flows. > > > > > As I'm known for simplistic approaches, my take is to mark traffic > > > sent by a home gateway to a provider policy point by two DSCPs only, > > > Best Effort and an AF PHB. I agree however with the authors, that a > > > Home Gateway could and should internally apply a much more fine > > > grained QoS differentiation for upstream traffic. If all home > > > network devices apply proper markings as suggested by the authors, th= is > may help. > > > > > > > I think it would be useful to say that each DSCP by a single app > > require a way for the app or transport to know which work appropriately > along that path. > > Especially when traffic is dynamically moved between different PHB grou= ps. > > > > The fact that many deployed networks support a small set of DSCPs is > > worth I think a mention. To me this has some implications, e.g. when > > the App sets EF or CS1 and networks supports just AF and BE - intended > > precedence would then rely upon correct treatment or re-marking. If > > this were not appropriate, then the loss will depend upon whether it > > was before or after the DSCPs were interpreted as intended. > > > > SD: ack. Yes, it is possible to add an example or two on how the DSCPs > > defined in this document can be treated in a network that has only 2-4 = PHBs. > > > > > If there's interest to approach the 3GPP community for a discussion > > > on a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to h= elp. > > > This should be documented in a separate draft, as I'd expect this > > > inter SDO work to consume a fair amount of time. > > SD: I will also participate as needed. > > > > Regards, > > Subha > > > > > > Regards and seasonal greetings, > > > > > > Ruediger > > > > > > > > > > > Gorry > > >=20 From adrian@olddog.co.uk Wed Jan 22 12:07:49 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586871A0416 for ; Wed, 22 Jan 2014 12:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 xAH_Lp24hJNt for ; Wed, 22 Jan 2014 12:07:48 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id E1ACA1A0403 for ; Wed, 22 Jan 2014 12:07:47 -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 s0MK7kau006831; Wed, 22 Jan 2014 20:07:46 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 s0MK7gZV006796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 20:07:43 GMT From: "Adrian Farrel" To: "'Joe Touch'" References: <20140110134619.2217.53215.idtracker@ietfa.amsl.com> <52DF1D03.9010900@isi.edu> In-Reply-To: <52DF1D03.9010900@isi.edu> Date: Wed, 22 Jan 2014 20:07:45 -0000 Message-ID: <0e8601cf17ad$9f8ea320$deabe960$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFCMnMLhO1wXW+3iJN5MR0ZfmGUGwIuuYlJm5l/xAA= Content-Language: en-gb Cc: rbonica@juniper.net, tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:07:49 -0000 Joe, That is a good point and a good pointer and we should reference it. It looks like draft-bonica-intarea-gre-mtu is relatively well advanced, = but it isn't an Int Area WG document. Can you let us know what the plans = are (adopted by a WG, AD sponsored, etc.)? Thanks, Adrian > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Joe Touch > Sent: 22 January 2014 01:21 > To: internet-drafts@ietf.org; i-d-announce@ietf.org > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] I-D Action: = draft-ietf-tsvwg-gre-in-udp-encap-00.txt >=20 > This doc should include some of the recommendations on GRE = fragmentation > summarized here: >=20 > draft-bonica-intarea-gre-mtu-03 >=20 > Ron and I spent quite a while going through the details; it'd be = useful > to not repeat that work in this doc. >=20 > Joe >=20 > On 1/10/2014 5:46 AM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the Transport Area Working Group = Working Group > of the IETF. > > > > Title : Generic UDP Encapsulation for IP = Tunneling > > Authors : Edward Crabbe > > Lucy Yong > > Xiaohu Xu > > Filename : draft-ietf-tsvwg-gre-in-udp-encap-00.txt > > Pages : 11 > > Date : 2014-01-09 > > > > Abstract: > > This document describes a method of encapsulating arbitrary = protocols > > within GRE and UDP headers. In this encapsulation, the source = UDP > > port may be used as an entropy field for purposes of = loadbalancing > > while the payload protocol may be identified by the GRE Protocol > > Type. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-00 > > > > > > 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 touch@isi.edu Wed Jan 22 13:37:58 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2831A02D5 for ; Wed, 22 Jan 2014 13:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 EGzl89m7gwUy for ; Wed, 22 Jan 2014 13:37:56 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 678E21A034A for ; Wed, 22 Jan 2014 13:37:56 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0MLbPGC020730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 13:37:25 -0800 (PST) Message-ID: <52E03A15.1070606@isi.edu> Date: Wed, 22 Jan 2014 13:37:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <20140110134619.2217.53215.idtracker@ietfa.amsl.com> <52DF1D03.9010900@isi.edu> <0e8601cf17ad$9f8ea320$deabe960$@olddog.co.uk> In-Reply-To: <0e8601cf17ad$9f8ea320$deabe960$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbonica@juniper.net, tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 21:37:58 -0000 On 1/22/2014 12:07 PM, Adrian Farrel wrote: > Joe, > > That is a good point and a good pointer and we should reference it. > > It looks like draft-bonica-intarea-gre-mtu is relatively well > advanced, but it isn't an Int Area WG document. Can you let us know what > the plans are (adopted by a WG, AD sponsored, etc.)? Ron might give us an update on that. I don't know the current status except as indicated within the document. Joe > > Thanks, > Adrian > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: 22 January 2014 01:21 >> To: internet-drafts@ietf.org; i-d-announce@ietf.org >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-00.txt >> >> This doc should include some of the recommendations on GRE fragmentation >> summarized here: >> >> draft-bonica-intarea-gre-mtu-03 >> >> Ron and I spent quite a while going through the details; it'd be useful >> to not repeat that work in this doc. >> >> Joe >> >> On 1/10/2014 5:46 AM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Transport Area Working Group Working Group >> of the IETF. >>> >>> Title : Generic UDP Encapsulation for IP Tunneling >>> Authors : Edward Crabbe >>> Lucy Yong >>> Xiaohu Xu >>> Filename : draft-ietf-tsvwg-gre-in-udp-encap-00.txt >>> Pages : 11 >>> Date : 2014-01-09 >>> >>> Abstract: >>> This document describes a method of encapsulating arbitrary protocols >>> within GRE and UDP headers. In this encapsulation, the source UDP >>> port may be used as an entropy field for purposes of loadbalancing >>> while the payload protocol may be identified by the GRE Protocol >>> Type. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-00 >>> >>> >>> 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 internet-drafts@ietf.org Wed Jan 22 14:22:53 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B9B1A04DA; Wed, 22 Jan 2014 14:22: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] 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 ReC7Ksiwg9vl; Wed, 22 Jan 2014 14:22:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FB61A04CB; Wed, 22 Jan 2014 14:22:51 -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: <20140122222251.2250.97785.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 14:22:51 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-prpolicies-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 22:22:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Additional Policies for the Partial Reliability E= xtension of the Stream Control Transmission Protocol Authors : Michael Tuexen Robin Seggelmann Randall R. Stewart Salvatore Loreto Filename : draft-ietf-tsvwg-sctp-prpolicies-01.txt Pages : 6 Date : 2014-01-22 Abstract: This document defines policies for the Partial Reliability Extension of the Stream Control Transmission Protocol (PR-SCTP) allowing to limit the number of retransmissions or to prioritize user messages for more efficient send buffer usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-prpolicies-01 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 rbonica@juniper.net Wed Jan 22 22:09:19 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987191A00EA for ; Wed, 22 Jan 2014 22:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 LvBaYvqA8wAK for ; Wed, 22 Jan 2014 22:09:16 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id A1C151A0200 for ; Wed, 22 Jan 2014 22:09:16 -0800 (PST) Received: from mail46-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE021.bigfish.com (10.43.70.78) with Microsoft SMTP Server id 14.1.225.22; Thu, 23 Jan 2014 06:09:15 +0000 Received: from mail46-ch1 (localhost [127.0.0.1]) by mail46-ch1-R.bigfish.com (Postfix) with ESMTP id BD5F73002EC; Thu, 23 Jan 2014 06:09:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I936eI542I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h9a9j1155h) Received-SPF: pass (mail46-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(377424004)(13464003)(189002)(199002)(164054003)(51704005)(377454003)(479174003)(24454002)(19580405001)(74706001)(83322001)(33646001)(54356001)(66066001)(86362001)(46102001)(50986001)(51856001)(47736001)(19580395003)(74876001)(65816001)(83072002)(85852003)(85306002)(53806001)(15202345003)(80022001)(47976001)(92566001)(74366001)(81686001)(93516002)(2171001)(74316001)(90146001)(93136001)(80976001)(56816005)(2656002)(81342001)(87936001)(76482001)(49866001)(47446002)(74662001)(74502001)(59766001)(81542001)(81816001)(79102001)(87266001)(31966008)(76576001)(63696002)(77096001)(15975445006)(77982001)(54316002)(4396001)(56776001)(76796001)(76786001)(69226001)(94316002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB437; H:BN1PR05MB439.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail46-ch1 (localhost.localdomain [127.0.0.1]) by mail46-ch1 (MessageSwitch) id 1390457353376599_23329; Thu, 23 Jan 2014 06:09:13 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail46-ch1.bigfish.com (Postfix) with ESMTP id 4CCE54E023E; Thu, 23 Jan 2014 06:09:13 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 23 Jan 2014 06:09:13 +0000 Received: from BN1PR05MB437.namprd05.prod.outlook.com (10.141.58.11) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 23 Jan 2014 06:09:12 +0000 Received: from BN1PR05MB439.namprd05.prod.outlook.com (10.141.58.22) by BN1PR05MB437.namprd05.prod.outlook.com (10.141.58.11) with Microsoft SMTP Server (TLS) id 15.0.859.15; Thu, 23 Jan 2014 06:09:10 +0000 Received: from BN1PR05MB439.namprd05.prod.outlook.com ([169.254.9.65]) by BN1PR05MB439.namprd05.prod.outlook.com ([169.254.9.65]) with mapi id 15.00.0859.013; Thu, 23 Jan 2014 06:09:09 +0000 From: Ronald Bonica To: "adrian@olddog.co.uk" , 'Joe Touch' Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-00.txt Thread-Index: AQFCMnMLhO1wXW+3iJN5MR0ZfmGUGwIuuYlJm5l/xACAAHYvcA== Date: Thu, 23 Jan 2014 06:09:08 +0000 Message-ID: References: <20140110134619.2217.53215.idtracker@ietfa.amsl.com> <52DF1D03.9010900@isi.edu> <0e8601cf17ad$9f8ea320$deabe960$@olddog.co.uk> In-Reply-To: <0e8601cf17ad$9f8ea320$deabe960$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-forefront-prvs: 0100732B76 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 06:09:19 -0000 Rm9sa3MsDQoNCkkgcHJvbWlzZSB0byB1cGRhdGUgdGhlIGRyYWZ0IGJlZm9yZSBJRVRGIDg5Lg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBBZHJpYW4gRmFycmVsIFttYWlsdG86YWRyaWFuQG9sZGRvZy5jby51 a10NCj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIyLCAyMDE0IDM6MDggUE0NCj4gVG86ICdK b2UgVG91Y2gnDQo+IENjOiB0c3Z3Z0BpZXRmLm9yZzsgUm9uYWxkIEJvbmljYQ0KPiBTdWJqZWN0 OiBSRTogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRzdndnLWdyZS1pbi11ZHAtZW5j YXAtDQo+IDAwLnR4dA0KPiANCj4gSm9lLA0KPiANCj4gVGhhdCBpcyBhIGdvb2QgcG9pbnQgYW5k IGEgZ29vZCBwb2ludGVyIGFuZCB3ZSBzaG91bGQgcmVmZXJlbmNlIGl0Lg0KPiANCj4gSXQgbG9v a3MgbGlrZSBkcmFmdC1ib25pY2EtaW50YXJlYS1ncmUtbXR1IGlzIHJlbGF0aXZlbHkgd2VsbCBh ZHZhbmNlZCwNCj4gYnV0IGl0IGlzbid0IGFuIEludCBBcmVhIFdHIGRvY3VtZW50LiBDYW4geW91 IGxldCB1cyBrbm93IHdoYXQgdGhlDQo+IHBsYW5zIGFyZSAoYWRvcHRlZCBieSBhIFdHLCBBRCBz cG9uc29yZWQsIGV0Yy4pPw0KPiANCj4gVGhhbmtzLA0KPiBBZHJpYW4NCj4gDQo+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2UgVG91Y2gNCj4gPiBTZW50OiAyMiBKYW51YXJ5 IDIwMTQgMDE6MjENCj4gPiBUbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnOyBpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmcNCj4gPiBDYzogdHN2d2dAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3Rz dndnXSBJLUQgQWN0aW9uOg0KPiA+IGRyYWZ0LWlldGYtdHN2d2ctZ3JlLWluLXVkcC1lbmNhcC0w MC50eHQNCj4gPg0KPiA+IFRoaXMgZG9jIHNob3VsZCBpbmNsdWRlIHNvbWUgb2YgdGhlIHJlY29t bWVuZGF0aW9ucyBvbiBHUkUNCj4gPiBmcmFnbWVudGF0aW9uIHN1bW1hcml6ZWQgaGVyZToNCj4g Pg0KPiA+IGRyYWZ0LWJvbmljYS1pbnRhcmVhLWdyZS1tdHUtMDMNCj4gPg0KPiA+IFJvbiBhbmQg SSBzcGVudCBxdWl0ZSBhIHdoaWxlIGdvaW5nIHRocm91Z2ggdGhlIGRldGFpbHM7IGl0J2QgYmUN Cj4gPiB1c2VmdWwgdG8gbm90IHJlcGVhdCB0aGF0IHdvcmsgaW4gdGhpcyBkb2MuDQo+ID4NCj4g PiBKb2UNCj4gPg0KPiA+IE9uIDEvMTAvMjAxNCA1OjQ2IEFNLCBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgd3JvdGU6DQo+ID4gPg0KPiA+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVzLg0KPiA+ ID4gICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUcmFuc3BvcnQgQXJlYSBXb3Jr aW5nIEdyb3VwDQo+ID4gPiBXb3JraW5nIEdyb3VwDQo+ID4gb2YgdGhlIElFVEYuDQo+ID4gPg0K PiA+ID4gICAgICAgICAgVGl0bGUgICAgICAgICAgIDogR2VuZXJpYyBVRFAgRW5jYXBzdWxhdGlv biBmb3IgSVANCj4gVHVubmVsaW5nDQo+ID4gPiAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBF ZHdhcmQgQ3JhYmJlDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBMdWN5IFlvbmcN Cj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFhpYW9odSBYdQ0KPiA+ID4gCUZpbGVu YW1lICAgICAgICA6IGRyYWZ0LWlldGYtdHN2d2ctZ3JlLWluLXVkcC1lbmNhcC0wMC50eHQNCj4g PiA+IAlQYWdlcyAgICAgICAgICAgOiAxMQ0KPiA+ID4gCURhdGUgICAgICAgICAgICA6IDIwMTQt MDEtMDkNCj4gPiA+DQo+ID4gPiBBYnN0cmFjdDoNCj4gPiA+ICAgICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBhIG1ldGhvZCBvZiBlbmNhcHN1bGF0aW5nIGFyYml0cmFyeQ0KPiBwcm90b2NvbHMN Cj4gPiA+ICAgICB3aXRoaW4gR1JFIGFuZCBVRFAgaGVhZGVycy4gIEluIHRoaXMgZW5jYXBzdWxh dGlvbiwgdGhlIHNvdXJjZQ0KPiBVRFANCj4gPiA+ICAgICBwb3J0IG1heSBiZSB1c2VkIGFzIGFu IGVudHJvcHkgZmllbGQgZm9yIHB1cnBvc2VzIG9mDQo+IGxvYWRiYWxhbmNpbmcNCj4gPiA+ICAg ICB3aGlsZSB0aGUgcGF5bG9hZCBwcm90b2NvbCBtYXkgYmUgaWRlbnRpZmllZCBieSB0aGUgR1JF DQo+IFByb3RvY29sDQo+ID4gPiAgICAgVHlwZS4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+ ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1ncmUt aW4tdWRwLWVuY2FwLw0KPiA+ID4NCj4gPiA+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNp b24gYXZhaWxhYmxlIGF0Og0KPiA+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi10c3Z3Zy1ncmUtaW4tdWRwLWVuY2FwLTAwDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mDQo+ID4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4gPg0KPiA+ID4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+ID4g ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPiA+DQo+IA0KPiANCg0K From bob.briscoe@bt.com Thu Jan 23 06:51:35 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259E01A0434; Thu, 23 Jan 2014 06:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 kU-VzVjD4OF6; Thu, 23 Jan 2014 06:51:32 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id A6CA81A045B; Thu, 23 Jan 2014 06:51:31 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 23 Jan 2014 14:51:30 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 23 Jan 2014 14:51:28 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Thu, 23 Jan 2014 14:51:28 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.25.144]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s0NEpQ4D000875; Thu, 23 Jan 2014 14:51:26 GMT Message-ID: <201401231451.s0NEpQ4D000875@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Jan 2014 14:51:25 +0000 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31EC25B8@ESESSMB205.ericss on.se> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <81564C0D7D4D2A4B9A86C8C7404A13DA31EC250B@ESESSMB205.ericsson.se> <201401212249.s0LMneWw026346@bagheera.jungle.bt.co.uk> <81564C0D7D4D2A4B9A86C8C7404A13DA31EC25B8@ESESSMB205.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "tsvwg@ietf.org" , "aqm@ietf.org" Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 14:51:35 -0000 Ingemar, inline... At 06:36 22/01/2014, Ingemar Johansson S wrote: >Hi > >Please find answers inline > >/Ingemar > > > -----Original Message----- > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > Sent: den 21 januari 2014 23:50 > > To: Ingemar Johansson S; Ruediger.Geib@telekom.de > > Cc: tsvwg@ietf.org; aqm@ietf.org > > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to= L2 > > or tunnel protocols? > > > > Ingemar, > > > > 1) Thx for the pointer. We should add this as another example where a= lower > > layer marks the IP header (the example we already have is the L3 switch= in > > the Ethernet world). > > > > 2) It doesn't talk about propagation of ECN markings during encap &= decap, > > which is one of the things ecn-encap-guidelines aims to give guidelines= on. > > Do you think a doc like the draft we've done=20 > would be useful to help 3GPP in > > this respect? Do you think a formal liaison=20 > would be useful to point it out? >L2 in this respect are the PDCP, RLC and MAC=20 >layers (to be honest I am not fully clear what=20 >constitutes L2). The problem is that to given=20 >encap/decap a meaning in this case it becomes=20 >necessary to encode at least an ECN-CE bit into=20 >any of the PDCP or RLC or MAC headers, as PDCP=20 >is ciphered it probably needs to be in the RLC=20 >or MAC headers. Currently there are no standards=20 >efforts to add an ECN-CE bit to any of these headers. I didn't mean encap of L3 in L2, because that=20 would indeed require major protocol changes. In=20 this case, the L2 node is marking L3 directly (see 1 above). I meant L3 in L3 (tunnelling), which is prevalent in 3GPP. > > > > 3) 3GPP TS 36.300 is ambiguous whether ECN=20 > marking is applied to all packets > > to "indicate congestion", or whether it is applied with a frequency or > > probability that depends on an AQM (it doesn't mention AQM, altho > > obviously it refers to RFC3168 that is based on AQM). Do you know= whether > > it was meant to imply use of AQM? >Yes, it is very ambiguous, I advocate for a=20 >frequency or probability as it makes most sense,=20 >but this is not specified at all. The ECN=20 >marking can imply the use of AQM but that is=20 >again not specified. In short, much of the=20 >actual implementation is vendor specific. OK. In general vendor-specific is good, and=20 congestion control can be robust to different behaviours. Our draft states that algorithm guidance is outside its scope, but... One of the purposes of the IETF's AQM guidance is=20 to set bounds on how much variety is feasible=20 without losing interworking. There's a message in=20 3GPP TS 36.300 on how the IETF's RFCs could be=20 (mis)interpreted, if we don't make them clear. Bob > > > > [Ruediger, thx for the supportive words too] > > > > > > Bob > > > > At 20:29 21/01/2014, Ingemar Johansson S wrote: > > >Hi > > > > > >Please note that ECN over LTE radio access is already standardized in > > >3GPP TS 36.300 (see 11.6 in > > >http://www.3gpp.org/ftp/specs/archive/36_series/36.300/36300-c00.zip ) > > > > > >/Ingemar > > > > -----Original Message----- > > > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > > > Sent: den 21 januari 2014 08:38 > > > > To: bob.briscoe@bt.com > > > > Cc: tsvwg@ietf.org; aqm@ietf.org > > > > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN > > > > to L2 or tunnel protocols? > > > > > > > > Hi Bob, > > > > > > > > I support the issue being picked up by IETF. What can be done within > > > > the bounds of IETF responsibility should be done. If ECN is seeing > > > > deployment, especially ECN support for IP over VLAN over IP/MPLS may > > be of interest. > > > > Further, ECN over LTE radio Access may be relevant (but my expertise > > > > is too limited to judge details). > > > > > > > > Regards, > > > > > > > > Ruediger > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] Im > > > > Auftrag von Bob Briscoe > > > > Gesendet: Montag, 4. November 2013 23:04 > > > > An: tsvwg IETF list; AQM IETF list > > > > Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org > > > > Betreff: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or > > > > tunnel protocols? > > > > > > > > Folks, > > > > > > > > Pls respond if you support this being adopted as a work-group item > > > > in the IETF transport services w-g (tsvwg). The WG > > > chairs need visibility of interest. > > > > Even better, if you're willing to read / comment / review / > > > > implement > > > > > > > > Guidelines for Adding Congestion Notification to Protocols that > > > > Encapsulate IP > > > >=20 > > >= > > > > > > > > > Abstract > > > > > > > > The purpose of this document is to guide the design of= congestion > > > > notification in any lower layer or tunnelling protocol that > > > > encapsulates IP. The aim is for explicit congestion signals to > > > > propagate consistently from lower=20 > layer protocols into IP. Then the > > > > IP internetwork layer can act as a portability layer to carry > > > > congestion notification from non-IP-aware congested nodes up to= the > > > > transport layer (L4). Following these guidelines should assure > > > > interworking between new lower layer congestion notification > > > > mechanisms, whether specified by the=20 > IETF or other standards bodies. > > > > > > > > > > > > [Cross-posting tsvwg & aqm, just in case] > > > > > > > > > > > > Bob Briscoe, > > > > also for co-authors Pat Thaler and John Kaippallimalil > > > > > > > > > > > > > > __________________________________________________________ > > > > ______ > > > > Bob Briscoe, BT > > > > > > > > > >_______________________________________________ > > >aqm mailing list > > >aqm@ietf.org > > >https://www.ietf.org/mailman/listinfo/aqm > > > > __________________________________________________________ > > ______ > > Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT=20 From bob.briscoe@bt.com Thu Jan 23 07:15:29 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8C01A002E; Thu, 23 Jan 2014 07:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 iVRx68Nc0iRw; Thu, 23 Jan 2014 07:15:23 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id D66671A0006; Thu, 23 Jan 2014 07:15:22 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 23 Jan 2014 15:15:21 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 23 Jan 2014 15:15:19 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Thu, 23 Jan 2014 15:15:17 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.25.144]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s0NFFF6T000987; Thu, 23 Jan 2014 15:15:16 GMT Message-ID: <201401231515.s0NFFF6T000987@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Jan 2014 15:15:14 +0000 To: Fred Baker , Gorry Fairhurst From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: AQM IETF list , tsvwg IETF list Subject: [tsvwg] How AQM Guidance might be misinterpreted X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 15:15:29 -0000 Fred, Gorry, In case you've tuned out of the thread below, it's worth reading the (very short) section on ECN in 3GPP TS 36.300 to understand how RFCs could be misinterpreted (link in email below). In this case, it's unclear but they seem to be assuming that there could be a special ECN marking behaviour on control signalling. It's ambiguous whether the 3GPP spec below intends to mean that ECN marking of a stream of packets is either all-on or all-off, rather than signalled by frequency/probability of marking. It's perhaps another example to be brought out in the AQM Guidance, probably under: "4.5. AQM algorithms SHOULD NOT be dependent on specific transport protocol behaviours" which currenty has only one example: "don't assume TCP". Bob >Date: Thu, 23 Jan 2014 14:51:25 +0000 >To: Ingemar Johansson S >From: Bob Briscoe >Subject: RE: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN >to L2 or tunnel protocols? >Cc: "Ruediger.Geib@telekom.de" , >"tsvwg@ietf.org" , "aqm@ietf.org" > >Ingemar, inline... > >At 06:36 22/01/2014, Ingemar Johansson S wrote: >>Hi >> >>Please find answers inline >> >>/Ingemar >> >> > -----Original Message----- >> > From: Bob Briscoe [mailto:bob.briscoe@bt.com] >> > Sent: den 21 januari 2014 23:50 >> > To: Ingemar Johansson S; Ruediger.Geib@telekom.de >> > Cc: tsvwg@ietf.org; aqm@ietf.org >> > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L2 >> > or tunnel protocols? >> > >> > Ingemar, [snip] >> > 3) 3GPP TS 36.300 is ambiguous whether ECN marking is applied to >> all packets >> > to "indicate congestion", or whether it is applied with a frequency or >> > probability that depends on an AQM (it doesn't mention AQM, altho >> > obviously it refers to RFC3168 that is based on AQM). Do you know whether >> > it was meant to imply use of AQM? >>Yes, it is very ambiguous, I advocate for a frequency or >>probability as it makes most sense, but this is not specified at >>all. The ECN marking can imply the use of AQM but that is again not >>specified. In short, much of the actual implementation is vendor specific. > >OK. In general vendor-specific is good, and congestion control can >be robust to different behaviours. > >Our draft states that algorithm guidance is outside its scope, but... > >One of the purposes of the IETF's AQM guidance is to set bounds on >how much variety is feasible without losing interworking. There's a >message in 3GPP TS 36.300 on how the IETF's RFCs could be >(mis)interpreted, if we don't make them clear. > >Bob > >> > At 20:29 21/01/2014, Ingemar Johansson S wrote: >> > >Hi >> > > >> > >Please note that ECN over LTE radio access is already standardized in >> > >3GPP TS 36.300 (see 11.6 in >> > >http://www.3gpp.org/ftp/specs/archive/36_series/36.300/36300-c00.zip ) >> > > >> > >/Ingemar ________________________________________________________________ Bob Briscoe, BT From fred@cisco.com Thu Jan 23 07:55:59 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9671A000F; Thu, 23 Jan 2014 07:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.036 X-Spam-Level: X-Spam-Status: No, score=-110.036 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.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 r2Nsf5GZ9fZR; Thu, 23 Jan 2014 07:55:57 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 8885F1A000A; Thu, 23 Jan 2014 07:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4414; q=dns/txt; s=iport; t=1390492557; x=1391702157; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9pPxRiCkVyAPSI9JjEDaVCUXawJyXNGFAB4byU40uIY=; b=SBV3UwD8+HGmefP0JBdCSoZNbVHNY8tJVveUD5dRXnMUFx9DK8kp2MYJ ONeEEG/+EWzgptbNURpHfTcbklw+3T5cOonGwBiGbH7MN0pxSrzs+gcl/ EijvibWk7xzeneeeeTlOyTB4rM5/Ghnrw+M4mCNzKnch1alNdfYlmFf+F w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFANA64VKtJXHA/2dsb2JhbABbgww4VrtzgRAWdIIlAQEBAwF5BQcEAgEIEQMBAQEBJwcyFAkIAgQOBQ6HbwgNxXAXjh4RASUaEQcGgx6BFASQPIExhjaBMosjhUODLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,706,1384300800"; d="asc'?scan'208";a="14991615" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-3.cisco.com with ESMTP; 23 Jan 2014 15:55:56 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0NFtuYb019016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 15:55:56 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.230]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 09:55:55 -0600 From: "Fred Baker (fred)" To: Bob Briscoe Thread-Topic: How AQM Guidance might be misinterpreted Thread-Index: AQHPGFOZ1wwzUzR7P0yCO+zyGWHQEA== Date: Thu, 23 Jan 2014 15:55:55 +0000 Message-ID: References: <201401231515.s0NFFF6T000987@bagheera.jungle.bt.co.uk> In-Reply-To: <201401231515.s0NFFF6T000987@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_C1A8AB3C-49D9-4760-9492-E5961522108C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Gorry Fairhurst , AQM IETF list , tsvwg IETF list Subject: Re: [tsvwg] How AQM Guidance might be misinterpreted X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 15:55:59 -0000 --Apple-Mail=_C1A8AB3C-49D9-4760-9492-E5961522108C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 23, 2014, at 7:15 AM, Bob Briscoe wrote: > Fred, Gorry, >=20 > In case you've tuned out of the thread below, it's worth reading the = (very short) section on ECN in 3GPP TS 36.300 to understand how RFCs = could be misinterpreted (link in email below). >=20 > In this case, it's unclear but they seem to be assuming that there = could be a special ECN marking behaviour on control signalling. It's = ambiguous whether the 3GPP spec below intends to mean that ECN marking = of a stream of packets is either all-on or all-off, rather than = signalled by frequency/probability of marking. >=20 > It's perhaps another example to be brought out in the AQM Guidance, = probably under: > "4.5. AQM algorithms SHOULD NOT be dependent on specific transport = protocol behaviours" > which currenty has only one example: "don't assume TCP". That seems reasonable. I'm not sure, though, what specific change you're = suggesting. Is it the addition of an example, or rewording of the = recommendation? Can you give us a specific proposed change? > Bob >=20 >=20 >> Date: Thu, 23 Jan 2014 14:51:25 +0000 >> To: Ingemar Johansson S >> From: Bob Briscoe >> Subject: RE: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN = to L2 or tunnel protocols? >> Cc: "Ruediger.Geib@telekom.de" , = "tsvwg@ietf.org" , "aqm@ietf.org" >>=20 >> Ingemar, inline... >>=20 >> At 06:36 22/01/2014, Ingemar Johansson S wrote: >>> Hi >>>=20 >>> Please find answers inline >>>=20 >>> /Ingemar >>>=20 >>> > -----Original Message----- >>> > From: Bob Briscoe [mailto:bob.briscoe@bt.com] >>> > Sent: den 21 januari 2014 23:50 >>> > To: Ingemar Johansson S; Ruediger.Geib@telekom.de >>> > Cc: tsvwg@ietf.org; aqm@ietf.org >>> > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding = ECN to L2 >>> > or tunnel protocols? >>> > >>> > Ingemar, >=20 > [snip] >=20 >>> > 3) 3GPP TS 36.300 is ambiguous whether ECN marking is applied to = all packets >>> > to "indicate congestion", or whether it is applied with a = frequency or >>> > probability that depends on an AQM (it doesn't mention AQM, altho >>> > obviously it refers to RFC3168 that is based on AQM). Do you know = whether >>> > it was meant to imply use of AQM? >>> Yes, it is very ambiguous, I advocate for a frequency or probability = as it makes most sense, but this is not specified at all. The ECN = marking can imply the use of AQM but that is again not specified. In = short, much of the actual implementation is vendor specific. >>=20 >> OK. In general vendor-specific is good, and congestion control can be = robust to different behaviours. >>=20 >> Our draft states that algorithm guidance is outside its scope, but... >>=20 >> One of the purposes of the IETF's AQM guidance is to set bounds on = how much variety is feasible without losing interworking. There's a = message in 3GPP TS 36.300 on how the IETF's RFCs could be = (mis)interpreted, if we don't make them clear. >>=20 >> Bob >>=20 >>> > At 20:29 21/01/2014, Ingemar Johansson S wrote: >>> > >Hi >>> > > >>> > >Please note that ECN over LTE radio access is already = standardized in >>> > >3GPP TS 36.300 (see 11.6 in >>> > = >http://www.3gpp.org/ftp/specs/archive/36_series/36.300/36300-c00.zip ) >>> > > >>> > >/Ingemar >=20 > ________________________________________________________________ > Bob Briscoe, BT=20 ------------------------------------------------------ 8 issues in virtual infrastructure http://dcrocker.net/#fallacies --Apple-Mail=_C1A8AB3C-49D9-4760-9492-E5961522108C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFS4TuIbjEdbHIsm0MRAnccAKC37EFLAHhHR5y+eZfpzFby0/ZAdQCfQ4Iz HtdXKSL4vabqoMVCaif4eJc= =DfC4 -----END PGP SIGNATURE----- --Apple-Mail=_C1A8AB3C-49D9-4760-9492-E5961522108C-- From ted.ietf@gmail.com Wed Jan 22 13:27:44 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE41A025A; Wed, 22 Jan 2014 13:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 2Aiz7y-wwwRl; Wed, 22 Jan 2014 13:27:40 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5661A026A; Wed, 22 Jan 2014 13:27:40 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id x13so156089ief.9 for ; Wed, 22 Jan 2014 13:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=noao96C6WliAI8uywHCD+Kqed29e+ON+bOXsNZKOK3w=; b=Lg8l+SEqZWcCkw++OGmY5zzWodUQmIscW088l/aSzBAxtk3pSjBVmPCQ5/qwGpv8mO MYW+lvME2EuBq48gQsIDnlg6/ZdnTfsLP5aDYxVWQRw2oagIsrjYu4TYC8fE9sFIFil1 fX3Rra7SnsH3Icn+n70jXk+IPz/S6PjsVFW6NUJOLA6cV8mfWpigTtpe7SqWCmrdLyGp 9SJt2AcvNHZFYzjGGlwh9YTZyY6b36sEMSUPQKz7SBB6YXUlvb2cYtFn5qt5TR23K6Zz EVYlUP1sHemFbnMiwXN/FS1yj2ihuYoCCOLIoAuyhB5URfBond93c2sq6LyijH9gBQ5z yj/Q== MIME-Version: 1.0 X-Received: by 10.43.56.4 with SMTP id wa4mr3136918icb.18.1390426059415; Wed, 22 Jan 2014 13:27:39 -0800 (PST) Received: by 10.43.65.14 with HTTP; Wed, 22 Jan 2014 13:27:39 -0800 (PST) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026F047D88@MX15A.corp.emc.com> References: <52AF0E7B.6030400@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712026F047C18@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712026F047D88@MX15A.corp.emc.com> Date: Wed, 22 Jan 2014 13:27:39 -0800 Message-ID: From: Ted Hardie To: "Black, David" Content-Type: multipart/alternative; boundary=bcaec517aa5a5ba5d604f095cb4d X-Mailman-Approved-At: Fri, 24 Jan 2014 09:15:10 -0800 Cc: "gorry@erg.abdn.ac.uk" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [rtcweb] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 21:27:45 -0000 --bcaec517aa5a5ba5d604f095cb4d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 22, 2014 at 7:28 AM, Black, David wrote: > Subha, > > > > I think some rewording is needed and reduction in scope. My concern is > two-fold: > > 1) RTC-Web documents should be focused on the browser and the browser > behavior. > Just as a wordsmithing correction, we should say "WebRTC endpoints" rather than browser, since mobile (or other) applications may use the WebRTC framework without being a browser. Though we could easily rat-hole on what constitutes a browser, generalizing this to "WebRTC endpoint" seems to avoid the issue. regards, Ted Hardie > This sort of discussion of traffic conditioning at network boundaries that > may > be well away from the browser seems peripheral. Given the strong desire > expressed > in both public and private by certain parties to get this draft done > quickly, > expanding its scope to non-essential areas seems like a poor move. > > 2) RTC-Web traffic will not be the only user of these PHBs and DSCPs, and > hence > probably should not be making recommendations on traffic conditioning in > general. If there's a way to specifically identify RTC-Web flows (e.g., > distinguish them from other uses of RTP), it could be appropriate to > discuss > what a multi-field (MF) classifier and associated traffic conditioning > (see RFC 2475) should do to them at network boundaries, but there's no > requirement to deploy MF classifiers at network boundaries. > > Unless there's an impact on how the browser should initially mark traffic, > it may > be better to remove this text. > > > > Thanks, > --David > > > -----Original Message----- > > From: Subha Dhesikan (sdhesika) [mailto:sdhesika@cisco.com] > > Sent: Tuesday, January 21, 2014 10:19 PM > > To: Black, David; gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de; > > tsvwg@ietf.org; rtcweb@ietf.org > > Subject: RE: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos > > > > David, > > > > Please help me understand: Are you suggesting that the whole text should > be > > removed or reworded to remove guidance and merely say that the DSCP > values may > > have to be combined based on network policies where application classes > are > > fewer. > > > > Regards, > > Subha > > > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Tuesday, January 21, 2014 10:59 AM > > To: Subha Dhesikan (sdhesika); gorry@erg.abdn.ac.uk; > Ruediger.Geib@telekom.de; > > tsvwg@ietf.org; rtcweb@ietf.org > > Cc: Black, David > > Subject: RE: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos > > > > > > > > > - Provided some guidance for networks with reduced number of DSCP > classes. > > > > That guidance would be (or would start with): > > > > If a packet enters a QoS domain that has no support for the above > > defined Data Types/Application classes, then the network node at the > > edge SHOULD map the DSCP value to one used by supported classes. > > Here are a couple of examples: > > > > o If a QoS domain supports only one video class, then the packets > > from the two video classes SHOULD be remarked to use the same > > DSCP, either AF4 or AF3 whichever is supported. > > o If a QoS domain supports a single class for all voice and video > > traffic, then the packets from all the video and voice classes > > SHOULD be combined and remarked to the single supported DSCP. > > > > This draft may not be a good place for that - there are concerns well > beyond > > rtcweb that drive these decisions by network architects/operators. > > > > > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Subha > > > Dhesikan > > > (sdhesika) > > > Sent: Tuesday, January 21, 2014 12:57 PM > > > To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de; tsvwg@ietf.org; > > > rtcweb@ietf.org > > > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos > > > > > > A new draft of the QoS document for rtcweb has been posted with the > > > edits suggested below. The edits are: > > > - Noted the trust issue and possibility of remarking at network edge > > > - Provided some guidance for networks with reduced number of DSCP > classes. > > > > > > > > > http://www.ietf.org/internet-drafts/draft-dhesikan-tsvwg-rtcweb-qos-04 > > > .txt > > > > > > Regards, > > > Subha > > > > > > > > > -----Original Message----- > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Subha > > > Dhesikan > > > (sdhesika) > > > Sent: Thursday, December 19, 2013 9:28 AM > > > To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de > > > Cc: tsvwg@ietf.org > > > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos > > > > > > Thank you for your comments, Ruediger and Gorry. > > > > > > Inline as SD: > > > > > > -----Original Message----- > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of > > > gorry@erg.abdn.ac.uk > > > Sent: Wednesday, December 18, 2013 3:28 AM > > > To: Ruediger.Geib@telekom.de > > > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > > > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos > > > > > > See a few thoughts in-line (with no chair-hat): > > > > > > > Hi Gorry, > > > > > > > > my small contribution to discuss the TSVWG input: > > > > > > > > draft dhesikan -03 is a rather short document. It is now focused on > > > > IP DSCP markings suggested for RTCweb traffic. I appreciate that the > > > > 3GPP QCI related discussion has been removed. > > > > > > > > The authors of draft dhesikan prefer to support a wide set of DSCPs > > > > and suggest to support different levels of priority. The > > > > introduction seems to say, it is largely considered to be applied > > > > within LANs, for home gateway internal classification and for Wifi. > That's > > fine with me. > > > > > > > > In the case of traffic sent to a network provider broadband access > > > > router / network gateway, I doubt that too many markings make sense. > > > > I'd expect the network provider routers or gateways not to trust > > > > DiffServ markings sent by a consumer device. The draft doesn't > > > > mention that. Adding such a note may be useful. > > > > > > > Personally I'd agree - it would be useful to describe this context > > > > > > SD: Sounds good. I will add a statement or two on lack of trust of > > > client devices and the effect on DSCP marking. > > > > > > In addition, I am expecting there will be some work done on the > > > authorization mechanisms for webrtc traffic that will allow some > > > off-path authorization of DSCP for particular flows. > > > > > > > As I'm known for simplistic approaches, my take is to mark traffic > > > > sent by a home gateway to a provider policy point by two DSCPs only, > > > > Best Effort and an AF PHB. I agree however with the authors, that a > > > > Home Gateway could and should internally apply a much more fine > > > > grained QoS differentiation for upstream traffic. If all home > > > > network devices apply proper markings as suggested by the authors, > this > > may help. > > > > > > > > > > I think it would be useful to say that each DSCP by a single app > > > require a way for the app or transport to know which work appropriately > > along that path. > > > Especially when traffic is dynamically moved between different PHB > groups. > > > > > > The fact that many deployed networks support a small set of DSCPs is > > > worth I think a mention. To me this has some implications, e.g. when > > > the App sets EF or CS1 and networks supports just AF and BE - intended > > > precedence would then rely upon correct treatment or re-marking. If > > > this were not appropriate, then the loss will depend upon whether it > > > was before or after the DSCPs were interpreted as intended. > > > > > > SD: ack. Yes, it is possible to add an example or two on how the DSCPs > > > defined in this document can be treated in a network that has only 2-4 > PHBs. > > > > > > > If there's interest to approach the 3GPP community for a discussion > > > > on a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to > help. > > > > This should be documented in a separate draft, as I'd expect this > > > > inter SDO work to consume a fair amount of time. > > > SD: I will also participate as needed. > > > > > > Regards, > > > Subha > > > > > > > > Regards and seasonal greetings, > > > > > > > > Ruediger > > > > > > > > > > > > > > > Gorry > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec517aa5a5ba5d604f095cb4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 22, 2014 at 7:28 AM= , Black, David <david.black@emc.com> wrote:
Subha,

<WG chair hat off>

I think some rewording is needed and reduction in scope. =A0My concern is t= wo-fold:

1) RTC-Web documents should be focused on the browser and the browser behav= ior.

Just as a wordsmithing correction, we should say "= WebRTC endpoints" rather than browser, since mobile (or other) applica= tions may use the WebRTC framework without being a browser.=A0 Though we co= uld easily rat-hole on what constitutes a browser, generalizing this to &qu= ot;WebRTC endpoint" seems to avoid the issue.

regards,

Ted Hardie

=A0
This sort of discussion of traffic conditioning at network boundaries that = may
be well away from the browser seems peripheral. =A0Given the strong desire = expressed
in both public and private by certain parties to get this draft done quickl= y,
expanding its scope to non-essential areas seems like a poor move.

2) RTC-Web traffic will not be the only user of these PHBs and DSCPs, and h= ence
probably should not be making recommendations on traffic conditioning in general. =A0If there's a way to specifically identify RTC-Web flows (e.= g.,
distinguish them from other uses of RTP), it could be appropriate to discus= s
what a multi-field (MF) classifier and associated traffic conditioning
(see RFC 2475) should do to them at network boundaries, but there's no<= br> requirement to deploy MF classifiers at network boundaries.

Unless there's an impact on how the browser should initially mark traff= ic, it may
be better to remove this text.

</WG chair hat off>

Thanks,
--David

> -----Original Message-----
> From: Subha Dhesikan (sdhesika) [mailto= :sdhesika@cisco.com]
> Sent: Tuesday, January 21, 2014 10:19 PM
> To: Black, David; gorry@erg.ab= dn.ac.uk; Ruediger.Geib@tel= ekom.de;
> tsvwg@ietf.org; rtcweb@ietf.org
> Subject: RE: [tsvwg] com= ments on draft-dhesikan-tsvwg-rtcweb-qos
>
> David,
>
> Please help me understand: Are you suggesting that the whole text shou= ld be
> removed or reworded to remove guidance and merely say that the DSCP va= lues may
> have to be combined based on network policies where application classe= s are
> fewer.
>
> Regards,
> Subha
>
> -----Original Message-----
> From: Black, David [mailto:davi= d.black@emc.com]
> Sent: Tuesday, January 21, 2014 10:59 AM
> To: Subha Dhesikan (sdhesika); gorry@erg.abdn.ac.uk; Rued= iger.Geib@telekom.de;
> tsvwg@ietf.org; rtcweb@ietf.org
> Cc: Black, David
> Subject: RE: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos
>
> <WG chair hat off>
>
> > - Provided some guidance for networks with reduced number of DSCP= classes.
>
> That guidance would be (or would start with):
>
> =A0 =A0If a packet enters a QoS domain that has no support for the abo= ve
> =A0 =A0defined Data Types/Application classes, then the network node a= t the
> =A0 =A0edge SHOULD map the DSCP value to one used by supported classes= .
> =A0 =A0Here are a couple of examples:
>
> =A0 =A0o =A0If a QoS domain supports only one video class, then the pa= ckets
> =A0 =A0 =A0 from the two video classes SHOULD be remarked to use the s= ame
> =A0 =A0 =A0 DSCP, either AF4 or AF3 whichever is supported.
> =A0 =A0o =A0If a QoS domain supports a single class for all voice and = video
> =A0 =A0 =A0 traffic, then the packets from all the video and voice cla= sses
> =A0 =A0 =A0 SHOULD be combined and remarked to the single supported DS= CP.
>
> This draft may not be a good place for that - there are concerns well = beyond
> rtcweb that drive these decisions by network architects/operators.
>
> </WG chair hat off>
>
> Thanks,
> --David
>
> > -----Original Message-----
> > From: tsvwg [mailto:tsv= wg-bounces@ietf.org] On Behalf Of Subha
> > Dhesikan
> > (sdhesika)
> > Sent: Tuesday, January 21, 2014 12:57 PM
> > To: gorry@erg.abdn.ac.uk<= /a>; Ruediger.Geib@telekom.de; tsvwg@ietf.org;
> > rtcweb@ietf.org
> > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos<= br> > >
> > A new draft of the QoS document for rtcweb has been posted with t= he
> > edits suggested below. The edits are:
> > - Noted the trust issue and possibility of remarking at network e= dge
> > - Provided some guidance for networks with reduced number of DSCP= classes.
> >
> >
> > http://www.ietf.org/internet-drafts/dra= ft-dhesikan-tsvwg-rtcweb-qos-04
> > .txt
> >
> > Regards,
> > Subha
> >
> >
> > -----Original Message-----
> > From: tsvwg [mailto:tsv= wg-bounces@ietf.org] On Behalf Of Subha
> > Dhesikan
> > (sdhesika)
> > Sent: Thursday, December 19, 2013 9:28 AM
> > To: gorry@erg.abdn.ac.uk<= /a>; Ruediger.Geib@telekom.de
> > Cc: tsvwg@ietf.org
> > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos<= br> > >
> > Thank you for your comments, Ruediger and Gorry.
> >
> > Inline as SD:
> >
> > -----Original Message-----
> > From: tsvwg [mailto:tsv= wg-bounces@ietf.org] On Behalf Of
> > gorry@erg.abdn.ac.uk<= br> > > Sent: Wednesday, December 18, 2013 3:28 AM
> > To: Ruediger.Geib@tel= ekom.de
> > Cc: gorry@erg.abdn.ac.uk<= /a>; tsvwg@ietf.org
> > Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos<= br> > >
> > See a few thoughts in-line (with no chair-hat):
> >
> > > Hi Gorry,
> > >
> > > my small contribution to discuss the TSVWG input:
> > >
> > > draft dhesikan -03 is a rather short document. It is now foc= used on
> > > IP DSCP markings suggested for RTCweb traffic. I appreciate = that the
> > > 3GPP QCI related discussion has been removed.
> > >
> > > The authors of draft dhesikan prefer to support a wide set o= f DSCPs
> > > and suggest to support different levels of priority. The
> > > introduction seems to say, it is largely considered to be ap= plied
> > > within LANs, for home gateway internal classification and fo= r Wifi. That's
> fine with me.
> > >
> > > In the case of traffic sent to a network provider broadband = access
> > > router / network gateway, I doubt that too many markings mak= e sense.
> > > I'd expect the network provider routers or gateways not = to trust
> > > DiffServ markings sent by a consumer device. The draft doesn= 't
> > > mention that. Adding such a note may be useful.
> > >
> > Personally I'd agree - it would be useful to describe this co= ntext
> >
> > SD: =A0Sounds good. I will add a statement or two on lack of trus= t of
> > client devices and the effect on DSCP marking.
> >
> > In addition, I am expecting there will be some work done on the > > authorization mechanisms for webrtc traffic that will allow some<= br> > > off-path authorization of DSCP for particular flows.
> >
> > > As I'm known for simplistic approaches, my take is to ma= rk traffic
> > > sent by a home gateway to a provider policy point by two DSC= Ps only,
> > > Best Effort and an AF PHB. I agree however with the authors,= that a
> > > Home Gateway could and should internally apply a much more f= ine
> > > grained QoS differentiation for upstream traffic. If all hom= e
> > > network devices apply proper markings as suggested by the au= thors, this
> may help.
> > >
> >
> > I think it would be useful to say that each DSCP by a single app<= br> > > require a way for the app or transport to know which work appropr= iately
> along that path.
> > Especially when traffic is dynamically moved between different PH= B groups.
> >
> > The fact that many deployed networks support a small set of DSCPs= is
> > worth I think a mention. To me this has some implications, e.g. w= hen
> > the App sets EF or CS1 and networks supports just AF and BE - int= ended
> > precedence would then rely upon correct treatment or re-marking. = If
> > this were not appropriate, then the loss will depend upon whether= it
> > was before or after the DSCPs were interpreted as intended.
> >
> > SD: ack. Yes, it is possible to add an example or two on how the = DSCPs
> > defined in this document can be treated in a network that has onl= y 2-4 PHBs.
> >
> > > If there's interest to approach the 3GPP community for a= discussion
> > > on a useful relation between 3GPP QCIs and IP PHBs, I'd = be happy to help.
> > > This should be documented in a separate draft, as I'd ex= pect this
> > > inter SDO work to consume a fair amount of time.
> > SD: I will also participate as needed.
> >
> > Regards,
> > Subha
> > >
> > > Regards and seasonal greetings,
> > >
> > > Ruediger
> > >
> > >
> > >
> > Gorry
> >
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec517aa5a5ba5d604f095cb4d-- From ingemar.s.johansson@ericsson.com Tue Jan 21 12:29:12 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B191A02E7; Tue, 21 Jan 2014 12:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 lMQqFR-F-eoZ; Tue, 21 Jan 2014 12:29:09 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 260031A02DC; Tue, 21 Jan 2014 12:29:08 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-5a-52ded89468a5 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A5.2F.10875.498DED25; Tue, 21 Jan 2014 21:29:08 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.205]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Tue, 21 Jan 2014 21:29:07 +0100 From: Ingemar Johansson S To: "Ruediger.Geib@telekom.de" , "bob.briscoe@bt.com" Thread-Topic: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHPFuN4cehttPFQ50yooU+SLXqCYZqPn5Ow Date: Tue, 21 Jan 2014 20:29:06 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31EC250B@ESESSMB205.ericsson.se> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje6UG/eCDHo3C1ms2SdpMX39F0aL D9M4LI69ucvmwOLR9mUyk8eSJT+ZPNpeKgQwR3HZpKTmZJalFunbJXBltEx7yFjwXqTi6ut3 zA2MxwW6GDk4JARMJC6tV+1i5AQyxSQu3FvP1sXIxSEkcIhR4sW9V8wQzhJGiSu3W5hAqtgE bCRWHvrOCGKLCKRJnP54hx1kELOAi8TU/cwgYWGBRInza88yQZQkSRy6tQGq3Eji2N7ZYDUs AqoS854cBqvhFfCVWHxpD9SuyYwS95Y/BJvJKRAtMf2LOkgNo4CsxP3v91hAbGYBcYlbT+Yz QRwtILFkz3lmCFtU4uXjf6wQtpLEiu2XGCHq9SRuTJ3CBmFrSyxb+JoZYq+gxMmZT1gmMIrN QjJ2FpKWWUhaZiFpWcDIsoqRPTcxMye93HATIzByDm75rbuD8dQ5kUOM0hwsSuK8H946BwkJ pCeWpGanphakFsUXleakFh9iZOLglGpgVPx7eprUprLpu6KL/Ge1KG7++Pf81O+6BV/WXtKQ vSwxVdHm/h4mJ7O6lWWH43/ble6JizrkzdzvqCMhESZ8T1rrvWzbh6T4HaXhS69lWjyf23a/ Zrmd/qH7fwsKCpcV6AVs3DBNYt6yI4XZt9b0K/g4Je3d5Oj42fdE/IH4OX0Ln7owZhW6KLEU ZyQaajEXFScCABmYLVhqAgAA X-Mailman-Approved-At: Fri, 24 Jan 2014 09:16:28 -0800 Cc: "tsvwg@ietf.org" , "aqm@ietf.org" Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:29:12 -0000 Hi Please note that ECN over LTE radio access is already standardized in 3GPP = TS 36.300 (see 11.6 in http://www.3gpp.org/ftp/specs/archive/36_series/36.3= 00/36300-c00.zip ) /Ingemar > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: den 21 januari 2014 08:38 > To: bob.briscoe@bt.com > Cc: tsvwg@ietf.org; aqm@ietf.org > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L= 2 > or tunnel protocols? >=20 > Hi Bob, >=20 > I support the issue being picked up by IETF. What can be done within the > bounds of IETF responsibility should be done. If ECN is seeing deployment= , > especially ECN support for IP over VLAN over IP/MPLS may be of interest. > Further, ECN over LTE radio Access may be relevant (but my expertise is t= oo > limited to judge details). >=20 > Regards, >=20 > Ruediger >=20 > -----Urspr=FCngliche Nachricht----- > Von: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] Im Auftrag > von Bob Briscoe > Gesendet: Montag, 4. November 2013 23:04 > An: tsvwg IETF list; AQM IETF list > Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org > Betreff: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunne= l > protocols? >=20 > Folks, >=20 > Pls respond if you support this being adopted as a work-group item in the > IETF transport services w-g (tsvwg). The WG chairs need visibility of int= erest. > Even better, if you're willing to read / comment / review / implement >=20 > Guidelines for Adding Congestion Notification to Protocols that Encapsula= te > IP >=20 > Abstract >=20 > The purpose of this document is to guide the design of congestion > notification in any lower layer or tunnelling protocol that > encapsulates IP. The aim is for explicit congestion signals to > propagate consistently from lower layer protocols into IP. Then the > IP internetwork layer can act as a portability layer to carry > congestion notification from non-IP-aware congested nodes up to the > transport layer (L4). Following these guidelines should assure > interworking between new lower layer congestion notification > mechanisms, whether specified by the IETF or other standards bodies. >=20 >=20 > [Cross-posting tsvwg & aqm, just in case] >=20 >=20 > Bob Briscoe, > also for co-authors Pat Thaler and John Kaippallimalil >=20 >=20 > __________________________________________________________ > ______ > Bob Briscoe, BT >=20 From curtis@ipv6.occnc.com Fri Jan 17 12:28:35 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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 X-Mailman-Approved-At: Fri, 24 Jan 2014 09:16:29 -0800 Cc: mpls@ietf.org, lisp@ietf.org, tsvwg@ietf.org, ietf@ietf.org Subject: Re: [tsvwg] [mpls] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Transport Area Working Group 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 Alexander.Vainshtein@ecitele.com Sun Jan 19 21:44:43 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: Fri, 24 Jan 2014 09:16:28 -0800 Cc: Randy Bush , "mpls@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] GRE in UDP - traffic distribution ( was RE: [mpls] OT (was Re: draft-ietf-mpls-in-udp) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group 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 ingemar.s.johansson@ericsson.com Tue Jan 21 22:36:30 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14951A0237; Tue, 21 Jan 2014 22:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 Q0_mTOxCYwac; Tue, 21 Jan 2014 22:36:27 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5642F1A01AA; Tue, 21 Jan 2014 22:36:26 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-3d-52df66e910c3 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B3.91.10875.9E66FD25; Wed, 22 Jan 2014 07:36:25 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.205]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Wed, 22 Jan 2014 07:36:24 +0100 From: Ingemar Johansson S To: Bob Briscoe , "Ruediger.Geib@telekom.de" Thread-Topic: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHPFvsUyg4YEXg0W0GlvtH5Ta2mz5qQR/iQ Date: Wed, 22 Jan 2014 06:36:24 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31EC25B8@ESESSMB205.ericsson.se> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <81564C0D7D4D2A4B9A86C8C7404A13DA31EC250B@ESESSMB205.ericsson.se> <201401212249.s0LMneWw026346@bagheera.jungle.bt.co.uk> In-Reply-To: <201401212249.s0LMneWw026346@bagheera.jungle.bt.co.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje7LtPtBBg87+CzW7JO0mL7+C6PF h2kcFsfe3GVzYPFo+zKZyWPJkp9MHm0vFQKYo7hsUlJzMstSi/TtErgyNrXfZC7YpFlxbPVG tgbGV/JdjJwcEgImEkdXLGKHsMUkLtxbzwZiCwkcYpTYcUWmi5ELyF7CKLH233+wBJuAjcTK Q98ZQWwRgViJeX/uMXUxcnAwC7hITN3PDBIWFkiSeHu6mQWiJFniwuYdbCAlIgJGEvv+ZIGE WQRUJa5MamYCsXkFfCVuX5rFCrFqApPEjL0fWEESnALOEts6l4GtZRSQlbj//R7YTGYBcYlb T+YzQdwsILFkz3lmCFtU4uXjf6wQtpLEiu2XGCHq9SRuTJ3CBmFrSyxb+JoZYrGgxMmZT1gm MIrNQjJ2FpKWWUhaZiFpWcDIsoqRPTcxMye93HATIzByDm75rbuD8dQ5kUOM0hwsSuK8H946 BwkJpCeWpGanphakFsUXleakFh9iZOLglGpglD5UNGH7FOe0fccW+8Ue3t24tGlVWO7K5DIp g+qpHKK3mHYvN2708V0avqn50AF2FvcnyqkL7y9xytu/vTDoefaFE876DZeff9/SynpI50Rm dMHWeifButppq7pSNuRLBikH/T9/8Y1J6MeTssfVytwPe11RPOFuxvfQ/2rRzpRyYZ+2xyaN SizFGYmGWsxFxYkA2jLvRGoCAAA= X-Mailman-Approved-At: Fri, 24 Jan 2014 09:16:28 -0800 Cc: "tsvwg@ietf.org" , "aqm@ietf.org" Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 06:36:30 -0000 Hi Please find answers inline /Ingemar > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: den 21 januari 2014 23:50 > To: Ingemar Johansson S; Ruediger.Geib@telekom.de > Cc: tsvwg@ietf.org; aqm@ietf.org > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L= 2 > or tunnel protocols? >=20 > Ingemar, >=20 > 1) Thx for the pointer. We should add this as another example where a low= er > layer marks the IP header (the example we already have is the L3 switch i= n > the Ethernet world). >=20 > 2) It doesn't talk about propagation of ECN markings during encap & decap= , > which is one of the things ecn-encap-guidelines aims to give guidelines o= n. > Do you think a doc like the draft we've done would be useful to help 3GPP= in > this respect? Do you think a formal liaison would be useful to point it o= ut? L2 in this respect are the PDCP, RLC and MAC layers (to be honest I am not = fully clear what constitutes L2). The problem is that to given encap/decap = a meaning in this case it becomes necessary to encode at least an ECN-CE bi= t into any of the PDCP or RLC or MAC headers, as PDCP is ciphered it probab= ly needs to be in the RLC or MAC headers. Currently there are no standards = efforts to add an ECN-CE bit to any of these headers. >=20 > 3) 3GPP TS 36.300 is ambiguous whether ECN marking is applied to all pack= ets > to "indicate congestion", or whether it is applied with a frequency or > probability that depends on an AQM (it doesn't mention AQM, altho > obviously it refers to RFC3168 that is based on AQM). Do you know whether > it was meant to imply use of AQM? Yes, it is very ambiguous, I advocate for a frequency or probability as it = makes most sense, but this is not specified at all. The ECN marking can imp= ly the use of AQM but that is again not specified. In short, much of the ac= tual implementation is vendor specific. >=20 > [Ruediger, thx for the supportive words too] >=20 >=20 > Bob >=20 > At 20:29 21/01/2014, Ingemar Johansson S wrote: > >Hi > > > >Please note that ECN over LTE radio access is already standardized in > >3GPP TS 36.300 (see 11.6 in > >http://www.3gpp.org/ftp/specs/archive/36_series/36.300/36300-c00.zip ) > > > >/Ingemar > > > -----Original Message----- > > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > > Sent: den 21 januari 2014 08:38 > > > To: bob.briscoe@bt.com > > > Cc: tsvwg@ietf.org; aqm@ietf.org > > > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN > > > to L2 or tunnel protocols? > > > > > > Hi Bob, > > > > > > I support the issue being picked up by IETF. What can be done within > > > the bounds of IETF responsibility should be done. If ECN is seeing > > > deployment, especially ECN support for IP over VLAN over IP/MPLS may > be of interest. > > > Further, ECN over LTE radio Access may be relevant (but my expertise > > > is too limited to judge details). > > > > > > Regards, > > > > > > Ruediger > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] Im > > > Auftrag von Bob Briscoe > > > Gesendet: Montag, 4. November 2013 23:04 > > > An: tsvwg IETF list; AQM IETF list > > > Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org > > > Betreff: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or > > > tunnel protocols? > > > > > > Folks, > > > > > > Pls respond if you support this being adopted as a work-group item > > > in the IETF transport services w-g (tsvwg). The WG > > chairs need visibility of interest. > > > Even better, if you're willing to read / comment / review / > > > implement > > > > > > Guidelines for Adding Congestion Notification to Protocols that > > > Encapsulate IP > > > > > > > > > > > > Abstract > > > > > > The purpose of this document is to guide the design of congestion > > > notification in any lower layer or tunnelling protocol that > > > encapsulates IP. The aim is for explicit congestion signals to > > > propagate consistently from lower layer protocols into IP. Then = the > > > IP internetwork layer can act as a portability layer to carry > > > congestion notification from non-IP-aware congested nodes up to t= he > > > transport layer (L4). Following these guidelines should assure > > > interworking between new lower layer congestion notification > > > mechanisms, whether specified by the IETF or other standards bodi= es. > > > > > > > > > [Cross-posting tsvwg & aqm, just in case] > > > > > > > > > Bob Briscoe, > > > also for co-authors Pat Thaler and John Kaippallimalil > > > > > > > > > > __________________________________________________________ > > > ______ > > > Bob Briscoe, BT > > > > > > >_______________________________________________ > >aqm mailing list > >aqm@ietf.org > >https://www.ietf.org/mailman/listinfo/aqm >=20 > __________________________________________________________ > ______ > Bob Briscoe, BT From david.black@emc.com Wed Jan 29 13:41:02 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176121A0368 for ; Wed, 29 Jan 2014 13:41:02 -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, 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 3AotMxMKVX94 for ; Wed, 29 Jan 2014 13:41:00 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7491A0351 for ; Wed, 29 Jan 2014 13:41:00 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0TLeock001974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jan 2014 16:40:51 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s0TLeock001974 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1391031651; bh=UsEe/4AE8pnX/IMY0xJ4v23BD58=; h=From:To:Date:Subject:Message-ID:References:Content-Type: Content-Transfer-Encoding:MIME-Version; b=b8++B4xEVLb4dbnFPGSARkFFBYYlOOdiDocfl2cKWU9b1ZMk1mB6qqPtuvjDFGll9 4MUqyLWOs15cZuGxKTw3efGu4wH2V23vqk29SlPUtD9UjMFGSbMMLdTAuVafpYtM1x Wf+NdML2S/HF+33BlPiTD7fjloGuHiperJZj0Iis= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s0TLeock001974 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd51.lss.emc.com (RSA Interceptor) for ; Wed, 29 Jan 2014 16:40:38 -0500 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0TLecIU024293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 29 Jan 2014 16:40:38 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Wed, 29 Jan 2014 16:40:37 -0500 From: "Black, David" To: "tsvwg@ietf.org" Date: Wed, 29 Jan 2014 16:40:36 -0500 Thread-Topic: Web-based email list archive search and browsing tool ready for use Thread-Index: Ac8dMyJkrrNZ6S/rRYWp+jTsqecqoQAB01ZwAAARcVA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026F16283D@MX15A.corp.emc.com> References: 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: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Subject: [tsvwg] FW: Web-based email list archive search and browsing tool ready for use X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 21:41:02 -0000 An improved interface has been released for accessing the email archive. P= lease see the information provided below. Thanks, --David -----Original Message----- From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IE= TF Chair Sent: Wednesday, January 29, 2014 3:45 PM To: ietf-announce@ietf.org Cc: ietf@ietf.org Mailing List; tools-discuss@ietf.org Subject: Web-based email list archive search and browsing tool ready for us= e The tool realizing the requirements we developed in RFC 6778 is ready for y= our use. You'll find the service at https://mailarchive.ietf.org/ If you choose to log in, use your datatracker credentials. If you see issues in the messages for a list, please contact the list's adm= inistrators (typically the working group chairs for working group lists). If you encounter other problems or have suggestions for future improvements= , please file a report using http://trac.tools.ietf.org/tools/ietfdb/newtic= ket If you find spam in the archives, please send a request to remove it includ= ing a link to the message to action@ietf.org. We are still working towards providing IMAP access to the archives. That is= not part of the tool at this time. The old archives will continue to receive new messages and will be availabl= e in their current locations until further notice. Early testers have reported this tool to be very useful. I hope you also fi= nd it to be so. (And I'd like to thank the tools team, AMS, and the early t= esters for this service!) Jari Arkko IETF Chair From ingemar.s.johansson@ericsson.com Thu Jan 30 04:46:42 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0151A039B; Thu, 30 Jan 2014 04:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 otQ5_PUmfu8S; Thu, 30 Jan 2014 04:46:40 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1741A03DB; Thu, 30 Jan 2014 04:46:39 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-0f-52ea49ab7dad Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FB.A8.23809.BA94AE25; Thu, 30 Jan 2014 13:46:35 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.233]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Thu, 30 Jan 2014 13:46:35 +0100 From: Ingemar Johansson S To: Bob Briscoe Thread-Topic: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHPGEqaa95X78tpWEWrA0Il1VF6DZqdPqvg Date: Thu, 30 Jan 2014 12:46:33 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31ED40CF@ESESSMB205.ericsson.se> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <81564C0D7D4D2A4B9A86C8C7404A13DA31EC250B@ESESSMB205.ericsson.se> <201401212249.s0LMneWw026346@bagheera.jungle.bt.co.uk> <81564C0D7D4D2A4B9A86C8C7404A13DA31EC25B8@ESESSMB205.ericsson.se> <201401231451.s0NEpQ4D000875@bagheera.jungle.bt.co.uk> In-Reply-To: <201401231451.s0NEpQ4D000875@bagheera.jungle.bt.co.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje5qz1dBBsfu6Fqs2SdpMX39F0aL D9M4LI69ucvmwOLR9mUyk8eSJT+ZPNpeKgQwR3HZpKTmZJalFunbJXBlPHpzj6Vgh2XFnMcR DYx92l2MnBwSAiYS547eYYSwxSQu3FvP1sXIxSEkcIhRYtqjVmaQhJDAEkaJ70fdQWw2ARuJ lYe+gzWICKhIHNs5A6iGg4NZoFZibn8SSFhYIFniadN1JoiSFIl/a+azQ9hGEncevQZrZRFQ lWiZugNsPK+Ar0Tj/G52iL29zBI7utrBGjgFnCX2XzjBBmIzCshK3P9+jwXEZhYQl7j1ZD4T xNECEkv2nGeGsEUlXj7+xwphK0p8fLWPEaJeT+LG1ClsELa2xLKFr6EWC0qcnPmEZQKj2Cwk Y2chaZmFpGUWkpYFjCyrGNlzEzNz0suNNjECI+fglt+qOxjvnBM5xCjNwaIkzvvhrXOQkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBkb1Q38O2E773+D6V/Pl7qRtPE8yW+a+DPW+K71GoGOL 9XSejjc6L4yUnHxmm3/Ne/PmSYNx1NcSmRPfE/XXRhy6z3LOUkfysXnQyye53Ru3HvCVbt5/ 1PdVrOWvqJf3kyyYfz0UU5e7Ic/gdSI2ISKAfcVL1+iXz9XYN6wXf3/1Siy7vs+iLc1KLMUZ iYZazEXFiQD9B8ylagIAAA== X-Mailman-Approved-At: Thu, 30 Jan 2014 05:58:39 -0800 Cc: "tsvwg@ietf.org" , "aqm@ietf.org" Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 12:46:42 -0000 Hi Sorry about the slow response and thanks for the L2/L3 clarification.=20 As regards to the more detailed specifics around ECN, agree, I believe that= the AQM WG can be helpful here and give recommendations on how packets sho= uld be ECN marked. /Ingemar > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: den 23 januari 2014 15:51 > To: Ingemar Johansson S > Cc: Ruediger.Geib@telekom.de; tsvwg@ietf.org; aqm@ietf.org > Subject: RE: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L= 2 > or tunnel protocols? >=20 > Ingemar, inline... >=20 > At 06:36 22/01/2014, Ingemar Johansson S wrote: > >Hi > > > >Please find answers inline > > > >/Ingemar > > > > > -----Original Message----- > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > Sent: den 21 januari 2014 23:50 > > > To: Ingemar Johansson S; Ruediger.Geib@telekom.de > > > Cc: tsvwg@ietf.org; aqm@ietf.org > > > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN > > > to L2 or tunnel protocols? > > > > > > Ingemar, > > > > > > 1) Thx for the pointer. We should add this as another example where > > > a lower layer marks the IP header (the example we already have is > > > the L3 switch in the Ethernet world). > > > > > > 2) It doesn't talk about propagation of ECN markings during encap & > > > decap, which is one of the things ecn-encap-guidelines aims to give > guidelines on. > > > Do you think a doc like the draft we've done > > would be useful to help 3GPP in > > > this respect? Do you think a formal liaison > > would be useful to point it out? > >L2 in this respect are the PDCP, RLC and MAC layers (to be honest I am > >not fully clear what constitutes L2). The problem is that to given > >encap/decap a meaning in this case it becomes necessary to encode at > >least an ECN-CE bit into any of the PDCP or RLC or MAC headers, as PDCP > >is ciphered it probably needs to be in the RLC or MAC headers. > >Currently there are no standards efforts to add an ECN-CE bit to any of > >these headers. >=20 > I didn't mean encap of L3 in L2, because that would indeed require major > protocol changes. In this case, the L2 node is marking L3 directly (see 1 > above). >=20 > I meant L3 in L3 (tunnelling), which is prevalent in 3GPP. >=20 > > > > > > 3) 3GPP TS 36.300 is ambiguous whether ECN > > marking is applied to all packets > > > to "indicate congestion", or whether it is applied with a frequency > > > or probability that depends on an AQM (it doesn't mention AQM, altho > > > obviously it refers to RFC3168 that is based on AQM). Do you know > > > whether it was meant to imply use of AQM? > >Yes, it is very ambiguous, I advocate for a frequency or probability as > >it makes most sense, but this is not specified at all. The ECN marking > >can imply the use of AQM but that is again not specified. In short, > >much of the actual implementation is vendor specific. >=20 > OK. In general vendor-specific is good, and congestion control can be rob= ust > to different behaviours. >=20 > Our draft states that algorithm guidance is outside its scope, but... >=20 > One of the purposes of the IETF's AQM guidance is to set bounds on how > much variety is feasible without losing interworking. There's a message i= n > 3GPP TS 36.300 on how the IETF's RFCs could be (mis)interpreted, if we do= n't > make them clear. >=20 >=20 > Bob >=20 >=20 > > > > > > [Ruediger, thx for the supportive words too] > > > > > > > > > Bob > > > > > > At 20:29 21/01/2014, Ingemar Johansson S wrote: > > > >Hi > > > > > > > >Please note that ECN over LTE radio access is already standardized > > > >in 3GPP TS 36.300 (see 11.6 in > > > >http://www.3gpp.org/ftp/specs/archive/36_series/36.300/36300-c00.zi > > > >p ) > > > > > > > >/Ingemar > > > > > -----Original Message----- > > > > > From: Ruediger.Geib@telekom.de > [mailto:Ruediger.Geib@telekom.de] > > > > > Sent: den 21 januari 2014 08:38 > > > > > To: bob.briscoe@bt.com > > > > > Cc: tsvwg@ietf.org; aqm@ietf.org > > > > > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding > > > > > ECN to L2 or tunnel protocols? > > > > > > > > > > Hi Bob, > > > > > > > > > > I support the issue being picked up by IETF. What can be done > > > > > within the bounds of IETF responsibility should be done. If ECN > > > > > is seeing deployment, especially ECN support for IP over VLAN > > > > > over IP/MPLS may > > > be of interest. > > > > > Further, ECN over LTE radio Access may be relevant (but my > > > > > expertise is too limited to judge details). > > > > > > > > > > Regards, > > > > > > > > > > Ruediger > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] Im > > > > > Auftrag von Bob Briscoe > > > > > Gesendet: Montag, 4. November 2013 23:04 > > > > > An: tsvwg IETF list; AQM IETF list > > > > > Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org > > > > > Betreff: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 > > > > > or tunnel protocols? > > > > > > > > > > Folks, > > > > > > > > > > Pls respond if you support this being adopted as a work-group > > > > > item in the IETF transport services w-g (tsvwg). The WG > > > > chairs need visibility of interest. > > > > > Even better, if you're willing to read / comment / review / > > > > > implement > > > > > > > > > > Guidelines for Adding Congestion Notification to Protocols that > > > > > Encapsulate IP > > > > > > > > > > > > > > > > > > > > > > Abstract > > > > > > > > > > The purpose of this document is to guide the design of conges= tion > > > > > notification in any lower layer or tunnelling protocol that > > > > > encapsulates IP. The aim is for explicit congestion signals = to > > > > > propagate consistently from lower > > layer protocols into IP. Then the > > > > > IP internetwork layer can act as a portability layer to carry > > > > > congestion notification from non-IP-aware congested nodes up = to > the > > > > > transport layer (L4). Following these guidelines should assu= re > > > > > interworking between new lower layer congestion notification > > > > > mechanisms, whether specified by the > > IETF or other standards bodies. > > > > > > > > > > > > > > > [Cross-posting tsvwg & aqm, just in case] > > > > > > > > > > > > > > > Bob Briscoe, > > > > > also for co-authors Pat Thaler and John Kaippallimalil > > > > > > > > > > > > > > > > > > > __________________________________________________________ > > > > > ______ > > > > > Bob Briscoe, BT > > > > > > > > > > > > >_______________________________________________ > > > >aqm mailing list > > > >aqm@ietf.org > > > >https://www.ietf.org/mailman/listinfo/aqm > > > > > > > __________________________________________________________ > > > ______ > > > Bob Briscoe, BT >=20 > __________________________________________________________ > ______ > Bob Briscoe, BT