Hi, Loa:

 

Thanks for your review. We have updated the draft accordingly.

Detail responses are inline below.

 

I also includes the word responses for your reference.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Loa 
Andersson
Sent: Friday, August 7, 2020 2:28 PM
To: [email protected]; "review: ddraft-ietf-teas-pce-native-.all"@ietf.org; TEAS 
WG Chairs <[email protected]>; TEAS WG <[email protected]>; [email protected]; 'Yemin 
(Amy' <[email protected]>; LucAndré Burdet <[email protected]>
Subject: [Pce] teas

 

 

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> 
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.

[WAJ] Actually, this draft define the architecture for traffic engineering 
within Native IP network(CCDR). Should we change the phrase from “framework” to 
“architecture”, and keep the document in “Experimental” track?

We have also discussed the possible status of this draft, at 
https://mailarchive.ietf.org/arch/msg/teas/YIMuXe1rM46aewPgfzMJrP-hPUA/

 

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.

[WAJ] We have some simulation results, as described in 
https://tools.ietf.org/html/rfc8735. Experiment in real filed will have similar 
results because the effect of such solution depends mainly on the performance 
of PCE. More data can be obtained after the PCEP extension 
draft(https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-05) 
been standardized. 

This is also the reason that we put this document in “Experimental” Status now. 

 

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> 
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.

[WAJ] The solution descried in this document does not decrease the scalability 
of RR. The forwarding plan will not pass RR.

 

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:  <mailto:[email protected]> [email protected]

Senior MPLS Expert                           <mailto:[email protected]> 
[email protected]

Bronze Dragon Consulting             phone: +46 739 81 21 64

Attachment: draft-ietf-teas-pce-native-ip-09(waj).docx
Description: MS-Word 2007 document

_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce

Reply via email to