IETF Logo Mail Archive

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

Ted Lemon <Ted.Lemon@nominum.com> Fri, 18 November 2011 02:17 UTC

Return-Path: <Ted.Lemon@nominum.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 6E8C61F0C5C for <mif@ietfa.amsl.com>; Thu, 17 Nov 2011 18:17:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.568
X-Spam-Level:
X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 dOLB+NpU9rzC for <mif@ietfa.amsl.com>; Thu, 17 Nov 2011 18:17:12 -0800 (PST)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id A86AE1F0C34 for <mif@ietf.org>; Thu, 17 Nov 2011 18:17:11 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTsXAJxlvEaDj6n0IKdSjgNSM/Relsu/T@postini.com; Thu, 17 Nov 2011 18:17:11 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C28321B82AD for <mif@ietf.org>; Thu, 17 Nov 2011 18:17:10 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B51DA19005D; Thu, 17 Nov 2011 18:17:10 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Thu, 17 Nov 2011 18:17:10 -0800
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: [mif] Server selection document is "band-aid" not solution
Thread-Index: AQHMpM8ZeOJMqkjpCkunz3mHScTfw5Ww4w+AgAAE1gD//5hqNIAB3BkA//+KU9U=
Date: Fri, 18 Nov 2011 02:17:09 +0000
Message-ID: <FE5A324F-6D21-4EE0-A3AD-C80D0D83BD87@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>
In-Reply-To: <4EC5B25C.7010903@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 02:17:12 -0000

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.

v2.23.0 | Report a Bug | By Email