Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22

Robert Raszuk <robert@raszuk.net> Sat, 22 May 2021 11:43 UTC

Return-Path: <robert@raszuk.net>
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 273C63A21C7 for <idr@ietfa.amsl.com>; Sat, 22 May 2021 04:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 miFi_w3yCOb3 for <idr@ietfa.amsl.com>; Sat, 22 May 2021 04:43:49 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 039C23A21CA for <idr@ietf.org>; Sat, 22 May 2021 04:43:48 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id w15so27097484ljo.10 for <idr@ietf.org>; Sat, 22 May 2021 04:43:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aPxEEIWIU/INaj24KJGAkEtWvRcMC91CVXyu9an/yCM=; b=alVBvABK+kpT2psOwWS/LIApW4/Nvcer6Yq7ZY87MOYdkoUL90GBDu66xvKCkbCxS/ BULqR7vBBtcBjYmKAImCszpdls4JpGa88FzzXCkjlAbIxadzpEMQtU43hhVcN5UK7OEf jTWNVfyG97pFqEUNLnB5lJyoaLmi5zL1zHORf1hOSGleXPuNFFTHUCxmJXt08Fbgkjwo HxxGKiH+sLbX9/IvflUFY2ksZTUNvoliI+XXwjWEO+3zZstw4lOdlSJIyBg8kFQ4lFgk KbrsyvrKWxVaDFoNCypB6xiXMimcb4w1PIPonY1TFQqzRP35QvDesaAOGg8QNMuVjghu +dqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aPxEEIWIU/INaj24KJGAkEtWvRcMC91CVXyu9an/yCM=; b=PdnS4SVEknFiRfgXEyKc04TByeziaKUFlxqFBPZSmsUPWJoWoqvNRR2ycctVnSEN9/ vQzKPojIuYOXnDo3FZMlHLqdXUKeLBGm48qdUf+DBsLXDnNbwNX9q98fBpJoDuGZez5K m9GVa1ffyUppPoNdtH9BStXY4Fub90cQFwglnMFvsEu+yKmSvZ0r61Is+QRrG/lnHqVZ pU2y60iF1N0JqozUtUlTZAZE/OLPnVTlblpBELicoKOeLe7wH1Yoms9besN8L1AREvwt Xiky226u0KDOYcF6A6NooDcEvbRGYbFdcPbbbZCPskPLVwsxnRgqzNmP6pSTWhKZuXev RiKQ==
X-Gm-Message-State: AOAM533bw6W6ItkA6odB9G/Ac2L8DoS4dWBU5CmQdSgumOsEhalzLVi0 iBfOp1eLgg/7wQoVPXBaQX2PNre7EIdQKbfHsMuasw==
X-Google-Smtp-Source: ABdhPJwhUqzyR0zjClqEiNyHwETGEl6t47j2d7v/XEp1Jenm9cIK02L7uW5UgcFtURNZGNepgEvFhMAi2JPCVYF9Qgw=
X-Received: by 2002:a2e:9ece:: with SMTP id h14mr10345838ljk.199.1621683822084; Sat, 22 May 2021 04:43:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESswK38j+PXQAJ4rDZSNSN-ZjutUSE=fSO0QvoYS3sLRgfA@mail.gmail.com> <879_1620810145_609B99A1_879_373_1_53C29892C857584299CBF5D05346208A4CD9C11E@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAMMESsyv9ohN6yGst8ovvVUXE7YhSn=X0JiDATFrpWa7UyfYWg@mail.gmail.com>
In-Reply-To: <CAMMESsyv9ohN6yGst8ovvVUXE7YhSn=X0JiDATFrpWa7UyfYWg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 22 May 2021 13:43:31 +0200
Message-ID: <CAOj+MMEM5FnwSztFvz2xeHfEr4pp1xgWSSobu+k00CbgRg_VXg@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: "draft-ietf-idr-bgp-optimal-route-reflection@ietf.org" <draft-ietf-idr-bgp-optimal-route-reflection@ietf.org>, Bruno Decraene <bruno.decraene@orange.com>, Susan Hares <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000027579a05c2e9b02b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mkOesY3YZMpp79IvavSPFgEWodU>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 22 May 2021 11:43:54 -0000

Hi Alvaro,

Few comments on your comments ....

What I meant is: when/why would an operator select to anchor the
> logical location based on a peer...or peer-group...   I understand the
> load considerations, but I'm looking for advantages/disadvantages
> related to the point of view (assuming the platform can handle either
> choice).  As you say in the abstract, the precision requirements are
> different -- but they are not explained.  BTW, the new text in §6
> doesn't address this question either.
>
> I'm looking for something along the lines of:
>
>    Selecting to configure an IGP location per peer has the highest
> precision
>    as each peer can be associated with their ideal IGP location.  However,
>    doing so may have an impact on the performance (as explained above).
> Using
>    an IGP location per peer-group implies a loss of precision, but reduces
> the
>    impact on the performance of the route reflector.  If peer-groups are
>    configured taking into account the location of the route reflector
> clients,
>    and not just the policy, the impact of considering a non-optimal
> individual
>    IGP location for each peer can be reduced.  Similarly, if an IGP
> location
>    is selected for the whole routing instance...
>


Well per peer-group or per peer was something added to the draft more for
convenience than anything else. If we were to be precise dynamic update
groups should also be listed.

The point however is that selecting a set of peers which may share IGP
proximity from the perspective of path selection is essentially orthogonal
to all of the above.

I am not sure if this is too late in the process but I would suggest to
just state in the draft "set of peers" and how they are grouped in the
given implementation is out of scope.

For example I may group peers just based on the fact that I am doing  some
policy on IBGP paths (say for vpnv4 routes as example). In such a case this
may be completely orthogonal to ORR objective.

So some smart implementations may build automated grouping and all operator
needs to enter is delta IGP metric between peers which are allowed to get
auto grouped.


How is a "node in the IGP topology" identified?
>
> I'm not asking how to configure it (you declare it out of scope later
> on -- which is ok).  I'm asking what it is?  How is it represented?  I
> guess that a "node in the IGP topology" would be identified by it's
> router-id/system-id -- is that the expectation?
>


Is this really needed ?

The reason why this is left out was to avoid limitations for the
implementation.

So if we say router-id we should also list nsap which router-id is only
part of. Further if we are to say this we perhaps should also specify if we
are talking about base topology or some other topology in case of mtr. And
then some may consider only to compute IGP metrics for next hops reachable
via specific flex algo topology as for some applications it could be
completely irrelevant what base topology says.

Many thx,
R.