Re: multi-homing for provider-assigned IPv6 addresses

"Fred Baker (fred)" <fred@cisco.com> Mon, 28 March 2016 19:47 UTC

Return-Path: <fred@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 65E9712D508 for <rtgwg@ietfa.amsl.com>; Mon, 28 Mar 2016 12:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.53
X-Spam-Level:
X-Spam-Status: No, score=-114.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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, USER_IN_WHITELIST=-100] 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 Q0oskbHnNCQF for <rtgwg@ietfa.amsl.com>; Mon, 28 Mar 2016 12:47:17 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A6712D133 for <rtgwg@ietf.org>; Mon, 28 Mar 2016 12:47:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29733; q=dns/txt; s=iport; t=1459194436; x=1460404036; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MGJtY6ZhTodBkXJc6a98Llj0TK8elCRIPtI27hP+D6Q=; b=WCi7bc9C6MAgpvc2kPKudM8pkIVEePhsrxRyKUgNhxuhiZa97y9Qx9Ck qUU4bfOcCCyJLf8Am+8l0sSFML3j+IndWWzsFifFMI6jDo/y4TMwHufhN mIz2U+dujrKPRcQ4CsDgguc+SEQ0PYboU2UsjsD6YMolSR4ZGtCYMyAM5 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D3AQAYiflW/49dJa1dgmJMgVAGgRm5VQENgXCGDQKBIzgUAQEBAQEBAWQnhEEBAQEDAXkFBwQCAQgOAwQBAQEgAQYHMhQJCAEBBA4FiB8Iv2UBAQEBAQEBAQEBAQEBAQEBAQEBAQEViBGCUYdngisFl2EBjgWBZo0lhhCIeQEeAQFCg2Vsh3x+AQEB
X-IronPort-AV: E=Sophos;i="5.24,408,1454976000"; d="scan'208,217";a="254544033"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2016 19:47:14 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u2SJlEeI009145 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Mar 2016 19:47:14 GMT
Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Mar 2016 14:47:14 -0500
Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 28 Mar 2016 14:47:13 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: Chris Bowers <cbowers@juniper.net>
Subject: Re: multi-homing for provider-assigned IPv6 addresses
Thread-Topic: multi-homing for provider-assigned IPv6 addresses
Thread-Index: AdF+uwDrcP0DGOmLTI2DpIRz9JHSSAHYdCQgABcYAIAAAC5+gAANlbvQAKkRhYA=
Date: Mon, 28 Mar 2016 19:47:13 +0000
Message-ID: <952CDE11-C5D6-4B19-BD22-86916222E605@cisco.com>
References: <BY2PR05MB614108C29A178E43A88B9D0A9890@BY2PR05MB614.namprd05.prod.outlook.com> <BY2PR05MB6149CE3235088E8010AE616A9820@BY2PR05MB614.namprd05.prod.outlook.com> <DB45D156-370C-4F96-BB23-B6DB385EE913@cisco.com> <913C1037-718D-4026-9C15-A0A2F8CB95E6@cisco.com> <BY2PR05MB614A27E17CB2E5189224E8FA9850@BY2PR05MB614.namprd05.prod.outlook.com>
In-Reply-To: <BY2PR05MB614A27E17CB2E5189224E8FA9850@BY2PR05MB614.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3124)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.64.123]
Content-Type: multipart/alternative; boundary="_000_952CDE11C5D64B19BD2286916222E605ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/SmmFF8X_NdDrKhPJ4rCA7eXbMB0>
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
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: Mon, 28 Mar 2016 19:47:19 -0000

On Mar 27, 2016, at 9:03 AM, Chris Bowers <cbowers@juniper.net<mailto:cbowers@juniper.net>> wrote:

Fred,

