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

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Remi,

> -----Original Message-----
> From: Rémi Després [mailto:remi.despres@free.fr]
> Sent: Tuesday, May 19, 2009 2:19 AM
> To: Templin, Fred L
> Cc: Sheng Jiang; v6ops@ops.ietf.org; guoseu@huawei.com; brian.e.carpenter@gmail.com; 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
fred.l.templin@boeing.com

> Regards,
> 
> RD