A PCE-Based Architecture for Application-Based Network Operations
draft-farrkingel-pce-abno-architecture-16

[Ballot comment]
I agree with Stephen's comments.  In the security considerations section, I'd suggest the word regulate and regulated get changed to "manage" and "managed" as opposed to controlled as it may fir with the text better and has the same intent that Stephen is pointing out.

  This security will include authentication and authorization
  to control access to the different functions that the ABNO system can
  perform, to enable different policies based on identity, and to
  regulate the control of the network devices.

  Considering that the ABNO system contains a lot of data about the
  network, the services carried by the network, and the services
  delivered to customers, access to information held in the system must
  be carefully regulated.

[Ballot comment]

- intro: it's not clear to me who is making these increasing
demands. I wonder because it seems sometimes as if it's
lower layer folks demanding that applications demand stuff
from the lower layers. If that is not correct, and if there
are good references to layer 7+ as the real source of
requirements here I think that'd be a nice addition.

- intro: grooming and regrooming aren't terms with which I'm
familiar and don't occur in 5557 so an explanation would be
good, esp. since the usual connotation of Internet grooming
is very negative.

- 2.3.2.7: just a note-to-self really, a function such as
this might be a nice place to do some security things (e.g.
certificate transperency like or to post-facto detect a
DH-MitM in some cases). That might need the auditor to not
belong to the network operator though so may be a different
beast really.

- section 5: do you *really* mean regulated? I think you
mean controlled actually.

- section 5: I think you could note the potential for a
network like this (or any network really) to be used to
track users, esp if one can compromise a node that has
access to information that assists in that (e.g.
configuration or keys for wireless devices or something)

- appendix B: I was a little surprised by this given the
kind of document. It also seems odd that there's no pointer
from this to a reference or URL describing findings or
details.

[Ballot comment]
This being outside of my domain of focus, I'm curious about the choice to publish this document now. There seem to be a number of places where the possibility that a currently unspecified interface will be defined by I2RS, although I gather that this document is not setting requirements for what I2RS will produce. This jumped out at me especially in the case of the ABNO control interface, which seems like a central component. I was also wondering whether ALTO is already being used in the ways described in this document, and Section 3.9 also caught my eye, as it seemed odd to go ahead with what are essentially placeholder use cases to be filled in later. 

I realize there is a trade-off between describing a high-level architecture to drive specification of the components and identifying how existing components can be fit together, but the combination of all of the above items made me wonder about the utility of writing this architecture down now when it could perhaps change depending on how the missing pieces get specified, implemented, and used.

The security considerations seem to emphasize the sensitivity of the network data involved in ABNO and the corresponding need to protect it, but couldn't the application data involved be equally as sensitive and deserving of protection from unauthorized access? That point seems to be missing in the text.

[Ballot comment]
This being outside of my domain of focus, I'm curious about the choice to publish this document now. There seem to be a number of places where the possibility that a currently unspecified interface will be defined by I2RS, although I gather that this document is not setting requirements for what I2RS will produce. This jumped out at me especially in the case of the ABNO control interface, which seems like a central component. I was also wondering whether ALTO is already being used in the ways described in this document, and Section 3.9 also caught my eye, as it seemed odd to go ahead with what are essentially placeholder use cases to be filled in later. 

I realize there is a trade-off between describing a high-level architecture to drive specification of the components and identifying how existing components can be fit together, but the combination of all of the above items made me wonder about the utility of writing this architecture down now when it could perhaps change depending on how the missing pieces get specified, implemented, and used.

IESG/Authors/WG Chairs:

IANA has reviewed draft-farrkingel-pce-abno-architecture-13, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A PCE-based Architecture for Application-based Network Operations) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'A PCE-based Architecture for Application-based Network Operations'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-01-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Services such as content distribution, distributed databases, or
  inter-data center connectivity place a set of new requirements on the
  operation of networks.  They need on-demand and application-specific
  reservation of network connectivity, reliability, and resources (such
  as bandwidth) in a variety of network applications (such as point-to-
  point connectivity, network virtualization, or mobile back-haul) and
  in a range of network technologies from packet (IP/MPLS) down to
  optical.  Additionally, existing services or capabilities like
  pseudowire connectivity or global concurrent optimization can benefit
  from a operational scheme that considers the application needs and
  the network status.  An environment that operates to meet these types
  of requirement is said to have Application-Based Network Operations
  (ABNO).

  ABNO brings together many existing technologies for gathering
  information about the resources available in a network, for
  consideration of topologies and how those topologies map to
  underlying network resources, for requesting path computation, and
  for provisioning or reserving network resources.  Thus, ABNO may be
  seen as the use of a toolbox of existing components enhanced with a
  few new elements.  The key component within an ABNO is the Path
  Computation Element (PCE), which can be used for computing paths and
  is further extended to provide policy enforcement capabilities for
  ABNO.

  This document describes an architecture and framework for ABNO
  showing how these components fit together.  It provides a cookbook of
  existing technologies to satisfy the architecture and meet the needs
  of the applications.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture/ballot/


No IPR declarations have been submitted directly on this I-D.