Re: [nat66] Comments on draft-mrw-nat66-12

Fred Baker <fred@cisco.com> Wed, 16 March 2011 00:28 UTC

Return-Path: <fred@cisco.com>
X-Original-To: nat66@core3.amsl.com
Delivered-To: nat66@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE31D3A6B8B for <nat66@core3.amsl.com>; Tue, 15 Mar 2011 17:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.416
X-Spam-Level:
X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 Ll5Zu-NiLy+C for <nat66@core3.amsl.com>; Tue, 15 Mar 2011 17:28:25 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8D8E43A6A55 for <nat66@ietf.org>; Tue, 15 Mar 2011 17:28:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1543; q=dns/txt; s=iport; t=1300235391; x=1301444991; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=wRufOPJy04titRYkp0NLzrMdVQxH6eJzhJ/Vv8ovbUE=; b=mFW0gPlXbqFtdbV6xTbaNp/sr3mZXCO9xzZvHN4x7R5iLn7vU6e0wEMg irsFBgIxFfR7etDGRUmgkJe8gePA9TvdkqSUghJEfuND3HDgExJKNs/t/ lyVjhA1hSM5hDskK5ZcG4y5LPsGPCFhPtGRRMhHMqdW6MOLUmbPq+rQGf 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEACqhf02tJV2d/2dsb2JhbACmDnekapxmhWIEhTCHLYNP
X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="225984094"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2011 00:29:50 +0000
Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2G0TjJa020181; Wed, 16 Mar 2011 00:29:50 GMT
Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 15 Mar 2011 17:29:50 -0700
X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 15 Mar 2011 17:29:50 -0700
Mime-Version: 1.0 (Apple Message framework v1082)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <4D7FFEA7.9040304@gmail.com>
Date: Tue, 15 Mar 2011 17:29:33 -0700
Message-Id: <B9EFE60B-AEFF-497E-9D45-89D6F196D6D3@cisco.com>
References: <20110314063002.28048.29694.idtracker@localhost> <19F3A4CD-F39C-4F17-A6E9-7AA8AFBC6B3B@cisco.com> <CF8367A6-F303-43D7-99C6-D40D1DD5D5D9@free.fr> <125BC580-ED43-40EE-B6B9-FD88557C35B9@apple.com> <758DD037-9DC2-4A1E-BEAE-7E99CBED6D3A@cisco.com> <4D7FFEA7.9040304@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1082)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: NAT66 HappyFunBall <nat66@ietf.org>
Subject: Re: [nat66] Comments on draft-mrw-nat66-12
X-BeenThere: nat66@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "List for discussion of IPv6-to-IPv6 NAT." <nat66.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nat66>
List-Post: <mailto:nat66@ietf.org>
List-Help: <mailto:nat66-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Mar 2011 00:28:28 -0000

On Mar 15, 2011, at 5:04 PM, Brian E Carpenter wrote:

> On 2011-03-16 11:51, Fred Baker wrote:
> ...
>> people don't spend a lot of cycles thinking about NAPT44 route flap effects. 
> 
> The interesting thing is that people don't spend cycles thinking about
> any of the NAT-induced glitches which cause end users to lose sessions;
> some of these will apply to NPTv6 of course. I wonder if it's possible
> to quantify this (rough % of sessions lost by NAPT44 glitches, and
> how many of these would *not* occur with NPTv6)?

I don't think so, at least not in any general sense, because it's a matter of routing, traffic loads, probability of failure, and so on - it's is all about specific cases. 

If a network has two upstreams and one DMZ to each, it will apply to every TCP session open at the time of the failure. If it has two DMZs to each, does re-routing take it to the other DMZ to the same ISP (0% loss) or a DMZ to a different ISP (100% loss), or some middle ground?

If failures happen every 100 days, and the network typically opens and closes 3100 TCP sessions/second (assumes that every session consumes 50 KBPS on a 155 MBPS link and that is exactly what's happening), 3100/(100*24*3600*3100) is 0.00003733572282%, or so says /Applications/Calculator.app. If you don't like my numbers, insert your own. For the record, we had a power failure this morning at the house and every TCP session I had outstanding did a belly flop. I think that was exactly zero.