[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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-05.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 Bill Fenner.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-05.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 nabil.n.bitar at verizon.com.
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.
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce