Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing
David Lamparter <equinox@diac24.net> Thu, 20 July 2017 07:41 UTC
Return-Path: <equinox@diac24.net>
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 268DB126CD6 for <rtgwg@ietfa.amsl.com>; Thu, 20 Jul 2017 00:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 a1hEfprbIrLk for <rtgwg@ietfa.amsl.com>; Thu, 20 Jul 2017 00:41:37 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62D7126557 for <rtgwg@ietf.org>; Thu, 20 Jul 2017 00:41:37 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.89) (envelope-from <equinox@diac24.net>) id 1dY65U-001pDA-Rz; Thu, 20 Jul 2017 09:41:34 +0200
Date: Thu, 20 Jul 2017 09:41:32 +0200
From: David Lamparter <equinox@diac24.net>
To: rtgwg@ietf.org
Cc: Anton Smirnov <as@cisco.com>, Jen Linkova <furry@google.com>, Chris Bowers <cbowers@juniper.net>, Fred Baker <FredBaker.IETF@gmail.com>
Subject: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing
Message-ID: <20170720074132.GW773745@eidolon>
References: <20170719172913.GU773745@eidolon>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170719172913.GU773745@eidolon>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/n2K1ZDD_Fco1CO7Oy4ZQ6MYJebg>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 20 Jul 2017 07:41:40 -0000
Gah, forgot Cc:s, resending to list so replies will inherit Cc:s (please reply on this one to get the Cc:s) On Wed, Jul 19, 2017 at 07:29:13PM +0200, David Lamparter wrote: Hello again, rtgwg, Unfortunately (and possibly contradicting earlier statements I may have made to the opposite), the routing system behaviour described in https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-01#section-3 is not compatible with the behaviour described in https://tools.ietf.org/html/draft-ietf-rtgwg-dst-src-routing and will result in loops in specific cases when mixing implementations. The failure scenario is illustrated by the following setup: Considering 2 connected routers A and B, A implementing dst-src-routing and B implementing enterprise-pa-multihoming. Have: - A advertise D=::/0, S=::/0 - B advertise D=2001:db8::/32, S=2001:db8::/32 - B advertise D=2001:db8:aaaa::/48, S=2001:db8:ffff::/48 B will build the following "scoped tables": - unscoped: ::/0 via A - scope 2001:db8::/32 2001:db8::/32 local ::/0 via A - scope 2001:db8:ffff::/48 2001:db8:aaaa::/48 local ::/0 via A Note that the last scope has no entry for 2001:db8::/32, since item 3. in the first list in section 3 of the draft only prescribes propagating unscoped entries to the scoped table. This leads to a packet with S=2001:db8:ffff::1, D=2001:db8::1 looping between the routers: - router B performs the lookup as: - longest matching scoped table is S=2001:db8:ffff::/48 - scoped table contains route to ::/0 pointing at A - router A performs the lookup as: - most specific destination match is 2001:db8::/32 - under this destination, route with S=2001:db8::/32 points to B => persistent loop. It is my understanding that this discrepancy in behaviour is accidental and the enterprise-pa-multihoming draft is attempting to describe the same behaviour in local wording. Assuming this is the case, I'm unsure how we've ended up in this situation. I've heard the rtgwg-dst-src-routing draft may be hard to understand. If there are specific concerns, I'd ask for them to be voiced so that I can address them. I've checked for such feedback and found none, if I lost any I'm terribly sorry and hope it can be resent. If there are shared unspecific concerns, I suppose I can look at different ways to argue section 3 / 3.1. Still assuming that this was intended to be identical in behaviour, I would hope the mismatch can be addressed in enterprise-pa-multihoming. Looking at, well, the title of that draft, it seems that it's trying to be complete in describing the specific application in multihomed enterprises. This may also explain the specific mismatch in behaviour; it's in fact identical as long as one only considers exit routing with non-overlapping source prefix restrictions. rtgwg-dst-src-routing argues a broader applicability of the idea and tries to be thorough in describing a routing system feature to build on. As such, I'd be very happy to see enterprise-pa-multihoming describing in detail how to apply this feature for its title. Assuming it is _not_ the case that the intention is for these to be identical, we're IMHO heading for a rather bad place. I'd rather not argue this without confirming we're indeed there. Cheers, -David P.S.: rtgwg-dst-src-routing already had a description on how to translate its routes into a form suitable for "policy routing" implementations. The version just posted adds a reference to https://hal.inria.fr/file/index/docid/947234/filename/source-sensitive-routing.pdf which argues the implementation specifics and correctness of this translation in its full mathematical gore ;)
- Persistent loops when mixing rtgwg-enterprise-pa-… David Lamparter
- Persistent loops when mixing rtgwg-enterprise-pa-… David Lamparter
- Re: Persistent loops when mixing rtgwg-enterprise… David Lamparter
- Re: Persistent loops when mixing rtgwg-enterprise… Acee Lindem (acee)
- Re: Persistent loops when mixing rtgwg-enterprise… Matthieu Boutier
- Re: Persistent loops when mixing rtgwg-enterprise… Acee Lindem (acee)
- RE: Persistent loops when mixing rtgwg-enterprise… Chris Bowers
- Re: Persistent loops when mixing rtgwg-enterprise… Matthieu Boutier
- Re: Persistent loops when mixing rtgwg-enterprise… Matthieu Boutier
- RE: Persistent loops when mixing rtgwg-enterprise… Chris Bowers
- Re: Persistent loops when mixing rtgwg-enterprise… Fred Baker
- Re: Persistent loops when mixing rtgwg-enterprise… Matthieu Boutier
- Re: Persistent loops when mixing rtgwg-enterprise… Matthieu Boutier
- Re: Persistent loops when mixing rtgwg-enterprise… Fred Baker
- Re: Persistent loops when mixing rtgwg-enterprise… David Lamparter
- Re: Persistent loops when mixing rtgwg-enterprise… David Lamparter
- Re: Persistent loops when mixing rtgwg-enterprise… David Lamparter
- Re: Persistent loops when mixing rtgwg-enterprise… Matthieu Boutier
- Re: Persistent loops when mixing rtgwg-enterprise… David Lamparter
- Re: Persistent loops when mixing rtgwg-enterprise… David Lamparter
- Re: Persistent loops when mixing rtgwg-enterprise… Jen Linkova