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

From: <[email-masked]>
Date: Fri, 1 Aug 2014 07:19:22 +0000

Hi Dan,

Please note that I have read the draft and I am willing to send comments to the  RTGWG list.
Please note, however, that this will happen after the 15th of August, since I am now on holidays.

Best regards,
Georgios

________________________________________
Van: sdn [[email-masked]] namens King, Daniel [[email-masked]]
Verzonden: vrijdag 25 juli 2014 20:27
Aan: [email-masked]'
CC: [email-masked]
Onderwerp: [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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 13 Aug 2014 19:41:37 +0000

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:[email-masked]] En nombre de King, Daniel
Enviado el: viernes, 25 de julio de 2014 20:27
Para: [email-masked]'
CC: [email-masked]
Asunto: [Sdn] Call for review of draft-farrkingel-pce-abno-architecture

Hi SDN RG'rs,

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

---

From: "King, Daniel" <[email-masked]>
Date: Thu, 14 Aug 2014 10:43:59 +0000

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

Br, Dan. 

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

Dear Daniel, Adrian,

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.

Specific
======

Typos
=====

Best regards,

Luis

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

Hi SDN RG'rs,

Thanks,
Dan

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 15 Aug 2014 20:28:17 +0100

Hi Luis,

Many thanks.

Discussions in line.

> 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.

I think I see what you are asking about, and I believe this is the role of the
ABNO Controller. That is the component that receives service requests from the
Application Service Coordinator and is responsible for working out how the
service can be realised and for reporting back about the status of the service.

On the other hand, in some circumstances it may be the Application Service
Coordinator that has this responsibility. That is, if the service is
particularly complicated or if the "application" is very unaware of what a
"service" is.

Now, you specifically mention "connectivity service requests." These are, I
suppose, pretty much the simplest services and I would expect that the ABNO
Controller to have the responsibility both for enabling the services and for
reporting their status. 

Although there are some "fast paths" in our model. Thus, an application could
control the network directly, and can receive notifications direct from the OAM
Handler.

> 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)

I think that what would happen in this case is that the Application Service
Coordinator would present a package of information to the ABNO Controller. If
the services had already been established by the ABNO Controller, this could be
just the service identifiers, but other information (such as modifiers of the
service expressed as likely traffic demands and so forth) would make the
operation more fruitful. The ABNO Controller would then have the job of
achieving the optimization. 

Of course, the action would be under the influence of policies that had already
been installed...

> + 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.

Agreed.

> + 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

I think I agree as well.
It is somewhat hard to draw all interactions between all components in the
architecture.
The OAM Handler will need to understand which services have been affected by
faults that it learns of.
In some cases (CC or CV) this is pretty simple.
In other cases (link down) more active correlation is required.
I think there is a trade of work between the OAM Handler and the ABNO Controller
for a lot of this work.

> 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.

I think you are saying that, in order to achieve its function, the ABNO
controller will need a database that maps services to underlying network
resources. I agree that the ABNO controller would need to keep this state
information, and that the information would need to be "persistent". 

I am wondering whether this database is internal or external to the ABNO
Controller. If it is internal, then it is just an implementation choice for the
ABNO Controller - it may be a necessary function of the Controller, but it is
not an externally visible feature.  If it is external then it needs to be
described (probably in 2.3.1.8 with a reference from 2.3.1.3), but I would like
to understand which other components or external agents examine this database -
perhaps your point is that the OAM Handler may look at it, and that it could be
exposed to the applications so that they can 'know' what is happening in the
network.

If you have thoughts on that, I'd be happy to see some text. Or, if I have
basically captured it in the previous paragraph, I can make the edits myself
without any pain.

> .- 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.

So I'm a bit confused.
Having said that the Provisioning Manager may act as an SDN controller, what
does it mean for "ABNO to interact with an SDN controller"?
The point, I think of the ABNO architecture is to pull together all of the
components that may operate and manage a network. Thus the SDN controller is
within the ABNO architecture not external to it.

On the other hand, we did not want to tie this architecture to the SDN
architecture or "buzz". It is what it is. SDN is a profile/application of ABNO,
or SDN is something on its own. This is neither competition for SDN nor an
attempt to subsume it.

> 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).

