Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-route-reflection-14
Adam Chappell <adam.chappell@gmail.com> Mon, 09 October 2017 19:15 UTC
Return-Path: <adam.chappell@gmail.com>
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 5299913453A for <idr@ietfa.amsl.com>; Mon, 9 Oct 2017 12:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 q4PlejFMXEHQ for <idr@ietfa.amsl.com>; Mon, 9 Oct 2017 12:15:55 -0700 (PDT)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF67F1286C7 for <idr@ietf.org>; Mon, 9 Oct 2017 12:15:55 -0700 (PDT)
Received: by mail-it0-x22f.google.com with SMTP id l196so1987865itl.4 for <idr@ietf.org>; Mon, 09 Oct 2017 12:15:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xs7/nhU+BLi6wgbe8KvA2zTViH1mGrjjy01cm44Mwto=; b=OhvIgl0UGeWfb8z6BYBhLesC7q+AOLn55VN93nbhWoCkiq413ZFTVPKr9Mo7s/LIbN QTTTwrYoc+OqBXPDlbBR7egYVsu1zhbfjTvXBOBjxQhQ/XxXJBgtheQavrs+QKPbmjvz 2qEaNwCBg6FQCAReRZ6DFezQFgy4TvnMfblWOqrI/hCjEbDDAVCxT/LMNCWdIHwbLW/Z p+Qwyf3lcROxZH7EcmMdcpUCHleIV8FCuQPNSqpVhFTzqPpfLJGns/L+R2NnvPqMONmD gLOo6R/KLQPpjSUFdYmFFVUjSMPewmmY06HN4YvTRJ41RNTpdKy2+bmdYXEB4h9E0g96 nXdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xs7/nhU+BLi6wgbe8KvA2zTViH1mGrjjy01cm44Mwto=; b=PNV6K54v89LFDihNJ4YtTw2OcV0B6FQGrdcOBm0gtZxAqEoO6vRaK4nJ9QWyb7XoXR q0Z2Tq4MDKifosbTkbgFkbpasa0Cq1K0ryA6XpI/W/DD6t7OFABwO207sWozM5ATapHK 9u7OiQEcnt7KEMH2eUN5ylzpIHYSHUrEEU+6VfNNWJ406iZb01NCuQ9hMItLYTNb87X9 hGvb8vaHOdbWvw9lzy8M20tLrAIwoQom5f+Hkncq617QfL1yL/U02lXLRTePjGBa6Q9C lKuJ8CRW9SA1VpwNup+nK8UQVpUJtFquO1AcXrEjmAzVHl+wcsFpMWT8ZvkpDTudkFip BUpA==
X-Gm-Message-State: AMCzsaXYGA0xxkiLt378m1XZ0FZyf736M/tfHELyPmHpNL4LR8sGEuOj uPOV1I/HN6a9gjP4Juc1lKF4RP3JgbKU7rjAxh9ENEaF
X-Google-Smtp-Source: AOwi7QDnJuZgtHGAOr0LVvetLB8iXheUUEosF/6+OV7ukAe9liMaaDpF0C52t/laMcFleWgw94GsOAov1CoBgioTzlc=
X-Received: by 10.36.241.66 with SMTP id q2mr15495503iti.57.1507576554908; Mon, 09 Oct 2017 12:15:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.38.76 with HTTP; Mon, 9 Oct 2017 12:15:54 -0700 (PDT)
In-Reply-To: <CA+b+ERnTAxra-G8xbtFAoovyCwpOySAuJx52vG3p5g7AdODK2Q@mail.gmail.com>
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>
From: Adam Chappell <adam.chappell@gmail.com>
Date: Mon, 09 Oct 2017 21:15:54 +0200
Message-ID: <CAF3K5KtpvYkJM6U_Cw3pbCiMgQvwJOFdMoRGuzGMQFYHA8VLSA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Job Snijders <job@ntt.net>, idr wg <idr@ietf.org>, ytti@ntt.net
Content-Type: multipart/alternative; boundary="f403045fc0c206efa4055b220552"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BiYEbCZBdaooq6iMV7eZNW5Sh14>
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 19:15:58 -0000
Perhaps resolve/recurse as far as is possible/feasible and eventually fall back to max metric for a comparison in absence of anything else? Would certainly be principle of least astonishment in Job's case where an NLRI was simply omitted because the NH wasn't comparable. Optimal should be better, but not really any worse than classic, right? :) I don't think the recursion needs to be mandated though, much as the supported IGP protocols aren't mandated. It is putting the the ORR's Loc-RIB and selection policy into play which is what we'd avoided. On 9 October 2017 at 17:56, Robert Raszuk <robert@raszuk.net> wrote: > Job, > > > I think you are overestimating the impact of the proposed change. > > It would be helpful to hear from vendors how propagating to BGP an IGP > metric in the scenario > of N-level of recursion is easy or hard for them. > > > The fact that they released software without this capacity, implies > draft has ambiguity > > which causes operational inconsistency in best path algortihm (with > possibility for blackholing). > > Ok in such a case I don't see any problem of addressing the ambiguity with > the below sentence > added to section 4.1: > > Current text: > > "In this document we refer to optimal as the decision made during best > path selection at the IGP metric to BGP next hop comparison step." > > > New text: > > > "In this document we refer to optimal as the decision made during best > path selection at the IGP metric to BGP next hop comparison step. > > > In the scenario of BGP route's next hop resolving via N level recursion > the metric used for given path's comparison (provided implementation > supports it) should be equal to IGP metric of the final IGP route the > N level recursion resolves via. Similarly next hop reachability > validation > should be based on the state of such IGP route." > > Would WG and yourself be fine with this change ? > > The only problem is what to do if implementation can not propagate such > metric .. should the N-level recursive path be less preferred and assumed > having max metric in such cases ? > > Thx, > R. > > > On Mon, Oct 9, 2017 at 5:20 PM, Job Snijders <job@ntt.net> wrote: > >> On Mon, Oct 09, 2017 at 04:25:27PM +0200, Robert Raszuk wrote: >> > 1. Are you using the same implementation on both client and RR with >> > ORR ? >> >> Sometimes. >> >> > The problem usually is related here not to BGP implementation but to >> > RIB. Not all RIBs reference a metric of N-level recursive route to >> > the child. >> >> No, this is an optimal route reflection specific challenge. A vendor >> read the document, and didn't consider the case where a BGP next-hop >> may recurse through another BGP route to an IGP route. This is a simple >> oversight that probably would not have happened if the document >> specified how to consider route recursion from via one or more >> protocols. >> >> > When BGP registers its next hop with RIB for state/metric tracking >> > (assuming that implementation even does that rathere then a single >> > call to RIB) the metric it get's is the one attached to the specific >> > next hop which is being queried. >> > >> > Bottom line is that mandating suggested text to the current spec may >> > very likely result in number of implementations to become >> > non-compliant and what is worse the proper fix may require in some >> > cases complete RIB redesign which is far from BGP and IDR area. >> >> I think you are overestimating the impact of the proposed change. >> >> > For your valid case I would suggest perhaps to solve it via >> > draft-ietf-idr-bgp-nh-cost-02. >> > >> > If you find vendors buying into your case we will be more then happy >> > to update the NH cost draft and progress it. >> >> I disagree, draft-ietf-idr-bgp-optimal-route-reflection is the right >> place for this. >> >> The specific vendor I was referring to told us that they'll change their >> behaviour: they'll fully recurse the BGP routes at route reflector, >> before chosing which route to reflect. The fact that they released >> software without this capacity, implies draft has ambiguity which causes >> operational inconsistency in best path algortihm (with possibility for >> blackholing). >> >> Kind regards, >> >> Job >> > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > -- -- Adam.
- [Idr] WGLC for draft-ietf-idr-bgp-optimal-route-r… John Scudder
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Robert Raszuk
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… bruno.decraene
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Job Snijders
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Erik.Aman
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Robert Raszuk
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Job Snijders
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Robert Raszuk
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Job Snijders
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Adam Chappell
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Robert Raszuk
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Jakob Heitz (jheitz)
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Robert Raszuk
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Jakob Heitz (jheitz)
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Nick Hilliard
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Robert Raszuk
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Robert Raszuk
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Jakob Heitz (jheitz)
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… John G. Scudder
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… John G. Scudder
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Nick Hilliard
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Rajiv Asati (rajiva)
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Serpil Bayraktar (serpil)
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Manish Bhardwaj (manbhard)
- [Idr] IPR in draft-ietf-idr-bgp-optimal-route-ref… John G. Scudder
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… Kevin F Wang
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Keyur Patel
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… Robert Raszuk
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… Serpil Bayraktar (serpil)
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… John Scudder
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… Robert Raszuk
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Jeff Tantsura
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Acee Lindem (acee)
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… Randy Bush
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… Christian Cassar
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… Randy Bush
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… Robert Raszuk
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… Randy Bush
- Re: [Idr] IPR in draft-ietf-idr-bgp-optimal-route… Randy Bush
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… John G. Scudder
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Robert Raszuk
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Job Snijders
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… John G. Scudder
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Randy Bush
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… Robert Raszuk
- Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-rou… John G. Scudder