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

[Sheng Jiang <[e-mail]>]

Fred,

Thanks for your comments.

Although I can agree on you the disadvantages of anycast, anycast has its
advantages and suitable scenarios, too. Furthermore, I don't think 6rd
depends on anycast. Remi may give us clarification.

However, our draft does no intend to make judge of 6rd, or other tunnel
techonogies. We actually would like to list serveral suitable tunnel
techonogies with brief introductions in order to complete our puzzle. As we
ready state in the draft, "ISATAP or VET are also be considered." Actually,
one thing we can do for next version is to expand this section a little bit,
to include brief introductions for Auto GRE, ISATAP and VET. However, we
also think 6rd is suitable and do not want to rule it out.

Best regards,

Sheng

> -----Original Message-----
> From: Templin, Fred L [mailto:[e-mail]] 
> Sent: Friday, May 15, 2009 7:02 AM
> To: Brian E Carpenter
> 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
> 
> 
> 
> > -----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
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
>