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

Dave Thaler <dthaler@microsoft.com> Tue, 31 July 2012 00:28 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD1F21F85D2 for <ipv6@ietfa.amsl.com>; Mon, 30 Jul 2012 17:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.406
X-Spam-Level:
X-Spam-Status: No, score=-103.406 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3QwlByJ2mS7 for <ipv6@ietfa.amsl.com>; Mon, 30 Jul 2012 17:28:15 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id DDD7F21F85C4 for <ipv6@ietf.org>; Mon, 30 Jul 2012 17:28:14 -0700 (PDT)
Received: from mail168-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 00:28:14 +0000
Received: from mail168-va3 (localhost [127.0.0.1]) by mail168-va3-R.bigfish.com (Postfix) with ESMTP id 39BA560389; Tue, 31 Jul 2012 00:28:14 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -28
X-BigFish: VS-28(zz9371I146fI542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah)
Received-SPF: pass (mail168-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail168-va3 (localhost.localdomain [127.0.0.1]) by mail168-va3 (MessageSwitch) id 1343694492835038_941; Tue, 31 Jul 2012 00:28:12 +0000 (UTC)
Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.254]) by mail168-va3.bigfish.com (Postfix) with ESMTP id BDA0F3800D2; Tue, 31 Jul 2012 00:28:12 +0000 (UTC)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 00:28:12 +0000
Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 31 Jul 2012 00:28:10 +0000
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 30 Jul 2012 17:28:10 -0700
Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Mon, 30 Jul 2012 17:28:10 -0700
From: Dave Thaler <dthaler@microsoft.com>
To: Karl Auer <kauer@biplane.com.au>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()
Thread-Topic: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()
Thread-Index: AQHNbSefWPJft5j+MUyaK6aT0cUFA5dCiZ7g
Date: Tue, 31 Jul 2012 00:28:09 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653B72ECDD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
References: <1343085852.2796.201.camel@karl> <1343524489.3497.94.camel@karl>
In-Reply-To: <1343524489.3497.94.camel@karl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.43]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jul 2012 00:28:16 -0000

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Karl Auer
> Sent: Saturday, July 28, 2012 6:15 PM
> To: ipv6@ietf.org
> Subject: Re: question about draft-ietf-6man-rfc3484bis-06.txt and
> CommonPrefixLen()
> 
> A few days ago, I asked about this draft as below. I haven't seen a response,

Probably because we've been in route to IETF.

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

True.   It is missing the implied tie breaker sentence that exists in
Destination address selection:
    Rule 10: Otherwise, leave the order unchanged.
    If DA preceded DB in the original list, prefer DA.  Otherwise prefer
    DB.

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

The bits in the interface identifier are not indicative of goodness or
appropriateness or whatever.   They can be random, or based on something
unrelated to appropriateness for a given destination or for destinations in
general.   So there's no benefit in having CommonPrefixLen() continue.
In the destination case, rule 10 preserves the original order, resulting in
DNS load balancing applying.   That is, the pre-sort order is the implied
tie breaker.

For source sorting, the same is true.   That is, you have a list of candidate
source addresses.   Whatever that order is, is the implied tie breaker.
So if the host has some default ordering, or chooses to round robin
them (as DNS does with dest addrs), or whatever else, then the 
implied Rule 9 (don't change the order) preserves that tie breaker,
which is better than using the interface identifier bits which don't
have any technical reason to use them.

I would be fine with making an editorial-only change to the doc to:
1) explicitly add Rule 9 which is already implied.
2) Update Appendix B with a sentence or two summarizing the change
   to source sorting.

Of course an implementation that does use the interface identifier bits
as RFC 3484 did is still compliant to 3484bis, since it can override rule
8 per the existing text, and of course it could order the candidate
source list by common prefix length, either of which would result in
the old behavior.   And since RFC 3484 already contained the same MAY
about overriding the new rule 8, there's no real "compliance" change
between the two, just a marginally different recommendation, based
on the WG agreement that the interface identifier bits aren't really
relevant to sorting.

-Dave

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