Path Computation Element (PCE) Communication Protocol (PCEP)
draft-ietf-pce-pcep-19

[Ballot discuss]
(updated for version -16)

"MUST implement either TCP-MD5 or TCP-AO" seems to require a
normative reference to TCP-AO. That works for me, but so would
some other approaches.

The text "The PCE SHOULD NOT allow parallel TCP connections from the
same PCC on the PCEP registered port." (added in -16) probably needs a
sentence or two qualifying and explaining this (situations involving
e.g. PCC software restarts can require two parallel connections, since
the PCE won't immediately notice the old connection is dead).

The document is inconsistent numbering of bit fields (some places
number bits starting from 0, others from 1, and some of those are in
conflict). Version -16 added one sentence about NO-PATH-VECTOR TLV
(choosing to start numbering from 1, unlike most parts of the
document), but that wasn't the only thing. E.g. Section 7.4.1 numbers
the flags in RP object starting from 0, but the IANA considerations
for them (Section 9.4) starts from 1. Since the document has dozens of
ASCII bit diagrams, which always start numbering from 0, I'd suggest
starting from 0 everywhere...  (using two numbering schemes in one
document seems very likely to cause problems).

[Ballot discuss]
(updated for version -16)

"MUST implement either TCP-MD5 or TCP-AO" seems to require a
normative reference to TCP-AO. That works for me, but so would
some other approaches.

The document is inconsistent numbering of bit fields (some places
number bits starting from 0, others from 1, and some of those are in
conflict). Version -16 added one sentence about NO-PATH-VECTOR TLV
(choosing to start numbering from 1, unlike most parts of the
document), but that wasn't the only thing. E.g. Section 7.4.1 numbers
the flags in RP object starting from 0, but the IANA considerations
for them (Section 9.4) starts from 1. Since the document has dozens of
ASCII bit diagrams, which always start numbering from 0, I'd suggest
starting from 0 everywhere...  (using two numbering schemes in one
document seems very likely to cause problems).

[Ballot comment]
Version 14 resolved my discusses almost completely. However the overload discuss I had needs commenting:

It is quite unclear if the overload protection provided does actually work. It has similarities with the one for SIP that has been found to not work. The only way of really learning this is to do simulation for which I am not going to hold up the document.

There was agreement to document the BNF used in its own document.

[Ballot comment]
Version 14 resolved my discusses almost completely. However the overload discuss I had needs commenting:

It is quite unclear if the overload protection provided does actually work. It has similarities with the one for SIP that has been found to not work. The only way of really learning this is to do simulation for which I am not going to hold up the document.

[Ballot comment]
The protocol has couple of fields that contain numbered bits (NO-PATH,
NO-PATH-VECTOR, RP, METRIC), but the numbering of bits is inconsistent
across the document (and doesn't follow the numbering convention used
in packet diagrams)

[Ballot comment]
Referencing other documents that use BNF without a reference to the
original definition of BNF is probably a worse solution than no
reference.  I think it would be better to reference a real definition
of the language, such as one of the older references here:

http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form

However, the change makes it clear the authors want to use a formal
language without definition so it's not worth my time to argue the
point further.

My previous DISCUSS:

This document uses a formal language (BNF) without providing a reference
to a document that defines that formal language.  Please provide a
reference.

[Ballot discuss]
1. Section 6.2:

Any message received
  prior to an Open message MUST trigger a protocol error condition and
  the PCEP session MUST be terminated.

How? To my understanding no Session context has been created due to failure. So it is meant that one should indicate that error and then close the TCP connection?

2. I can't find any information about how messages must be processed in relation to each other. There is text on various places talking about "pending requests" which seem to me to imply that requests can be handled in parallel. However, that doesn't seem to be explicitly stated. Also the inter message type relations in that case should be clarified. Both within a message type and between the different type of messages.

3. Section 7.3:

  SID (PCEP session-ID - 8 bits): unsigned PCEP session number that
  identifies the current session.  The SID MUST be incremented each
  time a new PCEP session is established and is used for logging and
  troubleshooting purposes.  There is one SID number in each direction.

How do it needs to be incremented? With current formulation any incremention, 1, 10 or 100 would be okay.

Secondly, what happens at wraparound?

Based on Lars discuss further clarification may be need if reconnecting or multiple simultaneous sessions are allowed.

4. Section 7.4.1:

Once more it is unclear if the request-id-number must be incremented with one or larger values are allowed. Also if any specific start value is assumed.

Please do also clarify if this value has long term validity and should be maintained over multiple PCEP sessions.

Wraparound may also be needed to be specified if the PCEP session becomes very long lived, or the space are valid over subsequent sessions

5. Section 7.7:

  Bandwidth: 32 bits.  The requested bandwidth is encoded in 32 bits in
  IEEE floating point format, expressed in bytes per second.  Refer to
  Section 3.1.2 of [RFC3471] for a table of commonly used values.

Over what time constraints are this value intended to be valid? Due to that transmission of packets can be bursty there is need for more information. Shouldn't this be a token bucket to better model the data moving capability of the request?

6. Section 7.7:

Reference for 32-bit "IEEE floating point format"? Please add it also on the other places where you use this format in definitions.

7. section 7.11:

Please be explicit about which of the documents you use the include-any, exclude-any, and include-all. Having browsed through RFC 4090 and 3209 I can't find a definition of what "attribute filters" are. So please include a reference to the definition of these also.

8. The SyncTimer:

How can this timer value be local only? The request sender MUST know how much time it has to supply all the request before it failing due to the timer. So if a PCE uses a non default then a failure may occur and the PCC doesn't know what value is the one used. This value should either be explicit signalled at session opening or at least be included in the error message.

9. Section 7.14, Overload PCE indication.

        Optionally, a TLV named OVERLOADED-DURATION may be included in
        the NOTIFICATION object that specifies the period of time
        during whichno further request should be sent to the PCE. Once
        this period of time has elapsed, the PCE should no longer be
        considered in congested state.

This design seems to suffer from the same issue as SIP has with its overload protection. Especially if I understand it that a PCC to PCE request can result in the PCE sending its own request further to the next PCE that may be overloaded. In that case it seems that this mechanism only can stop the PCC from sending any request, rather than the ones that affect a particular upstream PCE.

Secondary, for real safety against PCC->PCE congestion a mandatory exponential back-off for requests should be specified. That way a PCE that simply stops responding to request will shed load. Seems that with TCP this would need to be based on the response time on any request and some limitation on how many outstanding request the requestor may have.

I am also worried about the lack of mandatory to implement responses as this likely will make it hard to determine what will happen in real-life with multiple implementations making different choices.

[Ballot comment]
The protocol has couple of fields that contain numbered bits (NO-PATH,
NO-PATH-VECTOR, RP, METRIC), but the numbering of bits is inconsistent
across the document (and doesn't follow the numbering convention used
in packet diagrams)

The BNF for request-id-list and notification-list is missing one [].

[Ballot discuss]
Looking back at archives, I get the impression that when RFC 4657
(PCEP requirements) and RFC 5088/5089 (PCE discovery) were processed,
it was concluded that BCP107 applies. This is not reflected in
the document.

There is no mandatory-to-implement security mechanism (which typically
is required by BCP61).

RFC 4278 says "Despite the widespread deployment of [RFC2385] in BGP
deployments, the IESG has thus concluded that it is not appropriate
for use in other contexts."  Given this, using TCP-MD5 for a *new*
protocol would seem to require a particularly strong justification.

[Ballot discuss]
1. Section 6.2:

Any message received
  prior to an Open message MUST trigger a protocol error condition and
  the PCEP session MUST be terminated.

How? To my understanding no Session context has been created due to failure. So it is meant that one should indicate that error and then close the TCP connection?

2. I can't find any information about how messages must be processed in relation to each other. There is text on various places talking about "pending requests" which seem to me to imply that requests can be handled in parallel. However, that doesn't seem to be explicitly stated. Also the inter message type relations in that case should be clarified. Both within a message type and between the different type of messages.

3. Section 7.3:

  SID (PCEP session-ID - 8 bits): unsigned PCEP session number that
  identifies the current session.  The SID MUST be incremented each
  time a new PCEP session is established and is used for logging and
  troubleshooting purposes.  There is one SID number in each direction.

How do it needs to be incremented? With current formulation any incremention, 1, 10 or 100 would be okay.

Secondly, what happens at wraparound?

Based on Lars discuss further clarification may be need if reconnecting or multiple simultaneous sessions are allowed.

4. Section 7.4.1:

Once more it is unclear if the request-id-number must be incremented with one or larger values are allowed. Also if any specific start value is assumed.

Please do also clarify if this value has long term validity and should be maintained over multiple PCEP sessions.

Wraparound may also be needed to be specified if the PCEP session becomes very long lived, or the space are valid over subsequent sessions

5. Section 7.7:

  Bandwidth: 32 bits.  The requested bandwidth is encoded in 32 bits in
  IEEE floating point format, expressed in bytes per second.  Refer to
  Section 3.1.2 of [RFC3471] for a table of commonly used values.

Over what time constraints are this value intended to be valid? Due to that transmission of packets can be bursty there is need for more information. Shouldn't this be a token bucket to better model the data moving capability of the request?

6. Section 7.7:

Reference for 32-bit "IEEE floating point format"? Please add it also on the other places where you use this format in definitions.

7. section 7.11:

Please be explicit about which of the documents you use the include-any, exclude-any, and include-all. Having browsed through RFC 4090 and 3209 I can't find a definition of what "attribute filters" are. So please include a reference to the definition of these also.

8. The SyncTimer:

How can this timer value be local only? The request sender MUST know how much time it has to supply all the request before it failing due to the timer. So if a PCE uses a non default then a failure may occur and the PCC doesn't know what value is the one used. This value should either be explicit signalled at session opening or at least be included in the error message.

9. Section 7.14, Overload PCE indication.

        Optionally, a TLV named OVERLOADED-DURATION may be included in
        the NOTIFICATION object that specifies the period of time
        during whichno further request should be sent to the PCE. Once
        this period of time has elapsed, the PCE should no longer be
        considered in congested state.

This design seems to suffer from the same issue as SIP has with its overload protection. Especially if I understand it that a PCC to PCE request can result in the PCE sending its own request further to the next PCE that may be overloaded. In that case it seems that this mechanism only can stop the PCC from sending any request, rather than the ones that affect a particular upstream PCE.

Secondary, for real safety against PCC->PCE congestion a mandatory exponential back-off for requests should be specified. That way a PCE that simply stops responding to request will shed load. Seems that with TCP this would need to be based on the response time on any request and some limitation on how many outstanding request the requestor may have.

I am also worried about the lack of mandatory to implement responses as this likely will make it hard to determine what will happen in real-life with multiple implementations making different choices.

10. Discuss Discuss:

This is in fact a extension on Chris's Discuss regarding the normative definition of the formal language used in this document.
What tools has been used, if any, to determine the validity of the BNF? Has the shepherd or AD ensured that that these checks where run on the current version?

[Ballot discuss]
1. Section 6.2:

Any message received
  prior to an Open message MUST trigger a protocol error condition and
  the PCEP session MUST be terminated.

How? By closing the TCP connection?

2. I can't find any information about how messages must be processed in relation to each other. There is text on various places talking about "pending requests" which seem to me to imply that requests can be handled in parallel. However, that doesn't seem to be explicitly stated. Also the inter message type relations in that case should be clarified.

3. Section 7.3:

  SID (PCEP session-ID - 8 bits): unsigned PCEP session number that
  identifies the current session.  The SID MUST be incremented each
  time a new PCEP session is established and is used for logging and
  troubleshooting purposes.  There is one SID number in each direction.

How do it needs to be incremented? With current formulation any incremention, 1, 10 or 100 would be okay.

Secondly, what happens at wraparound?

Based on Lars discuss further clarification may be need if reconnecting or multiple simultaneous sessions are allowed.

4. Section 7.4.1:

Once more it is unclear if the request-id-number must be incremented with one or larger values are allowed. Also if any specific start value is assumed.

Please do also clarify if this value has long term validity and should be maintained over multiple PCEP sessions.

Wraparound may also be needed to be specified if the PCEP session becomes very long lived, or the space are valid over subsequent sessions

5. Section 7.7:

  Bandwidth: 32 bits.  The requested bandwidth is encoded in 32 bits in
  IEEE floating point format, expressed in bytes per second.  Refer to
  Section 3.1.2 of [RFC3471] for a table of commonly used values.

Over what time constraints are this value intended to be valid? Due to that transmission of packets can be bursty there is need for more information. Shouldn't this be a token bucket?

6. Section 7.7:

Reference for 32-bit "IEEE floating point format"? Please add it also on the other places where you use this format in definitions.

7. section 7.11:

Please be explicit about which of the documents you use the include-any, exclude-any, and include-all. Having browsed through RFC 4090 and 3209 I can't find a definition of what "attribute filters" are. So please include a reference to the definition of these also.

8. The SyncTimer:

How can this timer value be local only? The request sender MUST know how much time it has to supply all the request before it failing due to the timer. So if a PCE uses a non default then a failure may occur and the PCC doesn't know what value is the one used. This value should either be explicit signalled at session opening or at least be included in the error message.

9. Section 7.14, Overload PCE indication.

        Optionally, a TLV named OVERLOADED-DURATION may be included in
        the NOTIFICATION object that specifies the period of time
        during whichno further request should be sent to the PCE. Once
        this period of time has elapsed, the PCE should no longer be
        considered in congested state.

This design seems to suffer from the same issue as SIP has with its overload protection. Especially if I understand it that a request to a PCE can result in the PCE sending its own request further to the next PCE that may be overloaded. In that case it seems that this mechanism only can stop the PCC from sending any request, rather than the ones that affect a particular upstream PCE.

Secondary, for real safety against PCC->PCE congestion a mandatory exponential back-off for requests should be specified. That way a PCE that simply stops responding to request will shed load.

I am also worried about the lack of mandatory to implement responses as this likely will make it hard to determine what will happen in real-life with multiple implementations making different choices.

I also wonder if it is the request handling or the actually processing to determine the requests that are the bottleneck. I guess the later. In that case maybe some intermediate response that you request is in the queue and  we will come back within X time with an update. Combined with some function for queue length resulting in pushback for sending new request may allow for better working in the protocol.


10. Discuss Discuss:

This is in fact a extension on Chris's Discuss regarding the normative definition of the formal language used in this document.
What tools has been used, if any, to determine the validity of the BNF? Has the shepherd or AD ensured that that these checks where run on the current version?

[Ballot comment]
Note: I support Lars discuss with respect to preference of draft-ietf-tcpm-tcp-auth-opt
over TCP MD5.

Section 7.5

It is unclear if "PCE chain broken" in a No Path object is really a
meaningful "Nature of Issue". What action can/should a PCC take?
Contact a different PCE?

Editorial nit:
4.2.1
s/a pair a PCEP peers/a pair of PCEP peers/

[Ballot discuss]
This discuss has two parts: a relatively minor actionable discuss
and a discuss discuss.

Section 7.4.1

It is unclear if the R bit should be set for 0-bandwidth TE LSPs.
I suggest supplementing this section with text that describes
what should be specified in the case of 0-bandwidth TE LSPs.

Discuss discuss:

Summary:
Basically, I would like to understand the migration strategy for introduction of new features.

Detail:
I have specific concerns regarding processing the flag bits that concern extensibility.
I assume that objects and TLVs may be updated without updating PCEP.  For example,
new flags might be defined for the RP object without changing the PCEP version
number.  Since there are no version numbers for the objects, a PCEP v1 compliant
system could then encounter unrecognized flags quite unexpectedly.  What are the
processing rules for this situation?  Should a PCE or PCC throw an error, or should
it ignore the unrecognized flag?  This is particularly worrisome since a both 1 and 0
can have important context - for example, the B bit means either bi-directional or
uni-directional.

I originally noted this as an error of omission in section 7.4.2.  After further
reading, I have come to the conclusion this is a problem with many of the objects
and TLVs defined in this specification.

[Ballot discuss]
1. Section 6.2:

Any message received
  prior to an Open message MUST trigger a protocol error condition and
  the PCEP session MUST be terminated.

How? By closing the TCP connection?

2. I can't find any information about how messages must be processed in relation to each other. There is text on various places talking about "pending requests" which seem to me to imply that requests can be handled in parallel. However, that doesn't seem to be explicitly stated. Also the inter message type relations in that case should be clarified.

3. Section 7.3:

  SID (PCEP session-ID - 8 bits): unsigned PCEP session number that
  identifies the current session.  The SID MUST be incremented each
  time a new PCEP session is established and is used for logging and
  troubleshooting purposes.  There is one SID number in each direction.

How do it needs to be incremented? With current formulation any incremention, 1, 10 or 100 would be okay.

Secondly, what happens at wraparound?

Based on Lars discuss further clarification may be need if reconnecting or multiple simultaneous sessions are allowed.

4. Section 7.4.1:

Once more it is unclear if the request-id-number must be incremented with one or larger values are allowed. Also if any specific start value is assumed.

Please do also clarify if this value has long term validity and should be maintained over multiple PCEP sessions.

Wraparound may also be needed to be specified if the PCEP session becomes very long lived, or the space are valid over subsequent sessions

5. Section 7.7:

  Bandwidth: 32 bits.  The requested bandwidth is encoded in 32 bits in
  IEEE floating point format, expressed in bytes per second.  Refer to
  Section 3.1.2 of [RFC3471] for a table of commonly used values.

Over what time constraints are this value intended to be valid? Due to that transmission of packets can be bursty there is need for more information. Shouldn't this be a token bucket?

6. Section 7.7:

Reference for 32-bit "IEEE floating point format"? Please add it also on the other places where you use this format in definitions.



Discuss Discuss:

This is in fact a extension on Chris's Discuss regarding the normative definition of the formal language used in this document.
What tools has been used, if any, to determine the validity of the BNF? Has the shepherd or AD ensured that that these checks where run on the current version?

[Ballot comment]
Note: I support Lars discuss with respect to preference of draft-ietf-tcpm-tcp-auth-opt
over TCP MD5.

Section 7.4.1

It is unclear if the R bit should be set for 0-bandwidth TE LSPs.
I suggest supplementing this section with text that describes
what should be specified in the case of 0-bandwidth TE LSPs.

Section 7.5

It is unclear if "PCE chain broken" in a No Path object is really a
meaningful "Nature of Issue". What action can/should a PCC take?
Contact a different PCE?

Editorial nits:
4.2.1
s/a pair a PCEP peers/a pair of PCEP peers/

[Ballot comment]
Section 7.4.1

It is unclear if the R bit should be set for 0-bandwidth TE LSPs.
I suggest supplementing this section with text that describes
what should be specified in the case of 0-bandwidth TE LSPs.

Section 7.5

It is unclear if "PCE chain broken" in a No Path object is really a
meaningful "Nature of Issue". What action can/should a PCC take?
Contact a different PCE?

Editorial nits:
4.2.1
s/a pair a PCEP peers/a pair of PCEP peers/

[Ballot comment]
Section 7.4.1

It is unclear if the R bit should be set for 0-bandwidth TE LSPs.

Section x.x.x

It is unclear if "PCE chain broken" is a meaningful answer for a PCC.
What action can/should a PCC take?

Editorial nits:
4.2.1
s/a pair a PCEP peers/a pair of PCEP peers/

[Ballot comment]
Section 7.4.1

It is unclear if the R bit should be set for 0-bandwidth TE LSPs.

Editorial nits:
4.2.1
s/a pair a PCEP peers/a pair of PCEP peers/

[Ballot discuss]
This discuss has two parts: a process discuss and a discuss discuss.

Olafur Godmundson's comment on ietf discuss has not been answered

>I find it scary how many flags fields the document defines in message types
>with no flags defined and NO GUIDANCE on the scope of these flags.
>Are they per "object Class +object type" or per message type.
>
>Are these needed or just nice to have?
>What is the harm to just define these fields as Reserved ?

Discuss discuss:

Summary:
Basically, I would like to understand the migration strategy for introduction of new features.

Detail:
I have specific concerns regarding processing the flag bits that concern extensibility.
I assume that objects and TLVs may be updated without updating PCEP.  For example,
new flags might be defined for the RP object without changing the PCEP version
number.  Since there are no version numbers for the objects, a PCEP v1 compliant
system could then encounter unrecognized flags quite unexpectedly.  What are the
processing rules for this situation?  Should a PCE or PCC throw an error, or should
it ignore the unrecognized flag?  This is particularly worrisome since a both 1 and 0
can have important context - for example, the B bit means either bi-directional or
uni-directional.

I opriginally noted this as an error of omission in section 7.4.2.  After further
reading, I have come to the conclusion this is a problem with many of the objects
and TLVs defined in this specification.

[Ballot discuss]
This discuss has two parts: a process discuss and a discuss discuss.

Olafur Godmundson's comment on ietf discuss has not been answered

>I find it scary how many flags fields the document defines in message types
>with no flags defined and NO GUIDANCE on the scope of these flags.
>Are they per "object Class +object type" or per message type.
>
>Are these needed or just nice to have?
>What is the harm to just define these fields as Reserved ?

I also have issues regarding processing the flag bits that concern extensibility.
I assume that objects and TLVs may be updated without updating PCEP.  For example,
new flags might be defined for the RP object without changing the PCEP version
number.  Since there are no version numbers for the objects, a PCEP v1 compliant
system could then encounter unrecognized flags quite unexpectedly.  What are the
processing rules for this situation?  Should a PCE or PCC throw an error, or should
it ignore the unrecognized flag?  This is particularly worrisome since a both 1 and 0
can have important context - for example, the B bit means either bi-directional or
uni-directional.

Basically, I would like to understand the migration strategy for introduction of new features.

[Ballot discuss]
IANA has issues.  IANA is waiting for the authors to confirm that
  they have identified the actions correctly.  The author also need
  to clarify whether specific values are reserved or available for
  assignment.

[Ballot comment]
Section 4.2.1., paragraph 4:
> Successive retries are permitted but an implementation should make
> use of an exponential back-off session establishment retry procedure.

  s/should make/SHOULD make/


Section 4.2.2., paragraph 4:
> Once the PCC has selected a PCE, it sends the PCE a path computation
> request to the PCE (PCReq message) that contains a variety of objects
> that specify the set of constraints and attributes for the path to be
> computed.

  Can a PCC send a second path computation request over the same TCP
  connection to a PCE when the answer to an earlier one is still
  outstanding? Can multiple TCP connections exist between the same PCC
  and PCE?


Section 4.2.4., paragraph 1:
> There are several circumstances in which a PCE may want to notify a
> PCC of a specific event.  For example, suppose that the PCE suddenly
> gets overloaded, potentially leading to unacceptable response times.

  Can such notifications occur at any time, i.e., while another message
  is being sent? If so, how are they framed within the TCP byte stream?


Section 6.2., paragraph 2:
> characteristics.  If both parties agree on such characteristics the
> PCEP session is successfully established.  TOTO

  TOTO?


Section 7.3., paragraph 13:
> A sends an Open message to B with Keepalive=10 seconds and
> Deadtimer=30 seconds.  This means that A sends Keepalive messages (or
> ay other PCEP message) to B every 10 seconds and B can declare the
> PCEP session with A down if no PCEP message has been received from A
> within any 30 second period.

  I'd be nice if the example followed the recommended values/fomulas
  above and used Keepalive=30 and DeadTimer=4*Keepalive (or whatever the
  defaults will be after addressing my comments above.)


Section 7.3., paragraph 14:
> SID (PCEP session-ID - 8 bits): unsigned PCEP session number that
> identifies the current session.  The SID MUST be incremented each
> time a new PCEP session is established and is used for logging and
> troubleshooting purposes.  There is one SID number in each direction.

  What's the start value? Is it incremented for each connection to any
  PCEP peer or only for connections to the same PCEP peer? Does it
  matter when SID rolls over? The document doesn't discuss what the SID
  is used for at all.


Section 7.4.1., paragraph 14:
> Request-ID-number (32 bits).  The Request-ID-number value combined
> with the source IP address of the PCC and the PCE address uniquely
> identify the path computation request context.  The Request-ID-number
> MUST be incremented each time a new request is sent to the PCE.  The
> value 0x0000000 is considered as invalid.  If no path computation
> reply is received from the PCE, and the PCC wishes to resend its
> request, the same Request-ID-number MUST be used.  Conversely,
> different Request-ID-number MUST be used for different requests sent
> to a PCE.  The same Request-ID-number MAY be used for path
> computation requests sent to different PCEs.  The path computation
> reply is unambiguously identified by the IP source address of the
> replying PCE.

  It's redundant to identify requests by source and destination IP
  address, given that those are constant for requests going over the
  same TCP connection. Likewise, replies are implicitly identified by
  the TCP connection they arrive over.


Section 8.3., paragraph 1:
> PCEP includes a keepalive mechanism to check the liveliness of a PCEP
> peer and a notification procedure allowing a PCE to advertise its
> congestion state to a PCC.

  s/congestion/overload/ for consistency, here and throughout the
  document


Section 9.1., paragraph 1:
> PCEP uses a well-known TCP port. IANA is requested to assign a port
> number from the "System" sub-registry of the "Port Numbers" registry.

  Does "uses a well-known TCP port" mean that messages from the PCC to
  the PCE must come from that registered source port, or can they come
  from any port? (The former implies that only a single PCEP connection
  can exist between a PCC and a PCE. It also weakens security a bit,
  because an attacker doesn't need to guess the source port anymore.)


Section 10.3.1., paragraph 2:
> o  A PCE should avoid promiscuous TCP listens for PCEP TCP connection
>    establishment.  It should use only listens that are specific to
>    authorized PCCs.

  Authorized by what? TCP has no feature to restrict listens based on
  credentials.

Section 10.3.1., paragraph 4:
> o  The use of access-list on the PCE so as to restrict access to
>    authorized PCCs.

  Is redundant with the first bullet (or I don't understand what it
  means).


Appendix A., paragraph 46:
> If the system receives an Open message from the PCEP peer before the
> expiration of the OpenWait timer, the system first examines all of
> its sessions that are in the OpenWait or KeepWait state.  If another
> session with the same PCEP peer already exists (same IP address),
> then the system performs the following collision resolution
> procedure:

  The goal of this procedure seems to be to guarantee that there is only
  a single active PCEP connection between two peers, but it's
  cumbersome. It'd be much easier to require a peer to not initiate a
  connection to a peer it already has one established with, and to
  require it to immediately close a new TCP connection coming from a
  peer it has an active PCEP connection with. This handles everything at
  the TCP layer without needing to involve the PCEP state machine.

[Ballot discuss]
Section 6.3., paragraph 0:
> 6.3.  Keepalive Message

  DISCUSS: I have a few suggestions on improving the keepalive
  mechanism. (1) Both the PCC and PCE are allowed to send keepalives
  according to their timers. This wastes bandwidth. The reception of a
  keepalive request from the other end should restart the keepalive
  timer on the receiving end - the reception is an indication that the
  peer is alive. This means that keepalives will usually only be sent
  from one end (the one with the shorter keepalive timer) and responded
  to by the other end. (2) As long as a keepalive has not been responded
  to, a PCEP speaker MUST NOT send another one. TCP is a reliable
  protocol and will deliver the outstanding keepalive when it can. It is
  not lost, and there is no need to resend it. All that sending more
  keepalives does when there is no response is fill up the socket send
  buffer.


Section 7.3., paragraph 10:
> Keepalive (8 bits): maximum period of time (in seconds) between two
> consecutive PCEP messages sent by the sender of this message.  The
> minimum value for the Keepalive is 1 second.  When set to 0, once the
> session is established, no further Keepalive messages are sent to the
> remote peer.  A RECOMMENDED value for the keepalive frequency is 30
> seconds.

  DISCUSS: 1 second is extremely short. If there is a requirement that
  PCEP detect failures on such short timescales and should fail over in
  some way, TCP is the wrong underlying transport protocol. If that's
  the motivation, PCEP should use SCTP, which was specifically designed
  for this case. Otherwise, I'd suggest 30 seconds as a reasonable
  minimum to use, and something larger as a recommended default.


Section 9.1., paragraph 1:
>    PCEP uses a well-known TCP port. IANA is requested to assign a port
>    number from the "System" sub-registry of the "Port Numbers" registry.

  DISCUSS: Why is a system port (0-1023) required, wouldn't a registered
  port (1023-49151) suffice?


Section 10.1., paragraph 1:
> It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to
> provide for the authenticity and integrity of PCEP messages.  This
> will allow protecting against PCE or PCC impersonation and also
> against message content falsification.

  DISCUSS: Given all the issues with the continued use of TCP-MD5, I'm
  not convinced that we really want to recommend its use for a new
  protocol. Wouldn't draft-ietf-tcpm-tcp-auth-opt be the preferred
  alternative? Or TLS, since confidentiality is of key importance
  according to Section 10.2. (Also, nit, TCP-MD5 protects TCP segments
  and not PCEP messages.)

[Ballot discuss]
Section 6.3., paragraph 0:
> 6.3.  Keepalive Message

  DISCUSS: I have a few suggestions on improving the keepalive
  mechanism. (1) Both the PCC and PCE are allowed to send keepalives
  according to their timers. This wastes bandwidth. The reception of a
  keepalive request from the other end should restart the keepalive
  timer on the receiving end - the reception is an indication that the
  peer is alive. This means that keepalives will usually only be sent
  from one end (the one with the shorter keepalive timer) and responded
  to by the other end. (2) As long as a keepalive has not been responded
  to, a PCEP speaker MUST NOT send another one. TCP is a reliable
  protocol and will deliver the outstanding keepalive when it can. It is
  not lost, and there is no need to resend it. All that sending more
  keepalives does when there is no response if fill up the socket send
  buffer.


Section 7.3., paragraph 10:
> Keepalive (8 bits): maximum period of time (in seconds) between two
> consecutive PCEP messages sent by the sender of this message.  The
> minimum value for the Keepalive is 1 second.  When set to 0, once the
> session is established, no further Keepalive messages are sent to the
> remote peer.  A RECOMMENDED value for the keepalive frequency is 30
> seconds.

  DISCUSS: 1 second is extremely short. If there is a requirement that
  PCEP detect failures on such short timescales and should fail over in
  some way, TCP is the wrong underlying transport protocol. If that's
  the motivation, PCEP should use SCTP, which was specifically designed
  for this case. Otherwise, I'd suggest 30 seconds as a reasonable
  minimum to use, and something larger as a recommended default.


Section 9.1., paragraph 1:
>    PCEP uses a well-known TCP port. IANA is requested to assign a port
>    number from the "System" sub-registry of the "Port Numbers" registry.

  DISCUSS: Why is a system port (0-1023) required, wouldn't a registered
  port (1023-49151) suffice?


Section 10.1., paragraph 1:
> It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to
> provide for the authenticity and integrity of PCEP messages.  This
> will allow protecting against PCE or PCC impersonation and also
> against message content falsification.

  DISCUSS: Given all the issues with the continued use of TCP-MD5, I'm
  not convinced that we really want to recommend its use for a new
  protocol. Wouldn't draft-ietf-tcpm-tcp-auth-opt be the preferred
  alternative? Or TLS, since confidentiality is of key importance
  according to Section 10.2. (Also, nit, TCP-MD5 protects TCP segments
  and not PCEP messages.)

IANA review comments:

NOTE: this document appears to create several registries that are
not requested in the IANA Considerations section. Please confirm
that we have identified these actions correctly.

Action #1: (9.1)
PCEP needs a TCP port number in the System range.


Action #2: (9.2)
Upon approval of this document, the IANA will create a registry
called  "Path Computation Element Protocol (PCEP)” at
http://www.iana.org/assignments/TBD-PCEP


Action #3: (9.2.1)
Upon approval of this document, the IANA create the following
registry in "Path Computation Element Protocol (PCEP)" at
http://www.iana.org/assignments/TBD-PCEP

Registry Name: PCEP Message Types
Registration Procedures: IETF Consensus

Registry:
Message Type | Message | Reference
------------------------------
0 | Reserved ?? | [RFC-pce-pcep-12]
1 | Open | [RFC-pce-pcep-12]
2 | Keepalive | [RFC-pce-pcep-12]
3 | Path Computation Request | [RFC-pce-pcep-12]
4 | Path Computation Reply | [RFC-pce-pcep-12]
5 | Notification | [RFC-pce-pcep-12]
6 | Error | [RFC-pce-pcep-12]
7 | Close | [RFC-pce-pcep-12]
8-255 | Unassigned | [RFC-pce-pcep-12]

QUESTION: Is value 0 reserved or available for assignment?


Action #4: (9.2.2) (7.2)
Upon approval of this document, the IANA will create the following
registry in "Path Computation Element Protocol (PCEP)" at
http://www.iana.org/assignments/TBD-PCEP

Registry Name: PCEP Objects
Registration Procedure: IETF Consensus

Object Class Name Reference
---------+-----------------------------------------------+--------------
0 | Reserved ? | [RFC-pce-pcep-12]
| |
1 | OPEN | [RFC-pce-pcep-12]
| Object-Type
| 1: Open | [RFC-pce-pcep-12]
| |
2 | RP | [RFC-pce-pcep-12]
| Object-Type
| 1: Request Parameters | [RFC-pce-pcep-12]
| |
3 | NO-PATH | [RFC-pce-pcep-12]
| Object-Type
| 1: No Path | [RFC-pce-pcep-12]
| |
4 | END-POINTS | [RFC-pce-pcep-12]
| Object-Type
| 1: IPv4 addresses | [RFC-pce-pcep-12]
| 2: IPv6 addresses | [RFC-pce-pcep-12]
| |
5 | BANDWIDTH | [RFC-pce-pcep-12]
| Object-Type
| 1: Requested bandwidth | [RFC-pce-pcep-12]
| 2: Bandwidth of an existing TE LSP for | [RFC-pce-pcep-12]
| which a reoptimization is performed.
| |
6 | METRIC | [RFC-pce-pcep-12]
| Object-Type
| 1: Metric | [RFC-pce-pcep-12]
| |
7 | ERO | [RFC-pce-pcep-12]
| Object-Type
| 1: Explicit Route | [RFC-pce-pcep-12]
| |
8 | RRO | [RFC-pce-pcep-12]
| Object-Type
| 1: Record Route | [RFC-pce-pcep-12]
| |
9 | LSPA | [RFC-pce-pcep-12]
| Object-Type
| 1: LSP Attributes | [RFC-pce-pcep-12]
| |
10 | IRO | [RFC-pce-pcep-12]
| Object-Type
| 1: Include Route | [RFC-pce-pcep-12]
| |
11 | SVEC | [RFC-pce-pcep-12]
| Object-Type
| 1: Synchronization Vector | [RFC-pce-pcep-12]
| |
12 | NOTIFICATION | [RFC-pce-pcep-12]
| Object-Type
| 1: Notification | [RFC-pce-pcep-12]
| |
13 | PCEP-ERROR | [RFC-pce-pcep-12]
| Object-Type
| 1: Error | [RFC-pce-pcep-12]
| |
14 | LOAD-BALANCING | [RFC-pce-pcep-12]
| Object-Type
| 1: Load Balancing | [RFC-pce-pcep-12]
| |
15 | CLOSE | [RFC-pce-pcep-12]
| Object-Type
| 1: Close | [RFC-pce-pcep-12]
| |
16-255 | Unassigned

QUESTION: Is 0 reserved or available for assignment?


Action #5: (9.2.3) (7.4.1)
Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: Request Parameters Bit Flags
Registration Procedures: IETF Consensus

Registry:
Bit | Name | Description | Reference
-----------+----------+-----------------------+---------------
0-25 | | Available for allocation | [RFC-pce-pcep-12]
26 | O-bit | Strict/Loose | [RFC-pce-pcep-12]
27 | B-bit | Bi-directional | [RFC-pce-pcep-12]
28 | R-bit | Reoptimization | [RFC-pce-pcep-12]
29-31 | Pri | Priority | [RFC-pce-pcep-12]


Action #6: (9.2.4) (7.14)
Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: Notification Types and Values
Registration Procedures: IETF Consensus

Registry:
Notification Type Name Reference
------------+----------------------------------------------+---------
1 | Pending Request cancelled | [RFC-pce-pcep-12]
| Notification-value:
| 1: PCC cancels a set of pending requests | [RFC-pce-pcep-12]
| 2: PCE cancels a set of pending requests | [RFC-pce-pcep-12]
|
2 | PCE Congestion | [RFC-pce-pcep-12]
| Notification-value
| 1: PCE in congested state | [RFC-pce-pcep-12]
| 2: PCE no longer in congested state | [RFC-pce-pcep-12]


Action #7 (9.2.5) (7.15)
Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: Error Types and Values
Reference: [RFC-pce-pcep-12]
Registration Procedures: IETF Consensus

Registry:
Error Type Meaning Reference
-------+----------------------------------------------+---------
1 PCEP session establishment failure [RFC-pce-pcep-12]
Error-value=1: [RFC-pce-pcep-12]
Reception of an invalid Open message or a
non-Open message.
Error-value=2: [RFC-pce-pcep-12]
No Open message received before the expiration
of the OpenWait timer.
Error-value=3:
Unacceptable and non negotiable session [RFC-pce-pcep-12]
characteristics.
Error-value=4:
Unacceptable but negotiable session [RFC-pce-pcep-12]
characteristics.
Error-value=5: [RFC-pce-pcep-12]
Reception of a second Open message with still
unacceptable session characteristics.
Error-value=6: [RFC-pce-pcep-12]
Reception of a PCErr message proposing
unacceptable session characteristics.
Error-value=7: [RFC-pce-pcep-12]
No Keepalive or PCErr message received before
the expiration of the KeepWait timer.
Error-value=8: PCEP version not supported

2 Capability not supported [RFC-pce-pcep-12]

3 Unknown Object [RFC-pce-pcep-12]
Error-value=1: [RFC-pce-pcep-12]
Unrecognized object class
Error-value=2: [RFC-pce-pcep-12]
Unrecognized object type
Error-value=3: [RFC-pce-pcep-12]
Unrecognized subobject type
Error-value=4: [RFC-pce-pcep-12]
Unrecognized parameter

4 Not supported object [RFC-pce-pcep-12]
Error-value=1: [RFC-pce-pcep-12]
Unsupported object class.
Error-value=2: [RFC-pce-pcep-12]
Unsupported object type.
Error-value=3: [RFC-pce-pcep-12]
Unsupported subobject type.
Error-value=4: [RFC-pce-pcep-12]
Unsupported parameter.

5 Policy violation [RFC-pce-pcep-12]
Error-value=1: [RFC-pce-pcep-12]
C bit of the METRIC object set (request
rejected).
Error-value=2: [RFC-pce-pcep-12]
O bit of the RP object cleared (request
rejected).

6 Mandatory Object missing. [RFC-pce-pcep-12]
Error-value=1:
RP object missing.
Error-value=2: [RFC-pce-pcep-12]
RRO missing for a reoptimization request
(R bit of the RP object set).
Error-value=3: [RFC-pce-pcep-12]
END-POINTS object missing.

7 Synchronized path computation request missing. [RFC-pce-pcep-12]

8 Unknown request reference. [RFC-pce-pcep-12]

9 Attempt to establish a second PCEP session. [RFC-pce-pcep-12]

10 Reception of an invalid object [RFC-pce-pcep-12]
Error-value=1: [RFC-pce-pcep-12]
Reception of an object with P flag not set
although the P-flag must be set according
to this specification.


Action #8 (9.2.6) (7.17)
Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: Close Reasons
Registration Procedures: IETF Consensus

Registry:
Reasons Value Meaning
------------+----------------------------------------------+---------
0 | Reserved ? | [RFC-pce-pcep-12]
1 | No explanation provided | [RFC-pce-pcep-12]
2 | DeadTimer expired | [RFC-pce-pcep-12]
3 | Reception of a malformed PCEP message | [RFC-pce-pcep-12]
4-255 | Unassigned | [RFC-pce-pcep-12]

QUESTION: Is “0” reserved or available for assignment?


Action #9: 9.2.7.1 (7.5)
Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: No-Path Nature of Issue
Registration Procedures: IETF Consensus

Registry:
Value | Meaning | Reference
----------+----------------------------------------------+---------
0 | No path satisfying the set of constraints could be found | [RFC-pce-pcep-12]
1 | PCE chain broken | [RFC-pce-pcep-12]
2-255 | Unassigned | [RFC-pce-pcep-12]


Action #10
Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: No-Path Flags
Allocation policy: IETF Consensus

Registry:
Bit | Name | Description | Reference
-----------+----------+-----------------------+---------------
0 | O-bit | Unsatisfied constraints included | [RFC-pce-pcep-12]
1-15 | | Unassigned | [RFC-pce-pcep-12]


Action #11
Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: PCEP TLV Types
Registration Procedures: IETF Consensus

Registry:

TLV Type  Meaning  Reference
----------+---------------------------------------+---------
0 | Reserved | [RFC-pce-pcep-12]
1 | NO-PATH-VECTOR TLV | [RFC-pce-pcep-12]
2 | OVERLOAD-DURATION TLV | [RFC-pce-pcep-12]
3 | REQ-MISSING TLV | [RFC-pce-pcep-12]
4-65535 | Unassigned | [RFC-pce-pcep-12]


Action #12
Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: No-Path Reasons
Registration Procedures: IETF Consensus

Registry:
Bit | Name | Reference
-----------+----------------------------------+---------------
0 | Unassigned | [RFC-pce-pcep-12]
1 | PCE currently Unavailable | [RFC-pce-pcep-12]
2 | Unknown Destination | [RFC-pce-pcep-12]
3 | Unknown Source | [RFC-pce-pcep-12]
4-31 | Unassigned | [RFC-pce-pcep-12]


Action #13

NOTE: This action appears to be requested in Section 6.1, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: PCEP Version"
Registration Procedures: IETF Consensus.

Version | Version name | Reference
--------+-------------------+----------
0 | Reserved | [RFC-pce-pcep-12]
1 | PCEP-#1 | [RFC-pce-pcep-12]
2-7 | Unassigned | [RFC-pce-pcep-12]


Action #14
NOTE: This action appears to be requested in Section 6.1, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: PCEP Common Header flags
Registration Procedure: IETF Consensus

Registry:
Bit | Name | Reference
-----------+----------------------------------+---------------
0-4 | Unassigned | [RFC-pce-pcep-12]


Action #15
NOTE: This action appears to be requested in Section 7.2, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: PCEP Common Object Header flags
Registration Procedures: IETF Consensus

Registry:
Bit | Name | Description | Reference
-----------+--------+------------------------------+---------------
0-1 | | Unassigned | [RFC-pce-pcep-12]
2 | P-Flag | Processing Rule | [RFC-pce-pcep-12]
3 | I-Flag | Ignore | [RFC-pce-pcep-12]


Action #16
NOTE: This action appears to be requested in Section 7.3, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: PCEP Open flags
Registration procedures: IETF Consensus.

Registry:
Bit | Name | Reference
-----------+----------------------------------+---------------
0-4 | Unassigned | [RFC-pce-pcep-12]


Action #17
NOTE: This action appears to be requested in Section 7.8, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: PCEP Metric flags

Registration Procedures: IETF Consensus

Registry:
Bit | Name | Description | Reference
-----------+--------+------------------------------+---------------
0-5 | | Unassigned | [RFC-pce-pcep-12]
6 | C-Flag | Computed Metric | [RFC-pce-pcep-12]
7 | B-Flag | Bound | [RFC-pce-pcep-12]


Action #18
NOTE: This action appears to be requested in Section 7.8, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: PCEP Metric type
Registration Procedures: IETF Consensus.

Registry:
Value | Name | Reference
------------+---------------------------------+---------------
0 | Reserved | [RFC-pce-pcep-12]
1 | IGP metric | [RFC-pce-pcep-12]
2 | TE metric | [RFC-pce-pcep-12]
2 | Hop Counts | [RFC-pce-pcep-12]
4-255 | Unassigned | [RFC-pce-pcep-12]


Action #19
NOTE: This action appears to be requested in Section 7.11, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: LSPA Object flags
Registration Procedures: IETF Consensus

Registry:
Bit | Name | Description | Reference
-----------+----------+--------------------------+---------------
0-6 | | Unassigned | [RFC-pce-pcep-12]
7 | L-Flag | Local Protection Desired | [RFC-pce-pcep-12]


Action #20
NOTE: This action appears to be requested in Section 7.13.2, but
does not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: SVEC Object flags
Registration procedures: IETF Consensus

Registry:
Bit | Name | Description | Reference
-----------+----------+--------------------------+---------------
0-20 | | Unassigned | [RFC-pce-pcep-12]
21 | S-Flag | SRLG diverse | [RFC-pce-pcep-12]
22 | N-Flag | Node diverse | [RFC-pce-pcep-12]
23 | L-Flag | Link diverse | [RFC-pce-pcep-12]


Action #21
NOTE: This action appears to be requested in Section 7.14, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: Notification flags
Allocation policy: IETF Consensus

Registry:
Bit | Name | Reference
-----------+----------------------------------+---------------
0-7 | Unassigned | [RFC-pce-pcep-12]


Action #22
NOTE: This action appears to be requested in Section 7.15, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: PCEP-ERROR flags
Registration Procedures: IETF Consensus

Registry:
Bit | Name | Reference
-----------+----------------------------------+---------------
0-7 | Unassigned | [RFC-pce-pcep-12]


Action #23
NOTE: This action appears to be requested in Section 7.16, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP

Registry Name: LOAD-Balancing flags
Registration Procedures: IETF Consensus

Registry:
Bit | Name | Reference
-----------+----------------------------------+---------------
0-7 | Unassigned | [RFC-pce-pcep-12]


Action #24
NOTE: This action appears to be requested in Section 7.17, but does
not appear in the IANA Considerations section.

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD-PCEP
Registry Name: CLOSE flags
Registration Procedures: IETF Consensus

Registry:
Bit | Name | Reference
-----------+----------------------------------+---------------
0-7 | Unassigned | [RFC-pce-pcep-12]


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

Proto-write-up for draft-ietf-pce-pcep-11.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 has had very good level of discussions and review. The high version
number is indicative of many small deltas over the last year as reviews and
implementations have discovered nits to be fixed.

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

We are aware that the security considerations for a new protocol need
special attention. The I-D has been the subject of several informal security
discussions, and the authors and chairs have attempted to get the security
section right. But the WG feels that a review by the Security Directorate at
the same time as IESG review would be useful to close out any issues.

> (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 disclosure has been filed.

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

Consensus is comprehensive to the point of unanimity!

> (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 a new protocol and requests a registry with multiple
sub-registries. The registries are well documented and named.

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

The message formats are described in relatively simple BNF. No automated
checker has been used.

Note that the symbol "|" is used to denote an alternative whereas RFC 5234
specifies the use of "/". This choice was made deliberately as the "|"
symbol is found in related RFCs (e.g. RFCs 2205, 3209, 3473).

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

RFC4655 describes the motivations and architecture for a Path Computation
Element (PCE) based model for the computation of Multiprotocol Label
Switching (MPLS) and Generalized (GMPLS) Traffic Engineering Label Switch
Paths (TE LSPs).  The model allows for the separation of PCE from Path
Computation Client (PCC), and allows for the cooperation between PCEs.  This
necessitates a communication protocol between PCC and PCE, and between PCEs.

RFC4657 states the generic requirements for such a protocol including the
requirement for using the same protocol between PCC and PCE, and between
PCEs.

This document specifies the Path Computation Element Communication Protocol
(PCEP) for communications between a Path Computation Client (PCC) and a Path
Computation Element (PCE), or between two PCEs. Such interactions include
path computation requests and path computation replies as well as
notifications of specific states related to the use of a PCE in the context
of Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic
Engineering. PCEP is designed to be flexible and extensible so as to easily
allow for the addition of further messages and objects, should further
requirements be expressed in the future.

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

WG has thorough consensus with no disputes or disagreements.
At the start of the development of the protocol, a thorough survey was
conducted into the possible use or re-use of existing protocols. The
Applications Area was engaged, and several prototypes were produced. But in
the end it was determined that a new protocol was expeditious.

>        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 a substantial number of implementations (around 10 were recorded
in an informal survey). Some of these are experimental implementations in
service provider labs, while some are academic projects. Other
implementations are for hardware and software products and are commercially
available.

Private interoperability testing has been conducted between at least four of
these implementations. Initial testing raised important defects in the
specification (that were fixed).