[Teas] teas

Loa Andersson <loa@pi.nu> Fri, 07 August 2020 06:28 UTC

Return-Path: <loa@pi.nu>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72E33A079B; Thu, 6 Aug 2020 23:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 DQq_DD6NlP4s; Thu, 6 Aug 2020 23:28:12 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0E23A076F; Thu, 6 Aug 2020 23:28:11 -0700 (PDT)
Received: from [192.168.1.19] (unknown [122.2.101.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4DA9C32725E; Fri, 7 Aug 2020 08:28:06 +0200 (CEST)
From: Loa Andersson <loa@pi.nu>
To: rtg-ads@ietf.org, "review: ddraft-ietf-teas-pce-native-.all"@ietf.org, TEAS WG Chairs <teas-chairs@ietf.org>, TEAS WG <teas@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "'Yemin (Amy'" <amy.yemin@huawei.com>, =?UTF-8?Q?LucAndr=c3=a9_Burdet?= <laburdet.ietf@gmail.com>
Message-ID: <00f526b7-ffe7-d2b6-2e41-1d0384f049d5@pi.nu>
Date: Fri, 7 Aug 2020 14:28:01 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------D0A0C960971209EA9B7F5336"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/wK0oQ5zoDrqFm2Eqd2YBNdY4L4k>
Subject: [Teas] teas
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 07 Aug 2020 06:28:16 -0000

RtgDir review: ddraft-ietf-teas-pce-native-ip-09

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-teas-pce-native-ip-09
Reviewer: Loa Andersson
Review Date: 2020-07-08
IETF LC End Date: date-if-known
Intended Status: copy-from-I-D - Experimental (see issues list).

Summary:


I'm departing from the normal list, since if this would have been a
standard tracks document there would have been serious issues.

However, the document describes a TE experiment in a native IP network.
I think is so interesting that I wouldn't object if the issues I point 
are not (fully) resolved. Actually I would very much like to see
published and followed up by a document that reports the results from
the experiment.

I have the following issues with the document.

It is a framework that gives the framework for an experiment. Its
intended status is Experimental. While agree that the accompanying
specification should be Experimental I think that in accordance with
earlier document a framework should be Informational.

The document describes the experiment in some detail, I would like to
see more, especially evaluation criteria and bench marking. To have
an overview of the test bed would be interesting.

I would recommend that someone take a look at the document from a
language point of view. When I read I find myself correcting and
clarifying the English (this is probably not a good idea, since my
English is probably worse than the current authors).

There are loads of not expanded abbreviations, authors should go
through the document and compare to:
https://www.rfc-editor.org/materials/abbrev.expansion.txt
to decide what needs to be expanded or not.

I would also want to suggest that someone with experience of
"Native IP networks". both specification and operation should look at
the document. From the early days of MPLS I remember that one motivation
to create a strong tunnel technology was that the Route Reflectors no
longer scaled.

I normally review document based on a word document, I have included the
word-file, and it contains about everything form major issues to nits.


/Loa


-- 

Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64