Re: RFC 3484 Section 6 Rule 9

Tony Finch <dot@dotat.at> Mon, 02 June 2008 21:53 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973973A697A; Mon, 2 Jun 2008 14:53:01 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894BB3A697A for <ietf@core3.amsl.com>; Mon, 2 Jun 2008 14:53:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.3
X-Spam-Level:
X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZD9RhgVcLu1 for <ietf@core3.amsl.com>; Mon, 2 Jun 2008 14:52:59 -0700 (PDT)
Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by core3.amsl.com (Postfix) with ESMTP id 2C9A23A693D for <ietf@ietf.org>; Mon, 2 Jun 2008 14:52:59 -0700 (PDT)
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40181) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1K3HxS-0007KZ-GG (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Mon, 02 Jun 2008 22:52:50 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1K3HxS-0000sb-0t (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Mon, 02 Jun 2008 22:52:50 +0100
Date: Mon, 02 Jun 2008 22:52:50 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Mark Andrews <Mark_Andrews@isc.org>
Subject: Re: RFC 3484 Section 6 Rule 9
In-Reply-To: <200806020456.m524ueYb080876@drugs.dv.isc.org>
Message-ID: <alpine.LSU.1.10.0806022249470.10482@hermes-1.csi.cam.ac.uk>
References: <200806020456.m524ueYb080876@drugs.dv.isc.org>
User-Agent: Alpine 1.10 (LSU 962 2008-03-14)
MIME-Version: 1.0
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 2 Jun 2008, Mark Andrews wrote:
>
> 	This rule should not exist for IPv4 or IPv6.  Longest match
> 	does not make a good sorting critera for destination address
> 	selection.  In fact it has the opposite effect by concentrating
> 	traffic on particular address rather than spreading load.

And it has caused problems in practice. I tried to start a discussion
about this in December last year. Here are links to the first messages in
the threads on the apps-discuss and dnsop lists.

http://www.ietf.org/mail-archive/web/discuss/current/msg01035.html
http://www.ietf.org/mail-archive/web/dnsop/current/msg05847.html

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
MALIN HEBRIDES BAILEY: SOUTHEASTERLY BECOMING CYCLONIC OR SOUTHWESTERLY 4,
INCREASING 5 TO 7. MODERATE, OCCASIONALLY ROUGH LATER. RAIN OR SHOWERS.
MODERATE OR GOOD, OCCASIONALLY POOR.
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf