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

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

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Thursday, May 14, 2009 3:50 PM
> To: Templin, Fred L
> Cc: Sheng Jiang; [e-mail]; [e-mail]; Fleischman, Eric; Russert, Steven W; Rémi
> Després
> Subject: Re: New Version Notification for draft-jiang-v6ops-incremental-cgn
> 
> Fred,
> 
> (My previous message was somewhat inscrutable. See in-line.)
> 
> On 2009-05-15 03:17, Templin, Fred L wrote:
> > 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
> 
> When I look at the 6rd draft, I don't really see why the relay needs
> to be anycast - as far as I can see it could be genuinely unicast
> (since there is no semantic difference for the CPE or the relay;
> it's only anycast if the ISP sets up its IGP to make it anycast).
> So the real question is how the CPE knows the 6rd relay address,
> which is also a question for RFC3056. There are of course many
> possible answers to that, e.g. a DHCP(v4) option.

ISATAP and VET already have answers for that ([RFC5214],
Sections 8.3.2 and 9). If 6rd wants to do the same thing,
it would just be re-inventing the wheel.
 
> Personally I think a provisioned unicast address may be better,
> because of your points 1-4.

Provisioned unicast addresses are already the subject
matter for ISATAP/VET Potential Router List (PRL)
initialization. Is a new spec needed?

> > 5) with anycast, there is need for a manual provisioning
> >    of IPv6 prefixes and IPv4 anycast address on the CPE
> >    router.
> 
> Which IPv6 prefixes? The CPE builds its IPv6 prefix from its
> external IPv4 address, which it gets in the traditional way.

The CPE needs to learn the provider's IPv6 prefix reserved
for 6rd purposes. Unless there is some form of automated
discovery (e.g., PIOs in RAs), the IPv6 prefix would need
to be manually provisioned.

> > 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.
> 
> Yes. Are we running out of /24s yet?

Are we running out of /24s? I really don't know. Do
I know waste when I see it? I think so.
 
> > Secondly, the only mode of operation afforded
> > is Provider-Aggregated, i.e., there is no provision for
> > CPE use of Provider-Independent prefixes.
> 
> Yes. I would expect this method to be used for SOHO subscribers,
> not for larger customers who might use PI.

But, do you know what the service model will look
like 5-10yrs down the line? (Maybe coexisting wireless
broadband and cable modem?) Do you even know what
a SOHO network will look like 5-10yrs down the line?
PI is as some point going to become attractive to
enterprises of any size - not necessarily just the
big ones. 

> > 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.
> 
> I don't see this for SOHO subscribers using $50 CPEs,
> frankly, but I could be wrong.

Let's just have an awareness about this up front. Then,
we will have to explain to the customers years down the
line why we copped out and gave them a moped when they
could have had a 'VET.

Fred
[e-mail]

> 
> Thanks
> 
>      Brian
> 
> >
> > 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
> >>>
> >>>
> >>
> >
> >
> >