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

<mohamed.boucadair@orange-ftgroup.com> Wed, 02 December 2009 06:53 UTC

Return-Path: <mohamed.boucadair@orange-ftgroup.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 BB9F33A67B0 for <behave@core3.amsl.com>; Tue, 1 Dec 2009 22:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.913
X-Spam-Level:
X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 AWQvaL9QcgO4 for <behave@core3.amsl.com>; Tue, 1 Dec 2009 22:53:53 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id B015A3A6844 for <behave@ietf.org>; Tue, 1 Dec 2009 22:53:51 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 30AC7C0273; Wed, 2 Dec 2009 07:53:43 +0100 (CET)
Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 1977438406B; Wed, 2 Dec 2009 07:53:43 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.14]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 2 Dec 2009 07:53:42 +0100
From: mohamed.boucadair@orange-ftgroup.com
To: Dan Wing <dwing@cisco.com>, 'Xu Xiaohu' <xuxh@huawei.com>, 'Simon Perreault' <simon.perreault@viagenie.ca>
Date: Wed, 02 Dec 2009 07:53:41 +0100
Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
Thread-Index: AcpyurY2ozKXvywbRSmGU3G+3rofaAANVYogAACgIiAACjWLwA==
Message-ID: <29025_1259736823_4B160EF7_29025_3067_1_94C682931C08B048B7A8645303FDC9F30EF27742B6@PUEXCB1B.nanterre.francetelecom.fr>
References: <4B156B5C.7060800@viagenie.ca> <003401ca72f1$7d0d0310$d40c6f0a@china.huawei.com> <000001ca72f4$1e1a30a0$c3f0200a@cisco.com>
In-Reply-To: <000001ca72f4$1e1a30a0$c3f0200a@cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.12.2.10325
Cc: "behave@ietf.org" <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 06:53:53 -0000

Dear Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Dan Wing
Envoyé : mercredi 2 décembre 2009 03:07
À : 'Xu Xiaohu'; 'Simon Perreault'
Cc : behave@ietf.org
Objet : Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

... 
> > * Cluster = A set of synchronized NAT64 boxes sharing a 
> > single Pref64::/n.
> 
> Does that mean a set of NAT64 boxes within a cluster should 
> be from a single
> vendor? If so, how to deal with the case that some abnormal 
> packets cause
> NAT boxes (using the same OS) within a cluster to crash 
> simultaneously due to a bug with that OS?

The vendor fixes the bug.

The operational complexity of running two NATs, from two different vendors, is
very high:  different CLIs, different alarming/alerting (e.g., SYSLOG, SNMP,
per-session NAT logging), different features (e.g., IPsec Passthru, SCTP),
different implementation of features (e.g., TCP MSS adjustment, fragmentation
[timeouts?  how much memory dedicated to reassembly?  out-of-order packets
supported?]), bandwidth and throughput (Mbps, pps),  make it too hard to
operate both NATs.

Med: Except for the configuration operations, the remaining features should be the same, since both implementations should met the SP's requirement.
Furthermore, having both the primary and that backup nodes from the same vendor induces other unpredictable problems (and therefore long unavailability period). We experienced that kind of problems/behaviour with L2 nodes, it may be the case for NATxy boxes too.

To my knowledge, sites do not run two different implementations of DNS servers
(e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both DNSs back
up each other.  Like NAT, DNS needs to be rock-solid reliable, and a single
packet could take out a DNS server.


-d

_______________________________________________
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.
********************************