Re: [mif] Server selection document is "band-aid" not solution

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 18 November 2011 03:26 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E7511E80C4 for <mif@ietfa.amsl.com>; Thu, 17 Nov 2011 19:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.522
X-Spam-Level:
X-Spam-Status: No, score=-103.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, 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 LKxZgxaJkqxb for <mif@ietfa.amsl.com>; Thu, 17 Nov 2011 19:26:12 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D15A811E8097 for <mif@ietf.org>; Thu, 17 Nov 2011 19:26:12 -0800 (PST)
Received: by yenq4 with SMTP id q4so2326124yen.31 for <mif@ietf.org>; Thu, 17 Nov 2011 19:26:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n0uZ1fH1fuyYPokY5ILEWj8ZQVKXp2k+x7137tmNMAM=; b=s7qASp0i3sO1Ldex6Ov+RmNrU5VmjIbOrZlyKdQj1jW+JKYvexEbqxb9Ljzo3zsBnl vNztNQ9fWCrF+aA07hbL+/Cc8JfRD1YG/vDC/xSRnsPyoAxZGoC+4GvhQwWvvJcVqImH tr4vY7CGO0RoQ13NDCz6/mOK+6yjcr4WC3QUA=
Received: by 10.100.99.16 with SMTP id w16mr341442anb.22.1321586772499; Thu, 17 Nov 2011 19:26:12 -0800 (PST)
Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id h28sm16683550ani.17.2011.11.17.19.26.10 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 19:26:11 -0800 (PST)
Message-ID: <4EC5D04B.9080509@gmail.com>
Date: Fri, 18 Nov 2011 16:26:03 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC479E0.6030704@gmail.com> <292CDFDE-32DE-43D9-83DD-86D3978F3EEF@nominum.com>, <4EC5B25C.7010903@gmail.com> <FE5A324F-6D21-4EE0-A3AD-C80D0D83BD87@nominum.com>
In-Reply-To: <FE5A324F-6D21-4EE0-A3AD-C80D0D83BD87@nominum.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] Server selection document is "band-aid" not solution
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2011 03:26:13 -0000

On 2011-11-18 15:17, Ted Lemon wrote:
> On Nov 18, 2011, at 9:18 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>> However these (and any other) host mechanisms need an initial set of address
>> pairs to try out and, in many cases, an order of preference in which to
>> try them. In some cases (but not all) DNS may be source of a set of
>> destination addresses, but it's only the routing system that can provide
>> a priori information about which address *pairs* are worth trying.
> 
> Can you provide an example of a case where the routing system has the capacity to do this in a MIF setting where you have two interfaces connected to separate administrative domains?   I agree at least in principle that you may be able to come up with some special case where you could decide on the basis of some such information which pair to try first.   However, I am pretty sure that a general solution will not be able to rely on whatever information source you rely on in whatever special case you cite.
> 

Today? Probably not. But that doesn't mean it shouldn't be a
goal. Things like knowing which egresses are subject to which
ingress filters, for example, could be known to the border routers.

   Brian