Skip to main content

PCE-Based Traffic Engineering (TE) in Native IP Networks
draft-ietf-teas-pce-native-ip-17

Revision differences

Document history

Date Rev. By Action
2024-01-26
17 Gunter Van de Velde Request closed, assignment withdrawn: Jouni Korhonen Last Call OPSDIR review
2024-01-26
17 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2021-04-01
17 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-03-30
17 (System) RFC Editor state changed to AUTH48
2021-03-03
17 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-02-11
17 (System) IANA Action state changed to No IANA Actions from In Progress
2021-02-05
17 (System) RFC Editor state changed to EDIT
2021-02-05
17 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-02-05
17 (System) Announcement was received by RFC Editor
2021-02-05
17 (System) IANA Action state changed to In Progress
2021-02-05
17 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2021-02-05
17 Cindy Morgan IESG has approved the document
2021-02-05
17 Cindy Morgan Closed "Approve" ballot
2021-02-05
17 Cindy Morgan Ballot approval text was generated
2021-02-05
17 Cindy Morgan Ballot writeup was changed
2021-02-05
17 Deborah Brungard Ballot approval text was changed
2021-02-01
17 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-17.txt
2021-02-01
17 (System) New version approved
2021-02-01
17 (System) Request for posting confirmation emailed to previous authors: Aijun Wang , Boris Khasanov , Huaimo Chen , Quintin Zhao
2021-02-01
17 Aijun Wang Uploaded new revision
2021-01-22
16 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events'
2021-01-22
16 Jean Mahoney Assignment of request for Last Call review by GENART to Francesca Palombini was marked no-response
2021-01-21
16 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-16.txt
2021-01-21
16 (System) New version approved
2021-01-21
16 (System) Request for posting confirmation emailed to previous authors: Aijun Wang , Boris Khasanov , Huaimo Chen , Quintin Zhao
2021-01-21
16 Aijun Wang Uploaded new revision
2021-01-21
15 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2021-01-21
15 Magnus Westerlund
[Ballot comment]
I think this whole idea is based on the fact that you can actually have multiple different prefix the traffic based on the …
[Ballot comment]
I think this whole idea is based on the fact that you can actually have multiple different prefix the traffic based on the network treatment it should have. I think that has very limited applicability unless we are talking a deployment where one target tunnels between in ingress and egress that does traffic classification based on other aspects. Can this assumption about that the IP traffic needs to use different IP addresses with different prefix to get any differential treatment be expanded in the discussion?
2021-01-21
15 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2021-01-21
15 Robert Wilton
[Ballot comment]
Hi,

It might be helpful if this document had a short section covering operational considerations for monitoring and managing TE traffic when being …
[Ballot comment]
Hi,

It might be helpful if this document had a short section covering operational considerations for monitoring and managing TE traffic when being deployed in this way.

Regards,
Rob
2021-01-21
15 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-01-21
15 Benjamin Kaduk
[Ballot comment]
Even if this is no longer characterized as "experimental" I agree with
the rtgdir reviewer that it would be interesting to eventually see …
[Ballot comment]
Even if this is no longer characterized as "experimental" I agree with
the rtgdir reviewer that it would be interesting to eventually see a report of the
results of the not-experiment, when known.

Section 4

  When the priority traffic spans a large scale network, such as that
  illustrated in Figure 2, the multiple BGP sessions cannot be
  established hop by hop, for example, the iBGP within one AS.

nit: what is "the iBGP within one AS" an example of?  If it's "a large
scale network" that priority traffic spans, this clause should probably
be relocated.

Section 5

  For Prefix Set No.1, we can select the shortest distance path to
  carry the traffic; for Prefix Set No.2, we can select the path that
  has end to end under loaded links; for Prefix Set No.3, we can let

nit: hyphenate "under-loaded links".

Section 6

  o  Advertised prefixes and their associated BGP session.