So, I think, consistent with my previous comment, the REST API (such as the
Floodlight API) would sit between the ABN Controller and the Provisioning
Manager.

This is also consistent with the Floodlight Controller having the job of
determining the network path before programming the network elements. In other
words, the controller (Provisioning Manager) needs to consult a component (that
may be coded as internal, but which is functionally distinct) that computes
paths (PCE).

So I'm adding

2.3.2.12 ABNO Provisioning Requests

   Under some circumstances the ABNO Controller may make requests direct
   to the Provisioning Manager.  For example, if the Provisioning
   Manager is acting as an SDN Controller then the ABNO Controller may 
   use one of the APIs defined to allow requests to me made to the SDN
   Controller (such as the Floodlight REST API [Flood]).  Alternatively,
   since the Provisioning Manager may also receive instructions from a 
   stateful PCE, the use of PCEP extensions might be appropriate in
   some cases [I-D.crabbe-pce-pce-initiated-lsp].

> .- 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.

Right. We struggle to show every possible interface or use case, but you're
right about how this would be done.

> .- 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.

That would be interesting. I think I agree that resilience may need additional
functionality and state synchronisation in some cases. On the other hand, in
some cases, especially when seamless resiliency is not needed, it is enough to
switch to another instance and repeat the request  (consider issuing a request
to a PCE that fails - you would just re-issue the request to a new PCE).

I don't believe that this document has to describe every possible interaction
between all components, but I will add a sentence to the penultimate paragraph
of Section 4...

   In some circumstances state synchronization between
   instances of components may be needed in order to facilitate seamless
   resiliency.

> 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".

Yes. Edited a little.

> .- 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?

The reference loop is a bit squiggly...

2.3.1.6 describes the OAM Handler, but 2.3.2.14 describes interfaces to the OAM
Handler. 2.3.2.14 includes a back-pointer to 2.3.2.1 for the mechanisms that
might be used.

You're right that I2RS (but what is that?) might also be used, or maybe
Netconf/YANG is used for I2RS and for this purpose?

> .- 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.

I don't think that external ALTO clients would be interested in the content of
the TED in its raw form. I think it needs to pass through an ALTO server.

> .- 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".

Right. But (again) we can't possibly show or discuss every interaction between
every pair of components or every possible use case.

I am slightly dubious, however, about where such an "external ALTO server would
reside." Note that this is an architecture, not an implementation guide, so I
think that the situation you describe is really that one ALTO server may act as
a client for another ALTO server to enable them to serve different but
cooperating networks.

> .- 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.

I personally believe that if the topology is being exported for ALTO uses, it
should pass through an ALTO server.

However, the ALTO protocol is a potential mechanisms for exporting topologies,
and the TED contains topology. So the point here is that the *protocol* could be
ALTO without the use case being ALTO.

> .- 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.

Yes. Good point. Change made to text.

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

Yup.

> .- 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.

I don't see what brings you to this conclusion.
There are several approaches shown in the section and the choice may depend on
the relationship between ASes. For example, cooperating H-PCEs require that the
PCEs can, erm, cooperate. Yet the referenced 5520 allows "secrecy" in this mode
of operation. Alternatively, Figure 7 shows a different way to cut the cake.

> .- 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.

A shameless advertisement :-)

Actually, I am embarrassed to see that the figure in Section 3.7.2 is very
strikingly similar to Figure 1 in your draft that has been there since your -00
revision. No doubt this is because Young was the contributing author of Section
3.7 and is also a co-author on your draft. Nevertheless, I will add in the
cross-reference to make this clear and to show some relationship between the
work.

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

Yeah, OK.

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

yes

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

s/of/in/

> .- 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.

Yes, http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt has "System"

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

yes

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

yes

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

yes

> application and network strata."

Yeah.

Once again, many thanks.

You forgot...

Section 7, add "Luis Contreras"

Cheers,
Adrian

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 18 Aug 2014 23:49:31 +0000

Hi Adrian,

Thanks for the clarifications. Please, find additional comments/thoughts below for some of the topics. For the rest of the points, they become now clear to me after your reply.

-----Mensaje original-----
De: Adrian Farrel [mailto:[email-masked]]
Enviado el: viernes, 15 de agosto de 2014 21:28
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: 'King, Daniel'; [email-masked]
Asunto: RE: Call for review of draft-farrkingel-pce-abno-architecture

