A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture
draft-ietf-pce-monitoring-09

[Ballot comment]
Agree with Magnus. The OVERLOAD object seems to be redundant, given that it defines overload in terms of processing delay, and we already have a PROC-TIME object that has that (raw) information. The only different between the two seems to be that using the OVERLOAD object conveys the meaning of "hey, I consider myself overloaded at processing delay X" while using a PROC-TIME object just says "hey, here's my processing delay and it's X". Since there are huge question marks around which control mechanism would actually use the overload information (c.f. the SIP overload issues), I'm not sure both are needed.

Also, what control mechanism is envisioned for PCE overload control? This cannot be left up to implementations - a distributed control system needs at least some standardized behavior to get stability and avoid oscillations and livelock.

[Ballot discuss]
The PCE charter says:

  The Working Group will also work on the definition of metrics to
  evaluate path quality, scalability, responsiveness and robustness of
  path computation models.

and

  - Definition of objective metrics to evaluate various criteria such as
  the measurement of path quality, response time, robustness and
  scalability of path computation models.

The document goes much beyond the definition of metrics for PCE. As stated in the final sentence of the abstract, it "specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information."

It's not clear to me that extending PCEP for this purpose is in scope of the currently chartered work or even worth the trouble. For example, it seems like most if not all of the metrics in Section 4 can be realized by querying an appropriately-defined PCE MIB on the different nodes involved in a PCE computation. I am really missing a strong motivation for why adding a control and management functions to the PCEP protocol is desirable.

(Coincidentally, what is the status of the PCE MIB?)

[Ballot discuss]
The PCE charter says:

  The Working Group will also work on the definition of metrics to
  evaluate path quality, scalability, responsiveness and robustness of
  path computation models.

and

  - Definition of objective metrics to evaluate various criteria such as
  the measurement of path quality, response time, robustness and
  scalability of path computation models.

The document goes much beyond the definition of metrics for PCE. As stated in the final sentence of the abstract, it "specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information."

It's not clear to me that extending PCEP for this purpose is in scope of the currently chartered work or even worth the trouble. For example, it seems like most if not all of the metrics in Section 4 can be realized by querying an appropriately-defined PCE MIB on the different nodes involved in a PCE computation. I am really missing a strong motivation for why adding a control and management functions to the PCEP protocol is desirable.

(Coincidentally, what is the status of the PCE MIB?)

[Ballot discuss]
I have read this quite quickly so I can have missunderstood something, so please question my conclusions or point out what I should revisit in my review.

Section 4.4:

I can't understand how this is going to work. I think the object in 4.3 is excellent as it provides the adminstrator good tools to monitor the load situation on his PCE nodes. However, the Overload object does not provide useful information. Stating that you are overloaded, in a overload situation simple increases the load, making the node more overloaded. Secondly, it can't guess how long it is going to be overloaded. That all depends on the arrival rate of requests.

"The receiver MAY use this value to decide whether or not
  so send further requests to the same PCE."
This is also have the potential for being problematic as it will depend on how you define the mechanism to perform any congestion and load balancing. I naive implementation based on this type of signal can easily cause instability where requesting entities flap back and forth between nodes causing high load situations. There is need for much more clear specification on how to perform this type of actions.

Has anyone even simulated a system which tries to use this system?

