Re: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problemv6op6

joel jaeggli <joelja@bogus.com> Tue, 18 February 2014 15:22 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A366E1A0682 for <v6ops@ietfa.amsl.com>; Tue, 18 Feb 2014 07:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 9SmqjIPqziOT for <v6ops@ietfa.amsl.com>; Tue, 18 Feb 2014 07:22:30 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7991A03DC for <v6ops@ietf.org>; Tue, 18 Feb 2014 07:22:30 -0800 (PST)
Received: from [192.168.43.134] ([172.56.39.102]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1IFMKPq059587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 15:22:21 GMT (envelope-from joelja@bogus.com)
Message-ID: <53037AA6.102@bogus.com>
Date: Tue, 18 Feb 2014 07:22:14 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0
MIME-Version: 1.0
To: Ray Hunter <v6ops@globis.net>, "v6ops@ietf.org WG" <v6ops@ietf.org>
References: <5303125C.60303@globis.net>
In-Reply-To: <5303125C.60303@globis.net>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="HfAqrCStKNdVQ58W7CPGPMjVUpS5PK3in"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 18 Feb 2014 15:22:21 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Go1CVy-9oHaZ1D5GmL97qNMiNfk
Cc: joelja@gmail.com
Subject: Re: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problemv6op6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 15:22:34 -0000

On 2/17/14, 11:57 PM, Ray Hunter wrote:
>> From: <fred at cisco.com>
>> To: v6ops at ietf.org
>> Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem at tools.ietf.org
>> Date: Mon, 17 Feb 2014 05:45:16 -0800 (PST)
>> A new draft has been posted, at
>> http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem.
>> Please take a look at it and comment.
> 
> I have read this draft.
> 
> Isn't the obvious brute force mitigation to clamp all of your DC to IPv6
> minimum MTU?

That is an obvious brute force mitigation.

It does however doom ipv6 to the minimum mtu until I decide pmtu is no
longer necessary, which may or may not be never.

There wouldn't be much point if this happened frequently but as it is,
it happens at a rate of a handful of packets per second out of a few
gig's of v6 traffic. That says a lot I think about deployment.

> And isn't it yet another hint that PMTUD really needs to be incorporated
> into the transport layer [if we needed another]?
> 
> e.g. by referencing Packetization Layer Path MTU Discovery (PLPMTUD)
> http://tools.ietf.org/html/rfc4821

Sure I agree that in-band signaling would be way less likely to interact
badly with ecmp forwarding decisions.

> That should also be handled correctly by the load balancers, or not?
>