...

> 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
this
> comment, I can provide some contribution on this if you want.

I think you are saying that, in order to achieve its function, the ABNO controller will need a database that maps services to underlying network resources. I agree that the ABNO controller would need to keep this state information, and that the information would need to be "persistent".

I am wondering whether this database is internal or external to the ABNO Controller. If it is internal, then it is just an implementation choice for the ABNO Controller - it may be a necessary function of the Controller, but it is not an externally visible feature.  If it is external then it needs to be described (probably in 2.3.1.8 with a reference from 2.3.1.3), but I would like to understand which other components or external agents examine this database - perhaps your point is that the OAM Handler may look at it, and that it could be exposed to the applications so that they can 'know' what is happening in the network.

If you have thoughts on that, I'd be happy to see some text. Or, if I have basically captured it in the previous paragraph, I can make the edits myself without any pain.

[Luis>>] I think that the most appropriate case would be to consider it as a DB external to the ABNO Controller. I see a number of actions (implemented by ABNO components or external modules) using this DB:
.- recovery: the DB is queried to retrieve state of the service to be recovered
.- OAM: alarm correlation, reporting to the corresponding application, etc
.- resource usage: CDR like information
.- provisioning / deletion / modification of resources as per application requests.
.- network planning: the info the DB can be used for planning purposes, applying forecast demands to some existing services.
.- service inventory: the DB can play the role of service inventory then complementing some other resource inventory in place.
.- transport abstraction: this DB keeps the link between the service requested and how this service is implemented from the transport point of view.
I attach some text with these ideas for your convenience, in case you agree with what is stated before.

> .- 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
the
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
capability of
provisioning
> manager interacts with an SDN controller (e.g., through a REST API
> interface) instead of directly interact with network devices.

So I'm a bit confused.
Having said that the Provisioning Manager may act as an SDN controller, what does it mean for "ABNO to interact with an SDN controller"?
The point, I think of the ABNO architecture is to pull together all of the components that may operate and manage a network. Thus the SDN controller is within the ABNO architecture not external to it.

On the other hand, we did not want to tie this architecture to the SDN architecture or "buzz". It is what it is. SDN is a profile/application of ABNO, or SDN is something on its own. This is neither competition for SDN nor an attempt to subsume it.

[Luis>>] I think that one of the strengths of ABNO is precisely not to be tight to SDN only, or in other words, it facilitates to simultaneously work with different kind of networks, or profiles as you referred to. But because we are discussing this on the mailing list of the SDN RG let me go a bit further, just sharing my thoughts.
When I mention about a direct interaction of ABNO with an SDN Controller, I mean that the Provisioning Manager can interact with an SDN controller, as reflected in the modified figures I attached in my previous mail. But I agree that this can be considered as part of the Provisioning Manager itself, i.e., the Provisioning Manager could use a conventional SDN Controller (e.g., Floodlight, Ryu, etc) instead of building the logic itself.
My only worry here is that considering the SDN Controller as part of the Provisioning Manager produce asymmetric scenarios from the control plane point of view. Let me explain. With the SDN Controller logic being part of the PM, the ABNO would interact with devices without control plane capabilities. However, at the same time the PM could interact with some other devices, not SDN-based, that incorporate control plane capabilities (e.g., GMPLS based control). Maybe this different approach could condition the way the workflows are developed, avoiding generalization and technology agnostic approach.

> 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).

So, I think, consistent with my previous comment, the REST API (such as the Floodlight API) would sit between the ABN Controller and the Provisioning Manager.

This is also consistent with the Floodlight Controller having the job of determining the network path before programming the network elements. In other words, the controller (Provisioning Manager) needs to consult a component (that may be coded as internal, but which is functionally distinct) that computes paths (PCE).

[Luis>>] I see your point. That would reflect the case of the SDN Controller working in active mode. However, for an SDN Controller in passive mode probably not. Nevertheless this would not prevent of using the REST API there, of course.

So I'm adding

[Luis>>] ok. What I would expect would be a common interface between the ABNO Controller and the Provisioning Manager, and then a number of adaptors or protocols there as southbound interfaces to interact with different kind of devices. From the text above I understand that such interface could be for instance a REST API (as the one in Floodlight) or PCEP.

