Re: [Teas] Benjamin Kaduk's Discuss on draft-ietf-teas-native-ip-scenarios-09: (with DISCUSS and COMMENT)

[Aijun Wang <[e-mail]>]

Hi, Robert,
Thanks for your comments.
Please see the inline responses below.

Aijun Wang
China Telecom

> On Oct 3, 2019, at 18:06, Robert Raszuk <[e-mail]> wrote:
> 
> Hi Aijun.
> 
>> With the pervasive deployment of overlay technologies within the network,
> the necessity
>> of IP TE solutions will be more attractive than the traditional MPLS TE
> solutions.
> 
> I fully agree. That is why I wrote my draft proposing how IP TE can be
> easily constructed and deployed today.
> 
>> The PCE is just the representative of SDN controller. We can mitigate the
> descriptions of it. But without
>> the help of SDN controller and the global view of underlying network, it
> is almost impossible to achieve
>> the E2E QoS assurance and improve the network efficiency.
> 
> I actually disagree with this above statement.
> 
> Central control makes a lot of sense within single administrative domain
> where the advantage you have is ability to keep real time traffic matrix or
> traffic demand and then when you can control all ingress points and manage
> 100% of the transit traffic according to the plan.
> 
[Aijun Wang] I agree.

> While this is possible in intra-domain cases it is pretty seldom used. For
> inter-domain traffic IMO this is impossible simply as you can not either
> get the full traffic matrix across N number of underlay ASes nor control
> how that traffic flows.
[Aijun Wang] There are also the inter-domain that under one administration scope can achieve the expected results.

> 
> I presented in my draft how I envision to achieve IP TE based on real time
> SLA measurements which btw is the default way  of operation in number of
> SDWANs today. Some do it better then others but the core idea is still the
> same.

[Aijun Wang] Is there any SDWAN deployment that operated by different operators? As I known, current SDWAN solutions are mainly proprietary protocol.
The vision for E2E QoS assurance that covers different operators is attractive but also challenging. To transmit the SLA measurements via the central control unit and then deploy them in the network respectively is more feasible.

We can discuss such scenarios further in details.

