Re: [Actn] charter 1.4

[Khuzema Pithewan <[e-mail]>]

Hi Young,

Please see inline With tag [KP]

Thanks
Khuzema

From: Leeyoung [mailto:[e-mail]]
Sent: Monday, December 15, 2014 8:31 PM
To: Khuzema Pithewan; Andrew G. Malis
Cc: [e-mail]
Subject: RE: [Actn] charter 1.4

Hi Khuzema,

Here’s my response inline.

Thanks,
Young

From: Khuzema Pithewan [mailto:[e-mail]]
Sent: Friday, December 12, 2014 11:55 AM
To: Leeyoung; Andrew G. Malis
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Actn] charter 1.4

Hi Young,

On protection : There will be multiple things in this area. You did pointed out some of the most important aspects (both of them) of it. ACTN framework should support finer control of protection like

·         Co-ordination of protection among packet/OTN/optical layers

o   This can be automatic governed by rules/policy or user can intervene based on events/alarm triggered

·         Health checks for protection availability for various layers involved in end-2-end circuit

·         Order or priorities, when and which protection kicks on faults. This can either be policy driven or user can intervene depending on changing environment

·         Protection has implication on path computation (diversity/SRLG etc), which would need co-ordination among layers.

·         Protection planning through different layers, as different layers may offer different types of protection like 1+1, 1:1, m:n, shared protection.

·         :
Having this in charter opens up this essential area for investigation/analysis of existing work and its applicability to ACTN

YOUNG>>  Virtual service operation (VSO) is defined in the charter and has been elaborated in the 05 version of the framework document just published. Basically, with the VSO notion, customer’s policy can be enforced dynamically with a feedback loop (with event/alarm trigger). Some policy can be static while others dynamic.


[KP] As far we are to cover these details in some heading, I am fine.

YOUNG>> But the last two bullets seem purely network-oriented. What makes do you think they are unique to ACTN? ACTN architecture can definitely help in coordinating protection level in multi-layer networks. But do you think there are areas TEAS or CCAMP might not be able to provide solutions for multi-layer protection coordination?


[KP] ACTN deals with virtual topology and co-ordination with more than one domain to sketch multi-domain/multi-vendor network into one big network. ACTN will be able to harness work done by other group and fill the gap if there is anything missing from ACTN perspective. Having it in charter enables the work.

Network Efficiency : the draft you pointed out does talk about monitoring of service. My point is geared towards achieving network efficiency by ability to bulk/one-by-one regroom services.  Now there are 2 aspects here :

·         Trigger to initiate re-groom services

o   Can be through service monitoring, as discussed in draft

o   Can be through some policy, i.e. time or fiber capacity based

o   Can be through external trigger

·         APIs which can facilitate orchestration of regrooming.

o   VPI / CVI should be able to export such APIs and info model should support such actions from user

YOUNG>> This is an interesting point. You are basically saying that re-grooming policy should be supported, whether that is time-based, dynamically triggered by service monitoring, etc. What is fiber capacity based policy? What is external trigger?

[KP] yes. A module/component that deals with network efficiency from past trends or user trigger will help in taking care of this function.

Reliability :  I am talking about control plane reliability. Control plane and multi-domain coherency may not be just a matter of policy enforcement. This aspect has to be taken care explicitly by developing mechanism/protocol across controllers.

YOUNG>> The MDSC (Multi-domain Service Controller, which is used to be called VNC) redundancy can be a starting point as it interfaces different controllers. Of course, PNCs and CNCs are also factored in for end-to-end control plane reliability. I believe there are independent server redundant protocols out there. Do you think ACTN protocol should support controller redundancy as part of it?


[KP] Yes to an extent. As general guidance, ACTN framework needs to provide protocol/mechanism/methods which can take care of high-availability of functions it supports, for instance, function offered MDSC to CNC. This means MDSC should be able to connect to multiple CNC (This is an input to framework) and hence also require maintaining state coherency across multiple MDSCs. State coherency requirement may translate into re-using certain existing protocols or may need new ones, if they are not sufficient.

Thanks
Khuzema


From: Leeyoung [mailto:[e-mail]]
Sent: Wednesday, December 10, 2014 5:45 PM
To: Khuzema Pithewan; Andrew G. Malis
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Actn] charter 1.4

