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

[Sheng Jiang <[e-mail]>]

Hi, Templin,

Thanks so much for your comments. Can I ask you a question here: overall, do
you think this draft is suitable for v6ops charter and mature enough to be
adopted as wg file?

Most of your comments are accepted and will be reflected in the next version
except for point 5. Actually, I am with you and these texts were in the
earlier version. However, Fred thought any normative material were not
suitable for 6vops wg and should be removed. Apparently, a recommendation
for MTU is normative rather than operational. So, unless Fred confirms
that's fine I cannot put the MTU text back. Fred?

Many thanks and best regards,

Sheng

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Templin, Fred L
> Sent: Thursday, September 03, 2009 5:21 AM
> To: v6ops
> Cc: JiangSheng 66104; [e-mail]; Brian E Carpenter
> Subject: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt'
> 
> Below is my review of 'draft-jiang-v6ops-incremental-cgn-02.txt':
> 
> Fred
> [e-mail]
> 
> ---
> 
> 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.