> 
> Thx a lot,
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Thu, Oct 3, 2019 at 11:43 AM Aijun Wang <[e-mail]>
>> wrote:
>> 
>> Hi, Robert:
>> 
>> Thanks for your comments.
>> With the pervasive deployment of overlay technologies within the network,
>> the necessity of IP TE solutions will be more attractive than the
>> traditional MPLS TE solutions.
>> Current draft illustrates the intra-domain and inter-domain TE scenarios.
>> The solutions that can meet these scenarios/requirements  in one unique
>> approach will be more easily deployed in the network.
>> 
>> The PCE is just the representative of SDN controller. We can mitigate the
>> descriptions of it. But without the help of SDN controller and the global
>> view of underlying network, it is almost impossible to achieve the E2E QoS
>> assurance and improve the network efficiency.
>> 
>> Would you like to provide some text for what you want to solve but not
>> covered by this document?
>> 
>> Thanks in advance.
>> 
>> Aijun Wang
>> China Telecom
>> 
>> On Oct 3, 2019, at 16:39, Robert Raszuk <[e-mail]> wrote:
>> 
>> 
>> All,
>> 
>> I think it is useful informational document.
>> 
>> However I would remove PCE elements from it and turned it into
>> requirements document perhaps also adding few more real life deployment
>> scenarios where use of end to end IP TE is very important.
>> 
>> Many thx,
>> R.
>> 
>> 
>> 
>> 
>> 
>> On Thu, Oct 3, 2019 at 10:10 AM Aijun Wang <[e-mail]>
>> wrote:
>> 
>>> 
>>> Hi, Benjamin:
>>> Thanks for your review.
>>> 
>>> On summary, this draft just gives the scenarios that needed for TE in
>>> Native IP network, this is absent in current existing IETF documents. The
>>> simulation results just demonstrated the applicability of central control
>>> under the global view.
>>> This document is the base document of other two drafts:
>>> 
>>> https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-04 (Solution
>>> Draft)
>>> 
>>> https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-04
>>> <https://tools..ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-04>(PCEP
>>> extension)
>>> 
>>> There are currently at least three different solutions trying to
>>> accomplish the TE necessities in native IP network. This scenarios and
>>> simulation draft is just the start points of these documents.
>>> 
>>> More details responses are inline below. Wish they can convince you for
>>> the future vote.
>>> 
>>> Thanks in advance.
>>> 
>>> Aijun Wang
>>> China Telecom
>>> 
>>> On Oct 3, 2019, at 13:15, Benjamin Kaduk via Datatracker <
>>> [e-mail]> wrote:
>>> 
>>> Benjamin Kaduk has entered the following ballot position for
>>> draft-ietf-teas-native-ip-scenarios-09: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> I have two points for discussion:
>>> 
>>> (1) If this document was subject to the approval requirements for
>>> standards action, it would basically be suffering from "death by
>>> abstain"; this seems like a good signal for the IESG to discuss whether
>>> it makes sense to approve this document even though the more-lenient
>>> document-action requirements would otherwise let it go forward.
>>> 
>>> [Aijun Wang]: This document is the cooperation results of authors from
>>> operators, research university and the vendor. The style of the document
>>> maybe slight different from the traditional IETF documents, but the aim of
>>> it same as others: give some useful information to the community based on
>>> our efforts.
>>> Wish the relevant responses and explanations can convince the reviewer.
>>> 
>>> (2) The document seems incomplete to me.  It has some aspects of being
>>> all/any of a use-cases document, an architecture document, and an
>>> applicability analysis, but does not seem to have a complete treatment
>>> for any of them.  To be clear, there is enough in the document to
>>> indicate that the topic merits further work, and there are some
>>> interesting results, but I'm not sure that publication as an RFC is
>>> appropriate for this document in this form.  Specifically:
>>> 
>>> [Aijun Wang] It is mainly one native IP TE scenarios description
>>> document. The simulation part of this document just want to convince the
>>> reader the addition gain of central control under the global view.
>>> The architecture/solutions contents is in above mentioned solutions draft.
>>> 
>>> 
>>> (2a) use-cases: we see the examples of star topology with BRAS/SR and
>>> the simulated network in Figure 6, but there is not much discussion of
>>> where these (or similar) scenarios arise in practice, how common they
>>> are, and how closely the simulation reflects actual usage.
>>> 
>>> 
>>> [Aijun Wang]: The star topology and simulated topology are all
>>> abstraction from our real network deployment.
>>> 
>>> 
>>> (2b) architecture: a very high-level picture is given ("use a PCE to
>>> engineer some of the IP traffic on a network and improve overall
>>> efficiency"), but we don't see much about how PCCs will be involved and
>>> apply the computed paths or what requirements will need to be met by the
>>> protocols and components used to instantiate the architecture
>>> 
>>> 
>>> [Aijun Wang]: The above contents that you concerned is described in the
>>> above mentioned solution and PCEP extension drafts. As explained in
>>> previous, this draft focus only the overall scenarios and the simulation
>>> results.
>>> 
>>> 
>>> (2c) applicability: we see some scenarios where the proposed technology
>>> shows drastic improvement over the alternative selected for comparison,
>>> but there is little to give confidence that this reflects a broad maxima
>>> that is robust to environmental variations.  Is the alternative selected
>>> for comparison an appropriate one for the cases in question?  How would
>>> the propsal react in the face of changes in the environment it runs in,
>>> such as link or node failure, changes in the baseline usage, or traffic
>>> spikes?  What timescale can it react in and what level of visibility
>>> does the PCE need into current conditions in order to be reliable?
>>> 
>>> [Aijun Wang] The SDN controller get the overall underlying network
>>> conditions via BGP-LS/SNMP/Netflow protocol in about 5 minutes intervals