Skip to main content

Scenarios and Simulation Results of PCE in a Native IP Network
RFC 8735

Revision differences

Document history

Date Rev. By Action
2020-02-28
12 (System)
Received changes through RFC Editor sync (created alias RFC 8735, changed title to 'Scenarios and Simulation Results of PCE in a Native IP Network', …
Received changes through RFC Editor sync (created alias RFC 8735, changed title to 'Scenarios and Simulation Results of PCE in a Native IP Network', changed abstract to 'Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.

One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying the Path Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios.', changed pages to 16, changed standardization level to Informational, changed state to RFC, added RFC published event at 2020-02-28, changed IESG state to RFC Published)
2020-02-28
12 (System) RFC published
2020-02-27
12 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8735">AUTH48-DONE</a> from AUTH48
2020-02-24
12 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc">AUTH48</a> from RFC-EDITOR
2020-01-24
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-11-04
12 (System) RFC Editor state changed to EDIT
2019-11-04
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-11-04
12 (System) Announcement was received by RFC Editor
2019-11-04
12 (System) IANA Action state changed to No IANA Actions from In Progress
2019-11-04
12 (System) IANA Action state changed to In Progress
2019-11-04
12 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2019-11-04
12 Cindy Morgan IESG has approved the document
2019-11-04
12 Cindy Morgan Closed "Approve" ballot
2019-11-04
12 Cindy Morgan Ballot writeup was changed
2019-11-04
12 Deborah Brungard Ballot approval text was changed
2019-10-29
12 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-12.txt
2019-10-29
12 (System) New version accepted (logged-in submitter: Aijun Wang)
2019-10-29
12 Aijun Wang Uploaded new revision
2019-10-25
11 Benjamin Kaduk
[Ballot comment]
Thanks for the updates in the -11!
This version does a much better job at convincing the reader that CCDR
can be an …
[Ballot comment]
Thanks for the updates in the -11!
This version does a much better job at convincing the reader that CCDR
can be an effective solution to the stated problems in real-world networks.
2019-10-25
11 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2019-10-25
11 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-11.txt
2019-10-25
11 (System) New version approved
2019-10-25
11 (System)
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Caixia Qou <koucx@lsec.cc.ac.cn>, Aijun Wang …
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Caixia Qou <koucx@lsec.cc.ac.cn>, Aijun Wang <wangaj3@chinatelecom.cn>, Penghui Mi <mipenghui@huawei.com>
2019-10-25
11 Aijun Wang Uploaded new revision
2019-10-18
10 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Carlos Martínez was marked no-response
2019-10-17
10 Wesley Eddy Request closed, assignment withdrawn: Olivier Bonaventure Telechat TSVART review
2019-10-17
10 Wesley Eddy Closed request for Telechat review by TSVART with state 'Team Will not Review Version'
2019-10-08
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-10-08
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-10-08
10 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-10.txt
2019-10-08
10 (System) New version approved
2019-10-08
10 (System)
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Caixia Qou <koucx@lsec.cc.ac.cn>, Aijun Wang …
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Caixia Qou <koucx@lsec.cc.ac.cn>, Aijun Wang <wangaj3@chinatelecom.cn>, Penghui Mi <mipenghui@huawei.com>
2019-10-08
10 Aijun Wang Uploaded new revision
2019-10-03
09 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-10-03
09 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2019-10-03
09 Barry Leiba
[Ballot comment]
In light of Roman's comments about the academic paper, I agree and join in the "Abstain" group.  It would be better just to …
[Ballot comment]
In light of Roman's comments about the academic paper, I agree and join in the "Abstain" group.  It would be better just to have the other documents refer to the academic paper, rather than to republish a portion of that paper in the RFC series.
2019-10-03
09 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to Abstain from No Objection
2019-10-03
09 Martin Vigoureux
[Ballot comment]
Thank you Roman for finding the paper. It seems to me that there is much more details in the paper than in the …
[Ballot comment]
Thank you Roman for finding the paper. It seems to me that there is much more details in the paper than in the draft. As such I don't really see the value of publishing a subset as a draft and then an RFC.
2019-10-03
09 Martin Vigoureux [Ballot Position Update] New position, Abstain, has been recorded for Martin Vigoureux
2019-10-03
09 Magnus Westerlund
[Ballot discuss]
I also think IESG and the WG really should have a discussion if this document should be published at all. In addition to …
[Ballot discuss]
I also think IESG and the WG really should have a discussion if this document should be published at all. In addition to the points raised by Benjamin I want to add my view to this.

The document in its current form appear to be outside of TEAS Charter. This document is none of the several things TEAS is approved to work with. As Benjamin enumerates so well the document is also a very poor support or architecture document. Which is why I would argue that it fully outside of the TEAS charter as neither a main objective of the WG or a support document.

Even if fixed to be a better support document, I still think the WG should consider its charter and the IESG statement on support documents: https://www.ietf.org/about/groups/iesg/statements/support-documents/ and ask themselves if that is really something that is worth publishing.
2019-10-03
09 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2019-10-02
09 Benjamin Kaduk
[Ballot discuss]
I have two points for discussion:

(1) If this document was subject to the approval requirements for
standards action, it would basically be …
[Ballot 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.

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

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

(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

(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?
2019-10-02
09 Benjamin Kaduk
[Ballot 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 …
[Ballot 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?)

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?

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.

Section 4.1

nit: several sentences are missing spaces after the full stop.

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!

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.
2019-10-02
09 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-10-02
09 Roman Danyliw
[Ballot comment]
==[ Summary
I am balloting as an ABSTAIN because the primary contribution of this draft appears to be the simulation results.  However, these …
[Ballot comment]
==[ Summary
I am balloting as an ABSTAIN because the primary contribution of this draft appears to be the simulation results.  However, these results appear to be already published in greater detail in http://ieeexplore.ieee.org/document/8657733.

I have no commentary on the utility of the CDDR Scenarios found in Section 3.

==[ Details

I have reservations about the approach taken in Section 4.  As a stand-alone write-up, it insufficiently describes the simulations in question.  Furthermore, the content in this section copies verbatim or re-phrases the source material of these simulations from an already published academic paper (without citation).  See http://ieeexplore.ieee.org/document/8657733.  In particular:

-- The entirely of Section 4.1 (text and diagrams) is a cut-and-paste from Section V.B of the academic paper. 

-- The simulation results of Section 4.4 in this draft align with the analysis in Section V.C of the academic paper. 

-- The simulation results of Section 4.5 in this draft align with analysis in Section V.D of the academic paper.

Without the benefit of the academic paper cited above, I would have had the following feedback on Section 4:

-- Section 4.  What use case is being simulated isn’t clear.  The text is Section 3.1 states that “Section 4 of this document describes the simulation results of this use case”.  However, the topology for the simulation described in Section 4.2 looks different than the one in Figure 1 (of Section 3.1). 

-- Section 4.  A few questions about the simulation design:
Only the results were presented.  How were the simulations constructed and results evaluated? 

Section 4.0 states that this section “illustrate[s the] CCDR algorithm”.  Where is that algorithm defined?  Is that Section 7 of draft-ietf-teas-pce-native-ip or http://ieeexplore.ieee.org/document/8657733?

What specific algorithms was used to create the contrasting charts in Figures 7 and 8? 

Section 4.2 said that “[t]he number of links connecting one edge node to the set of core nodes is randomly between 2 to 30, and the total number of links is more than 20000.”  Section 4.3 said that “[i]n the CCDR simulation, the dimension of the traffic matrix is 500*500.  About 20% links are overloaded when the Open Shortest Path First (OSPF) protocol is used in the network.”, What is the basis of these choices?  Are they representative of a given use case?

What is the relationship between the Sections 4.2 and 4.3, and the simulation results in Sections 4.4 and 4.5

Additional feedback includes:

-- Section 5.  The purpose of this section isn’t clear.

-- Missing references
Section 1.  A reference to CCDR is needed.  Also, given that CCDR is the basis of the simulation, it needs to be normative.

Section 5.  A reference is needed for the IEEE document.
2019-10-02
09 Roman Danyliw [Ballot Position Update] New position, Abstain, has been recorded for Roman Danyliw
2019-10-02
09 Alissa Cooper
[Ballot comment]
I agree with Éric and Alvaro. It's not clear what is gained by publishing this as an RFC rather than a research paper, …
[Ballot comment]
I agree with Éric and Alvaro. It's not clear what is gained by publishing this as an RFC rather than a research paper, especially given the lack of support in the WG.
2019-10-02
09 Alissa Cooper [Ballot Position Update] New position, Abstain, has been recorded for Alissa Cooper
2019-10-01
09 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-10-01
09 Wesley Eddy Request for Telechat review by TSVART is assigned to Olivier Bonaventure
2019-10-01
09 Wesley Eddy Request for Telechat review by TSVART is assigned to Olivier Bonaventure
2019-10-01
09 Éric Vyncke
[Ballot comment]
I share Alvaro's and TSV reviewer feeling about this is not a usual RFC but rather a scientific paper (even if the results …
[Ballot comment]
I share Alvaro's and TSV reviewer feeling about this is not a usual RFC but rather a scientific paper (even if the results are not really a surprise). So, I am abstaining.

Some comments though:
- why using OSPF and not IS-IS for the comparison ? Not that it would change a lot IMHO
- when using generated topologies, little is written on how it is generated (as it could introduce some bias changing the results of section 4.4)
- using the new format for XML2RFC could have included SVG for graphics

Interesting read anyway

-éric
2019-10-01
09 Éric Vyncke [Ballot Position Update] New position, Abstain, has been recorded for Éric Vyncke
2019-09-30
09 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2019-09-29
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-09-29
09 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-09.txt
2019-09-29
09 (System) New version approved
2019-09-29
09 (System)
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Caixia Qou <koucx@lsec.cc.ac.cn>, Aijun Wang …
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Caixia Qou <koucx@lsec.cc.ac.cn>, Aijun Wang <wangaj3@chinatelecom.cn>, Penghui Mi <mipenghui@huawei.com>
2019-09-29
09 Aijun Wang Uploaded new revision
2019-09-27
08 Olivier Bonaventure Request for Last Call review by TSVART Completed: Not Ready. Reviewer: Olivier Bonaventure. Sent review to list.
2019-09-27
08 Alvaro Retana
[Ballot comment]
The integration of distributed protocols and centralized control in a Hybrid network is not a new topic.  I feel conflicted about the publication …
[Ballot comment]
The integration of distributed protocols and centralized control in a Hybrid network is not a new topic.  I feel conflicted about the publication of this document as an RFC because it doesn't contribute much to the existing literature...except maybe for the explicit suggestion of using "PCE in a native IP network".  Specifically, the interaction of the distributed and centralized components can result in added operational complexity and new security vulnerabilities.  Neither of these issues are mentioned. 

I appreciate the work that the authors have put into this document, but because of it being incomplete and only having "tepid support" [1] from the WG, I have decided to ABSTAIN and not stand in the way of publication.

[1] https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/shepherdwriteup/
2019-09-27
08 Alvaro Retana [Ballot Position Update] New position, Abstain, has been recorded for Alvaro Retana
2019-09-26
08 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Wassim Haddad.
2019-09-25
08 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-09-20
08 Cindy Morgan Placed on agenda for telechat - 2019-10-03
2019-09-20
08 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2019-09-20
08 Deborah Brungard Ballot has been issued
2019-09-20
08 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2019-09-20
08 Deborah Brungard Created "Approve" ballot
2019-09-20
08 Deborah Brungard Ballot writeup was changed
2019-09-13
08 Aanchal Malhotra Request for Last Call review by SECDIR Completed: Ready. Reviewer: Aanchal Malhotra. Sent review to list.
2019-09-13
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-09-09
08 Wesley Eddy Request for Last Call review by TSVART is assigned to Olivier Bonaventure
2019-09-09
08 Wesley Eddy Request for Last Call review by TSVART is assigned to Olivier Bonaventure
2019-09-09
08 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-09-09
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-teas-native-ip-scenarios-08, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-teas-native-ip-scenarios-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-09-06
08 Jean Mahoney Request for Last Call review by GENART is assigned to Wassim Haddad
2019-09-06
08 Jean Mahoney Request for Last Call review by GENART is assigned to Wassim Haddad
2019-09-05
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Aanchal Malhotra
2019-09-05
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Aanchal Malhotra
2019-09-02
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2019-09-02
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2019-08-30
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-08-30
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-09-13):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: db3546@att.com, teas-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2019-09-13):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, draft-ietf-teas-native-ip-scenarios@ietf.org, Lou Berger <lberger@labn.net>, lberger@labn.net
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-teas-native-ip-scenarios-08.txt> (Scenarios and Simulation Results of PCE in Native IP Network) to Informational RFC


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
ietf@ietf.org mailing lists by 2019-09-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Requirements for providing the End to End(E2E) performance assurance
  are emerging within the service provider network.  While there are
  various technology solutions, there is no one solution which can
  fulfill these requirements for a native IP network.  One universal
  (E2E) solution which can cover both intra-domain and inter-domain
  scenarios is needed.

  One feasible E2E traffic engineering solution is the use of a Path
  Computation Elements (PCE) in a native IP network.  This document
  describes various complex scenarios and simulation results when
  applying a PCE in a native IP network.  This solution, referred to as
  Centralized Control Dynamic Routing (CCDR), integrates the advantage
  of using distributed protocols and the power of a centralized control
  technology.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-08-30
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-08-30
08 Deborah Brungard Last call was requested
2019-08-30
08 Deborah Brungard Ballot approval text was generated
2019-08-30
08 Deborah Brungard Ballot writeup was generated
2019-08-30
08 Deborah Brungard IESG state changed to Last Call Requested from Expert Review
2019-08-30
08 Deborah Brungard Last call announcement was generated
2019-08-29
08 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-08.txt
2019-08-29
08 (System) New version approved
2019-08-29
08 (System)
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Caixia Qou <koucx@lsec.cc.ac.cn>, Aijun Wang …
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Caixia Qou <koucx@lsec.cc.ac.cn>, Aijun Wang <wangaj3@chinatelecom.cn>, Penghui Mi <mipenghui@huawei.com>
2019-08-29
08 Aijun Wang Uploaded new revision
2019-08-25
07 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-07.txt
2019-08-25
07 (System) New version approved
2019-08-25
07 (System)
Request for posting confirmation emailed to previous authors: Zhenqiang Li <li_zhenqiang@hotmail.com>, Xiaohong Huang <huangxh@bupt.edu.cn>, teas-chairs@ietf.org, Caixia Qou <koucx@lsec.cc.ac.cn>, …
Request for posting confirmation emailed to previous authors: Zhenqiang Li <li_zhenqiang@hotmail.com>, Xiaohong Huang <huangxh@bupt.edu.cn>, teas-chairs@ietf.org, Caixia Qou <koucx@lsec.cc.ac.cn>, Penghui Mi <mipenghui@huawei.com>, Aijun Wang <wangaj.bri@chinatelecom.cn>
2019-08-25
07 Aijun Wang Uploaded new revision
2019-08-21
06 Min Ye Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Loa Andersson.
2019-07-23
06 Min Ye Request for Last Call review by RTGDIR is assigned to Loa Andersson
2019-07-23
06 Min Ye Request for Last Call review by RTGDIR is assigned to Loa Andersson
2019-07-19
06 Deborah Brungard Requested RTG review.
2019-07-19
06 Deborah Brungard IESG state changed to Expert Review from Publication Requested
2019-07-19
06 Deborah Brungard Changed consensus to Yes from Unknown
2019-07-19
06 Deborah Brungard Requested Last Call review by RTGDIR
2019-07-10
06 Lou Berger

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. …

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Informational

> Why is this the proper type of RFC?

The document provides scenario and simulation results, no protocols are defined.

> Is this type of RFC indicated in the title page header?

Yes

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:

> Technical Summary
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.

  This document describes the scenarios and simulation results for PCE
  in native IP network, which integrates the merit of distributed
  protocols (IGP/BGP), and the power of centrally control technologies
  (PCE/SDN) to provide one feasible traffic engineering solution in
  various complex scenarios for the service provider.

> Working Group Summary
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

This document has received limited support and no objections to
publication as an Information document within the WG.

> Document Quality
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification? Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

This document describes scenarios and a related simulation, and has
input from multiple operators.

> Personnel

>  Who is the Document Shepherd?
Lou Berger

> Who is the Responsible Area Director?
Deborah Brungard

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

I have reviewed this work as it progressed, from the start of when it
was adopted until the recent WG Last call. I believe it is ready for
publication as an Informational document.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.

No.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No issues.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes. See
https://mailarchive.ietf.org/arch/msg/teas/AwyYxqMzXaDbKLOve4uJNfKsj_U


> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it? 

The document has strong support from those working this topic, and tepid
support from the rest of the working group.  No objections to
publication were raised within the WG.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

None. (There is a false positive reported, but the reference is present.)

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A as no protocol is defined.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

None.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

No.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section was fully reviewed and contains the information
typically found in a non-protocol defining draft.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

Idnits from the tools page was check, see:
      https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-teas-native-ip-scenarios-06.txt
     
2019-07-10
06 Lou Berger Responsible AD changed to Deborah Brungard
2019-07-10
06 Lou Berger IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-07-10
06 Lou Berger IESG state changed to Publication Requested from I-D Exists
2019-07-10
06 Lou Berger IESG process started in state Publication Requested
2019-07-10
06 Lou Berger

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. …

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Informational

> Why is this the proper type of RFC?

The document provides scenario and simulation results, no protocols are defined.

> Is this type of RFC indicated in the title page header?

Yes

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:

> Technical Summary
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.

  This document describes the scenarios and simulation results for PCE
  in native IP network, which integrates the merit of distributed
  protocols (IGP/BGP), and the power of centrally control technologies
  (PCE/SDN) to provide one feasible traffic engineering solution in
  various complex scenarios for the service provider.

> Working Group Summary
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

This document has received limited support and no objections to
publication as an Information document within the WG.

> Document Quality
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification? Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

This document describes scenarios and a related simulation, and has
input from multiple operators.

> Personnel

>  Who is the Document Shepherd?
Lou Berger

> Who is the Responsible Area Director?
Deborah Brungard

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

I have reviewed this work as it progressed, from the start of when it
was adopted until the recent WG Last call. I believe it is ready for
publication as an Informational document.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.

No.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No issues.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes. See
https://mailarchive.ietf.org/arch/msg/teas/AwyYxqMzXaDbKLOve4uJNfKsj_U


> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it? 

The document has strong support from those working this topic, and tepid
support from the rest of the working group.  No objections to
publication were raised within the WG.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

None. (There is a false positive reported, but the reference is present.)

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A as no protocol is defined.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

None.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

No.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section was fully reviewed and contains the information
typically found in a non-protocol defining draft.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

Idnits from the tools page was check, see:
      https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-teas-native-ip-scenarios-06.txt
     
2019-07-10
06 Lou Berger LC Complete: https://mailarchive.ietf.org/arch/msg/teas/s_OGNYS886n2t-oCb_ga2-UKXxQ
2019-07-10
06 Lou Berger IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-06-30
06 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-06.txt
2019-06-30
06 (System) New version approved
2019-06-30
06 (System)
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Aijun Wang <wangaj.bri@chinatelecom.cn>, Caixia Qou …
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Aijun Wang <wangaj.bri@chinatelecom.cn>, Caixia Qou <koucx@lsec.cc.ac.cn>, Penghui Mi <mipenghui@huawei.com>
2019-06-30
06 Aijun Wang Uploaded new revision
2019-06-13
05 Lou Berger IETF WG state changed to In WG Last Call from WG Document
2019-06-13
05 Lou Berger Notification list changed to Lou Berger <lberger@labn.net>
2019-06-13
05 Lou Berger Notification list changed to Lou Berger <lberger@labn.net>
2019-06-13
05 Lou Berger Document shepherd changed to Lou Berger
2019-06-13
05 Lou Berger Document shepherd changed to Lou Berger
2019-06-13
05 Lou Berger Intended Status changed to Informational from None
2019-06-13
05 Lou Berger
final response received in e-mail but didn't make it to the archive!

-------- Forwarded Message --------
Subject: 答复: Regarding IPR on draft-ietf-teas-native-ip-scenarios-04
Date: Wed, 12 …
final response received in e-mail but didn't make it to the archive!

-------- Forwarded Message --------
Subject: 答复: Regarding IPR on draft-ietf-teas-native-ip-scenarios-04
Date: Wed, 12 Jun 2019 07:03:48 +0000
From: Mipenghui (Kevin Mi) <mipenghui@huawei.com>
To: Aijun Wang <wangaj.bri@chinatelecom.cn>, 'Lou Berger' <lberger@labn.net>, huangxh@bupt.edu.cn <huangxh@bupt.edu.cn>, koucx@lsec.cc.ac.cn <koucx@lsec.cc.ac.cn>, li_zhenqiang@hotmail.com <li_zhenqiang@hotmail.com>
CC: 'TEAS WG' <teas@ietf.org>

Hi, All:

No, I'm not aware of any IPR that applies to this draft.

Thanks,

Penghui Mi
2019-06-13
05 Lou Berger Pre LC: IPR Poll https://mailarchive.ietf.org/arch/msg/teas/AwyYxqMzXaDbKLOve4uJNfKsj_U

Missing: Penghui Mi

Received:
Aijun Wang:  https://mailarchive.ietf.org/arch/msg/teas/TJH4xphxKjFkS_BiR9TIgryD-0M
Huang Xiaohong: https://mailarchive.ietf.org/arch/msg/teas/JTlR8EHs47itcmZS-wE0WWjh-zQ
寇彩霞 (Caixia Kou): https://mailarchive.ietf.org/arch/msg/teas/RJob3Yuy9r5lnw2AjEOz1jrB2wg
li zhenqiang: https://mailarchive.ietf.org/arch/msg/teas/PDuETMRfiuFFfar3xfEbSKBTpUE
2019-06-11
05 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-05.txt
2019-06-11
05 (System) New version approved
2019-06-11
05 (System)
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Aijun Wang <wangaj.bri@chinatelecom.cn>, Caixia Qou …
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Aijun Wang <wangaj.bri@chinatelecom.cn>, Caixia Qou <koucx@lsec.cc.ac.cn>, Penghui Mi <mipenghui@huawei.com>
2019-06-11
05 Aijun Wang Uploaded new revision
2019-06-03
04 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-04.txt
2019-06-03
04 (System) New version approved
2019-06-03
04 (System)
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Aijun Wang <wangaj.bri@chinatelecom.cn>, Caixia Qou …
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Aijun Wang <wangaj.bri@chinatelecom.cn>, Caixia Qou <koucx@lsec.cc.ac.cn>, Penghui Mi <mipenghui@huawei.com>
2019-06-03
04 Aijun Wang Uploaded new revision
2019-04-09
03 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-03.txt
2019-04-09
03 (System) New version approved
2019-04-09
03 (System)
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Aijun Wang <wangaj.bri@chinatelecom.cn>, Caixia Qou …
Request for posting confirmation emailed to previous authors: Xiaohong Huang <huangxh@bupt.edu.cn>, Zhenqiang Li <li_zhenqiang@hotmail.com>, Aijun Wang <wangaj.bri@chinatelecom.cn>, Caixia Qou <koucx@lsec.cc.ac.cn>, Penghui Mi <mipenghui@huawei.com>
2019-04-09
03 Aijun Wang Uploaded new revision
2018-10-22
02 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-02.txt
2018-10-22
02 (System) New version approved
2018-10-22
02 (System)
Request for posting confirmation emailed to previous authors: Zhenqiang Li <li_zhenqiang@hotmail.com>, Xiaohong Huang <huangxh@bupt.edu.cn>, teas-chairs@ietf.org, Lu Huang <hlisname@yahoo.com>, …
Request for posting confirmation emailed to previous authors: Zhenqiang Li <li_zhenqiang@hotmail.com>, Xiaohong Huang <huangxh@bupt.edu.cn>, teas-chairs@ietf.org, Lu Huang <hlisname@yahoo.com>, Caixia Qou <koucx@lsec.cc.ac.cn>, Penghui Mi <mipenghui@huawei.com>, Aijun Wang <wangaj.bri@chinatelecom.cn>
2018-10-22
02 Aijun Wang Uploaded new revision
2018-06-27
01 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-01.txt
2018-06-27
01 (System) New version approved
2018-06-27
01 (System)
Request for posting confirmation emailed to previous authors: Kevin Mi <kevinmi@tencent.com>, Xiaohong Huang <huangxh@bupt.edu.cn>, teas-chairs@ietf.org, Lu Huang <hlisname@yahoo.com>, …
Request for posting confirmation emailed to previous authors: Kevin Mi <kevinmi@tencent.com>, Xiaohong Huang <huangxh@bupt.edu.cn>, teas-chairs@ietf.org, Lu Huang <hlisname@yahoo.com>, Caixia Qou <koucx@lsec.cc.ac.cn>, Aijun Wang <wangaj.bri@chinatelecom.cn>
2018-06-27
01 Aijun Wang Uploaded new revision
2018-02-15
00 Vishnu Beeram This document now replaces draft-wang-teas-ccdr instead of None
2018-02-12
00 Aijun Wang New version available: draft-ietf-teas-native-ip-scenarios-00.txt
2018-02-12
00 (System) WG -00 approved
2018-02-12
00 Aijun Wang Set submitter to "Aijun Wang <wangaj.bri@chinatelecom.cn>", replaces to (none) and sent approval email to group chairs: teas-chairs@ietf.org
2018-02-12
00 Aijun Wang Uploaded new revision