Re: [Sdn] Call for review of draft-farrkingel-pce-abno-architecture

["King, Daniel" <[e-mail]>]

Thanks Luis, this is a really detailed review and very welcome. 

Br, Dan. 

-----Original Message-----
From: sdn [mailto:[e-mail]] On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: 13 August 2014 20:42
To: King, Daniel; '[e-mail]'
Cc: [e-mail]
Subject: Re: [Sdn] Call for review of draft-farrkingel-pce-abno-architecture

Dear Daniel, Adrian,

As requested by you, I provide here a number of comments and suggestions to the draft. I hope you can find them constructive and useful.

I have structured my comments in Generic, when they apply to the general architecture ideas exposed in the draft, and Specific, when they apply to certain points or sections which are identified for facilitating the corresponding text.

Generic
=======

.- service -awareness. The ABNO architecture does not present an specific module or component responsible to maintain the status of the connectivity service requested by the NMS/OSS/Application on top. By status I refer to the following information: administrative and operational status of the connectivity service; user and/or application which has requested the service; some identifiers (interchanged with the application/NMS/OSS to index the service); accountability of the resources in use for that service; associated QoS and policies/priorities to be applied; etc. I see that statefull PCE could cover this in part. But I think the draft should explicitly describe how all of this information is maintained during the service lifecycle.
Along different parts of the text it is clear that this service-awareness is required in ABNO. For instance:
+ the first bullet of the introduction mentions the possibility of 
+ optimizing traffic flows between applications. For optimizing / re-optimizing it is needed to know in advance the resources associated to any of the applications in place, as well as their privileges, QoS, SLAs, etc, and also it is needed to differentiate one service from the others (through some kind of identifiers e.g., service-id or circuit-id) the policy agent propagates policies in ABNO, as indicated in 2.3.1.4. However, if there are policies per application or even per user of the application, then ABNO should keep / handle the status of each connectivity service.
+ a similar need arise when considering OAM., as in 2.3.1.6. If the 
+ problems in the network should be correlated or risen to the affected 
+ application, then it is needed to keep information of the resources 
+ per application, as well as SLA, end points to be tested, kind of data 
+ to be reported, etc. Furthermore, if this information can be used for 
+ triggering further actions like service recovery (as in section 
+ 2.3.2.13) then it is necessary to check the status and information 
+ (priorities, privileges, SLAs, etc) of each service before performing 
+ any recovery action same comment applies to the reoptimization case in 
+ 3.5.2
This service-awareness module or component could come in the form of an additional DB to the ABNO architecture feed with the information mentioned before, plus some logic capable of handling and retrieving that (for instance part of the information can be retrieved from the statefull PCE). If you agree with this comment, I can provide some contribution on this if you want.

