Early Review of draft-farrkingel-pce-abno-architecture-11

Request Review of draft-farrkingel-pce-abno-architecture
Requested rev. no specific revision (document currently at 16)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2015-01-20
Requested 2014-09-19
Authors Daniel King, Adrian Farrel
Draft last updated 2014-10-16
Completed reviews Genart Last Call review of -13 by Vijay Gurbani (diff)
Genart Telechat review of -15 by Vijay Gurbani (diff)
Opsdir Early review of -11 by Tina Tsou (diff)
Opsdir Last Call review of -13 by Tina Tsou (diff)
Rtgdir Early review of -11 by Tomonori Takeda (diff)
Rtgdir Early review of -13 by Julien Meuric (diff)
Assignment Reviewer Tina Tsou
State Completed
Review review-farrkingel-pce-abno-architecture-11-opsdir-early-tsou-2014-10-16
Reviewed rev. 11 (document currently at 16)
Review result Has Issues
Review completed: 2014-10-16


Dear all,


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


Technical Comments:


This document provides a complete overview for both the existing networking and future networking and proposes architecture that compatible to both. It is quite generic and can be applied in various scenarios; however it is not easy
 to generate networks directly from this draft. There can be some future architectural drafts based on the ABNO architecture, talking about the detailed applications, for example, multi-layer architectures. Similar issue applies to most of the use case mentioned
 in section 3. 


From the architecture figure 1, it seems that the ABNO controller is the critical functional block in the architecture and a lot of interactions between this controller and other blocks are required. It is a necessary to consider the
 complexity of such controllers, which may bring difficulties for implementation. On the other hand, this figure only shows the one-to-one relationship between ABNO controller and PCE, however, there may be N-to-one or one-to-N cases for different applications.
 Some description should be included in section 2 for better specification. The functionalities between PCE and ABNO controller is also not very clear, there may be following understanding: the PCE is responsible for Path computation and ABNO controller for
 configuration, or, the PCE is responsible for Path computation and configuration while the ABNO controller is responsible for negotiation with APP layer. It is fine to be open on this question.

For section, it is necessary to describe the relationship between LSP database and stateful PCE, i.e., stateless PCE may not be able to use this database.


For section 3.2 multi-layer use case, there are 7 steps for service provisioning. RFC 5623 provide more than one solutions and there are still other alternatives for cross-layer service provisioning. Future work need to be added to make
 the solution more complete, maybe in separate draft with more specific descriptions.



Editorial Comments:


In section 3.1, The Hierarchical PCE section, the second paragraph has the following correction:


As shown in Figure 4, the ABNO Controller sends a request to the parent PCE for an end-to-end path.  As described in [RFC6805], the parent PCE consults its TED that shows the connectivity between ASes.  This helps it understand that
 the end-to-end path must cross each of ASa, ASb, and ASc, so it 



a few

 individual path computation requests to

each of 

PCE a, b, and c to determine the best options for crossing the ASes.



In section 3.7.2, the 2nd paragraph, “Figure 29 shows … ”, some editorial changes should be applied  as follow:

Figure 29 shows a diagram of an example data center based application.  A carrier network provides access for an




 through PE4. Three data centers (DC1, DC2, and DC3) are accessed through different parts of the network via PE1, PE2, and PE3.  

The Application Service Coordinator receives information from the end-user about the services it wants, and converts this to service requests that it passes to the the ABNO Controller. The end-user may already know which data center
 it wishes to use, the Application Service 




may be able to

can either

make this determination, or 

the task of selecting the data center may be left

leave it

to the ABNO Controller, and this may utilize a further database (see Section to contain information about server loads and other data center parameters.



Thank you,