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

Alvaro Retana <> Mon, 24 May 2021 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66CD33A2D82; Mon, 24 May 2021 09:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vf-hW9xaybXF; Mon, 24 May 2021 09:07:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8FDAC3A2D7A; Mon, 24 May 2021 09:07:12 -0700 (PDT)
Received: by with SMTP id lz27so42630082ejb.11; Mon, 24 May 2021 09:07:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=DAdwy/T9jnmWwDWwkRWkVntXe5PrH4FWubsFmhES+ZE=; b=sEGmIa75lbv2Mb/UAAUnOOBbodXyh1BrTcYX/zRwZ+xbzsmJ0YtGOM6pHnLsUwxXwT CCqh/OJIcyEpkO5+VtRyqsQgXAoJibwMOco5EvoHVgWNQScoYX6Tv2+iuSOV8hvAjipc wx95WfycsPicZ0dyGbMVc4XAdDmEE3eaSVYtwcW8fnLOCXW+i6W48bBx8hx89FX/EzAz 9lia1YylMIzyhvVj3M8ulodoDmwyNtMDhRROJ5K70Jh969a1w+SX201Kw9VEp0UJtO4b jnh7J8PgLkuIKVGIjyNRn3y3Q3LF3H1APXnqiDWEVAnHpqQYR2YxyReDGVO79GPMFGEC yhBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=DAdwy/T9jnmWwDWwkRWkVntXe5PrH4FWubsFmhES+ZE=; b=PafNsQgV1wWzRK8jqo3/NIXUH1Pd7GmzhOpB2HbzmKPoAYSBmuQKJ1jkxiMTzaBIrx PcWfdR4F5onsLrUTlORK2E/bchunWETF7T1q6yMnmWsTX2qIPg47XAAYQ/2J0R2o/WIl rO7XnV153nYC8zMht4VmGG1TFlOSkpAXulMP1lwRtkV5YW6xLxvcPnM03vdAVtGeb42y QPA5lfbFRYosGdrDE0zZqEgN0zJ+FqQHpU63Nl0AyARP0Q17blXvay3zlTB2Vqd6NaRg 82LB+gFbMSiSu28QoTjy2QQqUL0I9z0OV47isFAgPB0xz9HCw7cDEL/rqRPAEIes7yAK P9RQ==
X-Gm-Message-State: AOAM531LNGs4U03hG5+6G8JDmplR11AF6Pz51ei1MwHlBw+0NlxcKK14 scXLwLYHhhYeZFkiniYoi8P1yKi8ggx+K96IRNc=
X-Google-Smtp-Source: ABdhPJztDD1g77E1mwHr6uKDgVTpwQleimu1rBYhe04A7f2lQtP5+Ly8iHqjcOAz5bNGTnCfTl1ZtH49X0wVVNDGA34=
X-Received: by 2002:a17:906:4714:: with SMTP id y20mr11956847ejq.235.1621872428411; Mon, 24 May 2021 09:07:08 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 24 May 2021 09:07:07 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <879_1620810145_609B99A1_879_373_1_53C29892C857584299CBF5D05346208A4CD9C11E@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <>
MIME-Version: 1.0
Date: Mon, 24 May 2021 09:07:07 -0700
Message-ID: <>
To: Robert Raszuk <>
Cc: Susan Hares <>, "" <>, "" <>, Bruno Decraene <>, "idr@ietf. org" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 May 2021 16:07:15 -0000

On May 22, 2021 at 7:43:42 AM, Robert Raszuk wrote:



> 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.

All this is fine -- I don't disagree with anything.  My point is not
about selecting the peers, or how an implementation may group peers or

My point is about the precision requirements mentioned in the
abstract.  In the general case, assigning an IGP location per-peer is
more precise than doing it per group (again, regardless of how that
group was determined).

I think we're talking about related but different things. :-)

> > 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.

Read the rest of my comments... ;-)

Sure, that's ok.  At least please mention an example.