IETF Logo Mail Archive

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

Reinaldo Penno <rpenno@juniper.net> Thu, 03 December 2009 03:15 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 4C08A3A69B0 for <behave@core3.amsl.com>; Wed, 2 Dec 2009 19:15:21 -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=[AWL=0.000, 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 CdXO2lYoSrnx for <behave@core3.amsl.com>; Wed, 2 Dec 2009 19:15:20 -0800 (PST)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 8A0BB3A6885 for <behave@ietf.org>; Wed, 2 Dec 2009 19:15:18 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSxctNyWc88vlo1/tYIRXaKLP30ICVelk@postini.com; Wed, 02 Dec 2009 19:15:12 PST
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Dec 2009 19:14:55 -0800
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 2 Dec 2009 22:14:54 -0500
From: Reinaldo Penno <rpenno@juniper.net>
To: Simon Perreault <simon.perreault@viagenie.ca>
Date: Wed, 02 Dec 2009 22:14:51 -0500
Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
Thread-Index: AcpzpeTEDReKJVoRTGaNq5SDHKAgFAAIOIRe
Message-ID: <C73C6D2B.B448%rpenno@juniper.net>
In-Reply-To: <4B16F5FB.8000607@viagenie.ca>
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>, 'Xu Xiaohu' <xuxh@huawei.com>, Dan Wing <dwing@cisco.com>
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: Thu, 03 Dec 2009 03:15:21 -0000

On 12/2/09 3:19 PM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:

> On 12/02/2009 02:45 PM, Reinaldo Penno wrote:
>> 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.
> 
> How is this relevant to NAT64?

Maybe we are not talking about the same thing so let's work through an
throughput example and if we decide we are talking about the same thing we
can discuss the other issues I pointed out in the light of NAT64.

Let's assume you have NAT-A and NAT-B from different vendors. NAT-A is
processing packets for 3 NAT sessions and as master have synched these 3 NAT
sessions to NAT-B.

If NAT-A fails and NAT-B takes over, how can you guarantee that NAT-B will
be able to handle these sessions in terms of packets per second?

Thanks,

Reinaldo

> 
> What we need to consider is NAT64 state and not care about NAT44.
> Otherwise it will be a tar pit.
> 
> And I don't think we need any other separate document. This is a well
> understood problem.
> 
> Simon

v2.23.0 | Report a Bug | By Email