Re: multi-homing for provider-assigned IPv6 addresses

Anton Smirnov <asmirnov@cisco.com> Fri, 25 March 2016 11:31 UTC

Return-Path: <asmirnov@cisco.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C3112D66E for <rtgwg@ietfa.amsl.com>; Fri, 25 Mar 2016 04:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Kb1DdJleKoZM for <rtgwg@ietfa.amsl.com>; Fri, 25 Mar 2016 04:31:21 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BB112D68D for <rtgwg@ietf.org>; Fri, 25 Mar 2016 04:31:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8908; q=dns/txt; s=iport; t=1458905480; x=1460115080; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=bsYih9LSWLhOWPukEDnKq/V/M0cfzgVQIi0+Kqq81Og=; b=WL715fJVLQhKBaUxTGOGoyZAoBtGgVPZdd6RwMoxAM5MLDfOhx6bpLDw Baql4uYfQ3hFZtHl9XHKPfEupgdJcwx4OI2d+Bg6EABic0AmvWBBtfM5w GLwQqASthSknfrUovBA1ly/OPggnCyeJI+7RoqUxHQVJyoMGLB73wi/L/ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CvBACXIPVW/xbLJq1ehAd9vFkXDII6gzACggABAQEBAQFlHAuEQQEBAQMBAQEBNS8HCg0ECxEEAQEBCRYIBwkDAgECARUfCQgGDQYCAQEXiAQIDsEnAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGHoREhAwLBgEPhWUBBIddhxGIcoVxiBOBZod0hTGPCmKCAByBSjswAYdgAQcXgR0BAQE
X-IronPort-AV: E=Sophos;i="5.24,390,1454976000"; d="scan'208";a="636536553"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2016 11:31:18 +0000
Received: from as-lnx.cisco.com (ams-asmirnov-nitro5.cisco.com [10.55.206.134]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2PBVGiW032519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <rtgwg@ietf.org>; Fri, 25 Mar 2016 11:31:17 GMT
Message-ID: <56F52184.9030905@cisco.com>
Date: Fri, 25 Mar 2016 12:31:16 +0100
From: Anton Smirnov <asmirnov@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: multi-homing for provider-assigned IPv6 addresses
References: <BY2PR05MB614108C29A178E43A88B9D0A9890@BY2PR05MB614.namprd05.prod.outlook.com> <BY2PR05MB6149CE3235088E8010AE616A9820@BY2PR05MB614.namprd05.prod.outlook.com>
In-Reply-To: <BY2PR05MB6149CE3235088E8010AE616A9820@BY2PR05MB614.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Authenticated-User: asmirnov
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/ERBDKcvuXBsWKqABphxZOQXDb4U>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2016 11:31:27 -0000

    Hi Chris,

 > At this point, RTGWG also
 > needs to consider the impact of proposed solutions on routing
 > scalability.

    For any scalability discussion one has to remember that src-dst 
routing was conceived to IMPROVE routing scalability by avoiding need to 
advertise globally prefixes of small dual-connected networks. We should 
keep in mind that src-dst routing is addressing one of most important 
reasons of why /24 and smaller prefixes are being injected into BGP.

Anton


On 03/25/2016 12:34 AM, Chris Bowers wrote:
> RTGWG,
>
> It seems to me that most use cases for ipv6 multi-homing with provider-assigned addresses only need to route based on source address when the destination prefix is the default route.  So why not require that source prefixes can only be paired up with the default destination prefix ::/0?  That is, we could require that a router can only route based on the source address after the longest match route lookup based on destination address has reached ::/0.  That way, a router can still route packets local to the site based on destination address.  Only once it is clear that the packet is going to the Internet can the router use the source address to pick the correct CE router to get there.
>
> I see that there was some discussion about this in 2013 on a thread in homenet and rtgwg in the context of draft-baker-rtgwg-src-dst-routing-use-cases, and a number of different opinions were expressed mainly from the point of view of what is needed for homenet.  At this point, RTGWG also needs to consider the impact of proposed solutions on routing scalability.  On the surface, this simplification would seem to improve the scaling properties of the solution in draft-ietf-rtgwg-dst-src-routing, while covering most use cases.
>
> Regardless of how this discussion turns out, I think the draft itself will benefit from more active discussion of the tradeoffs involved.
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: Chris Bowers
> Sent: Tuesday, March 15, 2016 8:14 AM
> To: 'rtgwg@ietf.org' <rtgwg@ietf.org>
> Subject: multi-homing for provider-assigned IPv6 addresses
>
> RTGWG,
>
> We scheduled a significant amount of time in Buenos Aires for a discussion of multi-homing for provider-assigned IPv6 addresses for enterprise networks as well as homenet.  I want to explain the motivation for this and provide some background on the topic.  And hopefully spark some discussion on the list before Buenos Aires, as well.
>
> RTGWG adopted draft-ietf-rtgwg-dst-src-routing last October in the context of supporting multi-homing for provider-assigned IPv6 addresses in homenet.  In Yokohama, the v6ops WG had a lengthy discussion about the need for a solution to support multi-homing for provider-assigned IPv6 addresses for enterprise networks in general (as opposed to just homenet).  This discussion took place in the context of draft-ietf-v6ops-design-choices.  That discussion can be found at:
>
> https://youtu.be/VzH7yqqGiGc?t=5835
>
> This discussion led to the email (copied below) from Fred Baker in his role as v6ops co-chair to the chairs of several working groups in which drafts related to this topic are being discussed.
>
> Our meeting in Buenos Aires includes a 20 minute time slot to discuss the background and motivation of this request from v6ops.  The topic of multi-homing for provider-assigned IPv6 addresses has a long history with many documents written, so I thought it would be useful to highlight a few of the more recent documents that I found to be particularly useful reading.
>
> RFC 7157 "IPv6 Multihoming without Network Address Translation"
> https://datatracker.ietf.org/doc/rfc7157/
>
> draft-ietf-6man-multi-homed-host-06 "Routing packets from hosts in a multi-prefix network"
> https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/
>
> In addition, it would obviously be useful read or re-read the RTGWG document on this topic:
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-dst-src-routing/
>
> There following expired document is also helpful.
> https://www.ietf.org/archive/id/draft-baker-rtgwg-src-dst-routing-use-cases-01.txt
>
> And finally, this document is useful to understand a concrete proposal for how src/dst routing information could be carried in a link-state routing protocol.
> https://datatracker.ietf.org/doc/draft-baker-ipv6-isis-dst-src-routing/
>
> I look forward to a fruitful discussion on this topic on the list and in Buenos Aires.
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: Fred Baker (fred) [mailto:fred@cisco.com]
> Sent: Sunday, November 01, 2015 11:03 PM
> To: isis-ads@tools.ietf.org; rtgwg-chairs@ietf.org; isis-chairs@tools.ietf.org; ospf-chairs@tools.ietf.org; 6man Chairs <6man-chairs@tools.ietf.org>; homenet-chairs@tools.ietf.org
> Cc: v6ops@ietf.org WG <v6ops@ietf.org>; The IESG <iesg@ietf.org>
> Subject: PA Address Multihoming in IPv6
>
> This email is being sent in accordance with the v6ops charter, which calls for the working group to communicate operational issues and requirements to working groups that are chartered to address them.
>
> The IETF's current primary recommendation for multihoming of midrange enterprise networks - those that cannot justify the costs and overheads of a PI address and in fact multihome - is to obtain a provider-allocated prefix from each of their upstream networks, and deploy a /64 out of each on each LAN in their networks.
>
> https://tools.ietf.org/html/rfc4213
> 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark,
>       R. Gilligan. October 2005. (Format: TXT=58575 bytes) (Obsoletes
>       RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4213)
>
> This has a number of issues, not the least of which is in the back end OSS software, which needs to now scale to a much larger number of prefixes, handle multiple addresses in DNS for servers and perhaps clients, resolve reverse DNS queries, and so on. It also is obviously carrying that much more information in routing.
>
> One outcome of v6ops' discussions this morning was that PI multihoming demonstrably works, but PA multihoming when the upstreams implement BCP 38 filtering requires the deployment of some form of egress routing - source/destination routing in which the traffic using a stated PA source prefix and directed to a remote destination is routed to the provider that allocated the prefix. The IETF currently has no such recommendation, or consensus that it should have. However, enterprise networks are known to delaying operational deployment of IPv6 in part due to the complexities visited upon them and the cost of the back end software upgrades, and this is part of that issue.
>
> Without trying to limit the options available to the working groups in question, I'll point out that options currently on the table include the following. There are also current open source implementations of source/destination and source-specific routing in IS-IS, OSPFv3, and Babel.
>
> https://datatracker.ietf.org/doc/draft-baker-ipv6-isis-dst-src-routing
>    "IPv6 Source/Destination Routing using IS-IS", Fred Baker, David
>    Lamparter, 2015-10-19
>
> https://datatracker.ietf.org/doc/draft-boutier-babel-source-specific
>    "Source-Specific Routing in Babel", Matthieu Boutier, Juliusz
>    Chroboczek, 2015-05-27
>
> https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host
>    "Routing packets from hosts in a multi-prefix network", Fred Baker,
>    Brian Carpenter, 2015-10-15
>
> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend
>    "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred
>    Baker, 2015-10-08
>
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-dst-src-routing
>    "Destination/Source Routing", David Lamparter, 2015-10-17,
>
> https://datatracker.ietf.org/doc/draft-sarikaya-6man-sadr-overview
>    "Source Address Dependent Routing and Source Address Selection for IPv6
>    Hosts: Problem Space Overview", Behcet Sarikaya, Mohamed Boucadair,
>    2015-08-17
>
> https://datatracker.ietf.org/doc/draft-sarikaya-6man-sadr-ra
>    "IPv6 RA Option for Source Address Dependent Routing", Behcet Sarikaya,
>    2015-06-08
>
> https://datatracker.ietf.org/doc/draft-sarikaya-dhc-6man-dhcpv6-sadr
>    "DHCPv6 Solution for Source Address Dependent Routing", Behcet Sarikaya,
>    2015-05-08
>
> https://datatracker.ietf.org/doc/draft-xu-ospf-multi-homing-ipv6
>    "Extending OSPFv3 to Support Multi-homing", Mingwei Xu, Shu Yang,
>    Jianping Wu, Fred Baker, 2015-10-11,
>
> https://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-cases
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>