Last Call Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-06
review-ietf-pce-pcep-inter-domain-p2mp-procedures-06-secdir-lc-tsou-2014-05-30-00

Dear all,



I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were
 written primarily for the benefit of the security area directors.  Document
 editors and WG chairs should treat these comments just like any other last
 call comments.



Technical comments:

This draft focused on solving inter-domain P2MP procedures. The solution is
based on a core-tree and corresponding sub-trees construction, with BRPC
 used as reference. The procedure in this draft is complete and promising for
 an inter-domain P2MP path computation. However, for future work, following
 comments may be considered:

Now each PCE is considered friendly with each other, i.e., the cost on the
sub-tree will be reflected on the core-tree, and the signals are free to
 be transmitted correspondingly. But, this is the ideal case, PCE may need to
 hide some intra-domain information due to some security policies, so that
 global optimization may not be achieved. In this way, it should be better to
 split into a few scenarios, such as ‘friendly’ and ‘not friendly’ case. In the
 ‘not friendly’ scenario, it is also necessary to limit what signal is allowed
 and what is prohibited. There is no much existing work for this scenario, even
 for a P2P path computation, so the work for P2MP computation in this scenario
 should be listed as future work.



Nits:

In section 1, captions are not numbered correctly. The item “scope” and
“Requirements Language” should be section 1.1 and 1.2 respectively.



In section 3, the 5

th

 paragraph, “as discussed in [RFC4461], …”, the last sentence should be changed
 as follow:

Not only is this selection constrained by the network topology and available
network resources, but it is

also

 determined by the objective functions (OF) that may be applied to path
 computation.



Then in the next paragraph, “Generally, an inter-domain …”, following changes
are suggested:

For instance, while the BRPC may be well-suited for P2P paths, P2MP path
computation involves multiple branching path segments from the source to

the

multiple destinations. As such, inter-domain P2MP path computation may result
in a plurality of per-domain path options that may be difficult to coordinate
efficiently and effectively

between

among

 domains.



In the second paragraph from bottom of Section 3, “P2MP Minimum Cost Tree
(MCT), …”, following changes are suggested:

P2MP Minimum Cost Tree (MCT), i.e., a computation which guarantees the least
cost resulting tree, typically is an NP-complete problem. Moreover, adding
and/or removing
 a single destination to/from the tree may result in an entirely different
 tree.  In

this case

these cases

, frequent MCT path computation requests may prove computationally intensive,
and the resulting frequent tunnel reconfiguration may even cause network
destabilization.



For section 4, the first assumption is suggested to be:

Due to deployment and commercial limitations (e.g., inter-AS peering
agreements), the path domain tree

will

should

 be known in advance;



For section 5, the 4

th

 requirements is suggested to change:

      4.  Specifying which nodes are be

ing

 used as branch nodes SHOULD be supported in the PCReq.



For section 7.2, in the paragraph “Without trimming, the ingress…”, the
following change is recommended:

Without trimming, the ingress PCE will obtain all the possible S2L sub-paths
set for the entry boundary nodes of the leaf domain. The PCE will then, by
looking through
 all the combinations and taking one sub-path from each set to build one tree,

can

select the optimal core-tree.



For section 7.3, in the paragraph “Note that the P2MP path request…”, the
following change is recommended:

Note that the P2MP path request and response format is as per [RFC6006], where
Record Route Object (RRO)

are

is

 used to carry the core-tree paths in the P2MP grafting request.



For section 8.1, the following change is recommended:

8.1. End-to-end Protection

   An end-to-end protection (for nodes and links) principle can be applied for
   computing backup P2MP TE LSPs.  During computation of the core-tree and
   sub-trees,

the computation of protection

 may also be taken into consideration. A PCE may compute the primary and backup
 P2MP TE LSP together or sequentially.





Thank you,

Tina