Re: [Idr] [RTG-DIR] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection
Susan Hares <shares@ndzh.com> Wed, 22 June 2016 22:38 UTC
Return-Path: <shares@ndzh.com>
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 50ADC12DD36; Wed, 22 Jun 2016 15:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no
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 OFUi9c1O0fkd; Wed, 22 Jun 2016 15:38:18 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 4DA6112DD89; Wed, 22 Jun 2016 15:38:00 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.122.226;
Date: Wed, 22 Jun 2016 18:37:53 -0400
Message-ID: <x85u4mph41h4nw2g9vtef5av.1466635073288@email.android.com>
Importance: normal
From: Susan Hares <shares@ndzh.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "draft-ietf-idr-bgp-optimal-route-reflection.all@tools.ietf.org" <draft-ietf-idr-bgp-optimal-route-reflection.all@tools.ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_191302545369330"
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7f4ccXs3UDTFRcbpN_TS0eBRn3M>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] [RTG-DIR] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 22 Jun 2016 22:38:20 -0000
Daniele: Thank you for review. The authors will get back to you with their changes. Sue Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone-------- Original message --------From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Date: 6/22/2016 11:57 AM (GMT-05:00) To: draft-ietf-idr-bgp-optimal-route-reflection.all@tools.ietf.org Cc: rtg-dir@ietf.org, idr@ietf.org Subject: [RTG-DIR] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection Hello, I am the Routing Area Directorate member that was assigned the QA review of draft-ietf-idr-bgp-optimal-route-reflection. If you’re not familiar with the QA review process please see: https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa BR Daniele - General comment: The draft is understandable and does not require any major modification in addition to the minor edits and clarifications suggested below. My concern, which is something the working group probably already discussed, is about the complexity and usefulness of the idea. The goal of draft is: “ The core of this solution is the ability for an operator to specify on a per route reflector basis or per peer/update group basis or per peer basis the virtual IGP location placement of the route reflector. This enables having a given group of clients receive routes with optimal distance to the next hops from the position of the configured virtual IGP location. This also provides for freedom of route reflector location and allows transient or permanent migration of such network control plane function to optimal location.” But I understand that there is a number of workarounds and that different paths are already used for redundancy reasons, hence my questions is: is it worth defining a new solution? Is the usage of the actual mechanisms so disoptimized to require these changes? How many possible paths are there between the client and the AS border node? - Abstract “ This document proposes a solution for BGP route reflectors to allow them to choose the best path their clients would have chosen under the same conditions, without requiring further state or any new features to be placed on the clients” This is really hard to read. Maybe it could be improved stating what is the problem and what the solution is. You could copy a couple of sentences from section 1.1. which is much clear. - Introduction: “ In some situations, this method suffers from non-optimal path selection”. Which path? The one used to forward the packets? The one used to redistribute the route? Or? --- In a number of occurrences acronyms are not explained at first usage, e.g. POP, L3VPN, 6PE… --- Another general comment: I like the rich intro full of details on the problem statement, the existing solutions and the proposed one. However I’m struggling to understand how an implementation could be declared to be compliant to this ID. The only thing I see is “the implementation MUST NOT prevent reflecting more than one path” and an analog requirement which is “the route reflector MUST reflect N optimal paths”. I would have expected this to be an amendment to the existing RFC that states that a single path can be reflected. ---
- Re: [Idr] RTG Dir QA review of draft-ietf-idr-bgp… Jakob Heitz (jheitz)
- Re: [Idr] RTG Dir QA review of draft-ietf-idr-bgp… Daniele Ceccarelli
- Re: [Idr] [RTG-DIR] RTG Dir QA review of draft-ie… Susan Hares
- Re: [Idr] RTG Dir QA review of draft-ietf-idr-bgp… Robert Raszuk
- [Idr] RTG Dir QA review of draft-ietf-idr-bgp-opt… Daniele Ceccarelli