Subject: 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

From: S Moonesamy <[email-masked]>
Date: Fri, 27 Sep 2019 15:13:18 -0700

Hello,
At 11:08 AM 30-08-2019, The IESG wrote:
>The IESG has received a request from the Traffic Engineering Architecture and
>Signaling WG (teas) to consider the following document: - 'Scenarios and
>Simulation Results of PCE in Native IP Network'
>   <draft-ietf-teas-native-ip-scenarios-08.txt> as Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits final
>comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2019-09-13. Exceptionally, comments may be

I am sending the comments to the working group mailing list to 
decrease the number of emails to ietf@.

Section 1 of the draft states that it "provides path optimization 
simulation results to illustrate the applicability of the CCDR 
framework".  There isn't much information about the different 
simulations (Section 4).  It is not possible to verify the results 
given the absence of the information.

I could not figure out how the draft fits within the WG 
Charter.  What is the purpose of publishing this document as a RFC?

Regards,
S. Moonesamy

---

From: "Aijun Wang" <[email-masked]>
Date: Sat, 28 Sep 2019 10:39:25 +0800

Hi, S Moonesamy:

Thanks for your review and comments.
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.

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

Thanks in advance.

Best Regards.

Aijun Wang
China Telecom

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 S
Moonesamy
发送时间: 2019年9月28日 6:13
收件人: [email-masked]
抄送: [email-masked]
主题: 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

Hello,
At 11:08 AM 30-08-2019, The IESG wrote:
>The IESG has received a request from the Traffic Engineering 
>Architecture and Signaling WG (teas) to consider the following 
>document: - 'Scenarios and Simulation Results of PCE in Native IP Network'
>The IESG plans to make a decision in the next few weeks, and solicits 
>final comments on this action. Please send substantive comments to the 

I am sending the comments to the working group mailing list to decrease the
number of emails to ietf@.

Section 1 of the draft states that it "provides path optimization simulation
results to illustrate the applicability of the CCDR framework".  There isn't
much information about the different simulations (Section 4).  It is not
possible to verify the results given the absence of the information.

I could not figure out how the draft fits within the WG Charter.  What is
the purpose of publishing this document as a RFC?

Regards,
S. Moonesamy

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: S Moonesamy <[email-masked]>
Date: Sat, 28 Sep 2019 02:12:04 -0700

Hi Aijun,
>realization that current existing solutions can't meet our requirements in

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.

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

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

---

From: Aijun Wang <[email-masked]>
Date: Sat, 28 Sep 2019 17:48:33 +0800

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 <[email-masked]> wrote:
> 
> Hi Aijun,
> 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.
> 
> 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 TEAS Charter [1] mentions deliverables; it does not include scenarios as part of that.
> 
> Regards,
> S. Moonesamy
>

---

From: S Moonesamy <[email-masked]>
Date: Sat, 28 Sep 2019 04:46:33 -0700

Hi Aijun,
At 02:48 AM 28-09-2019, Aijun Wang wrote:
>Together with the solutions draft, I think they are fit to the 
>deliverables described in the charter of TEAS WG.

Could you or another WG participant else please explain under which 
point in the WG Charter does the draft fit in?

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

I am not arguing against such cooperation as cooperation is 
useful.  I would expect an operator or university to point out the 
pros and cons or else the document may sound too good to be 
true.  Furthermore, it can be useful to other operators if they are 
the intended audience.

Regards,
S. Moonesamy

---

From: Aijun Wang <[email-masked]>
Date: Sat, 28 Sep 2019 21:02:20 +0800

Hi, S Moonesamy:

2. Specification of terminology, architecture, and protocol
requirements for abstraction and distribution of TE
information between interconnected TE domains/layers.

And, would you like to give other comments for the document? We just want to provide some useful information for the community. The community is composited of members from operators, vendors and researchers.

The draft just gives the scenarios that the operator encounters in real situations. Shouldn’t we design the technologies/solution towards the application’s requirements?

Aijun Wang
China Telecom

> On Sep 28, 2019, at 19:47, S Moonesamy <[email-masked]> wrote:
> 
> Hi Aijun,
> Could you or another WG participant else please explain under which point in the WG Charter does the draft fit in?
> 
>> 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?
> 
> I am not arguing against such cooperation as cooperation is useful.  I would expect an operator or university to point out the pros and cons or else the document may sound too good to be true.  Furthermore, it can be useful to other operators if they are the intended audience.
> 
> Regards,
> S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Sat, 28 Sep 2019 08:38:52 -0700

Hi Aijun,
At 06:02 AM 28-09-2019, Aijun Wang wrote:
>And, would you like to give other comments for the document? We just 
>want to provide some useful information for the community. The 
>community is composited of members from operators, vendors and researchers.

There is a sentence in the Abstract about "requirements".  The 
Introduction Section, specifically the last paragraph, states that 
the draft is about scenarios.  There isn't any mention of 
requirements.  My understanding of requirement is that it is about a 
thing which is compulsory.  I could not find anything in the draft 
which states that
Centralized Control Dynamic Routing in a native IP network is compulsory.

If it wasn't for our email exchange, I would not known about the 
algorithm.  I do not disagree with you on whether you want to provide 
some useful information for the community.  Is there useful 
information in the draft which is intended to be published?

Is there a vendor, excluding any one which has some affiliation with 
the draft, which has expressed interest in this work?  Are there 
operators, unaffiliated with the affiliations listed in the draft, 
who have expressed an interest in this work?

>The draft just gives the scenarios that the operator encounters in 
>real situations. Shouldn't we design the technologies/solution 
>towards the application's requirements?

In the above, "scenarios" is mentioned once again.  The question 
which follows is not about "scenarios"; it is about requirements.  I 
would say yes to the question.  However, that does not change the 
fact that the draft is described as being about scenarios and that is 
not mentioned in the WG Charter.

Regards,
S. Moonesamy

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Mon, 30 Sep 2019 18:34:19 +0000

Hi,

First, thanks for your interest in this teas document. And for keeping it on the working group list vs. the very busy IETF list😊

As some of your questions were more on the teas charter, maybe I can help. As described in the charter:
"The Traffic Engineering Architecture and Signaling (TEAS)
Working Group is responsible for defining IP, MPLS and GMPLS
traffic engineering architecture"

Also (a) provides description and then further down "With the PCE WG on uses of a PCE in the
traffic-engineering architecture". One of the milestones lists the native IP work.

So, "uses" is explicit in the charter. Why "use document" is not mentioned explicitly in the milestone for the native IP work? In the routing area, we usually progress by doing use scenarios, requirements, generic architecture, solutions. Sometimes the use scenarios are part of the requirements or a framework document. Sometimes stand alone e.g. a quick scan of other groups: RFC6965, RFC8355, RFC8403, RFC8578. I understand some Areas in IETF do not publish Informational documents, do not find them "useful". In the routing area, we do find them "useful". We value very much when operators provide information on their planned use scenarios. It is a decision of the working group and the AD to progress. This document does have working group consensus to publish.

You ask - is there more than one vendor interested? For this type of document, I think the interest of more than one operator is key. For a solution document, yes, more than one vendor should be supporting. The operators by bringing it to IETF are showing their interest for a standard solution, it now will be for the vendors to show interest. Other operators did not raise concerns with the document. It is a product of the working group.

Previous to this, there was not any work/shown interest in this area.  And now, we have another document which also shows this need:
https://www.ietf.org/id/draft-raszuk-rtgwg-ip-te-np-00.txt

I noted your concern with the word "requirements" in the abstract. The sentence is "Requirements for providing the End to End(E2E) performance assurance are emerging within the service provider network." This is not about the document providing "requirements" - as you say the title and document does not have "requirements". This is about requirements put on an operator. A similar sentence is in the document referenced above "The construction of controlled transit paths usually is driven by requirements to ...". Maybe vendors interpret "requirements" as on the equipment/protocol, here, operators are using the word in relation to what are requirements placed on them (us😊).

The other concern which I noted was your concern with the algorithm. This didn't raise any concerns in the working group as the results are common to TE algorithms in general. No one raised any questions on the need for more information. It's not the specific algorithm used which is key to this document, it is that TE is useful for native IP networks. If you have any text to suggest to help clarify your concern, I'm sure Aijun will work with you to improve.

Thanks again for your interest,
Deborah
(AD for TEAS)

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of S Moonesamy
Sent: Saturday, September 28, 2019 11:39 AM
To: Aijun Wang <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: 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

Hi Aijun,
At 06:02 AM 28-09-2019, Aijun Wang wrote:
>requirements for abstraction and distribution of TE information between 
>interconnected TE domains/layers.
>

There is a sentence in the Abstract about "requirements".  The Introduction Section, specifically the last paragraph, states that the draft is about scenarios.  There isn't any mention of requirements.  My understanding of requirement is that it is about a thing which is compulsory.  I could not find anything in the draft which states that Centralized Control Dynamic Routing in a native IP network is compulsory.

If it wasn't for our email exchange, I would not known about the algorithm.  I do not disagree with you on whether you want to provide some useful information for the community.  Is there useful information in the draft which is intended to be published?

Is there a vendor, excluding any one which has some affiliation with the draft, which has expressed interest in this work?  Are there operators, unaffiliated with the affiliations listed in the draft, who have expressed an interest in this work?

>The draft just gives the scenarios that the operator encounters in real 
>situations. Shouldn't we design the technologies/solution towards the 
>application's requirements?

In the above, "scenarios" is mentioned once again.  The question which follows is not about "scenarios"; it is about requirements.  I would say yes to the question.  However, that does not change the fact that the draft is described as being about scenarios and that is not mentioned in the WG Charter.

Regards,
S. Moonesamy 

_______________________________________________
Teas mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=kRbIQUjAFBcHpQN5ad2WstKT97bx-6vIGNl_deodmvQ&s=ozQUURHCNOdJ-8443p1dZGAvGOgjJ2jErYDTPoBIYms&e=