From nobody Tue Jul 1 07:19:34 2014 Return-Path: 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 E14481A0339 for ; Tue, 1 Jul 2014 07:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 tEh1Zbgtf1rl for ; Tue, 1 Jul 2014 07:19:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB211B27EC for ; Tue, 1 Jul 2014 07:19:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGR41192; Tue, 01 Jul 2014 14:19:07 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Jul 2014 15:19:06 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml701-chm.china.huawei.com ([169.254.1.95]) with mapi id 14.03.0158.001; Tue, 1 Jul 2014 07:19:04 -0700 From: Leeyoung To: =?ks_c_5601-1987?B?vcXBvsCxKFNoaW4gSm9uZ3lvb24p?= , "actn@ietf.org" Thread-Topic: New Version Notification for draft-shin-actn-mvno-multi-domain-00.txt Thread-Index: Ac+U5VBxnfJ1mnoaSFuo97+Un3NBBQADwNZAABBiqGA= Date: Tue, 1 Jul 2014 14:19:03 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BFE74F@dfweml706-chm.china.huawei.com> References: <20140701043115.2780.66189.idtracker@ietfa.amsl.com> <490BF875279F7549BEBA47ADC8F369DB755C91A65E@SKT-MBXA.SKT.AD> In-Reply-To: <490BF875279F7549BEBA47ADC8F369DB755C91A65E@SKT-MBXA.SKT.AD> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.217] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/drEfLJeq84l2dlJBo-Ii7VYidlc Subject: Re: [Actn] New Version Notification for draft-shin-actn-mvno-multi-domain-00.txt X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 14:19:27 -0000 SGkgSm9uZ3lvb24sDQoNClRoYW5rcyBmb3IgdXBsb2FkaW5nIHRoaXMgdXNlLWNhc2UuIEkgaGF2 ZSBhIGZldyBxdWVzdGlvbnMgb24gdGhpcyB1c2UtY2FzZToNCg0KMS4gSW4gdGhlIGludHJvZHVj dGlvbiB0ZXh0LCAiTW9yZW92ZXIsIHRoZSB3aWRlc3ByZWFkIGRlcGxveW1lbnQgb2YgbWlkZGxl IGJveGVzIChlLmcuIGVkZ2UgY2FjaGUsIGZpcmV3YWxsIGV0Yy4pIGluc2lkZSB0aGUgREMgZWRn ZSBhbmQgY29yZSBlZGdlIHdpbGwgYmUgYWNoaWV2ZWQgZHVlIHRvIHRpZ2h0bHktY291cGxlZCBp bnRlcmFjdGlvbiB3aXRoIGhpZ2hlciBsYXllciBwcm90b2NvbHMgYW5kIHRyYW5zcG9ydCBjb250 cm9sIHByb3RvY29scyAoaS5lLiBHTVBMUywgUlNWUCwgZXRjLikiDQoNCi0tIERvIHRoZSBoaWdo ZXIgbGF5ZXIgcHJvdG9jb2xzIG1lYW4gImNhbGwtY29udHJvbCIgc3VjaCBhcyAzR1BQPyBJZiBz bywgYXJlIHlvdSB0cnlpbmcgdG8gc2F5LCB0aGVyZSBzaG91bGQgYWxzbyBiZSBhIGNvb3JkaW5h dGlvbiBiZXR3ZWVuIGNhbGwgY29udHJvbCBhbmQgY29ubmVjdGl2aXR5IGNvbnRyb2w/IA0KDQoy LiBJbiBTZWN0aW9uIDIsIHlvdSBkaXNjdXNzZWQgMy4gVHJhbnNwb3J0IGZyb20gTW9iaWxlIEVk Z2UgREMgdG8gSW50ZXJuZXQgQ29yZSBOZXR3b3JrDQoNCiAgICJGcm9tIE1vYmlsZSBFZGdlIERD IGRvbWFpbiB0byBJbnRlcm5ldCBDb3JlIE5ldHdvcmssIHRoZXJlIGlzIGFsc28NCiAgIGNvcmUg dHJhbnNwb3J0IG5ldHdvcmsgdGhhdCBwcm92aWRlcyBjb25uZWN0aXZpdHkgYmV0d2VlbiBlZGdl cyB0bw0KICAgSW50ZXJuZXQgY29yZSBmb3IgTG9jYWwgdHJhZmZpYyBicmVha291dCAoZS5nLiBM SVBBIGFuZCBTSVBUTykuIiANCg0KLS0tIENvdWxkIHlvdSBlbGFib3JhdGUgd2hhdCBsb2NhbCB0 cmFmZmljIGJyZWFrb3V0IChlLmcuLCBMSVBBIGFuZCBTSVBUTykgb3BlcmF0aW9uIHR5cGljYWxs eSBpbnZvbHZlPyAoUGVyaGFwcywgdGhpcyBpcyBkdWUgdG8gbXkgbGFjayBvZiBrbm93bGVkZ2Ug aW4gbW9iaWxlIG9wZXJhdGlvbnMsIGJ1dCBJIHRoaW5rIGl0IHdpbGwgYWxzbyBoZWxwIHRoZSBy ZWFkZXJzIG9mIHRoaXMgdXNlLWNhc2UgYXMgbW9zdCBvZiB1cyBhcmUgdHJhbnNwb3J0IGNvbnRy b2wgZm9sa3MpLiANCg0KUmVnYXJkcywNCllvdW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBBQ1ROIFttYWlsdG86YWN0bi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgPz8/KFNoaW4gSm9uZ3lvb24pDQpTZW50OiBUdWVzZGF5LCBKdWx5IDAxLCAyMDE0IDE6NTEg QU0NClRvOiBhY3RuQGlldGYub3JnDQpTdWJqZWN0OiBbQWN0bl0gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtc2hpbi1hY3RuLW12bm8tbXVsdGktZG9tYWluLTAwLnR4dA0K DQpEZWFyIEFsbCwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQtIGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hpbi1hY3RuLW12bm8tbXVsdGktZG9tYWluLw0K dGhhdCBkZXNjcmliZXMgYW4gQUNUTiBVc2UtY2FzZSBmb3IgTW9iaWxlIFZpcnR1YWwgTmV0d29y ayBPcGVyYXRpb24gZm9yIE11bHRpcGxlIERvbWFpbnMgaW4gYSBTaW5nbGUgT3BlcmF0b3IgTmV0 d29yay4gV2Ugd291bGQgYXBwcmVjaWF0ZSB5b3VyIGZlZWRiYWNrIGFuZCBhbnkgY29tbWVudHMg b24gaXQuDQoNClRoYW5rcywNCkpvbmd5b29uIFNoaW4NCg0KU0sgdGVsZWNvbQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDEsIDIw MTQgMTozMSBQTQ0KVG86IA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1zaGluLWFjdG4tbXZuby1tdWx0aS1kb21haW4tMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXNoaW4tYWN0bi1tdm5vLW11bHRpLWRvbWFpbi0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWW91bmcgTGVlIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXNoaW4tYWN0bi1tdm5vLW11bHRpLWRv bWFpbg0KUmV2aXNpb246CTAwDQpUaXRsZToJCUFDVE4gVXNlLWNhc2UgZm9yIE1vYmlsZSBWaXJ0 dWFsIE5ldHdvcmsgT3BlcmF0aW9uIGZvciBNdWx0aXBsZSBEb21haW5zIGluIGEgU2luZ2xlIE9w ZXJhdG9yIE5ldHdvcmsNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDYtMzANCkdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTkNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zaGluLWFjdG4tbXZuby1tdWx0aS1kb21haW4t MDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtc2hpbi1hY3RuLW12bm8tbXVsdGktZG9tYWluLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNoaW4tYWN0bi1tdm5vLW11bHRpLWRvbWFpbi0w MA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIHVzZS1jYXNlIHRo YXQgYWRkcmVzc2VzIHRoZSBuZWVkIGZvcg0KICAgdmlydHVhbCBuZXR3b3JrIG9wZXJhdGlvbiBm b3IgbW9iaWxlIG9wZXJhdG9ycywgd2hpY2ggaXMgZmFjaWxpdGF0ZWQNCiAgIGJ5IHRoZSBhcHBs aWNhdGlvbiBvZiBuZXR3b3JrIGFic3RyYWN0aW9uLiBUaGVzZSBhYnN0cmFjdGlvbnMgc2hhbGwN CiAgIGNyZWF0ZSBhIHZpcnR1YWwgbmV0d29yayBvcGVyYXRpb24gZW52aXJvbm1lbnQgc3VwcG9y dGluZyBtb2JpbGUNCiAgIG9wZXJhdG9ycyBpbiB2aWV3aW5nLCBtYW5hZ2luZyBhbmQgb3BlcmF0 aW5nIG11bHRpLWRvbWFpbnMgb2YgbWFueQ0KICAgZGltZW5zaW9ucyAoZS5nLiwgcmFkaW8gYWNj ZXNzLCBiYWNraGF1bCB0cmFuc3BvcnQsIG1vYmlsZSBEQyBlZGdlLA0KICAgbW9iaWxlIERDIGNv cmUsIHBhY2tldC9vcHRpY2FsIHRyYW5zcG9ydCBmb3IgREMgaW50ZXJjb25uZWN0LCBldGMuKQ0K ICAgYXMgYSBzaW5nbGUgdmlydHVhbGl6ZWQgbmV0d29yay4NCg0KICAgVGhpcyB1c2UtY2FzZSBj b25zaWRlcnMgdGhlIGFwcGxpY2F0aW9uIG9mIHRoZXNlIGFic3RyYWN0aW9ucyBhbmQNCiAgIHRo ZSBuZWVkIGZvciB0aGUgYXNzb2NpYXRlZCBvcGVyYXRpb25hbCBtZWNoYW5pc21zIHdpdGhpbiB0 aGUNCiAgIG5ldHdvcmsgb2YgYSBzaW5nbGUgb3BlcmF0b3IuDQoNCg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KQUNUTiBtYWlsaW5nIGxpc3QNCkFDVE5AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWN0bg0K From nobody Mon Jul 7 11:22:16 2014 Return-Path: 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 D46EA1A03C0 for ; Mon, 7 Jul 2014 11:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 I_elRpFWt3Z9 for ; Mon, 7 Jul 2014 11:22:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933ED1A02D5 for ; Mon, 7 Jul 2014 11:22:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS45803; Mon, 07 Jul 2014 18:22:10 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 19:22:09 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 11:22:00 -0700 From: Leeyoung To: "actn@ietf.org" Thread-Topic: Toronto BoF Thread-Index: Ac+aECI368kU6iMNTY+GdEjjqRKuSA== Date: Mon, 7 Jul 2014 18:21:59 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BFFD33@dfweml706-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.74] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BFFD33dfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/rh_BrWBG6ukinAHRNtjbpIb_nRo Cc: Young Lee , Daniel King Subject: [Actn] Toronto BoF X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 18:22:15 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729BFFD33dfweml706chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is to inform you that an ACTN Non-WG forming BoF will take place in To= ronto IETF as follows: Time: 13:00-15:00 Date: July 24 (Thursday) Location: Tudor 7/8. Please let us know by the end of this week if you'd like to have a presenta= tion slot. Best Regards, Dan & Young --_000_7AEB3D6833318045B4AE71C2C87E8E1729BFFD33dfweml706chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This is to inform you that an ACTN Non-WG forming Bo= F will take place in Toronto IETF as follows:

 

Time: 13:00-15:00

Date: July 24 (Thursday)

Location: Tudor 7/8.

 

Please let us know by the end of this week if you= 217;d like to have a presentation slot.

 

Best Regards,

