Re: [Actn] ACTN progress

윤빈영 <byyun@etri.re.kr> Thu, 15 January 2015 04:51 UTC

Return-Path: <byyun@etri.re.kr>
X-Original-To: actn@ietfa.amsl.com
Delivered-To: actn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F191ACEF6 for <actn@ietfa.amsl.com>; Wed, 14 Jan 2015 20:51:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.51
X-Spam-Level:
X-Spam-Status: No, score=-96.51 tagged_above=-999 required=5 tests=[CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLwnMN8IBwWB for <actn@ietfa.amsl.com>; Wed, 14 Jan 2015 20:51:33 -0800 (PST)
Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F651ACEF0 for <actn@ietf.org>; Wed, 14 Jan 2015 20:51:32 -0800 (PST)
Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 15 Jan 2015 13:51:30 +0900
Received: from SMTP1.etri.info ([169.254.1.130]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Thu, 15 Jan 2015 13:51:24 +0900
From: 윤빈영 <byyun@etri.re.kr>
To: Leeyoung <leeyoung@huawei.com>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: [Actn] ACTN progress
Thread-Index: AQHQMDS88CJXwHZaZUK2ONztVNPfl5zAdU0w
Date: Thu, 15 Jan 2015 04:51:23 +0000
Message-ID: <23C934174FAD8C4EACF66FEFB6AE43391D774143@SMTP1.etri.info>
References: <7AEB3D6833318045B4AE71C2C87E8E1729C70587@dfweml706-chm> <eecc34a2c82e438fb09897d328c03d0a@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C719C6@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C719C6@dfweml706-chm>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.254.173.49]
Content-Type: multipart/alternative; boundary="_000_23C934174FAD8C4EACF66FEFB6AE43391D774143SMTP1etriinfo_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/actn/gR_4uFgJGwWQ4vOX_dIa9L7BXOc>
Subject: Re: [Actn] ACTN progress
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jan 2015 04:51:35 -0000

Hi Young,



I like to catch up with you.

So I like to translate your saying into my words for my clear understanding as follows.



For future ACTN work, we will keep the same architecture consisting of CNC-MDSC-PNC,

and the interfaces between them should be the same as Igor insists.

Each controller has the same functions conceptually,

but some functions may not be used depending on the type of controller(MDSC/PNC).



In order to implement the models(Provisioning, OAM, etc.) required for transport SDN,

ACTN will describe the interface of each controller based on the architecture of CNC-MDSC-PNC.

The interfaces between the controllers may be different practically due to some functions not used.



We can say like the following if those above are true.

Some can implement a super(general) transport SDN controller to support all the functions,

while other can implement specific purposed(targeted) controllers such as PNC and MDSC.

For the former, the CMI is the same as the MPI.

For the latter, the CMI may not be the same as the MPI due to some functions not used.

ACTN will follow the latter for T-SDN implementation incorporating existing control systems like GMPLS and EMS/NMS.



Correct me if there is any misunderstanding.



Thanks,

Bin

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, January 15, 2015 4:12 AM
To: actn@ietf.org
Subject: [Actn] ACTN progress

Hi All,

Just wanted to share some private emails exchanged among a limited interested parties in the past week with a permission with Igor.

In a nutshell, I think we are converging with a common view on ACTN interfaces and architecture. Please check the following email thread. Please comment if you have any question.

Thanks,
Young

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Thursday, January 08, 2015 2:13 PM
To: Leeyoung; Daniele Ceccarelli
Cc: AshwoodsmithPeter
Subject: RE: Recap this morning's call

Hi Young,
You’ve captured all pretty accurately. I nominate you for the ACTN scribe job :=)

Igor

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, January 08, 2015 3:09 PM
To: Igor Bryskin; Daniele Ceccarelli
Cc: AshwoodsmithPeter
Subject: Recap this morning's call

Hi Igor,

Thanks for this morning’s call. I just wanted to recap what was agreed upon. Please feel free to correct if anything needs to be corrected.

We have identified several models to be implemented in ACTN control hierarchy (CNC-MDSC-PNC). Among them are, but not limited to:


1.      Topology Model

2.      Provisioning Model

3.      Service Model

4.      OAM Model

5.      Client Mapping/Policy Model

There could be more to the list. We can identify and add later on if we will.

Now, with these models, different components (i.e., different controller type) will implement whatever relevant models and support its interfaces. For instance, PNC may need not support Client mapping/policy model while CNC may not need to support Provisioning model.

We also agree that MDSC can interface another MDSC or PNCs with transparency. MDSC should not be able to distinguish if it interfaces MDSC or PNCs (i.e., the same interface).

And you also said, CNC interfacing MDSC should be essentially the same interface as MDSC interfacing another MDSC or PNCs.

Let us start from here. Then we can discuss further.

Thanks,
Young