A Path Computation Element (PCE)-Based Architecture
draft-ietf-pce-architecture-05

I'm slightly surprised that this has only one rather casual mention of the word "loop". I'd have expected some discussion of loop avoidance. Similarly, the assumption that QoS enters into path computation seems very casual given the history of QoS-based routing.

I cleared my DISCUSS as most of the issues I raised were addressed. There is one editorial issue left that is not worth more than a COMMENT, yet I would be glad to see it fixed or hear an explanation. Section 9 lists Manageability Considerations in sub-sections 9.1 to 9.6, and then includes the follwoing:

9.7. Other Considerations

   No other management considerations have been identified.

Why this?

I received the following comments by Pekka Savola from the OPS directorate that
you might want to consider:

(Note: we don't run MPLS or GMPLS TE networks so review from someone            
who does woudln't hurt..)                                                       
                                                                                
I read the draft and thought it was reasonably clear and easy to read.          
There seemed to be a couple of internal inconsistancies (section x              
said "foo", section y said "foo and bar") but nothing major.  I think           
the doc could easily be wrapped up in a month with one revision.                
                                                                                
semi-substantial                                                                
----------------                                                                
                                                                                
4.4. Node Outside the Routing Domain                                            
                                                                                
   An LER might not be part of the routing domain for administrative            
   reasons (for example, a customer-edge (CE) router connected to the           
   provider-edge (PE) router in the context of MPLS VPN [RFC2547] and           
   for which it is desired to provide a CE to CE TE LSP path). 
  This scenario suggests a solution that does not involve doing                
   computation on the ingress (TE LSP head-end) router, and that does           
   not rely on static loose hops configuration in which case optimal            
   shortest paths could not be achieved. A distinct PCE-based solution          
   can help here. Note that the PCE in this case may, itself, provide a         
   path that includes loose hops.                                               
                                                                                
==> I'm not sure how relevant this scenario really is.  If you don't            
rely on external equipment (e.g., CE's, maybe under the customer                
control or not) to participate in the routing domain for                        
administrative reasons, why could you rely on them doing TE decisions?          
(which could hurt ISP's own TE decisions..)  In any case, such nodes            
basically just have a default route to the ISP, so I'm not sure why             
they need to participate in TE at all..                                         
                                                                                
   Conversely, stateless PCEs do not have to remember any computed path         
   and each set of request(s) is processed independently of each other.         
   For example, stateless PCEs may compute paths based on current TED           
   information, which could be out of sync with actual network state            
   given other recent PCE-computed paths changes.                               
 ==> do you assume that if a PCE computes a path, it will actually               
automatically get used?  The last sentence seems to imply that. (But            
text further in the draft doesn't seem to assume that.) The router              
could just also very well discard it.  The path computations made to            
PCC's seem irrelevant, as the PCEs should use solely TED to get info            
about path changes. (This might imply that you might need to wait               
until TED has been updated between each PCE computation to know if it           
was activated or not...)                                                        
                                                                                
editorial                                                                       
---------                                                                       
                                                                                
4.8 Path Selection Policy                                                       
                                                                                
===> it might have been useful to briefly also mention the policy               
synchronization here, because if you have multiple PCE's, that's pretty         
important; whether that needs to be done out-of-band or using e.g., PCE-PCE     
protocols remains to be seen.                                                   

5.3. Multiple PCE Path Computation                                              
                                                                                
   Figure 3 illustrates how multiple PCE path computations may be               
   performed along the path of a signaled service. As in the previous           
   example, the head-end PCC makes a request to an external PCE, but the        
   path that is returned is such that the next network element finds it         
   necessary to perform further computation. This may be the case when          
   the path returned is a partial path that does not reach the intended         
   destination or when the computed path is loose. [...]                        
                                                                                
==> in section 5 or 6, you don't describe the scenario at all where PCC         
sends in a request to a PCE, which fails to provide a reply or replies in       
such a manner (e.g., the first hop is loose) that the PCC needs to contact      
another PCE for better path information.  On the other hand, the second         
bullet in Section 7 seems to imply this is also possible.  Is this an           
intentional omission or should that scenario also be mentioned here?            
                                                                                
(AFAICS, your the two cases addressed here are: 1) contact PCE, get enough      
information to forward packets to the next hop, let that contact the same or    
some other PCE, and 2) contact PCE, and assume inter-PCE communication to       
sort it out.)                                                                                                                                            

6.6. PCC-PCE & PCE-PCE Communication                                            
                                                                                
==> you don't include any requirements on how the communication needs to be     
1) secured (well, later in section 6.10 you have some but PCE-PCE or PCC-PCE    
IMHO belong here; note that you'll probably want more than just                 
confidentiality, e.g., integrity), or                                           
2) what kind of requirements there are for communication (e.g., how fast        
should you notice if the communication doesn't form?  or dies in the middle?)   
[I note that some of this is under 6.5]                                         
                                                                                
9.7. Other Considerations                                                       
                                                                                
   No other management considerations arise.                                    
                                                                                
==> hmm.. shouldn't you rather say, "No other management considerations have    
been identified." ? :-)

Typo in Section 5.6: s/extening/extending/

Please spell out all usage of acronyms in their first usage. Some example of this is ASON, NMS and IGP.