Dan & Young

 

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BFFD33dfweml706chmchi_-- From nobody Wed Jul 9 23:07:14 2014 Return-Path: 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 394831B2797 for ; Wed, 9 Jul 2014 23:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.171 X-Spam-Level: *** X-Spam-Status: No, score=3.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 dvwAoPk2fi04 for ; Wed, 9 Jul 2014 23:06:59 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id E46811B2795 for ; Wed, 9 Jul 2014 23:06:58 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea53be2d7a0e1-fa0e1; Thu, 10 Jul 2014 14:06:50 +0800 (CST) X-RM-TRANSID: 2eea53be2d7a0e1-fa0e1 Received: from chengweiqiang (unknown[10.2.52.150]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee353be2d78109-50c24; Thu, 10 Jul 2014 14:06:50 +0800 (CST) X-RM-TRANSID: 2ee353be2d78109-50c24 From: =?gb2312?B?s8zOsMe/?= To: Date: Thu, 10 Jul 2014 14:06:52 +0800 Message-ID: <00d401cf9c05$25b76820$71263860$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D5_01CF9C48.33DAA820" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+cBST5/jaLTmqDT6CUQZY2K7osMw== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/actn/TWl6THGA10tOm-n89bCy2k_ETYw Cc: 'xuyunbin' , 'zhangguoying' Subject: [Actn] ACTN use-case in MPLS-TP based packet transport networks X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 06:07:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D5_01CF9C48.33DAA820 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi There, We prepared a draft about ACTN use-case in MPLS-TP based packet transport networks. Due to the process issues within company, we missed the IETF draft upload deadline. Here we would like to post it in the mail list for review. It is highly appreciated if you can comment it. Best Regards, Weiqiang Cheng =============================Draft beginning=============================== Network Working Group W. Cheng Internet Draft China mobile Intended status: Informational Expires: January2015 Yunbin Xu CATR Guoying Zhang CATR July 10, 2014 ACTN Use-cases for Packet Transport Networks in Mobile Backhaul Networks draft-cheng-actn-ptn-requirements-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 10, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info)in effect on the date of Cheng, et al. Expires January 10,2015 [Page 1] Internet-Draft PTN requirements in ACTN architecture July 2014 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes the key requirements for ACTN in carrier's transport networks, which mainly focus on the Packet Transport Networks. Table of Contents 1. Introduction................................................3 2. ACTN Requirement for Packet Transport Networks..............3 2.1. End-to-End Enterprise Services Provisioning.................3 2.2. Multi-layer coordination Requirement in L2/L3 Packet Transport Networks..........................................................4 2.3. Optimizing the network resources utilization................4 3. Virtual Networks Operations for Packet Transport Networks...5 4. Security Considerations.....................................5 5. IANA Considerations.........................................6 6. References..................................................6 6.1. Informative References......................................6 Cheng, et al. Expires January 10,2015 [Page 2] Internet-Draft PTN requirements in ACTN architecture July 2014 1. Introduction MPLS-TP based packet transport network (PTN) has been widely used as mobile backhaul and enterprise customer private line/LAN solutions in many carrier's networks. The Packet Transport Networks work in different layers from L2 to L3 and in different areas such as access, metro and backbone networks. In the application scenarios, the most important requirements for operators are to solve the interoperability problems between multi-domain/multi-layer networks, realize the fast service provisioning, and improve the network operation efficiency. The PTN operators may use ACTN to improve efficiency of provision and operation, optimize the resources utilization, and promote the customer's experiences. This draft mainly discusses the key requirements for ACTN in carrier's Packet Transport Networks. 2. ACTN Requirement for Packet Transport Networks 2.1. End-to-End Enterprise Services Provisioning The enterprise customer services are sensitive to the network quality, have strict time-limit requirement for service establishment. Faster end-to-end service provisioning may make the operators win the competition. The operators had built a large scale of packet transport networks and divided them into different areas such as access, metro and backbone networks, each area has their own management systems. Currently in most application scenarios, PTN networks are using static provisioning with centralized Network management Systems (NMS). However, they are hard to meet the requirements of current enterprise services for fast provisioning and efficient operation. The ACTN architecture [ACTN-FWK] should be considered to coordinate with traditional the networks management systems, so as to realize the end-to-end service provision. | End-to-End Connection | |<-------------------------------------------------------->| | | +--------+ +-------+ +-------+ +-------+ +-------+ | Access | | Metro | | Core | | Metro | | Access| Cheng, et al. Expires January 10,2015 [Page 3] Internet-Draft PTN requirements in ACTN architecture July 2014 +--+ | PTN | | PTN | | PTN | | PTN | | PTN | +--+ |CE|==|(Vender |==|(Vender|==|(Vender|==|(Vender|==|(Vender|==|CE| +--+ | A) | | B) | | C) | | D) | | E) | +--+ +--------+ +-------+ +-------+ +-------+ +-------+ Figure 1 End-to-End Connection in Mobile Backhaul Networks 2.2. Multi-layer coordination Requirement in L2/L3 Packet Transport Networks LTE backhauling requires the PTN to realize L3 network function. This function requires the management systems operate in different layers of networks, and leads to separate and fragmented network configuration. Further, the L2 PTN and L3 PTN networks may be provided by different venders, and make the end-to-end provisioning much more complex. In the ACTN architecture, new functions such as topology detection and virtualization, auto-routing calculation are introduced. With these functions, operator can improve the user experiences and lower the OPEX. On the other hand, operators want to obtain the flow information and realize the load balancing within L3 PTN networks, | End-to-End Connection | |<------------------------------->| | | +----------+ +----------+ +--------+ | | | | +--------+ | Radio | | Layer 2 | | Layer 3 | | Radio | | Access |===| PTN |===| PTN |===| Core | |Networks| | Networks | | Networks | |Networks| +--------+ |(Vender A)| |(Vender B)| +--------+ | | | | +----------+ +----------+ Figure 2 End-to-End Connection for L2&L3 PTN Networks 2.3. Optimizing the network resources utilization The packet transport networks can support various performances monitoring matrix, such as traffic flow statistics, packet delay, delay variation, throughput and packet-loss rate, etc. All these performance parameters can support the enterprise customers SLA requirements. Through the performance monitoring, the PTN can Cheng, et al. Expires January 10,2015 [Page 4] Internet-Draft PTN requirements in ACTN architecture July 2014 realize the service SLA optimization and network traffic optimization. See [ACTN-PERF] for related discussion. 3. Virtual Networks Operations for Packet Transport Networks Figure 3 shows an example of virtual network operations for packet transport networks. In order to realize end-to-end service provision, the ACTN architecture [ACTN-FWK] should consider coordination with traditional network management systems. By the network virtualization and abstraction, the traditional networks can be considered as a virtual network for VNC service provider, which can be realized by network management systems providing an abstract agent for VNC, or the VNC providing traditional interface for NMS. +-----------------------------------------+ | VNC Service Provider | +-----------------------------------------+ / | \ / | \ / | \ / +-----------------------------+ \ / | NMS Abstract Agent | \ +-------+ +-----------------------------+ +-------+ |Access | +-----------------------------+ |Access | |Control| | Network Management Systems | |Control| +-------+ +-----------------------------+ +-------+ | | | | | | | | | | | | | | | +-------+ +-------+ +-------+ +-------+ +-------+ | Access| | Metro | | Core | | Metro | | Access| +--+ | PTN | | PTN | | PTN | | PTN | | PTN | +--+ |CE|==|(Vender|==|(Vender|==|(Vender|==|(Vender|==|(Vender|==|CE| +--+ | A) | | B) | | C) | | D) | | E) | +--+ +-------+ +-------+ +-------+ +-------+ +-------+ Figure 3 End-to-End Connection in Mobile Backhaul Networks 4. Security Considerations This document raises no new security issues. Cheng, et al. Expires January 10,2015 [Page 5] Internet-Draft PTN requirements in ACTN architecture July 2014 5. IANA Considerations No new IANA considerations are raised by this document. 6. References 6.1. Informative References [ACTN-FWK] Daniele C., Luyuan Fang, Yong Lee and Diego Lopez, "Framework for Abstraction and Control of Transport Networks", draft-ceccarelli-actn-framework-02. [ACTN-PERF] Yunbin Xu, Weiqiang Cheng, Guoying Zhang and Haomian Zheng, "Use Cases and Requirements of Dynamic Service Control based on Performance Monitoring in ACTN Architecture", draft-xu-actn-perf-dynamic-service-control- 01. Authors's Address Weiqiang Cheng China Mobile Communication Company No.32 Xuanwumen West Street, Xicheng District, Beijing, China Email:chengweiqiang@chinamobile.com Yunbin Xu China Academy of Telecom Research NO.52 Huayuan Beilu, Haidian District, Beijing, China Email: xuyunbin@catr.cn Guoying Zhang China Academy of Telecom Research NO.52 Huayuan Beilu, Haidian District, Beijing, China Email: zhangguoying@catr.cn Cheng, et al. Expires January 10,2015 [Page 6] =============================Draft end=============================== ------=_NextPart_000_00D5_01CF9C48.33DAA820 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi There,

We prepared a draft about ACTN use-case in MPLS-TP based packet = transport networks.  Due to the process issues within company, we = missed the IETF draft upload deadline. Here we would like to post it in = the mail list for review. It is highly appreciated if you can comment = it.

 

Best = Regards,
Weiqiang Cheng

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3DDraft = beginning=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Network Working = Group           &n= bsp;           &nb= sp;           &nbs= p;        W. = Cheng

Internet = Draft           &n= bsp;           &nb= sp;          =             &= nbsp;    China mobile

Intended status: = Informational

Expires: January2015

          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      Yunbin Xu

          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           = CATR

 

          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  Guoying Zhang

          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           = CATR

 

          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  July 10, 2014

 

 

       ACTN Use-cases for = Packet Transport Networks in Mobile Backhaul

          =             &= nbsp;            = Networks

          =          = draft-cheng-actn-ptn-requirements-00.txt

 

 

Status of this = Memo

 

   This Internet-Draft is submitted in full = conformance with the

   provisions of BCP 78 and BCP = 79.

   Internet-Drafts are working documents of the = Internet Engineering

   Task Force (IETF), its areas, and its working = groups. Note that

   other groups may also distribute working = documents as Internet-

   Drafts.

 

   Internet-Drafts are = draft documents valid for a maximum of six

   months and may be = updated, replaced, or obsoleted by other = documents

   at any time. It is inappropriate to use = Internet-Drafts as

   reference material or to cite them other than = as "work in progress."

 

   The list of current = Internet-Drafts can be accessed at

   = http://www.ietf.org/ietf/1id-abstracts.txt

 

   The list of = Internet-Draft Shadow Directories can be accessed = at

   = http://www.ietf.org/shadow.html

 

   This Internet-Draft = will expire on January 10, 2015.

 

Copyright = Notice

 

   Copyright (c) 2014 IETF Trust and the persons = identified as the

   document authors. All rights = reserved.

 

   This document is subject to BCP 78 and the = IETF Trust's Legal

   Provisions Relating to IETF = Documents

   (http://trustee.ietf.org/license-info)in = effect on the date of

 

 

Cheng, et = al.           Expires = January = 10,2015           =         [Page = 1]


Internet-Draft      PTN = requirements in ACTN architecture      July = 2014

   publication of this document. Please review = these documents

   carefully, as they describe your rights and = restrictions with

   respect to this document. Code Components = extracted from this

   document must include Simplified BSD License = text as described in

   Section 4.e of the Trust Legal Provisions and = are provided without

   warranty as described in the Simplified BSD = License.

 

   This document is subject to BCP 78 and the = IETF Trust's Legal

   Provisions Relating to IETF = Documents

   (http://trustee.ietf.org/license-info) in = effect on the date of

   publication of this document. Please review = these documents

   carefully, as they describe your rights and = restrictions with

   respect to this = document.

 

Abstract

 

   This document describes the key requirements = for ACTN in carrier's

   transport networks, which mainly focus on the = Packet Transport

   Networks.

 

Table of = Contents

 

 

   1.    = Introduction................................................3<= /span>

   = 2.    ACTN Requirement for Packet Transport = Networks..............3

    2.1. End-to-End Enterprise Services = Provisioning.................3

    2.2. Multi-layer = coordination Requirement in L2/L3 Packet = Transport

   = Networks..........................................................4<= /o:p>

    2.3. Optimizing the network resources = utilization................4

   3.    = Virtual Networks Operations for Packet Transport = Networks...5

   4.    Security = Considerations.....................................5

   = 5.    IANA = Considerations.........................................6

   = 6.    = References..................................................6<= /span>

   6.1. = Informative = References......................................6

 

 

 

 

Cheng, et = al.          Expires = January = 10,2015           =       [Page 2]


Internet-Draft        = PTN requirements in ACTN architecture     July = 2014

 

 

1. Introduction

 

 

   MPLS-TP based packet = transport network (PTN) has been widely used as

   mobile backhaul and = enterprise customer private line/LAN solutions

   in many carrier's = networks. The Packet Transport Networks work in

   different layers from = L2 to L3 and in different areas such as access,

   metro and backbone = networks. In the application scenarios, the most

   important requirements = for operators are to solve the

   interoperability = problems between multi-domain/multi-layer = networks,

   realize the fast service provisioning, and = improve the network

   operation efficiency.

 

   The PTN operators may = use ACTN to improve efficiency of provision

   and operation, = optimize the resources utilization, and promote = the

   customer's experiences. This draft mainly = discusses the key

   requirements for ACTN in carrier's Packet = Transport Networks.

 

2. ACTN Requirement for Packet Transport = Networks

 

2.1.   End-to-End Enterprise Services = Provisioning

 

   The enterprise customer services are sensitive = to the network

   quality, have strict time-limit requirement = for service

   establishment. Faster end-to-end service = provisioning may make the

   operators win the = competition.

 

   The operators had built a large scale of = packet transport networks

   and divided them into = different areas such as access, metro and

   backbone networks, = each area has their own management systems.

   Currently in most = application scenarios, PTN networks are using

   static provisioning = with centralized Network management Systems

   (NMS). However, they = are hard to meet the requirements of current

   enterprise services = for fast provisioning and efficient operation.

 

   The ACTN architecture = [ACTN-FWK] should be considered to coordinate

   with traditional the = networks management systems, so as to realize

   the end-to-end service = provision.

 

 

      = |            =      End-to-End = Connection          &nb= sp;         = |

      = |<-------------------------------------------------------->|

      = |            =             &= nbsp;           &n= bsp;   =             &= nbsp;     |

         = +--------+  +-------+  +-------+  +-------+  = +-------+

         | Access = |  | Metro |  | Core  |  | Metro |  | = Access|

 

 

 

Cheng, et = al.            = Expires January = 10,2015           =       [Page 3]


Internet-Draft      PTN = requirements in ACTN architecture      July = 2014

   +--+  | PTN    |  | = PTN   |  | PTN   |  | PTN   = |  | PTN   |  +--+

   |CE|=3D=3D|(Vender = |=3D=3D|(Vender|=3D=3D|(Vender|=3D=3D|(Vender|=3D=3D|(Vender|=3D=3D|CE|

   = +--+  |    A)  |  |   B)  = |  |   C)  |  |    D) |  = |    E) |  +--+

   =       +--------+  +-------+  = +-------+  +-------+  +-------+

 

         Figure 1 = End-to-End Connection in Mobile Backhaul = Networks

 

2.2. Multi-layer coordination Requirement in L2/L3 Packet = Transport

    Networks

 

   LTE backhauling = requires the PTN to realize L3 network function.

   This function requires = the management systems operate in different

   layers of networks, = and leads to separate and fragmented network

   configuration. = Further, the L2 PTN and L3 PTN networks may be

   provided by different = venders, and make the end-to-end provisioning

   much more complex. In = the ACTN architecture, new functions such as

   topology detection and = virtualization, auto-routing calculation are

   introduced. With these = functions, operator can improve the user

   experiences and lower = the OPEX.

 

   On the other hand, operators want to obtain = the flow information and

   realize the load balancing within L3 PTN = networks,

 

 

          =          = |       End-to-End = Connection     |

          =          = |<------------------------------->|

          =          = |            =             &= nbsp;        = |

          =              = +----------+   +----------+

          = +--------+   = |          |   = |          |   = +--------+

          | = Radio  |   | Layer 2  |   | Layer 3  = |   | Radio  |

          | = Access |=3D=3D=3D|   PTN    = |=3D=3D=3D|   PTN    |=3D=3D=3D| = Core   |

          = |Networks|   | Networks |   | Networks |   = |Networks|

          = +--------+   |(Vender A)|   |(Vender B)|   = +--------+

          =              = |          |   = |          = |

          =              = +----------+   +----------+

 

          =   Figure 2 End-to-End Connection for L2&L3 PTN = Networks

 

2.3.   Optimizing the network resources = utilization

 

   The packet transport networks can support = various performances

   monitoring matrix, such as traffic flow = statistics, packet delay,

   delay variation, = throughput and packet-loss rate, etc. All these

   performance parameters = can support the enterprise customers SLA

   requirements. Through = the performance monitoring, the PTN can

 

 

 

Cheng, et = al.           Expires = January = 10,2015           =         [Page = 4]


Internet-Draft      PTN = requirements in ACTN = architecture         July = 2014

   realize the service SLA optimization and = network traffic

   optimization. See [ACTN-PERF] for related = discussion.

 

3. Virtual Networks Operations for Packet Transport = Networks

 

   Figure 3 shows an example of virtual network = operations for packet

   transport networks. In order to realize = end-to-end service provision,

   the ACTN architecture = [ACTN-FWK] should consider coordination with

   traditional network = management systems. By the network

   virtualization and = abstraction, the traditional networks can be

   considered as a = virtual network for VNC service provider, which = can

   be realized by network management systems = providing an abstract

   agent for VNC, or the VNC providing = traditional interface for NMS.

 

 

          =    = +-----------------------------------------+

          =    = |            = VNC Service Provider        = |

          =    = +-----------------------------------------+

          =         = /            =     = |            =    \

          =        = /            =      = |            =     \

          =       = /            =       = |            =      \

          =      /   = +-----------------------------+    = \

          =     /    = |       NMS Abstract = Agent    |     = \

         +-------+ = +-----------------------------+ +-------+

         |Access | = +-----------------------------+ |Access |

=         |Control| | Network = Management Systems  | |Control|

         +-------+ = +-----------------------------+ +-------+

          =     |         = |          = |          = |          = |

          =     |         = |          = |          = |          = |

          =     |  =        |     =      = |          = |          = |

         = +-------+  +-------+  +-------+  +-------+  = +-------+

         | = Access|  | Metro |  | Core  |  | Metro |  | = Access|

   +--+  | PTN   |  | = PTN   |  | PTN   |  | PTN   = |  | PTN   |  +--+

   = |CE|=3D=3D|(Vender|=3D=3D|(Vender|=3D=3D|(Vender|=3D=3D|(Vender|=3D=3D|(V= ender|=3D=3D|CE|

   +--+  |    A) |  = |    B) |  |    C) |  = |    D) |  |    E) |  = +--+

         = +-------+  +-------+  +-------+  +-------+  = +-------+

 

        Figure 3 = End-to-End Connection in Mobile Backhaul = Networks

 

 

 

4. Security Considerations

 

   This document raises = no new security issues.

 

 

 

 

Cheng, et = al.           Expires = January = 10,2015           =          [Page = 5]


Internet-Draft      PTN = requirements in ACTN = architecture        July = 2014

5. = IANA Considerations

 

   No new IANA considerations are raised by this = document.

 

6. References

 

6.1.   Informative = References

 

   [ACTN-FWK]   Daniele C., Luyuan = Fang, Yong Lee and Diego Lopez,

          =       "Framework for Abstraction and = Control of Transport

          =       Networks", = draft-ceccarelli-actn-framework-02.

 

   [ACTN-PERF] Yunbin Xu, = Weiqiang Cheng, Guoying Zhang and Haomian

          =    Zheng, "Use Cases and Requirements of Dynamic = Service

          =    Control based on Performance Monitoring in = ACTN

          =   Architecture", = draft-xu-actn-perf-dynamic-service-control-

          =    01.

 

 

 

Authors's Address

 

   Weiqiang = Cheng

   China Mobile Communication = Company

   No.32 Xuanwumen West Street, Xicheng District, = Beijing, China

   = Email:chengweiqiang@chinamobile.com

   Yunbin = Xu

   China Academy of Telecom = Research

   NO.52 Huayuan Beilu, Haidian District, = Beijing, China

   Email: = xuyunbin@catr.cn

   Guoying Zhang

   China Academy of = Telecom Research

   NO.52 Huayuan Beilu, Haidian District, = Beijing, China

   Email: = zhangguoying@catr.cn

 

 

 

 

Cheng, et = al.           &nbs= p; Expires January = 10,2015           =       [Page 6]


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3DDraft = end=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

------=_NextPart_000_00D5_01CF9C48.33DAA820-- From nobody Thu Jul 10 07:16:51 2014 Return-Path: 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 C39851B290A for ; Thu, 10 Jul 2014 07:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 KhN9OYyhklI0 for ; Thu, 10 Jul 2014 07:16:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8884B1B291A for ; Thu, 10 Jul 2014 07:16:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJV32178; Thu, 10 Jul 2014 14:16:22 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 15:16:20 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 07:16:18 -0700 From: Leeyoung To: =?gb2312?B?s8zOsMe/?= , "actn@ietf.org" Thread-Topic: [Actn] ACTN use-case in MPLS-TP based packet transport networks Thread-Index: Ac+cBST5/jaLTmqDT6CUQZY2K7osMwARAm4g Date: Thu, 10 Jul 2014 14:16:18 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C005A2@dfweml706-chm.china.huawei.com> References: <00d401cf9c05$25b76820$71263860$@com> In-Reply-To: <00d401cf9c05$25b76820$71263860$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.231] Content-Type: multipart/mixed; boundary="_004_7AEB3D6833318045B4AE71C2C87E8E1729C005A2dfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/gL7melKxuiNj20Bvd-ku6_0TNg0 Cc: 'xuyunbin' , 'zhangguoying' Subject: Re: [Actn] ACTN use-case in MPLS-TP based packet transport networks X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:16:32 -0000 --_004_7AEB3D6833318045B4AE71C2C87E8E1729C005A2dfweml706chmchi_ Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C005A2dfweml706chmchi_" --_000_7AEB3D6833318045B4AE71C2C87E8E1729C005A2dfweml706chmchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNClRoYW5rcyBXZWlxaWFuZyBmb3IgcG9zdGluZyB0aGlzIHVzZS1jYXNlLg0KDQpIZXJl oa9zIGEgdGV4dCB2ZXJzaW9uIG9mIHRoZSB1c2UtY2FzZSBhdHRhY2hlZCBmb3IgYSBiZXR0ZXIg cmVhZGFiaWxpdHkuDQoNCllvdW5nDQoNCkZyb206IEFDVE4gW21haWx0bzphY3RuLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiA/Pz8NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0 IDE6MDcgQU0NClRvOiBhY3RuQGlldGYub3JnDQpDYzogJ3h1eXVuYmluJzsgJ3poYW5nZ3VveWlu ZycNClN1YmplY3Q6IFtBY3RuXSBBQ1ROIHVzZS1jYXNlIGluIE1QTFMtVFAgYmFzZWQgcGFja2V0 IHRyYW5zcG9ydCBuZXR3b3Jrcw0KDQpIaSBUaGVyZSwNCldlIHByZXBhcmVkIGEgZHJhZnQgYWJv dXQgQUNUTiB1c2UtY2FzZSBpbiBNUExTLVRQIGJhc2VkIHBhY2tldCB0cmFuc3BvcnQgbmV0d29y a3MuICBEdWUgdG8gdGhlIHByb2Nlc3MgaXNzdWVzIHdpdGhpbiBjb21wYW55LCB3ZSBtaXNzZWQg dGhlIElFVEYgZHJhZnQgdXBsb2FkIGRlYWRsaW5lLiBIZXJlIHdlIHdvdWxkIGxpa2UgdG8gcG9z dCBpdCBpbiB0aGUgbWFpbCBsaXN0IGZvciByZXZpZXcuIEl0IGlzIGhpZ2hseSBhcHByZWNpYXRl ZCBpZiB5b3UgY2FuIGNvbW1lbnQgaXQuDQoNCkJlc3QgUmVnYXJkcywNCldlaXFpYW5nIENoZW5n DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PURyYWZ0IGJlZ2lubmluZz09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXLiBDaGVuZw0KSW50ZXJuZXQgRHJhZnQg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGluYSBt b2JpbGUNCkludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbA0KRXhwaXJlczogSmFudWFyeTIw MTUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgWXVuYmluIFh1DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ0FUUg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3VveWluZyBa aGFuZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIENBVFINCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkgMTAsIDIwMTQNCg0KDQogICAgICAg QUNUTiBVc2UtY2FzZXMgZm9yIFBhY2tldCBUcmFuc3BvcnQgTmV0d29ya3MgaW4gTW9iaWxlIEJh Y2toYXVsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldHdvcmtzDQogICAg ICAgICAgICAgICAgICAgZHJhZnQtY2hlbmctYWN0bi1wdG4tcmVxdWlyZW1lbnRzLTAwLnR4dA0K DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJt aXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1Ag NzggYW5kIEJDUCA3OS4NCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMg b2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFy ZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBt YXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJh ZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3Ig YSBtYXhpbXVtIG9mIHNpeA0KICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMNCiAgIGF0IGFueSB0aW1lLiBJdCBpcyBp bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMNCiAgIHJlZmVyZW5jZSBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoN CiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBh dA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQoNCiAgIFRo ZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNz ZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCg0KICAgVGhpcyBJbnRl cm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDEwLCAyMDE1Lg0KDQpDb3B5cmlnaHQg Tm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAxNCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29u cyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gQWxsIHJpZ2h0cyByZXNl cnZlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElF VEYgVHJ1c3QncyBMZWdhbA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50 cw0KICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbylpbiBlZmZlY3Qgb24g dGhlIGRhdGUgb2YNCg0KDQpDaGVuZywgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkg MTAsMjAxNSAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAg IFBUTiByZXF1aXJlbWVudHMgaW4gQUNUTiBhcmNoaXRlY3R1cmUgICAgICBKdWx5IDIwMTQNCiAg IHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1l bnRzDQogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3Ry aWN0aW9ucyB3aXRoDQogICByZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuIENvZGUgQ29tcG9uZW50 cyBleHRyYWN0ZWQgZnJvbSB0aGlzDQogICBkb2N1bWVudCBtdXN0IGluY2x1ZGUgU2ltcGxpZmll ZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiA0LmUgb2YgdGhl IFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0DQogICB3YXJy YW50eSBhcyBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCiAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVn YWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMNCiAgIChodHRwOi8v dHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZg0K ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1 bWVudHMNCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVz dHJpY3Rpb25zIHdpdGgNCiAgIHJlc3BlY3QgdG8gdGhpcyBkb2N1bWVudC4NCg0KQWJzdHJhY3QN Cg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGtleSByZXF1aXJlbWVudHMgZm9yIEFD VE4gaW4gY2FycmllcidzDQogICB0cmFuc3BvcnQgbmV0d29ya3MsIHdoaWNoIG1haW5seSBmb2N1 cyBvbiB0aGUgUGFja2V0IFRyYW5zcG9ydA0KICAgTmV0d29ya3MuDQoNClRhYmxlIG9mIENvbnRl bnRzDQoNCg0KICAgMS4gICAgSW50cm9kdWN0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMw0KICAgMi4gICAgQUNUTiBSZXF1aXJlbWVudCBmb3IgUGFj a2V0IFRyYW5zcG9ydCBOZXR3b3Jrcy4uLi4uLi4uLi4uLi4uMw0KICAgIDIuMS4gRW5kLXRvLUVu ZCBFbnRlcnByaXNlIFNlcnZpY2VzIFByb3Zpc2lvbmluZy4uLi4uLi4uLi4uLi4uLi4uMw0KICAg IDIuMi4gTXVsdGktbGF5ZXIgY29vcmRpbmF0aW9uIFJlcXVpcmVtZW50IGluIEwyL0wzIFBhY2tl dCBUcmFuc3BvcnQNCiAgIE5ldHdvcmtzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQNCiAgICAyLjMuIE9wdGltaXppbmcgdGhlIG5ldHdv cmsgcmVzb3VyY2VzIHV0aWxpemF0aW9uLi4uLi4uLi4uLi4uLi4uLjQNCiAgIDMuICAgIFZpcnR1 YWwgTmV0d29ya3MgT3BlcmF0aW9ucyBmb3IgUGFja2V0IFRyYW5zcG9ydCBOZXR3b3Jrcy4uLjUN CiAgIDQuICAgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjUNCiAgIDUuICAgIElBTkEgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCiAgIDYuICAgIFJlZmVyZW5jZXMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCiAgIDYuMS4gSW5m b3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Ng0KDQoNCg0KDQpDaGVuZywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMCwyMDE1 ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUFROIHJl cXVpcmVtZW50cyBpbiBBQ1ROIGFyY2hpdGVjdHVyZSAgICAgSnVseSAyMDE0DQoNCg0KMS4gSW50 cm9kdWN0aW9uDQoNCg0KICAgTVBMUy1UUCBiYXNlZCBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmsg KFBUTikgaGFzIGJlZW4gd2lkZWx5IHVzZWQgYXMNCiAgIG1vYmlsZSBiYWNraGF1bCBhbmQgZW50 ZXJwcmlzZSBjdXN0b21lciBwcml2YXRlIGxpbmUvTEFOIHNvbHV0aW9ucw0KICAgaW4gbWFueSBj YXJyaWVyJ3MgbmV0d29ya3MuIFRoZSBQYWNrZXQgVHJhbnNwb3J0IE5ldHdvcmtzIHdvcmsgaW4N CiAgIGRpZmZlcmVudCBsYXllcnMgZnJvbSBMMiB0byBMMyBhbmQgaW4gZGlmZmVyZW50IGFyZWFz IHN1Y2ggYXMgYWNjZXNzLA0KICAgbWV0cm8gYW5kIGJhY2tib25lIG5ldHdvcmtzLiBJbiB0aGUg YXBwbGljYXRpb24gc2NlbmFyaW9zLCB0aGUgbW9zdA0KICAgaW1wb3J0YW50IHJlcXVpcmVtZW50 cyBmb3Igb3BlcmF0b3JzIGFyZSB0byBzb2x2ZSB0aGUNCiAgIGludGVyb3BlcmFiaWxpdHkgcHJv YmxlbXMgYmV0d2VlbiBtdWx0aS1kb21haW4vbXVsdGktbGF5ZXIgbmV0d29ya3MsDQogICByZWFs aXplIHRoZSBmYXN0IHNlcnZpY2UgcHJvdmlzaW9uaW5nLCBhbmQgaW1wcm92ZSB0aGUgbmV0d29y aw0KICAgb3BlcmF0aW9uIGVmZmljaWVuY3kuDQoNCiAgIFRoZSBQVE4gb3BlcmF0b3JzIG1heSB1 c2UgQUNUTiB0byBpbXByb3ZlIGVmZmljaWVuY3kgb2YgcHJvdmlzaW9uDQogICBhbmQgb3BlcmF0 aW9uLCBvcHRpbWl6ZSB0aGUgcmVzb3VyY2VzIHV0aWxpemF0aW9uLCBhbmQgcHJvbW90ZSB0aGUN CiAgIGN1c3RvbWVyJ3MgZXhwZXJpZW5jZXMuIFRoaXMgZHJhZnQgbWFpbmx5IGRpc2N1c3NlcyB0 aGUga2V5DQogICByZXF1aXJlbWVudHMgZm9yIEFDVE4gaW4gY2FycmllcidzIFBhY2tldCBUcmFu c3BvcnQgTmV0d29ya3MuDQoNCjIuIEFDVE4gUmVxdWlyZW1lbnQgZm9yIFBhY2tldCBUcmFuc3Bv cnQgTmV0d29ya3MNCg0KMi4xLiAgIEVuZC10by1FbmQgRW50ZXJwcmlzZSBTZXJ2aWNlcyBQcm92 aXNpb25pbmcNCg0KICAgVGhlIGVudGVycHJpc2UgY3VzdG9tZXIgc2VydmljZXMgYXJlIHNlbnNp dGl2ZSB0byB0aGUgbmV0d29yaw0KICAgcXVhbGl0eSwgaGF2ZSBzdHJpY3QgdGltZS1saW1pdCBy ZXF1aXJlbWVudCBmb3Igc2VydmljZQ0KICAgZXN0YWJsaXNobWVudC4gRmFzdGVyIGVuZC10by1l bmQgc2VydmljZSBwcm92aXNpb25pbmcgbWF5IG1ha2UgdGhlDQogICBvcGVyYXRvcnMgd2luIHRo ZSBjb21wZXRpdGlvbi4NCg0KICAgVGhlIG9wZXJhdG9ycyBoYWQgYnVpbHQgYSBsYXJnZSBzY2Fs ZSBvZiBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzDQogICBhbmQgZGl2aWRlZCB0aGVtIGludG8g ZGlmZmVyZW50IGFyZWFzIHN1Y2ggYXMgYWNjZXNzLCBtZXRybyBhbmQNCiAgIGJhY2tib25lIG5l dHdvcmtzLCBlYWNoIGFyZWEgaGFzIHRoZWlyIG93biBtYW5hZ2VtZW50IHN5c3RlbXMuDQogICBD dXJyZW50bHkgaW4gbW9zdCBhcHBsaWNhdGlvbiBzY2VuYXJpb3MsIFBUTiBuZXR3b3JrcyBhcmUg dXNpbmcNCiAgIHN0YXRpYyBwcm92aXNpb25pbmcgd2l0aCBjZW50cmFsaXplZCBOZXR3b3JrIG1h bmFnZW1lbnQgU3lzdGVtcw0KICAgKE5NUykuIEhvd2V2ZXIsIHRoZXkgYXJlIGhhcmQgdG8gbWVl dCB0aGUgcmVxdWlyZW1lbnRzIG9mIGN1cnJlbnQNCiAgIGVudGVycHJpc2Ugc2VydmljZXMgZm9y IGZhc3QgcHJvdmlzaW9uaW5nIGFuZCBlZmZpY2llbnQgb3BlcmF0aW9uLg0KDQogICBUaGUgQUNU TiBhcmNoaXRlY3R1cmUgW0FDVE4tRldLXSBzaG91bGQgYmUgY29uc2lkZXJlZCB0byBjb29yZGlu YXRlDQogICB3aXRoIHRyYWRpdGlvbmFsIHRoZSBuZXR3b3JrcyBtYW5hZ2VtZW50IHN5c3RlbXMs IHNvIGFzIHRvIHJlYWxpemUNCiAgIHRoZSBlbmQtdG8tZW5kIHNlcnZpY2UgcHJvdmlzaW9uLg0K DQoNCiAgICAgIHwgICAgICAgICAgICAgICAgIEVuZC10by1FbmQgQ29ubmVjdGlvbiAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICstLS0tLS0tLSsg ICstLS0tLS0tKyAgKy0tLS0tLS0rICArLS0tLS0tLSsgICstLS0tLS0tKw0KICAgICAgICAgfCBB Y2Nlc3MgfCAgfCBNZXRybyB8ICB8IENvcmUgIHwgIHwgTWV0cm8gfCAgfCBBY2Nlc3N8DQoNCg0K DQpDaGVuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLDIwMTUgICAgICAg ICAgICAgICAgIFtQYWdlIDNdDQoNCkludGVybmV0LURyYWZ0ICAgICAgUFROIHJlcXVpcmVtZW50 cyBpbiBBQ1ROIGFyY2hpdGVjdHVyZSAgICAgIEp1bHkgMjAxNA0KICAgKy0tKyAgfCBQVE4gICAg fCAgfCBQVE4gICB8ICB8IFBUTiAgIHwgIHwgUFROICAgfCAgfCBQVE4gICB8ICArLS0rDQogICB8 Q0V8PT18KFZlbmRlciB8PT18KFZlbmRlcnw9PXwoVmVuZGVyfD09fChWZW5kZXJ8PT18KFZlbmRl cnw9PXxDRXwNCiAgICstLSsgIHwgICAgQSkgIHwgIHwgICBCKSAgfCAgfCAgIEMpICB8ICB8ICAg IEQpIHwgIHwgICAgRSkgfCAgKy0tKw0KICAgICAgICAgKy0tLS0tLS0tKyAgKy0tLS0tLS0rICAr LS0tLS0tLSsgICstLS0tLS0tKyAgKy0tLS0tLS0rDQoNCiAgICAgICAgIEZpZ3VyZSAxIEVuZC10 by1FbmQgQ29ubmVjdGlvbiBpbiBNb2JpbGUgQmFja2hhdWwgTmV0d29ya3MNCg0KMi4yLiBNdWx0 aS1sYXllciBjb29yZGluYXRpb24gUmVxdWlyZW1lbnQgaW4gTDIvTDMgUGFja2V0IFRyYW5zcG9y dA0KICAgIE5ldHdvcmtzDQoNCiAgIExURSBiYWNraGF1bGluZyByZXF1aXJlcyB0aGUgUFROIHRv IHJlYWxpemUgTDMgbmV0d29yayBmdW5jdGlvbi4NCiAgIFRoaXMgZnVuY3Rpb24gcmVxdWlyZXMg dGhlIG1hbmFnZW1lbnQgc3lzdGVtcyBvcGVyYXRlIGluIGRpZmZlcmVudA0KICAgbGF5ZXJzIG9m IG5ldHdvcmtzLCBhbmQgbGVhZHMgdG8gc2VwYXJhdGUgYW5kIGZyYWdtZW50ZWQgbmV0d29yaw0K ICAgY29uZmlndXJhdGlvbi4gRnVydGhlciwgdGhlIEwyIFBUTiBhbmQgTDMgUFROIG5ldHdvcmtz IG1heSBiZQ0KICAgcHJvdmlkZWQgYnkgZGlmZmVyZW50IHZlbmRlcnMsIGFuZCBtYWtlIHRoZSBl bmQtdG8tZW5kIHByb3Zpc2lvbmluZw0KICAgbXVjaCBtb3JlIGNvbXBsZXguIEluIHRoZSBBQ1RO IGFyY2hpdGVjdHVyZSwgbmV3IGZ1bmN0aW9ucyBzdWNoIGFzDQogICB0b3BvbG9neSBkZXRlY3Rp b24gYW5kIHZpcnR1YWxpemF0aW9uLCBhdXRvLXJvdXRpbmcgY2FsY3VsYXRpb24gYXJlDQogICBp bnRyb2R1Y2VkLiBXaXRoIHRoZXNlIGZ1bmN0aW9ucywgb3BlcmF0b3IgY2FuIGltcHJvdmUgdGhl IHVzZXINCiAgIGV4cGVyaWVuY2VzIGFuZCBsb3dlciB0aGUgT1BFWC4NCg0KICAgT24gdGhlIG90 aGVyIGhhbmQsIG9wZXJhdG9ycyB3YW50IHRvIG9idGFpbiB0aGUgZmxvdyBpbmZvcm1hdGlvbiBh bmQNCiAgIHJlYWxpemUgdGhlIGxvYWQgYmFsYW5jaW5nIHdpdGhpbiBMMyBQVE4gbmV0d29ya3Ms DQoNCg0KICAgICAgICAgICAgICAgICAgIHwgICAgICAgRW5kLXRvLUVuZCBDb25uZWN0aW9uICAg ICB8DQogICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PnwNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLSsNCiAg ICAgICAgICArLS0tLS0tLS0rICAgfCAgICAgICAgICB8ICAgfCAgICAgICAgICB8ICAgKy0tLS0t LS0tKw0KICAgICAgICAgIHwgUmFkaW8gIHwgICB8IExheWVyIDIgIHwgICB8IExheWVyIDMgIHwg ICB8IFJhZGlvICB8DQogICAgICAgICAgfCBBY2Nlc3MgfD09PXwgICBQVE4gICAgfD09PXwgICBQ VE4gICAgfD09PXwgQ29yZSAgIHwNCiAgICAgICAgICB8TmV0d29ya3N8ICAgfCBOZXR3b3JrcyB8 ICAgfCBOZXR3b3JrcyB8ICAgfE5ldHdvcmtzfA0KICAgICAgICAgICstLS0tLS0tLSsgICB8KFZl bmRlciBBKXwgICB8KFZlbmRlciBCKXwgICArLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgfCAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgRmlndXJlIDIgRW5kLXRv LUVuZCBDb25uZWN0aW9uIGZvciBMMiZMMyBQVE4gTmV0d29ya3MNCg0KMi4zLiAgIE9wdGltaXpp bmcgdGhlIG5ldHdvcmsgcmVzb3VyY2VzIHV0aWxpemF0aW9uDQoNCiAgIFRoZSBwYWNrZXQgdHJh bnNwb3J0IG5ldHdvcmtzIGNhbiBzdXBwb3J0IHZhcmlvdXMgcGVyZm9ybWFuY2VzDQogICBtb25p dG9yaW5nIG1hdHJpeCwgc3VjaCBhcyB0cmFmZmljIGZsb3cgc3RhdGlzdGljcywgcGFja2V0IGRl bGF5LA0KICAgZGVsYXkgdmFyaWF0aW9uLCB0aHJvdWdocHV0IGFuZCBwYWNrZXQtbG9zcyByYXRl LCBldGMuIEFsbCB0aGVzZQ0KICAgcGVyZm9ybWFuY2UgcGFyYW1ldGVycyBjYW4gc3VwcG9ydCB0 aGUgZW50ZXJwcmlzZSBjdXN0b21lcnMgU0xBDQogICByZXF1aXJlbWVudHMuIFRocm91Z2ggdGhl IHBlcmZvcm1hbmNlIG1vbml0b3JpbmcsIHRoZSBQVE4gY2FuDQoNCg0KDQpDaGVuZywgZXQgYWwu ICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsMjAxNSAgICAgICAgICAgICAgICAgICBbUGFn ZSA0XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgIFBUTiByZXF1aXJlbWVudHMgaW4gQUNUTiBhcmNo aXRlY3R1cmUgICAgICAgICBKdWx5IDIwMTQNCiAgIHJlYWxpemUgdGhlIHNlcnZpY2UgU0xBIG9w dGltaXphdGlvbiBhbmQgbmV0d29yayB0cmFmZmljDQogICBvcHRpbWl6YXRpb24uIFNlZSBbQUNU Ti1QRVJGXSBmb3IgcmVsYXRlZCBkaXNjdXNzaW9uLg0KDQozLiBWaXJ0dWFsIE5ldHdvcmtzIE9w ZXJhdGlvbnMgZm9yIFBhY2tldCBUcmFuc3BvcnQgTmV0d29ya3MNCg0KICAgRmlndXJlIDMgc2hv d3MgYW4gZXhhbXBsZSBvZiB2aXJ0dWFsIG5ldHdvcmsgb3BlcmF0aW9ucyBmb3IgcGFja2V0DQog ICB0cmFuc3BvcnQgbmV0d29ya3MuIEluIG9yZGVyIHRvIHJlYWxpemUgZW5kLXRvLWVuZCBzZXJ2 aWNlIHByb3Zpc2lvbiwNCiAgIHRoZSBBQ1ROIGFyY2hpdGVjdHVyZSBbQUNUTi1GV0tdIHNob3Vs ZCBjb25zaWRlciBjb29yZGluYXRpb24gd2l0aA0KICAgdHJhZGl0aW9uYWwgbmV0d29yayBtYW5h Z2VtZW50IHN5c3RlbXMuIEJ5IHRoZSBuZXR3b3JrDQogICB2aXJ0dWFsaXphdGlvbiBhbmQgYWJz dHJhY3Rpb24sIHRoZSB0cmFkaXRpb25hbCBuZXR3b3JrcyBjYW4gYmUNCiAgIGNvbnNpZGVyZWQg YXMgYSB2aXJ0dWFsIG5ldHdvcmsgZm9yIFZOQyBzZXJ2aWNlIHByb3ZpZGVyLCB3aGljaCBjYW4N CiAgIGJlIHJlYWxpemVkIGJ5IG5ldHdvcmsgbWFuYWdlbWVudCBzeXN0ZW1zIHByb3ZpZGluZyBh biBhYnN0cmFjdA0KICAgYWdlbnQgZm9yIFZOQywgb3IgdGhlIFZOQyBwcm92aWRpbmcgdHJhZGl0 aW9uYWwgaW50ZXJmYWNlIGZvciBOTVMuDQoNCg0KICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICB8ICAgICAgICAgICAg IFZOQyBTZXJ2aWNlIFByb3ZpZGVyICAgICAgICB8DQogICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgLyAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgICAvICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAvICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgLyAgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgXA0KICAgICAgICAgICAgICAvICAgIHwgICAgICAgTk1T IEFic3RyYWN0IEFnZW50ICAgIHwgICAgIFwNCiAgICAgICAgICstLS0tLS0tKyArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rICstLS0tLS0tKw0KICAgICAgICAgfEFjY2VzcyB8ICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgfEFjY2VzcyB8DQogICAgICAgIHxDb250cm9sfCB8 IE5ldHdvcmsgTWFuYWdlbWVudCBTeXN0ZW1zICB8IHxDb250cm9sfA0KICAgICAgICAgKy0tLS0t LS0rICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgKy0tLS0tLS0rDQogICAgICAgICAg ICAgIHwgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQogICAgICAg ICAgICAgIHwgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQogICAg ICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQog ICAgICAgICArLS0tLS0tLSsgICstLS0tLS0tKyAgKy0tLS0tLS0rICArLS0tLS0tLSsgICstLS0t LS0tKw0KICAgICAgICAgfCBBY2Nlc3N8ICB8IE1ldHJvIHwgIHwgQ29yZSAgfCAgfCBNZXRybyB8 ICB8IEFjY2Vzc3wNCiAgICstLSsgIHwgUFROICAgfCAgfCBQVE4gICB8ICB8IFBUTiAgIHwgIHwg UFROICAgfCAgfCBQVE4gICB8ICArLS0rDQogICB8Q0V8PT18KFZlbmRlcnw9PXwoVmVuZGVyfD09 fChWZW5kZXJ8PT18KFZlbmRlcnw9PXwoVmVuZGVyfD09fENFfA0KICAgKy0tKyAgfCAgICBBKSB8 ICB8ICAgIEIpIHwgIHwgICAgQykgfCAgfCAgICBEKSB8ICB8ICAgIEUpIHwgICstLSsNCiAgICAg ICAgICstLS0tLS0tKyAgKy0tLS0tLS0rICArLS0tLS0tLSsgICstLS0tLS0tKyAgKy0tLS0tLS0r DQoNCiAgICAgICAgRmlndXJlIDMgRW5kLXRvLUVuZCBDb25uZWN0aW9uIGluIE1vYmlsZSBCYWNr aGF1bCBOZXR3b3Jrcw0KDQoNCg0KNC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhp cyBkb2N1bWVudCByYWlzZXMgbm8gbmV3IHNlY3VyaXR5IGlzc3Vlcy4NCg0KDQoNCg0KQ2hlbmcs IGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLDIwMTUgICAgICAgICAgICAgICAg ICAgIFtQYWdlIDVdDQoNCkludGVybmV0LURyYWZ0ICAgICAgUFROIHJlcXVpcmVtZW50cyBpbiBB Q1ROIGFyY2hpdGVjdHVyZSAgICAgICAgSnVseSAyMDE0DQo1LiBJQU5BIENvbnNpZGVyYXRpb25z DQoNCiAgIE5vIG5ldyBJQU5BIGNvbnNpZGVyYXRpb25zIGFyZSByYWlzZWQgYnkgdGhpcyBkb2N1 bWVudC4NCg0KNi4gUmVmZXJlbmNlcw0KDQo2LjEuICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0K DQogICBbQUNUTi1GV0tdICAgRGFuaWVsZSBDLiwgTHV5dWFuIEZhbmcsIFlvbmcgTGVlIGFuZCBE aWVnbyBMb3BleiwNCiAgICAgICAgICAgICAgICAiRnJhbWV3b3JrIGZvciBBYnN0cmFjdGlvbiBh bmQgQ29udHJvbCBvZiBUcmFuc3BvcnQNCiAgICAgICAgICAgICAgICBOZXR3b3JrcyIsIGRyYWZ0 LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDIuDQoNCiAgIFtBQ1ROLVBFUkZdIFl1bmJpbiBY dSwgV2VpcWlhbmcgQ2hlbmcsIEd1b3lpbmcgWmhhbmcgYW5kIEhhb21pYW4NCiAgICAgICAgICAg ICBaaGVuZywgIlVzZSBDYXNlcyBhbmQgUmVxdWlyZW1lbnRzIG9mIER5bmFtaWMgU2VydmljZQ0K ICAgICAgICAgICAgIENvbnRyb2wgYmFzZWQgb24gUGVyZm9ybWFuY2UgTW9uaXRvcmluZyBpbiBB Q1RODQogICAgICAgICAgICAgQXJjaGl0ZWN0dXJlIiwgZHJhZnQteHUtYWN0bi1wZXJmLWR5bmFt aWMtc2VydmljZS1jb250cm9sLQ0KICAgICAgICAgICAgIDAxLg0KDQoNCg0KQXV0aG9ycydzIEFk ZHJlc3MNCg0KICAgV2VpcWlhbmcgQ2hlbmcNCiAgIENoaW5hIE1vYmlsZSBDb21tdW5pY2F0aW9u IENvbXBhbnkNCiAgIE5vLjMyIFh1YW53dW1lbiBXZXN0IFN0cmVldCwgWGljaGVuZyBEaXN0cmlj dCwgQmVpamluZywgQ2hpbmENCiAgIEVtYWlsOmNoZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29t DQogICBZdW5iaW4gWHUNCiAgIENoaW5hIEFjYWRlbXkgb2YgVGVsZWNvbSBSZXNlYXJjaA0KICAg Tk8uNTIgSHVheXVhbiBCZWlsdSwgSGFpZGlhbiBEaXN0cmljdCwgQmVpamluZywgQ2hpbmENCiAg IEVtYWlsOiB4dXl1bmJpbkBjYXRyLmNuPG1haWx0bzp4dXl1bmJpbkBjYXRyLmNuPg0KICAgR3Vv eWluZyBaaGFuZw0KICAgQ2hpbmEgQWNhZGVteSBvZiBUZWxlY29tIFJlc2VhcmNoDQogICBOTy41 MiBIdWF5dWFuIEJlaWx1LCBIYWlkaWFuIERpc3RyaWN0LCBCZWlqaW5nLCBDaGluYQ0KICAgRW1h aWw6IHpoYW5nZ3VveWluZ0BjYXRyLmNuPG1haWx0bzp6aGFuZ2d1b3lpbmdAY2F0ci5jbj4NCg0K DQoNCg0KQ2hlbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsMjAxNSAg ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT1E cmFmdCBlbmQ9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg== --_000_7AEB3D6833318045B4AE71C2C87E8E1729C005A2dfweml706chmchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

=  

Thank= s Weiqiang for posting this use-case.

=  

Here= =A1=AFs a text version of the use-case attached for a better readability.

=  

Young=

=  

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of ???
Sent: Thursday, July 10, 2014 1:07 AM
To: actn@ietf.org
Cc: 'xuyunbin'; 'zhangguoying'
Subject: [Actn] ACTN use-case in MPLS-TP based packet transport netw= orks

 =

Hi There,

We prepared a draft about ACTN use-case in MPLS-TP based pa= cket transport networks.  Due to the process issues within company, we= missed the IETF draft upload deadline. Here we would like to post it in the mail list for review. It is highly appreciated if y= ou can comment it.

 

Best Regards,
Weiqiang Cheng

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DDraft beginning=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

Network Working Group     &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;W. Cheng

Internet Draft      &n= bsp;            = ;            &n= bsp;            &nbs= p;      China mobile

Intended status: Informational

Expires: January2015

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Yunbin Xu

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           CATR

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Guoying Zhang

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           CATR

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  July 10, 2014

 

 

       ACTN Use-cases = for Packet Transport Networks in Mobile Backhaul

        &nbs= p;            &= nbsp;           &nbs= p; Networks

        &nbs= p;          draft-cheng-actn-p= tn-requirements-00.txt

 

 

Status of this Memo

 

   This Internet-Draft is submitted in ful= l conformance with the

   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents o= f the Internet Engineering

   Task Force (IETF), its areas, and its w= orking groups. Note that

   other groups may also distribute workin= g documents as Internet-

   Drafts.

 

   Internet-Drafts are draft documents val= id for a maximum of six

   months and may be updated, replaced, or= obsoleted by other documents

   at any time. It is inappropriate to use= Internet-Drafts as

   reference material or to cite them othe= r than as "work in progress."

 

   The list of current Internet-Drafts can= be accessed at

   http://www.ietf.org/ietf/1id-abstracts.txt

 

   The list of Internet-Draft Shadow Direc= tories can be accessed at

   http://www.ietf.org/shadow.html

 

   This Internet-Draft will expire on Janu= ary 10, 2015.

 

Copyright Notice

 

   Copyright (c) 2014 IETF Trust and the p= ersons identified as the

   document authors. All rights reserved.<= o:p>

 

   This document is subject to BCP 78 and = the IETF Trust's Legal

   Provisions Relating to IETF Documents

   (http://trustee.ietf.org/license-info)in effect on the dat= e of

 

 

Cheng, et al.      &nb= sp;    Expires January 10,2015     =             &nb= sp; [Page 1]

Internet-Draft      PTN req= uirements in ACTN architecture      July 2014=

   publication of this document. Please re= view these documents

   carefully, as they describe your rights= and restrictions with

   respect to this document. Code Componen= ts extracted from this

   document must include Simplified BSD Li= cense text as described in

   Section 4.e of the Trust Legal Provisio= ns and are provided without

   warranty as described in the Simplified= BSD License.

 

   This document is subject to BCP 78 and = the IETF Trust's Legal

   Provisions Relating to IETF Documents

   (http://trustee.ietf.org/license-info) in effect on the date = of

   publication of this document. Please re= view these documents

   carefully, as they describe your rights= and restrictions with

   respect to this document.

 

Abstract

 

   This document describes the key require= ments for ACTN in carrier's

   transport networks, which mainly focus = on the Packet Transport

   Networks.

 

Table of Contents

 

 

   1.    Introduction......= ..........................................3

   2.    ACTN Requirement f= or Packet Transport Networks..............3

    2.1. End-to-End Enterprise Servic= es Provisioning.................3

    2.2. Multi-layer coordination Req= uirement in L2/L3 Packet Transport

   Networks...............................= ...........................4

    2.3. Optimizing the network resou= rces utilization................4

   3.    Virtual Networks O= perations for Packet Transport Networks...5

   4.    Security Considera= tions.....................................5

   5.    IANA Consideration= s.........................................6

   6.    References........= ..........................................6

   6.1. Informative References............= ..........................6

 

 

 

 

Cheng, et al.      &nb= sp;   Expires January 10,2015      =            [Page 2]<= /o:p>

Internet-Draft      &n= bsp; PTN requirements in ACTN architecture     July 201= 4

 

 

1. Introduction

 

 

   MPLS-TP based packet transport network = (PTN) has been widely used as

   mobile backhaul and enterprise customer= private line/LAN solutions

   in many carrier's networks. The Packet = Transport Networks work in

   different layers from L2 to L3 and in d= ifferent areas such as access,

   metro and backbone networks. In the app= lication scenarios, the most

   important requirements for operators ar= e to solve the

   interoperability problems between multi= -domain/multi-layer networks,

   realize the fast service provisioning, = and improve the network

   operation efficiency.

 

   The PTN operators may use ACTN to impro= ve efficiency of provision

   and operation, optimize the resources u= tilization, and promote the

   customer's experiences. This draft main= ly discusses the key

   requirements for ACTN in carrier's Pack= et Transport Networks.

 

2. ACTN Requirement for Packet Transport Networks

 

2.1.   End-to-End Enterprise Services Prov= isioning

 

   The enterprise customer services are se= nsitive to the network

   quality, have strict time-limit require= ment for service

   establishment. Faster end-to-end servic= e provisioning may make the

   operators win the competition.

 

   The operators had built a large scale o= f packet transport networks

   and divided them into different areas s= uch as access, metro and

   backbone networks, each area has their = own management systems.

   Currently in most application scenarios= , PTN networks are using

   static provisioning with centralized Ne= twork management Systems

   (NMS). However, they are hard to meet t= he requirements of current

   enterprise services for fast provisioni= ng and efficient operation.

 

   The ACTN architecture [ACTN-FWK] should= be considered to coordinate

   with traditional the networks managemen= t systems, so as to realize

   the end-to-end service provision.<= /o:p>

 

 

      |   &n= bsp;            = ; End-to-End Connection        &nbs= p;           |=

      |<----------------= ---------------------------------------->|

      |   &n= bsp;            = ;            &n= bsp;            &nbs= p;            &= nbsp;   |

         = 3;--------+  +-------+  +-------+  += -------+  +-------+

         | A= ccess |  | Metro |  | Core  |  | Metro |  | Access= |

 

 

 

Cheng, et al.      &nb= sp;     Expires January 10,2015    =              [P= age 3]

Internet-Draft      PTN req= uirements in ACTN architecture      July 2014=

   +--+  | PTN  &nb= sp; |  | PTN   |  | PTN   |  | PTN =   |  | PTN   |  +--+

   |CE|=3D=3D|(Vender |=3D=3D|(Vender|=3D= =3D|(Vender|=3D=3D|(Vender|=3D=3D|(Vender|=3D=3D|CE|

   +--+  |    = A)  |  |   B)  |  |   C)  |&nb= sp; |    D) |  |    E) |  +--&#= 43;

         = 3;--------+  +-------+  +-------+  += -------+  +-------+

 

         Fig= ure 1 End-to-End Connection in Mobile Backhaul Networks

 

2.2. Multi-layer coordination Requirement in L2/L3 P= acket Transport

    Networks

 

   LTE backhauling requires the PTN to rea= lize L3 network function.

   This function requires the management s= ystems operate in different

   layers of networks, and leads to separa= te and fragmented network

   configuration. Further, the L2 PTN and = L3 PTN networks may be

   provided by different venders, and make= the end-to-end provisioning

   much more complex. In the ACTN architec= ture, new functions such as

   topology detection and virtualization, = auto-routing calculation are

   introduced. With these functions, opera= tor can improve the user

   experiences and lower the OPEX.

 

   On the other hand, operators want to ob= tain the flow information and

   realize the load balancing within L3 PT= N networks,

 

 

        &nbs= p;          |   = ;    End-to-End Connection     |

        &nbs= p;          |<-------------= ------------------>|

        &nbs= p;          |   = ;            &n= bsp;            = ;     |

        &nbs= p;            &= nbsp; +----------+   +----------+

        &nbs= p; +--------+   |      &nbs= p;   |   |       &nb= sp;  |   +--------+

        &nbs= p; | Radio  |   | Layer 2  |   | Layer 3 = ; |   | Radio  |

        &nbs= p; | Access |=3D=3D=3D|   PTN    |=3D=3D=3D| =   PTN    |=3D=3D=3D| Core   |

        &nbs= p; |Networks|   | Networks |   | Networks |  = |Networks|

        &nbs= p; +--------+   |(Vender A)|   |(Vender B)|&nbs= p;  +--------+

        &nbs= p;            &= nbsp; |          |  = |          |

        &nbs= p;            &= nbsp; +----------+   +----------+

 

        &nbs= p;   Figure 2 End-to-End Connection for L2&L3 PTN Networks

 

2.3.   Optimizing the network resources ut= ilization

 

   The packet transport networks can suppo= rt various performances

   monitoring matrix, such as traffic flow= statistics, packet delay,

   delay variation, throughput and packet-= loss rate, etc. All these

   performance parameters can support the = enterprise customers SLA

   requirements. Through the performance m= onitoring, the PTN can

 

 

 

Cheng, et al.      &nb= sp;    Expires January 10,2015     =             &nb= sp; [Page 4]

Internet-Draft      PTN req= uirements in ACTN architecture       &nb= sp; July 2014

   realize the service SLA optimization an= d network traffic

   optimization. See [ACTN-PERF] for relat= ed discussion.

 

3. Virtual Networks Operations for Packet Transport = Networks

 

   Figure 3 shows an example of virtual ne= twork operations for packet

   transport networks. In order to realize= end-to-end service provision,

   the ACTN architecture [ACTN-FWK] should= consider coordination with

   traditional network management systems.= By the network

   virtualization and abstraction, the tra= ditional networks can be

   considered as a virtual network for VNC= service provider, which can

   be realized by network management syste= ms providing an abstract

   agent for VNC, or the VNC providing tra= ditional interface for NMS.

 

 

        &nbs= p;    +-----------------------------------------+

        &nbs= p;    |         = ;    VNC Service Provider      = ;  |

        &nbs= p;    +-----------------------------------------+

        &nbs= p;         /    = ;            | =             &nb= sp; \

        &nbs= p;        /     = ;            | =             &nb= sp;  \

        &nbs= p;       /      = ;            | =             &nb= sp;   \

        &nbs= p;      /   +-----------------------= ------+    \

        &nbs= p;     /    |    &nb= sp;  NMS Abstract Agent    |     \<= o:p>

         = 3;-------+ +-----------------------------+ +-------+

         |Ac= cess | +-----------------------------+ |Access |

        |Con= trol| | Network Management Systems  | |Control|

         = 3;-------+ +-----------------------------+ +-------+

        &nbs= p;     |        = ; |          |  &nbs= p;       |      = ;    |

        &nbs= p;     |        = ; |          |  &nbs= p;       |      = ;    |

        &nbs= p;     |        &nbs= p;|          |  &nbs= p;       |      = ;    |

         = 3;-------+  +-------+  +-------+  +-= ------+  +-------+

         | A= ccess|  | Metro |  | Core  |  | Metro |  | Access|=

   +--+  | PTN   |&= nbsp; | PTN   |  | PTN   |  | PTN  = |  | PTN   |  +--+

   |CE|=3D=3D|(Vender|=3D=3D|(Vender|=3D= =3D|(Vender|=3D=3D|(Vender|=3D=3D|(Vender|=3D=3D|CE|

   +--+  |    = A) |  |    B) |  |    C) |  |&= nbsp;   D) |  |    E) |  +--+

         = 3;-------+  +-------+  +-------+  +-= ------+  +-------+

 

        Figure 3 = End-to-End Connection in Mobile Backhaul Networks

 

 

 

4. Security Considerations

 

   This document raises no new security is= sues.

 

 

 

 

Cheng, et al.      &nb= sp;    Expires January 10,2015     =             &nb= sp;  [Page 5]

Internet-Draft      PTN req= uirements in ACTN architecture        Ju= ly 2014

5. IANA Considerations

 

   No new IANA considerations are raised b= y this document.

 

6. References

 

6.1.   Informative References

 

   [ACTN-FWK]   Daniele C., Luyu= an Fang, Yong Lee and Diego Lopez,

        &nbs= p;       "Framework for Abstraction and = Control of Transport

        &nbs= p;       Networks", draft-ceccarelli-act= n-framework-02.

 

   [ACTN-PERF] Yunbin Xu, Weiqiang Cheng, = Guoying Zhang and Haomian

        &nbs= p;    Zheng, "Use Cases and Requirements of Dynamic Ser= vice

        &nbs= p;    Control based on Performance Monitoring in ACTN

        &nbs= p;    Architecture", draft-xu-actn-perf-dynamic-service= -control-

        &nbs= p;    01.

 

 

 

Authors's Address

 

   Weiqiang Cheng

   China Mobile Communication Company=

   No.32 Xuanwumen West Street, Xicheng Di= strict, Beijing, China

   Email:chengweiqiang@chinamobile.com

   Yunbin Xu

   China Academy of Telecom Research<= /o:p>

   NO.52 Huayuan Beilu, Haidian District, = Beijing, China

   Email: xuyunbin@catr.cn

   Guoying Zhang

   China Academy of Telecom Research<= /o:p>

   NO.52 Huayuan Beilu, Haidian District, = Beijing, China

   Email: zhangguoying@catr.cn

 

 

 

 

Cheng, et al.      &nb= sp;      Expires January 10,2015   =             &nb= sp; [Page 6]

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DDraft end=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C005A2dfweml706chmchi_-- --_004_7AEB3D6833318045B4AE71C2C87E8E1729C005A2dfweml706chmchi_ Content-Type: text/plain; name="draft-cheng-actn-ptn-requirements-00.txt" Content-Description: draft-cheng-actn-ptn-requirements-00.txt Content-Disposition: attachment; filename="draft-cheng-actn-ptn-requirements-00.txt"; size=12368; creation-date="Thu, 10 Jul 2014 14:13:44 GMT"; modification-date="Thu, 10 Jul 2014 14:13:44 GMT" Content-Transfer-Encoding: base64 TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgV2VpcWlhbmcgQ2hlbmcNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDTUNDDQpJbnRlbmRlZCBzdGF0dXM6IElu Zm9ybWF0aW9uYWwNCkV4cGlyZXM6IEphbnVhcnkyMDE1DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFl1bmJpbiBYdQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIENBVFINCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEd1b3lpbmcgWmhhbmcNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDQVRSDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBKdWx5IDEwLCAyMDE0DQoNCg0KICAgICAgIEFDVE4gVXNlLWNhc2VzIGZvciBQYWNrZXQg VHJhbnNwb3J0IE5ldHdvcmtzIGluIE1vYmlsZSBCYWNraGF1bA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBOZXR3b3Jrcw0KICAgICAgICAgICAgICAgICAgIGRyYWZ0LWNoZW5n LWFjdG4tcHRuLXJlcXVpcmVtZW50cy0wMC50eHQNCg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoN CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aCB0aGUNCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQogICBJbnRlcm5l dC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu Zw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vw cy4gTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgNCiAgIG1vbnRo cyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9j dW1lbnRzDQogICBhdCBhbnkgdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJu ZXQtRHJhZnRzIGFzDQogICByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aWV0Zi8xaWQtYWJzdHJhY3RzLnR4dA0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBT aGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g SmFudWFyeSAxMCwgMjAxNS4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKGMp IDIwMTQgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAgIGRv Y3VtZW50IGF1dGhvcnMuIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQg aXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zp c2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMNCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRm Lm9yZy9saWNlbnNlLWluZm8paW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQoNCg0KQ2hlbmcsIGV0 IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLDIwMTUgICAgICAgICAgICAgICAgICAg W1BhZ2UgMV0NCgxJbnRlcm5ldC1EcmFmdCAgICAgIFBUTiByZXF1aXJlbWVudHMgaW4gQUNUTiBh cmNoaXRlY3R1cmUgICAgICBKdWx5IDIwMTQNCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1l bnQuIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBjYXJlZnVsbHksIGFzIHRoZXkg ZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoDQogICByZXNwZWN0IHRv IHRoaXMgZG9jdW1lbnQuIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzDQogICBk b2N1bWVudCBtdXN0IGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2Ny aWJlZCBpbg0KICAgU2VjdGlvbiA0LmUgb2YgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5k IGFyZSBwcm92aWRlZCB3aXRob3V0DQogICB3YXJyYW50eSBhcyBkZXNjcmliZWQgaW4gdGhlIFNp bXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBC Q1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcg dG8gSUVURiBEb2N1bWVudHMNCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWlu Zm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1 bWVudC4gUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNCiAgIGNhcmVmdWxseSwgYXMgdGhl eSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGgNCiAgIHJlc3BlY3Qg dG8gdGhpcyBkb2N1bWVudC4NCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgdGhlIGtleSByZXF1aXJlbWVudHMgZm9yIEFDVE4gaW4gY2FycmllcidzDQogICB0cmFuc3Bv cnQgbmV0d29ya3MsIHdoaWNoIG1haW5seSBmb2N1cyBvbiB0aGUgUGFja2V0IFRyYW5zcG9ydA0K ICAgTmV0d29ya3MuDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCg0KICAgMS4gICAgSW50cm9kdWN0 aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMw0KICAg Mi4gICAgQUNUTiBSZXF1aXJlbWVudCBmb3IgUGFja2V0IFRyYW5zcG9ydCBOZXR3b3Jrcy4uLi4u Li4uLi4uLi4uMw0KICAgIDIuMS4gRW5kLXRvLUVuZCBFbnRlcnByaXNlIFNlcnZpY2VzIFByb3Zp c2lvbmluZy4uLi4uLi4uLi4uLi4uLi4uMw0KICAgIDIuMi4gTXVsdGktbGF5ZXIgY29vcmRpbmF0 aW9uIFJlcXVpcmVtZW50IGluIEwyL0wzIFBhY2tldCBUcmFuc3BvcnQNCiAgIE5ldHdvcmtzLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQN CiAgICAyLjMuIE9wdGltaXppbmcgdGhlIG5ldHdvcmsgcmVzb3VyY2VzIHV0aWxpemF0aW9uLi4u Li4uLi4uLi4uLi4uLjQNCiAgIDMuICAgIFZpcnR1YWwgTmV0d29ya3MgT3BlcmF0aW9ucyBmb3Ig UGFja2V0IFRyYW5zcG9ydCBOZXR3b3Jrcy4uLjUNCiAgIDQuICAgIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgIDUuICAgIElB TkEgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjYNCiAgIDYuICAgIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjYNCiAgIDYuMS4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KDQoNCg0KDQpDaGVuZywgZXQgYWwuICAg ICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMCwyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0K DEludGVybmV0LURyYWZ0ICAgICAgICBQVE4gcmVxdWlyZW1lbnRzIGluIEFDVE4gYXJjaGl0ZWN0 dXJlICAgICBKdWx5IDIwMTQNCg0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KDQogICBNUExTLVRQIGJh c2VkIHBhY2tldCB0cmFuc3BvcnQgbmV0d29yayAoUFROKSBoYXMgYmVlbiB3aWRlbHkgdXNlZCBh cw0KICAgbW9iaWxlIGJhY2toYXVsIGFuZCBlbnRlcnByaXNlIGN1c3RvbWVyIHByaXZhdGUgbGlu ZS9MQU4gc29sdXRpb25zDQogICBpbiBtYW55IGNhcnJpZXIncyBuZXR3b3Jrcy4gVGhlIFBhY2tl dCBUcmFuc3BvcnQgTmV0d29ya3Mgd29yayBpbg0KICAgZGlmZmVyZW50IGxheWVycyBmcm9tIEwy IHRvIEwzIGFuZCBpbiBkaWZmZXJlbnQgYXJlYXMgc3VjaCBhcyBhY2Nlc3MsDQogICBtZXRybyBh bmQgYmFja2JvbmUgbmV0d29ya3MuIEluIHRoZSBhcHBsaWNhdGlvbiBzY2VuYXJpb3MsIHRoZSBt b3N0DQogICBpbXBvcnRhbnQgcmVxdWlyZW1lbnRzIGZvciBvcGVyYXRvcnMgYXJlIHRvIHNvbHZl IHRoZQ0KICAgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBiZXR3ZWVuIG11bHRpLWRvbWFpbi9t dWx0aS1sYXllciBuZXR3b3JrcywNCiAgIHJlYWxpemUgdGhlIGZhc3Qgc2VydmljZSBwcm92aXNp b25pbmcsIGFuZCBpbXByb3ZlIHRoZSBuZXR3b3JrDQogICBvcGVyYXRpb24gZWZmaWNpZW5jeS4N Cg0KICAgVGhlIFBUTiBvcGVyYXRvcnMgbWF5IHVzZSBBQ1ROIHRvIGltcHJvdmUgZWZmaWNpZW5j eSBvZiBwcm92aXNpb24NCiAgIGFuZCBvcGVyYXRpb24sIG9wdGltaXplIHRoZSByZXNvdXJjZXMg dXRpbGl6YXRpb24sIGFuZCBwcm9tb3RlIHRoZQ0KICAgY3VzdG9tZXIncyBleHBlcmllbmNlcy4g VGhpcyBkcmFmdCBtYWlubHkgZGlzY3Vzc2VzIHRoZSBrZXkNCiAgIHJlcXVpcmVtZW50cyBmb3Ig QUNUTiBpbiBjYXJyaWVyJ3MgUGFja2V0IFRyYW5zcG9ydCBOZXR3b3Jrcy4NCg0KMi4gQUNUTiBS ZXF1aXJlbWVudCBmb3IgUGFja2V0IFRyYW5zcG9ydCBOZXR3b3Jrcw0KDQoyLjEuICAgRW5kLXRv LUVuZCBFbnRlcnByaXNlIFNlcnZpY2VzIFByb3Zpc2lvbmluZw0KDQogICBUaGUgZW50ZXJwcmlz ZSBjdXN0b21lciBzZXJ2aWNlcyBhcmUgc2Vuc2l0aXZlIHRvIHRoZSBuZXR3b3JrDQogICBxdWFs aXR5LCBoYXZlIHN0cmljdCB0aW1lLWxpbWl0IHJlcXVpcmVtZW50IGZvciBzZXJ2aWNlDQogICBl c3RhYmxpc2htZW50LiBGYXN0ZXIgZW5kLXRvLWVuZCBzZXJ2aWNlIHByb3Zpc2lvbmluZyBtYXkg bWFrZSB0aGUNCiAgIG9wZXJhdG9ycyB3aW4gdGhlIGNvbXBldGl0aW9uLg0KDQogICBUaGUgb3Bl cmF0b3JzIGhhZCBidWlsdCBhIGxhcmdlIHNjYWxlIG9mIHBhY2tldCB0cmFuc3BvcnQgbmV0d29y a3MNCiAgIGFuZCBkaXZpZGVkIHRoZW0gaW50byBkaWZmZXJlbnQgYXJlYXMgc3VjaCBhcyBhY2Nl c3MsIG1ldHJvIGFuZA0KICAgYmFja2JvbmUgbmV0d29ya3MsIGVhY2ggYXJlYSBoYXMgdGhlaXIg b3duIG1hbmFnZW1lbnQgc3lzdGVtcy4NCiAgIEN1cnJlbnRseSBpbiBtb3N0IGFwcGxpY2F0aW9u IHNjZW5hcmlvcywgUFROIG5ldHdvcmtzIGFyZSB1c2luZw0KICAgc3RhdGljIHByb3Zpc2lvbmlu ZyB3aXRoIGNlbnRyYWxpemVkIE5ldHdvcmsgbWFuYWdlbWVudCBTeXN0ZW1zDQogICAoTk1TKS4g SG93ZXZlciwgdGhleSBhcmUgaGFyZCB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgY3VycmVu dA0KICAgZW50ZXJwcmlzZSBzZXJ2aWNlcyBmb3IgZmFzdCBwcm92aXNpb25pbmcgYW5kIGVmZmlj aWVudCBvcGVyYXRpb24uDQoNCiAgIFRoZSBBQ1ROIGFyY2hpdGVjdHVyZSBbQUNUTi1GV0tdIHNo b3VsZCBiZSBjb25zaWRlcmVkIHRvIGNvb3JkaW5hdGUNCiAgIHdpdGggdHJhZGl0aW9uYWwgdGhl IG5ldHdvcmtzIG1hbmFnZW1lbnQgc3lzdGVtcywgc28gYXMgdG8gcmVhbGl6ZQ0KICAgdGhlIGVu ZC10by1lbmQgc2VydmljZSBwcm92aXNpb24uDQoNCg0KICAgICAgfCAgICAgICAgICAgICAgICAg RW5kLXRvLUVuZCBDb25uZWN0aW9uICAgICAgICAgICAgICAgICAgICB8DQogICAgICB8PC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgKy0tLS0tLS0tKyAgKy0tLS0tLS0rICArLS0tLS0tLSsgICstLS0t LS0tKyAgKy0tLS0tLS0rDQogICAgICAgICB8IEFjY2VzcyB8ICB8IE1ldHJvIHwgIHwgQ29yZSAg fCAgfCBNZXRybyB8ICB8IEFjY2Vzc3wNCg0KDQoNCkNoZW5nLCBldCBhbC4gICAgICAgICAgICBF eHBpcmVzIEphbnVhcnkgMTAsMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgxJbnRlcm5l dC1EcmFmdCAgICAgIFBUTiByZXF1aXJlbWVudHMgaW4gQUNUTiBhcmNoaXRlY3R1cmUgICAgICBK dWx5IDIwMTQNCiAgICstLSsgIHwgUFROICAgIHwgIHwgUFROICAgfCAgfCBQVE4gICB8ICB8IFBU TiAgIHwgIHwgUFROICAgfCAgKy0tKw0KICAgfENFfD09fChWZW5kZXIgfD09fChWZW5kZXJ8PT18 KFZlbmRlcnw9PXwoVmVuZGVyfD09fChWZW5kZXJ8PT18Q0V8DQogICArLS0rICB8ICAgIEEpICB8 ICB8ICAgQikgIHwgIHwgICBDKSAgfCAgfCAgICBEKSB8ICB8ICAgIEUpIHwgICstLSsNCiAgICAg ICAgICstLS0tLS0tLSsgICstLS0tLS0tKyAgKy0tLS0tLS0rICArLS0tLS0tLSsgICstLS0tLS0t Kw0KDQogICAgICAgICBGaWd1cmUgMSBFbmQtdG8tRW5kIENvbm5lY3Rpb24gaW4gTW9iaWxlIEJh Y2toYXVsIE5ldHdvcmtzDQoNCjIuMi4gTXVsdGktbGF5ZXIgY29vcmRpbmF0aW9uIFJlcXVpcmVt ZW50IGluIEwyL0wzIFBhY2tldCBUcmFuc3BvcnQNCiAgICBOZXR3b3Jrcw0KDQogICBMVEUgYmFj a2hhdWxpbmcgcmVxdWlyZXMgdGhlIFBUTiB0byByZWFsaXplIEwzIG5ldHdvcmsgZnVuY3Rpb24u DQogICBUaGlzIGZ1bmN0aW9uIHJlcXVpcmVzIHRoZSBtYW5hZ2VtZW50IHN5c3RlbXMgb3BlcmF0 ZSBpbiBkaWZmZXJlbnQNCiAgIGxheWVycyBvZiBuZXR3b3JrcywgYW5kIGxlYWRzIHRvIHNlcGFy YXRlIGFuZCBmcmFnbWVudGVkIG5ldHdvcmsNCiAgIGNvbmZpZ3VyYXRpb24uIEZ1cnRoZXIsIHRo ZSBMMiBQVE4gYW5kIEwzIFBUTiBuZXR3b3JrcyBtYXkgYmUNCiAgIHByb3ZpZGVkIGJ5IGRpZmZl cmVudCB2ZW5kZXJzLCBhbmQgbWFrZSB0aGUgZW5kLXRvLWVuZCBwcm92aXNpb25pbmcNCiAgIG11 Y2ggbW9yZSBjb21wbGV4LiBJbiB0aGUgQUNUTiBhcmNoaXRlY3R1cmUsIG5ldyBmdW5jdGlvbnMg c3VjaCBhcw0KICAgdG9wb2xvZ3kgZGV0ZWN0aW9uIGFuZCB2aXJ0dWFsaXphdGlvbiwgYXV0by1y b3V0aW5nIGNhbGN1bGF0aW9uIGFyZQ0KICAgaW50cm9kdWNlZC4gV2l0aCB0aGVzZSBmdW5jdGlv bnMsIG9wZXJhdG9yIGNhbiBpbXByb3ZlIHRoZSB1c2VyDQogICBleHBlcmllbmNlcyBhbmQgbG93 ZXIgdGhlIE9QRVguDQoNCiAgIE9uIHRoZSBvdGhlciBoYW5kLCBvcGVyYXRvcnMgd2FudCB0byBv YnRhaW4gdGhlIGZsb3cgaW5mb3JtYXRpb24gYW5kDQogICByZWFsaXplIHRoZSBsb2FkIGJhbGFu Y2luZyB3aXRoaW4gTDMgUFROIG5ldHdvcmtzLA0KDQoNCiAgICAgICAgICAgICAgICAgICB8ICAg ICAgIEVuZC10by1FbmQgQ29ubmVjdGlvbiAgICAgfA0KICAgICAgICAgICAgICAgICAgIHw8LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQogICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0rICAgKy0tLS0tLS0tLS0rDQogICAgICAgICAgKy0tLS0tLS0tKyAgIHwgICAgICAg ICAgfCAgIHwgICAgICAgICAgfCAgICstLS0tLS0tLSsNCiAgICAgICAgICB8IFJhZGlvICB8ICAg fCBMYXllciAyICB8ICAgfCBMYXllciAzICB8ICAgfCBSYWRpbyAgfA0KICAgICAgICAgIHwgQWNj ZXNzIHw9PT18ICAgUFROICAgIHw9PT18ICAgUFROICAgIHw9PT18IENvcmUgICB8DQogICAgICAg ICAgfE5ldHdvcmtzfCAgIHwgTmV0d29ya3MgfCAgIHwgTmV0d29ya3MgfCAgIHxOZXR3b3Jrc3wN CiAgICAgICAgICArLS0tLS0tLS0rICAgfChWZW5kZXIgQSl8ICAgfChWZW5kZXIgQil8ICAgKy0t LS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIHwgICB8ICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0rDQoN CiAgICAgICAgICAgIEZpZ3VyZSAyIEVuZC10by1FbmQgQ29ubmVjdGlvbiBmb3IgTDImTDMgUFRO IE5ldHdvcmtzDQoNCjIuMy4gICBPcHRpbWl6aW5nIHRoZSBuZXR3b3JrIHJlc291cmNlcyB1dGls aXphdGlvbg0KDQogICBUaGUgcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrcyBjYW4gc3VwcG9ydCB2 YXJpb3VzIHBlcmZvcm1hbmNlcw0KICAgbW9uaXRvcmluZyBtYXRyaXgsIHN1Y2ggYXMgdHJhZmZp YyBmbG93IHN0YXRpc3RpY3MsIHBhY2tldCBkZWxheSwNCiAgIGRlbGF5IHZhcmlhdGlvbiwgdGhy b3VnaHB1dCBhbmQgcGFja2V0LWxvc3MgcmF0ZSwgZXRjLiBBbGwgdGhlc2UNCiAgIHBlcmZvcm1h bmNlIHBhcmFtZXRlcnMgY2FuIHN1cHBvcnQgdGhlIGVudGVycHJpc2UgY3VzdG9tZXJzIFNMQQ0K ICAgcmVxdWlyZW1lbnRzLiBUaHJvdWdoIHRoZSBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLCB0aGUg UFROIGNhbg0KDQoNCg0KQ2hlbmcsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEw LDIwMTUgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgxJbnRlcm5ldC1EcmFmdCAgICAgIFBU TiByZXF1aXJlbWVudHMgaW4gQUNUTiBhcmNoaXRlY3R1cmUgICAgICAgICBKdWx5IDIwMTQNCiAg IHJlYWxpemUgdGhlIHNlcnZpY2UgU0xBIG9wdGltaXphdGlvbiBhbmQgbmV0d29yayB0cmFmZmlj DQogICBvcHRpbWl6YXRpb24uIFNlZSBbQUNUTi1QRVJGXSBmb3IgcmVsYXRlZCBkaXNjdXNzaW9u Lg0KDQozLiBWaXJ0dWFsIE5ldHdvcmtzIE9wZXJhdGlvbnMgZm9yIFBhY2tldCBUcmFuc3BvcnQg TmV0d29ya3MNCg0KICAgRmlndXJlIDMgc2hvd3MgYW4gZXhhbXBsZSBvZiB2aXJ0dWFsIG5ldHdv cmsgb3BlcmF0aW9ucyBmb3IgcGFja2V0DQogICB0cmFuc3BvcnQgbmV0d29ya3MuIEluIG9yZGVy IHRvIHJlYWxpemUgZW5kLXRvLWVuZCBzZXJ2aWNlIHByb3Zpc2lvbiwNCiAgIHRoZSBBQ1ROIGFy Y2hpdGVjdHVyZSBbQUNUTi1GV0tdIHNob3VsZCBjb25zaWRlciBjb29yZGluYXRpb24gd2l0aA0K ICAgdHJhZGl0aW9uYWwgbmV0d29yayBtYW5hZ2VtZW50IHN5c3RlbXMuIEJ5IHRoZSBuZXR3b3Jr DQogICB2aXJ0dWFsaXphdGlvbiBhbmQgYWJzdHJhY3Rpb24sIHRoZSB0cmFkaXRpb25hbCBuZXR3 b3JrcyBjYW4gYmUNCiAgIGNvbnNpZGVyZWQgYXMgYSB2aXJ0dWFsIG5ldHdvcmsgZm9yIFZOQyBz ZXJ2aWNlIHByb3ZpZGVyLCB3aGljaCBjYW4NCiAgIGJlIHJlYWxpemVkIGJ5IG5ldHdvcmsgbWFu YWdlbWVudCBzeXN0ZW1zIHByb3ZpZGluZyBhbiBhYnN0cmFjdA0KICAgYWdlbnQgZm9yIFZOQywg b3IgdGhlIFZOQyBwcm92aWRpbmcgdHJhZGl0aW9uYWwgaW50ZXJmYWNlIGZvciBOTVMuDQoNCg0K ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgICAgICAgICAgICB8ICAgICAgICAgICAgIFZOQyBTZXJ2aWNlIFByb3ZpZGVyICAgICAgICB8 DQogICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgICAgICAgICAgICAgICAgLyAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgXA0K ICAgICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIFwNCiAg ICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgXA0KICAg ICAgICAgICAgICAgLyAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgXA0KICAg ICAgICAgICAgICAvICAgIHwgICAgICAgTk1TIEFic3RyYWN0IEFnZW50ICAgIHwgICAgIFwNCiAg ICAgICAgICstLS0tLS0tKyArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICstLS0tLS0t Kw0KICAgICAgICAgfEFjY2VzcyB8ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgfEFj Y2VzcyB8DQogICAgICAgICB8Q29udHJvbHwgfCBOZXR3b3JrIE1hbmFnZW1lbnQgU3lzdGVtcyAg fCB8Q29udHJvbHwNCiAgICAgICAgICstLS0tLS0tKyArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rICstLS0tLS0tKw0KICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICB8ICAg ICAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAg ICB8ICAgICAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgKy0tLS0tLS0rICArLS0tLS0tLSsg ICstLS0tLS0tKyAgKy0tLS0tLS0rICArLS0tLS0tLSsNCiAgICAgICAgIHwgQWNjZXNzfCAgfCBN ZXRybyB8ICB8IENvcmUgIHwgIHwgTWV0cm8gfCAgfCBBY2Nlc3N8DQogICArLS0rICB8IFBUTiAg IHwgIHwgUFROICAgfCAgfCBQVE4gICB8ICB8IFBUTiAgIHwgIHwgUFROICAgfCAgKy0tKw0KICAg fENFfD09fChWZW5kZXJ8PT18KFZlbmRlcnw9PXwoVmVuZGVyfD09fChWZW5kZXJ8PT18KFZlbmRl cnw9PXxDRXwNCiAgICstLSsgIHwgICAgQSkgfCAgfCAgICBCKSB8ICB8ICAgIEMpIHwgIHwgICAg RCkgfCAgfCAgICBFKSB8ICArLS0rDQogICAgICAgICArLS0tLS0tLSsgICstLS0tLS0tKyAgKy0t LS0tLS0rICArLS0tLS0tLSsgICstLS0tLS0tKw0KDQogICAgICAgIEZpZ3VyZSAzIEVuZC10by1F bmQgQ29ubmVjdGlvbiBpbiBNb2JpbGUgQmFja2hhdWwgTmV0d29ya3MNCg0KDQoNCjQuIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgcmFpc2VzIG5vIG5ldyBzZWN1 cml0eSBpc3N1ZXMuDQoNCg0KDQoNCkNoZW5nLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSmFu dWFyeSAxMCwyMDE1ICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDEludGVybmV0LURyYWZ0 ICAgICAgUFROIHJlcXVpcmVtZW50cyBpbiBBQ1ROIGFyY2hpdGVjdHVyZSAgICAgICAgSnVseSAy MDE0DQo1LiBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIE5vIG5ldyBJQU5BIGNvbnNpZGVyYXRp b25zIGFyZSByYWlzZWQgYnkgdGhpcyBkb2N1bWVudC4NCg0KNi4gUmVmZXJlbmNlcw0KDQo2LjEu ICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbQUNUTi1GV0tdICAgRGFuaWVsZSBDLiwg THV5dWFuIEZhbmcsIFlvbmcgTGVlIGFuZCBEaWVnbyBMb3BleiwNCiAgICAgICAgICAgICAgICAi RnJhbWV3b3JrIGZvciBBYnN0cmFjdGlvbiBhbmQgQ29udHJvbCBvZiBUcmFuc3BvcnQNCiAgICAg ICAgICAgICAgICBOZXR3b3JrcyIsIGRyYWZ0LWNlY2NhcmVsbGktYWN0bi1mcmFtZXdvcmstMDIu DQoNCiAgIFtBQ1ROLVBFUkZdIFl1bmJpbiBYdSwgV2VpcWlhbmcgQ2hlbmcsIEd1b3lpbmcgWmhh bmcgYW5kIEhhb21pYW4NCiAgICAgICAgICAgICBaaGVuZywgIlVzZSBDYXNlcyBhbmQgUmVxdWly ZW1lbnRzIG9mIER5bmFtaWMgU2VydmljZQ0KICAgICAgICAgICAgIENvbnRyb2wgYmFzZWQgb24g UGVyZm9ybWFuY2UgTW9uaXRvcmluZyBpbiBBQ1RODQogICAgICAgICAgICAgQXJjaGl0ZWN0dXJl IiwgZHJhZnQteHUtYWN0bi1wZXJmLWR5bmFtaWMtc2VydmljZS1jb250cm9sLQ0KICAgICAgICAg ICAgIDAxLg0KDQoNCg0KQXV0aG9ycydzIEFkZHJlc3MNCg0KICAgV2VpcWlhbmcgQ2hlbmcNCiAg IENoaW5hIE1vYmlsZSBDb21tdW5pY2F0aW9uIENvbXBhbnkNCiAgIE5vLjMyIFh1YW53dW1lbiBX ZXN0IFN0cmVldCwgWGljaGVuZyBEaXN0cmljdCwgQmVpamluZywgQ2hpbmENCiAgIEVtYWlsOmNo ZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tDQogICBZdW5iaW4gWHUNCiAgIENoaW5hIEFjYWRl bXkgb2YgVGVsZWNvbSBSZXNlYXJjaA0KICAgTk8uNTIgSHVheXVhbiBCZWlsdSwgSGFpZGlhbiBE aXN0cmljdCwgQmVpamluZywgQ2hpbmENCiAgIEVtYWlsOiB4dXl1bmJpbkBjYXRyLmNuDQogICBH dW95aW5nIFpoYW5nDQogICBDaGluYSBBY2FkZW15IG9mIFRlbGVjb20gUmVzZWFyY2gNCiAgIE5P LjUyIEh1YXl1YW4gQmVpbHUsIEhhaWRpYW4gRGlzdHJpY3QsIEJlaWppbmcsIENoaW5hDQogICBF bWFpbDogemhhbmdndW95aW5nQGNhdHIuY24NCg0KDQoNCg0KQ2hlbmcsIGV0IGFsLiAgICAgICAg ICAgICBFeHBpcmVzIEphbnVhcnkgMTAsMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgw= --_004_7AEB3D6833318045B4AE71C2C87E8E1729C005A2dfweml706chmchi_-- From nobody Thu Jul 10 19:16:40 2014 Return-Path: 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 396DE1A01BA for ; Thu, 10 Jul 2014 19:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 7bzmu2Q5V8W0 for ; Thu, 10 Jul 2014 19:16:35 -0700 (PDT) Received: from UTMC1101.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id D30B61B290F for ; Thu, 10 Jul 2014 19:16:33 -0700 (PDT) Received: from UTMC1101.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 78D9F785; Fri, 11 Jul 2014 11:16:32 +0900 (JST) Received: from UTMC1133 (unknown [10.5.16.198]) by UTMC1101.kddi.com (Postfix) with SMTP id 453A31210; Fri, 11 Jul 2014 11:16:32 +0900 (JST) Received: from UTMC1124.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 853C41BE6; Fri, 11 Jul 2014 11:16:26 +0900 (JST) Received: from LTMC1006.kddi.com (unknown [10.5.16.217]) by UTMC1124.kddi.com (Postfix) with ESMTP id 7057B1A09; Fri, 11 Jul 2014 11:16:26 +0900 (JST) Received: from LTMC1006.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id s6B2GQat031736; Fri, 11 Jul 2014 11:16:26 +0900 Received: from LTMC1006.kddi.com.mid_30820178 (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id s6B2FfjK031114; Fri, 11 Jul 2014 11:15:42 +0900 Received: from KDDI1202PC0730 ([10.200.121.252] [10.200.121.252]) by post-zip.kddi.com with ESMTPA; Fri, 11 Jul 2014 11:15:40 +0900 From: "Kenji Kumaki" To: "'Dhruv Dhody'" , References: <23CE718903A838468A8B325B80962F9B7556E858@szxeml556-mbs.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B7556E858@szxeml556-mbs.china.huawei.com> Date: Fri, 11 Jul 2014 11:15:40 +0900 Message-Id: <001101cf9cae$02b32090$081961b0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH8QtipobbuLqUMAWMKwLNeZYV0+ps/kuCg Content-Language: ja X-SA-MID: 30820178 X-WAuditID: 1407111116260000310953 X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/actn/xD0kPqfXNTkxKhM9eEDDtuUDJ7U Cc: actn@ietf.org Subject: Re: [Actn] Regarding draft-kumaki-actn-multitenant-vno X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 02:16:38 -0000 Hi Dhruv, Thanks for your comments and sorry for the delayed response. See in line. Thanks, Kenji > -----Original Message----- > From: Dhruv Dhody [mailto:dhruv.dhody@huawei.com] > Sent: Tuesday, June 17, 2014 1:34 PM > To: draft-kumaki-actn-multitenant-vno@tools.ietf.org > Cc: actn@ietf.org > Subject: [Actn] Regarding draft-kumaki-actn-multitenant-vno > > Dear Authors, > > Thanks for this document which describe the multi-tenant virtual network operations use case of ACTN. > > IMO this is especially harder in case of multi-domain core transport network and a small section maybe added for this. > I'd like to clarify the word 'domain'. Do you use it from routing perspective? If yes, normally, carrier networks consist of multiple domains. I'm not sure what you want to say here? > Further comments/suggestions for your consideration. > > >Abstract > > > > This document provides a use case that addresses the need for > > facilitating virtual network operation: creation and operation of > > multi-tenant virtual networks that use the common core network > > resources. This will accelerate a rapid service deployment of new > > services, including more dynamic and elastic services, and improve > > overall network operations and scaling of existing services. This > > use case addresses the aforementioned needs within a single operator > > network. > > You mention 'common core network' and 'single operator network'. It may be useful to clarify that they may be multi-domain, > multi-subnet, multi- technology etc. > Actually, 'common core network' means that we provide multiple services on the single core network, and it is a multi-domain network. > >1. Introduction > > > > This document provides a use case that addresses the need for > > facilitating virtual network operation: creation and operation of > > multi-tenant virtual networks that use the common core network > > resources. This will accelerate a rapid service deployment of new > > services, including more dynamic and elastic services, and improve > > overall network operations and scaling of existing services. This > > use case supports Abstraction and Control of Transport Networks > > (ACTN). The aim of ACTN is to facilitate virtual network operation, > > creation of a virtualized environment allowing operators to view and > > control multi-subnet multi-technology networks into a single > > virtualized network. Related documents are: > > [I-D.leeking-actn-problem-statement] and > > [I-D.ceccarelli-actn-framework] which provide detailed information > > regarding this work. > > It should be clarified that the multi-tenant VN using ACTN framework improves network operations and scaling, the first > few lines give an impression that just creating VN via existing means would achieve that. > > Also I was thinking, if there is a need to describe multi-tenant or virtual network from ACTN point of view. > OK. I'll reflect on your comments. > >3. Motivation > > The characteristics of the multiple services network are as follows: > > > > Can the current state of the multiple services network described first, followed by current issues and which of those > issues do ACTN tackles? IMO this would read better. > OK. I'll reflect on your comments. > >4.1. Service Consolidation > > > > Multi-tenant virtual network operation should support different > > services as the tenants that share the common core transport network > > resources. Therefore, it is important to understand the type of > > various services and its service requirement. > > > >4.2. VPN Service Consolidation > > > > Network providers have many different service networks such as VPNs > > of various types and different QoS requirements. Within VPNs, there > > are several QoS levels. Some VPN is best-effort VPN while other VPNs > > require a strict QoS such as bandwidth guarantee and latency. > > Therefore, multi-level VPNs should be supported in multi-tenant > > virtual network consolidation. > > But how is this consolidation of service? You also mention network consolidation... can this be clarified? > > Or do you think this would be similar to cargo consolidation where smaller shipments are assembled and shipped together? > We have two approaches for network consolidation. One is the horizontal network consolidation that we create a multiple domain network(multi-area/multi-domain network). Here is the conventional network architecture. The other is the vertical network consolidation that we create a network slice vertically on the common core network. Here, our approach shows the latter. > >4.3. Network Wholesale Service > > > > Network providers want to provide a network resource (i.e. a network > > slice) to ISPs. In this case, the network provider must guarantee > > the SLA to each ISP. There may be different level of SLA as well as > > different level of virtual network granularity for each ISP. The ISP > > should be given its virtual network(s) as well as an independent > > domain control of allocated virtual network(s). > > I think this is an important point, and we should highlight that this a bit more as a clear objective of ACTN and how > this cannot be done using existing mechanism. > In case that we provide a network to an ISP, which means the ISP has a different AS and basically ISP does not want to change own network policy, we can deploy carriers' carriers in RFC4364. However, ISPs need to change their network policy and run LDP at an edge router although they deploy just IP. Additionally, they (network architects at ISP) need to transfer MPLS knowledge to operators. > >5. Multi-tenant Virtual Network Operation Coordination > > > > The following Figure 2 depicts a functional control architecture that > > shows the need to support virtual networks to a number of different > > service networks that share the common core network resources. > > > > > > > > +-----------------+ > > | Multi-tenant | > > | VN Coordination | > > +-----------+ +-----------------+ +-----------+ > > | Service A |-+ | | | | Service A |-+ > > | Control |B|-+ | | | | Control |B|-+ > > +-----------+ |C|---------| | |---------+-----------+ |C| > > +-----------+ | | +-----------+ | > > +-----------+ +---------------+ +-----------+ > > |Core Transport | > > /------\ |Network Control| /------\ > > // \\ +---------------+ // \\ > > | Service A | | | Service A | > > \\ // ---------- /\ // > > ------ \ //// \\\\ / ------ > > /------\ \|| ||/ /------\ > > // \\ | Core Transport | // \\ > > | Service B |----| |----| Service B | > > \\ // || Network || \\ // > > \------/ \\\\ //// \------/ > > /------\ / ---------- \ /------\ > > // \\ / \ // \\ > > | Service C | \| Service C | > > \\ // \\ // > > ------ ------ > > > > > > Is there a reason for 2 sets of service control(ers) in this figure? > I have no particular reason for it. > > > > > 7. As a number of services carried on the common transport network > > sharing a common network resource, operational independence for > > each service has to be guaranteed as if each service owns its > > dedicated resources. > > > > Shouldn't this be 'each service owns its dedicated virtual resources.'? > Actually, I think each service should have the dedicated virtual resources. Because we need to share the common network resources from operational perspective. > Thanks Again! > > Regards, > Dhruv > > > --------------------------------------------------------------- > Dhruv Dhody > System Architect, > Huawei Technologies India Pvt. Ltd., > Banagalore > Mobile: +91-9845062422 > > _______________________________________________ > ACTN mailing list > ACTN@ietf.org > https://www.ietf.org/mailman/listinfo/actn From nobody Thu Jul 10 20:16:14 2014 Return-Path: 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 A1E6C1A01A0 for ; Thu, 10 Jul 2014 20:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 auvxpd-SzDEg for ; Thu, 10 Jul 2014 20:16:10 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBE31A0195 for ; Thu, 10 Jul 2014 20:16:10 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id r10so122494igi.4 for ; Thu, 10 Jul 2014 20:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aAzNFRtEkATqWM2ugTSBfdiPrDakze+sOV1PKjjN1cM=; b=gzcWSYIYJD+2y2WLvDxKUK0q8BgjKLelSt4f/JCiqcuN+39C+aZIQVr9j68MRk54rk 6DJEiDdtg+/VY+KNq8LQdpheMhPbRCWXQwoWvRC0j/sSK3RKioIIBl8LajiPigv9Bijd HRFb/c0fIklh09uEa68sFdH2jgBZrvq3dQiOugcyCFowoYTxpiRE3tr+ssRUrwY8oZXV ZXRJZ5i9IhG42R1KvGxHluGdDDhdhmzZtBboLLEr7KP3DIAyW2fs6kSiXYPz7XCnbLv1 4uo8NRqcxD+rPX5BRMtnuQjY242eWG8ek8AmaBXmHDi4CdNizG2fq+JKPfLYPs+FOlyV LXQA== MIME-Version: 1.0 X-Received: by 10.42.93.84 with SMTP id w20mr1484727icm.49.1405048569747; Thu, 10 Jul 2014 20:16:09 -0700 (PDT) Received: by 10.50.132.67 with HTTP; Thu, 10 Jul 2014 20:16:09 -0700 (PDT) In-Reply-To: <001101cf9cae$02b32090$081961b0$@kddi.com> References: <23CE718903A838468A8B325B80962F9B7556E858@szxeml556-mbs.china.huawei.com> <001101cf9cae$02b32090$081961b0$@kddi.com> Date: Fri, 11 Jul 2014 08:46:09 +0530 Message-ID: From: Dhruv Dhody To: Kenji Kumaki Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/wQ-fjNNKoqdSYHrYVCXYVaJcegQ Cc: draft-kumaki-actn-multitenant-vno@tools.ietf.org, "actn@ietf.org" , Dhruv Dhody Subject: Re: [Actn] Regarding draft-kumaki-actn-multitenant-vno X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 03:16:12 -0000 Hi Kenji, Thanks for your reply, see inline.. (snip) >> >> IMO this is especially harder in case of multi-domain core transport > network and a small section maybe added for this. >> > > I'd like to clarify the word 'domain'. Do you use it from routing > perspective? > If yes, normally, carrier networks consist of multiple domains. > I'm not sure what you want to say here? IMO particular attention needs to be paid to the multi-domain case, where ACTN can facilitate virtual network operation via the creation of a single virtualized network and these domains may be technology, administrative or vendor specific (vendor islands). A few more words on these lines in the introduction can be added. > >> Further comments/suggestions for your consideration. >> >> >Abstract >> > >> > This document provides a use case that addresses the need for >> > facilitating virtual network operation: creation and operation of >> > multi-tenant virtual networks that use the common core network >> > resources. This will accelerate a rapid service deployment of new >> > services, including more dynamic and elastic services, and improve >> > overall network operations and scaling of existing services. This >> > use case addresses the aforementioned needs within a single operator >> > network. >> >> You mention 'common core network' and 'single operator network'. It may be > useful to clarify that they may be multi-domain, >> multi-subnet, multi- technology etc. >> > > Actually, 'common core network' means that we provide multiple services on > the single core network, and it is a multi-domain network. as noted above, current text does not mention multi-domain at all, and i feel a few lines can be useful to clarify it. (snip) >> >4.1. Service Consolidation >> > >> > Multi-tenant virtual network operation should support different >> > services as the tenants that share the common core transport network >> > resources. Therefore, it is important to understand the type of >> > various services and its service requirement. >> > >> >4.2. VPN Service Consolidation >> > >> > Network providers have many different service networks such as VPNs >> > of various types and different QoS requirements. Within VPNs, there >> > are several QoS levels. Some VPN is best-effort VPN while other VPNs >> > require a strict QoS such as bandwidth guarantee and latency. >> > Therefore, multi-level VPNs should be supported in multi-tenant >> > virtual network consolidation. >> >> But how is this consolidation of service? You also mention network > consolidation... can this be clarified? >> >> Or do you think this would be similar to cargo consolidation where smaller > shipments are assembled and shipped together? >> > > We have two approaches for network consolidation. > One is the horizontal network consolidation that we create a multiple domain > network(multi-area/multi-domain network). Here is the conventional network > architecture. The other is the vertical network consolidation that we create > a network slice vertically on the common core network. > > Here, our approach shows the latter. > So if i understand you correctly, this is like Vertical integration (or consolidation) in business sense, as some very different services are consolidated and offered together? >> >4.3. Network Wholesale Service >> > >> > Network providers want to provide a network resource (i.e. a network >> > slice) to ISPs. In this case, the network provider must guarantee >> > the SLA to each ISP. There may be different level of SLA as well as >> > different level of virtual network granularity for each ISP. The ISP >> > should be given its virtual network(s) as well as an independent >> > domain control of allocated virtual network(s). >> >> I think this is an important point, and we should highlight that this a > bit more as a clear objective of ACTN and how >> this cannot be done using existing mechanism. >> > > In case that we provide a network to an ISP, which means the ISP has a > different AS and basically ISP does not want to change own network policy, > we can deploy carriers' carriers in RFC4364. However, ISPs need to change > their network policy and run LDP at an edge router although they deploy just > IP. Additionally, they (network architects at ISP) need to transfer MPLS > knowledge to operators. Agree. > >> >5. Multi-tenant Virtual Network Operation Coordination >> > >> > The following Figure 2 depicts a functional control architecture that >> > shows the need to support virtual networks to a number of different >> > service networks that share the common core network resources. >> > >> > >> > >> > +-----------------+ >> > | Multi-tenant | >> > | VN Coordination | >> > +-----------+ +-----------------+ +-----------+ >> > | Service A |-+ | | | | Service A |-+ >> > | Control |B|-+ | | | | Control |B|-+ >> > +-----------+ |C|---------| | |---------+-----------+ |C| >> > +-----------+ | | +-----------+ | >> > +-----------+ +---------------+ +-----------+ >> > |Core Transport | >> > /------\ |Network Control| /------\ >> > // \\ +---------------+ // \\ >> > | Service A | | | Service A | >> > \\ // ---------- /\ // >> > ------ \ //// \\\\ / ------ >> > /------\ \|| ||/ /------\ >> > // \\ | Core Transport | // \\ >> > | Service B |----| |----| Service B | >> > \\ // || Network || \\ // >> > \------/ \\\\ //// \------/ >> > /------\ / ---------- \ /------\ >> > // \\ / \ // \\ >> > | Service C | \| Service C | >> > \\ // \\ // >> > ------ ------ >> > >> > >> >> Is there a reason for 2 sets of service control(ers) in this figure? >> > > I have no particular reason for it. Then i would suggest we make it just one. :) > >> >> > >> > 7. As a number of services carried on the common transport network >> > sharing a common network resource, operational independence for >> > each service has to be guaranteed as if each service owns its >> > dedicated resources. >> > >> >> Shouldn't this be 'each service owns its dedicated virtual resources.'? >> > > Actually, I think each service should have the dedicated virtual resources. > Because we need to share the common network resources from operational > perspective. A rewording to "...each service owns its dedicated virtual resources" would be better then. > >> Thanks Again! >> >> Regards, >> Dhruv >> >> >> --------------------------------------------------------------- >> Dhruv Dhody >> System Architect, >> Huawei Technologies India Pvt. Ltd., >> Banagalore >> Mobile: +91-9845062422 >> >> _______________________________________________ >> ACTN mailing list >> ACTN@ietf.org >> https://www.ietf.org/mailman/listinfo/actn > > _______________________________________________ > ACTN mailing list > ACTN@ietf.org > https://www.ietf.org/mailman/listinfo/actn From nobody Thu Jul 10 21:25:00 2014 Return-Path: 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 2DE061A0A9B for ; Thu, 10 Jul 2014 21:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 lzKzu2c9wnfn for ; Thu, 10 Jul 2014 21:24:56 -0700 (PDT) Received: from UTMC1101.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 00EB41A02E6 for ; Thu, 10 Jul 2014 21:24:55 -0700 (PDT) Received: from UTMC1101.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id A50CF88C; Fri, 11 Jul 2014 13:24:54 +0900 (JST) Received: from UTMC1131 (unknown [10.5.16.192]) by UTMC1101.kddi.com (Postfix) with SMTP id 4B5AD524; Fri, 11 Jul 2014 13:24:54 +0900 (JST) Received: from UTMC1122.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 44F7C517B; Fri, 11 Jul 2014 13:24:47 +0900 (JST) Received: from LTMC1005.kddi.com (unknown [10.5.16.216]) by UTMC1122.kddi.com (Postfix) with ESMTP id 280C052A4; Fri, 11 Jul 2014 13:24:47 +0900 (JST) Received: from LTMC1005.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id s6B4OkvY031217; Fri, 11 Jul 2014 13:24:46 +0900 Received: from LTMC1005.kddi.com.mid_31086710 (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id s6B4NCrt029334; Fri, 11 Jul 2014 13:23:12 +0900 Received: from KDDI1202PC0730 ([10.200.121.252] [10.200.121.252]) by post-zip.kddi.com with ESMTPA; Fri, 11 Jul 2014 13:23:12 +0900 From: "Kenji Kumaki" To: "'Dhruv Dhody'" References: <23CE718903A838468A8B325B80962F9B7556E858@szxeml556-mbs.china.huawei.com> <001101cf9cae$02b32090$081961b0$@kddi.com> In-Reply-To: Date: Fri, 11 Jul 2014 13:23:12 +0900 Message-Id: <003201cf9cbf$d3a3d5d0$7aeb8170$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH8QtipobbuLqUMAWMKwLNeZYV0+gF/8cggAeirSWSbJagu4A== Content-Language: ja X-SA-MID: 31086710 X-WAuditID: 1407111324470050126798 X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/actn/xFM8f9eA18DX0jx2ik3b9h7LZFk Cc: draft-kumaki-actn-multitenant-vno@tools.ietf.org, actn@ietf.org, 'Dhruv Dhody' Subject: Re: [Actn] Regarding draft-kumaki-actn-multitenant-vno X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 04:24:58 -0000 Hi Dhruv, See in line. Thanks, Kenji > >> IMO this is especially harder in case of multi-domain core = transport > > network and a small section maybe added for this. > >> > > > > I'd like to clarify the word 'domain'. Do you use it from routing > > perspective? > > If yes, normally, carrier networks consist of multiple domains. > > I'm not sure what you want to say here? >=20 > IMO particular attention needs to be paid to the multi-domain case, = where ACTN can facilitate virtual network operation > via the creation of a single virtualized network and these domains may = be technology, administrative or vendor specific > (vendor islands). A few more words on these lines in the introduction = can be added. >=20 Understand. > > > >> Further comments/suggestions for your consideration. > >> > >> >Abstract > >> > > >> > This document provides a use case that addresses the need for > >> > facilitating virtual network operation: creation and operation = of > >> > multi-tenant virtual networks that use the common core network > >> > resources. This will accelerate a rapid service deployment of = new > >> > services, including more dynamic and elastic services, and = improve > >> > overall network operations and scaling of existing services. = This > >> > use case addresses the aforementioned needs within a single = operator > >> > network. > >> > >> You mention 'common core network' and 'single operator network'. It > >> may be > > useful to clarify that they may be multi-domain, > >> multi-subnet, multi- technology etc. > >> > > > > Actually, 'common core network' means that we provide multiple > > services on the single core network, and it is a multi-domain = network. >=20 > as noted above, current text does not mention multi-domain at all, and = i feel a few lines can be useful to clarify it. >=20 I'll clarify it. > >> >4.1. Service Consolidation > >> > > >> > Multi-tenant virtual network operation should support different > >> > services as the tenants that share the common core transport = network > >> > resources. Therefore, it is important to understand the type = of > >> > various services and its service requirement. > >> > > >> >4.2. VPN Service Consolidation > >> > > >> > Network providers have many different service networks such as = VPNs > >> > of various types and different QoS requirements. Within VPNs, = there > >> > are several QoS levels. Some VPN is best-effort VPN while = other VPNs > >> > require a strict QoS such as bandwidth guarantee and latency. > >> > Therefore, multi-level VPNs should be supported in multi-tenant > >> > virtual network consolidation. > >> > >> But how is this consolidation of service? You also mention network > > consolidation... can this be clarified? > >> > >> Or do you think this would be similar to cargo consolidation where > >> smaller > > shipments are assembled and shipped together? > >> > > > > We have two approaches for network consolidation. > > One is the horizontal network consolidation that we create a = multiple > > domain network(multi-area/multi-domain network). Here is the > > conventional network architecture. The other is the vertical network > > consolidation that we create a network slice vertically on the = common core network. > > > > Here, our approach shows the latter. > > >=20 > So if i understand you correctly, this is like Vertical integration = (or consolidation) in business sense, as some very > different services are consolidated and offered together? >=20 Yes, our approach is the vertical consolidation. I think it's not = business sense but technical one, as the horizontal consolidation has = some issues for minimizing an impact on routing/signaling process = failures. > >> >4.3. Network Wholesale Service > >> > > >> > Network providers want to provide a network resource (i.e. a = network > >> > slice) to ISPs. In this case, the network provider must = guarantee > >> > the SLA to each ISP. There may be different level of SLA as = well as > >> > different level of virtual network granularity for each ISP. = The ISP > >> > should be given its virtual network(s) as well as an = independent > >> > domain control of allocated virtual network(s). > >> > >> I think this is an important point, and we should highlight that = this > >> a > > bit more as a clear objective of ACTN and how > >> this cannot be done using existing mechanism. > >> > > > > In case that we provide a network to an ISP, which means the ISP has = a > > different AS and basically ISP does not want to change own network > > policy, we can deploy carriers' carriers in RFC4364. However, ISPs > > need to change their network policy and run LDP at an edge router > > although they deploy just IP. Additionally, they (network architects > > at ISP) need to transfer MPLS knowledge to operators. >=20 > Agree. >=20 > > > >> >5. Multi-tenant Virtual Network Operation Coordination > >> > > >> > The following Figure 2 depicts a functional control = architecture that > >> > shows the need to support virtual networks to a number of = different > >> > service networks that share the common core network resources. > >> > > >> > > >> > > >> > +-----------------+ > >> > | Multi-tenant | > >> > | VN Coordination | > >> > +-----------+ +-----------------+ +-----------+ > >> > | Service A |-+ | | | | Service A |-+ > >> > | Control |B|-+ | | | | Control = |B|-+ > >> > +-----------+ |C|---------| | |---------+-----------+ = |C| > >> > +-----------+ | | +-----------+ = | > >> > +-----------+ +---------------+ = +-----------+ > >> > |Core Transport | > >> > /------\ |Network Control| /------\ > >> > // \\ +---------------+ // \\ > >> > | Service A | | | Service A | > >> > \\ // ---------- /\ // > >> > ------ \ //// \\\\ / ------ > >> > /------\ \|| ||/ /------\ > >> > // \\ | Core Transport | // \\ > >> > | Service B |----| |----| Service B | > >> > \\ // || Network || \\ // > >> > \------/ \\\\ //// \------/ > >> > /------\ / ---------- \ /------\ > >> > // \\ / \ // \\ > >> > | Service C | \| Service C | > >> > \\ // \\ // > >> > ------ ------ > >> > > >> > > >> > >> Is there a reason for 2 sets of service control(ers) in this = figure? > >> > > > > I have no particular reason for it. >=20 > Then i would suggest we make it just one. :) >=20 OK. > > > >> > >> > > >> > 7. As a number of services carried on the common transport = network > >> > sharing a common network resource, operational independence = for > >> > each service has to be guaranteed as if each service owns = its > >> > dedicated resources. > >> > > >> > >> Shouldn't this be 'each service owns its dedicated virtual = resources.'? > >> > > > > Actually, I think each service should have the dedicated virtual = resources. > > Because we need to share the common network resources from = operational > > perspective. >=20 > A rewording to "...each service owns its dedicated virtual resources" > would be better then. >=20 OK. > > > >> Thanks Again! > >> > >> Regards, > >> Dhruv > >> > >> > >> --------------------------------------------------------------- > >> Dhruv Dhody > >> System Architect, > >> Huawei Technologies India Pvt. Ltd., > >> Banagalore > >> Mobile: +91-9845062422 > >> > >> _______________________________________________ > >> ACTN mailing list > >> ACTN@ietf.org > >> https://www.ietf.org/mailman/listinfo/actn > > > > _______________________________________________ > > ACTN mailing list > > ACTN@ietf.org > > https://www.ietf.org/mailman/listinfo/actn From nobody Wed Jul 16 13:13:46 2014 Return-Path: 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 8E68A1A0047 for ; Wed, 16 Jul 2014 13:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Gi07OG1vdA7C for ; Wed, 16 Jul 2014 13:13:39 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860CA1A005D for ; Wed, 16 Jul 2014 13:13:38 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s6GKALKI024508 for ; Wed, 16 Jul 2014 16:13:37 -0400 Received: from mdwvexchht01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 1n5yp1g33q-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 16 Jul 2014 16:13:37 -0400 Received: from MDWVEXCHHT02.ciena.com (10.4.156.176) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 16 Jul 2014 16:13:36 -0400 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by MDWVEXCHHT02.ciena.com (10.4.156.176) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 16 Jul 2014 16:09:42 -0400 Received: from ONWVEXCHMB02.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Wed, 16 Jul 2014 16:13:35 -0400 From: "Shew, Stephen" To: "actn@ietf.org" Date: Wed, 16 Jul 2014 16:13:35 -0400 Thread-Topic: Problem Statement Update Thread-Index: Ac9/rVteBL9+A32ETXqAHSkK2/3uwQhgFs4A Message-ID: <510C3D5C5DFBCB46AE189D936C1DD605A73B1F1EC7@ONWVEXCHMB02.ciena.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729BF2015@dfweml706-chm.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BF2015@dfweml706-chm.china.huawei.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20822.002 X-TM-AS-Result: No--18.302400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_510C3D5C5DFBCB46AE189D936C1DD605A73B1F1EC7ONWVEXCHMB02c_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-16_07:2014-07-16,2014-07-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407160223 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/FtdoNZfWwetj4Vs1AzEK7UYOznA Subject: Re: [Actn] Problem Statement Update X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 20:13:43 -0000 --_000_510C3D5C5DFBCB46AE189D936C1DD605A73B1F1EC7ONWVEXCHMB02c_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll be at IETF90, but may not make the BOF on Thursday so I've captured so= me comments on the ACTN problem statement below. 1. P.5 "Multi-tenant" - it's not clear to me what this means. Does it= mean resources at a common site that are virtualized? 2. P.7 "2.1 Virtual Private Networks". For layer 1 networks, I did po= int out in the IETF88 timeframe, that ITU-T Recommendations Y.1312 and Y.13= 13 be examined. They are referenced in RFC4847. What is significant about = those 2 Recommendations is that they define VPNs in both the user plane (re= sources) and the control plane. Much of what is described is directly appl= icable to the ACTN problem statement. For example, how a VPN user is able t= o create/release connections in a VPN that has dedicated resources. I sugg= est that much of the terminology and concepts be referenced in ACTN as it c= omes from an SDO that standardizes much of the transport technologies refer= red to in the I-D. 3. P.10 "3.2 Network Resource Recursiveness". I think recursion is a = powerful concept and recursion of network resources is well described in IT= U-T G.800. This section needs to be more precise in that it is also referr= ing to recursion of the control of resources, not just the resources themse= lves. In that regard, the ONF SDN Architecture describes SDN Controller hie= rarchy which is performing this recursion of control. The I-D should add a= reference to https://www.opennetworking.org/images/stories/downloads/sdn-r= esources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf 4. P. 13 "4.3 Common Data Models". The idea of a common data model is = helpful for many reasons. I suggest that the requirement be modified to sa= y "common information model" as this is a representation in terms of the pr= operties of thing and the relationship between those things. Data models c= an then be developed from the common information model with specific encodi= ngs at interfaces. I suggest that the I-D refer to TMF TR215 and that ACTN= interact with the ONF as they consider a common information model. Stephen From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: 04 June, 2014 00:28 To: actn@ietf.org Subject: [Actn] Problem Statement Update We have updated the problem statement for ACTN. Major changes are: - Luis (Telefonica) has been added as a co-author. He provided man= y valuable text that enriched the draft. - Added some text on virtual network operational aspect. Any comments are welcomed. Young & Dan --_000_510C3D5C5DFBCB46AE189D936C1DD605A73B1F1EC7ONWVEXCHMB02c_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll be at IETF90= , but may not make the BOF on Thursday so I’ve captured some comments= on the ACTN problem statement below.

 

1.    &= nbsp; P.5 “Multi-tenant” – itR= 17;s not clear to me what this means.  Does it mean resources at a com= mon site that are virtualized?

2.      P.7 “2.1 Vir= tual Private Networks”.  For layer 1 networks, I did point out i= n the IETF88 timeframe, that ITU-T Recommendations Y.1312 and Y.1313 be exa= mined. They are referenced in RFC4847.  What is significant about thos= e 2 Recommendations is that they define VPNs in both the user plane (resour= ces) and the control plane.  Much of what is described is directly app= licable to the ACTN problem statement. For example, how a VPN user is able = to create/release connections in a VPN that has dedicated resources.  = I suggest that much of the terminology and concepts be referenced in ACTN a= s it comes from an SDO that standardizes much of the transport technologies= referred to in the I-D.

3. = ;     P.10 “3.2 Network R= esource Recursiveness”.  I think recursion is a powerful concept= and recursion of network resources is well described in ITU-T G.800. = This section needs to be more precise in that it is also referring to recu= rsion of the control of resources, not just the resources themselves. In th= at regard, the ONF SDN Architecture describes SDN Controller hierarchy whic= h is performing this recursion of control.  The I-D should add a refer= ence to https://www.o= pennetworking.org/images/stories/downloads/sdn-resources/technical-reports/= TR_SDN_ARCH_1.0_06062014.pdf

<= span style=3D'mso-list:Ignore'>4.P. 13 “4.3 = Common Data Models”. The idea of a common data model is helpful for m= any reasons.  I suggest that the requirement be modified to say “= ;common information model” as this is a representation in terms of th= e properties of thing and the relationship between those things.  Data= models can then be developed from the common information model with specif= ic encodings at interfaces.  I suggest that the I-D refer to TMF TR215= and that ACTN interact with the ONF as they consider a common information = model.

 

Stephen

 

From: ACTN [mailto:actn-bounces@ietf.= org] On Behalf Of Leeyoung
Sent: 04 June, 2014 00:28
To: actn@ietf.org
Subject: [Actn] Problem Statement Update

 

<= p class=3DMsoNormal>We have updated the problem statement for ACTN.

 

Majo= r changes are:

 

-        &= nbsp; Luis (Telefonica) has been added as a co-auth= or. He provided many valuable text that enriched the draft.

=

-       &nb= sp;  Added some text on virtual network operat= ional aspect.

 

Any comments are welcomed.

 

Young & Dan

= --_000_510C3D5C5DFBCB46AE189D936C1DD605A73B1F1EC7ONWVEXCHMB02c_-- From nobody Wed Jul 23 07:02:43 2014 Return-Path: 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 356F81B2865 for ; Wed, 23 Jul 2014 07:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 uEnir1Ze-_rz for ; Wed, 23 Jul 2014 07:02:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2651B285C for ; Wed, 23 Jul 2014 07:02:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN29404; Wed, 23 Jul 2014 14:02:35 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 15:02:33 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 07:02:32 -0700 From: Leeyoung To: "actn@ietf.org" Thread-Topic: Agenda for ACTN BoF, 1-3pm, July 24 @ Tudor 7/8 Thread-Index: Ac+mfrtglZE5tkGRR42Rj2sm6PXnSw== Date: Wed, 23 Jul 2014 14:02:31 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C05DBE@dfweml706-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.147] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C05DBEdfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/nsrk7nZWXQOhc04YcK71O1kPS-g Cc: "d.king@lancaster.ac.uk" Subject: [Actn] Agenda for ACTN BoF, 1-3pm, July 24 @ Tudor 7/8 X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:02:40 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C05DBEdfweml706chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Final agenda for ACTN BOF (1-3pm, July 24 @ Tudor 7/8) has been published t= his week as follow: * Introduction (10 min) * Multi Tenant VNO use case (Takuya Miyasaka, KDDI) (15 min) - https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/ * Data Center Operator: Multi-domain Data Center Interconnect (Luyua= n Fang, Microsoft) (15 min) - https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ * Transport Network Operators: On-demand E2E Connectivity Services in Multiple Vendor Domain Transport Networks/Virtual Network Operation for = Multiple Domain in a Single Operator Network (Hosong Lee, Korea Telecom, Oscar Gonsalez, Telefonica) (20 min) - https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-= vendor-domains/ - https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ * Mobile Network Operators: Mobile Backhaul Packet Transport Networks= /Mobile Virtual Network Operation for Multiple Domains in a Single Operator= Network (Weiqiang Cheng, China Mobile, Rod Hwang, SK Telecom) (20 min) - https://datatracker.ietf.org/doc/draft-cheng-actn-ptn-requirements/ - https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ * Research: Toward Ultimate Convergence of All Networks (Dan King, Un= iversity of Lancaster) (5 min) * Open Discussion (25 min) * Summary & Next Steps (10 min) Hope to see you all who are in Toronto this week. Best Regards, Young & Dan --_000_7AEB3D6833318045B4AE71C2C87E8E1729C05DBEdfweml706chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Final agenda for ACTN BOF (1-3pm, July 24 @ Tudor 7/= 8) has been published this week as follow:

 

•       Introduction (10 min)

•       Multi Tenant VNO use case (Takuya Miy= asaka, KDDI) (15 min)

–      https://datatracker.ietf.org/doc/draft-= kumaki-actn-multitenant-vno/

•       Data Center Operator: Multi-domain Da= ta Center Interconnect  (Luyuan Fang, Microsoft) (15 min)

–      https://datatracker.ietf.org/doc/draft-fa= ng-actn-multidomain-dci/

•       Transport Network Operators: On-deman= d E2E Connectivity Services
in Multiple Vendor Domain Transport Networks/Virtual Network Operation for = Multiple Domain in a Single Operator Network
(Hosong Lee, Korea Telecom, Oscar Gonsalez, Telefonica) (20 min)=

–      https://datatracker.iet= f.org/doc/draft-klee-actn-connectivity-multi-vendor-domains/

–      https://datatracker.ietf.org/doc/draft-= lopez-actn-vno-multidomains/

•       Mobile Network Operators: Mobile Back= haul Packet Transport Networks/Mobile Virtual Network Operation for Multipl= e Domains in a Single Operator Network (Weiqiang  Cheng, China Mobile,= Rod Hwang, SK Telecom) (20 min)

–      https://datatracker.ietf.org/doc/draft-= cheng-actn-ptn-requirements/

–      https://datatracker.ietf.org/doc/draft-= shin-actn-mvno-multi-domain/

•       Research: Toward Ultimate Convergence= of All Networks (Dan King, University of Lancaster) (5 min)

•       Open Discussion (25 min)

•       Summary & Next Steps (10 min)

 

Hope to see you all who are in Toronto this week.

 

Best Regards,

Young & Dan

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C05DBEdfweml706chmchi_-- From nobody Wed Jul 23 07:52:49 2014 Return-Path: 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 9E6281A00F8 for ; Wed, 23 Jul 2014 07:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 xPmVqW4pUiIz for ; Wed, 23 Jul 2014 07:52:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6185F1ABB2E for ; Wed, 23 Jul 2014 07:52:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKL39253; Wed, 23 Jul 2014 14:52:35 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 15:52:33 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 07:52:31 -0700 From: Leeyoung To: "Shew, Stephen" , "actn@ietf.org" Thread-Topic: Problem Statement Update Thread-Index: Ac9/rVteBL9+A32ETXqAHSkK2/3uwQhgFs4AAVWFszA= Date: Wed, 23 Jul 2014 14:52:31 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C05E89@dfweml706-chm.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729BF2015@dfweml706-chm.china.huawei.com> <510C3D5C5DFBCB46AE189D936C1DD605A73B1F1EC7@ONWVEXCHMB02.ciena.com> In-Reply-To: <510C3D5C5DFBCB46AE189D936C1DD605A73B1F1EC7@ONWVEXCHMB02.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.147] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C05E89dfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/ODItmJB2mQV-hI15UhsHancooHs Subject: Re: [Actn] Problem Statement Update X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:52:40 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C05E89dfweml706chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephen, Sorry for my very late response. When I saw you today in Toronto, this remi= nded me of your email you posted last week. Here's my response to you. Please see inline. Thanks, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen Sent: Wednesday, July 16, 2014 3:14 PM To: actn@ietf.org Subject: Re: [Actn] Problem Statement Update I'll be at IETF90, but may not make the BOF on Thursday so I've captured so= me comments on the ACTN problem statement below. 1. P.5 "Multi-tenant" - it's not clear to me what this means. Does it= mean resources at a common site that are virtualized? YOUNG>> I think multi-tenant means many services are sharing the common tr= ansport resources. Please see KDDI use-case for detail. http://tools.ietf.org/html/draft-kumaki-actn-multitenant-vno-00 2. P.7 "2.1 Virtual Private Networks". For layer 1 networks, I did po= int out in the IETF88 timeframe, that ITU-T Recommendations Y.1312 and Y.13= 13 be examined. They are referenced in RFC4847. What is significant about = those 2 Recommendations is that they define VPNs in both the user plane (re= sources) and the control plane. Much of what is described is directly appl= icable to the ACTN problem statement. For example, how a VPN user is able t= o create/release connections in a VPN that has dedicated resources. I sugg= est that much of the terminology and concepts be referenced in ACTN as it c= omes from an SDO that standardizes much of the transport technologies refer= red to in the I-D. YOUNG>> Thanks for the pointers. I agree that some of your pointed referenc= es may have some implication to the scope of ACTN. We will look into that. 3. P.10 "3.2 Network Resource Recursiveness". I think recursion is a = powerful concept and recursion of network resources is well described in IT= U-T G.800. This section needs to be more precise in that it is also referr= ing to recursion of the control of resources, not just the resources themse= lves. In that regard, the ONF SDN Architecture describes SDN Controller hie= rarchy which is performing this recursion of control. The I-D should add a= reference to https://www.opennetworking.org/images/stories/downloads/sdn-r= esources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf YOUNG>> At this moment, we are not particularly looking at recursiveness as= pect. As you read use-cases, we have an immediate need for an operator's mu= lti-domain issue which is pretty flat layer. But as the PS draft alludes, t= here may be an implication for chains for client-server sets. Thanks for th= e pointer from ONF. Here we are mostly concerned about existing transport n= etworks of various kinds (e.g., GMPLS/ASON, NMS based, PCE based etc.) Hier= archical concept is also addressed in IETF H-PCE and others. But at this mo= ment, the focus of use-cases is pretty flat. 4. P. 13 "4.3 Common Data Models". The idea of a common data model is = helpful for many reasons. I suggest that the requirement be modified to sa= y "common information model" as this is a representation in terms of the pr= operties of thing and the relationship between those things. Data models c= an then be developed from the common information model with specific encodi= ngs at interfaces. I suggest that the I-D refer to TMF TR215 and that ACTN= interact with the ONF as they consider a common information model. YOUNG>> Common DM/IM is important. We will definitely look into Yang and JS= ON-based Models to begin with. TMF model will be looked at. Thanks. Stephen From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: 04 June, 2014 00:28 To: actn@ietf.org Subject: [Actn] Problem Statement Update We have updated the problem statement for ACTN. Major changes are: - Luis (Telefonica) has been added as a co-author. He provided man= y valuable text that enriched the draft. - Added some text on virtual network operational aspect. Any comments are welcomed. Young & Dan --_000_7AEB3D6833318045B4AE71C2C87E8E1729C05E89dfweml706chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephen,=

 

Sorry for my very late= response. When I saw you today in Toronto, this reminded me of your email = you posted last week.

 

Here’s my respon= se to you. Please see inline.

 

Thanks,

Young

 

From: ACTN [ma= ilto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen
Sent: Wednesday, July 16, 2014 3:14 PM
To: actn@ietf.org
Subject: Re: [Actn] Problem Statement Update

 

I’ll be at IETF90, but may not ma= ke the BOF on Thursday so I’ve captured some comments on the ACTN pro= blem statement below.

 

1= .   &= nbsp;  P.5 “Multi-tenant” = – it’s not clear to me what this means.  Does it mean reso= urces at a common site that are virtualized?

 

YOUNG>>  I = think multi-tenant means many services are sharing the common transport res= ources. Please see KDDI use-case for detail.

 

htt= p://tools.ietf.org/html/draft-kumaki-actn-multitenant-vno-00=

 

2= .   &= nbsp;  P.7 “2.1 Virtual Private = Networks”.  For layer 1 networks, I did point out in the IETF88 = timeframe, that ITU-T Recommendations Y.1312 and Y.1313 be examined. They are referenced in RFC4847.  What is significant about those 2 Recomme= ndations is that they define VPNs in both the user plane (resources) and th= e control plane.  Much of what is described is directly applicable to = the ACTN problem statement. For example, how a VPN user is able to create/release connections in a VPN that has dedicat= ed resources.  I suggest that much of the terminology and concepts be = referenced in ACTN as it comes from an SDO that standardizes much of the tr= ansport technologies referred to in the I-D.

 

YOUNG>> Thanks f= or the pointers. I agree that some of your pointed references may have some= implication to the scope of ACTN. We will look into that.

 

3= .   &= nbsp;  P.10 “3.2 Network Resourc= e Recursiveness”.  I think recursion is a powerful concept and r= ecursion of network resources is well described in ITU-T G.800.  This = section needs to be more precise in that it is also referring to recursion of the = control of resources, not just the resources themselves. In that regard, th= e ONF SDN Architecture describes SDN Controller hierarchy which is performi= ng this recursion of control.  The I-D should add a reference to https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/TR_SDN_ARCH_1.0_06062014.pdf

 

YOUNG>> At this = moment, we are not particularly looking at recursiveness aspect. As you rea= d use-cases, we have an immediate need for an operator’s multi-domain= issue which is pretty flat layer. But as the PS draft alludes, there may be an implication for chains for client-server se= ts. Thanks for the pointer from ONF. Here we are mostly concerned about exi= sting transport networks of various kinds (e.g., GMPLS/ASON, NMS based, PCE= based etc.) Hierarchical concept is also addressed in IETF H-PCE and others. But at this moment, the focus = of use-cases is pretty flat.

 

4= .   &= nbsp;  P. 13 “4.3 Common Data Mo= dels”. The idea of a common data model is helpful for many reasons.&n= bsp; I suggest that the requirement be modified to say “common inform= ation model” as this is a representation in terms of the properties of thi= ng and the relationship between those things.  Data models can then be= developed from the common information model with specific encodings at int= erfaces.  I suggest that the I-D refer to TMF TR215 and that ACTN interact with the ONF as they consider a common inform= ation model.

 

YOUNG>> Common D= M/IM is important. We will definitely look into Yang and JSON-based Models = to begin with. TMF model will be looked at. Thanks.

 

Stephen

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: 04 June, 2014 00:28
To: actn@ietf.org
Subject: [Actn] Problem Statement Update

 

We have updated the problem statement for ACTN.

 

Major changes are:

 

-     &= nbsp;    Luis (Telefonica) has been added as a co-author. He= provided many valuable text that enriched the draft.

-     &= nbsp;    Added some text on virtual network operational aspe= ct.

 

Any comments are welcomed.

 

Young & Dan

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C05E89dfweml706chmchi_-- From nobody Thu Jul 31 09:00:47 2014 Return-Path: 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 80B4C1A00D5 for ; Thu, 31 Jul 2014 09:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 rSLlXnOMM6G9 for ; Thu, 31 Jul 2014 09:00:33 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1063B1A00FF for ; Thu, 31 Jul 2014 09:00:32 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s6VFxdkV014231 for ; Thu, 31 Jul 2014 12:00:32 -0400 Received: from vawvcgsie2k1301.ciena.com (LIN1-118-36-35.ciena.com [63.118.36.35]) by mx0b-00103a01.pphosted.com with ESMTP id 1nf4xa2xh4-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 31 Jul 2014 12:00:31 -0400 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 31 Jul 2014 12:00:30 -0400 Received: from ONWVEXCHMB02.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Thu, 31 Jul 2014 12:00:29 -0400 From: "Shew, Stephen" To: "actn@ietf.org" Date: Thu, 31 Jul 2014 12:00:29 -0400 Thread-Topic: related standards work Thread-Index: Ac+s07DwrSd601O8RyCE0rBXyO3Rzw== Message-ID: <510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721@ONWVEXCHMB02.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-20852.000 x-tm-as-result: No--37.135900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721ONWVEXCHMB02c_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-07-31_06:2014-07-30,2014-07-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407310202 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/A_KZncIT_Z30gQyk9E-ObDLvUBM Subject: [Actn] related standards work X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 16:00:41 -0000 --_000_510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721ONWVEXCHMB02c_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As discussed in the actn bof last week, I list some related standards that = I think should be considered by actn so that things don't get re-invented. 1. Virtual Network. There are various semantics to the word "virtual"= so adopting or stating a definition is important. RFC4847 describes virtua= l networks in terms of ITU-T Y.1312 and Y.1313. Those Recommendations addr= ess both the data plane aspect of VPNs as well as the control plane aspect.= Concepts of private and shared VPNs are described. I find them quite use= ful and suggest that uses cases adopt these terms so that the commonality o= f the use cases can more readily be determined. 2. Abstraction and arrangement of control. The recently published ONF= SDN Architecture (https://www.opennetworking.org/images/stories/downloads/= sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf) describes var= ious arrangements of SDN controllers which I think should be adopted by act= n. They define "abstraction" in way that makes "virtual" a subset of abstr= action. Having a clear definition of the 2 terms is important. The Multip= le Vendor Domain Transport Networks use case could be covered by a limited = hierarchy of SDN controllers. One of the suggestions in the SDN Architectu= re document is that there may be a need for inter-domain control and this m= ay be a gap that actn addresses. 3. Interfaces. Implementations of interfaces imply some design, and i= t is helpful to expose that design upfront so that limitations, extensibili= ty, and commonality are understood. To that end, use of a common informati= on model has been beneficial. I point in particular to TM Forum's TR215 an= d is draft successor TR225. From an information model, a more specific inf= ormation model can be derived (like an instantiation of an aspect of the ge= neral one). Then, data models can be developed from that specific informat= ion model. If a common information model is used, then the particular enco= ding of the data model is less critical. I don't suggest that actn start w= ith just a data model because the architecture behind it is not exposed. Stephen Shew | Director, Standards sshew@ciena.com | 3500 Carling Ave. | Ottawa CANADA = K2H 8E9 Direct +1.613.670.3211 --_000_510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721ONWVEXCHMB02c_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As discussed in the act= n bof last week, I list some related standards that I think should be consi= dered by actn so that things don’t get re-invented.=

 

1. = ;     Virtual Network.  Th= ere are various semantics to the word “virtual” so adopting or = stating a definition is important. RFC4847 describes virtual networks in te= rms of ITU-T Y.1312 and Y.1313.  Those Recommendations address both th= e data plane aspect of VPNs as well as the control plane aspect.  Conc= epts of private and shared VPNs are described.  I find them quite usef= ul and suggest that uses cases adopt these terms so that the commonality of= the use cases can more readily be determined.

<= ![if !supportLists]>2.      Abs= traction and arrangement of control.  The recently published ONF SDN A= rchitecture (https://= www.opennetworking.org/images/stories/downloads/sdn-resources/technical-rep= orts/TR_SDN_ARCH_1.0_06062014.pdf) describes various arrangements of SD= N controllers which I think should be adopted by actn.  They define &#= 8220;abstraction” in way that makes “virtual” a subset of= abstraction.  Having a clear definition of the 2 terms is important.&= nbsp; The Multiple Vendor Domain Transport Networks use case could be cover= ed by a limited hierarchy of SDN controllers.  One of the suggestions = in the SDN Architecture document is that there may be a need for inter-doma= in control and this may be a gap that actn addresses.

=

3.      Interfaces.  Implementations of interfaces imply some design, and = it is helpful to expose that design upfront so that limitations, extensibil= ity, and commonality are understood.  To that end, use of a common inf= ormation model has been beneficial.  I point in particular to TM Forum= ’s TR215 and is draft successor TR225.  From an information mode= l, a more specific information model can be derived (like an instantiation = of an aspect of the general one).  Then, data models can be developed = from that specific information model.  If a common information model i= s used, then the particular encoding of the data model is less critical.&nb= sp; I don’t suggest that actn start with just a data model because th= e architecture behind it is not exposed.

 

Stephen Shew | Director, Standardss= shew@ciena.com | 3500 Ca= rling Ave. | Ottawa CANADA K2H 8E9
Direct = +1.613.670.3211

 =

= --_000_510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721ONWVEXCHMB02c_-- From nobody Thu Jul 31 09:43:56 2014 Return-Path: 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 124FC1B290F for ; Thu, 31 Jul 2014 09:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 IENFdH0lmmKm for ; Thu, 31 Jul 2014 09:43:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6CB1A0233 for ; Thu, 31 Jul 2014 09:43:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHU17673; Thu, 31 Jul 2014 16:43:44 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Jul 2014 17:43:44 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml701-chm.china.huawei.com ([169.254.1.129]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 09:43:43 -0700 From: Leeyoung To: "Shew, Stephen" , "actn@ietf.org" Thread-Topic: related standards work Thread-Index: Ac+s07DwrSd601O8RyCE0rBXyO3RzwAB92+Q Date: Thu, 31 Jul 2014 16:43:42 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C079A9@dfweml706-chm.china.huawei.com> References: <510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721@ONWVEXCHMB02.ciena.com> In-Reply-To: <510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721@ONWVEXCHMB02.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.220] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C079A9dfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/dJQT_RmHMLtelp0jpil3ial3zv8 Subject: Re: [Actn] related standards work X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 16:43:55 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C079A9dfweml706chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephen, Thanks for posting this list of reference. My overall comment is: in light of many works in the past and even presentl= y in other SDOs, it is ironic that operators came to IETF to address their = problems and see IETF as viable and practical place for their problem to be= solved. >From a transport network perspective, there have been many tools IETF champ= ioned in regard to GMPLS control plane, PCE and other configuration/managem= ent tools. Some of your pointer for ONF seems irrelevant to many operators = as OF is a green-field for them. As you were in the BoF, the operators bro= ught their current problems on their brown field. Are you aware of any real= deployment of ONF-based transport networks? ACTN can certainly treat OF-ba= sed transport as a domain among others once it is deployed. Your Virtual network reference from ITU-T is quite theoretical and VPNs hav= e been implemented in L2VPN/L3VPN WGs focusing on practical issues. I also = see some gap of many ITU-T references and the reality. Your pointer for TMF is all appreciated. We will look at if data model is n= ecessary to enable abstraction. For TE model of IETF, we did not have eithe= r IM or DM in GMPLS/PCE implementation. At this point, I am not sure if we = need IM or DM. One of the homeworks from the BoF is to investigate if we ne= ed IM/DM. If we do need IM/DM, there have been some efforts in IETF around = Yang and JSON. I have proposed JSON based abstraction models in the past in= IETF (In a BoF called I2AEX under ALTO) , which seems working very well fo= r transport network resource abstraction. There are also BGP-LS based mode= ls that have progressed in IETF quite a bit. I tend to think these lists ar= e a starting point. TMF is a bit foreign to IETF and to me. Thanks, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen Sent: Thursday, July 31, 2014 11:00 AM To: actn@ietf.org Subject: [Actn] related standards work As discussed in the actn bof last week, I list some related standards that = I think should be considered by actn so that things don't get re-invented. 1. Virtual Network. There are various semantics to the word "virtual"= so adopting or stating a definition is important. RFC4847 describes virtua= l networks in terms of ITU-T Y.1312 and Y.1313. Those Recommendations addr= ess both the data plane aspect of VPNs as well as the control plane aspect.= Concepts of private and shared VPNs are described. I find them quite use= ful and suggest that uses cases adopt these terms so that the commonality o= f the use cases can more readily be determined. 2. Abstraction and arrangement of control. The recently published ONF= SDN Architecture (https://www.opennetworking.org/images/stories/downloads/= sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf) describes var= ious arrangements of SDN controllers which I think should be adopted by act= n. They define "abstraction" in way that makes "virtual" a subset of abstr= action. Having a clear definition of the 2 terms is important. The Multip= le Vendor Domain Transport Networks use case could be covered by a limited = hierarchy of SDN controllers. One of the suggestions in the SDN Architectu= re document is that there may be a need for inter-domain control and this m= ay be a gap that actn addresses. 3. Interfaces. Implementations of interfaces imply some design, and i= t is helpful to expose that design upfront so that limitations, extensibili= ty, and commonality are understood. To that end, use of a common informati= on model has been beneficial. I point in particular to TM Forum's TR215 an= d is draft successor TR225. From an information model, a more specific inf= ormation model can be derived (like an instantiation of an aspect of the ge= neral one). Then, data models can be developed from that specific informat= ion model. If a common information model is used, then the particular enco= ding of the data model is less critical. I don't suggest that actn start w= ith just a data model because the architecture behind it is not exposed. Stephen Shew | Director, Standards sshew@ciena.com | 3500 Carling Ave. | Ottawa CANADA = K2H 8E9 Direct +1.613.670.3211 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C079A9dfweml706chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephen,=

 

Thanks for posting thi= s list of reference.

 

My overall comment is:= in light of many works in the past and even presently in other SDOs, it is= ironic that operators came to IETF to address their problems and see IETF = as viable and practical place for their problem to be solved.

 

From a transport netwo= rk perspective, there have been many tools IETF championed in regard to GMP= LS control plane, PCE and other configuration/management tools. Some of you= r pointer for ONF seems irrelevant to many operators as OF is a green-field for them.  As you were in the B= oF, the operators brought their current problems on their brown field. Are = you aware of any real deployment of ONF-based transport networks? ACTN can = certainly treat OF-based transport as a domain among others once it is deployed.

 

Your Virtual network r= eference from ITU-T is quite theoretical and VPNs have been implemented in = L2VPN/L3VPN WGs focusing on practical issues. I also see some gap of many I= TU-T references and the reality.

 

Your pointer for TMF i= s all appreciated. We will look at if data model is necessary to enable abs= traction. For TE model of IETF, we did not have either IM or DM in GMPLS/PC= E implementation. At this point, I am not sure if we need IM or DM. One of the homeworks from the BoF is to inve= stigate if we need IM/DM. If we do need IM/DM, there have been some efforts= in IETF around Yang and JSON. I have proposed JSON based abstraction model= s in the past in IETF (In a BoF called I2AEX under ALTO) , which seems working very well for transport net= work resource abstraction.  There are also BGP-LS based models that ha= ve progressed in IETF quite a bit. I tend to think these lists are a starti= ng point. TMF is a bit foreign to IETF and to me.

 

Thanks,

Young

 

From: ACTN [ma= ilto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen
Sent: Thursday, July 31, 2014 11:00 AM
To: actn@ietf.org
Subject: [Actn] related standards work

 

As discussed in the actn bof last week,= I list some related standards that I think should be considered by actn so= that things don’t get re-invented.

 

1= .   &= nbsp;  Virtual Network.  There ar= e various semantics to the word “virtual” so adopting or statin= g a definition is important. RFC4847 describes virtual networks in terms of ITU-T Y.1312 and Y.1313.  Those Recommendations address both the d= ata plane aspect of VPNs as well as the control plane aspect.  Concept= s of private and shared VPNs are described.  I find them quite useful = and suggest that uses cases adopt these terms so that the commonality of the use cases can more readily be determined.=

2= .   &= nbsp;  Abstraction and arrangement of = control.  The recently published ONF SDN Architecture (https://www.open= networking.org/images/stories/downloads/sdn-resources/technical-reports/TR_= SDN_ARCH_1.0_06062014.pdf) describes various arrangements of SDN controllers which= I think should be adopted by actn.  They define “abstraction= 221; in way that makes “virtual” a subset of abstraction. = Having a clear definition of the 2 terms is important.  The Multiple Vendor Domain T= ransport Networks use case could be covered by a limited hierarchy of SDN c= ontrollers.  One of the suggestions in the SDN Architecture document i= s that there may be a need for inter-domain control and this may be a gap that actn addresses.

3= .   &= nbsp;  Interfaces.  Implementatio= ns of interfaces imply some design, and it is helpful to expose that design= upfront so that limitations, extensibility, and commonality are understood.  To that end, use of a common information model has b= een beneficial.  I point in particular to TM Forum’s TR215 and i= s draft successor TR225.  From an information model, a more specific i= nformation model can be derived (like an instantiation of an aspect of the general one).  Then, data models can be developed= from that specific information model.  If a common information model = is used, then the particular encoding of the data model is less critical.&n= bsp; I don’t suggest that actn start with just a data model because the architecture behind it is not exposed.=

 

Stephen Shew | Director, Standards
sshew@cien= a.com | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
Direct +1.613.670.3211

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C079A9dfweml706chmchi_-- From nobody Thu Jul 31 10:05:57 2014 Return-Path: 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 0B7151B2936 for ; Thu, 31 Jul 2014 10:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 W50tskhGsAt8 for ; Thu, 31 Jul 2014 10:05:51 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613B11B2909 for ; Thu, 31 Jul 2014 10:05:50 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 6C3FD72F23449; Thu, 31 Jul 2014 17:05:47 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s6VH5kIk032459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 13:05:48 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.186]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 31 Jul 2014 13:05:48 -0400 From: "Varma, Eve L (Eve)" To: Leeyoung , "Shew, Stephen" , "actn@ietf.org" Thread-Topic: related standards work Thread-Index: Ac+s07DwrSd601O8RyCE0rBXyO3RzwAB92+QAADM7uA= Date: Thu, 31 Jul 2014 17:05:47 +0000 Message-ID: <6D32668528F93D449A073F45707153D82C49F304@US70UWXCHMBA03.zam.alcatel-lucent.com> References: <510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721@ONWVEXCHMB02.ciena.com> <7AEB3D6833318045B4AE71C2C87E8E1729C079A9@dfweml706-chm.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C079A9@dfweml706-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_6D32668528F93D449A073F45707153D82C49F304US70UWXCHMBA03z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/lp0LUef8n_a_D_FnEYUueTcVarw Subject: Re: [Actn] related standards work X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 17:05:57 -0000 --_000_6D32668528F93D449A073F45707153D82C49F304US70UWXCHMBA03z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Young, Please see below for my two cents ;-) With best regards, Eve From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, July 31, 2014 12:44 PM To: Shew, Stephen; actn@ietf.org Subject: Re: [Actn] related standards work Hi Stephen, Thanks for posting this list of reference. My overall comment is: in light of many works in the past and even presentl= y in other SDOs, it is ironic that operators came to IETF to address their = problems and see IETF as viable and practical place for their problem to be= solved. I am not surprised that operators are seeking to find solutions acros= s a range of standards and industry forums. This is not exclusive to IETF = - e.g., consider related ETSI NVF work items. >From a transport network perspective, there have been many tools IETF champ= ioned in regard to GMPLS control plane, PCE and other configuration/managem= ent tools. Some of your pointer for ONF seems irrelevant to many operators = as OF is a green-field for them. As you were in the BoF, the operators bro= ught their current problems on their brown field. Are you aware of any real= deployment of ONF-based transport networks? ACTN can certainly treat OF-ba= sed transport as a domain among others once it is deployed. The reference was to a protocol-neutral SDN Architecture document (i.= e., independent of the protocol used over interfaces), which has some very = useful material that has also been shared with other SDOs, and IMHO is quit= e relevant to the ACTN problem domain. I would certainly understand your c= omment if the document were focused/optimized for the OF protocol. However= , it is not. It is my view that protocol-independent architectural work sh= ould be examined regardless of what group produces it, as we have so many c= olleagues contributing across multiple standards and industry forums, which= allows for leverage of applicable work. Your Virtual network reference from ITU-T is quite theoretical and VPNs hav= e been implemented in L2VPN/L3VPN WGs focusing on practical issues. I also = see some gap of many ITU-T references and the reality. Perhaps the language used in the ITU-T Rec. could be a barrier for so= me, but there is useful information. You'll find some good material, lever= aging this, in the SDN Architecture document discussion of this area. Your pointer for TMF is all appreciated. We will look at if data model is n= ecessary to enable abstraction. For TE model of IETF, we did not have eithe= r IM or DM in GMPLS/PCE implementation. At this point, I am not sure if we = need IM or DM. One of the homeworks from the BoF is to investigate if we ne= ed IM/DM. If we do need IM/DM, there have been some efforts in IETF around = Yang and JSON. I have proposed JSON based abstraction models in the past in= IETF (In a BoF called I2AEX under ALTO) , which seems working very well fo= r transport network resource abstraction. There are also BGP-LS based mode= ls that have progressed in IETF quite a bit. I tend to think these lists ar= e a starting point. TMF is a bit foreign to IETF and to me. If one is looking from a broader transport networking perspective, a= n underlying information model from which various data models/interfaces ca= n be derived enables interoperability (not to mention leverage of significa= nt industry experience in networking & forwarding domain). However, this i= s a much larger discussion topic area (beyond ACTN). Thanks, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen Sent: Thursday, July 31, 2014 11:00 AM To: actn@ietf.org Subject: [Actn] related standards work As discussed in the actn bof last week, I list some related standards that = I think should be considered by actn so that things don't get re-invented. 1. Virtual Network. There are various semantics to the word "virtual"= so adopting or stating a definition is important. RFC4847 describes virtua= l networks in terms of ITU-T Y.1312 and Y.1313. Those Recommendations addr= ess both the data plane aspect of VPNs as well as the control plane aspect.= Concepts of private and shared VPNs are described. I find them quite use= ful and suggest that uses cases adopt these terms so that the commonality o= f the use cases can more readily be determined. 2. Abstraction and arrangement of control. The recently published ONF= SDN Architecture (https://www.opennetworking.org/images/stories/downloads/= sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf) describes var= ious arrangements of SDN controllers which I think should be adopted by act= n. They define "abstraction" in way that makes "virtual" a subset of abstr= action. Having a clear definition of the 2 terms is important. The Multip= le Vendor Domain Transport Networks use case could be covered by a limited = hierarchy of SDN controllers. One of the suggestions in the SDN Architectu= re document is that there may be a need for inter-domain control and this m= ay be a gap that actn addresses. 3. Interfaces. Implementations of interfaces imply some design, and i= t is helpful to expose that design upfront so that limitations, extensibili= ty, and commonality are understood. To that end, use of a common informati= on model has been beneficial. I point in particular to TM Forum's TR215 an= d is draft successor TR225. From an information model, a more specific inf= ormation model can be derived (like an instantiation of an aspect of the ge= neral one). Then, data models can be developed from that specific informat= ion model. If a common information model is used, then the particular enco= ding of the data model is less critical. I don't suggest that actn start w= ith just a data model because the architecture behind it is not exposed. Stephen Shew | Director, Standards sshew@ciena.com | 3500 Carling Ave. | Ottawa CANADA = K2H 8E9 Direct +1.613.670.3211 --_000_6D32668528F93D449A073F45707153D82C49F304US70UWXCHMBA03z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Young,

 

Please see below for my two ce= nts ;-)

 

With best regards,<= /span>

Eve

 

From: ACTN [ma= ilto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Thursday, July 31, 2014 12:44 PM
To: Shew, Stephen; actn@ietf.org
Subject: Re: [Actn] related standards work

 

Hi Stephen,=

 

Thanks for posting thi= s list of reference.

 

My overall comment is:= in light of many works in the past and even presently in other SDOs, it is= ironic that operators came to IETF to address their problems and see IETF = as viable and practical place for their problem to be solved.

 

<ELV> I am no= t surprised that operators are seeking to find solutions across a range of = standards and industry forums.  This is not exclusive to IETF – = e.g.,  consider related ETSI NVF work items. 

 

From a transport netwo= rk perspective, there have been many tools IETF championed in regard to GMP= LS control plane, PCE and other configuration/management tools. Some of you= r pointer for ONF seems irrelevant to many operators as OF is a green-field for them.  As you were in the B= oF, the operators brought their current problems on their brown field. Are = you aware of any real deployment of ONF-based transport networks? ACTN can = certainly treat OF-based transport as a domain among others once it is deployed.

 

<ELV> The ref= erence was to a protocol-neutral SDN Architecture document (i.e., independe= nt of the protocol used over interfaces), which has some very useful materi= al that has also been shared with other SDOs, and IMHO is quite relevant to the ACTN problem domain.  I would certa= inly understand your comment if the document were focused/optimized for the= OF protocol.  However, it is not.  It is my view that protocol-i= ndependent architectural work should be examined regardless of what group produces it, as we have so many colleagues contri= buting across multiple standards and industry forums, which allows for leve= rage of applicable work.    

 

Your Virtual network r= eference from ITU-T is quite theoretical and VPNs have been implemented in = L2VPN/L3VPN WGs focusing on practical issues. I also see some gap of many I= TU-T references and the reality.

 

<ELV> Perhaps= the language used in the ITU-T Rec. could be a barrier for some, but there= is useful information.  You’ll find some good material, leverag= ing this, in the SDN Architecture document discussion of this area.

 

Your pointer for TMF i= s all appreciated. We will look at if data model is necessary to enable abs= traction. For TE model of IETF, we did not have either IM or DM in GMPLS/PC= E implementation. At this point, I am not sure if we need IM or DM. One of the homeworks from the BoF is to inve= stigate if we need IM/DM. If we do need IM/DM, there have been some efforts= in IETF around Yang and JSON. I have proposed JSON based abstraction model= s in the past in IETF (In a BoF called I2AEX under ALTO) , which seems working very well for transport net= work resource abstraction.  There are also BGP-LS based models that ha= ve progressed in IETF quite a bit. I tend to think these lists are a starti= ng point. TMF is a bit foreign to IETF and to me.

 

<ELV>  I= f one is looking from a broader transport networking perspective, an underl= ying information model from which various data models/interfaces can be der= ived enables interoperability (not to mention leverage of significant industry experien= ce in networking & forwarding domain).  However, this is a much la= rger discussion topic area (beyond ACTN).

 

Thanks,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen
Sent: Thursday, July 31, 2014 11:00 AM
To: actn@ietf.org
Subject: [Actn] related standards work

 

As discussed in the actn bof last week,= I list some related standards that I think should be considered by actn so= that things don’t get re-invented.

 

1= .   &= nbsp;  Virtual Network.  There ar= e various semantics to the word “virtual” so adopting or statin= g a definition is important. RFC4847 describes virtual networks in terms of ITU-T Y.1312 and Y.1313.  Those Recommendations address both the d= ata plane aspect of VPNs as well as the control plane aspect.  Concept= s of private and shared VPNs are described.  I find them quite useful = and suggest that uses cases adopt these terms so that the commonality of the use cases can more readily be determined.=

2= .   &= nbsp;  Abstraction and arrangement of = control.  The recently published ONF SDN Architecture (https://www.open= networking.org/images/stories/downloads/sdn-resources/technical-reports/TR_= SDN_ARCH_1.0_06062014.pdf) describes various arrangements of SDN controllers which= I think should be adopted by actn.  They define “abstraction= 221; in way that makes “virtual” a subset of abstraction. = Having a clear definition of the 2 terms is important.  The Multiple Vendor Domain T= ransport Networks use case could be covered by a limited hierarchy of SDN c= ontrollers.  One of the suggestions in the SDN Architecture document i= s that there may be a need for inter-domain control and this may be a gap that actn addresses.

3= .   &= nbsp;  Interfaces.  Implementatio= ns of interfaces imply some design, and it is helpful to expose that design= upfront so that limitations, extensibility, and commonality are understood.  To that end, use of a common information model has b= een beneficial.  I point in particular to TM Forum’s TR215 and i= s draft successor TR225.  From an information model, a more specific i= nformation model can be derived (like an instantiation of an aspect of the general one).  Then, data models can be developed= from that specific information model.  If a common information model = is used, then the particular encoding of the data model is less critical.&n= bsp; I don’t suggest that actn start with just a data model because the architecture behind it is not exposed.=

 

Stephen Shew | Director, Standards
sshew@cien= a.com | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
Direct +1.613.670.3211

 

--_000_6D32668528F93D449A073F45707153D82C49F304US70UWXCHMBA03z_-- From nobody Thu Jul 31 10:34:24 2014 Return-Path: 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 8EDBF1B292A for ; Thu, 31 Jul 2014 10:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 F3WVaAbwFdLd for ; Thu, 31 Jul 2014 10:34:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5CE1A02E3 for ; Thu, 31 Jul 2014 10:34:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKT51571; Thu, 31 Jul 2014 17:34:14 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Jul 2014 18:34:13 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 10:34:02 -0700 From: Leeyoung To: "Varma, Eve L (Eve)" , "Shew, Stephen" , "actn@ietf.org" Thread-Topic: related standards work Thread-Index: Ac+s07DwrSd601O8RyCE0rBXyO3RzwAB92+QAADM7uAAAP+EQA== Date: Thu, 31 Jul 2014 17:34:01 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C07A03@dfweml706-chm.china.huawei.com> References: <510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721@ONWVEXCHMB02.ciena.com> <7AEB3D6833318045B4AE71C2C87E8E1729C079A9@dfweml706-chm.china.huawei.com> <6D32668528F93D449A073F45707153D82C49F304@US70UWXCHMBA03.zam.alcatel-lucent.com> In-Reply-To: <6D32668528F93D449A073F45707153D82C49F304@US70UWXCHMBA03.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.220] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C07A03dfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/y8nm1totnulnbu087gyHHMzQETI Subject: Re: [Actn] related standards work X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 17:34:21 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C07A03dfweml706chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eve, Good to hear from you in ACTN list. Thanks for your comment. I think you cl= arified some misunderstanding and confusion. Here's my comment for you in-l= ine. Regards, Young From: Varma, Eve L (Eve) [mailto:eve.varma@alcatel-lucent.com] Sent: Thursday, July 31, 2014 12:06 PM To: Leeyoung; Shew, Stephen; actn@ietf.org Subject: RE: related standards work Hi Young, Please see below for my two cents ;-) With best regards, Eve From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, July 31, 2014 12:44 PM To: Shew, Stephen; actn@ietf.org Subject: Re: [Actn] related standards work Hi Stephen, Thanks for posting this list of reference. My overall comment is: in light of many works in the past and even presentl= y in other SDOs, it is ironic that operators came to IETF to address their = problems and see IETF as viable and practical place for their problem to be= solved. I am not surprised that operators are seeking to find solutions acros= s a range of standards and industry forums. This is not exclusive to IETF = - e.g., consider related ETSI NVF work items. YOUNG>> Yes, that is a reality. >From a transport network perspective, there have been many tools IETF champ= ioned in regard to GMPLS control plane, PCE and other configuration/managem= ent tools. Some of your pointer for ONF seems irrelevant to many operators = as OF is a green-field for them. As you were in the BoF, the operators bro= ught their current problems on their brown field. Are you aware of any real= deployment of ONF-based transport networks? ACTN can certainly treat OF-ba= sed transport as a domain among others once it is deployed. The reference was to a protocol-neutral SDN Architecture document (i.= e., independent of the protocol used over interfaces), which has some very = useful material that has also been shared with other SDOs, and IMHO is quit= e relevant to the ACTN problem domain. I would certainly understand your c= omment if the document were focused/optimized for the OF protocol. However= , it is not. It is my view that protocol-independent architectural work sh= ould be examined regardless of what group produces it, as we have so many c= olleagues contributing across multiple standards and industry forums, which= allows for leverage of applicable work. YOUNG>> The assumption for SDN arch. Document (as far as I understand from = the initial version) is, however, tied with OF based philosophy, meaning th= at the SDN controller is a "God"-box as to what to control as to how much i= t wants to know. The ACTN is on a different assumption. ACTN control hierar= chy would not touch existing domain control of many kinds (e.g., GMPLS/ASON= , PCE-based, NMS/EMS-based, etc.) and let them continue control/operate the= ir networks (which is one of the requirements from many operators). What th= ey need is a overarching "overseer" that allows quick service provisioning = based on an end-to-end global abstraction view of all encompassing domains.= For instance, cross-connect and other low level control of NE will need no= t be abstracted in ACTN scope as these controls will continue to be done at= existing domain level control. I think this assumption makes a huge differ= ence. I believe what ACTN is trying to do based on operators' use-cases has= a different starting point from what you are referring to, namely, the ONF= SDN Control architecture models has been trying to do. ACTN does not repla= ce any existing network control and operation. It builds on top of that. Your Virtual network reference from ITU-T is quite theoretical and VPNs hav= e been implemented in L2VPN/L3VPN WGs focusing on practical issues. I also = see some gap of many ITU-T references and the reality. Perhaps the language used in the ITU-T Rec. could be a barrier for so= me, but there is useful information. You'll find some good material, lever= aging this, in the SDN Architecture document discussion of this area. YOUNG>> language is always a tremendous stumbling block. :) I will try to u= pdate myself with the mentioned references. Your pointer for TMF is all appreciated. We will look at if data model is n= ecessary to enable abstraction. For TE model of IETF, we did not have eithe= r IM or DM in GMPLS/PCE implementation. At this point, I am not sure if we = need IM or DM. One of the homeworks from the BoF is to investigate if we ne= ed IM/DM. If we do need IM/DM, there have been some efforts in IETF around = Yang and JSON. I have proposed JSON based abstraction models in the past in= IETF (In a BoF called I2AEX under ALTO) , which seems working very well fo= r transport network resource abstraction. There are also BGP-LS based mode= ls that have progressed in IETF quite a bit. I tend to think these lists ar= e a starting point. TMF is a bit foreign to IETF and to me. If one is looking from a broader transport networking perspective, a= n underlying information model from which various data models/interfaces ca= n be derived enables interoperability (not to mention leverage of significa= nt industry experience in networking & forwarding domain). However, this i= s a much larger discussion topic area (beyond ACTN). YOUNG>> Agree. My point is that models are only tools that should help the = functions. As pointed previously, for simple functions to fulfill, the vali= dity of models needs to be carefully evaluated. Thanks, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen Sent: Thursday, July 31, 2014 11:00 AM To: actn@ietf.org Subject: [Actn] related standards work As discussed in the actn bof last week, I list some related standards that = I think should be considered by actn so that things don't get re-invented. 1. Virtual Network. There are various semantics to the word "virtual"= so adopting or stating a definition is important. RFC4847 describes virtua= l networks in terms of ITU-T Y.1312 and Y.1313. Those Recommendations addr= ess both the data plane aspect of VPNs as well as the control plane aspect.= Concepts of private and shared VPNs are described. I find them quite use= ful and suggest that uses cases adopt these terms so that the commonality o= f the use cases can more readily be determined. 2. Abstraction and arrangement of control. The recently published ONF= SDN Architecture (https://www.opennetworking.org/images/stories/downloads/= sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf) describes var= ious arrangements of SDN controllers which I think should be adopted by act= n. They define "abstraction" in way that makes "virtual" a subset of abstr= action. Having a clear definition of the 2 terms is important. The Multip= le Vendor Domain Transport Networks use case could be covered by a limited = hierarchy of SDN controllers. One of the suggestions in the SDN Architectu= re document is that there may be a need for inter-domain control and this m= ay be a gap that actn addresses. 3. Interfaces. Implementations of interfaces imply some design, and i= t is helpful to expose that design upfront so that limitations, extensibili= ty, and commonality are understood. To that end, use of a common informati= on model has been beneficial. I point in particular to TM Forum's TR215 an= d is draft successor TR225. From an information model, a more specific inf= ormation model can be derived (like an instantiation of an aspect of the ge= neral one). Then, data models can be developed from that specific informat= ion model. If a common information model is used, then the particular enco= ding of the data model is less critical. I don't suggest that actn start w= ith just a data model because the architecture behind it is not exposed. Stephen Shew | Director, Standards sshew@ciena.com | 3500 Carling Ave. | Ottawa CANADA = K2H 8E9 Direct +1.613.670.3211 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C07A03dfweml706chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eve,

 

Good to hear from you = in ACTN list. Thanks for your comment. I think you clarified some misunders= tanding and confusion. Here’s my comment for you in-line.

 

Regards,

Young

 

From: Varma, E= ve L (Eve) [mailto:eve.varma@alcatel-lucent.com]
Sent: Thursday, July 31, 2014 12:06 PM
To: Leeyoung; Shew, Stephen; actn@ietf.org
Subject: RE: related standards work

 

Hi Young,

 

Please see below for my two ce= nts ;-)

 

With best regards,<= /span>

Eve

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Thursday, July 31, 2014 12:44 PM
To: Shew, Stephen; actn@ietf.org
Subject: Re: [Actn] related standards work

 

Hi Stephen,=

 

Thanks for posting thi= s list of reference.

 

My overall comment is:= in light of many works in the past and even presently in other SDOs, it is= ironic that operators came to IETF to address their problems and see IETF = as viable and practical place for their problem to be solved.

 

<ELV> I am no= t surprised that operators are seeking to find solutions across a range of = standards and industry forums.  This is not exclusive to IETF – = e.g.,  consider related ETSI NVF work items. 

 

YOUNG>> Yes, = that is a reality.

 

From a transport netwo= rk perspective, there have been many tools IETF championed in regard to GMP= LS control plane, PCE and other configuration/management tools. Some of you= r pointer for ONF seems irrelevant to many operators as OF is a green-field for them.  As you were in the B= oF, the operators brought their current problems on their brown field. Are = you aware of any real deployment of ONF-based transport networks? ACTN can = certainly treat OF-based transport as a domain among others once it is deployed.

 

<ELV> The ref= erence was to a protocol-neutral SDN Architecture document (i.e., independe= nt of the protocol used over interfaces), which has some very useful materi= al that has also been shared with other SDOs, and IMHO is quite relevant to the ACTN problem domain.  I would certa= inly understand your comment if the document were focused/optimized for the= OF protocol.  However, it is not.  It is my view that protocol-i= ndependent architectural work should be examined regardless of what group produces it, as we have so many colleagues contri= buting across multiple standards and industry forums, which allows for leve= rage of applicable work.    

 

YOUNG>> The a= ssumption for SDN arch. Document (as far as I understand from the initial v= ersion) is, however, tied with OF based philosophy, meaning that the SDN co= ntroller is a “God”-box as to what to control as to how much it wants to know. The ACTN is on a different assumption. AC= TN control hierarchy would not touch existing domain control of many kinds = (e.g., GMPLS/ASON, PCE-based, NMS/EMS-based, etc.) and let them continue co= ntrol/operate their networks (which is one of the requirements from many operators). What they need is a overa= rching “overseer” that allows quick service provisioning based = on an end-to-end global abstraction view of all encompassing domains. For i= nstance, cross-connect and other low level control of NE will need not be abstracted in ACTN scope as these controls will con= tinue to be done at existing domain level control. I think this assumption = makes a huge difference. I believe what ACTN is trying to do based on opera= tors’ use-cases has a different starting point from what you are referring to, namely, the ONF SDN Control= architecture models has been trying to do. ACTN does not replace any exist= ing network control and operation. It builds on top of that.

 

 

 

Your Virtual network r= eference from ITU-T is quite theoretical and VPNs have been implemented in = L2VPN/L3VPN WGs focusing on practical issues. I also see some gap of many I= TU-T references and the reality.

 

<ELV> Perhaps= the language used in the ITU-T Rec. could be a barrier for some, but there= is useful information.  You’ll find some good material, leverag= ing this, in the SDN Architecture document discussion of this area.

 

YOUNG>> langu= age is always a tremendous stumbling block. J<= span style=3D"color:#1F497D"> I will try to update myself with the mentione= d references.

 

Your pointer for TMF i= s all appreciated. We will look at if data model is necessary to enable abs= traction. For TE model of IETF, we did not have either IM or DM in GMPLS/PC= E implementation. At this point, I am not sure if we need IM or DM. One of the homeworks from the BoF is to inve= stigate if we need IM/DM. If we do need IM/DM, there have been some efforts= in IETF around Yang and JSON. I have proposed JSON based abstraction model= s in the past in IETF (In a BoF called I2AEX under ALTO) , which seems working very well for transport net= work resource abstraction.  There are also BGP-LS based models that ha= ve progressed in IETF quite a bit. I tend to think these lists are a starti= ng point. TMF is a bit foreign to IETF and to me.

 

<ELV>  I= f one is looking from a broader transport networking perspective, an underl= ying information model from which various data models/interfaces can be der= ived enables interoperability (not to mention leverage of significant industry experience in networking & forwarding domain).=   However, this is a much larger discussion topic area (beyond ACTN).<= o:p>

 

YOUNG>> Agree= . My point is that models are only tools that should help the functions. As= pointed previously, for simple functions to fulfill, the validity of model= s needs to be carefully evaluated.

 

Thanks,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen
Sent: Thursday, July 31, 2014 11:00 AM
To: actn@ietf.org
Subject: [Actn] related standards work

 

As discussed in the actn bof last week,= I list some related standards that I think should be considered by actn so= that things don’t get re-invented.

 

1= .   &= nbsp;  Virtual Network.  There ar= e various semantics to the word “virtual” so adopting or statin= g a definition is important. RFC4847 describes virtual networks in terms of ITU-T Y.1312 and Y.1313.  Those Recommendations address both the d= ata plane aspect of VPNs as well as the control plane aspect.  Concept= s of private and shared VPNs are described.  I find them quite useful = and suggest that uses cases adopt these terms so that the commonality of the use cases can more readily be determined.=

2= .   &= nbsp;  Abstraction and arrangement of = control.  The recently published ONF SDN Architecture (https://www.open= networking.org/images/stories/downloads/sdn-resources/technical-reports/TR_= SDN_ARCH_1.0_06062014.pdf) describes various arrangements of SDN controllers which= I think should be adopted by actn.  They define “abstraction= 221; in way that makes “virtual” a subset of abstraction. = Having a clear definition of the 2 terms is important.  The Multiple Vendor Domain T= ransport Networks use case could be covered by a limited hierarchy of SDN c= ontrollers.  One of the suggestions in the SDN Architecture document i= s that there may be a need for inter-domain control and this may be a gap that actn addresses.

3= .   &= nbsp;  Interfaces.  Implementatio= ns of interfaces imply some design, and it is helpful to expose that design= upfront so that limitations, extensibility, and commonality are understood.  To that end, use of a common information model has b= een beneficial.  I point in particular to TM Forum’s TR215 and i= s draft successor TR225.  From an information model, a more specific i= nformation model can be derived (like an instantiation of an aspect of the general one).  Then, data models can be developed= from that specific information model.  If a common information model = is used, then the particular encoding of the data model is less critical.&n= bsp; I don’t suggest that actn start with just a data model because the architecture behind it is not exposed.=

 

Stephen Shew | Director, Standards
sshew@cien= a.com | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
Direct +1.613.670.3211

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C07A03dfweml706chmchi_--