IETF Logo Mail Archive

Re: Multi-homed BCP38

"Fred Baker (fred)" <fred@cisco.com> Thu, 09 January 2014 19:55 UTC

Return-Path: <fred@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF5A1AE408 for <ietf@ietfa.amsl.com>; Thu, 9 Jan 2014 11:55:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.039
X-Spam-Level:
X-Spam-Status: No, score=-115.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
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 nhzgwqYH5xwj for <ietf@ietfa.amsl.com>; Thu, 9 Jan 2014 11:55:46 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 71DFB1AE3D5 for <ietf@ietf.org>; Thu, 9 Jan 2014 11:55:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2790; q=dns/txt; s=iport; t=1389297337; x=1390506937; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2LrFgdndKEExpycyLFSxvrp+v3skBEHkj3BwynErPnM=; b=Z5ncY09sj0kB73Ab2/xgXAY6zAGjpizKONyUj+T1Kv1i39OH8uIR5Sca 9gJzU8LmME52zYEDSpm5Vm0TcFGBVltStkWR5pJKBIMiCWlq4rnkReM04 vP2ELhz5nEFIt1vSgP5B9hFTXdyX22R7vX8XKbiTCTAcGPJ717weJTYmB A=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEFABX+zlKtJV2b/2dsb2JhbABZgws4VqBfBwGYWoEUFnSCJQEBAQMBeQULAgEIRjIlAgQOBQ6HbggNvH0BhgYXjwUHgySBEwSQM4ExhjOBMJBlgy2CKg
X-IronPort-AV: E=Sophos; i="4.95,633,1384300800"; d="asc'?scan'208"; a="296345627"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jan 2014 19:55:36 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s09JtakC029228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jan 2014 19:55:36 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 9 Jan 2014 13:55:36 -0600
From: "Fred Baker (fred)" <fred@cisco.com>
To: John R Levine <johnl@taugh.com>
Subject: Re: Multi-homed BCP38
Thread-Topic: Multi-homed BCP38
Thread-Index: AQHPDUzosHm2Io2q+0midFiC3JbkZpp9M4CA
Date: Thu, 09 Jan 2014 19:55:36 +0000
Message-ID: <A6DD18F1-0C5B-4142-AF62-936C36D7378B@cisco.com>
References: <alpine.BSF.2.00.1401090943270.929@joyce.lan>
In-Reply-To: <alpine.BSF.2.00.1401090943270.929@joyce.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.156.48.192]
Content-Type: multipart/signed; boundary="Apple-Mail=_D2B28EED-3A28-404E-9E25-B8B8D7C9B866"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: IETF general list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Thu, 09 Jan 2014 19:55:48 -0000

On Jan 9, 2014, at 7:09 AM, John R Levine <johnl@taugh.com> wrote:

> I was at a meeting talking to ops people from some large ISPs, who tell me that when they tell their large customers about BCP 38, the customers say forget it, because they're multihomed.  I gather the situation is typically that the customer has multiple address ranges, say from providers A and B.  Normally traffic from range A goes out through provider A, and vice-versa, except sometimes when it doesn't.  Sometimes it's failover, or it may be deliberate asymmetic routing.  The customers may not be running BGP, or if they do, they don't want to announce range A to provider B for business reasons I don't entirely understand but that are not going away.
> 
> The ISPs tell me that the customers are often ISPs themselves, so there are lots of address ranges, far more than anyone could track manually even if they wanted to.
> 
> I see BCP 84, which is now ten years old.  The ISPs are aware of it, but it doesn't seem to have done the trick.  I can think of some hacks to pseudo-announce ranges for filtering purposes, but surely I am not the only person to have noticed this problem.  What have people done to address this issue?*  I figure the first thing to do is to understand what's failed before.

There are some drafts you may find interesting:

http://tools.ietf.org/html/draft-boutier-homenet-source-specific-routing
http://tools.ietf.org/html/draft-troan-homenet-sadr
http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing
http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases
http://tools.ietf.org/html/draft-xu-homenet-traffic-class
http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing

Homenet has been looking at this from the perspective of egress routing in residential multihoming. I have been looking at it more from source/destination routing in OSPF/IS-IS, for which "egress routing" and "residential multihoming" are special cases.

v2.23.0 | Report a Bug | By Email