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

"Acee Lindem (acee)" <acee@cisco.com> Wed, 26 July 2017 00:16 UTC

Return-Path: <acee@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 21DD5132148 for <rtgwg@ietfa.amsl.com>; Tue, 25 Jul 2017 17:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 xwn0zWJ_OWWr for <rtgwg@ietfa.amsl.com>; Tue, 25 Jul 2017 17:16:19 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5256132146 for <rtgwg@ietf.org>; Tue, 25 Jul 2017 17:16:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6122; q=dns/txt; s=iport; t=1501028179; x=1502237779; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vdCpmkmaOu5nPSiN3qP+yt6gsxu4r0ghOMBhNirBDLQ=; b=U4yF+1V5uk1q5K5S2fLsfGJe46AHWtRqAagspCRg3AH7EKXvI1S+xr9G GmlhCHfsA0NexbZt5RkMSSFbFkL26RW7pCo21ojMQ32nhl0I11ZiIhBoH PSSeCG+mDhU/tOtmnK4EddGY7IkGeDvci9wXCIkDmWi971gucX8g8NVHk 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CTAQCx3ndZ/5xdJa1dGQEBAQEBAQEBAQEBBwEBAQEBg1pkgRQHtXSCEiENhEpPAhqDHkEWAQIBAQEBAQEBayiFGQIBAwEBIRE6CxACAQgODAImAgICJQsVEAIEAQ0Fii8QsBmCJotLAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4IdhS6DJIgGgmEFn1cCh02MUJI5lWgBJggpgQp3FR8qhUuBTnaIJ4EOAQEB
X-IronPort-AV: E=Sophos;i="5.40,413,1496102400"; d="scan'208";a="460672116"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2017 00:16:18 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6Q0GIlQ023537 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Jul 2017 00:16:18 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Jul 2017 20:16:17 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 25 Jul 2017 20:16:17 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: David Lamparter <equinox@diac24.net>, "rtgwg@ietf.org" <rtgwg@ietf.org>
CC: Anton Smirnov <as@cisco.com>
Subject: Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing
Thread-Topic: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing
Thread-Index: AQHTALSTB7SyiLHxWE2IPBWcbp9an6JlR1MA
Date: Wed, 26 Jul 2017 00:16:17 +0000
Message-ID: <D59D5469.BA187%acee@cisco.com>
References: <20170719172913.GU773745@eidolon>
In-Reply-To: <20170719172913.GU773745@eidolon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F2CD13169CD6D048AFAC34976CCF3C00@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/ch-wFkN_p6oAyNU3bVE3POjvZQE>
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: Wed, 26 Jul 2017 00:16:22 -0000

Hi David, 

I must admit that I had always thought that the source-routing paradigm in
draft-troan-homenet-sadr-01.txt was backward with the destination address
Longest Prefix Match (LPM) being done prior to the source address lookup.
Rather I think if were going to standardize in the RTG WG, it should be
the FIB organization described in section 3 of
draft-ietf-rtgwg-enterprise-pa-multihoming-01.txt. Note that doing the
source address lookup first  maps directly to the PA multi-homing
use-case. 

Thanks,
Acee 


On 7/19/17, 1:29 PM, "rtgwg on behalf of David Lamparter"
<rtgwg-bounces@ietf.org on behalf of equinox@diac24.net> 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-rou
>ting.pdf
>which argues the implementation specifics and correctness of this
>translation in its full mathematical gore ;)
>
>_______________________________________________
>rtgwg mailing list
>rtgwg@ietf.org
>https://www.ietf.org/mailman/listinfo/rtgwg