Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

Andrew Sullivan <ajs@shinkuro.com> Tue, 01 December 2009 20:43 UTC

Return-Path: <ajs@shinkuro.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DEAD3A69AE for <behave@core3.amsl.com>; Tue, 1 Dec 2009 12:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level:
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKwLujX0C1in for <behave@core3.amsl.com>; Tue, 1 Dec 2009 12:43:44 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 50E593A6849 for <behave@ietf.org>; Tue, 1 Dec 2009 12:43:44 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 294812FE8CDD for <behave@ietf.org>; Tue, 1 Dec 2009 20:43:36 +0000 (UTC)
Date: Tue, 01 Dec 2009 15:43:34 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: behave@ietf.org
Message-ID: <20091201204334.GZ71984@shinkuro.com>
References: <bcff0fba0911302332ub498269qabbdca8341b018d5@mail.gmail.com> <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> <097401ca72aa$0828aa50$c3f0200a@cisco.com> <4B1559E6.4060003@viagenie.ca> <E4561B14EE2A3E4E9D478EBFB5416E1B29B5A944@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20091201194017.GU71984@shinkuro.com> <4B15776F.4080901@viagenie.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4B15776F.4080901@viagenie.ca>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2009 20:43:45 -0000

On Tue, Dec 01, 2009 at 03:07:11PM -0500, Simon Perreault wrote:

> The point was that you cannot fail over clients from one Pref64::/n to another
> because applications will remember addresses. This is true, to some extent. If
> it was 100% true then you wouldn't be able to change anything once you publish a
> DNS record. In reality, hosts are rebooted, applications are restarted, and web
> pages are reloaded. So you have some wiggle room.

"Reloading a web page" often doesn't help.  I have experience of at
least one popular browser that reaches down and remembers the A record
for the target host.  Then the magic DNS load balancer decides to pull
that IP out of the mix, and stuff starts breaking randomly.  (One of
the many ways in which DNS load balancers don't work the way their
deployers seem to think they do.)   That said,

> partial fix is better than just shutting of the Internet to your
> customers. If it means they have to close Outlook and restart it, so
> be it.

I completely agree here.

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.