Re: [Idr] Opsdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21

Robert Raszuk <> Thu, 03 December 2020 13:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 759283A09F6 for <>; Thu, 3 Dec 2020 05:25:58 -0800 (PST)
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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vmrh7HqFhWx1 for <>; Thu, 3 Dec 2020 05:25:56 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DACA3A0A73 for <>; Thu, 3 Dec 2020 05:25:56 -0800 (PST)
Received: by with SMTP id r24so2680270lfm.8 for <>; Thu, 03 Dec 2020 05:25:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uXoHBtHKGhVz4sjKIyL5X7ApHse4i3yjzNm2T5W9aBA=; b=GTFa6qOun2/gkn2lFzHIH5vbjsrlJh7cMpdoUrBuDzELHGC0XeM/tndMbzw2gzWGv8 5inW84u8sAxHDMqR6nh8wZnGiksxMsehC4tkCzKbM12mzsAAyD2ykghjHti7xW1CqTQG LeClrh0hDaCPUf5FEmv/Gkzag8DA6+FD+vnVsKQ8gim2xyEt/iVEEBhvVrWIWIHBGl2S f9oK38BnQTUClk/f7CC+6/b9bBUTo9GIypGboi28k5lbQ7SkfhdJkPeUXpa/JQnlbRbs 6hy7pacLYdGXxhyQia2AeSkxUShMUPyFhSAOiORkJSlSh03X1cqLkaZoYBm9OdCiO5Z/ dyOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uXoHBtHKGhVz4sjKIyL5X7ApHse4i3yjzNm2T5W9aBA=; b=TTuFrMY45Kjk9v5e+Fr1kjCJlFjVQhjcyyZHJVFmzKcMtwA6oKNC3p6CLJVMmjAKtx HBvXgBZmpazPCgxpMQW4xjA9D0cUzpdKfGn0i9mSIAOmRe3qIRjSEq2eQz354wabIQb6 w5izslEBu8WBJibTMDd92ScZl3np3XQH9Pev9SXCZ+XpN9zbFPedD+4iFXQC/TuhQc2R rUxX3H5Uzk+BnVHss1dgi9khlkgGOTkVq5V/80uJknGbKuoFFm+M/mcFWWcOQAeP8yIg /PRM9elXFlf2fAHbEcEuV+UgXcGFTl03iAZyKxFxSbocorW6t4L8CMc/N6UkVnzb7C+k ku+Q==
X-Gm-Message-State: AOAM533kC8hVz9NBaPYZ/WqzjcH9i3zgQJIRBIYmgdmrw22DMRYcY8GP eMVly8ah4jTpB0k5aoP3s/Nl9PqUs8omKAawayPgqw==
X-Google-Smtp-Source: ABdhPJx1sC5tQi8/zb2cJxCFZOUz0mHSdWjdFts3ZboYU1UNlc8Mq+nOcTCUoZlB0HOCu72hDvxrXdFwKv2wfvTT8yE=
X-Received: by 2002:ac2:4831:: with SMTP id 17mr1369407lft.487.1607001953974; Thu, 03 Dec 2020 05:25:53 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Thu, 03 Dec 2020 14:25:43 +0100
Message-ID: <>
To: Dan Romascanu <>
Cc:,, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="0000000000009ed55905b58f4c06"
Archived-At: <>
Subject: Re: [Idr] Opsdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
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: Thu, 03 Dec 2020 13:25:59 -0000

Hi Dan,

Many thx for the review.

What are the consequences of this condition not being met? Are there any
> requirements or recommendations for operators in deployment? Some
> clarification
> text would be useful, did I miss something?

If the route reflector does not contain all eligible paths its decision may
be suboptimal in the sense of choosing the exit path still perhaps closer
in metric to logical placement of the RR (better then overall best). In
general if route reflectors even without this extension do not contain all
eligible paths for a given net and clients are connected without strict
topology awareness in basic IP hop by hop forwarding loops can easily

Original RR design was to place them in the data path (typically at or near
are boundaries or POP boundaries). With networks moving away from hop by
hop IP lookup to ingress-egress encapsulation that MUST condition or design
rule has been safely relaxed and RRs have moved to central positions.

BGP Optimal Route Reflection does not really place any additional burden on
the RR design as such. Contrary it allows to place RRs (perhaps running on
general compute x86 blades) anywhere in the network and still be able to
accomplish the optimal choice of path(s).

With all of that said I recognize that the current text may sound a bit too
scary :) I will talk with co-authors on rewording or removing it.

> 2. In Section 3.1:
> > In addition to the change specified in [RFC4456] section 9, the BGP
>    Decision Process Tie Breaking rules ([RFC4271] Sect. are
>    modified as follows.
> Should not the document UPDATE RFC 4271 (when approved)?

Well I don't think so. See this is not modification to BGP protocol as such
.. just an optional functional enhancement.

Just like original route reflection RFC 4456 did not update RFC4271 even
though it also modified section there.

Likewise Add-paths RFC 7911 did not update neither RFC4456 nor RFC4271, but
obviously does change best path selection when choosing more then best path
for advertisement irrespective of metric to the next hop.

Many thx,