Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering
draft-ietf-pce-pcecp-interarea-reqs-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2007-03-19
|
05 | (System) | IANA Action state changed to No IC from In Progress |
2007-03-19
|
05 | (System) | IANA Action state changed to In Progress |
2007-03-16
|
05 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-03-15
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-03-15
|
05 | Amy Vezza | IESG has approved the document |
2007-03-15
|
05 | Amy Vezza | Closed "Approve" ballot |
2007-03-13
|
05 | Ross Callon | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon |
2007-03-12
|
05 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2007-03-09
|
05 | Samuel Weiler | Request for Telechat review by SECDIR Completed. Reviewer: Catherine Meadows. |
2007-03-09
|
05 | (System) | Removed from agenda for telechat - 2007-03-08 |
2007-03-08
|
05 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2007-03-08
|
05 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2007-03-08
|
05 | Dan Romascanu | [Ballot discuss] The Manageability Considerations section includes the following: A built in diagnostic tool MUST be defined to monitor the performances of a … [Ballot discuss] The Manageability Considerations section includes the following: A built in diagnostic tool MUST be defined to monitor the performances of a PCE chain, in case of multiple-PCE inter-area path computation. It MUST allow determining the minimum maximum and average response time globally for the chain, and on a per PCE basis. It is not clear to me what a 'built in diagnostic tool' means in this context. The IETF does not usually define device level diagnostic tools, and this looks more like a network level capability targeting measurments of the performance of the PCE chain, but I may be wrong. In any case, are we shure this is a MUST requirement for interarea pcecp? If so I would suggest that we clarify or change the terminology and include text that explains why such a capability is mandatory or very important for the deployment and operations of the protocol. |
2007-03-08
|
05 | Dan Romascanu | [Ballot discuss] The Manageability Considerations section includes the following: A built in diagnostic tool MUST be defined to monitor the performances of a … [Ballot discuss] The Manageability Considerations section includes the following: A built in diagnostic tool MUST be defined to monitor the performances of a PCE chain, in case of multiple-PCE inter-area path computation. It MUST allow determining the minimum maximum and average response time globally for the chain, and on a per PCE basis. It is not clear to me what a 'built in diagnostic tool' means in this context. The IETF does not usually define device level diagnostic tools, and this looks more like a network level capability targeting measurments of the performance of the PCE chain, but I may be wrong. In any case, are we shure this is a MUST requirement for interarea pcecp? If so I would suggest that we clarify or change the terminology and include text that explains why such a capability is mandatory or very important for the deployment and operations of the protocol. |
2007-03-08
|
05 | Dan Romascanu | [Ballot discuss] The Manageability Considerations section includes the following: |
2007-03-08
|
05 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2007-03-08
|
05 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2007-03-07
|
05 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded by David Kessens |
2007-03-07
|
05 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie |
2007-03-07
|
05 | Russ Housley | [Ballot comment] From the SecDir Review by Cathy Meadows: RFC 4657 explicitly includes multi-area networks among multi-domain networks. It then goes on the … [Ballot comment] From the SecDir Review by Cathy Meadows: RFC 4657 explicitly includes multi-area networks among multi-domain networks. It then goes on the say, in the security considerations section: Of particular relevance are the implications for confidentiality inherent in a PCECP for multi-domain networks. It is not necessarily the case that a multi-domain PCE solution will compromise security, but solutions MUST examine their impacts in this area. More needs to be said aboutt multi-area routing and trust issues. The document says that it does not open up any new trust issues. Even though the different areas are administered by the same entity, there may still be issues if one or more of the areas is compromised. |
2007-03-07
|
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2007-03-07
|
05 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2007-03-05
|
05 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter |
2007-03-05
|
05 | Yoshiko Fong | IANA Evaluation Comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2007-03-02
|
05 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2007-03-02
|
05 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Catherine Meadows |
2007-03-02
|
05 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Catherine Meadows |
2007-02-28
|
05 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon |
2007-02-28
|
05 | Ross Callon | Ballot has been issued by Ross Callon |
2007-02-28
|
05 | Ross Callon | Created "Approve" ballot |
2007-02-28
|
05 | (System) | Ballot writeup text was added |
2007-02-28
|
05 | (System) | Last call text was added |
2007-02-28
|
05 | (System) | Ballot approval text was added |
2007-02-28
|
05 | Ross Callon | Placed on agenda for telechat - 2007-03-08 by Ross Callon |
2007-02-28
|
05 | Ross Callon | State Changes to IESG Evaluation from AD Evaluation by Ross Callon |
2007-02-01
|
05 | Ross Callon | State Changes to AD Evaluation from Publication Requested by Ross Callon |
2007-01-05
|
05 | Ross Callon | PROTO writeup by JP Vasseur: 1) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this … PROTO writeup by JP Vasseur: 1) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? This document has been adequately reviewed. No concern. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No. 5) 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? Good WG consensus. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No. 7) Have the chairs verified that the document adheres to all of the ID Checklist items ? Yes. 8) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) All normative references are already published as RFCs. 9) What is the intended status of the document? (e.g., Proposed Standard, Informational?) Informational. |
2007-01-05
|
05 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2006-12-29
|
05 | (System) | New version available: draft-ietf-pce-pcecp-interarea-reqs-05.txt |
2006-11-21
|
04 | (System) | New version available: draft-ietf-pce-pcecp-interarea-reqs-04.txt |
2006-10-23
|
03 | (System) | New version available: draft-ietf-pce-pcecp-interarea-reqs-03.txt |
2006-06-28
|
02 | (System) | New version available: draft-ietf-pce-pcecp-interarea-reqs-02.txt |
2006-02-22
|
01 | (System) | New version available: draft-ietf-pce-pcecp-interarea-reqs-01.txt |
2005-12-01
|
00 | (System) | New version available: draft-ietf-pce-pcecp-interarea-reqs-00.txt |