Early Review of draft-farrkingel-pce-abno-architecture-11
review-farrkingel-pce-abno-architecture-11-opsdir-early-tsou-2014-10-16-00

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 2.3.1.8.2, 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

is

 sends

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

and-user

end-user

 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

Controller

Coordinator

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
2.3.1.8) to contain information about server loads and other data center
parameters.





Thank you,

Tina