Re: draft-ietf-v6ops-addr-select-ps-02

[Florian Weimer <fw@deneb.enyo.de>]

* Arifumi Matsumoto:

> This problem can be thought to be conflict of local (client-side)
> optimization and remote (server-side) optimization. Dst-rule 9 tries
> to implement local optimization of subsequent communication and breaks
> DNS round-robin technique which is optimization of the remote side
> traffic.
>
> In my solution draft, which was approved as 6man wg item at Vancouver,
> some proposed mechanisms for achieving/compensating local optimization
> are described and analyzed, such as address policy distrbituion
> mechanism.

Does this mean that the 6man WG is responsible for RFC 3484bis?  I had
missed this.  And why is v6ops dealing with
draft-ietf-v6ops-addr-select-ps-02?  Wouldn't this fit 6man better, too?

> My suggestion for solving this problem is to change default address selection
> algorithm to support remote optimization, namely invalidate dst-rule 9, and to
> adopt other mechanism for local optimization if necessary.

I'm in favor of disabling Rule 9 for IPv4.  If IPv6 is finally deployed,
I guess the prefix distribution will resemble that of IPv4, so Rule 9
isn't that helpful over there, either.  But this is mere speculation.

> As everyone mentioned, poor way of local optimization does harm for
> remote side and sometimes for local side. Any kind of local
> optimization should be implemented carefully by an administrator that
> figures out what size of address block his site has, which address
> block the upstream network has, and what kind of address selection
> policy doesn't conflict with DNS round-robin like remote optimization.

To some extent, it's also possible to put that optimization into the
caching resolver (which might get better topology data via BGP, for
instance).  If the client reorders addresses, this doesn't work anymore.