...

survivability 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
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
that
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.

That would be interesting. I think I agree that resilience may need additional functionality and state synchronisation in some cases. On the other hand, in some cases, especially when seamless resiliency is not needed, it is enough to switch to another instance and repeat the request  (consider issuing a request to a PCE that fails - you would just re-issue the request to a new PCE).

I don't believe that this document has to describe every possible interaction between all components, but I will add a sentence to the penultimate paragraph of Section 4...

[Luis>>] When you consider the provisioning of a new service probably state synchronization it is not an issue. As you mention you can try with another instance of a given component and just be sure that the running component record the state. There are however more challenging cases:
.- ABNO components resiliency: the modification or deletion of provisioned services has to be performed with certainty about the resources associated to any of the services. If this state is not properly kept then the operation of modifying or deleting a service could impact some other service. Additionally, if a given component fails during the process of modification or deletion (or even provision), then some mechanisms should be in place to either take over the operation in the state found at the moment of the failure or to undo whatever action was performed before the failure.
.- Network elements resiliency: when one network element fails or should be rebooted, for instance, the services have to be re-deployed with the same properties / characteristics as they were running before the failure. As an example, in an SDN environment the forwarding rules should be re-installed in the device, so these have to be kept in some place (or should be a way of regenerating them for re-installation).
Maybe this could be addressed in this or in another document. But in my opinion it is a relevant topic to provide an operational insight to the ABNO architecture (talking from an operator perspective).

...

the
it
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".

Right. But (again) we can't possibly show or discuss every interaction between every pair of components or every possible use case.

I am slightly dubious, however, about where such an "external ALTO server would reside." Note that this is an architecture, not an implementation guide, so I think that the situation you describe is really that one ALTO server may act as a client for another ALTO server to enable them to serve different but cooperating networks.

[Luis>>] I see reasonable your concern about the difficulty (and manageability) of documenting every possible use case. My question was certainly about cooperating networks (e.g. cloud or content over the top).
...

that all
probably

I don't see what brings you to this conclusion.
There are several approaches shown in the section and the choice may depend on the relationship between ASes. For example, cooperating H-PCEs require that the PCEs can, erm, cooperate. Yet the referenced 5520 allows "secrecy" in this mode of operation. Alternatively, Figure 7 shows a different way to cut the cake.

[Luis>>] What I had in mind here was the following: if the AS's are part of the same administrative domain, the ABNO framework can control all the devices in the way you describe. However, if the AS's pertain to different administrative domains, then it is not so clear how one ABNO Controller can (directly) provision resources from other different domains. This has several implications. Maybe a simplistic scheme could be the interworking of ABNOs, just to say something. As you mention documenting every possible use case is not the objective of the draft.

...

[Luis>>] Thanks ;-)

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 24 Aug 2014 18:11:08 +0100

Hi Luis,

Continuing this conversation:

> > that (for instance part of the information can be retrieved from the
> > stateful PCE). If you agree with this comment, I can provide some
> > contribution on this if you want.
> 
> I think you are saying that, in order to achieve its function, the ABNO controller
> will need a database that maps services to underlying network resources. I agree
> that the ABNO controller would need to keep this state information, and that the
> information would need to be "persistent".
> 
> Controller.

[snip]
 
> [Luis>>] I think that the most appropriate case would be to consider it as a DB
> external to the ABNO Controller. I see a number of actions (implemented by
> ABNO components or external modules) using this DB:
> .- network planning: the info the DB can be used for planning purposes, applying
> forecast demands to some existing services.
> .- service inventory: the DB can play the role of service inventory then
> complementing some other resource inventory in place.
> .- transport abstraction: this DB keeps the link between the service requested
> and how this service is implemented from the transport point of view.

Thanks for these thoughts and for the attached text. Actually, to me this makes the service DB sound like an ABNO component. That is, it stores state about the requested services and the relation between those services and the underlying network resources. That state is used by ABNO components during the normal course of events and also in recovery situations. The state could be examined by external parties and can be verified (synchronised) on recovery.

If it is OK with you I will work up the text and ideas you've sent into a new sub-section describing the "Services DB".

> > 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
> > also some ideas about potential triggering of actions are provided.
> > What I miss from the information before is the capability of
> > provisioning manager interacts with an SDN controller (e.g., 
> > through a REST API interface) instead of directly interact with
> > network devices.
> 
> So I'm a bit confused.
> architecture or "buzz". It is what it is. SDN is a profile/application of ABNO, or
> SDN is something on its own. This is neither competition for SDN nor an
> attempt to subsume it.
> 
> [Luis>>] I think that one of the strengths of ABNO is precisely not to be tight to
> SDN only, or in other words, it facilitates to simultaneously work with different
> kind of networks, or profiles as you referred to. But because we are discussing
> this on the mailing list of the SDN RG let me go a bit further, just sharing my
> thoughts.
> When I mention about a direct interaction of ABNO with an SDN Controller, I
> mean that the Provisioning Manager can interact with an SDN controller, as
> reflected in the modified figures I attached in my previous mail. But I agree that
> this can be considered as part of the Provisioning Manager itself, i.e., the
> Provisioning Manager could use a conventional SDN Controller (e.g., Floodlight,
> Ryu, etc) instead of building the logic itself.
> My only worry here is that considering the SDN Controller as part of the
> Provisioning Manager produce asymmetric scenarios from the control plane point
> of view. Let me explain. With the SDN Controller logic being part of the PM, the
> ABNO would interact with devices without control plane capabilities. However, at
> the same time the PM could interact with some other devices, not SDN-based,
> that incorporate control plane capabilities (e.g., GMPLS based control). Maybe
> this different approach could condition the way the workflows are developed,
> avoiding generalization and technology agnostic approach.
 
So, for the discussion, let's continue this...

Yes, there is an imbalance in the operations that the PM can perform. This is a bit like the old fashioned NMS that could program individual nodes or could send instructions to the control plane. Or, if we look at the combination of an NMS, the control plane, and the EMSes, then the ABNO architecture and the SDN architecture are all part of the same world view and can be freely mixed up.

Just for clarity, I am not saying that the SDN Controller must be part of the Provisioning Manager in ABNO. What I am saying is that this is an architecture not an implementation blueprint. That means that you realise the architecture using the components you have lying around, and build new ones if you need them. So, you can have multiple implementation components that realise the Provisioning Manager function. So, for a combined system you might have (and considering "internal" to mean "within the software box labelled ABNO"):
- An internal PM that talks to a control plane (like GMPLS)
- An internal PM that talks to external nodes as if an SDN Controller
- The PCE talking direct to the control plane
- The ABNO Controller talks to an external SDN Controller (that is, of course, a PM)

> > 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).
> 
> This is also consistent with the Floodlight Controller having the job of determining
> the network path before programming the network elements. In other words,
> the controller (Provisioning Manager) needs to consult a component (that may
> be coded as internal, but which is functionally distinct) that computes paths
> (PCE).
> 
> [Luis>>] I see your point. That would reflect the case of the SDN Controller
> working in active mode. However, for an SDN Controller in passive mode
> probably not. Nevertheless this would not prevent of using the REST API there,
> of course.

Sure. The point is to include all of the functional options.

> [Luis>>] ok. What I would expect would be a common interface between the
> ABNO Controller and the Provisioning Manager, and then a number of adaptors
> or protocols there as southbound interfaces to interact with different kind of
> devices. From the text above I understand that such interface could be for
> instance a REST API (as the one in Floodlight) or PCEP.

Yup. That's what the text tries to say.

> > 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.
> 
> switch to another instance and repeat the request  (consider issuing a request to
> a PCE that fails - you would just re-issue the request to a new PCE).
> 
> [Luis>>] When you consider the provisioning of a new service probably state
> synchronization it is not an issue. As you mention you can try with another
> instance of a given component and just be sure that the running component
> record the state. There are however more challenging cases:
> .- ABNO components resiliency: the modification or deletion of provisioned
> services has to be performed with certainty about the resources associated to
> any of the services. If this state is not properly kept then the operation of
> modifying or deleting a service could impact some other service. Additionally, if a
> given component fails during the process of modification or deletion (or even
> provision), then some mechanisms should be in place to either take over the
> operation in the state found at the moment of the failure or to undo whatever
> action was performed before the failure.

I am not disagreeing with you on this. I think this is exactly what my new text captures. 

But I don't believe this is the subject of a new architectural component. 

To a great extent this is an implementation issue. That is, how an ABNO implementation decides to recover/synchronise state between components and instances of components could be achieved in a wide variety of ways. One approach allows "horizontal" interfaces between instances of the same component. Another approach has a centralized owner of state. A further approach enhances interfaces between different component to allow them to resynchronise.

This topic has been the subject of research for as long as I can recall (and I'm old :-) whether in communications software or in databases. I think it would be a perfect topic for a separate document and possibly some healthy research papers in the SDNRG. But I am reluctant to further open the topic in the initial ABNO architecture for fear it will spiral down into the tar pit.

> .- Network elements resiliency: when one network element fails or should be
> rebooted, for instance, the services have to be re-deployed with the same
> properties / characteristics as they were running before the failure. As an
> example, in an SDN environment the forwarding rules should be re-installed in
> the device, so these have to be kept in some place (or should be a way of
> regenerating them for re-installation).

This is certainly true in a transport network, but in that case the NE has probably retained a lot of state.

But in all cases, when an NE is restarted in a way that affects forwarding, end-to-end traffic will have been restored on other paths, and when the node recovers the network may have moved on considerably.

Perhaps "SDN resiliency" would also be a good subject for research and documentation in the SDNRG.

> Maybe this could be addressed in this or in another document. But in my opinion
> it is a relevant topic to provide an operational insight to the ABNO architecture
> (talking from an operator perspective).

Operational insights would be very valuable.
Let's try for a set of documents rather than a single book :-)

Thanks,
Adrian

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 25 Aug 2014 13:35:30 +0000

Hi Adrian,

Thanks for your reply. I don't have any additional comments. Please feel free to edit the text I forwarded in the way you consider more appropriate.

Best regards

Luis

-----Mensaje original-----
De: Adrian Farrel [mailto:[email-masked]]
Enviado el: domingo, 24 de agosto de 2014 19:11
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: 'King, Daniel'; [email-masked]
Asunto: RE: Call for review of draft-farrkingel-pce-abno-architecture

Hi Luis,

Continuing this conversation:

> I think you are saying that, in order to achieve its function, the
> ABNO controller will need a database that maps services to underlying
> network resources. I agree that the ABNO controller would need to keep
> this state information, and that the information would need to be "persistent".
>
> I am wondering whether this database is internal or external to the
> ABNO Controller.

[snip]

> [Luis>>] I think that the most appropriate case would be to consider
> it as a DB external to the ABNO Controller. I see a number of actions
> (implemented by ABNO components or external modules) using this DB:
> .- network planning: the info the DB can be used for planning
> purposes, applying forecast demands to some existing services.
> .- service inventory: the DB can play the role of service inventory
> then complementing some other resource inventory in place.
> .- transport abstraction: this DB keeps the link between the service
> requested and how this service is implemented from the transport point of view.

> > 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.
>
> So I'm a bit confused.
> Having said that the Provisioning Manager may act as an SDN
> controller, what does it mean for "ABNO to interact with an SDN controller"?
> The point, I think of the ABNO architecture is to pull together all of
> the components that may operate and manage a network. Thus the SDN
> controller is within the ABNO architecture not external to it.
>
> architecture or "buzz". It is what it is. SDN is a profile/application
> of ABNO, or SDN is something on its own. This is neither competition
> for SDN nor an attempt to subsume it.
>
> [Luis>>] I think that one of the strengths of ABNO is precisely not to
> be tight to SDN only, or in other words, it facilitates to
> simultaneously work with different kind of networks, or profiles as
> you referred to. But because we are discussing this on the mailing
> list of the SDN RG let me go a bit further, just sharing my thoughts.
> When I mention about a direct interaction of ABNO with an SDN
> Controller, I mean that the Provisioning Manager can interact with an
> SDN controller, as reflected in the modified figures I attached in my
> previous mail. But I agree that this can be considered as part of the
> Provisioning Manager itself, i.e., the Provisioning Manager could use
> a conventional SDN Controller (e.g., Floodlight, Ryu, etc) instead of building the logic itself.
> My only worry here is that considering the SDN Controller as part of
> the Provisioning Manager produce asymmetric scenarios from the control
> plane point of view. Let me explain. With the SDN Controller logic
> being part of the PM, the ABNO would interact with devices without
> control plane capabilities. However, at the same time the PM could
> interact with some other devices, not SDN-based, that incorporate
> control plane capabilities (e.g., GMPLS based control). Maybe this
> different approach could condition the way the workflows are developed, avoiding generalization and technology agnostic approach.

> > 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
> So, I think, consistent with my previous comment, the REST API (such
> as the Floodlight API) would sit between the ABN Controller and the
> Provisioning Manager.
>
> This is also consistent with the Floodlight Controller having the job
> of determining the network path before programming the network
> elements. In other words, the controller (Provisioning Manager) needs
> to consult a component (that may be coded as internal, but which is
> functionally distinct) that computes paths (PCE).
>
> [Luis>>] I see your point. That would reflect the case of the SDN
> Controller working in active mode. However, for an SDN Controller in
> passive mode probably not. Nevertheless this would not prevent of
> using the REST API there, of course.

> [Luis>>] ok. What I would expect would be a common interface between
> the ABNO Controller and the Provisioning Manager, and then a number of
> adaptors or protocols there as southbound interfaces to interact with
> different kind of devices. From the text above I understand that such
> interface could be for instance a REST API (as the one in Floodlight) or PCEP.

> > 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.
>
> That would be interesting. I think I agree that resilience may need
> additional functionality and state synchronisation in some cases. On
> the other hand, in some cases, especially when seamless resiliency is
> not needed, it is enough to switch to another instance and repeat the
> request  (consider issuing a request to a PCE that fails - you would just re-issue the request to a new PCE).
>
> I don't believe that this document has to describe every possible
> interaction between all components, but I will add a sentence to the
> penultimate paragraph of Section 4...
>
> [Luis>>] When you consider the provisioning of a new service probably
> state synchronization it is not an issue. As you mention you can try
> with another instance of a given component and just be sure that the
> running component record the state. There are however more challenging cases:
> .- ABNO components resiliency: the modification or deletion of
> provisioned services has to be performed with certainty about the
> resources associated to any of the services. If this state is not
> properly kept then the operation of modifying or deleting a service
> could impact some other service. Additionally, if a given component
> fails during the process of modification or deletion (or even
> provision), then some mechanisms should be in place to either take
> over the operation in the state found at the moment of the failure or to undo whatever action was performed before the failure.

> .- Network elements resiliency: when one network element fails or
> should be rebooted, for instance, the services have to be re-deployed
> with the same properties / characteristics as they were running before
> the failure. As an example, in an SDN environment the forwarding rules
> should be re-installed in the device, so these have to be kept in some
> place (or should be a way of regenerating them for re-installation).

> Maybe this could be addressed in this or in another document. But in
> my opinion it is a relevant topic to provide an operational insight to
> the ABNO architecture (talking from an operator perspective).

Thanks,
Adrian

---

From: <[email-masked]>
Date: Sun, 31 Aug 2014 07:37:48 +0000

Hi Dan, Hi Adrian,

Sorry for the delay on sending my comments on the draft-farrkingel-pce-abno-architecture-10
I have seen that you have updated the draft and that you have now published version 11.

Please note that IMHO, the below comments apply also to version 11 of this draft:

First of all I would like to mention that the draft is useful for the IETF and that its IETF publication process can start soon.

Comment_1: Please emphasize how the ABNO architecture can be applied in the context of SFC (Service Function Chaining). In other words what is the relation between the IETF SFC WG documents and this document.

Comment_2: The draft is not describing in detail which existing northbound interface solutions can be used in combination with the ABNO architecture. Please emphasize what are the existing IETF activities that can be used/applied for the support of the northbound interface.

Best regards,
Georgios
________________________________________
Van: sdn <[email-masked]> namens [email-masked] <[email-masked]>
Verzonden: vrijdag 1 augustus 2014 09:19
Aan: [email-masked]; [email-masked]
CC: [email-masked]
Onderwerp: Re: [Sdn] Call for review of draft-farrkingel-pce-abno-architecture

Hi Dan,

Best regards,
Georgios

Hi SDN RG'rs,

Thanks,
Dan
_______________________________________________
sdn mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/sdn