[Teas] Éric Vyncke's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Wed, 20 January 2021 10:56 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C083A10C5; Wed, 20 Jan 2021 02:56:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-teas-pce-native-ip@ietf.org, teas-chairs@ietf.org, teas@ietf.org, Lou Berger <lberger@labn.net>, lberger@labn.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
Message-ID: <161114019815.29154.13349753835162364695@ietfa.amsl.com>
Date: Wed, 20 Jan 2021 02:56:38 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/2TosyaSjedInCLC-CO_wk9aoon8>
Subject: [Teas] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-teas-pce-native-ip-15=3A_=28with_COMMENT=29?=
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2021 10:56:39 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-teas-pce-native-ip-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thank you for the work put into this document. I love the oxymoron approach
with "The solution combines the use of distributed routing protocols and a
centralized controller" ;-)

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

I hope that this helps to improve the document,




Am I right when inferring that for each TE path there is a need to add one
loopback interface/address on every edge router + 1 BGP session ? How will it
scale ? Should there be a mention somewhere of this limitation (if confirmed) ?
I saw nothing in section 7.1 (scalability).

-- Abstract --
"it ... identifies needed extensions for the Path Computation Element
Communication Protocol (PCEP)", at first sight, it seems that it is an
incomplete document or a problem statement until reading the last sentence of
the introduction. May I suggest to change the sentence in the abstract in a
more assertive way ?

-- Section 3 --
Suggest to define the lo11 & others as the loopback interfaces in the first
bullet in the list.

I am far from being an expert in BGP and routing but isn't the link selection
still done *only* on the destination prefix ? I fail to see how the source
prefix is used in the forwarding decision (except for the return traffic).
I.e., there is no traffic isolation as PF11 can sent traffic to PF22 using the
link 'reserved' for PF12 to PF22.

-- Section 4 --
Suggest to add 'RR' in the R3 box.

== NITS ==

several s/large scale/large-scale/ ?

The usual way for acronyms is "Path Computation Client (PCC)" rather than "PCC
(Path Computation Client)"