Hi Khuzema,

Thanks for brining interesting discussion points.

Please see inline for my comment.

Thanks,
Young


From: Khuzema Pithewan [mailto:[e-mail]]
Sent: Tuesday, December 09, 2014 4:08 PM
To: Andrew G. Malis; Leeyoung
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Actn] charter 1.4

Hi,

Need for OAM co-ordination across domain boundaries leads me to think about

·         need for protection aspect of services from flexibility standpoint for multi-layer network i.e. ability to choose layers for protection in a multi-layer environment for a given end-2-end service.

YOUNG>> Your first point on the ability to choose multi-layer protection, are you referring to CNC’s (customer) policy or the VNC’s (multi-domain coordinator) policy, or both?


-          There is a requirement for a VN survivability from customers. But customer may not be aware of multi-layer aspect of operator’s networks. In such case, the VNC has to determine the proper protection mechanism to meet this customer’s VN survivability requirement.


-          Or you are talking about operator’s ability to coordinate packet/optical protection mechanism from a network control perspective?


Another important aspect of network operation is achieving efficiency in network utilization. This may mean re-grooming of existing services from time to time. May be this aspect is part of service elasticity to an extent (not sure though).

YOUNG>>  If I understand correctly, you are saying we need a way to re-optimize existing connections to achieve a better network utilization. To achieve this, we need a periodic network performance statistics across PNC, VNC and CNC to allow seamless and consistent policy decision. If this is what you are talking about, there is a use-case: please check if this use-case fits what you are referring to: https://datatracker.ietf.org/doc/draft-xu-actn-perf-dynamic-service-control/ (This is in scope of ACTN).

One more point, may not be part of charter. Since ACTN framework will contain multiple components which would work with each other in tandem, the coherency of operation of ACTN framework should be ensured.

YOUNG>>  Are you talking about the need for seamless operation for multi-domain networks from a control plane perspective or data plane perspective? If the latter, that is out of scope of ACTN; if the former, then, we need to consider that aspect. One requirement from an operator is the multi-domain coordinator (VNC) would enforce policies to ensure operational consistency in all domains. If you can give a bit more concrete example of operational coherency, that will be helpful.

To generalize, reliability aspect need to captured in the charter.

Thanks
Khuzema

From: ACTN [mailto:[e-mail]] On Behalf Of Andrew G. Malis
Sent: Tuesday, December 09, 2014 9:31 AM
To: Leeyoung
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Actn] charter 1.4

Young,

Good addition for the LIME WG reference.

With regards to the quoted paragraph, how about:

Virtual service coordination function in ACTN incorporates
customer's service-related knowledge in virtual network operation in order to
seamlessly operate virtual networks while meeting customer's service
requirements. This may require OAM coordination across domain boundaries.

Cheers,
Andy

On Tue, Dec 9, 2014 at 11:32 AM, Leeyoung <[e-mail]<mailto:[e-mail]>> wrote:
Hi Andy,

Very good point you are raising. Actually as for the LIME WG coordination, Carlos (LIME WG’s co-chair) and I have touched base already in Honolulu to ensure there will be a close coordination between LIME and ACTN.

How about, adding another dashed item at the end of this text (in bold and italic)

The ACTN WG will coordinate with the following working groups:

-With the LIME WG on architectural, modeling, and protocol coordination for OAM.

As for your suggestion to include operational OAM coordination across domain boundaries, I agree with you.
Will you be able to suggest specific text perhaps to the quoted paragraph?

Thanks,
Young

From: Andrew G. Malis [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, December 09, 2014 9:32 AM
To: Leeyoung
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Actn] charter 1.4

Young,

This is a very good looking charter. I have one comment on the following paragraph:

Virtual service coordination function in ACTN incorporates
customer's service-related knowledge in virtual network operation in order to
seamlessly operate virtual networks while meeting customer's service
requirements.

Given that ongoing operation (not just (virtual) network or service provisioning) would be in charter, should there be an explicit mention of operational OAM coordination across domain boundaries, and also architectural, modeling, and protocol coordination with the LIME WG?

Cheers,
Andy