Re: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()

Karl,

2012/7/29 Karl Auer <kauer@biplane.com.au>:
> A few days ago, I asked about this draft as below. I haven't seen a
> response, but the question still seems fair.
>
>> I don't fully understand this change (from section Appendix B):
>>
>> 1.  Changed the definition of CommonPrefixLen() to only compare bits
>>        up to the source address's prefix length.  The previous
>>        definition used the entire source address, rather than only its
>>        prefix. As a result, when a source and destination addresses
>>        had the same prefix, common bits in the interface ID would
>>        previously result in overriding DNS load balancing [RFC1794] by
>>        forcing the destination address with the most bits in common to
>>        be always chosen.  The updated definition allows DNS load
>>        balancing to continue to be used as a tie breaker.
>>
>> I can see this for destination address selection, where you are
>> working from a candidate set provided by a DNS server.
>>
>> But I don't see it for source address selection. If you have multiple
>> source address candidates in the same prefix, they will "fall through"
>> Rule 8 and the implementation then has to make a choice anyway, and
>> that choice doesn't seem able to be related to DNS load balancing.
>>
>> That is, the design rationale for the new CommonPrefixLen() doesn't
>> seem to apply to source address selection, which leads me to think
>> that for source address selection, CommonPrefixLen() should not stop
>> at the source address prefix length.
>>
>> Am I missing something obvious here?

In my understanding, there is no use to look at the interface id part
also for source address selection as well as for destination address
selection.

DNS load balance issue is explicitly specified, because it is clear
problem that we see.

Thanks.

>>
>> Regards, K.
>>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (kauer@biplane.com.au)
> http://www.biplane.com.au/kauer
> http://www.biplane.com.au/blog
>
> GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
> Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------