RE: New Version Notification for draft-jiang-v6ops-incremental-cgn

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

Dear authors,

The document is clean and concise, which is appreciated.
However, section 3.2 seems to be showing preference
toward a particular tunneling technology, and I'd like
to understand that better.

To understand this, we must first observe that the 6rd
approach relies on anycast for CPE router accessing of
IPv6 routers within the IPv4 ISP network. The idea of
anycast was entertained and abandoned by the ISATAP
team in the 2001/2002 timeframe when ISATAP was still
being developed in the ngtrans working group. This came
after much discussion among authors and guidance from
the working group. Reasons include:

1) if the tunnel fragments, fragments of the same packet
   may go to different anycast-addressed routers.

2) with anycast, there is no opportunity for default
   router selection (when there are multiple)

3) with anycast, there is no opportunity for traffic
   engineering

4) with anycast, IPv6 neighbor discovery over the
   tunnel may yield unpredictable results

5) with anycast, there is need for a manual provisioning
   of IPv6 prefixes and IPv4 anycast address on the CPE
   router.

We next observe that the 6rd mechanism is rooted in a
customized IPv6 prefix configuration that embeds an
IPv4 address. First, this would require that a quite
large IPv6 prefix (e.g., a /24) be delegated to the
ISP were its customers to obtain even a /56 as the
largest possible prefix. Such a prefix would be used
only sparsely, as only a small portion of the IPv4
address space may be available for assignment to CPE
routers. Secondly, the only mode of operation afforded
is Provider-Aggregated, i.e., there is no provision for
CPE use of Provider-Independent prefixes.

I suspect you know where I'm going with this, but take
each of the deficiencies named above and apply VET, and
you will see that VET robustly covers all of these cases
and more. Indeed, with VET as the phase 1 deployment,
there would be no need for a phase 2, and no need for
any IPv6 readdressing as VET uses unmodified IPv6
prefixes natively.

The VET model asks only that CPE routers become VET
enterprise border routers, that CGNs become VET
enterprise border gateways, and that the ISP name
service be provisioned with resource records for
border gateway discovery. In other words, the VET
deployment touches exactly the same CPE/PE equipment
that the 6rd approach touches, and VET asks only that
the ISP network administrators add a few resource
records to the DNS. If there are doubts as to how
VET satisfies each of these use cases, I will be
happy to explain in follow-up.

In your section 3.6, we note a strong recommendation
for a tunnel MTU of at least 1500 bytes and I concur
with this recommendation. Were that not the case,
customer devices would be constantly inconvenienced
with excessive ICMP PTB messages reporting degenerate
MTUs for crossing the ISP network. We also note that
SEAL uniquely and correctly provides the tunnel 1500
MTU assurance that incremental cgn is seeking, and
moreover note that larger MTUs (e.g., 9K) are robustly
and naturally discovered when customer devices request
them. Please see also RANGER Scenarios (RANGERS) for
additional insight into the application of VET and
SEAL into the ISP network problem space:

http://tools.ietf.org/html/draft-russert-rangers
http://tools.ietf.org/html/draft-templin-autoconf-dhcp
http://tools.ietf.org/html/draft-templin-seal

Fred
[e-mail] 
   

> -----Original Message-----
> From: Sheng Jiang [mailto:[e-mail]]
> Sent: Wednesday, May 13, 2009 5:44 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: FW:New Version Notification for
draft-jiang-v6ops-incremental-cgn
> 
> Dear all,
> 
> A revised version of draft-jiang-v6ops-incremental-cgn has been
submitted to
> v6ops WG. It had been represented by Brian Carpenter in v6ops meeting
in
> IETF 74 as draft-jiang-incremental-cgn-00 and received positive
comments
> also modification comments. We have integrated these comments into
this
> version.
> 
> Please review and comments on it. Many thanks.
> 
> Best regards,
> 
> Sheng
> 
> > Filename:	   draft-jiang-v6ops-incremental-cgn
> > Version:	   00
> > Staging URL:
> > http://tools.ietf.org/id/draft-jiang-v6ops-incremental-cgn-00.txt
> >
> > Title:		   An Incremental Carrier-Grade NAT
> > (CGN) for IPv6 Transition
> > Creation_date:	   2009-05-08
> > WG ID:		   Indvidual Submission
> > Number_of_pages: 11
> > Abstract:
> > Global IPv6 deployment was slower than originally expected in
> > the last ten years. As IPv4 address exhaustion gets closer,
> > the IPv4/IPv6 transition issues become more critical and
> > complicated. Host-based transition mechanisms are not able to
> > meet the requirements while most end users are not
> > sufficiently expert to configure or maintain these transition
> > mechanisms. Carrier Grade NAT with integrated transition
> > mechanisms can simplify the operation of end users during the
> > IPv4/IPv6 migration or coexistence period. This document
> > proposes an incremental Carrier-Grade NAT (CGN) solution for
> > IPv6 transition.
> > It can provide IPv6 access services for IPv6-enabled end hosts and
> > IPv4 access services for IPv4 end hosts while remaining most
> > of legacy IPv4 ISP networks unchanged. It is suitable for the
> > initial stage of IPv4/IPv6 migration. Unlike CGN alone, it
> > also supports and encourages transition towards dual-stack or
> > IPv6-only ISP networks.
> >
> > Submitter: Sheng Jiang ([e-mail])
> >
> > Author(s):
> > Sheng Jiang, [e-mail]
> > Dayong Guo, [e-mail]
> > Brian Carpenter, [e-mail]
> >
> >
> > Comment:
> > Replacement for draft-jiang-incremental-cgn-00
> >
> >
> 
>