IETF Logo Mail Archive

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

Xu Xiaohu <xuxh@huawei.com> Wed, 02 December 2009 04:39 UTC

Return-Path: <xuxh@huawei.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 E42023A67C2 for <behave@core3.amsl.com>; Tue, 1 Dec 2009 20:39:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.49
X-Spam-Level:
X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45]
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 K6qGkepZVnji for <behave@core3.amsl.com>; Tue, 1 Dec 2009 20:39:24 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1EEA63A67AE for <behave@ietf.org>; Tue, 1 Dec 2009 20:39:24 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU0001KFCXEFN@szxga03-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 12:39:15 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU000AZMCXEA2@szxga03-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 12:39:14 +0800 (CST)
Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU000BW4CXERJ@szxml04-in.huawei.com> for behave@ietf.org; Wed, 02 Dec 2009 12:39:14 +0800 (CST)
Date: Wed, 02 Dec 2009 12:39:14 +0800
From: Xu Xiaohu <xuxh@huawei.com>
In-reply-to: <000801ca72f8$c3fa5820$c3f0200a@cisco.com>
To: 'Dan Wing' <dwing@cisco.com>, 'Cameron Byrne' <cb.list6@gmail.com>, 'Simon Perreault' <simon.perreault@viagenie.ca>
Message-id: <004101ca7309$668d5a00$d40c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable
Thread-index: Acpy0mn3S8LOZsW/SWW5oxGfCX6NjAAH5KCwAAGDm/AABCGFcA==
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: Wed, 02 Dec 2009 04:39:25 -0000

> -----邮件原件-----
> 发件人: Dan Wing [mailto:dwing@cisco.com]
> 发送时间: 2009年12月2日 10:40
> 收件人: 'Xu Xiaohu'; 'Cameron Byrne'; 'Simon Perreault'
> 抄送: behave@ietf.org
> 主题: RE: [BEHAVE] proprietary implementation v.s
standardisedprotocols//re:
> draft-xu-behave-nat-state-sync-00
> 
> ...
> > > 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
> >
> > Ask a user or ask a huge amount of users?
> 
> All the affected users.
> 
> > By the way, if one uses one of those mechanisms defined in
> > draft-wing-behave-learn-prefix, other than DNS64, to
> > synthesize IPv6 addresses, does that mean the DNS server or
> > the DHCP server should also dynamically detect the
> > availability of each prefix64?
> 
> Whatever hands out the prefix (DNS, IPv6 router advertisements,
> DHCPv6) should hand out a functioning prefix.  Providing a
> non-functioning prefix is harmful.

Agree. In fact, with the IPv6 RA approach, the gateway router could
dynamically learn the available prefix64 through IGP extension (e.g., Router
Information LSA in OSPF).

Xiaohu

> The same is true of a DHCP server providing the IP address of
> DNS servers, NTP servers, and suchlike.  If a DHCP server hands
> out IP addresses for broken (or dead) servers, it is harmful.
> 
> Does that need to be stated, though?
> 
> -d

v2.8.7 | Report a Bug | By Email