Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-route-reflection-14

Nick Hilliard <nick@foobar.org> Mon, 09 October 2017 21:16 UTC

Return-Path: <nick@foobar.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46A9134218 for <idr@ietfa.amsl.com>; Mon, 9 Oct 2017 14:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 UYfycbNeBP2r for <idr@ietfa.amsl.com>; Mon, 9 Oct 2017 14:16:37 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40ABF132D51 for <idr@ietf.org>; Mon, 9 Oct 2017 14:16:36 -0700 (PDT)
X-Envelope-To: idr@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v99KG97J047735 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Oct 2017 21:16:10 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <59DBE72C.1060807@foobar.org>
Date: Mon, 09 Oct 2017 22:16:28 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.19 (Macintosh/20170908)
MIME-Version: 1.0
To: Robert Raszuk <robert@raszuk.net>
CC: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, idr wg <idr@ietf.org>, "ytti@ntt.net" <ytti@ntt.net>
References: <1F4BD63B-3273-469E-A3C6-4365B56724EA@juniper.net> <20171009081140.qram6b2ubl4y3isj@hanna.meerval.net> <CA+b+ERmVAA8eG3cm8++osKS4OmxiBZ6svhNPj8wC7gnQXWWYdg@mail.gmail.com> <20171009152051.GH34236@Vurt.local> <CA+b+ERnTAxra-G8xbtFAoovyCwpOySAuJx52vG3p5g7AdODK2Q@mail.gmail.com> <CAF3K5KtpvYkJM6U_Cw3pbCiMgQvwJOFdMoRGuzGMQFYHA8VLSA@mail.gmail.com> <CA+b+ER=xuh9vD7ksPUY-+WQnfduiQF=gL3=wMxK+p9rCO4s0_w@mail.gmail.com> <6062f554aa904352bc81c80040229d34@XCH-ALN-014.cisco.com> <CA+b+ER==6AKBO6BrcF__jNYmgJWbqjuTX=t213n6S_x8T=Mahg@mail.gmail.com>
In-Reply-To: <CA+b+ER==6AKBO6BrcF__jNYmgJWbqjuTX=t213n6S_x8T=Mahg@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8eQx0s44su-bXx0cwzdGar9Nd8A>
Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-route-reflection-14
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Oct 2017 21:16:39 -0000

Robert Raszuk wrote:
> So when you run (regular or ORR) best path on 1.1.1.1/24
> <http://1.1.1.1/24> you should have all three metrics 90, 100, 110 there
> to pick the best path. If next hop is not in IGP with or without
> recursion such path is invalid so we should not worry about it here. 

correct me if I'm wrong, but I don't think you're understanding what
Jakob is saying.

When you have multiple orr clients (BGP1 and BGP2 in Jakob's example),
their IGP view of the next-next-hops might be different from each other.
 This might happen if the NH address was anycasted in the IGP, for
example, causing the NNH to be resolved different on different bgp clients.

In this situation, the behaviour of the ORR client is not defined
clearly in the spec.  Because of the ambiguity, some implementations
appear to have steered clear of handling recursion because it can cause
non deterministic resolution problems.

Nick