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

[Arifumi Matsumoto <arifumi@nttv6.net>]

Florian,

Florian Weimer wrote:
> * 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?

Not exactly for RFC 3484bis, but for solving problems related to address
selection described in draft-ietf-v6ops-addr-select-ps-02.

About 2nd question,
we started this work at v6ops because v6ops are motivated for this.
Solution draft moved to 6man mainly because it involves some kind of
protocol work and we cannot do that at operation area.

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

Now that we have IPv6 PI, I agree that we should expect such a situation.
I'm afraid that leaving another difference between IPv4 and IPv6 spec is
gonna be another obstacle to IPv6 transition. So, disabling Rule 9 only
for IPv4 seems to me not a good idea, as far as IPv6 world doesn't
drastically change from IPv4.

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

If the rule 9 is disabled, that might be another mechanism for local
optimization. However, destination address sorting without knowledge
of source addresses that a querying host has is not helpful in some
cases.

Best regards,

--
Arifumi Matsumoto
   IP Technology Expert Team
   Secure Communication Project
   NTT Information Sharing Platform Laboratories
   E-mail: arifumi@nttv6.net