.- interaction with SDN controllers: the ABNO architecture supports the SDN concepts. In fact, it is stated in section 2.3.1.11 that the Provisioning Manager itself may act as an OpenFlow Controller, and also OpenFlow is mentioned in the text as one of the potential protocols for controlling network resources. (I don't intend to relate SDN only to OpenFlow  here, it is just for reference). In the insight over provisioning manager control of networks, in section 2.3.2.6, a number of protocols are listed, and also some ideas about potential triggering of actions are provided. What I miss from the information before is the capability of ABNO for directly interacting with SDN controllers. That is, that the provisioning manager interacts with an SDN controller (e.g., through a REST API interface) instead of directly interact with network devices. Then, considering it as an option, the usage of REST API interfaces should be included in the list for program/configuring devices, and the fact of triggering actions with SDN controllers should be included in the list of triggered actions through control plane. To illustrate the concept I have attached slightly modified versions of Figure 5 and 15, as examples. This way of positioning ABNO is something we are proposing in the FP7 XIFI project (see for instance [1]). In this case ABNO acts as an orchestrator of separated SDN domains, and ABNO is able of interacting with each of those domains through a REST API with the local controllers. As an additional interaction, besides of controlling network elements, the ABNO can obtain topology information from the SDN controller directly (the topology information obtained from running LLDP in the SDN/OpenFlow environment).

.- reporting of resources usage / billing: one missing piece in current ABNO architecture is the inclusion of reporting capabilities with respect the usage of the resources in one provisioned service. Such usage reports could be lately processed for billing purposes, for instance. Something similar to the existing CDRs in current networks. It is of special interest when external applications demand services to a network provider. I guess this capability should be present in the ABNO control interface (section 2.3.2.11) to inform the applications or the NMS/OSS about this usage.

.- resiliency and scalability. Chapter 4 presents some text about survivability and resiliency in ABNO.  In my understanding there is a mix of resiliency and scalability in such text. I would suggest to separate both concepts. For instance, second paragraph is more related to scalability, in my opinion. When talking about the scalability it can be assumed that multiple instances of the different components can be in place, each of them taking over some workload of the total workload offered to ABNO. The workload split can be implemented e.g. by technology. The workflows in the ABNO controller could be the glue of such split workload to compose a complete connectivity service. However, when talking about resiliency additional functionality has to be in place to ensure consistency and to keep the status of the provisioned resources among the different instances that provide reliability. The scalability and resiliency features are different and have different needs, even if they are supported in the same way, i.e., through several instances of the same component. If you share also this vision I can prepare some text on that, if you wish.

Specific
======

.- In the abstract some services are presented as the main drivers for ABNO by placing new connectivity requirements. Being that true, however the draft presents a number of other conventional services that are also benefitted from the introduction of ABNO. IN fact the list of those conventional services is longer than the new ones. I can identify services/applications in sections 3.1, 3.3, 3.4, 3.5 and 3.6 as conventional services that can take advantage of ABNO. Considering that, I would suggest to include a new sentence (before the last one in the first paragraph) in the abstract remarking also the benefits for these other cases, for instance: "Additionally, existing services or capabilities like pseudowire connectivity or global concurrent optimization can be benefitted from a more comprehensive operation considering the application needs and the network status".

.- in section 2.3.1.6 it is mentioned that the OAM handler interacts with the devices to perform OAM actions. This implies some access to the control plane of the devices to trigger that actions. What kind of interface is used to that? I2RS, other?

.- section 2.3.1.8.1: when talking about the TED it is mentioned that the TED may provide information to application services like ALTO. It is not clear to me if you refer to the ALTO Server included in the ABNO architecture of Figure 1, or to external ALTO clients. In the second case, then it would be needed to clarify this by including some sentence in the sense that the TED can act as an ALTO server itself.

.- section 2.3.1.9. When talking about ALTO Server it seems that its role in the ABNO architecture is to offer information to the applications on top. However, it can also be used internally by the ABNO components to perform their corresponding functions e.g. at provisioning time. To that respect, I wonder if the ALTO module in ABNO could also act as ALTO client of external ALTO Servers if available. This for instance could be useful in multi administrative domains (somehow similar to the case described in 3.1 but when each AS is part of a different administrative domain). If so I would suggest to include a sentence pointing out such possibility, e.g.: "The ALTO component in the ABNO architecture could behave also as ALTO client to retrieve information from external ALTO Servers either for providing a complete network view to the Application Service Coordinator, or for allowing the other modules in ABNO to perform their corresponding tasks".

.- section 2.3.2.4. When talking about the protocols for exporting the TED, the first bullet refers to the ALTO protocol. It is not clear to me if the interaction with the TED in this case is indirect, i.e. passing through the ALTO Server in ABNO architecture, or if it means that the TED actually implements the ALTO protocol as NBI. I would suggest to make this clear.

.- section 2.3.2.7. The auditing process is referred to the provisioning process, but for completeness, it has to be extended to the other two possible workflows: decommissioning or deletion of connectivity services, and the modification of existing connectivity services.

.- section 2.3.2.12. In the second list of bullets, I would include QoS classification.

.- section 3.1. Despite multiple AS are involved in this use case, it seems that all the AS pertain to the same administrative domain. Is that correct? If so, probably it would be nice to include such clarification in the text.

.- section 3.7. I bring to your attention the following reference for cross-stratum optimization with PCE (draft-dhody-pce-cso-enabled-path-computation-06) just in case you consider relevant and worthy refer to that possibility in the text. The architecture presented there fits totally, in my opinion, with ABNO, where the NCG + PCE module presented in that draft can be seen as the ABNO.

.- section 6. I would modify a bit the third bullet in the following sense: "- Management and monitoring of ABNO components"

Typos
=====

.- just before section 1.1: ". Network Management Station (NMS) ans Operations Support System (OSS) ." -> ". Network Management Station (NMS) and Operations Support System (OSS) ."

.- idem: ". recent developments programmatic ." -> ". recent developments of programmatic ."

.- section 2.3.1.1: For NMS you span the acronym as Network Management Station, but it seems to be more proper to talk about Network Management System.

.- section 3.2.1. End of second paragraph. ". remote DCs an be operated ." -> ". remote DCs can be operated ."

.- section 3.2.1. Bullet 1. ". two end points. the actual ." -> ". two end points. The actual ."

.- sentence above Figure 24. ". network such such that ." -> ". network such that ."

.- section 3.7. 1st paragraph. ". application and network stratums." -> ". application and network strata."


Best regards,

Luis

[1] J. González, F. Álvarez, L.M. Contreras, Ó. González, "Interdomain Monitoring and Internetworking Connectivity in Federated Infrastructures based on Software Defined Networking", Proceedings of 2014 European Conference on Networks and Communications (EuCNC), Bologna, June, 2014


-----Mensaje original-----
De: sdn [mailto:[e-mail]] En nombre de King, Daniel Enviado el: viernes, 25 de julio de 2014 20:27
Para: '[e-mail]'
CC: [e-mail]
Asunto: [Sdn] Call for review of draft-farrkingel-pce-abno-architecture

Hi SDN RG'rs,

The authors of draft-farrkingel-pce-abno-architecture are in the process of requesting AD-sponsored publication of draft-farrkingel-pce-abno-architecture:

http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture

This I-D is a bit of an architecture and a bit an applicability statement. It has been presented in SDNRG a couple of times.

The last call will obviously pop out sometime, but it would be nice to have review comments before then. Perhaps you could send your comments to the authors or to the RTGWG list rather than clogging this list with discussion of an IETF draft.

Thanks,
Dan

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição