Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, pce mailing list <firstname.lastname@example.org>, pce chair <email@example.com> Subject: Document Action: 'PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering' to Informational RFC The IESG has approved the following document: - 'PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering ' <draft-ietf-pce-pcecp-interarea-reqs-06.txt> as an Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-06.txt
Technical Summary This document lists a detailed set of requirements for the Path Computation Element Communication Protocol for support of inter- area TE-LSP path computation. This specifically applies to paths that cross multiple areas within a single IGP routing domain. It complements the generic requirements for a PCE Communication Protocol. Working Group Summary no dissent reported. Protocol Quality Ross Callon has reviewed this spec for the IESG. As a requirements document, it inherently isn't implemented, but there is ongoing work to update the PCE Communications Protocol to handle inter-area path computation consistent with these requirements. Note to RFC Editor The email address for Nabil Bitar (in section 11 contributors' addresses) should be firstname.lastname@example.org. Please replace the second paragraph of section 5 (Manageability Considerations) as follows: Old Text (one paragraph to be removed): 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. New Text (two paragraphs to be added): It is really important, for diagnostic and troubleshooting reasons, to monitor the availability and performances of each PCE of a PCE chain used for inter-area path computation. Particularly it is really important to identify the PCE(s) responsible for a delayed reply. Hence a mechanism MUST be defined to monitor the performances of a PCE chain. It MUST allow determining the availability of each PCE of the chain as well as its minimum maximum and average response time.