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

Alvaro Retana <> Fri, 21 May 2021 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE8A23A1BAA; Fri, 21 May 2021 11:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 IFBe4afnErJA; Fri, 21 May 2021 11:58:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 045CD3A1BBA; Fri, 21 May 2021 11:58:21 -0700 (PDT)
Received: by with SMTP id t3so24410398edc.7; Fri, 21 May 2021 11:58:21 -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=DHjHycggkXjQlJmheqFvj4oFxrJY7vJNkdyGtPwF1zc=; b=u4PyPPCY2uOpJzsv6I5IGbZbC91Qu9X2qivGXNUKb1gMX9VTpMA0zvZUM+qdtfOIZ0 548pYKK8nZyVEax7jYK5I70yGEOdHSoTe/hZ3+MJr5IZOCe4dLaossOFZrXLRBa3EWni NTK1q/2HXCeUn+/aimWEcE+CrIQFi+wKfye+ViJFyFPBJO1wwSM6ZKIgD6Rb5VHD0X8h jHZ4g5twPtAQIAHUEs+Sq/CJK4UDrxn0bUkpLK0Ldi25pHgGZwc2c1H9RiOhZdRVSGkE DNZru+D0woLZYLz4DnTFo/XEtdWl1lNnz4f2hAfxya4IdyOZQYnXc6WkHKekCPfcNb9v qKZw==
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=DHjHycggkXjQlJmheqFvj4oFxrJY7vJNkdyGtPwF1zc=; b=WrM/1VeNZnAurEBIQ2akLNROSrmVYWwdoSSoyzTgzCxBdmV5aApAJSEfkNf4QyRJ6r h2+z5hAVeQoU+qsCPnWrcZDCwKnQi+iOTfob+zX1QYj4pEXBEVCsOcsHCGSfJ5pwiMM0 NGBoiNpsnAQ6oe+vWLY+HqTJ9mSjSRlmZ8/NzPDt497xkYtBTRwtSMW++VQbFfkCggD7 7klAvvMwMJ8svh6n1K7NfUKZc4NiIyaxaE6ZtuN0MDjBxonCvhIbCCJp7eOr1pE575pR gJOtEN+X/yt2/FzmR6EHjR8so9kqM3NvzPVFjx45kjwbdhaHSHpkIXZ3QQXvvYJLTFx6 s7YQ==
X-Gm-Message-State: AOAM531quUnUh2qKBS1UGE4SL/Hux13rfAqKqRs4DkOcD2SyuXKq7iil EPjJSIGotyNI5OATkxmDQ47k6cs61mz3/pKwGLTyjU2d
X-Google-Smtp-Source: ABdhPJwDzUnpKClI8iKAZ7obRXPhu/ypwFgSt03nsfYHMtAc1tigXzAVp4eMUiZ2tYhMeC0xnDupifKKl4XyvYbQmjw=
X-Received: by 2002:aa7:cf03:: with SMTP id a3mr12597820edy.314.1621623498976; Fri, 21 May 2021 11:58:18 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 21 May 2021 11:58:18 -0700
From: Alvaro Retana <>
In-Reply-To: <879_1620810145_609B99A1_879_373_1_53C29892C857584299CBF5D05346208A4CD9C11E@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <> <879_1620810145_609B99A1_879_373_1_53C29892C857584299CBF5D05346208A4CD9C11E@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Date: Fri, 21 May 2021 11:58:18 -0700
Message-ID: <>
To: "" <>,
Cc: Susan Hares <>, "" <>, IDR List <>
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: Fri, 21 May 2021 18:58:36 -0000

On May 12, 2021 at 5:02:25 AM, wrote:



I'm fine with the changes (or no changes) resulting from the points
I'm not commenting on.  Thanks for the detail in the discussion!

I have a couple of comments left.  I think these can be addressed
along with any other from the IETF LC, so I'm starting it.



> > (2) Deployment Considerations. §6 says that a compliant
> > implementation is one that allows the operator to configure "a logical
> > location from which the best path will be computed, on the basis of
> > either a peer, a peer group, or an entire routing instance". Please
> > spend some time providing guidance so an operator can decide what best
> > works for their network. [I pointed below to other places there
> > operational guidance would be ideal.]
> OK. What about the following text:
> Calculating routes for different IGP locations requires multiple SPF
> calculations and multiple (subsets of) BGP Decision Processes, which
> requires more computing resources. This document allows for different
> granularity such as one Decision Process per route reflector, per group of
> peers or per peer. A more fine grained granularity may translate into more
> optimal hot potato routing at the cost of more computing power. The ability
> to run fine grained computations depends on the platform/hardware deployed,
> the number of peers, the number of BGP routes and the size of the IGP
> topology. In essence, sizing considerations are similar to the deployments
> of BGP Route Reflector.

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

> > [major] "IGP location" Before I forget -- please clearly define (not
> > in the Abstract of course) what an "IGP location" is.
> Added in section "Modifications to BGP Route Selection"
> NEW:
> The core of this solution is the ability for an operator to specify the IGP
> location for which the route reflector calculates interior cost for the
> NEXT_HOP. The IGP location is defined as a node in the IGP topology and may
> be configured on a per route reflector basis, per peer/update group basis,
> or per peer basis.

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?

Later you mentioned: "Configuration itself is out of scope (in
particular how the location is indicated as it could be via router ID,
loopback @, IS-IS ISO NET...)."   Can you at least provide examples?
Maybe mention that it is protocol specific.

Not specifying how the node is identified seems like it could result
in different implementations doing different things: for example, some
allowing a loopback but others requiring the router-id.  The problem
is that this could result in operational complexity (assuming that
different implementations are used in the network and that the
router-id is not the specific loopback)...  I'm just saying this out
loud for the record because it makes me feel uncomfortable, but we can
leave it out of scope.

> > [major] "one or more backup locations SHOULD be allowed to be
> > specified for redundancy"
> >
> > (1) §3.1 says that the "configuration of the IGP location is outside
> > of the scope of this document". If that is true, then you can't
> > recommend anything related to the configuration.
> Configuration itself is out of scope (in particular how the location is
> indicated as it could be via router ID, loopback @, IS-IS ISO NET...).
> In all cases, one IGP location needs to be provisioned. Providing a backup
> one seem like the same functional work. I don't see why the document could
> talk about the former but not about the latter.
> IOW,
> - §3 says "an operator to specify the IGP location" and this seems ok.
> - §4.1 says "one or more backup locations SHOULD be allowed to be specified
> for redundancy" and this seem non ok although the term used seem similar
> (IGP location, specify).
> Could you please clarify the point and if possible suggest a path for
> clarification.

The difference is in the use of normative language (SHOULD): if the
configuration is out of scope, then we shouldn't normatively recommend
anything.   s/SHOULD/should

> > (2) If there were "backup locations", how would they be used?
> As backup for redundancy. I.e., used when the nominal failed and hence not
> in the network topology anymore.

Related to the guidance about indicating an IGP location per-peer,
etc.  The backup will not be as good as the primary location; sure
there are cases where the IGP location may be one of a pair of
redundant routers so there's not much change...but the general case
will probably result in the backups being increasingly less optimal.
Can you please add a sentence or two about this?

> Now whether or not the sentence is useful, is an open question:
> - on one hand you expressed that comparison between solutions are never good
> - on the other hand you expressed that guidance to the network operator is
> useful when multiple options are offered.

Just to be clear: comparison between ORR and other solutions is not
good.  If, when deploying ORR (this document), multiple options are
presented, then guidance (which is different than comparison) is good.

> > 425 7. Security Considerations
> NEW:
> This document does not introduce requirements for any new
> protection measures.

I'm ok with this change.

The downside is that now the Security Considerations section is very
short.  This is usually a red flag for the Sec ADs to look for more.
But besides adding a reference to rfc4272 I can't think of anything
else to add.