[v6ops] Comments on draft-ietf-v6ops-nat64-experience-00

Philip Matthews <philip_matthews@magma.ca> Thu, 01 November 2012 14:06 UTC

Return-Path: <philip_matthews@magma.ca>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCCB21F8CBD for <v6ops@ietfa.amsl.com>; Thu, 1 Nov 2012 07:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+7zzyNqNQKL for <v6ops@ietfa.amsl.com>; Thu, 1 Nov 2012 07:06:12 -0700 (PDT)
Received: from mail-08.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id AEFC221F8CB5 for <v6ops@ietf.org>; Thu, 1 Nov 2012 07:06:12 -0700 (PDT)
Received: from [74.198.165.39] (helo=[172.20.10.2]) by mail-08.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <philip_matthews@magma.ca>) id 1TTvPN-0002l9-36; Thu, 01 Nov 2012 10:06:12 -0400
From: Philip Matthews <philip_matthews@magma.ca>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 01 Nov 2012 10:06:04 -0400
Message-Id: <86E4957C-33CA-493A-991E-9A937FC28BE0@magma.ca>
To: draft-ietf-v6ops-nat64-experience@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.39]
Cc: "v6ops@ietf.org list" <v6ops@ietf.org>
Subject: [v6ops] Comments on draft-ietf-v6ops-nat64-experience-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Nov 2012 14:06:13 -0000

Hi authors:

I read your draft with interest.   I need to re-read it more carefully, but here are some preliminary comments:

1) The title of the draft is "NAT64 Operational Experiences", but I feel the draft reads much more like "NAT64 Deployment Considerations".   I didn't see any place where the draft says "This is what we did and it worked well (or it didn't work well)". That is, it is not really relating the specific experience of an operator in deploying NAT64 so much as describing things that an operator should take into account when planning their own NAT64 deployment. 

2) Section 3.1 has the sentence:
   It is advantageous from the vantage-point of
   troubleshooting and traffic engineering to carry the IPv6 traffic
   natively for as long as possible within an access network and
   translates only at or near the network egress.
I think it would be interesting and helpful to say more about why you feel this is true.  Can you give some specific examples? Though today I suspect most operators will try to centralize their NAT64 boxes for cost reasons, I can see in the future an operator that is forced to go pure IPv6 and is planning a large rollout, and will be worried that centralizing NAT64 will not scale well and will thus consider pushing NAT64 to closer to the customer.

3) Section 3.2 on HA Considerations has the sentence:
    Given that short
   lived sessions account for most of the bindings, hot-standby does not
   offer much benefit for those sessions.
Just curious if you have evidence or a reference that backs up this claim? This is certainly frequently stated for NAT44, but I haven't seen hard facts in the case of NAT64. I am especially wondering if the fact that some traffic (like DNS traffic and native IPV6 traffic) doesn't go through the NAT64 would change the situation from the NAT44 case.

4) The draft is currently organized so that section 3 discusses the NAT64-CGN case, and section 4 discusses the same topics in the NAT64-CPE case.  I suggest you consider organizing the draft differently, so that you have a series of sections discussing a topic (e.g Load Balancing or MTU), and within the section you first discuss the NAT64-CGN case and then the NAT64-CPE case. I suggest that this would allow you to discuss each topic more fully, and would emphasis the similarities or differences between the CGN and CPE cases.  Just a suggestion.

- Philip