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

["BRUNGARD, DEBORAH A" <[e-mail]>]

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 <[e-mail]> On Behalf Of S Moonesamy
Sent: Saturday, September 28, 2019 11:39 AM
To: Aijun Wang <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
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:
>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.

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
[e-mail]
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=