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

Reinaldo Penno <rpenno@juniper.net> Wed, 02 December 2009 19:46 UTC

Return-Path: <rpenno@juniper.net>
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 214943A690D for <behave@core3.amsl.com>; Wed, 2 Dec 2009 11:46:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 aANjCHsXhgRX for <behave@core3.amsl.com>; Wed, 2 Dec 2009 11:46:03 -0800 (PST)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 8E7F73A6403 for <behave@ietf.org>; Wed, 2 Dec 2009 11:45:58 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSxbD7DBurZMDUvZX4nZJODDwD5YjiM2b@postini.com; Wed, 02 Dec 2009 11:45:55 PST
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Dec 2009 11:45:38 -0800
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 2 Dec 2009 14:45:37 -0500
From: Reinaldo Penno <rpenno@juniper.net>
To: Dan Wing <dwing@cisco.com>, 'Xu Xiaohu' <xuxh@huawei.com>, 'Simon Perreault' <simon.perreault@viagenie.ca>
Date: Wed, 02 Dec 2009 14:45:33 -0500
Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
Thread-Index: AcpyurY2ozKXvywbRSmGU3G+3rofaAANVYogAACgIiAAJV1tuw==
Message-ID: <C73C03DD.B32D%rpenno@juniper.net>
In-Reply-To: <000001ca72f4$1e1a30a0$c3f0200a@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-Entourage/13.0.0.090609
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 19:46:04 -0000

I agree with Dan in the operational complexity and said so in a different
post pointing issues such as different memory footprints, timers,
configuration, etc.

I think before we jump in and work on standardizing a protocol we should
exercise caution, take a step back and understand the challenges and scope
of the work. 

I suggest the IETF works on a document discussing what kind of information
is synched between two NAT boxes/cards of the same vendor today and
assumptions around platform (Memory, CPU, throughput), configuration, timers
(TCP, UDP, fragmentation, etc), keep-alives, and others that go with that.

Thanks,

Reinaldo

On 12/1/09 6:06 PM, "Dan Wing" <dwing@cisco.com> wrote:

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