Review of 'draft-jiang-v6ops-incremental-cgn-02.txt'

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 02 September 2009 21:30 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21E228C76A for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 2 Sep 2009 14:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.864
X-Spam-Level:
X-Spam-Status: No, score=-4.864 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 2cibtMNLoUyv for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 2 Sep 2009 14:30:43 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FC813A69DA for <v6ops-archive@lists.ietf.org>; Wed, 2 Sep 2009 14:27:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1MixGZ-000EGe-8J for v6ops-data0@psg.com; Wed, 02 Sep 2009 21:21:19 +0000
Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Fred.L.Templin@boeing.com>) id 1MixGV-000ECj-4O for v6ops@ops.ietf.org; Wed, 02 Sep 2009 21:21:17 +0000
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n82LKYcP003312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Sep 2009 16:20:35 -0500 (CDT)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n82LKYGS005918; Wed, 2 Sep 2009 14:20:34 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n82LKYST005915; Wed, 2 Sep 2009 14:20:34 -0700 (PDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 14:20:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt'
Date: Wed, 02 Sep 2009 14:20:32 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106599A1A@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt'
Thread-Index: Acoqcu8VCR/v6St/SJyVNzJoxoAu2QAsGJeAADaneSA=
References: <31484.26522.qm@web45503.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com><373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com>
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: v6ops <v6ops@ops.ietf.org>
Cc: JiangSheng 66104 <shengjiang@huawei.com>, guoseu@huawei.com, Brian E Carpenter <brian.e.carpenter@gmail.com>
X-OriginalArrivalTime: 02 Sep 2009 21:20:34.0025 (UTC) FILETIME=[35180D90:01CA2C13]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Below is my review of 'draft-jiang-v6ops-incremental-cgn-02.txt':

Fred
fred.l.templin@boeing.com

---

1) Section 1, second paragraph, the sentence beginning
"They are too complicated..." is meaningless unless it
were to name specific transition mechanisms within specific
deployment scenarios. For example, perceived complications
may only be relevant when necessary network-supporting
infrasturcture is missing. Suggestion is to rewrite the
paragraph as follows:

   "IPv4/IPv6 transition issues therefore become more critical
    and complicated for the soon-coming global IPv6 deployment.
    Host-based transition mechanisms alone may not be able to
    meet the requirements in all cases. Therefore, network
    supporting functions and/or new transition mechanisms
    with simple user-side operation are needed."

2) Section 1, paragraph 4, the final two sentences seem to
imply that DSLite requires the ISP to upgrade its network
to IPv6, but that is incorrect. DSLite can operate as
IPv4-in-IPv6-in-IPv4 encapsulation, such that it can
operate over IPv4-only networks as long as the CPE and
CGN are dual-stacked. These two sentences need to be
corrected to reflect this.

3 Section 2.1, the sentence: "The integration of NAT-PT
is out of scope for this document." should be changed
to: "The integration of such mechanisms is out of scope
for this document."

4) Section 2.2, sentence beginning "Other tunneling
mechanisms..." should read:

  "Other tunneling mechanisms such as 6over4 [RFC2529], the
   Intra-Site Automatic Tunnel Addressing Protocol [RFC5214]
   and Virtual Enterprise Traversal (VET) [VET] are also
   considered."

5) Section 2.6, bring back text removed from the -01 in a
slightly modified form as follows:

  "However, for IPv6 traffic, a user behind the DS HG will
   see normal IPv6 service. It is therefore recommended that
   all IPv6 tunnels support an MTU of at least 1500 bytes,
   to ensure that the mechanism does not cause excessive
   fragmentation of IPv6 traffic nor excessive IPv6 path
   MTU discovery interactions."

6) Section 3, first part of first sentence, change to:
"If the core network transitions to IPv6,".

7) Section 3, paragraph 3 - same comment as 2) above. DSLite
does not require an IPv6-only ISP network, and can run as
IPv4-in-IPv6-in-IPv4 in an IPv4-only ISP network in which the
CPE and CGN are both dual-stacked. The advantages of using
DSLite over v4-v4 NATing are that the CPE can use traffic
engineering and ingress filtering by selecting specific CGNs
through which to direct their traffic. This requires only
that the CPE be able to discover the addresses of CGNs in
the operator network. That process can be coupled with the
ISATAP/VET Potential Router List (PRL) discovery mechanisms,
in which case the CGN would be co-resident with an ISATAP/VET
router that terminates IPv6-in-IPv4 intra-site tunnels.

8) Section 3.1, end of final sentence of first paragraph
says: "so we refer to it non-specifically" but then names
a specific service. To keep the sense of the sentence,
it would have to be changed to: "so we refer to it
non-specifically as "NAT64"." (i.e., and remove the
specific citation). I am open to other suggestions.