Path Computation Element (PCE) Communication Protocol Generic Requirements
draft-ietf-pce-comm-protocol-gen-reqs-07

[Ballot comment]
Less concrete issues from Gen-ART review by Robert Sparks:

ISSUE 2:
  The extensibility requirements demand arbitrary objective
  functions. A discussion of the security implications of this
  requirement is needed. There are probably additional requirements
  on the protocol to be identified focusing on mitigating the risk
  of, for example, a PCC using complex objetives to intentionally drive
  a PCE into resource exhaustion. Does the protocol need to give the  PCE
  tools to say "I tried to do that, but it's turning out to be harder
  than my policies allow."?

ISSUE 4:
  There are several requirements of PCEs that have been captured
  here as requirements of the PCECP. Section 6.1.15 requires that
  the protocol "scale well", where it really means that the system
  using the protocol scales well. The numbers in this section are
  capacity and performance numbers for a PCE, and they are useful
  when designing the PCECP to make sure the protocol itself makes
  achieving those numbers sane. This section should be reworded to
  make this obvious.

  Similarly, section 8 should separate requirements on the protocol
  from the motivational requirements on CPE implementations (2119
  words shouldn't be used in that motivation).

ISSUE 5 (Apologies if my lack of domain expertise led me to miss
        something obvious here):
  Section 6.3.3 requires the protocol to carry information about
  the state of the network to the PCE that would normally come from
  the TED. Does this not introduce security concerns? Could a PCC
  use this poison CPE calculations for other PCCs? If this capability
  exists, there needs to be discussion about how the data gets used
  by the PCE (does it cache it?), but that discussion doesn't belong
  in this document. I suggest at a minimum that some discussion of
  the ramifications of this capability be included in the security
  consideration section of this document.
ISSUE 7:
  The purpose of 6.2.1 is not clear. What is the real requirement
  being placed on the protocol, and how can we evaluate the protocol
  against that requirement. If there are no such explicit  requirements,
  I suggest this be rewritten as advice on where the protocol is  expected
  to be used and not use 2119 terms at all.
  I'm particularly puzzled about what impact operating in environments
  including
    "- packet and non-packet networks"
  is intended to have on the protocol itself.

Nits:
The draft passes the idnits checker (in spirit at least).
The checker complains about the reference to 2119 in the
boilerplate, and the unexpected use of
"Authors' and Contributors' Addresses".

These nits are in no particular order:

NIT 1:
  The references to I-Ds that are works in progress do not
  include draft names, Please add them.

NIT 2:
  Please expand PCE in the title.

NIT 3:
  Section 6.1.6 uses "notification message" which is not yet
  defined - a forward reference would be helpful.

NIT 3:
  Section 6.1.11 requires unsolicited notifications, but doesn't
  really define them. Are these reliable messages? Do they get
  responses?  More detail about what's really being required would
  make the document more useful.

NIT 4:
  The final requirement in 6.1.15 is redundant with requirements
  in both 6.1.8 and section 8. Consolodating those would make the
  document stronger.

NIT 5:
  I suggest deleting "easily" in section 6.1.14:
    The PCECP MUST be easily extensible -> The PCECP MUST be extensible

NIT 6:
  Sections 6.1.16 and .17 share some language that confuses me:
  "does not mean that the constraint must not be supported"
  and
  "does not mean that the objective function may not be supported"

  Is there a way to say this with fewer negations?

  You are trying to reinforce that these sets are extensible. Maybe
  you could just say that instead?

NIT 7:
  The first sentence of 6.2.2 has at least two discrete requirements
  embedded in it. It would be easier to evaluate against the eventual
  protocol definition if these were separated.

NIT 8:
  It's not clear to me what "resynchronization of information" means in
  section 6.3.2. Is there any way to add detail? Is it obvious to the
  community using this document what information is being  resynchronized?

NIT 9:
  Section 6.3.3, third paragraph. I suggest changing
  "large number of PCCs is going to simultaneously" to
  "large number of PCCs will simultaneously".

A couple of final comments that I didn't think worthy of
being called an issue or a nit:

The draft requires response aggregation, but doesn't discuss
the ramifications this will have on the reliability mechanisms
that you will either use from a selected transport or have to
build above it. Pointing out that there are non-trivial issues
here would probably be useful.

The security consideration section doesn't capture any thinking
your group may have put in so far towards threats from elements
that are part of the architecture. Capturing early thinking here
will go a long way.

[Ballot discuss]
There are a lot of issues with the way this document uses RFC 2119
normative language, identified by Robert Sparks in his Gen-ART review.
A serious pass over the document to eliminate these inconsistencies
is needed, if we are to use such language in an Informational document.

ISSUE 1:
  The summary of requirements in section 6.4 are inconsistant with
  the requirements in the document.

  Example: 6.4 contains:
        Functionality added to PCECP if transport
        protocol provides it                      SHOULD NOT 6.1.8
    while 6.1.8 says
    Functionality MUST NOT be added to the PCECP where
        the chosen transport protocol already provides it.

  Example: 6.4 contains:
        Maintain PCC-PCE session                NON-RQMT  6.1.2
    but 6.1.2 is silent on maintaining sessions

  I have not done an exhaustive comparison of the table vs the text.
  This is what I found spot-checking a few. A more thorough  reconcilliation
  is needed.

ISSUE 3:
  There is an incorporation of MUST requirements by incomplete
  reference in section 6.1.14:
    "The PCECP MUST support the requirements specified in the
    application-specific requirements documents."
  But it's not clear what these requirements documents are. There
  is a list in the preceeding paragraph, but only a subset of the
  elements in that list have concrete references.

  One possible resolution is to state that the protocol must be
  extensible, explicitly call out the kinds of extensibility (adding
  to the first paragraph of 6.1.14 perhaps) and calling out these
  other documents as examples of the users of the extensibility  mechanism
  instead of directly requiring support of their requirements here.

ISSUE 6 (not as major as the above, but should still be addressed):
  There are several places where 2119 terms are used where they
  shouldn't be. The large difference in the number of occurances of
  MUST outside section 6.4 and inside section 6.4 points to this and
  could be used as a mechanism to help find these places.
    Examples from 6.1.4:
      A list of core objective functions that MUST be supported by the
      PCECP is supplied in Section 6.1.17. Specification of objective
      functions MUST be future-proofed as described in Section 6.1.14.

[Ballot discuss]
> The PCECP may utilize an existing transport protocol or operate
> directly over IP.

> If a transport protocol is used, it MAY be used to satisfy some
> requirements stated in other sections of this document (for example,
> reliability and security). Where requirements expressed in this
> document match the function of existing transport protocols,
> consideration MUST be given to the use of those protocols.

> If a transport protocol is used, it MUST NOT limit the size of the
> message used by the PCECP.

Magnus already raised the issue about congestion control if no
existing transport protocol is used. And I'm not sure we would like to
burn a protocol number from the IP space for this purpose. But there
are also other issues in this section. In particular, the requirement
says very little, does not clearly specify what the requirements for
the transport protocol are, or if there are multiple different
deployment scenarios where different transports might be needed.

I see that the protocol spec currently under development in the WG
actually uses TCP. As a result, I wonder if we could make the
requirements in this section simpler and tighter. For instance,

  The PCECP SHOULD utilize an existing transport protocol
  that supports congestion control. This transport protocol
  may also be used to satisfy some requirements in other
  sections of this document, such as reliability. The PCECP
  SHOULD be defined for one transport protocol only in order
  to ensure interoperability.

Comment: Nits:

s/disjointess/disjointness/

[Ballot discuss]
The security solution to this protocol needs to address RFC 4107.  I
believe that an RFC 4107 analysis will clearly require mandatory key
management in this protocol.

It is important to me that the working group is aware of this
requirement.  If they are aware and have just chosen not to discuss
the requirement in this document, I can remove my discuss.

[Ballot discuss]
Section 6.1.9 includes a discussion of authentication, encryption
  (although I would prefer a discussion of confidentiality), and DOS
  attack countermeasures.  There ought to also be a discussion of
  authorization.  Once a PCC is identified and authenticated, do all
  PCCs have the same privileges?
 
  Section 6.3.3 talks about the "identity of the failed element."
  If possible, it would be good to say a bit more about the
  identification of PCCs and PCEs.  The text does not need to be
  in this section of the document, but it would aid identification,
  authentication, and authorization discussion if there is a clear
  way to name the entities.

[Ballot comment]
1. From Section 8:

'PCECP operations MUST be modeled and controlled through appropriate MIB modules.' 


It looks to me that there are enough specific differences between PCCs and PCEs to lead to the need of defining separate MIB modules. I suggest that this is mentioned in Section 8.

3. 'The operator MUST be able to determine PCECP historical interactions and the success rate of requests using data from MIB modules.'

The way this phrase is written the use of capitalization does not seem justified. Maybe a beter text would be:

'The MIB modules MUST provide information that will allow an operator to PCECP historical interactions and the success rate of requests.'


3. 'The new MIB modules should also be used to provide notifications (traps) when thresholds are crossed or when important events occur.'

This is extremely vague and general for a requirement. I wsuggest that sepcific information be provided about what type of faults and events are critical and need to be reported in notifications. Maybe this paragraph needs to be merged with the last paragraph, where there is some mention about congestion and rate limitation indications.

[Ballot discuss]
6.1.3 Transport

  The PCECP may utilize an existing transport protocol or operate
  directly over IP.

If operating directly over IP or a transport protocol not providing congestion control the PCECP must have congestion control functions.

Section 6.1.8:

The PCECP MUST provide:

  - Detection and report of lost or corrupted messages
  - Automatic attempts to retransmit lost messages without reference to
    the application
  - Handling of out-of-order messages
  - Handling of duplicate messages
  - Flow control and back-pressure to enable throttling of requests and
    responses
  - Rapid PCECP communication failure detection
  - Distinction between partner failure and communication channel
    failure after the PCECP communication is recovered

I think the formulation that it is the PCECP that needs to provide all of these functionalities seems to going to far. I would suggest to change the text to:

The PCECP or its transport protocol MUST provide:

  - Detection ...

In regards to:

Functionality MUST NOT be added
  to the PCECP where the chosen transport protocol already provides it.

I think that was in contradiction of the earlier statement unless the proposed change or similar is applied. I would also like to point out that I think there will be need for both transport congestion control and throttling of requests. I get the impression that document tries to cover this, however maybe not clearly enough. Thus I think a addition to section 6.1.3 can fix this.

For the IESG's use in looking at , here is an email exchange between Ross Callon and a working group chair (JP Vasseur) regarding a few minor changes to be made (authors were also on the email TO: list). My understanding is that the authors should be updating the draft prior to our telechat.

>>Page 8, section 6.1.8, first sentence reads:

    The PCECP MUST include reliability.

This needs some clarification. Does this mean:

    The PCECP MUST support reliable transmission of PCECP
    packets.

Right.


>>Page 9, section 6.1.9, first sentence: Should the word "insure"
be instead "ensure".

Yes, thanks.


>>Same paragraph: I am pleased that you specifically mention
DOS attacks, since this seems like an issue that could come
up with PCE. In terms of the possible methods to deal with
DOS, you specifically mention rate limiting. However, I think
that you might also want to specifically mention packet filtering.
Of course rate limiting is one form of packet filtering. However,
people might also want to put in filters which prohibit packets
altogether from, for example, source addresses that are not
authorized.

Thanks for the comments Ross; indeed rate limiting is probably not 
sufficient and packet filtering is undoubtedly a required function.

Also, it has occurred to me that if the PCE protocol
is limited to operation within a single routing domain and single
administrative domain, a provider could protect against DOS by
putting the PCE servers and clients in a private address space,
which is not available to customers or the general Internet. Thus
a bit more description might make sense. Whether this would be
in this section, or in section 7, is TBD. Possible extension of the
current wording for section 6.1.9 might be:

    The PCC-PCE communication protocol MUST include provisions
    to ensure the security of the exchanges between the entities. In
    particular, it MUST support mechanisms to prevent spoofing (e.g.,
    authentication), snooping (e.g., encryption) and DOS attacks 
    (e.g., packet filtering, rate limiting, no promiscuous listening).
    Where the PCE-PCC communication takes place entirely within one limited
    domain, the use of a private address space which is not available
    to customer systems MAY be used to help protect the information
    exchange, but other mechanisms MUST also be available.

Really like the formulation since indeed the PCE does not have to be 
in the same domain but if it is, private addressing may help, 
although as you know not all SPs use private addressing in their core.

PROTO Writeup by JP Vasseur (WG co-chair):

> 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?
>
> The document has been reviewed by several key WG members. No pending
> 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 concerns.
>
> 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. One set of comments for clarification during Last
> Call that has been addressed by the authors.
>
> 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.
>
> None.
>
> 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 references are informational.
>
> 9. What is the intended status of the document? (e.g., Proposed
> Standard,
> Informational?)
>
> Informational.
>
> 10. For Standards Track and BCP documents, the IESG approval
> announcement
> includes a write-up section with the following sections:
>
> - Technical Summary
> - Working Group Summary
> - Protocol Quality
>
> N/A