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 ;)