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

[Aijun Wang <[e-mail]>]


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