Re: [Teas] Last Call: <draft-ietf-teas-native-ip-scenarios-08.txt> (Scenarios and Simulation Results of PCE in Native IP Network) to Informational RFC

[S Moonesamy <[e-mail]>]

Hi Aijun,
At 07:39 PM 27-09-2019, Aijun Wang wrote:
>The aim of this draft is to illustrate the scenarios that applicability and
>requirements for the TE in Native IP network. It is the base document for
>the other two WG drafts:
>https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/ (Solution
>document)
>https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip
>(PCEP extension document)
>
>As you can see from the recent discussion within the maillist, the TE work
>in native IP network becomes more aware and necessary, because most of
>Internet traffic are based on the native IP forwarding.
>We have done such research works within the recent years, based on the
>realization that current existing solutions can't meet our requirements in
>real network deployment.

Thank you for the prompt response.  I am not subscribed to the TEAS 
WG mailing list.

I took a look at draft-ietf-teas-pce-native-ip-04.  It has an 
informative reference to
draft-ietf-teas-native-ip-scenarios-06.  As such, 
draft-ietf-teas-native-ip-scenarios-06 does not qualify as a base 
document for draft-ietf-teas-native-ip-scenarios-06.

>Section 4(CCDR Simulation) just wants to convince the reader that we have
>implemented the algorithm to find the optimal path for E2E QoS assurance and
>the network congestion elimination. The detailed algorithm is described in
>another paper(https://ieeexplore.ieee.org/document/8657733 " A Practical
>Traffic Control Scheme With Load Balancing Based on PCE Architecture ") that
>I will refer to it in upcoming update version.

The paper proposes a traffic control scheme.  Based on the 
experiments which have been done (according to the authors), it 
states that the proposed scheme can obtain good performance, etc.  I 
read Section 4 of the draft once again.  The only thing that might 
convince the reader is that the (intended) RFC is authored by a 
service provider, a university and a company which sells equipment in 
the relevant market.

>The charter of the TEAS WG (https://datatracker.ietf.org/wg/teas/about/) has
>stated clearly the followings:
>"The Traffic Engineering Architecture and Signaling (TEAS) Working Group is
>responsible for defining IP, MPLS and GMPLS traffic engineering architecture
>and identifying required related control-protocol functions, i.e., routing
>and path computation element functions. The TEAS group is also responsible
>for standardizing RSVP-TE signaling protocol mechanisms that are not related
>to a specific switching technology."
>
>The current scenario
>draft(https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/)
>is discussing mainly for the IP traffic engineering.
>
>And it also says the followings:
>"The TEAS WG is responsible for:
>a) Traffic-engineering architectures for generic applicability across packet
>and non-packet networks. This includes, for example, networks that perform
>centralized computation and control, distributed computation and control, or
>even a hybrid approach."
>
>The above mentioned solution
>draft(https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/)
>belong to the category of "hybrid approach"
>
>Will the above explanation answer your concern? I will update the revised
>draft in recent days, together to reflect the comments from other reviewers.

The TEAS Charter [1] mentions deliverables; it does not include 
scenarios as part of that.

Regards,
S. Moonesamy

1. https://datatracker.ietf.org/wg/teas/about/