Is conveying BGP session information via PCEP going to introduce an
additional layer of statefullness to the system?  Or will the PCEP be
able to determine and configure everything in a single pass as it
currently does?

Section 7.1

I agree with Alvaro that the comparison to flowspec is not serving a
useful purpose in its present form.

Section 8

Increasing the number of BGP sessions (and router loopback addresses,
routes, etc.) seems like it would incrementally add to the baseline load
on such systems, and thus the risk that transient spikes in load could
lead to denial of service.

Section 11.1

It's not entirely clear to me that, at least based on where we currently
reference it, RFC 4655 needs to be characterized as normative.

I also don't think that RFC 8735 needs to be normative; we seem to
replicate the key list of requirements and not rely on the reference for
them.

Section 11.2

On the other hand, if the extensionns from
draft-ietf-pce-pcep-extension-native-ip are truly necessary for the
system to work (per §6), then it needs to be characterized as normative.
2021-01-21
15 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-01-20
15 Roman Danyliw
[Ballot comment]
Thanks to Donald Eastlake for the SECDIR review

** Section 8.  Since PCE is used to setup the BGP sessions, etc., the references …
[Ballot comment]
Thanks to Donald Eastlake for the SECDIR review

** Section 8.  Since PCE is used to setup the BGP sessions, etc., the references to the Security Considerations of PCE specs should be reiterated as applying – minimally RFC5440 and RFC8231

** To restate Alvaro Retana's comment #9, RFC8231 already notes that malicious PCE and PCCs are possible (see above comment).  In this context, the new variant relevant to this architecture would be in form of (malicious) BGP configurations.  It's worth highlighting.
2021-01-20
15 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-01-20
15 Martin Duke
[Ballot comment]
I am a bit confused that a design objective (sec 1) is “ No changes in a router's forwarding behavior”. Isn’t that what …
[Ballot comment]
I am a bit confused that a design objective (sec 1) is “ No changes in a router's forwarding behavior”. Isn’t that what this whole draft is about?
2021-01-20
15 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-01-20
15 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. I love the oxymoron approach with "The solution combines the use of distributed routing …
[Ballot comment]
Thank you for the work put into this document. I love the oxymoron approach with "The solution combines the use of distributed routing protocols and a centralized controller" ;-)

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Am I right when inferring that for each TE path there is a need to add one loopback interface/address on every edge router + 1 BGP session ? How will it scale ? Should there be a mention somewhere of this limitation (if confirmed) ? I saw nothing in section 7.1 (scalability).


-- Abstract --
"it ... identifies needed extensions for the Path Computation Element Communication Protocol (PCEP)", at first sight, it seems that it is an incomplete document or a problem statement until reading the last sentence of the introduction. May I suggest to change the sentence in the abstract in a more assertive way ?

-- Section 3 --
Suggest to define the lo11 & others as the loopback interfaces in the first bullet in the list.

I am far from being an expert in BGP and routing but isn't the link selection still done *only* on the destination prefix ? I fail to see how the source prefix is used in the forwarding decision (except for the return traffic). I.e., there is no traffic isolation as PF11 can sent traffic to PF22 using the link 'reserved' for PF12 to PF22.

-- Section 4 --
Suggest to add 'RR' in the R3 box.

== NITS ==

several s/large scale/large-scale/ ?

The usual way for acronyms is "Path Computation Client (PCC)" rather than "PCC (Path Computation Client)"
2021-01-20
15 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-01-19
15 Alvaro Retana
[Ballot comment]
I have some significant issues with this document.  While none of these raise
to the level of a DISCUSS, they result in what …
[Ballot comment]
I have some significant issues with this document.  While none of these raise
to the level of a DISCUSS, they result in what I consider an incomplete
document, and I would want them to be addressed before publication --
specifically points 1-5.


