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

[Robert Raszuk <[e-mail]>]

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.

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.

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.

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.
>> The optimization process for the simulated complex topology and traffic
>> matrix need only tens of seconds. For further strict requirements, it is
>> easy to enhance the central controller’s capability to tackle the
>> changeable environment.
>>
>> The above concerns has more relations to the solutions, we can add such
>> descriptions in the solutions draft at its “Deployment Considerations”
>> part.(
>> https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-04#section-9)
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> If we're using a PCE in a native IP network, how do the computed routes
>> get applied; are we using source routing or just being careful about
>> the prefixes in use?  (Are there going to be any scaling concerns?)
>>
>>
>> [Aijun Wang] These contents are in the above mentioned solution draft. It
>> is not using the current source routing, but the combination of multiple
>> BGP session and the manipulation of the path to BGP nexthop with the help
>> of PCEP protocol. The scalability is discussed in section 9.1 of solution
>> draft(
>> https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-04#section-9.1)
>>
>>
>>
>> Section 3.1
>>
>> I don't understand what Figure 1 is intending to convey.  Are "Private
>> Cloud Site" and "Public Cloud Site" supposed to be separate boxes on the
>> edge of the distributed control network?  Why is the "Cloud Based
>> Application" in neither of the named clouds?
>>
>>
>> [Aijun Wang]: The source and destination of the “Cloud-Based Application”
>> are located at the “Private Cloud Site” and “Public Cloud Site”. You can
>> deem these sites as the concepts described in traditional VPN deployment
>> scenarios.
>>
>> Section 3.2
>>
>>   Network topology within a Metro Area Network (MAN) is generally in a
>>   star mode as illustrated in Figure 2, with different devices
>>
>> "Generally" within what scope, commercial ISPs?  I know of things that
>> could be called MANs that use a different topology..
>>
>> [Aijun Wang]: In commercial ISP.
>>
>> Section 4..1
>>
>> nit: several sentences are missing spaces after the full stop.
>>
>>
>> [Aijun Wang] Will correct them in update version.
>>
>>
>> Section 4.2
>>
>> Is a fully-linked core of 100 nodes representative of typical
>> deployments?  That's a lot of links not going to customers!
>>
>>
>> [Aijun Wang]: The core nodes can also connects the customers. That is the
>> reasons that the traffic matrix is 500*500, not 100*100
>>
>>
>> Section 4.3
>>
>>   The traffic matrix is generated based on the link capacity of
>>   topology.  [...]
>>
>> I don't know how to interpret this statement.
>> It does sound like the traffic matrix is generated in a somewhat
>> arbitrary fashion, with no stated effort to keep it aligned with
>> real-world traffic patterns.
>>
>> [Aijun Wang] We just keep the overall congestion links ratio is similar
>> with the real network. The arbitration fashion can otherwise certificate
>> the robustness of the simulation process.
>>
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>