Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing

Matthieu Boutier <boutier@irif.fr> Thu, 27 July 2017 16:41 UTC

Return-Path: <boutier@irif.fr>
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 CFF76131FF7 for <rtgwg@ietfa.amsl.com>; Thu, 27 Jul 2017 09:41:34 -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 AusL8T66wkfs for <rtgwg@ietfa.amsl.com>; Thu, 27 Jul 2017 09:41:32 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 F3EDD131CF8 for <rtgwg@ietf.org>; Thu, 27 Jul 2017 09:41:31 -0700 (PDT)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v6RGfOTc013322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Jul 2017 18:41:24 +0200
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v6RGfNPF004946; Thu, 27 Jul 2017 18:41:23 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B17BCEB2CC; Thu, 27 Jul 2017 18:41:23 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id FrgSpJPs3znl; Thu, 27 Jul 2017 18:41:22 +0200 (CEST)
Received: from host-37-32.sg.lan (unknown [172.23.37.32]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 637D9EB2F8; Thu, 27 Jul 2017 18:41:22 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing
From: Matthieu Boutier <boutier@irif.fr>
In-Reply-To: <MWHPR05MB282950D357E8B6597685E828A9B90@MWHPR05MB2829.namprd05.prod.outlook.com>
Date: Thu, 27 Jul 2017 18:41:22 +0200
Cc: David Lamparter <equinox@diac24.net>, "rtgwg@ietf.org" <rtgwg@ietf.org>, Anton Smirnov <as@cisco.com>, Jen Linkova <furry@google.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BF40E52-63D7-4B04-815A-64F863241010@irif.fr>
References: <20170719172913.GU773745@eidolon> <20170720074132.GW773745@eidolon> <MWHPR05MB282950D357E8B6597685E828A9B90@MWHPR05MB2829.namprd05.prod.outlook.com>
To: Chris Bowers <cbowers@juniper.net>
X-Mailer: Apple Mail (2.3124)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 27 Jul 2017 18:41:24 +0200 (CEST)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 27 Jul 2017 18:41:24 +0200 (CEST)
X-Miltered: at korolev with ID 597A17B4.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 597A17B3.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 597A17B4.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/<boutier@irif.fr>
X-j-chkmail-Enveloppe: 597A17B3.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<boutier@irif.fr>
X-j-chkmail-Score: MSGID : 597A17B4.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 597A17B3.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/6ujo-imnLPCf0_fttXo0XrJ4kRM>
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, 27 Jul 2017 16:41:35 -0000

Hi,

> Does this generalization of rule #3 resolve the discrepancy ?

It's not enough, because if you have overlapping source prefix, you'll
need to change the following.

   1.  If the source address of the packet matches one of the source
       prefixes, then look up the destination address of the packet in
       the corresponding source-prefix-scoped forwarding table to
       determine the next-hop for the packet.

   2.  If the source address of the packet does NOT match one of the
       source prefixes, then look up the destination address of the
       packet in unscoped forwarding table to determine the next-hop for
       the packet.

Basically, you'll have to replace these two points by only one saying:
"order your entries by prefix specificity (longest match first)".

And… I have the feeling that the routing part is overcomplicated.  It
should be as simple as: "put a SADR routing protocol on your network".
And you're done.

The draft discusses a lot about how to progressively deploy SADR in the
network.  This should be put in a "progressive deployment" section, which
would essentially say:

  - have a connected SADR backbone including the edge routers,

  - announce a default route from the backbone to attract packets.

It's the role of the routing protocol to be backward compatible with
the legacy (non-SADR) version.

Also, about routing tables, section 3 clearly shows that if a packet
matches two routes, it should follow the one with the most specific
destination.  All the section 3 is about what to do if we don't have
native destination-first SADR tables but only policy routing.  I
believe it's the role of the routing protocol's implementation to
deal with that (that's what we do since 2013).  Then section 3 could
probably just be a reference to David's draft, since it only concerns
SADR/dst-src/source-specific/etc. routing protocol implementations.

Matthieu