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

[Aijun Wang <[e-mail]>]

Hi, S Moonesamy:

Currently, I list only the RFC documents in the solutions draft as the “Normative Reference”. I knew your consideration. Once this draft is published, we will move the relevant reference to the right place.
The mean for “base document” is also for that this is the start points for the following solutions and protocol extension documents. 
Every solution has its own applicable scope. 

Together with the solutions draft, I think they are fit to the deliverables described in the charter of TEAS WG. 

The separation of scenarios and solutions draft is to encourage more solutions be proposed. There exists at least three solutions for the traffic engineering in Native IP network now.

And actually, the operator’s network is composed by the devices from vendors, and the algorithm may be from the university. Isn’t such cooperation the direction of operator? 
We will enhance the part of section 4 to try to give the reader more information for our efforts/results in the simulation process in next version in recent days.

Thanks for your reviews again. Wish more comments/supports from you.


Aijun Wang
China Telecom

> On Sep 28, 2019, at 17:13, S Moonesamy <[e-mail]> wrote:
> 
> 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/
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas