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

Dan Romascanu via Datatracker <noreply@ietf.org> Thu, 03 December 2020 10:42 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8C23A0E5D; Thu, 3 Dec 2020 02:42:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dan Romascanu via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org, idr@ietf.org, dromasca@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160699217439.12968.15167518753403970194@ietfa.amsl.com>
Reply-To: Dan Romascanu <dromasca@gmail.com>
Date: Thu, 03 Dec 2020 02:42:54 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zddpCgW1FxSrBcujyDTcfabRNXw>
Subject: [Idr] Opsdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 03 Dec 2020 10:42:55 -0000

Reviewer: Dan Romascanu
Review result: Has Issues

This document defines an extension to BGP route reflectors by which BGP route
selection is modified in order to choose the best path for their clients
standpoint, rather than from the route reflectors standpoint. The Introduction
includes text that describes in what situations these extensions are applicable.

>From the operators perspective, Section 4 and Section 6 includes important
recommendations for SP operators, as well as deployment considerations.

The document is Almost Ready from an OPS perspective. I would suggest however
to clarify the following two issues before approval:

1. In Section 3:

> Both modifications rely upon all route reflectors learning all paths
   that are eligible for consideration.  In order to satisfy this
   requirement, path diversity enhancing mechanisms such as add-path may
   need to be deployed between route reflectors.

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?

2. In Section 3.1:

> In addition to the change specified in [RFC4456] section 9, the BGP
   Decision Process Tie Breaking rules ([RFC4271] Sect.  9.1.2.2) are
   modified as follows.

Should not the document UPDATE RFC 4271 (when approved)?