I would like to better understand the particular use case offered as a counter-example.  One version of this counter-example is described in Section 2.3 of draft-baker-rtgwg-src-dst-routing-use-cases-01 (Specialized Egress Routing).  I have copied figure 3 from that draft below.

                                                ,-------.
                                             ,-'         `-.
             ,---.            ,-----.      ,'               `.
            /     \    +-+  ,'       `.   /                   \
           /       +---+R+-+   ISP 1   --+---                  \
          /         \  +-+  `.       ,' ;                       :
         ; Customer  :        `-----'   |       The Internet    |
         | Network   |        ,-----.   :                       ;
         :           ; +-+  ,'       `.  \                     /
          \         +--+R+-+   ISP 2   )  \                   /
           \       /   +-+  `.       ,'    `.               ,'
            \     /           `--+--'        '-.         ,-'
             `---'               |              `-------'
                           Some specialized
                              Service

       Figure 3: Egress Routing with a specialized upstream network


If a customer network homed to ISP1 and ISP2 (with PA prefixes S1 and S2) needs to reach a destination prefix (D2) associated with a service offered by ISP2, then the customer network can route all traffic with destination address in D2 to ISP2 using existing destination-based routing.

Yes, if the packet first goes through a router that is not depicted in the diagram (I didn't describe the interior of the customer network, which could be as simple as a LAN and as complex as you care to imagine). If the only routing is done by the host itself, the packet will go to the router the host considers to be its default router, which is pretty likely to be the other router in this example. That is the subject of draft-ietf-6man-multi-homed-host. Note, BTW, that the picture is essentially NTT's BFLETS configuration, with the exception that (as I understand it) the two ISPs are served by the same managed router, deployed by NTT and configured to route appropriately.

Therefore, it seems to me that pairing a source prefix with an arbitrary destination prefix is not required to support the Specialized Egress Routing use case in draft-baker-rtgwg-src-dst-routing-use-cases-01. In any case, it would be useful to come to agreement about what is required to address the Specialized Egress Routing use case described in draft-baker-rtgwg-src-dst-routing-use-cases-01.

I'm happy to discuss that. I think it misses the point, however. If the use case described isn't a good one, let's think of a better use case, perhaps one that doesn't involve a PA prefix from an ISP. Perhaps the biggest issue with your proposal, which was to take all traffic using a given source prefix to an appropriate egress router, is that it precludes the use of the address to communicate within the customer network. All traffic would dogleg through the egress router, and I'm not sure I see how packets get from that router to a point inside without looping. There has to be a way to prefer to destination-address route some traffic and source-address route some other traffic. The simplest way I can think of is to use both addresses in every route lookup, interpreting a traditional destination route as a source/destination route from ::/0 to the stated destination, or (if there are multiple route tables by source prefix) duplicate the destination route table in each.

If instead the counter-example use case described below is different from Specialized Egress Routing use case in draft-baker-rtgwg-src-dst-routing-use-cases-01, it would be useful to describe that use case in more detail so that we can evaluate it more thoroughly.

I'll take a look at that. Of course, I can't update the draft until next week.

Thanks,
Chris

-----Original Message-----
From: Fred Baker (fred) [mailto:fred@cisco.com]
Sent: Thursday, March 24, 2016 11:37 PM
To: Chris Bowers <cbowers@juniper.net<mailto:cbowers@juniper.net>>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: Re: multi-homing for provider-assigned IPv6 addresses


> On Mar 24, 2016, at 9:32 PM, Fred Baker (fred) <fred@cisco.com<mailto:fred@cisco.com>> wrote:
>
>
>> On Mar 24, 2016, at 4:34 PM, Chris Bowers <cbowers@juniper.net<mailto:cbowers@juniper.net>> wrote:
>>
>> 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?
>
> When what one has in mind is an egress route, that probably makes sense. However, it precludes an entire class of use cases mentioned in the use case draft. Why do that?

Let me give you an obvious variant. Imagine, if you will, that I have a PA prefix from each of N ISPs, and therefore a default route to each of N ISPs. Imagine also that I have a particular prefix that I would like to route through via a given one of those N ISPs, in the special case that I happen to have been smart enough to use that source prefix. So now I have N+1 source/destination routes - unless you tie it to default routes.

A premature optimization usually breaks things...