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

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

Mark,

> -----Original Message-----
> From: Mark Townsley [mailto:[e-mail]]
> Sent: Wednesday, May 20, 2009 6:17 AM
> To: Templin, Fred L
> Cc: Rémi Després; Sheng Jiang; [e-mail]; [e-mail]; [e-mail];
> Fleischman, Eric; Russert, Steven W
> Subject: Re: New Version Notification for draft-jiang-v6ops-incremental-cgn
> 
> 
> Indeed, 6rd is targeted to ISPs who have the ability to specify the
> residential gateway's functionality. This certainly does not apply to
> all ISP offerings, but it does apply to quite a few.
> 
> As Remi points out, he and I (and others) have been working together
> recently on a new 6rd spec which includes some of the things discussed
> here (DHCP options, etc). Current plan is to have that out in the next
> week or so.

I must apologize to you and to the list for inappropriate
non-technical content directed toward you in an earlier
message. That said, I believe the following technical
content merits consideration.

For the 6rd prefix discovery, what you are suggesting is
simply a stateless IPv6 prefix delegation. It is stateless
in the sense that the customer need only discover the
operator's /32 or larger prefix, and then the customer
can self-assign its own IPv6 prefix based on its IPv4
address. This can be done as a DHCPv4 option, or if
link-local IPv6 is available it can also be done as a
DHCPv6 option. But, stateless IPv6 prefix delegation
is really what it is.

For 6rd router unicast/anycast address discovery, that
function would be identical to the potential router list
(PRL) discovery mechanisms of ISATAP/VET. Indeed, 6rd is
nothing more than ISATAP/VET with many of the features
removed. A worthwhile idea to consider is to combine
the 6rd stateless prefix delegation (which AFAICT is
its primary contribution) with the already defined
mechanisms of ISATAP and VET.

Fred
[e-mail]

> 
> - Mark
> 
> Templin, Fred L wrote:
> > Remi,
> >
> >
> >> -----Original Message-----
> >> From: Rémi Després [mailto:[e-mail]]
> >> Sent: Tuesday, May 19, 2009 2:19 AM
> >> To: Templin, Fred L
> >> Cc: Sheng Jiang; [e-mail]; [e-mail]; [e-mail]; Fleischman,
> >> Eric; Russert, Steven W
> >> Subject: Re: New Version Notification for draft-jiang-v6ops-incremental-cgn
> >>
> >> Templin, Fred L  -  le (m/j/a) 5/14/09 5:17 PM:
> >>
> >>> 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.
> >>>
> >> As explained in the 6rd draft (soon to become an RFC), 6rd solves the
> >> major problem of 6to4: the lack of guarantee that paths exist between
> >> all IPv6 sites and all 6to4 sites, and that these paths have ISP
> >> controlled QoS.
> >>
> >
> > Yes, so is VET soon to become an RFC. But, 6rd is not solving a
> > 6to4 problem with its open relays; it is solving an intra-site
> > problem with ordinary IPv6 routers just like VET.
> >
> >
> >>> 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 important point is that the 6rd-relay address MAY be anycast. If
> >> there is only one relay at this address, there is no difference with an
> >> anycast address.
> >> Reasons for permitting  anycast are SCALABILITY and AVAILABILITY of the
> >> solution:
> >>
> >
> > Just for the record, ISATAP/VET can use anycast just
> > the same as for 6rd but chose not to specify it. This
> > choice was based on deliberations between authors and
> > working group alike that identified the stated problems.
> >
> >
> >> - if available relays seem to be soon insufficient for the traffic, just
> >> add one more, at the same anycast address. While ISATAP is intra-site,
> >> 6rd relays, like those of 6to4 which also use an anycast address, have
> >> to support all the IPv6 traffic of an ISP that uses 6rd.
> >> - if a 6rd-relay fails, the traffic goes to another one.
> >>
> >
> > No; 6rd is intra-site. The site is the ISP operator's
> > 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.
> >>>
> >> If the ISP supports an IPv4 MTU long enough for IPv6 packets of 1280
> >> octets (as it should) and discards longer ones, no fragmentation is ever
> >> needed.
> >> This is common with 6to4, which uses anycast addressing for its relays.
> >>
> >
> > 1280 is an unsatisfactory MTU for customer devices that
> > would prefer to use 1500. The CPE is an in-the-network
> > tunnel endpoint such that customer devices on a 1500
> > segment would be constantly inconvenienced with ICMP
> > PTB messages were the CPE to deploy with only 1280.
> >
> > But, if you want to push the CPE tunnel endpoint to
> > 1500, you have to allow for the possibility of
> > fragmentation. VET and SEAL solve this problem.
> >
> >
> >>> 2) with anycast, there is no opportunity for default
> >>>    router selection (when there are multiple)
> >>>
> >> Yes. But what is the practical problem?
> >>
> >
> > If there are multiple PE routers in the ISP network,
> > the CPE should have the ability to distinguish them
> > and choose between them - just as for any link where
> > there may be multiple routers.
> >
> >
> >>> 3) with anycast, there is no opportunity for traffic
> >>>    engineering
> >>>
> >> Different source zones may be oriented toward different relays, or relay
> >> farms with internal load balancers.
> >>
> >
> > Traffic engineering is the ability for a CPE router
> > to direct some traffic through PE router A and other
> > traffic through PE router B. With anycast, the CPE
> > router can't discern A from B.
> >
> >
> >> All the complexity of deciding which customer sites should receive which
> >> unicast addresses is avoided.
> >>
> >
> > I don't see anything having to do with complexity, really.
> > And, it's the very same consideration as to which customers
> > should receive which DNS suffixes.
> >
> >
> >>> 4) with anycast, IPv6 neighbor discovery over the
> >>>    tunnel may yield unpredictable results
> >>>
> >> Neighbor discovery doesn't apply more over 6rd tunnels than it does on
> >> 6to4 tunnels.
> >>
> >
> > Neighbor discovery is useful in many ways. NUD, default
> > router preferences and more specific routes, SEND, and
> > many more. 6rd is not really comparable to 6to4, however;
> > 6rd is intra-site just as ISATAP/VET.
> >
> >
> >>> 5) with anycast, there is need for a manual provisioning
> >>>    of IPv6 prefixes and IPv4 anycast address on the CPE
> >>>    router.
> >>>
> >> As explained in the draft, Free deployed 6rd with their 6rd parameters
> >> included in their downloaded CPE software (IPv6 prefix and relay anycast
> >> address).
> >>
> >
> > This is unnecessarily marrying the CPE devices to the
> > ISP in a way that CPE vendors might not appreciate. It
> > also makes renumbering and discovery of new prefixes
> > quite cumbersome.
> >
> >
> >> For independently supplied CPEs , tools to convey these parameters have
> >> to be specified. As far as I know, Mark Townsley is working on a
> >> proposal for this.
> >>
> >
> > If Mark Townsley is working on a proposal for this, he is
> > re-inventing ISATAP PRL discovery. See also my proposal
> > for stateless DHCP prefix delegation for the 6rd prefix.
> >
> > Fred
> > [e-mail]
> >
> >
> >> Regards,
> >>
> >> RD
> >>
> >
> >
> >