Re: routing area design team on dataplane encapsulation considerations

<l.wood@surrey.ac.uk> Wed, 10 December 2014 10:01 UTC

Return-Path: <l.wood@surrey.ac.uk>
X-Original-To: routing-discussion@ietfa.amsl.com
Delivered-To: routing-discussion@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345901A1B80 for <routing-discussion@ietfa.amsl.com>; Wed, 10 Dec 2014 02:01: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 LmKBx6uysMNd for <routing-discussion@ietfa.amsl.com>; Wed, 10 Dec 2014 02:01:41 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.143]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB171A3BA7 for <routing-discussion@ietf.org>; Wed, 10 Dec 2014 02:01:38 -0800 (PST)
Received: from [195.245.231.67] by server-7.bemta-5.messagelabs.com id CE/D4-31453-10A18845; Wed, 10 Dec 2014 10:01:37 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-4.tower-82.messagelabs.com!1418205691!34049558!3
X-Originating-IP: [131.227.200.39]
X-StarScan-Received:
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4461 invoked from network); 10 Dec 2014 10:01:36 -0000
Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-4.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 10 Dec 2014 10:01:36 -0000
Received: from EXHY021V.surrey.ac.uk (131.227.200.104) by EXHT012P.surrey.ac.uk (131.227.200.39) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 10 Dec 2014 10:01:33 +0000
Received: from emea01-db3-obe.outbound.protection.outlook.com (131.227.200.4) by EXHY021v.surrey.ac.uk (131.227.200.104) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 10 Dec 2014 10:01:33 +0000
Received: from DB4PR06MB457.eurprd06.prod.outlook.com (10.141.238.15) by DB4PR06MB458.eurprd06.prod.outlook.com (10.141.238.19) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 10:01:32 +0000
Received: from DB4PR06MB457.eurprd06.prod.outlook.com ([10.141.238.15]) by DB4PR06MB457.eurprd06.prod.outlook.com ([10.141.238.15]) with mapi id 15.01.0031.000; Wed, 10 Dec 2014 10:01:32 +0000
From: l.wood@surrey.ac.uk
To: akatlas@gmail.com, routing-discussion@ietf.org, stbryant@cisco.com
Subject: Re: routing area design team on dataplane encapsulation considerations
Thread-Topic: routing area design team on dataplane encapsulation considerations
Thread-Index: AQHQFAI+mxeM7C5mI06ufRYYSYZE2pyH3cwAgABL+58=
Date: Wed, 10 Dec 2014 10:01:32 +0000
Message-ID: <DB4PR06MB457D1FCFF0FBBA25E7A4EC3AD620@DB4PR06MB457.eurprd06.prod.outlook.com>
References: <CAG4d1rd60hK8=WtYw-nid_Z7Z8+TvdzA52fNx3pFjND+eDWAfA@mail.gmail.com>, <54877D58.9050002@cisco.com>
In-Reply-To: <54877D58.9050002@cisco.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [124.168.9.252]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB458;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB458;
x-forefront-prvs: 0421BF7135
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(479174003)(24454002)(199003)(40100003)(64706001)(20776003)(2656002)(105586002)(76176999)(77096005)(66066001)(107046002)(21056001)(107886001)(15975445007)(99396003)(102836002)(1720100001)(120916001)(86362001)(122556002)(87936001)(68736005)(106356001)(54606007)(106116001)(76576001)(50986999)(15395725005)(54356999)(4396001)(62966003)(77156002)(46102003)(74482002)(15198665003)(19580405001)(19580395003)(33656002)(92566001)(101416001)(74316001)(31966008)(54206007)(97736003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB458; H:DB4PR06MB457.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: DB4PR06MB458.eurprd06.prod.outlook.com
X-OriginatorOrg: surrey.ac.uk
X-CrossPremisesHeadersPromoted: EXHY021v.surrey.ac.uk
X-CrossPremisesHeadersFiltered: EXHY021v.surrey.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/d4SVF4GkI0HfogfeRR2QXTOocCE
X-BeenThere: routing-discussion@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area General mailing list <routing-discussion.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/routing-discussion/>
List-Post: <mailto:routing-discussion@ietf.org>
List-Help: <mailto:routing-discussion-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 10:01:43 -0000

Of course the tunnellers are happy with a zero checksum. The pollution caused by missent corrupted ipv6 packets evading checks elsewhere does not affect them.

Congestion is not a problem for tunnellers either. Like zero checksums, any congestion problem caused by a tunnel is just not the tunnel's problem. Why should the tunneller have to consider congestion? Or zero checksums? Or anything that impedes tunnel performance?

The tragedy of the commons, in action.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: routing-discussion <routing-discussion-bounces@ietf.org> on behalf of Stewart Bryant <stbryant@cisco.com>
Sent: Wednesday, 10 December 2014 9:53:12 AM
To: Alia Atlas; routing-discussion@ietf.org
Subject: Re: routing area design team on dataplane encapsulation considerations

Alia

On 09/12/2014 22:46, Alia Atlas wrote:
> * IPv6 header protection (non-zero UDP checksum over IPv6 issue)
I am not sure if it is the non-zero UDP checksum over IPv6 issue, or
the zeroUDP checksum over IPv6 issue.

Most people doing tunneling seem quite happy with zero but get pushback
from the transport area.

Perhaps the topic is really

* IPv6 header protection (UDP checksum issue)

- Stewart


_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion