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

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

Hi Sheng,

> -----Original Message-----
> From: Sheng Jiang [mailto:[e-mail]]
> Sent: Thursday, May 14, 2009 7:12 PM
> To: Templin, Fred L; 'Brian E Carpenter'
> Cc: [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,
> 
> 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.

As near as I can tell, the contribution of 6rd is the
definition of a "stateless" prefix delegation mechanism;
everything else is just intra-site tunneling, and 6rd
would do well to look at the ISATAP/VET mechanisms that
already handle this.

Thanks - Fred
[e-mail]

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