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

["Templin, Fred L" <[e-mail]>]

Hi Sheng,

> -----Original Message-----
> From: Sheng Jiang [mailto:[e-mail]]
> Sent: Sunday, September 06, 2009 3:52 PM
> To: Templin, Fred L; 'v6ops'; 'Fred Baker'
> Cc: [e-mail]; 'Brian E Carpenter'
> Subject: RE: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt'
> 
> 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?

Thanks for considering the input. On point 5), however,
it should be OK to talk about MTU without using words that
could be construed as normative. For example, the original
text could be reworded slightly as follows:
 
   "However, for IPv6 traffic, a user behind the DS HG will
    see normal IPv6 service. We therefore observe that an
    IPv6 tunnel MTU of at least 1500 bytes would ensure that
    the mechanism does not cause excessive fragmentation of
    IPv6 traffic nor excessive IPv6 path MTU discovery
    interactions."

Fred
[e-mail]

> 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.