(1) In general, the solution presented seems to assume that there will be an
independent E2E physical path per priority group/set of prefixes.  As the
number of groups/sets increases, the probability of finding node-disjoint
paths across a network diminishes significantly.  Link-disjoint paths can
also have issues.  I would like to see a discussion about the required
disjointness, and considerations for reusing links/nodes.


(2) §6: "Different BGP sessions are used mainly for the clarification of the
network prefixes, which can be differentiated via the different BGP nexthop."
I would be interested to understand why simply advertising a different
NEXT_HOP, while maintaining a single BGP session was discarded as part of the
solution.  As you mention in this sentence, the real differentiator is the
next hop -- if the advertised prefixes are always different then changing the
NEXT_HOP should also be a valid solution.  Given that this document defines
the architecture, and that the PCEP extensions will be based on it, it would
be ideal if alternate implementations (minimally different in this case) were not precluded.

  [Disclaimer: I haven't looked at I-D.ietf-pce-pcep-extension-native-ip in
  detail, but it looks like using a single BGP session is not supported. :-(]


(3) §7.1: "the on-path router needs only to keep the specific policy routes
for the BGP next-hop of the differentiate prefixes, not the specific routes to
the prefixes themselves. ... For example, if we want to differentiate 1000
prefixes from the normal traffic, CCDR needs only one explicit peer route in
every on-path router."  You may need to expand on this concept.  As far as I
can tell, the traffic is natively transported through the network, with a
destination IP address corresponding to one of the differentiated prefixes,
not the BGP next hop.  IOW, routes to the prefixes are still needed (as
explained in §3/§4), but the steering is achieved through the individual
"explicit peer routes".  Am I missing something?


(4) §7.2: "If one node on the optimal path fails, the priority traffic will
fall over to the best-effort forwarding path."  This statement is only
true/possible if the prefixes associated with the priority traffic are also
advertised through the BGP sessions associated with the best-effort path...or
if there is an alternate path to the corresponding next-hop.  Neither of these
options is explained in §3-5.


(5) This document provides a description of the architecture, and as mentioned
in §6: "Details...are out of scope of this draft and will be described in a
separate document [I-D.ietf-pce-pcep-extension-native-ip]."  However, the
description depends on the extensions/behavior from
I-D.ietf-pce-pcep-extension-native-ip in a couple of places:

§5:
  o  PCE sends the route information to the routers (R1,R2,R4,R7 in
      Figure 3) on the forwarding path via PCEP
      [I-D.ietf-pce-pcep-extension-native-ip], to build the path to the
      BGP next-hop of the advertised prefixes.

§7.3:
  Not every router within the network needs to support the PCEP
  extension defined in [I-D.ietf-pce-pcep-extension-native-ip]
  simultaneously.


These references make I-D.ietf-pce-pcep-extension-native-ip a normative
reference because it is necessary to implement the architecture.  Please write
these two paragraphs in a solution-neutral way (using
I-D.ietf-pce-pcep-extension-native-ip as an example is ok).


(6) §5: "PCE sends the prefixes information to the PCC for advertising
different prefixes via the specified BGP session."  Specifically, I think you
mean the RR.  s/PCC/RR


(7) §7.1: "Unlike the solution from BGP Flowspec[I-D.ietf-idr-rfc5575bis]..."
This is the only place where flowspec is mentioned.  Referencing a different
potential solution without a proper comparison (either in this document or
rfc8736, where it is not even mentioned) is out of place.  Please focus on the
considerations related to this solution, and not the potential downsides of
others.


(8) §8: "See [RFC7454] for BGP security consideration."  rfc7454 is not the
best reference for BGP-specific security considerations, please use
rfc4271/rfc4272 instead (or in addition).


(9) §8: Note that even if the PCE/PCC connection is secured, a rogue PCE may
still harm the network: it may set up more BGP sessions than required
(resulting in more control traffic, routes, etc.), it may direct the BGP
speakers to advertise the wrong routes (more, less, etc.), it may instantiate
incorrect explicit routes...  While this is not a new risk, it should me
mentioned in the context of the described architecture.


(10) [nits]

§2: s/Other terms are defined in this document/Other terms are used in this document

§3: s/in simple topology/in a simple topology

§3: s/topology is comprises/topology comprises

§4: s/for example, the iBGP within one AS/for example, using iBGP within one AS

5: s/as that described in/as described in
2021-01-19
15 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-01-19
15 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2021-01-19
15 Murray Kucherawy
[Ballot comment]
Just some nits here, adding to what Erik found:

Section 3:

"The topology is comprises four devices ..." should be "The topology is …
[Ballot comment]
Just some nits here, adding to what Erik found:

Section 3:

"The topology is comprises four devices ..." should be "The topology is comprised of four devices ..." or "The topology comprises four devices ..."

In the third bullet: "For example, PF11/PF21 via ..." -- I suggest putting "send" before "PF11/PF21".

"... achieving the needed QoS assurance ..." -- suggest changing "achieving" to "satisfying" (since you used "achieve" already in that sentence)

Section 4:

I can't quite parse the first sentence, specifically the end of it.

Section 5:

"... is as the follows:" -- remove "the"

Section 8:

"... BGP security consideration." -- s/consideration/considerations/

"There will no additional ..." -- add "be" before "no", or change "will" to "are"
2021-01-19
15 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-01-16
15 Erik Kline
[Ballot comment]
[[ nits ]]

[ section 3 ]

* s/The topology is comprises/The topology comprises/

  or

  s/The topology is comprises/The topology is …
[Ballot comment]
[[ nits ]]

[ section 3 ]

* s/The topology is comprises/The topology comprises/

  or

  s/The topology is comprises/The topology is composed of/

  I think.

[ section 7.1 ]

* s/of the differentiate prefixes/of the different prefixes/?
2021-01-16
15 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-12-18
15 Amy Vezza Placed on agenda for telechat - 2021-01-21
2020-12-18
15 Deborah Brungard Ballot has been issued
2020-12-18
15 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2020-12-18
15 Deborah Brungard Created "Approve" ballot
2020-12-18
15 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2020-12-18
15 Deborah Brungard Ballot writeup was changed
2020-12-18
15 Deborah Brungard
> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.

> This …
> 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 1 November 2019.

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

This document defines an approach to IP traffic engineering
using BGP and PCE.  There is general consensus that this is interesting
work and it would be beneficial to the WG in developing a
possible future proposed standard solution in this space.

> 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 defines an architecture for providing traffic
  engineering in a native IP network using multiple BGP sessions and a
  Path Computation Element (PCE)-based central control mechanism.  It
  defines the Central Control Dynamic Routing (CCDR) procedures and
  identifies needed extensions for the Path Computation Element
  Communication Protocol (PCEP).

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

There were occasional requests from the authors to move this away from
Experimental, which it was initially, it was decided then to move to
Informational in consultation with our AD.

> 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, YANG 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?

The quality is sufficient for the stated purpose of the document.

> 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 reread this document as it progressed as well as in its final
form.  All significant comments have been addressed. The document is
ready for publication.


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

The document relates to work on-going in the PCE wg.  WG LC was
coordinated with the PCE WG chairs and announced on the PCE WG list.

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

> (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/detnet/oCh4L5p5qPO26RfV7RDP_UxzRac/


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

There was no specific discussion on the disclosures other than pointing
out to the WG that the disclosures existed both during adoption and WG LC.

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

I think the document has good support from a narrow set of WG participants.

> (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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

Idnits issues have been fixed.

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

N/A.

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

No.

> (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, N/A.

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

No requests are made in the document.

> (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, YANG modules,
> etc.

N/A

> (20) If the document contains a YANG module, has the module been checked
> with any of the recommended validation tools
> (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
> formatting validation? If there are any resulting errors or warnings,
> what is the justification for not fixing them at this time? Does the
> YANG module comply with the Network Management Datastore Architecture
> (NMDA) as specified in RFC8342?

There are no yang models.
2020-12-10
15 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Donald Eastlake. Submission of review completed at an earlier date.
2020-12-10
15 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-12-09
15 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2020-12-09
15 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-teas-pce-native-ip-14, 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-pce-native-ip-14, 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
2020-12-08
15 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-15.txt
2020-12-08
15 (System) New version approved
2020-12-08
15 (System) Request for posting confirmation emailed to previous authors: Quintin Zhao , Boris Khasanov , Huaimo Chen , Aijun Wang
2020-12-08
15 Aijun Wang Uploaded new revision
2020-12-07
15 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Donald Eastlake.
2020-12-03
14 Jean Mahoney Request for Last Call review by GENART is assigned to Francesca Palombini
2020-12-03
14 Jean Mahoney Request for Last Call review by GENART is assigned to Francesca Palombini
2020-12-03
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2020-12-03
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2020-11-26
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2020-11-26
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2020-11-26
14 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-11-26
14 Amy Vezza
The following Last Call announcement was sent out (ends 2020-12-10):

From: The IESG
To: IETF-Announce
CC: lberger@labn.net, draft-ietf-teas-pce-native-ip@ietf.org, teas@ietf.org, db3546@att.com, teas-chairs@ietf.org …
The following Last Call announcement was sent out (ends 2020-12-10):

From: The IESG
To: IETF-Announce
CC: lberger@labn.net, draft-ietf-teas-pce-native-ip@ietf.org, teas@ietf.org, db3546@att.com, teas-chairs@ietf.org, Lou Berger
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (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: - 'PCE in Native IP
Network'
  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
last-call@ietf.org mailing lists by 2020-12-10. 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


  This document defines an architecture for providing traffic
  engineering in a native IP network using multiple BGP sessions and a
  Path Computation Element (PCE)-based central control mechanism.  It
  defines the Central Control Dynamic Routing (CCDR) procedures and
  identifies needed extensions for the Path Computation Element
  Communication Protocol (PCEP).




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


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3144/
  https://datatracker.ietf.org/ipr/3134/





2020-11-26
14 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-11-26
14 Deborah Brungard Last call was requested
2020-11-26
14 Deborah Brungard Ballot approval text was generated
2020-11-26
14 Deborah Brungard Ballot writeup was generated
2020-11-26
14 Deborah Brungard IESG state changed to Last Call Requested from Expert Review
2020-11-26
14 Deborah Brungard Last call announcement was changed
2020-11-25
14 Deborah Brungard Changed consensus to Yes from Unknown
2020-11-25
14 Deborah Brungard Intended Status changed to Informational from Experimental
2020-11-24
14 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-14.txt
2020-11-24
14 (System) New version approved
2020-11-24
14 (System) Request for posting confirmation emailed to previous authors: Boris Khasanov , Huaimo Chen , Quintin Zhao , Aijun Wang
2020-11-24
14 Aijun Wang Uploaded new revision
2020-11-15
13 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-13.txt
2020-11-15
13 (System) New version approved
2020-11-15
13 (System) Request for posting confirmation emailed to previous authors: Huaimo Chen , Boris Khasanov , Aijun Wang , Quintin Zhao
2020-11-15
13 Aijun Wang Uploaded new revision
2020-10-28
12 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-12.txt
2020-10-28
12 (System) New version approved
2020-10-28
12 (System) Request for posting confirmation emailed to previous authors: teas-chairs@ietf.org, Aijun Wang , Boris Khasanov , Quintin Zhao , Huaimo Chen
2020-10-28
12 Aijun Wang Uploaded new revision
2020-08-25
11 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-11.txt
2020-08-25
11 (System) New version approved
2020-08-25
11 (System) Request for posting confirmation emailed to previous authors: Huaimo Chen , Boris Khasanov , Aijun Wang , Quintin Zhao
2020-08-25
11 Aijun Wang Uploaded new revision
2020-08-10
10 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-10.txt
2020-08-10
10 (System) New version approved
2020-08-10
10 (System) Request for posting confirmation emailed to previous authors: Boris Khasanov , Quintin Zhao , Huaimo Chen , Aijun Wang
2020-08-10
10 Aijun Wang Uploaded new revision
2020-08-07
09 Min Ye Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Loa Andersson.
2020-07-28
09 Deborah Brungard RTG Dir reviewer: Loa Andersson
2020-07-28
09 Deborah Brungard IESG state changed to Expert Review from Publication Requested
2020-06-23
09 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Loa Andersson
2020-06-23
09 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Loa Andersson
2020-06-22
09 Deborah Brungard Requested Last Call review by RTGDIR
2020-06-12
09 Lou Berger
> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.

> This …
> 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 1 November 2019.

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Experimental

> Why is this the proper type of RFC?

This document defines an experimental approach to IP traffic engineering
using BGP and PCE.  There is general consensus that this is interesting
work and more data would be beneficial to the WG in developing a
possible future proposed standard solution in this space.

> 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 defines the framework for traffic engineering within
  native IP network, using multiple BGP sessions strategy and PCE
  -based central control architecture.  The procedures described in
  this document are experimental.  The experiment is intended to enable
  research for the usage of PCE in native IP scenarios.  For this
  purpose, this document describe the Central Control Dynamic Routing
  (CCDR) framework and the PCEP extension is specified in
  [I-D.ietf-pce-pcep-extension-native-ip].

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

There were occasional requests from the authors to move this away from
Experimental, but there was not general support for this in 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, YANG 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?

The quality is sufficient for the stated purpose of the document.

> 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 reread this document as it progressed as well as in its final
form.  All significant comments have been addressed. The document is
ready for publication as an Experimental RFC.


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

The document relates to work on-going in the PCE wg.  WG LC was
coordinated with the PCE WG chairs and announced on the PCE WG list.

> (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 concerns, assuming published as Experimental.

> (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/detnet/oCh4L5p5qPO26RfV7RDP_UxzRac/


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

There was no specific discussion on the disclosures other than pointing
out to the WG that the disclosures existed both during adoption and WG LC.

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

I think the document has good support from a narrow set of WG participants.

> (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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

Idnits issues have been fixed.

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

N/A.

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

No.

> (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, N/A.

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

No requests are made in the document.

> (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, YANG modules,
> etc.

N/A

> (20) If the document contains a YANG module, has the module been checked
> with any of the recommended validation tools
> (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
> formatting validation? If there are any resulting errors or warnings,
> what is the justification for not fixing them at this time? Does the
> YANG module comply with the Network Management Datastore Architecture
> (NMDA) as specified in RFC8342?

There are no yang models.
2020-06-12
09 Lou Berger Responsible AD changed to Deborah Brungard
2020-06-12
09 Lou Berger IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2020-06-12
09 Lou Berger IESG state changed to Publication Requested from I-D Exists
2020-06-12
09 Lou Berger IESG process started in state Publication Requested
2020-06-12
09 Lou Berger Tag Revised I-D Needed - Issue raised by WGLC cleared.
2020-06-07
09 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-09.txt
2020-06-07
09 (System) New version approved
2020-06-07
09 (System) Request for posting confirmation emailed to previous authors: Boris Khasanov , Aijun Wang , Huaimo Chen , Quintin Zhao
2020-06-07
09 Aijun Wang Uploaded new revision
2020-06-07
08 Lou Berger https://mailarchive.ietf.org/arch/msg/teas/BjfMuu9itdC-N15dkSDwVc_91nk/
2020-06-07
08 Lou Berger Tag Revised I-D Needed - Issue raised by WGLC set.
2020-06-07
08 Lou Berger IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Document
2020-06-07
08 Lou Berger
> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.

> This …
> 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 1 November 2019.

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Experimental

> Why is this the proper type of RFC?

This document defines an experimental approach to IP traffic engineering
using BGP and PCE.  There is general consensus that this is interesting
work and more data would be beneficial to the WG in developing a
possible future proposed standard solution in this space.

> 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 defines the framework for traffic engineering within
  native IP network, using multiple BGP sessions strategy and PCE
  -based central control architecture.  The procedures described in
  this document are experimental.  The experiment is intended to enable
  research for the usage of PCE in native IP scenarios.  For this
  purpose, this document describe the Central Control Dynamic Routing
  (CCDR) framework and the PCEP extension is specified in
  [I-D.ietf-pce-pcep-extension-native-ip].

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

There were occasional requests from the authors to move this away from
Experimental, but there was not general support for this in 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, YANG 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?

The quality is sufficient for the stated purpose of the document.

> 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 reread this document as it progressed as well as in its final
form.  All significant comments have been addressed. The document is
ready for publication as an Experimental RFC.


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

The document relates to work on-going in the PCE wg.  WG LC was
coordinated with the PCE WG chairs and announced on the PCE WG list.

> (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 concerns, assuming published as Experimental.

> (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/detnet/oCh4L5p5qPO26RfV7RDP_UxzRac/


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

There was no specific discussion on the disclosures other than pointing
out to the WG that the disclosures existed both during adoption and WG LC.

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

I think the document has good support from a narrow set of WG participants.

> (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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

Idnits issues have been fixed.

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

N/A.

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

No.

> (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, N/A.

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

No requests are made in the document.

> (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, YANG modules,
> etc.

N/A

> (20) If the document contains a YANG module, has the module been checked
> with any of the recommended validation tools
> (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
> formatting validation? If there are any resulting errors or warnings,
> what is the justification for not fixing them at this time? Does the
> YANG module comply with the Network Management Datastore Architecture
> (NMDA) as specified in RFC8342?

There are no yang models.
2020-06-01
08 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-08.txt
2020-06-01
08 (System) New version approved
2020-06-01
08 (System) Request for posting confirmation emailed to previous authors: Quintin Zhao , Huaimo Chen , Boris Khasanov , Aijun Wang
2020-06-01
08 Aijun Wang Uploaded new revision
2020-05-31
07 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-07.txt
2020-05-31
07 (System) New version approved
2020-05-31
07 (System) Request for posting confirmation emailed to previous authors: Quintin Zhao , Huaimo Chen , Aijun Wang , Boris Khasanov
2020-05-31
07 Aijun Wang Uploaded new revision
2020-05-15
06 Lou Berger
Responses in thread: https://mailarchive.ietf.org/arch/msg/teas/0oDaNW9JIZ0HcA2oxWZDh25OdIs/
[Teas] 答复: Regarding IPR on draft-ietf-teas-pce-n…  Aijun Wang
Re: [Teas] Regarding IPR on draft-ietf-teas-pce-n…  Khasanov Boris
Re: [Teas] Regarding IPR on …
Responses in thread: https://mailarchive.ietf.org/arch/msg/teas/0oDaNW9JIZ0HcA2oxWZDh25OdIs/
[Teas] 答复: Regarding IPR on draft-ietf-teas-pce-n…  Aijun Wang
Re: [Teas] Regarding IPR on draft-ietf-teas-pce-n…  Khasanov Boris
Re: [Teas] Regarding IPR on draft-ietf-teas-pce-n…  Huaimo Chen
Re: [Teas] Regarding IPR on draft-ietf-teas-pce-n…  Quintin Zhao
2020-05-14
06 Lou Berger Aijun Wang received

Still missing:
      Quintin Zhao
      Boris Khasanov
      Huaimo Chen
2020-05-14
06 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-06.txt
2020-05-14
06 (System) New version approved
2020-05-14
06 (System) Request for posting confirmation emailed to previous authors: Aijun Wang , Boris Khasanov , teas-chairs@ietf.org, Huaimo Chen , Quintin Zhao
2020-05-14
06 Aijun Wang Uploaded new revision
2020-05-13
05 Lou Berger
IPR Call started: https://mailarchive.ietf.org/arch/msg/teas/0oDaNW9JIZ0HcA2oxWZDh25OdIs/

1 bouncing:
(expanded from
    ): host
    mx5.huawei.com[103.218.216.136] said: 550 5.1.1 Error: invalid recipients
    is …
IPR Call started: https://mailarchive.ietf.org/arch/msg/teas/0oDaNW9JIZ0HcA2oxWZDh25OdIs/

1 bouncing:
(expanded from
    ): host
    mx5.huawei.com[103.218.216.136] said: 550 5.1.1 Error: invalid recipients
    is found from 4.31.198.44 (in reply to RCPT TO command)
2020-05-13
05 Lou Berger Notification list changed to Lou Berger <lberger@labn.net>
2020-05-13
05 Lou Berger Document shepherd changed to Lou Berger
2020-05-13
05 Lou Berger Intended Status changed to Experimental from None
2020-01-09
05 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-05.txt
2020-01-09
05 (System) New version approved
2020-01-09
05 (System) Request for posting confirmation emailed to previous authors: Huaimo Chen , Boris Khasanov , teas-chairs@ietf.org, Raghavendra Mallya , Quintin Zhao , Aijun Wang
2020-01-09
05 Aijun Wang Uploaded new revision
2019-08-25
04 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-04.txt
2019-08-25
04 (System) New version approved
2019-08-25
04 (System) Request for posting confirmation emailed to previous authors: Boris Khasanov , teas-chairs@ietf.org, Raghavendra Mallya , Quintin Zhao , Huaimo Chen , Aijun Wang
2019-08-25
04 Aijun Wang Uploaded new revision
2019-04-15
03 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-03.txt
2019-04-15
03 (System) New version approved
2019-04-15
03 (System) Request for posting confirmation emailed to previous authors: Huaimo Chen , Raghavendra Mallya , Boris Khasanov , Quintin Zhao , Aijun Wang
2019-04-15
03 Aijun Wang Uploaded new revision
2018-10-22
02 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-02.txt
2018-10-22
02 (System) New version approved
2018-10-22
02 (System)
Request for posting confirmation emailed to previous authors: Penghui Mi , Boris Khasanov , teas-chairs@ietf.org, Raghavendra Mallya , Quintin Zhao , Huaimo Chen , …
Request for posting confirmation emailed to previous authors: Penghui Mi , Boris Khasanov , teas-chairs@ietf.org, Raghavendra Mallya , Quintin Zhao , Huaimo Chen , Shaofu Peng , Aijun Wang
2018-10-22
02 Aijun Wang Uploaded new revision
2018-06-27
01 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-01.txt
2018-06-27
01 (System) New version approved
2018-06-27
01 (System) Request for posting confirmation emailed to previous authors: Quintin Zhao , Kevin Mi , Boris Khasanov , teas-chairs@ietf.org, Aijun Wang
2018-06-27
01 Aijun Wang Uploaded new revision
2018-02-15
00 Vishnu Beeram This document now replaces draft-wang-teas-pce-native-ip instead of None
2018-02-14
Jenny Bui Posted related IPR disclosure: China Telecom's Statement about IPR related to draft-ietf-teas-pce-native-ip
2018-02-12
00 Aijun Wang New version available: draft-ietf-teas-pce-native-ip-00.txt
2018-02-12
00 (System) WG -00 approved
2018-02-12
00 Aijun Wang Set submitter to "Aijun Wang ", replaces to (none) and sent approval email to group chairs: teas-chairs@ietf.org
2018-02-12
00 Aijun Wang Uploaded new revision