Subject: Re: [Actn] Additional requirements about protection switching service

From: Leeyoung <[email-masked]>
Date: Mon, 1 Dec 2014 16:10:45 +0000

From: 윤빈영 [mailto:[email-masked]]
Sent: Sunday, November 30, 2014 8:24 PM
To: [email-masked]; [email-masked]; Leeyoung
Cc: [email-masked]
Subject: Additional requirements about protection switching service

Hi all,

I think that protection-switching is one of the most important services in transport networks.
So, I suggest that it should be included in the framework.
I add three protocols related to the service: protection-switching request, response, and failure event.
Please, see attached the two files.

Specially, I want Daniele and Young to check the violet colored line modified by me in <.ppt file>.
The line indicates a control channel connecting between PNC3 and EP3's node.
It is used to configure the head-end and tail-end for protection-switching.
It will be great if you give me some clear description about  the solid lines between PNC and network infra(each domain).
(Some nodes are not connected to PNCs)

Sincerely yours,

---

From: Leeyoung <[email-masked]>
Date: Mon, 1 Dec 2014 16:31:27 +0000

Hi Bin,

VN survivability is expressed by operator’s use cases such as KDDI and others and I believe this is a part of scope of the CNC-VNC interface that includes protocol work as well as YANG data model.

The subsequent actions necessary for the interface between the VNC and PNCs might be worthwhile to evaluate within this effort. The actual protocol work on the VNC-PNC interface to support VN survivability is also a new work, but whether it is pursued in ACTN or other WGs is yet to be determined.

In regard to your question on the solid line between PNC and the nodes (and why some nodes are not connected to the VNC), the picture is not meant to show the accuracy of the control channel connectivity per se.

Best regards,
Young

Hi all,

Sincerely yours,

---

From: 윤빈영 <[email-masked]>
Date: Tue, 2 Dec 2014 09:20:16 +0000

Hi Young,

I like to share my opinion as one way for future ACTN works.

One big different thing of ACTN from other WGs in IETF, I think, is that it separates a service provider(VNC) as an independent operator from a network provider(PNC). Let me correct it if other WGs highlight this concept. If we take ourselves into an owner of the VNC, we will try to do our best of providing various services for customers based on our assigned resources for more earning by reducing service dependency from the PNC. By more focusing on the business model(how to get more profit by the VNC), I think that we can generate some creative ideas. So I expect that ACTN will play a good role in leading SDN, if we elaborate the current proposed work with this business aspect. It will also be works to be distinguished from other WGs.

For an example, the VNC will do just a simple mapping of a CNC’s protection request to a PNC’s protection request if an operator of the VNC is the same as operators of PNCs(not interested in business). Otherwise, the VNC operator may try to provide the service for themselves through VNC-based restoration service, which can increase their profit by cutting the cost to the PNC’s operators for the service. It can require some functional requirements and new protocols.

This is the way(seeing it from business point of view) by which I like to make a contribution if the BoF passes.

Sincerely yours,

From: Leeyoung [mailto:[email-masked]]
Sent: Tuesday, December 02, 2014 1:31 AM
Subject: Re: [Actn] Additional requirements about protection switching service

Hi Bin,

Best regards,
Young

Hi all,

Sincerely yours,

---

From: 이광국(통합전달망팀) <[email-masked]>
Date: Thu, 4 Dec 2014 02:41:52 +0000

Dear Dr. Yoon,

As Young mentioned, VN survivability might be handled by the interface between CNC and VNC according to the current ACTN architecture. Also, the term “protection” for VNs might not be adequate because the term generally is used for sub-50ms recovery in transport networks without any introduction of control planes.

Except the term “protection,” I also support that the VN survivability is very important and this is one of the important roles of ACTN. The ACTN can provide the survivability to meet user requirements through the underlying PNC control because most of transport networks have their own protection schemes in their data planes. The control of survivability for VNs depends on the information and data model which will be defined by ACTN. The strong point of ACTN in terms of the VN survivability is that border areas between multi-domains can be also touched by VNC to control whole area. So, from end-to-end perspectives, VN survivability could be guaranteed and help operator concerns about the border areas.

Best regards,
Kwang-koog Lee

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Tuesday, December 02, 2014 1:31 AM
To: 윤빈영; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Actn] Additional requirements about protection switching service

Hi Bin,

Best regards,
Young

From: 윤빈영 [mailto:[email-masked]]
Sent: Sunday, November 30, 2014 8:24 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Leeyoung
Cc: [email-masked]<mailto:[email-masked]>
Subject: Additional requirements about protection switching service

Hi all,

Sincerely yours,

이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately.

---

From: Leeyoung <[email-masked]>
Date: Thu, 4 Dec 2014 17:24:22 +0000

Dear Kwangkoog,

Thanks for sharing your thought. I fully agree with your view. VN survivability is a top-down client initiated policy that would affect their applications and as such needs to be carefully orchestrated/coordinated across all domains. I also believe, PNC’s profile on protection capability/policy needs to be known to the VNC so that the VNC would be able to map/implement the VN survivability request from the CNC into a feasible solution across multi-domain.

As for your “border areas” between multi-domains, I think I need to understand this a bit more clearly so that the requirement can be captured correctly.
Let us consider the following figure (as an illustration purpose).

Let’s focus on PNC 1 and PNC 2. I would assume that PNC1 and PNC2 will abstract its topology with a minimal information about its topology. I would say it will include at a minimum, the following inter-domain links (with Domain 2) from PNC1 will be abstracted to the VNC.

-          B.1 is an interface to Domain 2 (in Domain 2, it is D.1)

-          B.2 is an interface to Domain 2’s node E (in Domain2, it is E.1)

-          C.1 is an interface to Domain 2’s node E (in Domain 2, it is E.2)

Likewise from Domain 2, D.1 and E.1 and E.2 will be relevant interfaces to Domain 1.

With this abstraction level on the border nodes/links from PNCs 1 and 2, the VNC will be able to infer all the inter-domain resource/connectivity between Domains 1 and 2. Likewise, other inter-domain border nodes/links can be abstracted.

Do you see any other particular requirements on the abstraction of inter-domain nodes/links that are missing in this illustration?

Thanks,
Young
From: 이광국(통합전달망팀) [mailto:[email-masked]]
Sent: Wednesday, December 03, 2014 8:42 PM
To: Leeyoung; 윤빈영; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Actn] Additional requirements about protection switching service

Dear Dr. Yoon,

Best regards,
Kwang-koog Lee

Hi Bin,

Best regards,
Young

Hi all,

Sincerely yours,