Requirements for Path Computation Element (PCE) Discovery
draft-ietf-pce-discovery-reqs-05

[Ballot comment]
I think that section 6.6 should discuss confidentiality, not privacy.
  See the definitions of these words in RFC 2828.

  I also made this comment on draft-ietf-pce-comm-protocol-gen-reqs-04:
  If possible, it would be good to say a bit more about the
  identification of PCCs and PCEs.  The text would aid identification,
  authentication, and authorization discussion if there is a clear
  way to name the entities.

[Ballot comment]
The discovery protocol may be an excellent way to improve the security
of the basic communications protocol.  For example, if the discovery
protocol has good authentication and can carry the cryptographic
identity of the PCE, then this protocol may significant ease the
deployment of secure PCE devices.  See draft-ietf-mmusic-comedia-tls
for an example of a protocol where discovery is used to enhance the
security of another protocol.

The authors should consider whether such a solution will help their
work.

[Ballot discuss]
The document says:

  Where inter-domain path computation is required, the PCE discovery
  method MUST allow a PCC to automatically discover the location of
  PCEs in other domains that can assist with inter-domain path
  computation. 

Does this presume there is a pre-existing agreement between the domains
to allow inter-domain path computation?  That is, we're not presuming
that the PCC gets to decide on its own that it needs inter-domain path computation?

The document says:

6.1.1.1. Discovery of PCE Location
   
  The PCE discovery mechanism MUST allow the discovery, for a given
  PCE, of the IPv4 and/or IPv6 address to be used to reach the PCE.
  This address will typically be a loop-back address that is always
  reachable, if there is any connectivity to the PCE.

This isn't how RFC 3330 uses loopback address, so I suspect you may
want to use a different term or specify the meaning.

This worries me:

  The PCE discovery mechanisms MUST also allow discovery of the set of
  one or more domains toward which a PCE can compute paths. For
  instance in an inter-AS path computation context, there may be
  several PCEs in an AS, each one responsible for taking part in the
  computation of inter-AS paths toward a set of one or more destination
  ASs, and a PCC must discover the destination ASs each PCE is
  responsible for.

because it seems to imply that the PCE discovery method must allow
for the discovery of every PCE, rather "one or more" as set out in 4.2
If this does not imply that the PCC must discover every available PCE,
does it presume that any one PCE it contacts will know the path
computation contexts available to the other PCEs?

As a general, non-blocking comment, but something I would like
to discuss, I'd like to note that the IETF has failed pretty spectacularly in
discovery problems that had a far smaller set of MUSTs than this.  It may
be the limited discover domain will make this easier than the generalized
discovery mechanisms, but I am concerned.  Is there any set of
simplifying assumptions or applicability statements that can be made here
that will make this more likely to succeed?

[Ballot discuss]
The Manageability considerations section is very thin. I would expect for at least the following information to be included:

- what entities will run the MIB module mentioned in the text
- what type of information will be included in the data model represented by this MIB module (information about the discovered PCEs acquired by using the discovery mechanisms, configuration of the discovery mechanisms on the client, discovery protocol statistics, faults)
- will there be any notifications associated with the discovery mechanism?
- what type of management operations are allowed (read-write? if yes, unsing SNMP or other mechanisms?)
- liveness detection and monitoring
- impact on network operations

For the IESG's use in reviewing this document, here is an email exchange between the AD (Ross Callon) and WG Chair (JP Vasseur) regarding some minor changes to be made. My understanding is that the author's will update the document accordingly before our telechat (authors were included in the TO: field of the email).


>>Page 4, section 4.1, first sentence currently reads:

    A routing domain may, in practice, be comprised of multiple PCEs:

Strictly speaking a routing domain is comprised of all sorts of stuff,
of which the PCEs are only a small part. How about instead saying:

    A routing domain may, in practice, make use of multiple PCEs:

Indeed, we should have caught that one. It should read "A routing 
domain may, in practice, contain multiple PCEs"


>> Page 12, Section 6.6, first full paragraph that is on this page
currently states:

    Mechanisms MUST be defined in order to limit the impact of a
    DoS attack on the PCE discovery procedure (e.g. filter out
    excessive PCE information change and flapping PCEs).

The comments above (on PCE generic requirements) apply here as well.
Also, this sentence quite
correctly points to the possibility of an "accidental" DOS attack
(caused by a mis-behaving system) in addition to the possibility
of intentional attacks. How about expanding this slightly to be:

    Mechanisms MUST be defined in order to limit the impact of a
    DoS attack on the PCE discovery procedure. Note also that DOS
    attacks may be either accidental (caused by a mis-behaving
    PCE system) or intentional. As discussed in [reference
    draft-ietf-pce-comm-protocol-gen-reqs-04.txt] such mechanisms
    may include packet filtering, rate limiting, no promiscuous
    listening, and where applicable use of private addresses spaces.

Perfect.

Proto writeup from JP Vasseur:

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. 


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