Re: [v6ops] Question on multi-homed nodes and address/route selection

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Thu, 02 March 2017 16:28 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAFD12953A; Thu, 2 Mar 2017 08:28:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZzgSVIF7EB2; Thu, 2 Mar 2017 08:28:09 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BE8129570; Thu, 2 Mar 2017 08:28:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3330; q=dns/txt; s=iport; t=1488472088; x=1489681688; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7IbtK1nfRO93rAgUP5nGyWhOSv4W+6CveJo2Xml+T+g=; b=R6UWJFgNuu69En3p3VXfiU1sIz9FYycF/RJHfl7rLyvU48pkcVDUya0l VwtzCOVt3VV1bfaGyD+Jo79aR0IN0AsaS3/wEk1DNHxX3BUh0MGYHAEEa o2CmEHiU+PDGbyzRMGKjQCsy/y04uJVZRZGxQfdUFx3sdNAlrSWVaiTfU w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C+AQC5RrhY/4wNJK1eGQEBAQEBAQEBAQEBBwEBAQEBg1BhgQkHg1aKCpFnlTWCDR8LhXgCGoIzPxgBAgEBAQEBAQFiKIRxAQEDAQEBIRE6CxACAQgODAImAgICJQsVEAIEAQkEBYlyCA6xVIImixgBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUGCBYJqhCYQAgEbF4JvLoIxBYkPiBCLCgGGdIs9kR+TNgEfOHkIVBU+EQGGO3WIcYENAQEB
X-IronPort-AV: E=Sophos;i="5.35,232,1484006400"; d="scan'208";a="213357996"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Mar 2017 16:28:07 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v22GS7Bb020447 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Mar 2017 16:28:07 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Mar 2017 11:28:07 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 2 Mar 2017 11:28:06 -0500
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Simon Hobson <linux@thehobsons.co.uk>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] Question on multi-homed nodes and address/route selection
Thread-Index: AQHSk3H5PR61nvg62USOXUB7zY+yQQ==
Date: Thu, 02 Mar 2017 16:28:06 +0000
Message-ID: <A495BAE4-CC7D-4E94-94A0-51EC829E9A7D@cisco.com>
References: <E969A0C5-46E5-4B58-BDEB-AE686D76210F@thehobsons.co.uk> <013B7A75-E5F6-4F47-9D92-33114F1781F8@cisco.com> <B1BBBF51-2B5D-4E65-BB23-1D1A52C1A183@thehobsons.co.uk>
In-Reply-To: <B1BBBF51-2B5D-4E65-BB23-1D1A52C1A183@thehobsons.co.uk>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.56.4]
Content-Type: text/plain; charset="utf-8"
Content-ID: <BA1879F2E77ECA43B2C8C41A1B329D1D@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/TNB8OG27z0iXscgp5Xxvw8G-rKY>
Cc: "draft-bruneau-pvd.authors@ietf.org" <draft-bruneau-pvd.authors@ietf.org>
Subject: Re: [v6ops] Question on multi-homed nodes and address/route selection
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 16:28:10 -0000

Simon,

You nail the problem that the draft https://tools.ietf.org/html/draft-bruneau-pvd-00 is trying to address ;-)

Comments are welcome of course (I will send a separate email for those comments in a few minutes).

The other document I was refering to is now expired: https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-10 

-éric


On 02/03/17 14:45, "v6ops on behalf of Simon Hobson" <v6ops-bounces@ietf.org on behalf of linux@thehobsons.co.uk> wrote:

    Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
    
    > How timely :-)
    > 
    > Together with other folks, we are submitting an I-D in the  coming hours about Provisioning Domains (PvD) which addresses your use case of multi-homing in a 'complex case'.
    
    I look forward to looking at it.
    
    > AFAIK, there is another I-D (or even RFC) that recommends hosts to select the default route next-hop based on the source prefix used.
    
    That doesn't really address the issue. It's logical that for whichever address the node picks to use as a source address for an outbound connection, it should use an appropriate outbound route - I would guess, logically a router that advertised the matching prefix as one it routes for.
    
    But you have to take a step back and look at how that source address is picked - because in effect, source address selection for an outbound connection is intrinsically linked to route selection. Ie, if the node/service picks address A then the packet must be routed via connection X, if it picks source address B then the packet must be routed via connection Y.
    
    So it's no good if (just picking an example) I've got a connection that is good for bulk transfers (cheap, maybe slower and/or higher latency/jitter) and want to route my outbound mail via that connection, thus leaving the higher cost but better connection for interactive use (eg browsing) - if the mail service then uses a source address meaning that the packets have to be routed via the latter connection.
    I could force the mail service to bind to just one address - but that then means more local config - and it breaks if the latter connection goes down and I need it to failover to the other one for the duration of the outage.
    
    
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops