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

["Adrian Farrel" <[e-mail]>]

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.

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

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

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

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

Yeah.

Once again, many thanks.

You forgot...

Section 7, add "Luis Contreras"

Cheers,
Adrian