[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-01-06 raised some
  comments.  Please consider them.  These two seem the most important
  to me:
 
  - 4.1 page 14: even if MONITORING object has no optional TLV
    currently defined, the format of these TLVs must be specified.
    I propose the PCEP generic TLV format, RFC 5440 7.1.

  - 4.3 page 17: the variance of time is a squared time. I propose to
    switch to standard deviation (ecart type in French, the square root
    of the variance)

[Ballot comment]
The phrase  "path computation chain" appears sixteen times, and the phrase "PCE chain" appears seven times.  The latter phrase is undefined; are they equivalent terms?  If they are equivalent, I would change everything to path computation chain.  (If not, please define the term.)

In section 9 (Security Considerations), I would suggest an explicit reference to 5440 section 10.7.2.  "Request Input Shaping/Policing" in the last sentence, since there is an extensive treatment in that spec.

Finally, while it arrived rather late I strongly encourage the authors to review Hannes'
thought provoking secdir review.

[Ballot discuss]
Given that the algorithms for computing both general and specific processing times are
out of scope, it would appear that the results are most useful as a relative measure.  That
is, comparison of results from different PCEs (esp. from different vendors) may not be very
reliable.  Perhaps I missed it, but I did not notice anything in the document to caution those
deploying the protocol about the use of this information as a comparative metric.

I believe this issue applies to OVERLOAD as well.

[Note thanks to Hannes Tschofenig, whose secdir review crystallized this issue for me!]

[Ballot comment]
The phrase  "path computation chain" appears sixteen times, and the phrase "PCE chain" appears seven times.  The latter phrase is undefined; are they equivalent terms?  If they are equivalent, I would change everything to path computation chain.  (If not, please define the term.)

In section 9 (Security Considerations), I would suggest an explicit reference to 5440 section 10.7.2.  "Request Input Shaping/Policing" in the last sentence, since there is an extensive treatment in that spec.

[Ballot discuss]
I have reviewed this document and believe the document is generally
in good condition. However, I had severe trouble understanding one
aspect. This may be due to lack of my familiarity with the other PCE
RFCs or possibly an error. Thus, it would be good to discuss this issue
before we approve the document as an RFC.

The document says:

"Monitoring-id-number (32 bits): The monitoring-id-number value
combined with the PCEP-ID of the PCC identifies the monitoring
request context.  ...  The path computation monitoring
reply is unambiguously identified by the monitoring-id-number and the
PCEP-ID of the replying PCE.  A PCEP implementation SHOULD checkpoint
the Monitoring-id-number of pending monitoring requests in case of
restart thus avoiding the re-use of a Monitoring-id-number of an in-
process monitoring request."

and

"Special case of multi-destination monitoring: monitoring request
related to more than one destinations may involve a set of path
computation chains.  In that case, a PCE sends each copy of the
PCMonReq message to each downstream PCE of each path computation
chain."

I have several questions about this.

First, what is "PCEP-ID"? This string does not appear in the RFC
directory, and is introduced without reference or definition.

Second, where is this identifier stored? I can't find a suitable
place in RFC 5440, and if you meant PCE-ID and not PCEP-ID, then
I'll observe that PCE-ID is not a mandatory part of the messages
that you define in this draft. Yet you say "The monitoring-id-number
value combined with the PCEP-ID of the PCC identifies ...", so
presumably the identifier must exist in all messages.

Third, is there a way to define "multi-destination monitoring" more
formally? Is it simply a PCEReq with multiple destinations?

Fourth, I do not understand the processing of monitoring-id-number
for situations where a PCE must forward monitoring requests to
the next element in the chain. Does the PCE act as a PCC and generate
a new monitoring-id-number, or use the one from the PCC? If the
latter, is the PCC's identity stored in the forward message or
discarded? Presumably it would have to be stored for the
unambiguous identification processing to be possible.

Fifth, I had particular trouble understanding monitoring-id-number
processing for multiple destination monitoring with chains longer
than 1 element. What if you copy the same monitoring request and PCC ID
to two chains, but the two chains end up using the a common PCE? Will
it see the two requests as duplicates or not?

Sixth, you say "In that case, a PCE sends each copy of the
PCMonReq message to each downstream PCE of each path computation
chain." I do not understand the first occurrence of the word "each".
Did the PCE receive one or multiple PCMonReqs?

[Ballot comment]
From section 3:

  Because the P flag
  exclusively relates to a path computation request, it MUST be cleared
  in the two PCEP messages (PCMonReq and PCMonRep message).

Should this sentence end with "defined in this document"?

Editorial nits in section 3.1; the definition of  should come before  and the description of the PCMonRep message includes a (seemingly) redundant "where:"

[Ballot discuss]
I'm unable to understand completely the use of PCE-ID, the determination of the "path computation chain" and the procedures for forwarding and processing PCMonReq and PCMonRep messages, as described in section 6.  List item 3 under "Upon receiving a PCMonReq message" reads:

  If the PCE is not
  the last element of the path computation chain, the PCMonReq message
  is relayed to the next hop PCE: such next hop may either be specified
  by means of a PCE-ID object present in the PCMonReq message or
  dynamically determined by means of a procedure outside of the scope
  of this document.

Does the  take precedence over some other method of specifying the part computation chain?

Is the order of the PCE-ID objects in the  important?

Does a PCE (say 192.168.100.100) forward the PCMonReq to the PCE-ID immediately following the PCE-ID 192.168.100.100 in the ?

Does the last PCE in the  include the  in the PCEMonRep; does it reverse the order of the ?

How is the PEMonRep forwarded to the original source of the PCMonReq; e.g., is the IP address of the original source stored somewhere in the message?

[Ballot comment]
From section 3:

  Because the P flag
  exclusively relates to a path computation request, it MUST be cleared
  in the two PCEP messages (PCMonReq and PCMonRep message).

Should this sentence end with "defined in this document"?

IANA questions/comments:


NOTE: Some of the desired object class values are already assigned
to other protocols.

NOTE: "IETF Consensus" should be changed to "IETF Review," per RFC5226.

QUESTION: In Section 4.4 you say that "No flag is currently
defined" for the CONGESTION object, but then in action 6 you define
a "congestion" flag. Where is this flag defined?


Action 1 (section 8.1):

Upon approval of this document, IANA will make the following
assignments in the "PCEP Messages" registry:
http://www.iana.org/assignments/pcep/pcep.xhtml

Value Description Reference
----- -------------- -----------
tbd(8) Path Computation Monitoring Request (PCMonReq) [RFC-pce-monitoring-04]
tbd(9) Path Computation Monitoring Reply (PCMonRep) [RFC-pce-monitoring-04]


Action 2 (Section 8.2):

Upon approval of this document, IANA will make the following
assignments in the "PCEP Objects" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Object-Class Value Name Object-Type Reference

tbd(19) MONITORING 1 [RFC-pce-monitoring-04]

tbd(20) PCE-ID 1: IPv4 addresses [RFC-pce-monitoring-04]
2: IPv6 addresses [RFC-pce-monitoring-04]

tbd(21) PROC-TIME 1 [RFC-pce-monitoring-04]

tbd(22) CONGESTION 1 [RFC-pce-monitoring-04]


Action 3 (Section 8.3):

Upon approval of this document, IANA will make the following
assignments in the "PCEP-ERROR Object Error Types and Values"
registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Error-Type Meaning Error-value Reference
5 Policy violation
Monitoring message supported tbd(3) [RFC-pce-monitoring-04]
but rejected due to
policy violation

6 Mandatory Object missing
MONITORING Object missing tbd(4) [RFC-pce-monitoring-04]


Action 4 (Section 8.4):

Upon approval of this document, IANA will create the following
new registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Registry Name: MONITORING Object Flag Field
Registration Procedure: IETF Review
Initial contents of this sub-registry will be:

Bit Description Reference
---- ----------- ------------
0-18 Unassigned [RFC-pce-monitoring-04]
19 Incomplete [RFC-pce-monitoring-04]
20 Congestion [RFC-pce-monitoring-04]
21 Processing Time [RFC-pce-monitoring-04]
22 General [RFC-pce-monitoring-04]
23 Liveness [RFC-pce-monitoring-04]


Action 5 (Section 8.5):

Upon approval of this document, IANA will create the following
new registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Registry Name: PROC-TIME Object Flag Field
Registration Procedure: IETF Review
Initial contents of this sub-registry will be:

Bit Description Reference
--- ----------- ---------
0-14 Unassigned [RFC-pce-monitoring-04]
15 Estimated [RFC-pce-monitoring-04]


Action 6 (Section 8.6):

Upon approval of this document, IANA will create the following
new registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Registry Name: CONGESTION Object Flag Field
Registration Procedure: IETF Review
Initial contents of this sub-registry will be:

Bit Description Reference
---- ----------- --------------
0-6 Unassigned [RFC-pce-monitoring-04]
7 Congestion [RFC-pce-monitoring-04]


We understand the above to be the only IANA Actions for this document.

Proto-write-up for draft-ietf-pce-monitoring-04.txt

Intended status : Standards Track

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

Adrian Farrel is the document shepherd.
He has personally reviewed the I-D and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

I-D had a relatively low level of discussions and review in the PCE
working group. However, the work makes only a small modification to
the base PCE protocol (PCEP) and is only of interest to people
building large PCE-based systems. It has been authored by individuals
associated with three separate PCEP implementations.

It has not had review in any wider forums, but none was deemed
necessary or appropriate.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues 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.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

No IPR discolsed

> (1.e)  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?

As per document review, the consensus represents the strong concurrence
of a few individuals, with others being silent. There has been no
dissent at all.

> (1.f)  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
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

All checks made.

> (1.h)  Has the document split its references into normative and
>        informative?  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
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

The document defines small protocol enhancements to PCEP. The PCEP
specification is progressing through the RFC Editor process and no
the IANA registry that has been created is not quite definitive yet.
Nevertheless, this I-D requests further allocations from the PCEP
registry that IANA will create and manage.

The IANA section of this I-D uses the same language as the PCEP
specification and, in particular, uses the same sub-registry names.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

A small amount of BNF is used.
A normative reference to draft-farrel-rtg-common-bnf is included to
scope the form of BNF in use.
No automated checker has been used.

> (1.k)  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.

A Path Computation Element (PCE) based architecture has been
specified in RFC 4655 for the computation of Traffic Engineering
(TE) Label Switched Paths in MPLS and GMPLS networks. This
architecture can be used in the context of single or multiple
domains (where a domain refers to a collection of network
elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous
Systems).

Path Computation Clients send computation requests to PCEs using
the Path Computation Protocol (PCEP). These PCEs may forward the
requests to, and cooperate with, other PCEs forming a "path
computation chain". In PCE-based environments, it is critical to
monitor the state of the path computation chain for
troubleshooting and performance monitoring purposes: liveness of
each element (PCE) involved in the PCE chain, detection of
potential computational resource contention states and statistics
in terms of path computation times are examples of such metrics
of interest.

This document specifies procedures and extensions to PCEP in
order to gather such information.

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

Nothing of note.
Not a very loud consensus, but no dissent.

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

There are no known implementations of this minor addition to the
protocol. There are long-term plans to implement, but nothing in the
immediate future.

Althought the specification got ahead of the implementation, it is felt
that it would be useful to complete the publication process and move on.