IETF Logo Mail Archive

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

Cameron Byrne <cb.list6@gmail.com> Tue, 01 December 2009 22:05 UTC

Return-Path: <cb.list6@gmail.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 974AB3A679C for <behave@core3.amsl.com>; Tue, 1 Dec 2009 14:05:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level:
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 3JoP5+hrD+4m for <behave@core3.amsl.com>; Tue, 1 Dec 2009 14:05:37 -0800 (PST)
Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 9A24F3A692E for <behave@ietf.org>; Tue, 1 Dec 2009 14:05:37 -0800 (PST)
Received: by yxe30 with SMTP id 30so10584647yxe.29 for <behave@ietf.org>; Tue, 01 Dec 2009 14:05:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c38K3l0OPNEu/6WXzvHGvOoXeo+RT2nFtBTcPR4vjfY=; b=ZjlTtXUs0F5r/0aS4jrEIgCyR9R2PQvV0aHwMHRtZ+FVTgIhHvM93wTIp5zdsTANhq 3jBAMsPs7BmBsczdJ+GnsQUhCgHck6D3U4DSaMavWYny7LG4cXMS4zOBAs9Y/Dmz8w0u ez9yI9OjShfgrGy/jUfM/c+AZz/VjxkqO9g68=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SttxOgybxe19aKha2L18envtjRyOdtD3EAw1Kp72GxE5rA9ujIC9Of/7o33ZzW71Ql jurY2aaR2f5vlhzlwd1jGCqDkFf2pcOFz+8wLfiCiO+/96VexHoR+sAw8ZvGjtTopInb Gz1qLIqjb0NA1UQcIVLf/vxau0A2K0ptOWWwg=
MIME-Version: 1.0
Received: by 10.150.250.21 with SMTP id x21mr9788482ybh.181.1259705123564; Tue, 01 Dec 2009 14:05:23 -0800 (PST)
In-Reply-To: <4B15776F.4080901@viagenie.ca>
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>
Date: Tue, 01 Dec 2009 14:05:23 -0800
Message-ID: <bcff0fba0912011405x56975fe7t442f60ab8f9a1284@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: behave@ietf.org
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 22:05:38 -0000

On Tue, Dec 1, 2009 at 12:07 PM, Simon Perreault
<simon.perreault@viagenie.ca> wrote:
> Andrew Sullivan wrote, on 2009-12-01 14:40:
>> On Tue, Dec 01, 2009 at 07:26:29PM +0000, Dave Thaler wrote:
>>> So yes NAT64 should try (to the extent that is practical)
>>> to accommodate apps that don't pay attention to TTL, since that's
>>> 99.99% of all applications.
>>
>> Either that, or we should get to work on changing the APIs.  Since I
>> predict heat death of the universe first, I agree with Dave.
>
> No, let's change the APIs to make NAT64 work!
>
> Just kidding... we all agree on that. But what was the point again?
>
> 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.
>
> Failing over to another Pref64::/n is an unlikely event. It means that something
> *really bad* happened. (See my other email about the two types of breakage.) Any
> 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.

100% agree.  Members in a cluster failing can locally be resolved
without bouncing the Pref64.  If entire cluster fails, this is very
unlikely but catastrophic, i just want a fail safe that can work
*mostly*, and if the networks really broke, asking a user to reboot
their phone and be fixed in 1 minute is better than waiting for a 4
hour RMA or  guy with backhoe to fix fiber or electrician to arrve
,...


>
> Simon
> --
> DNS64 open-source   --> http://ecdysis.viagenie.ca
> STUN/TURN server    --> http://numb.viagenie.ca
> vCard 4.0           --> http://www.vcarddav.org
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>

v2.23.0 | Report a Bug | By Email