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

Xu Xiaohu <xuxh@huawei.com> Wed, 25 November 2009 10:05 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 C064C3A694F for <behave@core3.amsl.com>; Wed, 25 Nov 2009 02:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.686
X-Spam-Level:
X-Spam-Status: No, score=0.686 tagged_above=-999 required=5 tests=[AWL=3.285, 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 2RMhZilRF5y7 for <behave@core3.amsl.com>; Wed, 25 Nov 2009 02:05:25 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A65A33A68E2 for <behave@ietf.org>; Wed, 25 Nov 2009 02:05:25 -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 <0KTN00077TCIOF@szxga03-in.huawei.com> for behave@ietf.org; Wed, 25 Nov 2009 18:05:07 +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 <0KTN004WDTCHYU@szxga03-in.huawei.com> for behave@ietf.org; Wed, 25 Nov 2009 18:05:05 +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 <0KTN006POTCHTF@szxml04-in.huawei.com> for behave@ietf.org; Wed, 25 Nov 2009 18:05:05 +0800 (CST)
Date: Wed, 25 Nov 2009 18:05:05 +0800
From: Xu Xiaohu <xuxh@huawei.com>
In-reply-to: <21422_1258094445_4AFCFF6D_21422_40641_1_94C682931C08B048B7A8645303FDC9F307914E625D@PUEXCB1B.nanterre.francetelecom.fr>
To: mohamed.boucadair@orange-ftgroup.com, 'Brian E Carpenter' <brian.e.carpenter@gmail.com>, behave@ietf.org
Message-id: <003401ca6db6$c2f6cc70$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="utf-8"
Content-transfer-encoding: quoted-printable
Thread-index: AcpkBGV5WQWd75kNQhedwrf/iaLaiwAJkStAAmKLNPA=
Subject: [BEHAVE] proprietary implementation v.s standardised protocols //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, 25 Nov 2009 10:05:26 -0000

> -----邮件原件-----
> 发件人: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] 代表
> mohamed.boucadair@orange-ftgroup.com
> 发送时间: 2009年11月13日 14:41
> 收件人: Brian E Carpenter; behave@ietf.org
> 主题: Re: [BEHAVE] draft-xu-behave-nat-state-sync-00
> 
> 
> Dear all,
> 
> I guess that the question should be asked priori to yours:
> 
> Do we let vendors define their proprietary solutions or does the IETF define
> a solution based on standardised protocols to achieve reliable state
> synchronisation?

For a small enterprise network, maybe it's acceptable to deploy two or more NAT boxes purchased from the same vendor for redundancy. However, for a large ISP network or large enterprise network, it is not reliable enough. For example, an abnormal packet will cause the router OS to crash, it is not absolutely acceptable. Hence I believe the standardization of NAT redundancy is necessary.

Xiaohu


> From a service provider perspective, I'd like to see a solution with IETF stamp
> so as to be included in our RFPs/analysis. Vendors are then free to propose
> more reliable solutions, if any, compared to the one standardised by IETF.
> 
> Cheers,
> Med
> 
> 
> -----Message d'origine-----
> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de
> Brian E Carpenter
> Envoyé : vendredi 13 novembre 2009 02:55
> À : behave@ietf.org
> Objet : [BEHAVE] draft-xu-behave-nat-state-sync-00
> 
> My question about this draft is whether there is available code and
> implementation experience with SCSP, which was defined in 1998.
> 
> If there isn't code and experience, since it is a quite complex design, I would
> be a bit worried.
> 
> On the other hand, I believe that something of the complexity of SCSP is
> absolutely required to provide reliable synchronisation.
> There is no simple, lightweight way to do this reliably.
> 
>     Brian
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
> 
> *********************************
> This message and any attachments (the "message") are confidential and intended
> solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed
> or falsified.
> If you are not the intended addressee of this message, please cancel it
> immediately and inform the sender.
> ********************************
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave