From amy.yemin@huawei.com Thu Aug 1 01:57:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA66D21F9E9F for ; Thu, 1 Aug 2013 01:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.761 X-Spam-Level: X-Spam-Status: No, score=-2.761 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waK-D-R3xS5x for ; Thu, 1 Aug 2013 01:57:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7702021F9E62 for ; Thu, 1 Aug 2013 01:57:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVQ08627; Thu, 01 Aug 2013 08:57:28 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 09:57:11 +0100 Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 09:57:23 +0100 Received: from CDA130110267GB (10.47.139.249) by szxeml457-hub.china.huawei.com (10.82.67.200) with Microsoft SMTP Server id 14.1.323.7; Thu, 1 Aug 2013 16:57:09 +0800 Message-ID: <42AD3B5FE67D4090B41F24C617A55395@china.huawei.com> From: Amy To: Date: Thu, 1 Aug 2013 16:59:00 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D39_01CE8ED8.6B232AB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.47.139.249] X-CFilter-Loop: Reflected Cc: Longhao Subject: [CCAMP] draft-long-ccamp-rsvp-te-bandwidth-availability-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:57:36 -0000 ------=_NextPart_000_0D39_01CE8ED8.6B232AB0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQ0NBTVBlcnMsDQoNClRoZXJlIHdlcmUgc29tZSBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzIGFm dGVyIHRoZSBwcmVzZW50YXRpb24gb2YgZHJhZnQtbG9uZy1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0 aC1hdmFpbGFiaWxpdHkgYW5kIGRyYWZ0LWxvbmctY2NhbXAtb3NwZi1hdmFpbGFiaWxpdHktZXh0 ZW5zaW9uLg0KDQpCZWxvdyBhcmUgdGhlIGNvbW1lbnRzIGFuZCByZXBsaWVzOg0KDQoxLiBUaGUg bW90aXZhdGlvbiANCltBdXRob3JzXSBGb3IgdGhlIGxpbmtzIHdpdGggdmFyaWFibGUgZGlzY3Jl dGUgYmFuZHdpZHRoLCBhdmFpbGFiaWxpdHkgaXMgdXNlZCB0byBkZWNyaWJlIHRoZSBiYW5kd2lk dGguIEl0J3MgcHJvcG9zZWQgdG8gYWRkIHRoZSBhdmFpbGFiaWxpdHkgYXMgYW4gcGFyYW10ZXIg YWxvbmcgd2l0aCB0aGUgYmFuZHdpZHRoIHJlcXVlc3QuIFdpdGhvdXQgdGhpcyBleHRlbnNpb24s IHRoZSBsaW5rIGJhbmR3aWR0aCBjYW5ub3QgZ2V0IGdvb2QgdXRpbGl6YXRpb246IGZvciBleGFt cGxlLCB0aGUgbm9kZSBtYXkgcmVzZXJ2ZSB0aGUgYmFuZHdpZHRoIHdpdGggOTkuOTk5JSBhdmFp bGFiaWxpdHkgd2hpbGUgdGhlIGFjdHVhbCByZXF1aXJlbWVudCBpcyBvbmx5IDk5LjklLCBhbmQg Y29uc2VxdWVudGx5IGl0IGNhbiBub3QgcmVzZXJ2ZSB0aGUgYmFuZHdpZHRoIHdoZW4gdGhlIHJl YWwgcmVxdWlyZW1lbnQgd2l0aCA5OS45OTklIGF2YWlsYWJpbGl0eSBjb21lcy4NCg0KMi4gVGhl IG1lY2hhbmlzbSwgaG93IHRvIHVzZSB0aGUgYXZhaWxhYmlsaXR5IHByb2ZpbGUNCltBdXRob3Jz XSBPbmNlIHRoZSBsaW5rIGlzIHNldCB1cCwgdGhlIGluZm9ybWF0aW9uIG9uIGF2YWlsYWJpbGl0 eSBhbmQgYmFuZHdpZHRoIGlzIHNhdmVkIGluIHRoZSBsaW5rIGJhbmR3aWR0aCBjYXBhY2l0eSB0 YWJsZSBvbiBsb2NhbCBub2RlLCBhbmQgc2hvdWxkIGFsc28gYmUgcHJvcGFnYXRlZCBpbiB0aGUg cm91dGluZyBtZXNzYWdlIHRvIGNhbGN1bGF0ZSBhIHBhdGguIFdoZW4gdGhlIGJhbmR3aWR0aCBy ZXF1ZXN0IGNvbWVzLCB0aGUgbm9kZSB3aWxsIGNvbXBhcmUgdGhlIHJlcXVlc3Qgd2l0aCB0aGUg bGluayBjYXBhY2l0eSB0YWJsZS4gSWYgdGhlIHJlcXVlc3QgY2FuIGJlIHNhdGlzZmllZCwgdGhl IGJhbmR3aWR0aCBpcyByZXNlcnZlZCBhbmQgdGhlIGxpbmsgY2FwYWNpdHkgdGFibGUgaXMgdXBk YXRlZC4NCg0KMy4gV2hhdCB3aWxsIGhhcHBlbiBpZiB0aGVyZSBhcmUgdHdvIGxpbmtzIGJldHdl ZW4gQyBhbmQgRChzZWUgdGhlIGZpZ3VyZSBpbiB0aGUgc2xpZGVzKSwgd2lsbCBpdCBlbmQgdXAg d2l0aCBtdWx0aXBsZSBwYXRoPw0KW0F1dGhvcnNdIFdoZW4gdGhlcmUgYXJlIG11bHRpcGxlIGxp bmtzIGJldHdlZW4gdHdvIG5vZGVzLCB0aGUgbGluayBhZ2dyZWdhdGlvbiBtYXkgYmUgdXNlZCBz byB0aGF0IHRoZSB0d28gbGlua3MgY2FuIGJlIHRyZWF0ZWQgYXMgb25lIGxvZ2ljIGxpbmsuICBB bmQgdGhlIGxpbmsgYWdncmVnYXRpb24gc2hvdWxkIGJlIHRyYW5zcGFyZW50IHRvIHJlc291cmNl IHJlc3ZlcmF0aW9uIGFzIGl0IGJlbG9uZ3MgdG8gdGhlIGxpbmsgbGF5ZXIgdGVjaG5vbG9neSwg DQoNCjQuIFdoZW4gdGhlIHJlcXVpcmVtZW50cyBpbiB0aGUgUEFUSCBtZXNzYWdlIGNvdWxkbid0 IGJlIHNhdGlzZmllZCwgRCBzaG91bGQgc2VuZCB0aGUgUEFUSEVSUiBtZXNzYWdlLg0KW0F1dGhv cnNdIElmIHRoZSByZXF1aXJlbWVudHMgY291bGRuJ3QgYmUgc2F0aXNmaWVkLCB0byBrZWVwIHRo ZSBjb25zaXN0ZW50IHdpdGggdGhlIG5vcm1hbCBwcm9jZXNzLCB0aGUgcmVzdiBwcm9jZXNzIGlz IHRlcm1pbmF0ZWQgYXQgQywgQyBzaG91bGQgc2VuZCB0aGUgUEFUSEVSUiBtZXNzYWdlLCAgYW5k IFJFU1YgbWVzc2FnZSB3b24ndCBiZSBwYXNzZWQgdG8gRC4NCg0KNS4gSW4gVFNWV0csIHRoZXJl J3MgYSBkcmFmdCBvbiBtdWx0aXBsZS1UU1BFQyB3aGljaCBtaWdodCBiZSB1c2VmdWwgaW4gdGhp cyBjYXNlLiANCltBdXRob3JzXSBBZnRlciBsb29raW5nIGludG8gdGhlIGRyYWZ0LWlldGYtdHN2 d2ctaW50c2Vydi1tdWx0aXBsZS10c3BlYy0wMiwgaXQgbWlnaHQgd29yayB0byBhZGQgYSBhdmFp bGFiaWxpdHkgZmllbGQgaW4gdGhlIFRTUEVDIGluc3RlYWQgb2YgaGF2aW5nIGEgc3ViLVRMViBp biBiYW5kd2lkaHQgcHJvZmlsZSBUTFYgKCBpZiBJIHVuZGVyc3RhbmQgY29ycmVsdHkpLiANCg0K DQpUaGFuayBLaHV6ZW1hLCBMb3UsIFl1amksIERpZXRlciB0byBnaXZlIHRoZWlyIGNvbW1lbnRz LiBBbmQgbW9yZSBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQoNCkJSLA0KQW15IFllKG9uIGJl aGFsZiBvZiBjby1hdXRob3JzKQ0KDQoNCg0K ------=_NextPart_000_0D39_01CE8ED8.6B232AB0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjIzNDg3Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PkhpIENDQU1QZXJzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+VGhlcmUgd2VyZSBzb21lIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYWZ0ZXIgDQp0aGUgcHJl c2VudGF0aW9uIG9mIDxFTT5kcmFmdC1sb25nLWNjYW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2YWls YWJpbGl0eTwvRU0+IGFuZCANCjxFTT5kcmFmdC1sb25nLWNjYW1wLW9zcGYtYXZhaWxhYmlsaXR5 LWV4dGVuc2lvbjwvRU0+LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+QmVsb3cgYXJlIHRoZSBjb21tZW50cyBhbmQgDQpyZXBsaWVzOjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+MS4gVGhlIG1vdGl2YXRpb24gPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltBdXRob3JzXSBGb3Ig dGhlIGxpbmtzIHdpdGggdmFyaWFibGUgZGlzY3JldGUgDQpiYW5kd2lkdGgsIGF2YWlsYWJpbGl0 eSBpcyB1c2VkIHRvIGRlY3JpYmUgdGhlIGJhbmR3aWR0aC4gSXQncyBwcm9wb3NlZCB0byANCmFk ZCZuYnNwO3RoZSBhdmFpbGFiaWxpdHkgYXMgYW4gcGFyYW10ZXIgYWxvbmcgd2l0aCB0aGUgYmFu ZHdpZHRoIHJlcXVlc3QuIA0KV2l0aG91dCB0aGlzIGV4dGVuc2lvbiwgdGhlIGxpbmsgYmFuZHdp ZHRoIGNhbm5vdCBnZXQgZ29vZCB1dGlsaXphdGlvbjogZm9yIA0KZXhhbXBsZSwgdGhlIG5vZGUg bWF5IHJlc2VydmUgdGhlIGJhbmR3aWR0aCB3aXRoJm5ic3A7OTkuOTk5JSBhdmFpbGFiaWxpdHkg d2hpbGUgDQp0aGUgYWN0dWFsIHJlcXVpcmVtZW50IGlzIG9ubHkgOTkuOSUsJm5ic3A7YW5kIGNv bnNlcXVlbnRseSBpdCBjYW4gbm90IHJlc2VydmUgDQp0aGUgYmFuZHdpZHRoIHdoZW4gdGhlIHJl YWwgcmVxdWlyZW1lbnQgd2l0aCA5OS45OTklIGF2YWlsYWJpbGl0eSANCmNvbWVzLjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCANCnNpemU9MiBmYWNlPcvOzOU+PC9GT05UPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4yLiBUaGUg bWVjaGFuaXNtLCBob3cgdG8gdXNlIHRoZSBhdmFpbGFiaWxpdHkgDQpwcm9maWxlPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltBdXRob3JzXSZuYnNwO09u Y2UgdGhlIGxpbmsgaXMgc2V0IHVwLCB0aGUgDQppbmZvcm1hdGlvbiBvbiBhdmFpbGFiaWxpdHkg YW5kIGJhbmR3aWR0aCBpcyBzYXZlZCBpbiB0aGUgbGluayBiYW5kd2lkdGggDQpjYXBhY2l0eSB0 YWJsZSBvbiBsb2NhbCBub2RlLCBhbmQgc2hvdWxkIGFsc28gYmUgcHJvcGFnYXRlZCBpbiB0aGUg cm91dGluZyANCm1lc3NhZ2UgdG8gY2FsY3VsYXRlIGEgcGF0aC4gV2hlbiB0aGUgYmFuZHdpZHRo IHJlcXVlc3QgY29tZXMsIHRoZSBub2RlIHdpbGwgDQpjb21wYXJlIHRoZSByZXF1ZXN0IHdpdGgg dGhlIGxpbmsgY2FwYWNpdHkgdGFibGUuIElmIHRoZSByZXF1ZXN0IGNhbiBiZSANCnNhdGlzZmll ZCwgdGhlIGJhbmR3aWR0aCBpcyByZXNlcnZlZCBhbmQgdGhlIGxpbmsgY2FwYWNpdHkgdGFibGUg aXMgDQp1cGRhdGVkLjxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+My4gV2hhdCB3aWxsIGhhcHBlbiBpZiB0aGVyZSBhcmUgdHdvIGxpbmtzIA0KYmV0 d2VlbiBDIGFuZCBEKHNlZSB0aGUgZmlndXJlIGluIHRoZSBzbGlkZXMpLCB3aWxsIGl0IGVuZCB1 cCB3aXRoIG11bHRpcGxlIA0KcGF0aD88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+W0F1dGhvcnNdIFdoZW4gdGhlcmUgYXJlIG11bHRpcGxlIGxpbmtzIA0K YmV0d2VlbiB0d28gbm9kZXMsIHRoZSBsaW5rIGFnZ3JlZ2F0aW9uJm5ic3A7bWF5IGJlIHVzZWQg c28gdGhhdCB0aGUgdHdvIGxpbmtzIA0KY2FuIGJlIHRyZWF0ZWQgYXMgb25lIGxvZ2ljIGxpbmsu Jm5ic3A7Jm5ic3A7QW5kIHRoZSZuYnNwO2xpbmsgYWdncmVnYXRpb24gDQpzaG91bGQgYmUgdHJh bnNwYXJlbnQgdG8gcmVzb3VyY2UgcmVzdmVyYXRpb24gYXMgaXQgYmVsb25ncyB0byB0aGUgbGlu ayBsYXllciANCnRlY2hub2xvZ3ksIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+NC4gV2hlbiB0aGUgcmVxdWlyZW1lbnRzIGluIHRoZSBQQVRIIG1lc3NhZ2Ug DQpjb3VsZG4ndCBiZSBzYXRpc2ZpZWQsJm5ic3A7RCBzaG91bGQgc2VuZCB0aGUgUEFUSEVSUiBt ZXNzYWdlLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5b QXV0aG9yc10gSWYgdGhlIHJlcXVpcmVtZW50cyBjb3VsZG4ndCBiZSANCnNhdGlzZmllZCwgdG8g a2VlcCB0aGUgY29uc2lzdGVudCB3aXRoIHRoZSBub3JtYWwgcHJvY2VzcywgdGhlJm5ic3A7cmVz diBwcm9jZXNzIA0KaXMgdGVybWluYXRlZCZuYnNwO2F0IEMsIEMgc2hvdWxkIHNlbmQgdGhlIFBB VEhFUlIgbWVzc2FnZSwmbmJzcDsmbmJzcDthbmQgUkVTViANCm1lc3NhZ2Ugd29uJ3QgYmUgcGFz c2VkIHRvIEQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj41 LiBJbiBUU1ZXRywgdGhlcmUncyBhIGRyYWZ0IG9uIG11bHRpcGxlLVRTUEVDIA0Kd2hpY2ggbWln aHQgYmUgdXNlZnVsIGluIHRoaXMgY2FzZS4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+W0F1dGhvcnNdIEFmdGVyIGxvb2tpbmcgaW50byB0aGUg DQpkcmFmdC1pZXRmLXRzdndnLWludHNlcnYtbXVsdGlwbGUtdHNwZWMtMDIsJm5ic3A7aXQgbWln aHQmbmJzcDt3b3JrIHRvIGFkZCBhIA0KYXZhaWxhYmlsaXR5IGZpZWxkIGluIHRoZSBUU1BFQyBp bnN0ZWFkIG9mIGhhdmluZyBhIHN1Yi1UTFYgaW4gYmFuZHdpZGh0IHByb2ZpbGUgDQpUTFYmbmJz cDsoJm5ic3A7aWYgSSB1bmRlcnN0YW5kIGNvcnJlbHR5KS4gPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRoYW5rJm5ic3A7S2h1emVtYSwgTG91LCBZdWpp LCBEaWV0ZXIgdG8gZ2l2ZSANCnRoZWlyIGNvbW1lbnRzLiBBbmQgbW9yZSBjb21tZW50cyBhcmUg YXBwcmVjaWF0ZWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij5CUiw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+QW15 IFllKG9uIGJlaGFsZiBvZiBjby1hdXRob3JzKTwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFj ZT3LzszlPjwvRk9OVD48QlI+PEJSPjwvRElWPjwvRk9OVD4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0D39_01CE8ED8.6B232AB0-- From adrian@olddog.co.uk Thu Aug 1 07:15:11 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A569921E8206 for ; Thu, 1 Aug 2013 07:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1KmeZp9Ow0I for ; Thu, 1 Aug 2013 07:15:06 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id F1C4221E81B3 for ; Thu, 1 Aug 2013 07:15:04 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r71EF3ZX014677 for ; Thu, 1 Aug 2013 15:15:03 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r71EF2Di014656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 1 Aug 2013 15:15:03 +0100 From: "Adrian Farrel" To: "'CCAMP'" References: <51F9405B.5040008@labn.net> In-Reply-To: <51F9405B.5040008@labn.net> Date: Thu, 1 Aug 2013 15:15:00 +0100 Message-ID: <079401ce8ec1$832cd9b0$89868d10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGp4v4RR/QkBvbFjNsb5rNwK/1eZJnJvHCg Content-Language: en-gb Subject: Re: [CCAMP] rough minutes for Berlin CCAMP meetings X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:15:11 -0000 Thanks to chairs and note-takers for getting this together speedily and = posting while we still remember (well, those of us who are not aged ADs) = what happened. Good job. Adrian > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of > Lou Berger > Sent: 31 July 2013 17:51 > To: CCAMP > Subject: [CCAMP] rough minutes for Berlin CCAMP meetings >=20 >=20 > As before, it would be best to enter corrections on > http://tools.ietf.org/wg/ccamp/minutes (send mail to list if you = can't). >=20 > Discussion should take place on the list and *not* in etherpad. >=20 > Much thanks to our secretaries and all who contributed to the notes. >=20 > Lou >=20 > > CCAMP Agenda For IETF 87 > > CCAMP Agenda For IETF 87 > > Version: Jul 22, 2013 > > > > First Session > > TUESDAY, July 30, 2013 > > 1700-1830 Afternoon Session III > > Room: Potsdam 3 > > Presentation Start Time Duration Information > > 0 17:00 10 Title: Administrivia & WG Status > > Draft: > > Presenter: Chairs >=20 > Fatai Zhang: After this meeting we plan to update > [draft-ietf-ccamp-otn-g709-info-model] and > [draft-ietf-ccamp-gmpls-g709-framework] based on AD (Adrian Farrel) = review. >=20 > Comments requested on non presented WG drafts status: >=20 > =E2=80=92 draft-ietf-ccamp-rsvp-te-srlg-collect > Oscar Gonzalez de Dios: The document is stable. There is one > functionality (knowing if a RRO suboject is incomplete or has been > edited) that needs to be made generic (there was a comment from Lou > during IETF 86th). A mail was sent on 4th of July with several options > to make the functionality generic. A new mail to the CCAMP list will = be > sent this with the options. Feedback is requested from the CCAMP list. > =E2=80=92 draft-ietf-ccamp-rsvp-te-li-lb: > Daniele Ceccarelli: No changes from last meeting >=20 > > 1 17:10 8 Title: LSP Attribute in ERO > > Draft: > http://tools.ietf.org/html/draft-ietf-ccamp-lsp-attribute-ro-02 > > Presenter: Cyril Margaria >=20 > Lou Berger: I suspect that you addressed Adrian's [Farrel) comment. I > suggest you check with him via the list to confirm. >=20 > > 2 17:18 8 Title: RSVP-TE Extensions for > Associated Bidirectional LSPs > > Draft: > = http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated= -lsp-06 > > Presenter: Matt Hartley >=20 > Lou Berger: I think we can move rapidly towards Last Call. > Matt Hartley: Splendid. >=20 > > 3 17:26 8 Title: RSVP-TE extension for = recording > TE Metric of a LSP > > Draft: > http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-02 > > Presenter: George Swallow >=20 > Oscar Gonzalez de Dios: Regarding IANA requests Collision with IANA > assignment. We need to align on temporary assignments to avoid = collisions. > George Swallow: > Daniele Ceccarelli: How about we merge the drafts to minimized the > number of drafts to read? > George Swallow: We initially had this plan, but we wanted to avoid > holding up the other draft. > Lou Berger: Regarding IANA assignments, are you having similar issues = in > MPLS? (re collision of temporary assignments values). We used to have > the wiki which has not been touched for a long time. > George Swallow: I fully support it. > Dan: We used to do that but our AD suggested to stop. > Lou Berger: It's not temporary assignment it is just a way to ensure > that documents do no collide and avoid implementation issues. We will > discuss this with Adrian Farrel. Do we have someone who will take > responsibility for the CCAMP page? > Oscar Gonzalez de Dios: I volunteer. > Lou Berger: We think it would be a good idea to resurrect the wiki > Adrian: Different times wrt RFC4020. People wanted to implement and > start interop. Now that we support early allocation which gives a > codepoint for 2 years i don't think we need allocations outside IANA. > What happens if we screw up that registry? > George Swallow: We will caveat the request. > Adrian Farrel: Why not go that extra bit further and request an early > allocation. We should talk in more details chairs and ADs. > Loa Andersson: Suggestion: ask the WG chairs if the draft is stable > enough to start development, then request an early allocation. > Adrian Farrel: I suggest that if I am uneasy with this the IESG may = also > have issues. We can take this discussion offline (with CCAMP and MPLS > chairs). >=20 >=20 > > 4 17:34 8 Title: RSVP-TE LSP Route Diversity > using Exclude Routes > > Draft: > http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-02 > > Presenter: George Swallow >=20 > Fatai Zhang: I understand the motivation, but I have an issue with the > comp0lext solution. Why not use existing solution like path-key? > George Swallow: The operator may not be using PCE. We did discuss the > solution early on before this document became a WG document. > Deborah Brungard: Make sure you read the document and trigger = discussion > on the list, not wait for the meeting. >=20 >=20 > > 5 17:42 6 Title: Include Routes - Extension to > RSVP-TE > > Draft: > http://tools.ietf.org/html/draft-ali-ccamp-rsvp-te-include-route-04 > > Presenter: George Swallow >=20 > Khuzema Pithewan: There are elements (constraints) influencing a = section > or complete path of an LSP, these need to be managed. > George Swallow: If you cannot meet all the existing constraints, as = well > as meet diverse objective, then an error will be issued. This is > described in the document. > Lou Berger: another XRO might be present and you need to consider it. > Adrian: Suggest that you rename subobject. As there might be = confusion. > George Swallow: An easy change, do you have an suggestion? > Lou Berger: "Inclusion"? > George Swallow: "Follow the breadcrumb"? Ok, we (authors) will = discuss. >=20 >=20 > > 6 17:48 5 Title: RSVP-TE Extension for Label > Switched Path (LSP) Inquiry > > Draft: > http://tools.ietf.org/html/draft-ali-ccamp-lsp-inquiry-00 > > Presenter: George Swallow >=20 > Lou Berger: Off course reusing existing mechanisms is good, if you > manage to reuse also existing terminology its better. > George Swallow: Yes. > Khuzema Pithewan: This will affect existing services. > George Swallow: This is signaled from the IP plane, so we assume that > you are in a maintenance window. > Dieter Beller: There are technologies out there that allow soft set up > of resources. Are you envisaging to cover also those technologies? > George Swallow: We see this being used for shared mesh protection in > optical environments. > Dieter Beller: I'm talking about technologies that in tens of ms are > able to tear down an LSP and setup the protecting one. > Xian: I don't follow the motivation for the second type of inquiry. = What > is its usage? Have you considered using calls? > George Swallow: I'm not familiar with that particular mechanism. > Lou Berger: Not sure how it would help. >=20 > > 7 17:53 5 Title: RSVP-TE Extension for = Signaling > Objective Function and Metric Bound > > Draft: > = http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function-metric-b= ound-03 > > Presenter: George Swallow >=20 > Lou Berger: how many people think it's a useful function (good number) > How many read? (slightly less) > How many think this is a good foundation? (slightly less) > Cyril Margaria: Mechanisms defined in = draft-ietf-ccamp-lsp-attribute-ro > are meant for this kind of information > Oscar Gonzalez de Dios: Not only in this draft but in others you add > path computation constraints like include/exclude things. When path > computation is done in the middle of the network one may want to pass > all the path computation constraints in RSVP-TE. However, in the > proposal, you are duplicating PCEP objects. > Lou; we followed the approach that we can distribute path computation. > Oscar Gonzalez de Dios: Not what I meant. I mean that if there is > already a complete syntax to express path computation constraints, > inclusions/exclusions, etc, why not reuse it? > Lou Berger: Can you make this suggestion on the list? > Fatai Zhang: not sure about the value of this draft. >=20 >=20 > > 8 17:58 5 Title: RSVP-TE Signaling Extension = for > Bandwidth availability > > Draft: > = http://tools.ietf.org/html/draft-long-ccamp-rsvp-te-bandwidth-availabilit= y-01 > > Presenter: Min Ye >=20 > Lou Berger: See the TSV WG [Tunnel Congestion I-D?], there could be > overlap with your draft. > Khuzema Pithewan: you might end up multiple lengths to satisfy a > bandwidth request. >=20 > > 9 18:03 5 Title: OSPF Routing Extension for > links with variable discrete bandwidth > > Draft: > = http://tools.ietf.org/html/draft-long-ccamp-ospf-availability-extension-0= 0 > > Presenter: Min Ye > Matt Hartley: Should this be an OSPF WG draft? > Lou Berger: in the past we agreed with the OSPF chairs that it is > possible to make OSPF changes in CCAMP. >=20 > > 10 18:08 7 Title: Domain Subobjects for = Resource > ReserVation Protocol =E2=80=93 Traffic Engineering (RSVP-TE) > > Draft: > = http://tools.ietf.org/html/draft-dhody-ccamp-rsvp-te-domain-subobjects-02= > > Presenter: Dhruv Dhody >=20 > Deborah Brungard: [Poll] > How many think it's useful? [good number], How many have read [good > number] Take to the list >=20 > > 11 18:15 5 Title: A SNMP MIB to manage GMPLS > with General Constraints Support > > Draft: > http://tools.ietf.org/html/draft-gmggm-ccamp-gencons-snmp-mib-02 > > Presenter: Giovanni Martinelli >=20 > Lou Berger: I think this document is timed perfectly in relation to = the > WSON work. > Fatai Zhang: General comment. When do we need MIB drafts? Do we need = it > in this case? Some MIB drafts are on the CCAMP page and are not = updated > for years. > Deborah Brungard: Some people use SNMP as management interface, some > others use different management protocols > Adrian: You are not required to write MIB modules. You are required to > discuss how your network may be managed. >=20 > > 12 18:20 5 Title: Information Model for WSONs > with Impairments Validation > > Draft: > http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-info-02 > > Presenter: Giovanni Martinelli >=20 > Dieter Beller: Considering we do not have data plane interop, and a > computation capability to compute end-to-end, find this work a little = early? > Giovanni: What do you mean that there is no data plane compatibility? > The answer from ITU-T folks was that there could be some multivendor = case. > Dieter From the discussion in Orlando interop is not currently = capable, > so is development of an information model too soon? > Giovanni: The compatibility will come, we cannot make any public > statement now. There are some parameters that no one cares how are > computed. > Dieter Beller: We are supposed to develop standard that provide > interoperability > Giovanni: Yes. At the control plane. > Deborah Brungard: I suggest to talk with Q6 guys. Interim meeting, to > help define. >=20 > > 13 18:25 5 Title: Information Encoding for = WSON > with Impairments Validation > > Draft: > http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-encode-02 > > Presenter: Giovanni Martinelli >=20 > No comments. >=20 >=20 >=20 >=20 > > Adjourn 18:30 > > > > Second Session > > WEDNESDAY, July 31, 2013 > > 1300-1500 > > Room: Potsdam 1 > > Presentation Start Time Duration Information > > 0 13:00 5 Title: Administrivia > > Draft: > > Presenter: Chairs >=20 > > 14 13:05 8 Title: Framework and Requirements = for > GMPLS based control of Flexi-grid DWDM networks > > Draft: > http://tools.ietf.org/html/draft-ogrcetal-ccamp-flexi-grid-fwk-03 > > Presenter: Oscar Gonzalez de Dios >=20 > Deborah Brungard: we have a lot of liaisons from ITU-T. G.872 was = consented? > Malcolm: G.872 has been consented. > Deborah Brungard: has it been sent to the CCAMP? > Malcolm: I think it is worth sending a specific Liaison to Q6. > Lou Berger: polling on usefulness, reading and support as foundation = of > WG work. Good support. Confirm on the list. >=20 > > 15 13:13 8 Title: RSVP-TE Signaling Extensions > in support of Flexible Grid > > Draft: > = http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-rsvp-te-ext-02= > > Presenter: Xian Zhang >=20 > Giovanni: what happens if the LSP needs to be resized? > Xian: > Lou Berger: The document is in an early stage of development. [Poll] = How > many have read? How many support? Pretty good number but less than = FWK. > We may poll before the next meeting, assuming adoption of the = framework > document. > Iftekar: It seems that this document isn't as well developed. Does it > make sense to adopt. > Lou Berger: We can adopt early if it makes sense. remember that > adoption is the start of the WG's technical work, not a statement that = a > documented solution is completely correct. if you feel the document is > not ready or heading in the wrong direction, then you should bring any > comments to the list. > Iftekar: [?] > Giovanni: WG can judge if the document is suitable, but it maybe = early. > Lou Berger: So you feel adopting the document is premature? > Giovanni: Yes. >=20 > > 16 13:21 8 Title: GMPLS OSPF-TE Extensions in > support of Flexible Grid DWDM Networks > > Draft: > http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-ospf-ext-02 > > Presenter: Ramon Casellas >=20 > Cyril Margaria: A bit too early to make it a wg document > Lou Berger: Specific technical issues? > Cyril Margaria: no > Lou Berger: Okay, then please review and send specific comments to the = list. > Lou Berger: General comment. Please take advantage of the list to = raise > comments and objections, lack of discussion may be misconstrued as > concurrence or disinterest. >=20 > Fatai Zhang: We could adopt the framework and label drafts and then > speak about signaling and routing > Lou Berger: Can you make this suggestion on the list once the result = of > the framework adoption poll is known? >=20 > > 17 13:29 7 Title: An SNMP MIB extension to > RFC3591 to manage optical interface parameters of DWDM applications > > Draft: > http://tools.ietf.org/html/draft-galikunze-ccamp-g-698-2-snmp-mib-03 > > Presenter: Gabriele Galimberti > > 18 13:36 7 Title: An SNMP MIB extension to > RFC3591 to manage optical interface parameters of DWDM applications > > Draft: > http://tools.ietf.org/html/draft-galikunze-ccamp-opt-imp-snmp-mib-00 > > Presenter: Gabriele Galimberti >=20 > Gert Grammel: These two drafts are covering the same content of the = one > we discussed in Orlando? > Gabriele Galimberti: one is covering what is in the ITU-T = recommendation > and the other one what is not there. They are complimentary. > Deborah Brungard: [Poll] How many have read the document? [Not too = many] > Hopefully we will see a Liaison to help us progress these documents. >=20 > > 19 13:43 8 Title: Extension to the LMP for = DWDM > Optical Line Systems to manage optical parameters of DWDM applications > > Draft: > http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp-03 > > > http://tools.ietf.org/html/draft-dharinigert-ccamp-opt-imp-lmp-00 > > Presenter: Gert Grammel >=20 > Deborah Brungard: If you not use the application codes, the set of > parameters you are defining is enough to provide interoperability? > Gert Grammel: If it is a standard application code then it is > interoperable. If it is not a standards application code, then... > Deborah Brungard: it would be good to take it to Q6 > [Poll] Is draft-dharinigert-ccamp-opt-imp-lmp-00 useful, [a reasonable > number]. Poll for 698.2 lmp same number. Poll for opt imp lmp same = number -1 >=20 >=20 > > 20 13:51 7 Title: Use cases for operating > networks in the overlay model context > > Draft: > = http://tools.ietf.org/html/draft-ceccadedios-ccamp-overlay-use-cases-01 > > Presenter: Daniele Ceccarelli > (single presentation for next) > > 21 13:58 8 Title: Applicability of = Generalized > Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI) > > Draft: > http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-uni-app-04 > > Presenter: Daniele Ceccarelli >=20 > Adrian Farrel: AD hat off - My name appears on applicability I-D, but > not on the use cases. This is not an accident, if we go for option 1 > fine, if we go for option 2 I would not support. I do not think the > approach is good or even possible. This is not how we should build = networks. > Lou Berger: Do you believe that sharing network information between > domains is not acceptable? > Adrian Farrel: No, in fact I am working on a document that facilitates > this. My issue is the mechanisms used to exchange information. > Lou Berger: At the overlay provider, what used to be called L1VPN > enhanced mode would this be acceptable? > Adrian Farrel: architecture or protocol? We did discuss solutions, = three > options including an inter-domain routing protocol. > Lou Berger: In theory you support this, but you have an issue with one > of the solutions. > Adrian Farrel: > Lou Berger: Layer you communicate at Vs. ... > Adrian Farrel: My view as a WG participant is that we need to step = back > and discuss the architecture, then solution work. > Oscar; When I began this work I wanted to discuss the use cases and > describe the architecture, rather than develop solutions. > Lou Berger: so maybe we should step back and review the architecture. > Actually we have other documents that discuss the work. > Julien Meuric: [slide UNI/ONI Use case] this feels like transport > recovery mechanisms being pushed into the packet layer. > Daniele Ceccarelli: The intention was to demonstrate how it is = possible > mix the advantages of the two layers > Deborah Brungard: I suggest we break up the examples and post to the > list and request feedback. > Lou Berger: Happy to hear the authors are looking at taking a step = back > and revisiting their drafts. When doing this please look at other > individual drafts that may have related text and work with those = other > authors. Also consider the differences between UNI and ENNI, which > operate in a single layer, and the concepts of L1VPN basic and = enhanced > mode which can be leveraged for cross client/server layers -- which = is > perhaps what's intended by ONI. >=20 > > 22 14:06 5 Title: Extensions to RSVP-TE for > Error Notication in GMPLS User-Network Interface (UNI) > > Draft: > = http://tools.ietf.org/html/draft-ali-ccamp-gmpls-uni-error-notification-0= 0 > > Presenter: Matt Hartley >=20 > Igor Bryskin: What happens if the notification is not received? > The edge node will not find out. > Igor Bryskin: most of that solutions don't work. What you need is some > reliable mechanism to do it. > Matt Hartley: It'll work the way RSVP-TE always works. > Igor Bryskin: you should think about a reliable notify delivery > Lou Berger: This is a general issue with RSVP and beyond the scope of > this single document > Matt Hartley: > Cyril Margaria: This mechanisms seems to apply to UNI, we need a = general > mechanism. > Lou Berger: This leads to a question that I had, why is the general > address mapping/hiding mechanism defined RFC4208 insufficient? > Matt Hartley: will have to look at that > Adrian: The question I sent on the mailing list is that what you want = to > define is already there in RFC4783 > Matt Hartley: If you can send this comment to the list I can review = and > comment. > Deborah Brungard: Are you looking at segment protection in the core? > Lou Berger: what you are looking for is a single error value? (Matt > Hartley: Yes) It seems it's going to be a short draft. >=20 > > 23 14:11 8 Title: UNI Extensions for Diversity > and Latency Support > > Draft: > http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-02 > > Presenter: Dieter Beller >=20 > Lou Berger: [slide - relationships with prior work] Do you think that > your document is related to Daniele's > [draft-ceccadedios-ccamp-overlay-use-cases and ] presentation? > Dieter Beller: Yes. > Lou Berger: I suggest you take advantage of the time this week and see > how these documents fit together. And then update the documents/WG > accordingly. >=20 >=20 > > 24 14:19 8 Title: Mutually Exclusive Link = Group > (MELG) > > Draft: > http://tools.ietf.org/html/draft-beeram-ccamp-melg-01 > > Presenter: Vishnu Pavan Beeram >=20 > Lou Berger: [slide - 4] A clarification question, is this a virtual TE > link, or an actual TE link? > Vishnu Pavan Beeram: a virtual TE link > Lou Berger: Based on existing work (RFCs), there is no distinction > between virtual TE link and an actual TE link in the client topology. > This is a significant change. > Vishnu Pavan Beeram: We can make a note of this in the document. > George Swallow: At what point would you advertise mutual exclusivity, = do > you wait until it is setup? If this is the direction, how many do you > advertise, why not include this in the draft. > Igor Bryskin: we did consider this and we think to expand the concept = of > SRLG. [Will poke Igor to provide his comments.] > Deborah Brungard: [poll] how many think this is interesting? not to > many, try to raise interest. >=20 > > 25 14:27 8 Title: OSPF-TE extensions for = MLNMRN > based on OTN > > Draft: > http://tools.ietf.org/html/draft-rao-ccamp-mlnmrn-otn-ospfte-ext-02 > > Presenter: Khuzema Pithewan >=20 > Lou Berger: Do you require anything from signaling? > Khuzema Pithewan: yes, maybe yes. > Fatai Zhang: >=20 > > 26 14:35 8 Title: GMPLS-based Hierarchy LSP > Creation in Multi-Region and Multi-Layer Networks > > Draft: > http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-h-lsp-mln-05 > > Presenter: Xian Zhang >=20 > Lou Berger: Do you need anything from routing to make the signaling = work? > Cyril Margaria: You don't know where you originate > Lou Berger: I do not understand, can you discuss with the previous > authors and see if anything needs to be aligned. > Cyril Margaria: no we don't need igp extensions. > Khuzema Pithewan: If you are in a single domain you definitely need > routing extensions > Lou Berger: Please review RFC6107 as some of these mechanisms may > already be described. >=20 >=20 > > 27 14:43 5 Title: RSVP-TE Extensions For > Signaling GMPLS Restoration LSP > > Draft: > http://tools.ietf.org/html/draft-gandhi-ccamp-gmpls-restoration-lsp-01 > > Presenter: Gabriele Galimberti >=20 > Igor Bryskin: why are you requesting feedbacks if 2 years ago we > presented a similar draft and there was no interest? >=20 > Lou Berger: Cyril are you willing to work on a BCP with the authors, I > think we agree that mechanisms exist but we need to document how they > might be used. We do not have time to discuss, so let=E2=80=99s take = this offline. >=20 >=20 > > 28 14:48 7 Title: Update Forced Switch = Priority > > Draft: > http://tools.ietf.org/html/draft-helvoort-ccamp-fs-priority-00 > > Presenter: Huub van Helvoort >=20 > Lou Berger: You mentioned on the list that this draft was in response = to > a message that I sent. The message stated that a combined change was > needed to 4427 and 6372, but this draft only covers 4427. Also I was > mistaken in my statement WRT 4427, as it doesn't state relative > priorities. That is stated only in 6372. There are other discussions = on > this topic going on, and this draft should be taken forward in a = manner > consistent with those discussions. >=20 > > 29 14:55 5 Title: RSVP-TE Extensions for Bit > Error Rate (BER) Measurement > > Draft: > http://tools.ietf.org/html/draft-zhang-ccamp-rsvpte-ber-measure-00 > > Presenter: Zhenbin Li > > Adjourn 15:00 >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From internet-drafts@ietf.org Fri Aug 2 01:54:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04D111E82CC; Fri, 2 Aug 2013 01:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B25HmXvBKlmK; Fri, 2 Aug 2013 01:54:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FE721E8249; Fri, 2 Aug 2013 01:51:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130802085106.18382.1671.idtracker@ietfa.amsl.com> Date: Fri, 02 Aug 2013 01:51:06 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-g709-framework-14.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:54:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Framework for GMPLS and PCE Control of G.709 Optical Tra= nsport Networks Author(s) : Fatai Zhang Dan Li Han Li Sergio Belotti Daniele Ceccarelli Filename : draft-ietf-ccamp-gmpls-g709-framework-14.txt Pages : 27 Date : 2013-08-02 Abstract: This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as published in 2012. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-g709-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-g709-framework-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhangfatai@huawei.com Fri Aug 2 02:10:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AD411E839F for ; Fri, 2 Aug 2013 02:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.987 X-Spam-Level: * X-Spam-Status: No, score=1.987 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-aWJC8Txoy1 for ; Fri, 2 Aug 2013 02:10:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEC911E833F for ; Fri, 2 Aug 2013 02:07:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVR02051; Fri, 02 Aug 2013 09:07:43 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 10:07:25 +0100 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 10:07:41 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.007; Fri, 2 Aug 2013 17:07:36 +0800 From: Fatai Zhang To: "adrian@olddog.co.uk" , "ccamp@ietf.org" , Lou Berger , "BRUNGARD, DEBORAH A" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-g709-framework-14.txt Thread-Index: AQHOj15vXzG7juatvkqkfdfNkod4tJmBnqkw Date: Fri, 2 Aug 2013 09:07:35 +0000 Message-ID: References: <20130802085106.18382.1671.idtracker@ietfa.amsl.com> In-Reply-To: <20130802085106.18382.1671.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.218.249] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh?= =?gb2312?b?bXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMTQudHh0?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:10:26 -0000 X-List-Received-Date: Fri, 02 Aug 2013 09:10:26 -0000 SGkgQWRyaWFuLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBzdWdnZXN0aW9ucy4NCg0K VG8gc3BlZWQgdXAgT1ROIHdvcmssIEkgZ290IGhlbHAgZnJvbSBteSBjb2xsZWFndWUgQFNoZW56 aGVuIHRvIGNvbnZlcnQgbXkgTVMgV29yZCBkb2N1bWVudCB0byB0eHQuDQoNCkkgdGhpbmsgYWxs IHlvdXIgY29tbWVudHMgaGF2ZSBiZWVuIGFkZHJlc3NlZCwgcGxlYXNlIGNoZWNrIGlmIGl0IHNh dGlzZmllcyB5b3UuIA0KDQoNCg0KVGhhbmtzDQoNCkZhdGFpDQoNCg0KDQotLS0tLdPKvP7Urbz+ LS0tLS0NCreivP7IyzogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQq3osvNyrG85DogMjAx M8TqONTCMsjVIDE2OjUxDQrK1bz+yMs6IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0Ks63LzTogY2Nh bXBAaWV0Zi5vcmcNCtb3zOI6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1nNzA5LWZyYW1ld29yay0xNC50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQog VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1 cmVtZW50IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCglUaXRsZSAgICAgICAg ICAgOiBGcmFtZXdvcmsgZm9yIEdNUExTIGFuZCBQQ0UgQ29udHJvbCBvZiBHLjcwOSBPcHRpY2Fs IFRyYW5zcG9ydCBOZXR3b3Jrcw0KCUF1dGhvcihzKSAgICAgICA6IEZhdGFpIFpoYW5nDQogICAg ICAgICAgICAgICAgICAgICAgICAgIERhbiBMaQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBI YW4gTGkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgU2VyZ2lvIEJlbG90dGkNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgRGFuaWVsZSBDZWNjYXJlbGxpDQoJRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0xNC50eHQNCglQYWdlcyAgICAg ICAgICAgOiAyNw0KCURhdGUgICAgICAgICAgICA6IDIwMTMtMDgtMDINCg0KQWJzdHJhY3Q6DQog ICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgZnJhbWV3b3JrIHRvIGFsbG93IHRoZSBkZXZlbG9w bWVudCBvZg0KICAgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBzdXBwb3J0IEdlbmVyYWxpemVkIE11 bHRpLVByb3RvY29sIExhYmVsDQogICBTd2l0Y2hpbmcgKEdNUExTKSBhbmQgUGF0aCBDb21wdXRh dGlvbiBFbGVtZW50IChQQ0UpIGNvbnRyb2wgb2YNCiAgIE9wdGljYWwgVHJhbnNwb3J0IE5ldHdv cmtzIChPVE4pIGFzIHNwZWNpZmllZCBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbg0KICAgRy43MDkg YXMgcHVibGlzaGVkIGluIDIwMTIuDQoNCg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yaw0KDQpUaGVyZSdzIGFsc28g YSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMTQNCg0KQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cDovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0x NA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== From zhangfatai@huawei.com Fri Aug 2 02:52:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA86A21E8271 for ; Fri, 2 Aug 2013 02:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=3.181, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSeVQD2losiF for ; Fri, 2 Aug 2013 02:52:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 26C4B11E8210 for ; Fri, 2 Aug 2013 02:51:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUA50163; Fri, 02 Aug 2013 09:51:56 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 10:51:29 +0100 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 10:51:44 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 2 Aug 2013 17:51:37 +0800 From: Fatai Zhang To: Lou Berger , "George Swallow (swallow)" Thread-Topic: =?utf-8?B?Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1sc3AtZGl2ZXJzaXR5LTAy?= =?utf-8?B?Ly8g562U5aSNOiBbQ0NBTVBdIHJvdWdoIG1pbnV0ZXMgZm9yIEJlcmxpbiBD?= =?utf-8?Q?CAMP_meetings?= Thread-Index: AQHOjg4zm356AwRGlUOmRvnwiH+V6pmBrWaw Date: Fri, 2 Aug 2013 09:51:36 +0000 Message-ID: References: <51F9405B.5040008@labn.net> In-Reply-To: <51F9405B.5040008@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.218.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: [CCAMP] =?utf-8?q?Comments_on_draft-ietf-ccamp-lsp-diversity-02//?= =?utf-8?q?_=E7=AD=94=E5=A4=8D=3A__rough_minutes_for_Berlin_CCAMP_meetings?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:52:30 -0000 SGkgR2VvcmdlLA0KDQpJIG1lYW50IFJTVlAtVEUgUGF0aCBLZXkgU3Vib2JqZWN0IGRlZmluZWQg aW4gUkZDNTU1MyByYXRoZXIgdGhhbiBQQ0Ugc3R1ZmYgd2hlbiBJIG1lbnRpb25lZCBQYXRoIEtl eS4NCg0KSSBhbSBtYWtpbmcgYSBkcmFmdCB0byB1c2UgUGF0aCBLZXkgU3Vib2JqZWN0IHRvIGFk ZHJlc3MgeW91ciBkaXZlcnNpdHkgcmVxdWlyZW1lbnQsIHdoaWNoIGlzIHF1aXRlIHNpbXBsZSBh bmQgc3RyYWlnaHRmb3J3YXJkLiANCg0KSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIG15IGRyYWZ0 IHRoYXQgSSBhbSBtYWtpbmcsIHdlbGNvbWUgeW91IHRvIGpvaW4gdXMuDQoNCg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gNCAgICAgICAgICAg MTc6MzQgICAgIDggICAgIFRpdGxlOiAgICAgUlNWUC1URSBMU1AgUm91dGUgRGl2ZXJzaXR5DQp1 c2luZyBFeGNsdWRlIFJvdXRlcw0KPiAgICAgICAgICAgICAgICAgRHJhZnQ6DQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLWxzcC1kaXZlcnNpdHktMDINCj4gICAg ICAgICAgICAgICAgIFByZXNlbnRlcjogICAgIEdlb3JnZSBTd2FsbG93DQoNCkZhdGFpIFpoYW5n OiBJIHVuZGVyc3RhbmQgdGhlIG1vdGl2YXRpb24sIGJ1dCBJIGhhdmUgYW4gaXNzdWUgd2l0aCB0 aGUgY29tcDBsZXh0IHNvbHV0aW9uLiBXaHkgbm90IHVzZSBleGlzdGluZyBzb2x1dGlvbiBsaWtl IHBhdGgta2V5Pw0KR2VvcmdlIFN3YWxsb3c6IFRoZSBvcGVyYXRvciBtYXkgbm90IGJlIHVzaW5n IFBDRS4gV2UgZGlkIGRpc2N1c3MgdGhlIHNvbHV0aW9uIGVhcmx5IG9uIGJlZm9yZSB0aGlzIGRv Y3VtZW50IGJlY2FtZSBhIFdHIGRvY3VtZW50Lg0KRGVib3JhaCBCcnVuZ2FyZDogTWFrZSBzdXJl IHlvdSByZWFkIHRoZSBkb2N1bWVudCBhbmQgdHJpZ2dlciBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0 LCBub3Qgd2FpdCBmb3IgdGhlIG1lZXRpbmcuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNClRoYW5rcw0KDQpG YXRhaQ0KDQoNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBjY2FtcC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIExvdSBC ZXJnZXINCuWPkemAgeaXtumXtDogMjAxM+W5tDjmnIgx5pelIDA6NTENCuaUtuS7tuS6ujogQ0NB TVANCuS4u+mimDogW0NDQU1QXSByb3VnaCBtaW51dGVzIGZvciBCZXJsaW4gQ0NBTVAgbWVldGlu Z3MNCg0KDQpBcyBiZWZvcmUsIGl0IHdvdWxkIGJlIGJlc3QgdG8gZW50ZXIgY29ycmVjdGlvbnMg b24gaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2NjYW1wL21pbnV0ZXMgKHNlbmQgbWFpbCB0byBs aXN0IGlmIHlvdSBjYW4ndCkuDQoNCkRpc2N1c3Npb24gc2hvdWxkIHRha2UgcGxhY2Ugb24gdGhl IGxpc3QgYW5kICpub3QqIGluIGV0aGVycGFkLg0KDQpNdWNoIHRoYW5rcyB0byBvdXIgc2VjcmV0 YXJpZXMgYW5kIGFsbCB3aG8gY29udHJpYnV0ZWQgdG8gdGhlIG5vdGVzLg0KDQpMb3UNCg0KPiBD Q0FNUCBBZ2VuZGEgRm9yIElFVEYgODcNCj4gICAgICAgICAgICAgICAgICAgICBDQ0FNUCBBZ2Vu ZGEgRm9yIElFVEYgODcNCj4gICAgICAgICAgICAgICAgICAgICBWZXJzaW9uOiBKdWwgMjIsIDIw MTMNCj4NCj4gICAgICAgICAgICAgICAgICAgICBGaXJzdCBTZXNzaW9uDQo+ICAgICAgICAgICAg ICAgICAgICAgVFVFU0RBWSwgSnVseSAzMCwgMjAxMw0KPiAgICAgICAgICAgICAgICAgICAgIDE3 MDAtMTgzMCBBZnRlcm5vb24gU2Vzc2lvbiBJSUkNCj4gICAgICAgICAgICAgICAgICAgICBSb29t OiBQb3RzZGFtIDMNCj4gUHJlc2VudGF0aW9uICAgICAgICAgU3RhcnQgVGltZSAgICAgRHVyYXRp b24gICAgIEluZm9ybWF0aW9uDQo+IDAgICAgICAgICAgIDE3OjAwICAgICAxMCAgICAgVGl0bGU6 ICAgICBBZG1pbmlzdHJpdmlhICYgV0cgU3RhdHVzDQo+ICAgICAgICAgICAgICAgICBEcmFmdDoN Cj4gICAgICAgICAgICAgICAgIFByZXNlbnRlcjogICAgIENoYWlycw0KDQpGYXRhaSBaaGFuZzog QWZ0ZXIgdGhpcyBtZWV0aW5nIHdlIHBsYW4gdG8gdXBkYXRlIFtkcmFmdC1pZXRmLWNjYW1wLW90 bi1nNzA5LWluZm8tbW9kZWxdIGFuZCBbZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1l d29ya10gYmFzZWQgb24gQUQgKEFkcmlhbiBGYXJyZWwpIHJldmlldy4NCg0KQ29tbWVudHMgcmVx dWVzdGVkIG9uIG5vbiBwcmVzZW50ZWQgV0cgZHJhZnRzIHN0YXR1czoNCg0K4oCSIGRyYWZ0LWll dGYtY2NhbXAtcnN2cC10ZS1zcmxnLWNvbGxlY3QNCk9zY2FyIEdvbnphbGV6IGRlIERpb3M6IFRo ZSBkb2N1bWVudCBpcyBzdGFibGUuIFRoZXJlIGlzIG9uZSBmdW5jdGlvbmFsaXR5IChrbm93aW5n IGlmIGEgUlJPIHN1Ym9qZWN0IGlzIGluY29tcGxldGUgb3IgaGFzIGJlZW4NCmVkaXRlZCkgdGhh dCBuZWVkcyB0byBiZSBtYWRlIGdlbmVyaWMgKHRoZXJlIHdhcyBhIGNvbW1lbnQgZnJvbSBMb3Ug ZHVyaW5nIElFVEYgODZ0aCkuIEEgbWFpbCB3YXMgc2VudCBvbiA0dGggb2YgSnVseSB3aXRoIHNl dmVyYWwgb3B0aW9ucyB0byBtYWtlIHRoZSBmdW5jdGlvbmFsaXR5IGdlbmVyaWMuIEEgbmV3IG1h aWwgdG8gdGhlIENDQU1QIGxpc3Qgd2lsbCBiZSBzZW50IHRoaXMgd2l0aCB0aGUgb3B0aW9ucy4g RmVlZGJhY2sgaXMgcmVxdWVzdGVkIGZyb20gdGhlIENDQU1QIGxpc3QuDQrigJIgZHJhZnQtaWV0 Zi1jY2FtcC1yc3ZwLXRlLWxpLWxiOg0KRGFuaWVsZSBDZWNjYXJlbGxpOiBObyBjaGFuZ2VzIGZy b20gbGFzdCBtZWV0aW5nDQoNCj4gMSAgICAgICAgICAgMTc6MTAgICAgIDggICAgIFRpdGxlOiAg ICAgTFNQIEF0dHJpYnV0ZSBpbiBFUk8NCj4gICAgICAgICAgICAgICAgIERyYWZ0Og0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1sc3AtYXR0cmlidXRlLXJvLTAy DQo+ICAgICAgICAgICAgICAgICBQcmVzZW50ZXI6ICAgICBDeXJpbCBNYXJnYXJpYQ0KDQpMb3Ug QmVyZ2VyOiBJIHN1c3BlY3QgdGhhdCB5b3UgYWRkcmVzc2VkIEFkcmlhbidzIFtGYXJyZWwpIGNv bW1lbnQuIEkgc3VnZ2VzdCB5b3UgY2hlY2sgd2l0aCBoaW0gdmlhIHRoZSBsaXN0IHRvIGNvbmZp cm0uDQoNCj4gMiAgICAgICAgICAgMTc6MTggICAgIDggICAgIFRpdGxlOiAgICAgUlNWUC1URSBF eHRlbnNpb25zIGZvcg0KQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUHMNCj4gICAgICAgICAg ICAgICAgIERyYWZ0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2Ft cC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDYNCj4gICAgICAgICAgICAgICAg IFByZXNlbnRlcjogICAgIE1hdHQgSGFydGxleQ0KDQpMb3UgQmVyZ2VyOiBJIHRoaW5rIHdlIGNh biBtb3ZlIHJhcGlkbHkgdG93YXJkcyBMYXN0IENhbGwuDQpNYXR0IEhhcnRsZXk6IFNwbGVuZGlk Lg0KDQo+IDMgICAgICAgICAgIDE3OjI2ICAgICA4ICAgICBUaXRsZTogICAgIFJTVlAtVEUgZXh0 ZW5zaW9uIGZvciByZWNvcmRpbmcNClRFIE1ldHJpYyBvZiBhIExTUA0KPiAgICAgICAgICAgICAg ICAgRHJhZnQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLXRl LW1ldHJpYy1yZWNvcmRpbmctMDINCj4gICAgICAgICAgICAgICAgIFByZXNlbnRlcjogICAgIEdl b3JnZSBTd2FsbG93DQoNCk9zY2FyIEdvbnphbGV6IGRlIERpb3M6IFJlZ2FyZGluZyBJQU5BIHJl cXVlc3RzIENvbGxpc2lvbiB3aXRoIElBTkEgYXNzaWdubWVudC4gV2UgbmVlZCB0byBhbGlnbiBv biB0ZW1wb3JhcnkgYXNzaWdubWVudHMgdG8gYXZvaWQgY29sbGlzaW9ucy4NCkdlb3JnZSBTd2Fs bG93Og0KRGFuaWVsZSBDZWNjYXJlbGxpOiBIb3cgYWJvdXQgd2UgbWVyZ2UgdGhlIGRyYWZ0cyB0 byBtaW5pbWl6ZWQgdGhlIG51bWJlciBvZiBkcmFmdHMgdG8gcmVhZD8NCkdlb3JnZSBTd2FsbG93 OiBXZSBpbml0aWFsbHkgaGFkIHRoaXMgcGxhbiwgYnV0IHdlIHdhbnRlZCB0byBhdm9pZCBob2xk aW5nIHVwIHRoZSBvdGhlciBkcmFmdC4NCkxvdSBCZXJnZXI6IFJlZ2FyZGluZyBJQU5BIGFzc2ln bm1lbnRzLCBhcmUgeW91IGhhdmluZyBzaW1pbGFyIGlzc3VlcyBpbiBNUExTPyAocmUgY29sbGlz aW9uIG9mIHRlbXBvcmFyeSBhc3NpZ25tZW50cyB2YWx1ZXMpLiBXZSB1c2VkIHRvIGhhdmUgdGhl IHdpa2kgd2hpY2ggaGFzIG5vdCBiZWVuIHRvdWNoZWQgZm9yIGEgbG9uZyB0aW1lLg0KR2Vvcmdl IFN3YWxsb3c6IEkgZnVsbHkgc3VwcG9ydCBpdC4NCkRhbjogV2UgdXNlZCB0byBkbyB0aGF0IGJ1 dCBvdXIgQUQgc3VnZ2VzdGVkIHRvIHN0b3AuDQpMb3UgQmVyZ2VyOiBJdCdzIG5vdCB0ZW1wb3Jh cnkgYXNzaWdubWVudCBpdCBpcyBqdXN0IGEgd2F5IHRvIGVuc3VyZSB0aGF0IGRvY3VtZW50cyBk byBubyBjb2xsaWRlIGFuZCBhdm9pZCBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMuIFdlIHdpbGwgZGlz Y3VzcyB0aGlzIHdpdGggQWRyaWFuIEZhcnJlbC4gRG8gd2UgaGF2ZSBzb21lb25lIHdobyB3aWxs IHRha2UgcmVzcG9uc2liaWxpdHkgZm9yIHRoZSBDQ0FNUCBwYWdlPw0KT3NjYXIgR29uemFsZXog ZGUgRGlvczogSSB2b2x1bnRlZXIuDQpMb3UgQmVyZ2VyOiBXZSB0aGluayBpdCB3b3VsZCBiZSBh IGdvb2QgaWRlYSB0byByZXN1cnJlY3QgdGhlIHdpa2kNCkFkcmlhbjogRGlmZmVyZW50IHRpbWVz IHdydCBSRkM0MDIwLiBQZW9wbGUgd2FudGVkIHRvIGltcGxlbWVudCBhbmQgc3RhcnQgaW50ZXJv cC4gTm93IHRoYXQgd2Ugc3VwcG9ydCBlYXJseSBhbGxvY2F0aW9uIHdoaWNoIGdpdmVzIGEgY29k ZXBvaW50IGZvciAyIHllYXJzIGkgZG9uJ3QgdGhpbmsgd2UgbmVlZCBhbGxvY2F0aW9ucyBvdXRz aWRlIElBTkEuDQpXaGF0IGhhcHBlbnMgaWYgd2Ugc2NyZXcgdXAgdGhhdCByZWdpc3RyeT8NCkdl b3JnZSBTd2FsbG93OiBXZSB3aWxsIGNhdmVhdCB0aGUgcmVxdWVzdC4NCkFkcmlhbiBGYXJyZWw6 IFdoeSBub3QgZ28gdGhhdCBleHRyYSBiaXQgZnVydGhlciBhbmQgcmVxdWVzdCBhbiBlYXJseSBh bGxvY2F0aW9uLiBXZSBzaG91bGQgdGFsayBpbiBtb3JlIGRldGFpbHMgY2hhaXJzIGFuZCBBRHMu DQpMb2EgQW5kZXJzc29uOiBTdWdnZXN0aW9uOiBhc2sgdGhlIFdHIGNoYWlycyBpZiB0aGUgZHJh ZnQgaXMgc3RhYmxlIGVub3VnaCB0byBzdGFydCBkZXZlbG9wbWVudCwgdGhlbiByZXF1ZXN0IGFu IGVhcmx5IGFsbG9jYXRpb24uDQpBZHJpYW4gRmFycmVsOiBJIHN1Z2dlc3QgdGhhdCBpZiBJIGFt IHVuZWFzeSB3aXRoIHRoaXMgdGhlIElFU0cgbWF5IGFsc28gaGF2ZSBpc3N1ZXMuIFdlIGNhbiB0 YWtlIHRoaXMgZGlzY3Vzc2lvbiBvZmZsaW5lICh3aXRoIENDQU1QIGFuZCBNUExTIGNoYWlycyku DQoNCg0KPiA0ICAgICAgICAgICAxNzozNCAgICAgOCAgICAgVGl0bGU6ICAgICBSU1ZQLVRFIExT UCBSb3V0ZSBEaXZlcnNpdHkNCnVzaW5nIEV4Y2x1ZGUgUm91dGVzDQo+ICAgICAgICAgICAgICAg ICBEcmFmdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtbHNw LWRpdmVyc2l0eS0wMg0KPiAgICAgICAgICAgICAgICAgUHJlc2VudGVyOiAgICAgR2VvcmdlIFN3 YWxsb3cNCg0KRmF0YWkgWmhhbmc6IEkgdW5kZXJzdGFuZCB0aGUgbW90aXZhdGlvbiwgYnV0IEkg aGF2ZSBhbiBpc3N1ZSB3aXRoIHRoZSBjb21wMGxleHQgc29sdXRpb24uIFdoeSBub3QgdXNlIGV4 aXN0aW5nIHNvbHV0aW9uIGxpa2UgcGF0aC1rZXk/DQpHZW9yZ2UgU3dhbGxvdzogVGhlIG9wZXJh dG9yIG1heSBub3QgYmUgdXNpbmcgUENFLiBXZSBkaWQgZGlzY3VzcyB0aGUgc29sdXRpb24gZWFy bHkgb24gYmVmb3JlIHRoaXMgZG9jdW1lbnQgYmVjYW1lIGEgV0cgZG9jdW1lbnQuDQpEZWJvcmFo IEJydW5nYXJkOiBNYWtlIHN1cmUgeW91IHJlYWQgdGhlIGRvY3VtZW50IGFuZCB0cmlnZ2VyIGRp c2N1c3Npb24gb24gdGhlIGxpc3QsIG5vdCB3YWl0IGZvciB0aGUgbWVldGluZy4NCg0KDQo+IDUg ICAgICAgICAgIDE3OjQyICAgICA2ICAgICBUaXRsZTogICAgIEluY2x1ZGUgUm91dGVzIC0gRXh0 ZW5zaW9uIHRvDQpSU1ZQLVRFDQo+ICAgICAgICAgICAgICAgICBEcmFmdDoNCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFsaS1jY2FtcC1yc3ZwLXRlLWluY2x1ZGUtcm91dGUtMDQN Cj4gICAgICAgICAgICAgICAgIFByZXNlbnRlcjogICAgIEdlb3JnZSBTd2FsbG93DQoNCktodXpl bWEgUGl0aGV3YW46IFRoZXJlIGFyZSBlbGVtZW50cyAoY29uc3RyYWludHMpIGluZmx1ZW5jaW5n IGEgc2VjdGlvbiBvciBjb21wbGV0ZSBwYXRoIG9mIGFuIExTUCwgdGhlc2UgbmVlZCB0byBiZSBt YW5hZ2VkLg0KR2VvcmdlIFN3YWxsb3c6IElmIHlvdSBjYW5ub3QgbWVldCBhbGwgdGhlIGV4aXN0 aW5nIGNvbnN0cmFpbnRzLCBhcyB3ZWxsIGFzIG1lZXQgZGl2ZXJzZSBvYmplY3RpdmUsIHRoZW4g YW4gZXJyb3Igd2lsbCBiZSBpc3N1ZWQuIFRoaXMgaXMgZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVu dC4NCkxvdSBCZXJnZXI6IGFub3RoZXIgWFJPIG1pZ2h0IGJlIHByZXNlbnQgYW5kIHlvdSBuZWVk IHRvIGNvbnNpZGVyIGl0Lg0KQWRyaWFuOiBTdWdnZXN0IHRoYXQgeW91IHJlbmFtZSBzdWJvYmpl Y3QuIEFzIHRoZXJlIG1pZ2h0IGJlIGNvbmZ1c2lvbi4NCkdlb3JnZSBTd2FsbG93OiBBbiBlYXN5 IGNoYW5nZSwgZG8geW91IGhhdmUgYW4gc3VnZ2VzdGlvbj8NCkxvdSBCZXJnZXI6ICJJbmNsdXNp b24iPw0KR2VvcmdlIFN3YWxsb3c6ICJGb2xsb3cgdGhlIGJyZWFkY3J1bWIiPyBPaywgd2UgKGF1 dGhvcnMpIHdpbGwgZGlzY3Vzcy4NCg0KDQo+IDYgICAgICAgICAgIDE3OjQ4ICAgICA1ICAgICBU aXRsZTogICAgIFJTVlAtVEUgRXh0ZW5zaW9uIGZvciBMYWJlbA0KU3dpdGNoZWQgUGF0aCAoTFNQ KSAgSW5xdWlyeQ0KPiAgICAgICAgICAgICAgICAgRHJhZnQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1hbGktY2NhbXAtbHNwLWlucXVpcnktMDANCj4gICAgICAgICAgICAgICAg IFByZXNlbnRlcjogICAgIEdlb3JnZSBTd2FsbG93DQoNCkxvdSBCZXJnZXI6IE9mZiBjb3Vyc2Ug cmV1c2luZyBleGlzdGluZyBtZWNoYW5pc21zIGlzIGdvb2QsIGlmIHlvdSBtYW5hZ2UgdG8gcmV1 c2UgYWxzbyBleGlzdGluZyB0ZXJtaW5vbG9neSBpdHMgYmV0dGVyLg0KR2VvcmdlIFN3YWxsb3c6 IFllcy4NCktodXplbWEgUGl0aGV3YW46IFRoaXMgd2lsbCBhZmZlY3QgZXhpc3Rpbmcgc2Vydmlj ZXMuDQpHZW9yZ2UgU3dhbGxvdzogVGhpcyBpcyBzaWduYWxlZCBmcm9tIHRoZSBJUCBwbGFuZSwg c28gd2UgYXNzdW1lIHRoYXQgeW91IGFyZSBpbiBhIG1haW50ZW5hbmNlIHdpbmRvdy4NCkRpZXRl ciBCZWxsZXI6IFRoZXJlIGFyZSB0ZWNobm9sb2dpZXMgb3V0IHRoZXJlIHRoYXQgYWxsb3cgc29m dCBzZXQgdXAgb2YgcmVzb3VyY2VzLiBBcmUgeW91IGVudmlzYWdpbmcgdG8gY292ZXIgYWxzbyB0 aG9zZSB0ZWNobm9sb2dpZXM/DQpHZW9yZ2UgU3dhbGxvdzogV2Ugc2VlIHRoaXMgYmVpbmcgdXNl ZCBmb3Igc2hhcmVkIG1lc2ggcHJvdGVjdGlvbiBpbiBvcHRpY2FsIGVudmlyb25tZW50cy4NCkRp ZXRlciBCZWxsZXI6IEknbSB0YWxraW5nIGFib3V0IHRlY2hub2xvZ2llcyB0aGF0IGluIHRlbnMg b2YgbXMgYXJlIGFibGUgdG8gdGVhciBkb3duIGFuIExTUCBhbmQgc2V0dXAgdGhlIHByb3RlY3Rp bmcgb25lLg0KWGlhbjogSSBkb24ndCBmb2xsb3cgdGhlIG1vdGl2YXRpb24gZm9yIHRoZSBzZWNv bmQgdHlwZSBvZiBpbnF1aXJ5LiBXaGF0IGlzIGl0cyB1c2FnZT8gSGF2ZSB5b3UgY29uc2lkZXJl ZCB1c2luZyBjYWxscz8NCkdlb3JnZSBTd2FsbG93OiBJJ20gbm90IGZhbWlsaWFyIHdpdGggdGhh dCBwYXJ0aWN1bGFyIG1lY2hhbmlzbS4NCkxvdSBCZXJnZXI6IE5vdCBzdXJlIGhvdyBpdCB3b3Vs ZCBoZWxwLg0KDQo+IDcgICAgICAgICAgIDE3OjUzICAgICA1ICAgICBUaXRsZTogICAgIFJTVlAt VEUgRXh0ZW5zaW9uIGZvciBTaWduYWxpbmcNCk9iamVjdGl2ZSBGdW5jdGlvbiBhbmQgTWV0cmlj IEJvdW5kDQo+ICAgICAgICAgICAgICAgICBEcmFmdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWFsaS1jY2FtcC1yYy1vYmplY3RpdmUtZnVuY3Rpb24tbWV0cmljLWJvdW5kLTAz DQo+ICAgICAgICAgICAgICAgICBQcmVzZW50ZXI6ICAgICBHZW9yZ2UgU3dhbGxvdw0KDQpMb3Ug QmVyZ2VyOiBob3cgbWFueSBwZW9wbGUgdGhpbmsgaXQncyBhIHVzZWZ1bCBmdW5jdGlvbiAoZ29v ZCBudW1iZXIpIEhvdyBtYW55IHJlYWQ/IChzbGlnaHRseSBsZXNzKSBIb3cgbWFueSB0aGluayB0 aGlzIGlzIGEgZ29vZCBmb3VuZGF0aW9uPyAoc2xpZ2h0bHkgbGVzcykgQ3lyaWwgTWFyZ2FyaWE6 IE1lY2hhbmlzbXMgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLWNjYW1wLWxzcC1hdHRyaWJ1dGUtcm8g YXJlIG1lYW50IGZvciB0aGlzIGtpbmQgb2YgaW5mb3JtYXRpb24gT3NjYXIgR29uemFsZXogZGUg RGlvczogTm90IG9ubHkgaW4gdGhpcyBkcmFmdCBidXQgaW4gb3RoZXJzIHlvdSBhZGQgcGF0aCBj b21wdXRhdGlvbiBjb25zdHJhaW50cyBsaWtlIGluY2x1ZGUvZXhjbHVkZSB0aGluZ3MuIFdoZW4g cGF0aCBjb21wdXRhdGlvbiBpcyBkb25lIGluIHRoZSBtaWRkbGUgb2YgdGhlIG5ldHdvcmsgb25l IG1heSB3YW50IHRvIHBhc3MgYWxsIHRoZSBwYXRoIGNvbXB1dGF0aW9uIGNvbnN0cmFpbnRzIGlu IFJTVlAtVEUuIEhvd2V2ZXIsIGluIHRoZSBwcm9wb3NhbCwgeW91IGFyZSBkdXBsaWNhdGluZyBQ Q0VQIG9iamVjdHMuDQpMb3U7IHdlIGZvbGxvd2VkIHRoZSBhcHByb2FjaCB0aGF0IHdlIGNhbiBk aXN0cmlidXRlIHBhdGggY29tcHV0YXRpb24uDQpPc2NhciBHb256YWxleiBkZSBEaW9zOiBOb3Qg d2hhdCBJIG1lYW50LiBJIG1lYW4gdGhhdCBpZiB0aGVyZSBpcyBhbHJlYWR5IGEgY29tcGxldGUg c3ludGF4IHRvIGV4cHJlc3MgcGF0aCBjb21wdXRhdGlvbiBjb25zdHJhaW50cywgaW5jbHVzaW9u cy9leGNsdXNpb25zLCBldGMsIHdoeSBub3QgcmV1c2UgaXQ/DQpMb3UgQmVyZ2VyOiBDYW4geW91 IG1ha2UgdGhpcyBzdWdnZXN0aW9uIG9uIHRoZSBsaXN0Pw0KRmF0YWkgWmhhbmc6IG5vdCBzdXJl IGFib3V0IHRoZSB2YWx1ZSBvZiB0aGlzIGRyYWZ0Lg0KDQoNCj4gOCAgICAgICAgICAgMTc6NTgg ICAgIDUgICAgIFRpdGxlOiAgICAgUlNWUC1URSBTaWduYWxpbmcgRXh0ZW5zaW9uIGZvcg0KQmFu ZHdpZHRoIGF2YWlsYWJpbGl0eQ0KPiAgICAgICAgICAgICAgICAgRHJhZnQ6DQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb25nLWNjYW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2YWls YWJpbGl0eS0wMQ0KPiAgICAgICAgICAgICAgICAgUHJlc2VudGVyOiAgICAgTWluIFllDQoNCkxv dSBCZXJnZXI6IFNlZSB0aGUgVFNWIFdHIFtUdW5uZWwgQ29uZ2VzdGlvbiBJLUQ/XSwgdGhlcmUg Y291bGQgYmUgb3ZlcmxhcCB3aXRoIHlvdXIgZHJhZnQuDQpLaHV6ZW1hIFBpdGhld2FuOiB5b3Ug bWlnaHQgZW5kIHVwIG11bHRpcGxlIGxlbmd0aHMgdG8gc2F0aXNmeSBhIGJhbmR3aWR0aCByZXF1 ZXN0Lg0KDQo+IDkgICAgICAgICAgIDE4OjAzICAgICA1ICAgICBUaXRsZTogICAgIE9TUEYgUm91 dGluZyBFeHRlbnNpb24gZm9yDQpsaW5rcyB3aXRoIHZhcmlhYmxlIGRpc2NyZXRlIGJhbmR3aWR0 aA0KPiAgICAgICAgICAgICAgICAgRHJhZnQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1sb25nLWNjYW1wLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi0wMA0KPiAgICAgICAg ICAgICAgICAgUHJlc2VudGVyOiAgICAgTWluIFllDQpNYXR0IEhhcnRsZXk6IFNob3VsZCB0aGlz IGJlIGFuIE9TUEYgV0cgZHJhZnQ/DQpMb3UgQmVyZ2VyOiBpbiB0aGUgcGFzdCB3ZSBhZ3JlZWQg d2l0aCB0aGUgT1NQRiBjaGFpcnMgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBtYWtlIE9TUEYgY2hh bmdlcyBpbiBDQ0FNUC4NCg0KPiAxMCAgICAgICAgICAgMTg6MDggICAgIDcgICAgIFRpdGxlOiAg ICAgRG9tYWluIFN1Ym9iamVjdHMgZm9yIFJlc291cmNlDQpSZXNlclZhdGlvbiBQcm90b2NvbCDi gJMgVHJhZmZpYyBFbmdpbmVlcmluZyAoUlNWUC1URSkNCj4gICAgICAgICAgICAgICAgIERyYWZ0 Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGhvZHktY2NhbXAtcnN2cC10ZS1k b21haW4tc3Vib2JqZWN0cy0wMg0KPiAgICAgICAgICAgICAgICAgUHJlc2VudGVyOiAgICAgRGhy dXYgRGhvZHkNCg0KRGVib3JhaCBCcnVuZ2FyZDogW1BvbGxdDQpIb3cgbWFueSB0aGluayBpdCdz IHVzZWZ1bD8gW2dvb2QgbnVtYmVyXSwgSG93IG1hbnkgaGF2ZSByZWFkIFtnb29kIG51bWJlcl0g VGFrZSB0byB0aGUgbGlzdA0KDQo+IDExICAgICAgICAgICAxODoxNSAgICAgNSAgICAgVGl0bGU6 ICAgICBBIFNOTVAgTUlCIHRvIG1hbmFnZSBHTVBMUw0Kd2l0aCBHZW5lcmFsIENvbnN0cmFpbnRz IFN1cHBvcnQNCj4gICAgICAgICAgICAgICAgIERyYWZ0Og0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZ21nZ20tY2NhbXAtZ2VuY29ucy1zbm1wLW1pYi0wMg0KPiAgICAgICAgICAg ICAgICAgUHJlc2VudGVyOiAgICAgR2lvdmFubmkgTWFydGluZWxsaQ0KDQpMb3UgQmVyZ2VyOiBJ IHRoaW5rIHRoaXMgZG9jdW1lbnQgaXMgdGltZWQgcGVyZmVjdGx5IGluIHJlbGF0aW9uIHRvIHRo ZSBXU09OIHdvcmsuDQpGYXRhaSBaaGFuZzogR2VuZXJhbCBjb21tZW50LiBXaGVuIGRvIHdlIG5l ZWQgTUlCIGRyYWZ0cz8gRG8gd2UgbmVlZCBpdCBpbiB0aGlzIGNhc2U/IFNvbWUgTUlCIGRyYWZ0 cyBhcmUgb24gdGhlIENDQU1QIHBhZ2UgYW5kIGFyZSBub3QgdXBkYXRlZCBmb3IgeWVhcnMuDQpE ZWJvcmFoIEJydW5nYXJkOiBTb21lIHBlb3BsZSB1c2UgU05NUCBhcyBtYW5hZ2VtZW50IGludGVy ZmFjZSwgc29tZSBvdGhlcnMgdXNlIGRpZmZlcmVudCBtYW5hZ2VtZW50IHByb3RvY29scw0KQWRy aWFuOiBZb3UgYXJlIG5vdCByZXF1aXJlZCB0byB3cml0ZSBNSUIgbW9kdWxlcy4gWW91IGFyZSBy ZXF1aXJlZCB0byBkaXNjdXNzIGhvdyB5b3VyIG5ldHdvcmsgbWF5IGJlIG1hbmFnZWQuDQoNCj4g MTIgICAgICAgICAgIDE4OjIwICAgICA1ICAgICBUaXRsZTogICAgIEluZm9ybWF0aW9uIE1vZGVs IGZvciBXU09Ocw0Kd2l0aCBJbXBhaXJtZW50cyBWYWxpZGF0aW9uDQo+ICAgICAgICAgICAgICAg ICBEcmFmdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbmVsbGktY2Nh bXAtd3Nvbi1pdi1pbmZvLTAyDQo+ICAgICAgICAgICAgICAgICBQcmVzZW50ZXI6ICAgICBHaW92 YW5uaSBNYXJ0aW5lbGxpDQoNCkRpZXRlciBCZWxsZXI6IENvbnNpZGVyaW5nIHdlIGRvIG5vdCBo YXZlIGRhdGEgcGxhbmUgaW50ZXJvcCwgYW5kIGEgY29tcHV0YXRpb24gY2FwYWJpbGl0eSB0byBj b21wdXRlIGVuZC10by1lbmQsIGZpbmQgdGhpcyB3b3JrIGEgbGl0dGxlIGVhcmx5Pw0KR2lvdmFu bmk6IFdoYXQgZG8geW91IG1lYW4gdGhhdCB0aGVyZSBpcyBubyBkYXRhIHBsYW5lIGNvbXBhdGli aWxpdHk/DQpUaGUgYW5zd2VyIGZyb20gSVRVLVQgZm9sa3Mgd2FzIHRoYXQgdGhlcmUgY291bGQg YmUgc29tZSBtdWx0aXZlbmRvciBjYXNlLg0KRGlldGVyIEZyb20gdGhlIGRpc2N1c3Npb24gaW4g T3JsYW5kbyBpbnRlcm9wIGlzIG5vdCBjdXJyZW50bHkgY2FwYWJsZSwgc28gaXMgZGV2ZWxvcG1l bnQgb2YgYW4gaW5mb3JtYXRpb24gbW9kZWwgdG9vIHNvb24/DQpHaW92YW5uaTogVGhlIGNvbXBh dGliaWxpdHkgd2lsbCBjb21lLCB3ZSBjYW5ub3QgbWFrZSBhbnkgcHVibGljIHN0YXRlbWVudCBu b3cuIFRoZXJlIGFyZSBzb21lIHBhcmFtZXRlcnMgdGhhdCBubyBvbmUgY2FyZXMgaG93IGFyZSBj b21wdXRlZC4NCkRpZXRlciBCZWxsZXI6IFdlIGFyZSBzdXBwb3NlZCB0byBkZXZlbG9wIHN0YW5k YXJkIHRoYXQgcHJvdmlkZSBpbnRlcm9wZXJhYmlsaXR5DQpHaW92YW5uaTogWWVzLiBBdCB0aGUg Y29udHJvbCBwbGFuZS4NCkRlYm9yYWggQnJ1bmdhcmQ6IEkgc3VnZ2VzdCB0byB0YWxrIHdpdGgg UTYgZ3V5cy4gSW50ZXJpbSBtZWV0aW5nLCB0byBoZWxwIGRlZmluZS4NCg0KPiAxMyAgICAgICAg ICAgMTg6MjUgICAgIDUgICAgIFRpdGxlOiAgICAgSW5mb3JtYXRpb24gRW5jb2RpbmcgZm9yIFdT T04NCndpdGggSW1wYWlybWVudHMgVmFsaWRhdGlvbg0KPiAgICAgICAgICAgICAgICAgRHJhZnQ6 DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXJ0aW5lbGxpLWNjYW1wLXdzb24t aXYtZW5jb2RlLTAyDQo+ICAgICAgICAgICAgICAgICBQcmVzZW50ZXI6ICAgICBHaW92YW5uaSBN YXJ0aW5lbGxpDQoNCk5vIGNvbW1lbnRzLg0KDQoNCg0KDQo+IEFkam91cm4gICAgICAgICAgIDE4 OjMwDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgU2Vjb25kIFNlc3Npb24NCj4gICAgICAgICAg ICAgICAgICAgICBXRURORVNEQVksIEp1bHkgMzEsIDIwMTMNCj4gICAgICAgICAgICAgICAgICAg ICAxMzAwLTE1MDANCj4gICAgICAgICAgICAgICAgICAgICBSb29tOiBQb3RzZGFtIDENCj4gUHJl c2VudGF0aW9uICAgICAgICAgU3RhcnQgVGltZSAgICAgRHVyYXRpb24gICAgIEluZm9ybWF0aW9u DQo+IDAgICAgICAgICAgIDEzOjAwICAgICA1ICAgICBUaXRsZTogICAgIEFkbWluaXN0cml2aWEN Cj4gICAgICAgICAgICAgICAgIERyYWZ0Og0KPiAgICAgICAgICAgICAgICAgUHJlc2VudGVyOiAg ICAgQ2hhaXJzDQoNCj4gMTQgICAgICAgICAgIDEzOjA1ICAgICA4ICAgICBUaXRsZTogICAgIEZy YW1ld29yayBhbmQgUmVxdWlyZW1lbnRzIGZvcg0KR01QTFMgYmFzZWQgY29udHJvbCBvZiBGbGV4 aS1ncmlkIERXRE0gbmV0d29ya3MNCj4gICAgICAgICAgICAgICAgIERyYWZ0Og0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtb2dyY2V0YWwtY2NhbXAtZmxleGktZ3JpZC1md2stMDMN Cj4gICAgICAgICAgICAgICAgIFByZXNlbnRlcjogICAgIE9zY2FyIEdvbnphbGV6IGRlIERpb3MN Cg0KRGVib3JhaCBCcnVuZ2FyZDogd2UgaGF2ZSBhIGxvdCBvZiBsaWFpc29ucyBmcm9tIElUVS1U LiBHLjg3MiB3YXMgY29uc2VudGVkPw0KTWFsY29sbTogRy44NzIgaGFzIGJlZW4gY29uc2VudGVk Lg0KRGVib3JhaCBCcnVuZ2FyZDogaGFzIGl0IGJlZW4gc2VudCB0byB0aGUgQ0NBTVA/DQpNYWxj b2xtOiBJIHRoaW5rIGl0IGlzIHdvcnRoIHNlbmRpbmcgYSBzcGVjaWZpYyBMaWFpc29uIHRvIFE2 Lg0KTG91IEJlcmdlcjogcG9sbGluZyBvbiB1c2VmdWxuZXNzLCByZWFkaW5nIGFuZCBzdXBwb3J0 IGFzIGZvdW5kYXRpb24gb2YgV0cgd29yay4gR29vZCBzdXBwb3J0LiBDb25maXJtIG9uIHRoZSBs aXN0Lg0KDQo+IDE1ICAgICAgICAgICAxMzoxMyAgICAgOCAgICAgVGl0bGU6ICAgICBSU1ZQLVRF IFNpZ25hbGluZyBFeHRlbnNpb25zDQppbiBzdXBwb3J0IG9mIEZsZXhpYmxlIEdyaWQNCj4gICAg ICAgICAgICAgICAgIERyYWZ0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhh bmctY2NhbXAtZmxleGlibGUtZ3JpZC1yc3ZwLXRlLWV4dC0wMg0KPiAgICAgICAgICAgICAgICAg UHJlc2VudGVyOiAgICAgWGlhbiBaaGFuZw0KDQpHaW92YW5uaTogd2hhdCBoYXBwZW5zIGlmIHRo ZSBMU1AgbmVlZHMgdG8gYmUgcmVzaXplZD8NClhpYW46DQpMb3UgQmVyZ2VyOiBUaGUgZG9jdW1l bnQgaXMgaW4gYW4gZWFybHkgc3RhZ2Ugb2YgZGV2ZWxvcG1lbnQuIFtQb2xsXSBIb3cgbWFueSBo YXZlIHJlYWQ/IEhvdyBtYW55IHN1cHBvcnQ/IFByZXR0eSBnb29kIG51bWJlciBidXQgbGVzcyB0 aGFuIEZXSy4NCldlIG1heSBwb2xsIGJlZm9yZSB0aGUgbmV4dCBtZWV0aW5nLCBhc3N1bWluZyBh ZG9wdGlvbiBvZiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50Lg0KSWZ0ZWthcjogSXQgc2VlbXMgdGhh dCB0aGlzIGRvY3VtZW50IGlzbid0IGFzIHdlbGwgZGV2ZWxvcGVkLiAgRG9lcyBpdCBtYWtlIHNl bnNlIHRvIGFkb3B0Lg0KTG91IEJlcmdlcjogIFdlIGNhbiBhZG9wdCBlYXJseSBpZiBpdCBtYWtl cyBzZW5zZS4gcmVtZW1iZXIgdGhhdCBhZG9wdGlvbiBpcyB0aGUgc3RhcnQgb2YgdGhlIFdHJ3Mg dGVjaG5pY2FsIHdvcmssIG5vdCBhIHN0YXRlbWVudCB0aGF0IGEgZG9jdW1lbnRlZCBzb2x1dGlv biBpcyBjb21wbGV0ZWx5IGNvcnJlY3QuIGlmIHlvdSBmZWVsIHRoZSBkb2N1bWVudCBpcyBub3Qg cmVhZHkgb3IgaGVhZGluZyBpbiB0aGUgd3JvbmcgZGlyZWN0aW9uLCB0aGVuIHlvdSBzaG91bGQg YnJpbmcgYW55IGNvbW1lbnRzIHRvIHRoZSBsaXN0Lg0KSWZ0ZWthcjogWz9dDQpHaW92YW5uaTog V0cgY2FuIGp1ZGdlIGlmIHRoZSBkb2N1bWVudCBpcyBzdWl0YWJsZSwgYnV0IGl0IG1heWJlIGVh cmx5Lg0KTG91IEJlcmdlcjogU28geW91IGZlZWwgYWRvcHRpbmcgdGhlIGRvY3VtZW50IGlzIHBy ZW1hdHVyZT8NCkdpb3Zhbm5pOiBZZXMuDQoNCj4gMTYgICAgICAgICAgIDEzOjIxICAgICA4ICAg ICBUaXRsZTogICAgIEdNUExTIE9TUEYtVEUgRXh0ZW5zaW9ucyBpbg0Kc3VwcG9ydCBvZiBGbGV4 aWJsZSBHcmlkIERXRE0gTmV0d29ya3MNCj4gICAgICAgICAgICAgICAgIERyYWZ0Og0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtZmxleGlibGUtZ3JpZC1vc3Bm LWV4dC0wMg0KPiAgICAgICAgICAgICAgICAgUHJlc2VudGVyOiAgICAgUmFtb24gQ2FzZWxsYXMN Cg0KQ3lyaWwgTWFyZ2FyaWE6IEEgYml0IHRvbyBlYXJseSB0byBtYWtlIGl0IGEgd2cgZG9jdW1l bnQgTG91IEJlcmdlcjogU3BlY2lmaWMgdGVjaG5pY2FsIGlzc3Vlcz8NCkN5cmlsIE1hcmdhcmlh OiBubw0KTG91IEJlcmdlcjogT2theSwgdGhlbiBwbGVhc2UgcmV2aWV3IGFuZCBzZW5kIHNwZWNp ZmljIGNvbW1lbnRzIHRvIHRoZSBsaXN0Lg0KTG91IEJlcmdlcjogR2VuZXJhbCBjb21tZW50LiBQ bGVhc2UgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGxpc3QgdG8gcmFpc2UgY29tbWVudHMgYW5kIG9i amVjdGlvbnMsIGxhY2sgb2YgZGlzY3Vzc2lvbiBtYXkgYmUgbWlzY29uc3RydWVkIGFzIGNvbmN1 cnJlbmNlIG9yIGRpc2ludGVyZXN0Lg0KDQpGYXRhaSBaaGFuZzogV2UgY291bGQgYWRvcHQgdGhl IGZyYW1ld29yayBhbmQgbGFiZWwgZHJhZnRzIGFuZCB0aGVuIHNwZWFrIGFib3V0IHNpZ25hbGlu ZyBhbmQgcm91dGluZyBMb3UgQmVyZ2VyOiBDYW4geW91IG1ha2UgdGhpcyBzdWdnZXN0aW9uIG9u IHRoZSBsaXN0IG9uY2UgdGhlIHJlc3VsdCBvZiB0aGUgZnJhbWV3b3JrIGFkb3B0aW9uIHBvbGwg aXMga25vd24/DQoNCj4gMTcgICAgICAgICAgIDEzOjI5ICAgICA3ICAgICBUaXRsZTogICAgIEFu IFNOTVAgTUlCIGV4dGVuc2lvbiB0bw0KUkZDMzU5MSB0byBtYW5hZ2Ugb3B0aWNhbCBpbnRlcmZh Y2UgcGFyYW1ldGVycyBvZiBEV0RNIGFwcGxpY2F0aW9ucw0KPiAgICAgICAgICAgICAgICAgRHJh ZnQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYWxpa3VuemUtY2NhbXAtZy02 OTgtMi1zbm1wLW1pYi0wMw0KPiAgICAgICAgICAgICAgICAgUHJlc2VudGVyOiAgICAgR2Ficmll bGUgR2FsaW1iZXJ0aQ0KPiAxOCAgICAgICAgICAgMTM6MzYgICAgIDcgICAgIFRpdGxlOiAgICAg QW4gU05NUCBNSUIgZXh0ZW5zaW9uIHRvDQpSRkMzNTkxIHRvIG1hbmFnZSBvcHRpY2FsIGludGVy ZmFjZSBwYXJhbWV0ZXJzIG9mIERXRE0gYXBwbGljYXRpb25zDQo+ICAgICAgICAgICAgICAgICBE cmFmdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbGlrdW56ZS1jY2FtcC1v cHQtaW1wLXNubXAtbWliLTAwDQo+ICAgICAgICAgICAgICAgICBQcmVzZW50ZXI6ICAgICBHYWJy aWVsZSBHYWxpbWJlcnRpDQoNCkdlcnQgR3JhbW1lbDogVGhlc2UgdHdvIGRyYWZ0cyBhcmUgY292 ZXJpbmcgdGhlIHNhbWUgY29udGVudCBvZiB0aGUgb25lIHdlIGRpc2N1c3NlZCBpbiBPcmxhbmRv Pw0KR2FicmllbGUgR2FsaW1iZXJ0aTogb25lIGlzIGNvdmVyaW5nIHdoYXQgaXMgaW4gdGhlIElU VS1UIHJlY29tbWVuZGF0aW9uIGFuZCB0aGUgb3RoZXIgb25lIHdoYXQgaXMgbm90IHRoZXJlLiBU aGV5IGFyZSBjb21wbGltZW50YXJ5Lg0KRGVib3JhaCBCcnVuZ2FyZDogW1BvbGxdIEhvdyBtYW55 IGhhdmUgcmVhZCB0aGUgZG9jdW1lbnQ/IFtOb3QgdG9vIG1hbnldIEhvcGVmdWxseSB3ZSB3aWxs IHNlZSBhIExpYWlzb24gdG8gaGVscCB1cyBwcm9ncmVzcyB0aGVzZSBkb2N1bWVudHMuDQoNCj4g MTkgICAgICAgICAgIDEzOjQzICAgICA4ICAgICBUaXRsZTogICAgIEV4dGVuc2lvbiB0byB0aGUg TE1QIGZvciBEV0RNDQpPcHRpY2FsIExpbmUgU3lzdGVtcyB0byBtYW5hZ2Ugb3B0aWNhbCBwYXJh bWV0ZXJzIG9mIERXRE0gYXBwbGljYXRpb25zDQo+ICAgICAgICAgICAgICAgICBEcmFmdDoNCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRoYXJpbmlnZXJ0LWNjYW1wLWctNjk4LTIt bG1wLTAzDQo+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kaGFyaW5pZ2VydC1j Y2FtcC1vcHQtaW1wLWxtcC0wMA0KPiAgICAgICAgICAgICAgICAgUHJlc2VudGVyOiAgICAgR2Vy dCBHcmFtbWVsDQoNCkRlYm9yYWggQnJ1bmdhcmQ6IElmIHlvdSBub3QgdXNlIHRoZSBhcHBsaWNh dGlvbiBjb2RlcywgdGhlIHNldCBvZiBwYXJhbWV0ZXJzIHlvdSBhcmUgZGVmaW5pbmcgaXMgZW5v dWdoIHRvIHByb3ZpZGUgaW50ZXJvcGVyYWJpbGl0eT8NCkdlcnQgR3JhbW1lbDogSWYgaXQgaXMg YSBzdGFuZGFyZCBhcHBsaWNhdGlvbiBjb2RlIHRoZW4gaXQgaXMgaW50ZXJvcGVyYWJsZS4gSWYg aXQgaXMgbm90IGEgc3RhbmRhcmRzIGFwcGxpY2F0aW9uIGNvZGUsIHRoZW4uLi4NCkRlYm9yYWgg QnJ1bmdhcmQ6IGl0IHdvdWxkIGJlIGdvb2QgdG8gdGFrZSBpdCB0byBRNiBbUG9sbF0gSXMgZHJh ZnQtZGhhcmluaWdlcnQtY2NhbXAtb3B0LWltcC1sbXAtMDAgdXNlZnVsLCBbYSByZWFzb25hYmxl IG51bWJlcl0uIFBvbGwgZm9yIDY5OC4yIGxtcCBzYW1lIG51bWJlci4gUG9sbCBmb3Igb3B0IGlt cCBsbXAgc2FtZSBudW1iZXIgLTENCg0KDQo+IDIwICAgICAgICAgICAxMzo1MSAgICAgNyAgICAg VGl0bGU6ICAgICBVc2UgY2FzZXMgZm9yIG9wZXJhdGluZw0KbmV0d29ya3MgaW4gdGhlIG92ZXJs YXkgbW9kZWwgY29udGV4dA0KPiAgICAgICAgICAgICAgICAgRHJhZnQ6DQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1jZWNjYWRlZGlvcy1jY2FtcC1vdmVybGF5LXVzZS1jYXNlcy0w MQ0KPiAgICAgICAgICAgICAgICAgUHJlc2VudGVyOiAgICAgRGFuaWVsZSBDZWNjYXJlbGxpDQoo c2luZ2xlIHByZXNlbnRhdGlvbiBmb3IgbmV4dCkNCj4gIDIxICAgICAgICAgICAxMzo1OCAgICAg OCAgICAgVGl0bGU6ICAgICBBcHBsaWNhYmlsaXR5IG9mIEdlbmVyYWxpemVkDQogTXVsdGlwcm90 b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSBVc2VyLU5ldHdvcmsgSW50ZXJmYWNlIChVTkkp DQo+ICAgICAgICAgICAgICAgICBEcmFmdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXpoYW5nLWNjYW1wLWdtcGxzLXVuaS1hcHAtMDQNCj4gICAgICAgICAgICAgICAgIFByZXNl bnRlcjogICAgIERhbmllbGUgQ2VjY2FyZWxsaQ0KDQpBZHJpYW4gRmFycmVsOiBBRCBoYXQgb2Zm IC0gTXkgbmFtZSBhcHBlYXJzIG9uIGFwcGxpY2FiaWxpdHkgSS1ELCBidXQgbm90IG9uIHRoZSB1 c2UgY2FzZXMuIFRoaXMgaXMgbm90IGFuIGFjY2lkZW50LCBpZiB3ZSBnbyBmb3Igb3B0aW9uIDEg ZmluZSwgaWYgd2UgZ28gZm9yIG9wdGlvbiAyIEkgd291bGQgbm90IHN1cHBvcnQuIEkgZG8gbm90 IHRoaW5rIHRoZSBhcHByb2FjaCBpcyBnb29kIG9yIGV2ZW4gcG9zc2libGUuIFRoaXMgaXMgbm90 IGhvdyB3ZSBzaG91bGQgYnVpbGQgbmV0d29ya3MuDQpMb3UgQmVyZ2VyOiBEbyB5b3UgYmVsaWV2 ZSB0aGF0IHNoYXJpbmcgbmV0d29yayBpbmZvcm1hdGlvbiBiZXR3ZWVuIGRvbWFpbnMgaXMgbm90 IGFjY2VwdGFibGU/DQpBZHJpYW4gRmFycmVsOiBObywgaW4gZmFjdCBJIGFtIHdvcmtpbmcgb24g YSBkb2N1bWVudCB0aGF0IGZhY2lsaXRhdGVzIHRoaXMuIE15IGlzc3VlIGlzIHRoZSBtZWNoYW5p c21zIHVzZWQgdG8gZXhjaGFuZ2UgaW5mb3JtYXRpb24uDQpMb3UgQmVyZ2VyOiBBdCB0aGUgb3Zl cmxheSBwcm92aWRlciwgd2hhdCB1c2VkIHRvIGJlIGNhbGxlZCBMMVZQTiBlbmhhbmNlZCBtb2Rl IHdvdWxkIHRoaXMgYmUgYWNjZXB0YWJsZT8NCkFkcmlhbiBGYXJyZWw6IGFyY2hpdGVjdHVyZSBv ciBwcm90b2NvbD8gV2UgZGlkIGRpc2N1c3Mgc29sdXRpb25zLCB0aHJlZSBvcHRpb25zIGluY2x1 ZGluZyBhbiBpbnRlci1kb21haW4gcm91dGluZyBwcm90b2NvbC4NCkxvdSBCZXJnZXI6IEluIHRo ZW9yeSB5b3Ugc3VwcG9ydCB0aGlzLCBidXQgeW91IGhhdmUgYW4gaXNzdWUgd2l0aCBvbmUgb2Yg dGhlIHNvbHV0aW9ucy4NCkFkcmlhbiBGYXJyZWw6DQpMb3UgQmVyZ2VyOiBMYXllciB5b3UgY29t bXVuaWNhdGUgYXQgVnMuIC4uLg0KQWRyaWFuIEZhcnJlbDogTXkgdmlldyBhcyBhIFdHIHBhcnRp Y2lwYW50IGlzIHRoYXQgd2UgbmVlZCB0byBzdGVwIGJhY2sgYW5kIGRpc2N1c3MgdGhlIGFyY2hp dGVjdHVyZSwgdGhlbiBzb2x1dGlvbiB3b3JrLg0KT3NjYXI7IFdoZW4gSSBiZWdhbiB0aGlzIHdv cmsgSSB3YW50ZWQgdG8gZGlzY3VzcyB0aGUgdXNlIGNhc2VzIGFuZCBkZXNjcmliZSB0aGUgYXJj aGl0ZWN0dXJlLCByYXRoZXIgdGhhbiBkZXZlbG9wIHNvbHV0aW9ucy4NCkxvdSBCZXJnZXI6IHNv IG1heWJlIHdlIHNob3VsZCBzdGVwIGJhY2sgYW5kIHJldmlldyB0aGUgYXJjaGl0ZWN0dXJlLg0K QWN0dWFsbHkgd2UgaGF2ZSBvdGhlciBkb2N1bWVudHMgdGhhdCBkaXNjdXNzIHRoZSB3b3JrLg0K SnVsaWVuIE1ldXJpYzogW3NsaWRlIFVOSS9PTkkgVXNlIGNhc2VdIHRoaXMgZmVlbHMgbGlrZSB0 cmFuc3BvcnQgcmVjb3ZlcnkgbWVjaGFuaXNtcyBiZWluZyBwdXNoZWQgaW50byB0aGUgcGFja2V0 IGxheWVyLg0KRGFuaWVsZSBDZWNjYXJlbGxpOiBUaGUgaW50ZW50aW9uIHdhcyB0byBkZW1vbnN0 cmF0ZSBob3cgaXQgaXMgcG9zc2libGUgbWl4IHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSB0d28gbGF5 ZXJzIERlYm9yYWggQnJ1bmdhcmQ6IEkgc3VnZ2VzdCB3ZSBicmVhayB1cCB0aGUgZXhhbXBsZXMg YW5kIHBvc3QgdG8gdGhlIGxpc3QgYW5kIHJlcXVlc3QgZmVlZGJhY2suDQpMb3UgQmVyZ2VyOiBI YXBweSB0byBoZWFyIHRoZSBhdXRob3JzIGFyZSBsb29raW5nIGF0IHRha2luZyBhIHN0ZXAgYmFj ayBhbmQgcmV2aXNpdGluZyB0aGVpciBkcmFmdHMuIFdoZW4gZG9pbmcgdGhpcyBwbGVhc2UgbG9v ayBhdCBvdGhlciBpbmRpdmlkdWFsIGRyYWZ0cyB0aGF0IG1heSBoYXZlIHJlbGF0ZWQgdGV4dCBh bmQgd29yayB3aXRoIHRob3NlICBvdGhlciBhdXRob3JzLiBBbHNvIGNvbnNpZGVyIHRoZSBkaWZm ZXJlbmNlcyBiZXR3ZWVuIFVOSSBhbmQgRU5OSSwgd2hpY2ggb3BlcmF0ZSBpbiBhIHNpbmdsZSBs YXllciwgYW5kIHRoZSBjb25jZXB0cyBvZiBMMVZQTiBiYXNpYyBhbmQgZW5oYW5jZWQgbW9kZSB3 aGljaCAgY2FuIGJlIGxldmVyYWdlZCBmb3IgY3Jvc3MgY2xpZW50L3NlcnZlciBsYXllcnMgLS0g d2hpY2ggaXMgcGVyaGFwcyB3aGF0J3MgaW50ZW5kZWQgYnkgT05JLg0KDQo+IDIyICAgICAgICAg ICAxNDowNiAgICAgNSAgICAgVGl0bGU6ICAgICBFeHRlbnNpb25zIHRvIFJTVlAtVEUgZm9yDQpF cnJvciBOb3RpY2F0aW9uIGluIEdNUExTIFVzZXItTmV0d29yayBJbnRlcmZhY2UgKFVOSSkNCj4g ICAgICAgICAgICAgICAgIERyYWZ0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YWxpLWNjYW1wLWdtcGxzLXVuaS1lcnJvci1ub3RpZmljYXRpb24tMDANCj4gICAgICAgICAgICAg ICAgIFByZXNlbnRlcjogICAgIE1hdHQgSGFydGxleQ0KDQpJZ29yIEJyeXNraW46IFdoYXQgaGFw cGVucyBpZiB0aGUgbm90aWZpY2F0aW9uIGlzIG5vdCByZWNlaXZlZD8NClRoZSBlZGdlIG5vZGUg d2lsbCBub3QgZmluZCBvdXQuDQpJZ29yIEJyeXNraW46IG1vc3Qgb2YgdGhhdCBzb2x1dGlvbnMg ZG9uJ3Qgd29yay4gV2hhdCB5b3UgbmVlZCBpcyBzb21lIHJlbGlhYmxlIG1lY2hhbmlzbSB0byBk byBpdC4NCk1hdHQgSGFydGxleTogSXQnbGwgd29yayB0aGUgd2F5IFJTVlAtVEUgYWx3YXlzIHdv cmtzLg0KSWdvciBCcnlza2luOiB5b3Ugc2hvdWxkIHRoaW5rIGFib3V0IGEgcmVsaWFibGUgbm90 aWZ5IGRlbGl2ZXJ5IExvdSBCZXJnZXI6IFRoaXMgaXMgYSBnZW5lcmFsIGlzc3VlIHdpdGggUlNW UCBhbmQgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNpbmdsZSBkb2N1bWVudCBNYXR0IEhhcnRs ZXk6DQpDeXJpbCBNYXJnYXJpYTogVGhpcyBtZWNoYW5pc21zIHNlZW1zIHRvIGFwcGx5IHRvIFVO SSwgd2UgbmVlZCBhIGdlbmVyYWwgbWVjaGFuaXNtLg0KTG91IEJlcmdlcjogVGhpcyBsZWFkcyB0 byBhIHF1ZXN0aW9uIHRoYXQgSSBoYWQsICB3aHkgaXMgdGhlIGdlbmVyYWwgYWRkcmVzcyBtYXBw aW5nL2hpZGluZyBtZWNoYW5pc20gZGVmaW5lZCBSRkM0MjA4IGluc3VmZmljaWVudD8NCk1hdHQg SGFydGxleTogd2lsbCBoYXZlIHRvIGxvb2sgYXQgdGhhdA0KQWRyaWFuOiBUaGUgcXVlc3Rpb24g SSBzZW50IG9uIHRoZSBtYWlsaW5nIGxpc3QgaXMgdGhhdCB3aGF0IHlvdSB3YW50IHRvIGRlZmlu ZSBpcyBhbHJlYWR5IHRoZXJlIGluIFJGQzQ3ODMgTWF0dCBIYXJ0bGV5OiBJZiB5b3UgY2FuIHNl bmQgdGhpcyBjb21tZW50IHRvICB0aGUgbGlzdCBJIGNhbiByZXZpZXcgYW5kIGNvbW1lbnQuDQpE ZWJvcmFoIEJydW5nYXJkOiBBcmUgeW91IGxvb2tpbmcgYXQgc2VnbWVudCBwcm90ZWN0aW9uIGlu IHRoZSBjb3JlPw0KTG91IEJlcmdlcjogd2hhdCB5b3UgYXJlIGxvb2tpbmcgZm9yIGlzIGEgc2lu Z2xlIGVycm9yIHZhbHVlPyAoTWF0dA0KSGFydGxleTogWWVzKSBJdCBzZWVtcyBpdCdzIGdvaW5n IHRvIGJlIGEgc2hvcnQgZHJhZnQuDQoNCj4gMjMgICAgICAgICAgIDE0OjExICAgICA4ICAgICBU aXRsZTogICAgIFVOSSBFeHRlbnNpb25zIGZvciBEaXZlcnNpdHkNCmFuZCBMYXRlbmN5IFN1cHBv cnQNCj4gICAgICAgICAgICAgICAgIERyYWZ0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZmVkeWstY2NhbXAtdW5pLWV4dGVuc2lvbnMtMDINCj4gICAgICAgICAgICAgICAgIFBy ZXNlbnRlcjogICAgIERpZXRlciBCZWxsZXINCg0KTG91IEJlcmdlcjogW3NsaWRlIC0gcmVsYXRp b25zaGlwcyB3aXRoIHByaW9yIHdvcmtdIERvIHlvdSB0aGluayB0aGF0IHlvdXIgZG9jdW1lbnQg aXMgcmVsYXRlZCB0byBEYW5pZWxlJ3MgW2RyYWZ0LWNlY2NhZGVkaW9zLWNjYW1wLW92ZXJsYXkt dXNlLWNhc2VzIGFuZCBdIHByZXNlbnRhdGlvbj8NCkRpZXRlciBCZWxsZXI6IFllcy4NCkxvdSBC ZXJnZXI6IEkgc3VnZ2VzdCB5b3UgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIHRpbWUgdGhpcyB3ZWVr IGFuZCBzZWUgaG93IHRoZXNlIGRvY3VtZW50cyBmaXQgdG9nZXRoZXIuIEFuZCB0aGVuIHVwZGF0 ZSB0aGUgZG9jdW1lbnRzL1dHIGFjY29yZGluZ2x5Lg0KDQoNCj4gMjQgICAgICAgICAgIDE0OjE5 ICAgICA4ICAgICBUaXRsZTogICAgIE11dHVhbGx5IEV4Y2x1c2l2ZSBMaW5rIEdyb3VwDQooTUVM RykNCj4gICAgICAgICAgICAgICAgIERyYWZ0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtYmVlcmFtLWNjYW1wLW1lbGctMDENCj4gICAgICAgICAgICAgICAgIFByZXNlbnRlcjog ICAgIFZpc2hudSBQYXZhbiBCZWVyYW0NCg0KTG91IEJlcmdlcjogW3NsaWRlIC0gNF0gQSBjbGFy aWZpY2F0aW9uIHF1ZXN0aW9uLCBpcyB0aGlzIGEgdmlydHVhbCBURSBsaW5rLCBvciBhbiBhY3R1 YWwgVEUgbGluaz8NClZpc2hudSBQYXZhbiBCZWVyYW06IGEgdmlydHVhbCBURSBsaW5rDQpMb3Ug QmVyZ2VyOiBCYXNlZCBvbiBleGlzdGluZyB3b3JrIChSRkNzKSwgIHRoZXJlIGlzIG5vIGRpc3Rp bmN0aW9uIGJldHdlZW4gdmlydHVhbCBURSBsaW5rIGFuZCBhbiBhY3R1YWwgVEUgbGluayBpbiB0 aGUgY2xpZW50IHRvcG9sb2d5Lg0KVGhpcyBpcyBhIHNpZ25pZmljYW50IGNoYW5nZS4NClZpc2hu dSBQYXZhbiBCZWVyYW06IFdlIGNhbiBtYWtlIGEgbm90ZSBvZiB0aGlzIGluIHRoZSBkb2N1bWVu dC4NCkdlb3JnZSBTd2FsbG93OiBBdCB3aGF0IHBvaW50IHdvdWxkIHlvdSBhZHZlcnRpc2UgbXV0 dWFsIGV4Y2x1c2l2aXR5LCBkbyB5b3Ugd2FpdCB1bnRpbCBpdCBpcyBzZXR1cD8gSWYgdGhpcyBp cyB0aGUgZGlyZWN0aW9uLCBob3cgbWFueSBkbyB5b3UgYWR2ZXJ0aXNlLCB3aHkgbm90IGluY2x1 ZGUgdGhpcyBpbiB0aGUgZHJhZnQuDQpJZ29yIEJyeXNraW46IHdlIGRpZCBjb25zaWRlciB0aGlz IGFuZCB3ZSB0aGluayB0byBleHBhbmQgdGhlIGNvbmNlcHQgb2YgU1JMRy4gW1dpbGwgcG9rZSBJ Z29yIHRvIHByb3ZpZGUgaGlzIGNvbW1lbnRzLl0gRGVib3JhaCBCcnVuZ2FyZDogW3BvbGxdIGhv dyBtYW55IHRoaW5rIHRoaXMgaXMgaW50ZXJlc3Rpbmc/IG5vdCB0byBtYW55LCB0cnkgdG8gcmFp c2UgaW50ZXJlc3QuDQoNCj4gMjUgICAgICAgICAgIDE0OjI3ICAgICA4ICAgICBUaXRsZTogICAg IE9TUEYtVEUgZXh0ZW5zaW9ucyBmb3IgTUxOTVJODQpiYXNlZCBvbiBPVE4NCj4gICAgICAgICAg ICAgICAgIERyYWZ0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFvLWNjYW1w LW1sbm1ybi1vdG4tb3NwZnRlLWV4dC0wMg0KPiAgICAgICAgICAgICAgICAgUHJlc2VudGVyOiAg ICAgS2h1emVtYSBQaXRoZXdhbg0KDQpMb3UgQmVyZ2VyOiBEbyB5b3UgcmVxdWlyZSBhbnl0aGlu ZyBmcm9tIHNpZ25hbGluZz8NCktodXplbWEgUGl0aGV3YW46IHllcywgbWF5YmUgeWVzLg0KRmF0 YWkgWmhhbmc6DQoNCj4gMjYgICAgICAgICAgIDE0OjM1ICAgICA4ICAgICBUaXRsZTogICAgIEdN UExTLWJhc2VkIEhpZXJhcmNoeSBMU1ANCkNyZWF0aW9uIGluIE11bHRpLVJlZ2lvbiBhbmQgTXVs dGktTGF5ZXIgTmV0d29ya3MNCj4gICAgICAgICAgICAgICAgIERyYWZ0Og0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtaC1sc3AtbWxuLTA1DQo+ICAg ICAgICAgICAgICAgICBQcmVzZW50ZXI6ICAgICBYaWFuIFpoYW5nDQoNCkxvdSBCZXJnZXI6IERv IHlvdSBuZWVkIGFueXRoaW5nIGZyb20gcm91dGluZyB0byBtYWtlIHRoZSBzaWduYWxpbmcgd29y az8NCkN5cmlsIE1hcmdhcmlhOiBZb3UgZG9uJ3Qga25vdyB3aGVyZSB5b3Ugb3JpZ2luYXRlIExv dSBCZXJnZXI6IEkgZG8gbm90IHVuZGVyc3RhbmQsIGNhbiB5b3UgZGlzY3VzcyB3aXRoIHRoZSBw cmV2aW91cyBhdXRob3JzIGFuZCBzZWUgaWYgYW55dGhpbmcgbmVlZHMgdG8gYmUgYWxpZ25lZC4N CkN5cmlsIE1hcmdhcmlhOiBubyB3ZSBkb24ndCBuZWVkIGlncCBleHRlbnNpb25zLg0KS2h1emVt YSBQaXRoZXdhbjogSWYgeW91IGFyZSBpbiBhIHNpbmdsZSBkb21haW4geW91IGRlZmluaXRlbHkg bmVlZCByb3V0aW5nIGV4dGVuc2lvbnMgTG91IEJlcmdlcjogUGxlYXNlIHJldmlldyBSRkM2MTA3 IGFzIHNvbWUgb2YgdGhlc2UgbWVjaGFuaXNtcyBtYXkgYWxyZWFkeSBiZSBkZXNjcmliZWQuDQoN Cg0KPiAyNyAgICAgICAgICAgMTQ6NDMgICAgIDUgICAgIFRpdGxlOiAgICAgUlNWUC1URSBFeHRl bnNpb25zIEZvcg0KU2lnbmFsaW5nIEdNUExTIFJlc3RvcmF0aW9uIExTUA0KPiAgICAgICAgICAg ICAgICAgRHJhZnQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktY2Nh bXAtZ21wbHMtcmVzdG9yYXRpb24tbHNwLTAxDQo+ICAgICAgICAgICAgICAgICBQcmVzZW50ZXI6 ICAgICBHYWJyaWVsZSBHYWxpbWJlcnRpDQoNCklnb3IgQnJ5c2tpbjogd2h5IGFyZSB5b3UgcmVx dWVzdGluZyBmZWVkYmFja3MgaWYgMiB5ZWFycyBhZ28gd2UgcHJlc2VudGVkIGEgc2ltaWxhciBk cmFmdCBhbmQgdGhlcmUgd2FzIG5vIGludGVyZXN0Pw0KDQpMb3UgQmVyZ2VyOiBDeXJpbCBhcmUg eW91IHdpbGxpbmcgdG8gd29yayBvbiBhIEJDUCB3aXRoIHRoZSBhdXRob3JzLCBJIHRoaW5rIHdl IGFncmVlIHRoYXQgbWVjaGFuaXNtcyBleGlzdCBidXQgd2UgbmVlZCB0byBkb2N1bWVudCBob3cg dGhleSBtaWdodCBiZSB1c2VkLiBXZSBkbyBub3QgaGF2ZSB0aW1lIHRvIGRpc2N1c3MsIHNvIGxl dOKAmXMgdGFrZSB0aGlzIG9mZmxpbmUuDQoNCg0KPiAyOCAgICAgICAgICAgMTQ6NDggICAgIDcg ICAgIFRpdGxlOiAgICAgVXBkYXRlIEZvcmNlZCBTd2l0Y2ggUHJpb3JpdHkNCj4gICAgICAgICAg ICAgICAgIERyYWZ0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGVsdm9vcnQt Y2NhbXAtZnMtcHJpb3JpdHktMDANCj4gICAgICAgICAgICAgICAgIFByZXNlbnRlcjogICAgIEh1 dWIgdmFuIEhlbHZvb3J0DQoNCkxvdSBCZXJnZXI6IFlvdSBtZW50aW9uZWQgb24gdGhlIGxpc3Qg dGhhdCB0aGlzIGRyYWZ0IHdhcyBpbiByZXNwb25zZSB0byBhIG1lc3NhZ2UgdGhhdCBJIHNlbnQu IFRoZSBtZXNzYWdlIHN0YXRlZCB0aGF0IGEgY29tYmluZWQgY2hhbmdlIHdhcyBuZWVkZWQgdG8g NDQyNyBhbmQgNjM3MiwgYnV0IHRoaXMgZHJhZnQgb25seSBjb3ZlcnMgNDQyNy4gIEFsc28gSSB3 YXMgbWlzdGFrZW4gaW4gbXkgc3RhdGVtZW50IFdSVCA0NDI3LCBhcyBpdCBkb2Vzbid0IHN0YXRl IHJlbGF0aXZlIHByaW9yaXRpZXMuICBUaGF0IGlzIHN0YXRlZCBvbmx5IGluIDYzNzIuIFRoZXJl IGFyZSBvdGhlciBkaXNjdXNzaW9ucyBvbiB0aGlzIHRvcGljIGdvaW5nIG9uLCBhbmQgdGhpcyBk cmFmdCBzaG91bGQgYmUgdGFrZW4gZm9yd2FyZCBpbiBhIG1hbm5lciBjb25zaXN0ZW50IHdpdGgg dGhvc2UgZGlzY3Vzc2lvbnMuDQoNCj4gMjkgICAgICAgICAgIDE0OjU1ICAgICA1ICAgICBUaXRs ZTogICAgIFJTVlAtVEUgRXh0ZW5zaW9ucyBmb3IgQml0DQpFcnJvciBSYXRlIChCRVIpIE1lYXN1 cmVtZW50DQo+ICAgICAgICAgICAgICAgICBEcmFmdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXpoYW5nLWNjYW1wLXJzdnB0ZS1iZXItbWVhc3VyZS0wMA0KPiAgICAgICAgICAg ICAgICAgUHJlc2VudGVyOiAgICAgWmhlbmJpbiBMaQ0KPiBBZGpvdXJuICAgICAgICAgICAxNTow MA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpD Q0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo= From daniele.ceccarelli@ericsson.com Sat Aug 3 09:28:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FC421F9F52 for ; Sat, 3 Aug 2013 09:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMY6TkunIHzb for ; Sat, 3 Aug 2013 09:28:05 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 70B3921F9AD2 for ; Sat, 3 Aug 2013 09:27:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-ef-51fd2f8ef262 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DF.69.00725.E8F2DF15; Sat, 3 Aug 2013 18:27:58 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.144]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Sat, 3 Aug 2013 18:27:57 +0200 From: Daniele Ceccarelli To: "Margaria, Cyril (Coriant - DE/Munich)" , "Zafar Ali (zali)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQ Date: Sat, 3 Aug 2013 16:27:57 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48128432@ESESSMB301.ericsson.se> References: <523C37072C291347B9730C9291CCA07D0D0F1B@DB3PRD0411MB427.eurprd04.prod.outlook.com> <523C37072C291347B9730C9291CCA07D0D0FDC@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: <523C37072C291347B9730C9291CCA07D0D0FDC@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48128432ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvrW6f/t9Agw3nxC2ezLnBYvHwzmom i2+ruS1e7/jK7sDiMeX3RlaP89/2sHosWfKTyePSi0NsASxRXDYpqTmZZalF+nYJXBlNpz8w F0ydwFTR99ergXHaJ8YuRk4OCQETiX9b77JC2GISF+6tZwOxhQQOM0qs3uHbxcgFZC9mlHjx cgdzFyMHB5uAlcSTQz4gcRGB44wST97NYgFpEBYwlji2qRNsqAjQ0Pszu6DsPIn5uzaD1bAI qEjcO3IczOYV8JZ4vugNM8SCb4wS0xb9ZAdJcArES/y4dB6smVFAVmLC7kVgNrOAuMStJ/OZ IC4VkFiy5zwzhC0q8fLxP6gPlCQalzxhhajPl5gzczUbxDJBiZMzn7BMYBSZhWTULCRls5CU QcT1JG5MncIGYWtLLFv4mhnC1pWY8e8QC7L4Akb2VYzsuYmZOenlhpsYgVF2cMtv3R2Mp86J HGKU5mBREufdpHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjZ+pOn5LHh3QNDj1fc6hX RGjnRZ0XoY6yDPECBx3KVUN6jzSKblTjeee99uJVth3nubYylyec+dxu/mlBk+qEzQdj4qz2 u6UcPeFYcNxh8Y6FKZdtzpl4nLoeVCv18eSHkoeWB+3frDKQvzlNUDlzm3+2wY1NEXOTnG6u X26/y8KC6eR7pdD3SizFGYmGWsxFxYkA1MOBEIACAAA= Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 16:28:12 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48128432ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you'd like to inherit t= he priorities of the LSP you're re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks... From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of M= argaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards ... Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_4A1562797D64E44993C5CBF38CF1BE48128432ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Cyril,

 

Your idea is a bright = workaround but I would not bind the capability of setting up inquiry LSPs t= o the capability of supporting priorities and supporting the capability of = changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, I guess you̵= 7;d like to inherit the priorities of the LSP you’re re-optimizing.

 

Re the Admin status ob= ject VS the LSP_attributes I think the choice depends on the relationship b= etween the existing LSP and the inquiry LSP. If the inquiry LSP is a new on= e I would suggest to use the Admin status (it is not so different from e.g. the exercise status), while if the two L= SP are linked, maybe the LSP_attributes is more appropriate.

 

My 2 cents<= /span>

Daniele

 

PS. I have the suspect= that we turning RSVP-TE into a management protocol between a client and a = server networks…

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: mercoled=EC 31 luglio 2013 13:24
To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi, =

 

 

The LSP inquiry withou= t resource locking (at a given priority then) mechanism is present not rese= rve the resource for other LSPs (of same or higher priority) or preempt low= er priority.

 

Could this be achieved= by setting the LSP with a lower holding priority, signal is as pre-planned= AND indicate that this should not preempt other LSPs.

When this is instantia= ted a new LSP (or the same ) can be signaled with SE and explicit ERO with = the changed flag.

 

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: Zafar Ali (zali) [ma= ilto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Marg= aria- 

&n= bsp;

Resourc= e reservation (in control plane) are always associated with a given priorit= y. The inquiry LSP should be signaled using the same setup and hold priorit= y as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect blocking for th= e inquiry LSP (as resource may be available at the priority of the LSP but = may not be available at the 7 (lowest) priority. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= … Zafar

&n= bsp;

From: <Margaria>, "Cyril (Coriant - DE/Munich)= " <cyril.margaria@cor= iant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Hi,

 

For the resource reser= vation aspect, this seems related to priorities, LSP inquiry without reserv= ation could be defined as LSP with setup, holding priority 8 (or 255). This= would in addition allow for reporting when the resource are gone (preempted) =

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Khuz= ema: 

 <= /span>

Please = see in-line. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Hi Zafar,

 

The point I am making = here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly s= ame in terms of object re-use and both of them defines new bits for enhance= d functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not d= esirable.

 

 <= /span>

The inquire/ potential reopt LSP is likely not to fol= low path of the currently active LSP. Hence this cannot be implemented by j= ust adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 <= /span>

Thanks

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Khuz= ema:

 

For signalin= g inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&= nbsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &nb= sp;

 

Thanks

 

Regards R= 30; Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking… aren’t you?=

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.<= /o:p>

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:= zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Khuzema= :

 <= /span>

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Another point I spoke = about in the meeting ..

 

Why can’t we ext= end Admin Status object to signal resource locking, checking for re-optimiz= ation. Since this operation is typically done in maintenance window by Admi= n, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.<= o:p>

 

Khuzema

 

--_000_4A1562797D64E44993C5CBF38CF1BE48128432ESESSMB301ericsso_-- From ggrammel@juniper.net Sat Aug 3 13:28:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E677321F9E7C for ; Sat, 3 Aug 2013 13:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+2E1Bfbx9gv for ; Sat, 3 Aug 2013 13:28:35 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id B5D0A11E80D1 for ; Sat, 3 Aug 2013 13:28:35 -0700 (PDT) Received: from mail8-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE015.bigfish.com (10.236.130.78) with Microsoft SMTP Server id 14.1.225.22; Sat, 3 Aug 2013 20:28:35 +0000 Received: from mail8-co9 (localhost [127.0.0.1]) by mail8-co9-R.bigfish.com (Postfix) with ESMTP id EF22F1400A2 for ; Sat, 3 Aug 2013 20:28:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371Ic89bhc85dhec9I31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1de096h8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail8-co9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=ggrammel@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail8-co9 (localhost.localdomain [127.0.0.1]) by mail8-co9 (MessageSwitch) id 1375561711516208_1957; Sat, 3 Aug 2013 20:28:31 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.225]) by mail8-co9.bigfish.com (Postfix) with ESMTP id 79169CC0047 for ; Sat, 3 Aug 2013 20:28:31 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.52) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 3 Aug 2013 20:28:31 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 3 Aug 2013 13:28:30 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Sat, 3 Aug 2013 13:28:30 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.252) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 3 Aug 2013 13:41:23 -0700 Received: from mail160-db9-R.bigfish.com (10.174.16.238) by DB9EHSOBE041.bigfish.com (10.174.14.104) with Microsoft SMTP Server id 14.1.225.22; Sat, 3 Aug 2013 20:28:27 +0000 Received: from mail160-db9 (localhost [127.0.0.1]) by mail160-db9-R.bigfish.com (Postfix) with ESMTP id 2F8A22201E0 for ; Sat, 3 Aug 2013 20:28:27 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(199002)(189002)(37854004)(33646001)(46102001)(76482001)(54316002)(74876001)(16406001)(81542001)(54356001)(53806001)(81342001)(74366001)(51856001)(15202345003)(19300405004)(47736001)(49866001)(50986001)(80022001)(74316001)(66066001)(47976001)(65816001)(74706001)(83072001)(74502001)(47446002)(69226001)(74662001)(31966008)(4396001)(80976001)(63696002)(83322001)(19580395003)(19580405001)(19580385001)(59766001)(77982001)(79102001)(56816003)(77096001)(76786001)(76796001)(16236675002)(76576001)(56776001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB043; H:BN1PR05MB041.namprd05.prod.outlook.com; CLIP:193.110.54.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail160-db9 (localhost.localdomain [127.0.0.1]) by mail160-db9 (MessageSwitch) id 1375561704642971_1914; Sat, 3 Aug 2013 20:28:24 +0000 (UTC) Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.225]) by mail160-db9.bigfish.com (Postfix) with ESMTP id 97D3432020B; Sat, 3 Aug 2013 20:28:24 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 3 Aug 2013 20:28:24 +0000 Received: from BN1PR05MB043.namprd05.prod.outlook.com (10.255.202.148) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sat, 3 Aug 2013 20:28:22 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB043.namprd05.prod.outlook.com (10.255.202.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Sat, 3 Aug 2013 20:28:20 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.152]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.152]) with mapi id 15.00.0731.000; Sat, 3 Aug 2013 20:28:20 +0000 From: Gert Grammel To: Daniele Ceccarelli , "Margaria, Cyril (Coriant - DE/Munich)" , "Zafar Ali (zali)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQAAiR5UA= Date: Sat, 3 Aug 2013 20:28:19 +0000 Message-ID: <2067a7d5b6ba48d295c5851caf5ea82d@BN1PR05MB041.namprd05.prod.outlook.com> References: <523C37072C291347B9730C9291CCA07D0D0F1B@DB3PRD0411MB427.eurprd04.prod.outlook.com> <523C37072C291347B9730C9291CCA07D0D0FDC@DB3PRD0411MB427.eurprd04.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE48128432@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48128432@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.54.36] x-forefront-prvs: 0927AA37C7 Content-Type: multipart/alternative; boundary="_000_2067a7d5b6ba48d295c5851caf5ea82dBN1PR05MB041namprd05pro_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CORIANT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 20:28:43 -0000 --_000_2067a7d5b6ba48d295c5851caf5ea82dBN1PR05MB041namprd05pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I don't think it is a good design to let clients blindly poke into the serv= er domain. If an objective function is met, why is the client still poking = the server? Is it for a different objective function? Then what is the crit= eria to stop poking around? Gert From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli Sent: 03 August 2013 18:28 To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithew= an; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you'd like to inherit t= he priorities of the LSP you're re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks... From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards ... Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_2067a7d5b6ba48d295c5851caf5ea82dBN1PR05MB041namprd05pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

I don&#= 8217;t think it is a good design to let clients blindly poke into the serve= r domain. If an objective function is met, why is the client still poking t= he server? Is it for a different objective function? Then what is the criteria to stop poking around?

&n= bsp;

Gert

&n= bsp;

From: ccamp-bounces@ietf.org [= mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: 03 August 2013 18:28
To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema= Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Cyri= l,

 <= /span>

Your id= ea is a bright workaround but I would not bind the capability of setting up= inquiry LSPs to the capability of supporting priorities and supporting the= capability of changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, = I guess you’d like to inherit the priorities of the LSP you’re = re-optimizing.

 <= /span>

Re the = Admin status object VS the LSP_attributes I think the choice depends on the= relationship between the existing LSP and the inquiry LSP. If the inquiry = LSP is a new one I would suggest to use the Admin status (it is not so different from e.g. the exercise status), w= hile if the two LSP are linked, maybe the LSP_attributes is more appropriat= e.

 <= /span>

My 2 ce= nts

Daniele=

 <= /span>

PS. I h= ave the suspect that we turning RSVP-TE into a management protocol between = a client and a server networks…

 <= /span>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: mercoled=EC 31 luglio 2013 13:24
To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

 <= /span>

The LSP= inquiry without resource locking (at a given priority then) mechanism is p= resent not reserve the resource for other LSPs (of same or higher priority)= or preempt lower priority.

 <= /span>

Could t= his be achieved by setting the LSP with a lower holding priority, signal is= as pre-planned AND indicate that this should not preempt other LSPs.

When th= is is instantiated a new LSP (or the same ) can be signaled with SE and exp= licit ERO with the changed flag.

 <= /span>

 <= /span>

Mit freundlichen Gr=FC=DF= en / Best Regards
Cyril Margaria

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Margaria- 

 

Resource reservation (in control plane) are always associated with = a given priority. The inquiry LSP should be signaled using the same setup a= nd hold priority as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect b= locking for the inquiry LSP (as resource may be available at the priority o= f the LSP but may not be available at the 7 (lowest) priority. =

 

Thanks

 

Regards … Zafar=

 

From: = <Margaria>, &qu= ot;Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

For the= resource reservation aspect, this seems related to priorities, LSP inquiry= without reservation could be defined as LSP with setup, holding priority 8= (or 255). This would in addition allow for reporting when the resource are gone (preempted)

 <= /span>

Mit freundlichen Gr=FC=DF= en / Best Regards
Cyril Margaria

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema: 

 

Please see in-line. 

 

Thanks

 

Regards … Zafar=

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Zafa= r,

 <= /span>

The poi= nt I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes= , are exactly same in terms of object re-use and both of them defines new b= its for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which= is not desirable.

 <= /span>

 

The inquire/ potential reopt LSP is li= kely not to follow path of the currently active LSP. Hence this cannot be i= mplemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks<= /span>

Khuzema=

 <= /span>

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema:

 

For signaling inquiry LSP with resource locking, we are using the Pre-Pl= anned LSP flag as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource l= ocking.  

 

Thanks

 

Regards … Zafar

 

From: Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. = not really.

 <= /span>

You are= defining new bits for LSP_ATTRIBUTES for resource locking… aren̵= 7;t you?

 <= /span>

Instead= of doing that, you can define bits in ADMIN_STATUS and save new LSP life c= ycle management, which would be quite cumbersome.

 <= /span>

Regards=

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema:

 

The point is to reuse what already exists. The Pre-Planned LSP= flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already define= d in [RFC5420] and is a glove fit. 

 

Thanks

 

Regards … Zafar=

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Another= point I spoke about in the meeting ..

 <= /span>

Why can= ’t we extend Admin Status object to signal resource locking, checking= for re-optimization. Since this operation is typically done in maintenance= window by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin= Status object.

 <= /span>

This wi= ll save network element to manage life of additional LSP and control plane = failure related issues attached to the additional LSP.

 <= /span>

Khuzema=

 <= /span>

--_000_2067a7d5b6ba48d295c5851caf5ea82dBN1PR05MB041namprd05pro_-- From zali@cisco.com Sat Aug 3 15:00:18 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083BD11E80C5 for ; Sat, 3 Aug 2013 15:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf9EXmzwP-1l for ; Sat, 3 Aug 2013 15:00:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D729111E80E3 for ; Sat, 3 Aug 2013 15:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43766; q=dns/txt; s=iport; t=1375567212; x=1376776812; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=To9AqnyT+d+1jJsuXQbzVhooohONKVU7Z1lmcSKJfjA=; b=mTHeEtVMmar++eO+w6I7+Dom4mTF8t2wSRxl9QHH1qhKh2/84TC02fQG wk8b3nv3zZrKl0fOj2o2sthgsFQIrjSIENxxO+ffJqE5eZnEI9lHyhRJE 6M74Jba4xF6UeZWiJm9N4ysVJiJrS/dzGXcl6zAiSFBGw4Ry869X0j2rQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADR9/VGtJXG//2dsb2JhbABagkJENVC/FIEeFnSCJAEBAQEDLUUZAQgOAwMBAQELFgEGORQJCAIEARIIEYd3tj+OUYEXDRMXAYMZdAOpL4MXgXE5 X-IronPort-AV: E=Sophos;i="4.89,808,1367971200"; d="scan'208,217";a="243138303" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 03 Aug 2013 22:00:11 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r73M0A23012506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Aug 2013 22:00:10 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sat, 3 Aug 2013 17:00:09 -0500 From: "Zafar Ali (zali)" To: Gert Grammel , Daniele Ceccarelli , "Margaria, Cyril (Coriant - DE/Munich)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQAAiR5UAABYt+gA== Date: Sat, 3 Aug 2013 22:00:09 +0000 Message-ID: In-Reply-To: <2067a7d5b6ba48d295c5851caf5ea82d@BN1PR05MB041.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.254.147] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9FAF9Axmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 22:00:18 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9FAF9Axmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gert: Firstly, the inquiry (or poking) is much controlled by Policy. It is not th= at client network will probe server network blindly. Usually this operation= will only be done during maintenance window and/ or in a well controlled f= ashion. Secondly, routing is not only about the objective function (changes). As cl= ient layer understands and dedicates the requirement for the client connect= ion (SRLG and other routing constraints, metric bound, OF, etc.), client la= yer is in better position to dedicate what path would be acceptable should = an unprotected tunnel connection goes down. If a connection cannot be resto= re using existing constraints, UNI-C may change the constraints depending o= n what is acceptable to the client layer. Please also refer to Matt's email= on this. Thanks Regards =85 Zafar From: Gert Grammel > Date: Saturday, August 3, 2013 4:28 PM To: Daniele Ceccarelli >, "Margaria, Cyril (Coriant - DE/Munich)" >, zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, I don=92t think it is a good design to let clients blindly poke into the se= rver domain. If an objective function is met, why is the client still pokin= g the server? Is it for a different objective function? Then what is the cr= iteria to stop poking around? Gert From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 03 August 2013 18:28 To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithew= an; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you=92d like to inherit= the priorities of the LSP you=92re re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks=85 From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards =85 Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking=85 aren= =92t you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can=92t we extend Admin Status object to signal resource locking, check= ing for re-optimization. Since this operation is typically done in maintena= nce window by Admin, it may make sense to use Admin Status Object. Moreover= , we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_B6585D85A128FD47857D0FD58D8120D30E9FAF9Axmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Gert: 

Firstly, the inquiry (or poking) is much controlled by Policy. It is n= ot that client network will probe server network blindly. Usually this oper= ation will only be done during maintenance window and/ or in a well control= led fashion. 

Secondly, routing is not only about the objective function (changes). = As client layer understands and dedicates the requirement for the client co= nnection (SRLG and other routing constraints, metric bound, OF, etc.), clie= nt layer is in better position to dedicate what path would be acceptable should an unprotected tunnel connec= tion goes down. If a connection cannot be restore using existing const= raints, UNI-C may change the constraints depending on what is acceptab= le to the client layer. Please also refer to Matt's email on this. 

Thanks

Regards =85 Zafar

From: Gert Grammel <ggrammel@juniper.net>
Date: Saturday, August 3, 2013 4:28= PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com= >, "Margaria, Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>, zali <zali@cisco.com>, Khuzema= Pithewan <kpithewan@infinera.= com>, "ccamp@ietf.org&quo= t; <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccam= p-lsp-inquiry-00

Hi,

&n= bsp;

I don= =92t think it is a good design to let clients blindly poke into the server = domain. If an objective function is met, why is the client still poking the= server? Is it for a different objective function? Then what is the criteria to stop poking around?

&n= bsp;

Gert

&n= bsp;

From:<= /b> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: 03 August 2013 18:28
To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema= Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Cyri= l,

 <= /span>

Your id= ea is a bright workaround but I would not bind the capability of setting up= inquiry LSPs to the capability of supporting priorities and supporting the= capability of changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, = I guess you=92d like to inherit the priorities of the LSP you=92re re-optim= izing.

 <= /span>

Re the = Admin status object VS the LSP_attributes I think the choice depends on the= relationship between the existing LSP and the inquiry LSP. If the inquiry = LSP is a new one I would suggest to use the Admin status (it is not so different from e.g. the exercise status), w= hile if the two LSP are linked, maybe the LSP_attributes is more appropriat= e.

 <= /span>

My 2 ce= nts

Daniele=

 <= /span>

PS. I h= ave the suspect that we turning RSVP-TE into a management protocol between = a client and a server networks=85

 <= /span>

 

Hi,

 <= /span>

 <= /span>

The LSP= inquiry without resource locking (at a given priority then) mechanism is p= resent not reserve the resource for other LSPs (of same or higher priority)= or preempt lower priority.

 <= /span>

Could t= his be achieved by setting the LSP with a lower holding priority, signal is= as pre-planned AND indicate that this should not preempt other LSPs.

When th= is is instantiated a new LSP (or the same ) can be signaled with SE and exp= licit ERO with the changed flag.

 <= /span>

 <= /span>

Mit freundlichen Gr=FC=DFen / Best Re= gards
Cyril Margaria

From:<= /b> Zafar Ali (zali) [mailto:zali@= cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Margaria- 

 

Resource reservation (in control plane) are always associated with = a given priority. The inquiry LSP should be signaled using the same setup a= nd hold priority as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect b= locking for the inquiry LSP (as resource may be available at the priority o= f the LSP but may not be available at the 7 (lowest) priority. =

 

Thanks

 

Regards =85 Zafar

 

From: = <Margaria>, &qu= ot;Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

For the= resource reservation aspect, this seems related to priorities, LSP inquiry= without reservation could be defined as LSP with setup, holding priority 8= (or 255). This would in addition allow for reporting when the resource are gone (preempted)

 <= /span>

Mit freundlichen Gr=FC=DFen / Bes= t Regards
Cyril Margaria

 

Hi Khuzema: 

 

Please see in-line. 

 

Thanks

 

Regards =85 Zafar

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Zafa= r,

 <= /span>

The poi= nt I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes= , are exactly same in terms of object re-use and both of them defines new b= its for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which= is not desirable.

 <= /span>

 

The inquire/ potential reopt LSP is li= kely not to follow path of the currently active LSP. Hence this cannot be i= mplemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks<= /span>

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali@cisco.com] <= br> Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuze= ma:

 =

For signaling= inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&n= bsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without res= ource locking.  

 =

Thanks=

 =

Regards =85 Z= afar

 

From: Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. = not really.

 <= /span>

You are= defining new bits for LSP_ATTRIBUTES for resource locking=85 aren=92t you?=

 <= /span>

Instead= of doing that, you can define bits in ADMIN_STATUS and save new LSP life c= ycle management, which would be quite cumbersome.

 <= /span>

Regards=

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali= @cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema:

 

The point is to reuse what already exists. The Pre-Planned LSP= flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already define= d in [RFC5420] and is a glove fit. 

 

Thanks

 

Regards =85 Zafar

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Another= point I spoke about in the meeting ..

 <= /span>

Why can= =92t we extend Admin Status object to signal resource locking, checking for= re-optimization. Since this operation is typically done in maintenance win= dow by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin= Status object.

 <= /span>

This wi= ll save network element to manage life of additional LSP and control plane = failure related issues attached to the additional LSP.

 <= /span>

Khuzema=

 <= /span>

--_000_B6585D85A128FD47857D0FD58D8120D30E9FAF9Axmbrcdx14ciscoc_-- From zhangfatai@huawei.com Mon Aug 5 19:26:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A4221F92C2 for ; Mon, 5 Aug 2013 19:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=3.609, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gytbe9bwpOKx for ; Mon, 5 Aug 2013 19:26:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E339821F90AC for ; Mon, 5 Aug 2013 19:26:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUD03386; Tue, 06 Aug 2013 02:26:03 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 6 Aug 2013 03:25:55 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 6 Aug 2013 03:26:01 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.007; Tue, 6 Aug 2013 10:25:56 +0800 From: Fatai Zhang To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-gmpls-g709-framework.all@tools.ietf.org" Thread-Topic: AD review of draft-ietf-ccamp-gmpls-g709-framework Thread-Index: Ac6IkPjHAf7FJy/FS5u7e31pZmaAPgJud1yg Date: Tue, 6 Aug 2013 02:25:55 +0000 Message-ID: References: <03c801ce8891$02322800$06967800$@olddog.co.uk> In-Reply-To: <03c801ce8891$02322800$06967800$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-g709-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 02:26:15 -0000 Hi Adrian, I was advised by my our WG chairs that I should respond you here. A new version of this draft (ie., draft-ietf-ccamp-gmpls-g709-framework-14)= has been submitted to address your following comments. Please see more in-line to check how these comments have been addressed.=20 Best Regards Fatai -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Thursday, July 25, 2013 1:13 AM To: draft-ietf-ccamp-gmpls-g709-framework.all@tools.ietf.org Cc: ccamp@ietf.org Subject: AD review of draft-ietf-ccamp-gmpls-g709-framework Thanks for this document. It is really well-written and a good read. I am sure a lot of effort went into it, so many thanks for the=20 attention you have given to getting it right. I have two requests for small additions to the document and a couple of nits. Obviously, these comments are up for debate, but until then I have placed the document in "Revised I-D Needed" state. Once we resolve these issues or you post a new revision I will issue IETF last call. Thanks, Adrian =3D=3D=3D Please add a new section to provide a discussion of network management and OAM. A way to approach this is to look at Appendix A of RFC 5706=20 and use that to guide to what you should write. Alternatively, you could use RFC 6123 to give you guidance and structure. This information is more important in the framework document than in the protocol documents because it will set the scene correctly. A lot of this can probably be done by reference to existing documentation, and a total of only a few paragraphs will probably suffice. I suggest this goes in as Section 5.7 "Implications for Management of GMPLS Networks" [Fatai] Agreed, and a new section 5.7 was created with a few paragraphs and= [RFC3945] & [RFC5440] were referenced for more information about managemen= t aspects. --- "OTN" needs to be expanded on first use in the Introduction. [Fatai] Expanded as suggested.=20 --- The phrase "OTN network" seems to be redundant.=20 [Fatai] "network/networks" was removed as suggested. --- Section 7 should talk about whether the DCN is likely to be in the=20 overhead and therefore in-fiber. This approach, together with access=20 lists at the network edges, provides a significant security feature. [Fatai] Updated as suggested.=20 From ggrammel@juniper.net Tue Aug 6 08:40:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD8421F9476 for ; Tue, 6 Aug 2013 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip1Viz6p0fXq for ; Tue, 6 Aug 2013 08:40:52 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id CD1AE21F8B12 for ; Tue, 6 Aug 2013 08:40:51 -0700 (PDT) Received: from mail225-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Aug 2013 15:40:50 +0000 Received: from mail225-va3 (localhost [127.0.0.1]) by mail225-va3-R.bigfish.com (Postfix) with ESMTP id D37BF100087; Tue, 6 Aug 2013 15:40:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371Ic89bhc85dhec9I31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah18c673h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail225-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=ggrammel@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(37854004)(377454003)(189002)(199002)(79102001)(16236675002)(19580385001)(19300405004)(83322001)(54356001)(31966008)(74662001)(83072001)(15202345003)(65816001)(56776001)(54316002)(77982001)(59766001)(74366001)(19580405001)(19580395003)(80022001)(74316001)(76482001)(33646001)(66066001)(76576001)(74706001)(81542001)(16406001)(47446002)(51856001)(77096001)(80976001)(76786001)(76796001)(4396001)(56816003)(63696002)(47736001)(46102001)(81342001)(74876001)(47976001)(50986001)(69226001)(53806001)(49866001)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB044; H:BN1PR05MB041.namprd05.prod.outlook.com; CLIP:193.110.54.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail225-va3 (localhost.localdomain [127.0.0.1]) by mail225-va3 (MessageSwitch) id 137580364866161_31453; Tue, 6 Aug 2013 15:40:48 +0000 (UTC) Received: from VA3EHSMHS040.bigfish.com (unknown [10.7.14.241]) by mail225-va3.bigfish.com (Postfix) with ESMTP id 0C26E30004A; Tue, 6 Aug 2013 15:40:48 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS040.bigfish.com (10.7.99.50) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 6 Aug 2013 15:40:47 +0000 Received: from BN1PR05MB044.namprd05.prod.outlook.com (10.255.202.154) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 6 Aug 2013 15:40:47 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB044.namprd05.prod.outlook.com (10.255.202.154) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 6 Aug 2013 15:40:44 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.216]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.216]) with mapi id 15.00.0731.000; Tue, 6 Aug 2013 15:40:44 +0000 From: Gert Grammel To: "Zafar Ali (zali)" , Daniele Ceccarelli , "Margaria, Cyril (Coriant - DE/Munich)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQAAiR5UAABYt+gACGkgXQ Date: Tue, 6 Aug 2013 15:40:43 +0000 Message-ID: <3b003053a8884105a66387e1bb6b3521@BN1PR05MB041.namprd05.prod.outlook.com> References: <2067a7d5b6ba48d295c5851caf5ea82d@BN1PR05MB041.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.54.36] x-forefront-prvs: 0930AAFAD9 Content-Type: multipart/alternative; boundary="_000_3b003053a8884105a66387e1bb6b3521BN1PR05MB041namprd05pro_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$infinera.com%0%1%DuplicateDomain-c684c95e-93ad-459f-9d80-96fa46cd75af.juniper.net%False%False%0$ X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INFINERA.COM$RO%1$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%CORIANT.COM$RO%1$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:40:58 -0000 --_000_3b003053a8884105a66387e1bb6b3521BN1PR05MB041namprd05pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zhafar, how would that policy enforced? In the end every topology information has t= o be poked out of the server network and how frequent/updated this informat= ion is, is not visible to the client. When you say: If a connection cannot be restore using existing const= raints, UNI-C may change the constraints depending on what is acceptable to= the client layer. How is the client able to figure out which constraint is eventually able to= succeed? And if it doesn't what is the client about to do? In other words, how does the client network able to understand that it is b= eating a dead horse (a server network that is full), and how does it unders= tand that it actually is no more? -Gert From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: 04 August 2013 00:00 To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich)= ; Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Gert: Firstly, the inquiry (or poking) is much controlled by Policy. It is not th= at client network will probe server network blindly. Usually this operation= will only be done during maintenance window and/ or in a well controlled f= ashion. Secondly, routing is not only about the objective function (changes). As cl= ient layer understands and dedicates the requirement for the client connect= ion (SRLG and other routing constraints, metric bound, OF, etc.), client la= yer is in better position to dedicate what path would be acceptable should = an unprotected tunnel connection goes down. If a connection cannot be resto= re using existing constraints, UNI-C may change the constraints depending o= n what is acceptable to the client layer. Please also refer to Matt's email= on this. Thanks Regards ... Zafar From: Gert Grammel > Date: Saturday, August 3, 2013 4:28 PM To: Daniele Ceccarelli >, "Margaria, Cyril (Coriant - DE/Munich)" >, zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, I don't think it is a good design to let clients blindly poke into the serv= er domain. If an objective function is met, why is the client still poking = the server? Is it for a different objective function? Then what is the crit= eria to stop poking around? Gert From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 03 August 2013 18:28 To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithew= an; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you'd like to inherit t= he priorities of the LSP you're re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks... From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards ... Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_3b003053a8884105a66387e1bb6b3521BN1PR05MB041namprd05pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Zhafar,<= /span>

 

how wou= ld that policy enforced? In the end every topology information has to be po= ked out of the server network and how frequent/updated this information is,= is not visible to the client.

When yo= u say: <snip> If a con= nection cannot be restore using existing constraints, UNI-C may c= hange the constraints depending on what is acceptable to the client layer.<= /span> <snip>

How is = the client able to figure out which constraint is eventually able to succee= d?

And if = it doesn’t what is the client about to do?

&n= bsp;

In othe= r words, how does the client network able to understand that it is beating = a dead horse (a server network that is full), and how does it understand th= at it actually is no more?

&n= bsp;

-Gert

&n= bsp;

From: Zafar Ali (zali) [mailto= :zali@cisco.com]
Sent: 04 August 2013 00:00
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/= Munich); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Gert= : 

&n= bsp;

Firstly= , the inquiry (or poking) is much controlled by Policy. It is not that clie= nt network will probe server network blindly. Usually this operation will o= nly be done during maintenance window and/ or in a well controlled fashion. 

&n= bsp;

Secondl= y, routing is not only about the objective function (changes). As client la= yer understands and dedicates the requirement for the client connection (SR= LG and other routing constraints, metric bound, OF, etc.), client layer is in better position to dedicate what path= would be acceptable should an unprotected tunnel connection goes down. If = a connection cannot be restore using existing constraints, UNI-C = may change the constraints depending on what is acceptable to the client layer. Please also refer to Matt's email = on this. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= … Zafar

&n= bsp;

From: Gert Grammel <ggrammel@juniper.net>
Date: Saturday, August 3, 2013 4:28 PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (C= oriant - DE/Munich)" <cyril.margaria@coriant.com>, zali <zali@cisco.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Hi,

 <= /span>

I don&#= 8217;t think it is a good design to let clients blindly poke into the serve= r domain. If an objective function is met, why is the client still poking t= he server? Is it for a different objective function? Then what is the criteria to stop poking around?

 <= /span>

Gert

 <= /span>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: 03 August 2013 18:28
To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema= Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Cyri= l,

 <= /span>

Your id= ea is a bright workaround but I would not bind the capability of setting up= inquiry LSPs to the capability of supporting priorities and supporting the= capability of changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, = I guess you’d like to inherit the priorities of the LSP you’re = re-optimizing.

 <= /span>

Re the = Admin status object VS the LSP_attributes I think the choice depends on the= relationship between the existing LSP and the inquiry LSP. If the inquiry = LSP is a new one I would suggest to use the Admin status (it is not so different from e.g. the exercise status), w= hile if the two LSP are linked, maybe the LSP_attributes is more appropriat= e.

 <= /span>

My 2 ce= nts

Daniele=

 <= /span>

PS. I h= ave the suspect that we turning RSVP-TE into a management protocol between = a client and a server networks…

 <= /span>

From:<= a href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: mercoled=EC 31 luglio 2013 13:24
To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

 <= /span>

The LSP= inquiry without resource locking (at a given priority then) mechanism is p= resent not reserve the resource for other LSPs (of same or higher priority)= or preempt lower priority.

 <= /span>

Could t= his be achieved by setting the LSP with a lower holding priority, signal is= as pre-planned AND indicate that this should not preempt other LSPs.

When th= is is instantiated a new LSP (or the same ) can be signaled with SE and exp= licit ERO with the changed flag.

 <= /span>

 <= /span>

Mit freundlichen Gr=FC=DF= en / Best Regards
Cyril Margaria

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Margaria- 

 

Resource reservation (in control plane) are always associated with = a given priority. The inquiry LSP should be signaled using the same setup a= nd hold priority as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect b= locking for the inquiry LSP (as resource may be available at the priority o= f the LSP but may not be available at the 7 (lowest) priority. =

 

Thanks

 

Regards … Zafar=

 

From: = <Margaria>, &qu= ot;Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

For the= resource reservation aspect, this seems related to priorities, LSP inquiry= without reservation could be defined as LSP with setup, holding priority 8= (or 255). This would in addition allow for reporting when the resource are gone (preempted)

 <= /span>

Mit freundlichen Gr=FC=DF= en / Best Regards
Cyril Margaria

From:<= a href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema: 

 

Please see in-line. 

 

Thanks

 

Regards … Zafar=

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Zafa= r,

 <= /span>

The poi= nt I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes= , are exactly same in terms of object re-use and both of them defines new b= its for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which= is not desirable.

 <= /span>

 

The inquire/ potential reopt LSP is li= kely not to follow path of the currently active LSP. Hence this cannot be i= mplemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks<= /span>

Khuzema=

 <= /span>

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema:

 

For signaling inquiry LSP with resource locking, we are using the Pre-Pl= anned LSP flag as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource l= ocking.  

 

Thanks

 

Regards … Zafar

 

From: Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. = not really.

 <= /span>

You are= defining new bits for LSP_ATTRIBUTES for resource locking… aren̵= 7;t you?

 <= /span>

Instead= of doing that, you can define bits in ADMIN_STATUS and save new LSP life c= ycle management, which would be quite cumbersome.

 <= /span>

Regards=

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema:

 

The point is to reuse what already exists. The Pre-Planned LSP= flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already define= d in [RFC5420] and is a glove fit. =

 

Thanks

 

Regards … Zafar=

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Another= point I spoke about in the meeting ..

 <= /span>

Why can= ’t we extend Admin Status object to signal resource locking, checking= for re-optimization. Since this operation is typically done in maintenance= window by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin= Status object.

 <= /span>

This wi= ll save network element to manage life of additional LSP and control plane = failure related issues attached to the additional LSP.

 <= /span>

Khuzema=

 <= /span>

--_000_3b003053a8884105a66387e1bb6b3521BN1PR05MB041namprd05pro_-- From zhangfatai@huawei.com Tue Aug 6 20:32:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3650321F9CA2 for ; Tue, 6 Aug 2013 20:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=3.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTmYP7niZDGU for ; Tue, 6 Aug 2013 20:31:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE3021F9CA1 for ; Tue, 6 Aug 2013 20:31:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUD93826; Wed, 07 Aug 2013 03:31:50 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 7 Aug 2013 04:31:01 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 7 Aug 2013 04:31:10 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.007; Wed, 7 Aug 2013 11:31:04 +0800 From: Fatai Zhang To: "Zafar Ali (zali)" , Gert Grammel , Daniele Ceccarelli , "Margaria, Cyril (Coriant - DE/Munich)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQAAiR5UAABYt+gACgPkbg Date: Wed, 7 Aug 2013 03:31:04 +0000 Message-ID: References: <2067a7d5b6ba48d295c5851caf5ea82d@BN1PR05MB041.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84EE46AC5SZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 03:32:01 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF84EE46AC5SZXEML552MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zafar, As I said, I don't think this is a good idea. It is not feasible in the pra= ctical deployment. I also agree with Gert. Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Z= afar Ali (zali) Sent: Sunday, August 04, 2013 6:00 AM To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich)= ; Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Gert: Firstly, the inquiry (or poking) is much controlled by Policy. It is not th= at client network will probe server network blindly. Usually this operation= will only be done during maintenance window and/ or in a well controlled f= ashion. Secondly, routing is not only about the objective function (changes). As cl= ient layer understands and dedicates the requirement for the client connect= ion (SRLG and other routing constraints, metric bound, OF, etc.), client la= yer is in better position to dedicate what path would be acceptable should = an unprotected tunnel connection goes down. If a connection cannot be resto= re using existing constraints, UNI-C may change the constraints depending o= n what is acceptable to the client layer. Please also refer to Matt's email= on this. Thanks Regards ... Zafar From: Gert Grammel > Date: Saturday, August 3, 2013 4:28 PM To: Daniele Ceccarelli >, "Margaria, Cyril (Coriant - DE/Munich)" >, zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, I don't think it is a good design to let clients blindly poke into the serv= er domain. If an objective function is met, why is the client still poking = the server? Is it for a different objective function? Then what is the crit= eria to stop poking around? Gert From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 03 August 2013 18:28 To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithew= an; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you'd like to inherit t= he priorities of the LSP you're re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks... From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards ... Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_F82A4B6D50F9464B8EBA55651F541CF84EE46AC5SZXEML552MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Zafar,

 

As I said, I don’t think this is a good idea. It is not fea= sible in the practical deployment.

 

I also agree = with Gert.

 

 

 

Best Regards<= o:p>

 

Fatai

 

From: ccamp-bounces@ietf.org [= mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Sunday, August 04, 2013 6:00 AM
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/= Munich); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Gert: 

 

Firstly, the inquiry (or poking) is much controlled by Policy. It is= not that client network will probe server network blindly. Usually this op= eration will only be done during maintenance window and/ or in a well controlled fashion. 

 

Secondly, routing is not only about the objective function (changes)= . As client layer understands and dedicates the requirement for the client = connection (SRLG and other routing constraints, metric bound, OF, etc.), client layer is in better position to dedicate wh= at path would be acceptable should an unprotected tunnel connection goes do= wn. If a connection cannot be restore using existing constraints, = ;UNI-C may change the constraints depending on what is acceptable to the client layer. Please also refer to Matt'= s email on this. 

 

Thanks

 

Regards … Zafar

 

From: = Gert Grammel <ggrammel@juniper.net>
Date: Saturday, August 3, 2013 4:28 PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (C= oriant - DE/Munich)" <cyril.margaria@coriant.com>, zali <zali@cisco.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

I don&#= 8217;t think it is a good design to let clients blindly poke into the serve= r domain. If an objective function is met, why is the client still poking t= he server? Is it for a different objective function? Then what is the criteria to stop poking around?

 <= /span>

Gert

 <= /span>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: 03 August 2013 18:28
To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema= Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /o:p>

Hi Cyri= l,

 <= /span>

Your id= ea is a bright workaround but I would not bind the capability of setting up= inquiry LSPs to the capability of supporting priorities and supporting the= capability of changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, = I guess you’d like to inherit the priorities of the LSP you’re = re-optimizing.

 <= /span>

Re the = Admin status object VS the LSP_attributes I think the choice depends on the= relationship between the existing LSP and the inquiry LSP. If the inquiry = LSP is a new one I would suggest to use the Admin status (it is not so different from e.g. the exercise status), w= hile if the two LSP are linked, maybe the LSP_attributes is more appropriat= e.

 <= /span>

My 2 ce= nts

Daniele=

 <= /span>

PS. I h= ave the suspect that we turning RSVP-TE into a management protocol between = a client and a server networks…

 <= /span>

From:<= a href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: mercoled=EC 31 luglio 2013 13:24
To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

 <= /span>

The LSP= inquiry without resource locking (at a given priority then) mechanism is p= resent not reserve the resource for other LSPs (of same or higher priority)= or preempt lower priority.

 <= /span>

Could t= his be achieved by setting the LSP with a lower holding priority, signal is= as pre-planned AND indicate that this should not preempt other LSPs.

When th= is is instantiated a new LSP (or the same ) can be signaled with SE and exp= licit ERO with the changed flag.

 <= /span>

 <= /span>

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Margaria- 

 

Resource reservation (in control plane) are always associated with = a given priority. The inquiry LSP should be signaled using the same setup a= nd hold priority as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect b= locking for the inquiry LSP (as resource may be available at the priority o= f the LSP but may not be available at the 7 (lowest) priority. =

 

Thanks

 

Regards … Zafar

 

From: = <Margaria>, &qu= ot;Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

For the= resource reservation aspect, this seems related to priorities, LSP inquiry= without reservation could be defined as LSP with setup, holding priority 8= (or 255). This would in addition allow for reporting when the resource are gone (preempted)

 <= /span>

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From:<= a href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema: 

 

Please see in-line. 

 

Thanks

 

Regards … Zafar

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Zafa= r,

 <= /span>

The poi= nt I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes= , are exactly same in terms of object re-use and both of them defines new b= its for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which= is not desirable.

 <= /span>

 

The inquire/ potential reopt LSP is li= kely not to follow path of the currently active LSP. Hence this cannot be i= mplemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks<= /span>

Khuzema=

 <= /span>

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema:

 <= /p>

For signaling inquiry LSP with resource locking, we are using the Pre-Pl= anned LSP flag as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource l= ocking.  

 <= /p>

Thanks<= /p>

 <= /p>

Regards … Zafar

 

From: Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. = not really.

 <= /span>

You are= defining new bits for LSP_ATTRIBUTES for resource locking… aren̵= 7;t you?

 <= /span>

Instead= of doing that, you can define bits in ADMIN_STATUS and save new LSP life c= ycle management, which would be quite cumbersome.

 <= /span>

Regards=

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema:<= /span>

 

The point is to reuse what already exists. The Pre-Planned LSP= flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already define= d in [RFC5420] and is a glove fit. 

 

Thanks

 

Regards … Zafar

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Another= point I spoke about in the meeting ..

 <= /span>

Why can= ’t we extend Admin Status object to signal resource locking, checking= for re-optimization. Since this operation is typically done in maintenance= window by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin= Status object.

 <= /span>

This wi= ll save network element to manage life of additional LSP and control plane = failure related issues attached to the additional LSP.

 <= /span>

Khuzema=

 <= /span>

--_000_F82A4B6D50F9464B8EBA55651F541CF84EE46AC5SZXEML552MBXchi_-- From zali@cisco.com Wed Aug 7 07:49:00 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A4421E8117 for ; Wed, 7 Aug 2013 07:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdHCnQ6vN1K8 for ; Wed, 7 Aug 2013 07:48:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CA13811E8139 for ; Wed, 7 Aug 2013 07:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56215; q=dns/txt; s=iport; t=1375886934; x=1377096534; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=qytBhFRzO/F8f6i8xGfORMsmjFT1H/7NKvKvILCUCjo=; b=c2gIhkQ9bavUIDzBu3sIAnSdKF/2wypHSt2GDGN2k2DZqt38Q4Me2xfA W/s+VdxCPQpiVsg88RWTkoF/IQKh4dx6mDqlqe4PmoLfUT7/cHmLXwEz1 pN8lhOwN+pfC2RR4TwaKkncPEzlTusQBKeh7Ky6jL95BfnieH0HusuybD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFALddAlKtJV2d/2dsb2JhbABbgkJENVC+RoEcFnSCJAEBAQQtRRkBCA4DAwEBAQsWAQY5FAkIAgQBEggRh3e4Q45UCoELDRMXAQKDGHQDqTCDF4FoCRci X-IronPort-AV: E=Sophos;i="4.89,833,1367971200"; d="scan'208,217";a="244596861" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 07 Aug 2013 14:48:53 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r77EmqFV031410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 14:48:52 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 09:48:52 -0500 From: "Zafar Ali (zali)" To: Gert Grammel , Daniele Ceccarelli , "Margaria, Cyril (Coriant - DE/Munich)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQAAiR5UAABYt+gACGkgXQADOIbAA= Date: Wed, 7 Aug 2013 14:48:52 +0000 Message-ID: In-Reply-To: <3b003053a8884105a66387e1bb6b3521@BN1PR05MB041.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.235.183] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9FDF8Dxmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:49:00 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9FDF8Dxmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gert- Please see in-line. Thanks Regards =85 Zafar From: Gert Grammel > Date: Tuesday, August 6, 2013 11:40 AM To: zali >, Daniele Ceccarelli >, "Marga= ria, Cyril (Coriant - DE/Munich)" >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zhafar, how would that policy enforced? By UNI-C node having a policy from operator on when it should run inquiry p= rocedure. Usually, during maintenance window. In the end every topology information has to be poked out of the server net= work and how frequent/updated this information is, is not visible to the cl= ient. No, as this is a UNI. When you say: If a connection cannot be restore using existing const= raints, UNI-C may change the constraints depending on what is acceptable to= the client layer. How is the client able to figure out which constraint is eventually able to= succeed? By trying a list of paths that releases constraints from toughest to easies= t. We are talking about a list with typically 2-4 entries. And if it doesn=92t what is the client about to do? Release the path constraints =96 until it finds a path or constraints canno= t be released any further. In other words, how does the client network able to understand that it is b= eating a dead horse (a server network that is full), and how does it unders= tand that it actually is no more? Obviously we are talking about trying a very limited list of path options (= 2-4, typically). -Gert From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: 04 August 2013 00:00 To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich)= ; Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Gert: Firstly, the inquiry (or poking) is much controlled by Policy. It is not th= at client network will probe server network blindly. Usually this operation= will only be done during maintenance window and/ or in a well controlled f= ashion. Secondly, routing is not only about the objective function (changes). As cl= ient layer understands and dedicates the requirement for the client connect= ion (SRLG and other routing constraints, metric bound, OF, etc.), client la= yer is in better position to dedicate what path would be acceptable should = an unprotected tunnel connection goes down. If a connection cannot be resto= re using existing constraints, UNI-C may change the constraints depending o= n what is acceptable to the client layer. Please also refer to Matt's email= on this. Thanks Regards =85 Zafar From: Gert Grammel > Date: Saturday, August 3, 2013 4:28 PM To: Daniele Ceccarelli >, "Margaria, Cyril (Coriant - DE/Munich)" >, zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, I don=92t think it is a good design to let clients blindly poke into the se= rver domain. If an objective function is met, why is the client still pokin= g the server? Is it for a different objective function? Then what is the cr= iteria to stop poking around? Gert From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 03 August 2013 18:28 To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithew= an; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you=92d like to inherit= the priorities of the LSP you=92re re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks=85 From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards =85 Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking=85 aren= =92t you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can=92t we extend Admin Status object to signal resource locking, check= ing for re-optimization. Since this operation is typically done in maintena= nce window by Admin, it may make sense to use Admin Status Object. Moreover= , we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_B6585D85A128FD47857D0FD58D8120D30E9FDF8Dxmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <67091FC911EE75469812096FBF7E9D4E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Gert- 

Please see in-line. 

Thanks

Regards =85 Zafar

From: Gert Grammel <ggrammel@juniper.net>
Date: Tuesday, August 6, 2013 11:40= AM
To: zali <zali@cisco.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>,= "Margaria, Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccam= p-lsp-inquiry-00

Hi Zhafar,<= /span>

 

how wou= ld that policy enforced?


By UNI-C node having a policy from operator on when it should run inqu= iry procedure. Usually, during maintenance window. 

In the = end every topology information has to be poked out of the server network an= d how frequent/updated this information is, is not visible to the client.

No, as this is a UNI. 

When yo= u say: <snip> If a con= nection cannot be restore using existing constraints, UNI-C may c= hange the constraints depending on what is acceptable to the client layer.<= /span> <snip>

How is = the client able to figure out which constraint is eventually able to succee= d?

By trying a list of paths that releases constraints from toughest to e= asiest. We are talking about a list with typically 2-4 entries.  

And if = it doesn=92t what is the client about to do?

&n= bsp;

Release the path constraints =96 until it finds a path or constra= ints cannot be released any further. 

In othe= r words, how does the client network able to understand that it is beating = a dead horse (a server network that is full), and how does it understand th= at it actually is no more?

&n= bsp;

Obviously we are talking about trying a very limited list of path opti= ons (2-4, typically). 

-Gert

&n= bsp;

From:<= /b> Zafar Ali (zali) [mailto:zali@= cisco.com]
Sent: 04 August 2013 00:00
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/= Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Gert= : 

&n= bsp;

Firstly= , the inquiry (or poking) is much controlled by Policy. It is not that clie= nt network will probe server network blindly. Usually this operation will o= nly be done during maintenance window and/ or in a well controlled fashion. 

&n= bsp;

Secondl= y, routing is not only about the objective function (changes). As client la= yer understands and dedicates the requirement for the client connection (SR= LG and other routing constraints, metric bound, OF, etc.), client layer is in better position to dedicate what path= would be acceptable should an unprotected tunnel connection goes down. If = a connection cannot be restore using existing constraints, UNI-C = may change the constraints depending on what is acceptable to the client layer. Please also refer to Matt's email = on this. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= =85 Zafar

&n= bsp;

From: Gert Grammel <ggrammel@juniper.net>
Date: Saturday, August 3, 2013 4:28 PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (C= oriant - DE/Munich)" <cyril.margaria@coriant.com>, zali <zali@cisco.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Hi,

 <= /span>

I don= =92t think it is a good design to let clients blindly poke into the server = domain. If an objective function is met, why is the client still poking the= server? Is it for a different objective function? Then what is the criteria to stop poking around?

 <= /span>

Gert

 <= /span>

 =

Hi Cyri= l,

 <= /span>

Your id= ea is a bright workaround but I would not bind the capability of setting up= inquiry LSPs to the capability of supporting priorities and supporting the= capability of changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, = I guess you=92d like to inherit the priorities of the LSP you=92re re-optim= izing.

 <= /span>

Re the = Admin status object VS the LSP_attributes I think the choice depends on the= relationship between the existing LSP and the inquiry LSP. If the inquiry = LSP is a new one I would suggest to use the Admin status (it is not so different from e.g. the exercise status), w= hile if the two LSP are linked, maybe the LSP_attributes is more appropriat= e.

 <= /span>

My 2 ce= nts

Daniele=

 <= /span>

PS. I h= ave the suspect that we turning RSVP-TE into a management protocol between = a client and a server networks=85

 <= /span>

 

Hi,

 <= /span>

 <= /span>

The LSP= inquiry without resource locking (at a given priority then) mechanism is p= resent not reserve the resource for other LSPs (of same or higher priority)= or preempt lower priority.

 <= /span>

Could t= his be achieved by setting the LSP with a lower holding priority, signal is= as pre-planned AND indicate that this should not preempt other LSPs.

When th= is is instantiated a new LSP (or the same ) can be signaled with SE and exp= licit ERO with the changed flag.

 <= /span>

 <= /span>

Mit freundlichen Gr=FC=DFen / Best Re= gards
Cyril Margaria

From: Zafar Ali (zali) [mailto:zali@cisco.com] <= br> Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Margaria- 

 

Resource reservation (in control plane) are always associated with = a given priority. The inquiry LSP should be signaled using the same setup a= nd hold priority as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect b= locking for the inquiry LSP (as resource may be available at the priority o= f the LSP but may not be available at the 7 (lowest) priority. =

 

Thanks

 

Regards =85 Zafar

 

From: = <Margaria>, &qu= ot;Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

For the= resource reservation aspect, this seems related to priorities, LSP inquiry= without reservation could be defined as LSP with setup, holding priority 8= (or 255). This would in addition allow for reporting when the resource are gone (preempted)

 <= /span>

Mit freundlichen Gr=FC=DFen / Bes= t Regards
Cyril Margaria=

 

Hi Khuzema: 

 

Please see in-line. 

 

Thanks

 

Regards =85 Zafar

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Zafa= r,

 <= /span>

The poi= nt I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes= , are exactly same in terms of object re-use and both of them defines new b= its for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which= is not desirable.

 <= /span>

 

The inquire/ potential reopt LSP is li= kely not to follow path of the currently active LSP. Hence this cannot be i= mplemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks<= /span>

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali@cisco.com] <= br> Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuze= ma:

 =

For signaling= inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&n= bsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without res= ource locking.  <= /p>

 =

Thanks=

 =

Regards =85 Z= afar

 

From: Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. = not really.

 <= /span>

You are= defining new bits for LSP_ATTRIBUTES for resource locking=85 aren=92t you?=

 <= /span>

Instead= of doing that, you can define bits in ADMIN_STATUS and save new LSP life c= ycle management, which would be quite cumbersome.

 <= /span>

Regards=

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali= @cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema:

 

The point is to reuse what already exists. The Pre-Planned LSP= flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already define= d in [RFC5420] and is a glove fit. =

 

Thanks

 

Regards =85 Zafar

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Another= point I spoke about in the meeting ..

 <= /span>

Why can= =92t we extend Admin Status object to signal resource locking, checking for= re-optimization. Since this operation is typically done in maintenance win= dow by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin= Status object.

 <= /span>

This wi= ll save network element to manage life of additional LSP and control plane = failure related issues attached to the additional LSP.

 <= /span>

Khuzema=

 <= /span>

 --_000_B6585D85A128FD47857D0FD58D8120D30E9FDF8Dxmbrcdx14ciscoc_-- From ggrammel@juniper.net Wed Aug 7 08:46:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5611E8142 for ; Wed, 7 Aug 2013 08:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdK1ca80bt+P for ; Wed, 7 Aug 2013 08:46:06 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5EB21E8064 for ; Wed, 7 Aug 2013 08:46:03 -0700 (PDT) Received: from mail165-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Aug 2013 15:46:02 +0000 Received: from mail165-tx2 (localhost [127.0.0.1]) by mail165-tx2-R.bigfish.com (Postfix) with ESMTP id 70E4F2C0146; Wed, 7 Aug 2013 15:46:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371Ic89bhc85dhec9I31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah18c673h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail165-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=ggrammel@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(37854004)(199002)(189002)(377454003)(31966008)(76796001)(19300405004)(47736001)(15202345003)(49866001)(65816001)(83072001)(74316001)(66066001)(47976001)(50986001)(80976001)(77096001)(56816003)(19580385001)(46102001)(80022001)(19580405001)(79102001)(51856001)(19580395003)(47446002)(74876001)(76576001)(74366001)(76786001)(53806001)(54316002)(81542001)(77982001)(74502001)(74662001)(74706001)(54356001)(56776001)(59766001)(4396001)(81342001)(63696002)(16406001)(76482001)(16236675002)(83322001)(33646001)(69226001)(24736002)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB039; H:BLUPR05MB040.namprd05.prod.outlook.com; CLIP:193.110.54.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail165-tx2 (localhost.localdomain [127.0.0.1]) by mail165-tx2 (MessageSwitch) id 1375890358687638_3196; Wed, 7 Aug 2013 15:45:58 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.254]) by mail165-tx2.bigfish.com (Postfix) with ESMTP id A29AD3A004C; Wed, 7 Aug 2013 15:45:58 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 7 Aug 2013 15:45:49 +0000 Received: from BLUPR05MB039.namprd05.prod.outlook.com (10.255.210.148) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Wed, 7 Aug 2013 15:45:48 +0000 Received: from BLUPR05MB040.namprd05.prod.outlook.com (10.255.210.156) by BLUPR05MB039.namprd05.prod.outlook.com (10.255.210.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 7 Aug 2013 15:45:45 +0000 Received: from BLUPR05MB040.namprd05.prod.outlook.com ([169.254.1.71]) by BLUPR05MB040.namprd05.prod.outlook.com ([169.254.1.71]) with mapi id 15.00.0731.000; Wed, 7 Aug 2013 15:45:45 +0000 From: Gert Grammel To: "Zafar Ali (zali)" , Daniele Ceccarelli , "Margaria, Cyril (Coriant - DE/Munich)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQAAiR5UAABYt+gACGkgXQADOIbAAAAgPUYA== Date: Wed, 7 Aug 2013 15:45:44 +0000 Message-ID: <38a4fec6461b469fb85a26ee49f16b7b@BLUPR05MB040.namprd05.prod.outlook.com> References: <3b003053a8884105a66387e1bb6b3521@BN1PR05MB041.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.54.36] x-forefront-prvs: 0931CB1479 Content-Type: multipart/alternative; boundary="_000_38a4fec6461b469fb85a26ee49f16b7bBLUPR05MB040namprd05pro_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$infinera.com%0%1%DuplicateDomain-c684c95e-93ad-459f-9d80-96fa46cd75af.juniper.net%False%False%0$ X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INFINERA.COM$RO%1$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%CORIANT.COM$RO%1$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:46:13 -0000 --_000_38a4fec6461b469fb85a26ee49f16b7bBLUPR05MB040namprd05pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zhafar, Seems you suggest the client tries 3-4 times with something that has been i= nquired before, i.e. by 3-4 inquiry attempts. Now if none of those succeeds= , will it stay mute forever or continue poking once a while to understand w= hen it can get back? Another issue is the semantics of what is returned, as= the client semantic for a parameter is different than the server semantic. In the end we are talking about a multi-domain problem and it seems to me t= hat those kind of problems have been addressed already in the IETF. Perhap= s it would help to step back a bit and define what you want to achieve. You= r use case looks like a CE-PE relation in L1VPN enhanced mode, so why not b= uild on previous work? -Gert From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: 07 August 2013 16:49 To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich)= ; Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Gert- Please see in-line. Thanks Regards ... Zafar From: Gert Grammel > Date: Tuesday, August 6, 2013 11:40 AM To: zali >, Daniele Ceccarelli >, "Marga= ria, Cyril (Coriant - DE/Munich)" >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zhafar, how would that policy enforced? By UNI-C node having a policy from operator on when it should run inquiry p= rocedure. Usually, during maintenance window. In the end every topology information has to be poked out of the server net= work and how frequent/updated this information is, is not visible to the cl= ient. No, as this is a UNI. When you say: If a connection cannot be restore using existing const= raints, UNI-C may change the constraints depending on what is acceptable to= the client layer. How is the client able to figure out which constraint is eventually able to= succeed? By trying a list of paths that releases constraints from toughest to easies= t. We are talking about a list with typically 2-4 entries. And if it doesn't what is the client about to do? Release the path constraints - until it finds a path or constraints cannot = be released any further. In other words, how does the client network able to understand that it is b= eating a dead horse (a server network that is full), and how does it unders= tand that it actually is no more? Obviously we are talking about trying a very limited list of path options (= 2-4, typically). -Gert From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: 04 August 2013 00:00 To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich)= ; Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Gert: Firstly, the inquiry (or poking) is much controlled by Policy. It is not th= at client network will probe server network blindly. Usually this operation= will only be done during maintenance window and/ or in a well controlled f= ashion. Secondly, routing is not only about the objective function (changes). As cl= ient layer understands and dedicates the requirement for the client connect= ion (SRLG and other routing constraints, metric bound, OF, etc.), client la= yer is in better position to dedicate what path would be acceptable should = an unprotected tunnel connection goes down. If a connection cannot be resto= re using existing constraints, UNI-C may change the constraints depending o= n what is acceptable to the client layer. Please also refer to Matt's email= on this. Thanks Regards ... Zafar From: Gert Grammel > Date: Saturday, August 3, 2013 4:28 PM To: Daniele Ceccarelli >, "Margaria, Cyril (Coriant - DE/Munich)" >, zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, I don't think it is a good design to let clients blindly poke into the serv= er domain. If an objective function is met, why is the client still poking = the server? Is it for a different objective function? Then what is the crit= eria to stop poking around? Gert From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 03 August 2013 18:28 To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithew= an; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you'd like to inherit t= he priorities of the LSP you're re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks... From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards ... Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_38a4fec6461b469fb85a26ee49f16b7bBLUPR05MB040namprd05pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Zhaf= ar,

&n= bsp;

Seems y= ou suggest the client tries 3-4 times with something that has been inquired= before, i.e. by 3-4 inquiry attempts. Now if none of those succeeds, will = it stay mute forever or continue poking once a while to understand when it can get back? Another issue is the sema= ntics of what is returned, as the client semantic for a parameter is differ= ent than the server semantic.

In the = end we are talking about a multi-domain problem and it seems to me that tho= se kind of problems have been addressed already in the IETF.  Perhaps = it would help to step back a bit and define what you want to achieve. Your use case looks like a CE-PE relation in L1V= PN enhanced mode, so why not build on previous work?

&n= bsp;

-Gert <= o:p>

&n= bsp;

From: Zafar Ali (zali) [mailto= :zali@cisco.com]
Sent: 07 August 2013 16:49
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/= Munich); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Gert= - 

&n= bsp;

Please = see in-line. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= … Zafar

&n= bsp;

From: Gert Grammel <ggrammel@juniper.net>
Date: Tuesday, August 6, 2013 11:40 AM
To: zali <zali@cisco.com>= ;, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (Coriant -= DE/Munich)" <cyril.m= argaria@coriant.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Hi Zhafar,

 

how wou= ld that policy enforced?

 

By UNI-C node having a policy from operator on when i= t should run inquiry procedure. Usually, during maintenance window. 

 

In the = end every topology information has to be poked out of the server network an= d how frequent/updated this information is, is not visible to the client.

 

No, as this is a UNI. 

 

When yo= u say: <snip> If a con= nection cannot be restore using existing constraints, UNI-C may c= hange the constraints depending on what is acceptable to the client layer.<= /span> <snip>

How is = the client able to figure out which constraint is eventually able to succee= d?

 

By trying a list of paths that releases constraints f= rom toughest to easiest. We are talking about a list with typically 2-4 ent= ries.  

 

And if = it doesn’t what is the client about to do?

 <= /span>

 

Release the path constraints – until it finds a= path or constraints cannot be released any further. <= /span>

 

In othe= r words, how does the client network able to understand that it is beating = a dead horse (a server network that is full), and how does it understand th= at it actually is no more?

 <= /span>

 

Obviously we are talking about trying a very limited = list of path options (2-4, typically). 

 

-Gert

 <= /span>

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: 04 August 2013 00:00
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/= Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Gert= : 

 <= /span>

Firstly= , the inquiry (or poking) is much controlled by Policy. It is not that clie= nt network will probe server network blindly. Usually this operation will o= nly be done during maintenance window and/ or in a well controlled fashion. 

 <= /span>

Secondl= y, routing is not only about the objective function (changes). As client la= yer understands and dedicates the requirement for the client connection (SR= LG and other routing constraints, metric bound, OF, etc.), client layer is in better position to dedicate what path= would be acceptable should an unprotected tunnel connection goes down. If = a connection cannot be restore using existing constraints, UNI-C = may change the constraints depending on what is acceptable to the client layer. Please also refer to Matt's email = on this. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Gert Grammel <ggrammel@juniper.net>
Date: Saturday, August 3, 2013 4:28 PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (C= oriant - DE/Munich)" <cyril.margaria@coriant.com>, zali <zali@cisco.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Hi,

 <= /span>

I don&#= 8217;t think it is a good design to let clients blindly poke into the serve= r domain. If an objective function is met, why is the client still poking t= he server? Is it for a different objective function? Then what is the criteria to stop poking around?

 <= /span>

Gert

 <= /span>

From:<= a href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: 03 August 2013 18:28
To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema= Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Cyri= l,

 <= /span>

Your id= ea is a bright workaround but I would not bind the capability of setting up= inquiry LSPs to the capability of supporting priorities and supporting the= capability of changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, = I guess you’d like to inherit the priorities of the LSP you’re = re-optimizing.

 <= /span>

Re the = Admin status object VS the LSP_attributes I think the choice depends on the= relationship between the existing LSP and the inquiry LSP. If the inquiry = LSP is a new one I would suggest to use the Admin status (it is not so different from e.g. the exercise status), w= hile if the two LSP are linked, maybe the LSP_attributes is more appropriat= e.

 <= /span>

My 2 ce= nts

Daniele=

 <= /span>

PS. I h= ave the suspect that we turning RSVP-TE into a management protocol between = a client and a server networks…

 <= /span>

From:<= a href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: mercoled=EC 31 luglio 2013 13:24
To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

 <= /span>

The LSP= inquiry without resource locking (at a given priority then) mechanism is p= resent not reserve the resource for other LSPs (of same or higher priority)= or preempt lower priority.

 <= /span>

Could t= his be achieved by setting the LSP with a lower holding priority, signal is= as pre-planned AND indicate that this should not preempt other LSPs.

When th= is is instantiated a new LSP (or the same ) can be signaled with SE and exp= licit ERO with the changed flag.

 <= /span>

 <= /span>

Mit freundlichen Gr=FC=DF= en / Best Regards
Cyril Margaria

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Margaria- 

 

Resource reservation (in control plane) are always associated with = a given priority. The inquiry LSP should be signaled using the same setup a= nd hold priority as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect b= locking for the inquiry LSP (as resource may be available at the priority o= f the LSP but may not be available at the 7 (lowest) priority. =

 

Thanks

 

Regards … Zafar=

 

From: = <Margaria>, &qu= ot;Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

For the= resource reservation aspect, this seems related to priorities, LSP inquiry= without reservation could be defined as LSP with setup, holding priority 8= (or 255). This would in addition allow for reporting when the resource are gone (preempted)

 <= /span>

Mit freundlichen Gr=FC=DF= en / Best Regards
Cyril Margaria

From:<= a href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema: 

 

Please see in-line. 

 

Thanks

 

Regards … Zafar=

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Zafa= r,

 <= /span>

The poi= nt I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes= , are exactly same in terms of object re-use and both of them defines new b= its for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which= is not desirable.

 <= /span>

 

The inquire/ potential reopt LSP is li= kely not to follow path of the currently active LSP. Hence this cannot be i= mplemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks<= /span>

Khuzema=

 <= /span>

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema:

 

For signaling inquiry LSP with resource locking, we are using the Pre-Pl= anned LSP flag as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource l= ocking.  

 

Thanks

 

Regards … Zafar

 

From: Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. = not really.

 <= /span>

You are= defining new bits for LSP_ATTRIBUTES for resource locking… aren̵= 7;t you?

 <= /span>

Instead= of doing that, you can define bits in ADMIN_STATUS and save new LSP life c= ycle management, which would be quite cumbersome.

 <= /span>

Regards=

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema:

 

The point is to reuse what already exists. The Pre-Planned LSP= flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already define= d in [RFC5420] and is a glove fit. =

 

Thanks

 

Regards … Zafar=

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Another= point I spoke about in the meeting ..

 <= /span>

Why can= ’t we extend Admin Status object to signal resource locking, checking= for re-optimization. Since this operation is typically done in maintenance= window by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin= Status object.

 <= /span>

This wi= ll save network element to manage life of additional LSP and control plane = failure related issues attached to the additional LSP.

 <= /span>

Khuzema=

 <= /span>

--_000_38a4fec6461b469fb85a26ee49f16b7bBLUPR05MB040namprd05pro_-- From mhartley@cisco.com Wed Aug 7 09:06:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B062E21F9EB6 for ; Wed, 7 Aug 2013 09:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG8JRDYPHUlt for ; Wed, 7 Aug 2013 09:06:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id ECCB321F9E88 for ; Wed, 7 Aug 2013 09:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61731; q=dns/txt; s=iport; t=1375891576; x=1377101176; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TlaFiOu9yuS9xllQpZaqmhs//4PhdGUsCJnjBtTuD8U=; b=GQ4UmDmO/NyX7hhEUFme/tZerjco4RkhG1hZTuigqBMx549Esl+5Nk4o MS2IMA+8KDF03KcRbr7EEW6h1sykLFY1T7bgKrFr2IXy4Can883fHG9ps Wk3UUABe2gQHu98rKmIrjzU0zeDfpbn+u+zp4YWeQxBZAmhj28gks6SZM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAMBvAlKtJV2d/2dsb2JhbABbgkJENVC+RoEcFnSCJAEBAQQaE0UHEAIBCBEDAQEBCxYBBgcyFAkIAgQBDQUIEYd3uDaOVAqBCw0TEQYBAoMYdAOIc6A9gxeBaAkXIg X-IronPort-AV: E=Sophos;i="4.89,834,1367971200"; d="scan'208,217";a="241621873" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 07 Aug 2013 16:06:14 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r77G6EN6017092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 16:06:14 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 11:06:14 -0500 From: "Matt Hartley (mhartley)" To: "Zafar Ali (zali)" , Gert Grammel , Daniele Ceccarelli , Fatai Zhang , "Margaria, Cyril (Coriant - DE/Munich)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQAAiR5UAABYt+gACGkgXQADOIbAAAAED5UA== Date: Wed, 7 Aug 2013 16:06:13 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105A7491@xmb-rcd-x03.cisco.com> References: <3b003053a8884105a66387e1bb6b3521@BN1PR05MB041.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.251] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC105A7491xmbrcdx03ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 16:06:31 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC105A7491xmbrcdx03ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gert, Fatai, Further to Zafar's reply... You're correct that a UNI-C could, in principle, make repeated inquiries th= at will never result in a path being found. However, hopefully a network op= erator will not configure a set of constraints on a tunnel that have no cha= nce of being met by the core network and will thus result in indefinite inq= uiries... and if they do, that problem can be fixed by removing the unreaso= nable constraints. So, yes, this is a tool that could be mis-used or abused, with adverse cons= equences if that happens. But I don't think this is sufficient reason to sa= y that a useful tool should be denied to folks who will use it properly. Cheers Matt Hi Gert- Please see in-line. Thanks Regards ... Zafar From: Gert Grammel > Date: Tuesday, August 6, 2013 11:40 AM To: zali >, Daniele Ceccarelli >, "Marga= ria, Cyril (Coriant - DE/Munich)" >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zhafar, how would that policy enforced? By UNI-C node having a policy from operator on when it should run inquiry p= rocedure. Usually, during maintenance window. In the end every topology information has to be poked out of the server net= work and how frequent/updated this information is, is not visible to the cl= ient. No, as this is a UNI. When you say: If a connection cannot be restore using existing const= raints, UNI-C may change the constraints depending on what is acceptable to= the client layer. How is the client able to figure out which constraint is eventually able to= succeed? By trying a list of paths that releases constraints from toughest to easies= t. We are talking about a list with typically 2-4 entries. And if it doesn't what is the client about to do? Release the path constraints - until it finds a path or constraints cannot = be released any further. In other words, how does the client network able to understand that it is b= eating a dead horse (a server network that is full), and how does it unders= tand that it actually is no more? Obviously we are talking about trying a very limited list of path options (= 2-4, typically). -Gert From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: 04 August 2013 00:00 To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich)= ; Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Gert: Firstly, the inquiry (or poking) is much controlled by Policy. It is not th= at client network will probe server network blindly. Usually this operation= will only be done during maintenance window and/ or in a well controlled f= ashion. Secondly, routing is not only about the objective function (changes). As cl= ient layer understands and dedicates the requirement for the client connect= ion (SRLG and other routing constraints, metric bound, OF, etc.), client la= yer is in better position to dedicate what path would be acceptable should = an unprotected tunnel connection goes down. If a connection cannot be resto= re using existing constraints, UNI-C may change the constraints depending o= n what is acceptable to the client layer. Please also refer to Matt's email= on this. Thanks Regards ... Zafar From: Gert Grammel > Date: Saturday, August 3, 2013 4:28 PM To: Daniele Ceccarelli >, "Margaria, Cyril (Coriant - DE/Munich)" >, zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, I don't think it is a good design to let clients blindly poke into the serv= er domain. If an objective function is met, why is the client still poking = the server? Is it for a different objective function? Then what is the crit= eria to stop poking around? Gert From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 03 August 2013 18:28 To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithew= an; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you'd like to inherit t= he priorities of the LSP you're re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks... From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards ... Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_9D50FCE7413E3D4EA5E42331115FB5BC105A7491xmbrcdx03ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Gert, Fatai,

 

Further to Zafar̵= 7;s reply...

 

You’re correct = that a UNI-C could, in principle, make repeated inquiries that will never r= esult in a path being found. However, hopefully a network operator will not configure a set of constraints on a tunnel that have no chance of= being met by the core network and will thus result in indefinite inquiries= ... and if they do, that problem can be fixed by removing the unreasonable = constraints.

 

So, yes, this is a to= ol that could be mis-used or abused, with adverse consequences if that happ= ens. But I don’t think this is sufficient reason to say that a useful tool should be denied to folks who will use it properly.

 

Cheers

 

Matt

 

Hi Gert= - 

&n= bsp;

Please = see in-line. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= … Zafar

&n= bsp;

From: Gert Grammel <ggrammel@juniper.net>
Date: Tuesday, August 6, 2013 11:40 AM
To: zali <zali@cisco.com>= ;, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (Coriant -= DE/Munich)" <cyril.m= argaria@coriant.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Hi Zhafar,=

 

how would that policy = enforced?

 

By UNI-C node having a policy from operator on when i= t should run inquiry procedure. Usually, during maintenance window. 

 

In the end every topol= ogy information has to be poked out of the server network and how frequent/= updated this information is, is not visible to the client.

 

No, as this is a UNI. 

 

When you say: <snip= > If a connection ca= nnot be restore using existing constraints, UNI-C may change the = constraints depending on what is acceptable to the client layer. <snip>

How is the client able= to figure out which constraint is eventually able to succeed?

 

By trying a list of paths that releases constraints f= rom toughest to easiest. We are talking about a list with typically 2-4 ent= ries.  

 

And if it doesn’= t what is the client about to do?

 

 

Release the path constraints – until it finds a= path or constraints cannot be released any further. <= /span>

 

In other words, how do= es the client network able to understand that it is beating a dead horse (a= server network that is full), and how does it understand that it actually = is no more?

 

 

Obviously we are talking about trying a very limited = list of path options (2-4, typically). 

 

-Gert

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: 04 August 2013 00:00
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/= Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /o:p>

Hi Gert: 

 

Firstly, the inquiry (or poking) is much controlled by Policy. It is n= ot that client network will probe server network blindly. Usually this oper= ation will only be done during maintenance window and/ or in a well controlled fashion. 

 

Secondly, routing is not only about the objective function (changes). = As client layer understands and dedicates the requirement for the client co= nnection (SRLG and other routing constraints, metric bound, OF, etc.), client layer is in better position to dedicate wh= at path would be acceptable should an unprotected tunnel connection goes do= wn. If a connection cannot be restore using existing constraints, = ;UNI-C may change the constraints depending on what is acceptable to the client layer. Please also refer to Matt'= s email on this. <= /o:p>

 

Thanks

 

Regards … Zafar

 

From: Gert Grammel <ggrammel@juniper.net>
Date: Saturday, August 3, 2013 4:28 PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (C= oriant - DE/Munich)" <cyril.margaria@coriant.com>, zali <zali@cisco.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 

I don’t think it= is a good design to let clients blindly poke into the server domain. If an= objective function is met, why is the client still poking the server? Is i= t for a different objective function? Then what is the criteria to stop poking around?

 

Gert

 

 <= /o:p>

Hi Cyril,

 

Your idea is a bright = workaround but I would not bind the capability of setting up inquiry LSPs t= o the capability of supporting priorities and supporting the capability of = changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, I guess you̵= 7;d like to inherit the priorities of the LSP you’re re-optimizing.

 

Re the Admin status ob= ject VS the LSP_attributes I think the choice depends on the relationship b= etween the existing LSP and the inquiry LSP. If the inquiry LSP is a new on= e I would suggest to use the Admin status (it is not so different from e.g. the exercise status), while if the two L= SP are linked, maybe the LSP_attributes is more appropriate.

 

My 2 cents

Daniele

 

PS. I have the suspect= that we turning RSVP-TE into a management protocol between a client and a = server networks…<= /o:p>

 

 

Hi,

 

 

The LSP inquiry withou= t resource locking (at a given priority then) mechanism is present not rese= rve the resource for other LSPs (of same or higher priority) or preempt low= er priority.

 

Could this be achieved= by setting the LSP with a lower holding priority, signal is as pre-planned= AND indicate that this should not preempt other LSPs.

When this is instantia= ted a new LSP (or the same ) can be signaled with SE and explicit ERO with = the changed flag.=

 

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Marg= aria- 

 <= /span>

Resourc= e reservation (in control plane) are always associated with a given priorit= y. The inquiry LSP should be signaled using the same setup and hold priorit= y as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect blocking for th= e inquiry LSP (as resource may be available at the priority of the LSP but = may not be available at the 7 (lowest) priority. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: <Margaria>, "Cyril (Coriant - DE/Munich)= " <cyril.margaria@cor= iant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Hi,

 

For the resource reser= vation aspect, this seems related to priorities, LSP inquiry without reserv= ation could be defined as LSP with setup, holding priority 8 (or 255). This= would in addition allow for reporting when the resource are gone (preempted)

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

 

Hi Khuz= ema: =

 <= /span>

Please = see in-line. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Hi Zafar,

 

The point I am making = here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly s= ame in terms of object re-use and both of them defines new bits for enhance= d functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not d= esirable.<= /p>

 

 =

The inquire/ potential reopt LSP is likely not to fol= low path of the currently active LSP. Hence this cannot be implemented by j= ust adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 =

Thanks

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuz= ema:

 

For signalin= g inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&= nbsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &nb= sp;

 

Thanks

 

Regards R= 30; Zafar<= /p>

 =

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking… aren’t you?=

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:= zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema= :

 <= /span>

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Another point I spoke = about in the meeting ..=

 

Why can’t we ext= end Admin Status object to signal resource locking, checking for re-optimiz= ation. Since this operation is typically done in maintenance window by Admi= n, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.

 

Khuzema

 

--_000_9D50FCE7413E3D4EA5E42331115FB5BC105A7491xmbrcdx03ciscoc_-- From jdrake@juniper.net Wed Aug 7 09:21:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBCF11E80D3 for ; Wed, 7 Aug 2013 09:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUdGS-zmI+RP for ; Wed, 7 Aug 2013 09:21:18 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id DBAEA21F9D3A for ; Wed, 7 Aug 2013 09:21:15 -0700 (PDT) Received: from mail49-db8-R.bigfish.com (10.174.8.226) by DB8EHSOBE027.bigfish.com (10.174.4.90) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Aug 2013 16:21:13 +0000 Received: from mail49-db8 (localhost [127.0.0.1]) by mail49-db8-R.bigfish.com (Postfix) with ESMTP id 0D64A640208; Wed, 7 Aug 2013 16:21:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371Ic89bhc85dhec9I31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail49-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(37854004)(377454003)(4396001)(15202345003)(80976001)(19300405004)(50986001)(31966008)(74662001)(59766001)(76796001)(76786001)(53806001)(76576001)(47736001)(18717965001)(74706001)(16406001)(79102001)(47976001)(74502001)(49866001)(69226001)(74876001)(47446002)(83072001)(66066001)(81342001)(74316001)(16236675002)(63696002)(65816001)(76482001)(80022001)(81542001)(56776001)(77982001)(46102001)(33646001)(1941001)(74366001)(19580385001)(83322001)(19580405001)(56816003)(19580395003)(77096001)(54316002)(51856001)(54356001)(24736002)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB046; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.53; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail49-db8 (localhost.localdomain [127.0.0.1]) by mail49-db8 (MessageSwitch) id 1375892468817307_8554; Wed, 7 Aug 2013 16:21:08 +0000 (UTC) Received: from DB8EHSMHS014.bigfish.com (unknown [10.174.8.252]) by mail49-db8.bigfish.com (Postfix) with ESMTP id C1AE5D80049; Wed, 7 Aug 2013 16:21:08 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS014.bigfish.com (10.174.4.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 7 Aug 2013 16:21:08 +0000 Received: from BY2PR05MB046.namprd05.prod.outlook.com (10.242.34.144) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.341.1; Wed, 7 Aug 2013 16:21:05 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB046.namprd05.prod.outlook.com (10.242.34.144) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 7 Aug 2013 16:21:03 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Wed, 7 Aug 2013 16:21:03 +0000 From: John E Drake To: "Matt Hartley (mhartley)" , "Zafar Ali (zali)" , Gert Grammel , Daniele Ceccarelli , Fatai Zhang , "Margaria, Cyril (Coriant - DE/Munich)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQAAiR5UAABYt+gACGkgXQADOIbAAAAED5UAAAoRRQ Date: Wed, 7 Aug 2013 16:21:02 +0000 Message-ID: <00874a6587bf4082bee1fa44c900ebda@BY2PR05MB142.namprd05.prod.outlook.com> References: <3b003053a8884105a66387e1bb6b3521@BN1PR05MB041.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105A7491@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC105A7491@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] x-forefront-prvs: 0931CB1479 Content-Type: multipart/alternative; boundary="_000_00874a6587bf4082bee1fa44c900ebdaBY2PR05MB142namprd05pro_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$infinera.com%0%1%DuplicateDomain-c684c95e-93ad-459f-9d80-96fa46cd75af.juniper.net%False%False%0$ X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%CORIANT.COM$RO%1$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INFINERA.COM$RO%1$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 16:21:26 -0000 --_000_00874a6587bf4082bee1fa44c900ebdaBY2PR05MB142namprd05pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matt, I think a much crisper problem statement is in order, as is a gap analysis = of existing solutions. I have the impression that this draft is a solution= in search of a problem. Also, lest we forget, the UNI clients are not under the direct control of t= he service provider. This mechanism allows any number of misconfigured or = malicious clients to completely wedge the service provider's network. Yours Irrespectively, John From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of M= att Hartley (mhartley) Sent: Wednesday, August 07, 2013 9:06 AM To: Zafar Ali (zali); Gert Grammel; Daniele Ceccarelli; Fatai Zhang; Margar= ia, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Gert, Fatai, Further to Zafar's reply... You're correct that a UNI-C could, in principle, make repeated inquiries th= at will never result in a path being found. However, hopefully a network op= erator will not configure a set of constraints on a tunnel that have no cha= nce of being met by the core network and will thus result in indefinite inq= uiries... and if they do, that problem can be fixed by removing the unreaso= nable constraints. So, yes, this is a tool that could be mis-used or abused, with adverse cons= equences if that happens. But I don't think this is sufficient reason to sa= y that a useful tool should be denied to folks who will use it properly. Cheers Matt Hi Gert- Please see in-line. Thanks Regards ... Zafar From: Gert Grammel > Date: Tuesday, August 6, 2013 11:40 AM To: zali >, Daniele Ceccarelli >, "Marga= ria, Cyril (Coriant - DE/Munich)" >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zhafar, how would that policy enforced? By UNI-C node having a policy from operator on when it should run inquiry p= rocedure. Usually, during maintenance window. In the end every topology information has to be poked out of the server net= work and how frequent/updated this information is, is not visible to the cl= ient. No, as this is a UNI. When you say: If a connection cannot be restore using existing const= raints, UNI-C may change the constraints depending on what is acceptable to= the client layer. How is the client able to figure out which constraint is eventually able to= succeed? By trying a list of paths that releases constraints from toughest to easies= t. We are talking about a list with typically 2-4 entries. And if it doesn't what is the client about to do? Release the path constraints - until it finds a path or constraints cannot = be released any further. In other words, how does the client network able to understand that it is b= eating a dead horse (a server network that is full), and how does it unders= tand that it actually is no more? Obviously we are talking about trying a very limited list of path options (= 2-4, typically). -Gert From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: 04 August 2013 00:00 To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich)= ; Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Gert: Firstly, the inquiry (or poking) is much controlled by Policy. It is not th= at client network will probe server network blindly. Usually this operation= will only be done during maintenance window and/ or in a well controlled f= ashion. Secondly, routing is not only about the objective function (changes). As cl= ient layer understands and dedicates the requirement for the client connect= ion (SRLG and other routing constraints, metric bound, OF, etc.), client la= yer is in better position to dedicate what path would be acceptable should = an unprotected tunnel connection goes down. If a connection cannot be resto= re using existing constraints, UNI-C may change the constraints depending o= n what is acceptable to the client layer. Please also refer to Matt's email= on this. Thanks Regards ... Zafar From: Gert Grammel > Date: Saturday, August 3, 2013 4:28 PM To: Daniele Ceccarelli >, "Margaria, Cyril (Coriant - DE/Munich)" >, zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, I don't think it is a good design to let clients blindly poke into the serv= er domain. If an objective function is met, why is the client still poking = the server? Is it for a different objective function? Then what is the crit= eria to stop poking around? Gert From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 03 August 2013 18:28 To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithew= an; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you'd like to inherit t= he priorities of the LSP you're re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks... From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards ... Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_00874a6587bf4082bee1fa44c900ebdaBY2PR05MB142namprd05pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Matt,

 

I think a much crisper= problem statement is in order, as is a gap analysis of existing solutions.=   I have the impression that this draft is a solution in search of a p= roblem.

 

Also, lest we forget, = the UNI clients are not under the direct control of the service provider.&n= bsp; This mechanism allows any number of misconfigured or malicious clients= to completely wedge the service provider’s network. 

 

Yours Irrespectively,

 

John

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Matt Hartley (mhartley)
Sent: Wednesday, August 07, 2013 9:06 AM
To: Zafar Ali (zali); Gert Grammel; Daniele Ceccarelli; Fatai Zhang;= Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@ietf= .org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Gert, Fatai,

 

Further to Zafar̵= 7;s reply...

 

You’re correct = that a UNI-C could, in principle, make repeated inquiries that will never r= esult in a path being found. However, hopefully a network operator will not configure a set of constraints on a tunnel that have no chance of= being met by the core network and will thus result in indefinite inquiries= ... and if they do, that problem can be fixed by removing the unreasonable = constraints.

 

So, yes, this is a to= ol that could be mis-used or abused, with adverse consequences if that happ= ens. But I don’t think this is sufficient reason to say that a useful tool should be denied to folks who will use it properly.

 

Cheers

 

Matt

 

Hi Gert= - 

&n= bsp;

Please = see in-line. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= … Zafar

&n= bsp;

From: Gert Grammel <ggrammel@juniper.net>
Date: Tuesday, August 6, 2013 11:40 AM
To: zali <zali@cisco.com>= ;, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (Coriant -= DE/Munich)" <cyril.m= argaria@coriant.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Hi Zhafar,=

 

how would that policy = enforced?

 

By UNI-C node having a policy from operator on when i= t should run inquiry procedure. Usually, during maintenance window. 

 

In the end every topol= ogy information has to be poked out of the server network and how frequent/= updated this information is, is not visible to the client.

 

No, as this is a UNI. 

 

When you say: <snip= > If a connection ca= nnot be restore using existing constraints, UNI-C may change the = constraints depending on what is acceptable to the client layer. <snip>

How is the client able= to figure out which constraint is eventually able to succeed?

 

By trying a list of paths that releases constraints f= rom toughest to easiest. We are talking about a list with typically 2-4 ent= ries.  

 

And if it doesn’= t what is the client about to do?

 

 

Release the path constraints – until it finds a= path or constraints cannot be released any further. <= /span>

 

In other words, how do= es the client network able to understand that it is beating a dead horse (a= server network that is full), and how does it understand that it actually = is no more?

 

 

Obviously we are talking about trying a very limited = list of path options (2-4, typically). 

 

-Gert

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: 04 August 2013 00:00
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/= Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /o:p>

Hi Gert: 

 

Firstly, the inquiry (or poking) is much controlled by Policy. It is n= ot that client network will probe server network blindly. Usually this oper= ation will only be done during maintenance window and/ or in a well controlled fashion. 

 

Secondly, routing is not only about the objective function (changes). = As client layer understands and dedicates the requirement for the client co= nnection (SRLG and other routing constraints, metric bound, OF, etc.), client layer is in better position to dedicate wh= at path would be acceptable should an unprotected tunnel connection goes do= wn. If a connection cannot be restore using existing constraints, = ;UNI-C may change the constraints depending on what is acceptable to the client layer. Please also refer to Matt'= s email on this. <= /o:p>

 

Thanks

 

Regards … Zafar

 

From: Gert Grammel <ggrammel@juniper.net>
Date: Saturday, August 3, 2013 4:28 PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (C= oriant - DE/Munich)" <cyril.margaria@coriant.com>, zali <zali@cisco.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 

I don’t think it= is a good design to let clients blindly poke into the server domain. If an= objective function is met, why is the client still poking the server? Is i= t for a different objective function? Then what is the criteria to stop poking around?

 

Gert

 

 <= /o:p>

Hi Cyril,

 

Your idea is a bright = workaround but I would not bind the capability of setting up inquiry LSPs t= o the capability of supporting priorities and supporting the capability of = changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, I guess you̵= 7;d like to inherit the priorities of the LSP you’re re-optimizing.

 

Re the Admin status ob= ject VS the LSP_attributes I think the choice depends on the relationship b= etween the existing LSP and the inquiry LSP. If the inquiry LSP is a new on= e I would suggest to use the Admin status (it is not so different from e.g. the exercise status), while if the two L= SP are linked, maybe the LSP_attributes is more appropriate.

 

My 2 cents

Daniele

 

PS. I have the suspect= that we turning RSVP-TE into a management protocol between a client and a = server networks…<= /o:p>

 

 

Hi,

 

 

The LSP inquiry withou= t resource locking (at a given priority then) mechanism is present not rese= rve the resource for other LSPs (of same or higher priority) or preempt low= er priority.

 

Could this be achieved= by setting the LSP with a lower holding priority, signal is as pre-planned= AND indicate that this should not preempt other LSPs.

When this is instantia= ted a new LSP (or the same ) can be signaled with SE and explicit ERO with = the changed flag.=

 

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Marg= aria- 

 <= /span>

Resourc= e reservation (in control plane) are always associated with a given priorit= y. The inquiry LSP should be signaled using the same setup and hold priorit= y as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect blocking for th= e inquiry LSP (as resource may be available at the priority of the LSP but = may not be available at the 7 (lowest) priority. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: <Margaria>, "Cyril (Coriant - DE/Munich)= " <cyril.margaria@cor= iant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Hi,

 

For the resource reser= vation aspect, this seems related to priorities, LSP inquiry without reserv= ation could be defined as LSP with setup, holding priority 8 (or 255). This= would in addition allow for reporting when the resource are gone (preempted)

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

 

Hi Khuz= ema: =

 <= /span>

Please = see in-line. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Hi Zafar,

 

The point I am making = here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly s= ame in terms of object re-use and both of them defines new bits for enhance= d functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not d= esirable.<= /p>

 

 =

The inquire/ potential reopt LSP is likely not to fol= low path of the currently active LSP. Hence this cannot be implemented by j= ust adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 =

Thanks

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuz= ema:

 

For signalin= g inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&= nbsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &nb= sp;

 

Thanks

 

Regards R= 30; Zafar<= /p>

 =

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking… aren’t you?=

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:= zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema= :

 <= /span>

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Another point I spoke = about in the meeting ..=

 

Why can’t we ext= end Admin Status object to signal resource locking, checking for re-optimiz= ation. Since this operation is typically done in maintenance window by Admi= n, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.

 

Khuzema

 

--_000_00874a6587bf4082bee1fa44c900ebdaBY2PR05MB142namprd05pro_-- From ggrammel@juniper.net Wed Aug 7 09:26:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1468D11E80E2 for ; Wed, 7 Aug 2013 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaQYlXc+jNq9 for ; Wed, 7 Aug 2013 09:26:20 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id B2D8221F9C59 for ; Wed, 7 Aug 2013 09:26:19 -0700 (PDT) Received: from mail194-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Aug 2013 16:26:18 +0000 Received: from mail194-ch1 (localhost [127.0.0.1]) by mail194-ch1-R.bigfish.com (Postfix) with ESMTP id 9B9951201C0; Wed, 7 Aug 2013 16:26:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371Ic89bhc85dhec9I31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah18c673h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail194-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=ggrammel@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(37854004)(377454003)(47446002)(16406001)(80976001)(76786001)(51856001)(77096001)(76482001)(33646001)(66066001)(74316001)(80022001)(81542001)(76576001)(74706001)(74502001)(49866001)(53806001)(69226001)(74876001)(47976001)(50986001)(81342001)(56816003)(76796001)(4396001)(63696002)(47736001)(46102001)(31966008)(74662001)(54356001)(79102001)(19300405004)(19580385001)(83322001)(16236675002)(74366001)(19580405001)(19580395003)(77982001)(65816001)(15202345003)(83072001)(54316002)(59766001)(56776001)(24736002)(559001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB044; H:BN1PR05MB041.namprd05.prod.outlook.com; CLIP:193.110.54.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail194-ch1 (localhost.localdomain [127.0.0.1]) by mail194-ch1 (MessageSwitch) id 137589277582327_10341; Wed, 7 Aug 2013 16:26:15 +0000 (UTC) Received: from CH1EHSMHS041.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail194-ch1.bigfish.com (Postfix) with ESMTP id 0E64F14005A; Wed, 7 Aug 2013 16:26:15 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 7 Aug 2013 16:26:14 +0000 Received: from BN1PR05MB044.namprd05.prod.outlook.com (10.255.202.154) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Wed, 7 Aug 2013 16:26:14 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB044.namprd05.prod.outlook.com (10.255.202.154) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 7 Aug 2013 16:25:39 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.216]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.216]) with mapi id 15.00.0731.000; Wed, 7 Aug 2013 16:25:38 +0000 From: Gert Grammel To: "Matt Hartley (mhartley)" , "Zafar Ali (zali)" , Daniele Ceccarelli , Fatai Zhang , "Margaria, Cyril (Coriant - DE/Munich)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQAAiR5UAABYt+gACGkgXQADOIbAAAAED5UAAAlrXA Date: Wed, 7 Aug 2013 16:25:37 +0000 Message-ID: References: <3b003053a8884105a66387e1bb6b3521@BN1PR05MB041.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105A7491@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC105A7491@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.54.36] x-forefront-prvs: 0931CB1479 Content-Type: multipart/alternative; boundary="_000_c9aa1e49083d43e89af791bbb0dc1954BN1PR05MB041namprd05pro_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$infinera.com%0%1%DuplicateDomain-c684c95e-93ad-459f-9d80-96fa46cd75af.juniper.net%False%False%0$ X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%CORIANT.COM$RO%1$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INFINERA.COM$RO%1$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 16:26:27 -0000 --_000_c9aa1e49083d43e89af791bbb0dc1954BN1PR05MB041namprd05pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matt, there are several points here: 1. Which information is actually required to exchange in order to sup= port a certain use case? 2. What is the architecturally best way to enable this exchange? 3. Is there prior work that can be built upon? For 1) an applicability statement would help to document the use case. Then= 2) needs to be discussed and in parallel one could already start to look a= t 3) to understand how our ancestors approached similar problems and how th= ey solved them. If you have a large server network, poking with RSVP to let= client devices understand the network state isn't really what RSVP is abou= t. -Gert From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] Sent: 07 August 2013 18:06 To: Zafar Ali (zali); Gert Grammel; Daniele Ceccarelli; Fatai Zhang; Margar= ia, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Cc: Matt Hartley (mhartley) Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Gert, Fatai, Further to Zafar's reply... You're correct that a UNI-C could, in principle, make repeated inquiries th= at will never result in a path being found. However, hopefully a network op= erator will not configure a set of constraints on a tunnel that have no cha= nce of being met by the core network and will thus result in indefinite inq= uiries... and if they do, that problem can be fixed by removing the unreaso= nable constraints. So, yes, this is a tool that could be mis-used or abused, with adverse cons= equences if that happens. But I don't think this is sufficient reason to sa= y that a useful tool should be denied to folks who will use it properly. Cheers Matt Hi Gert- Please see in-line. Thanks Regards ... Zafar From: Gert Grammel > Date: Tuesday, August 6, 2013 11:40 AM To: zali >, Daniele Ceccarelli >, "Marga= ria, Cyril (Coriant - DE/Munich)" >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zhafar, how would that policy enforced? By UNI-C node having a policy from operator on when it should run inquiry p= rocedure. Usually, during maintenance window. In the end every topology information has to be poked out of the server net= work and how frequent/updated this information is, is not visible to the cl= ient. No, as this is a UNI. When you say: If a connection cannot be restore using existing const= raints, UNI-C may change the constraints depending on what is acceptable to= the client layer. How is the client able to figure out which constraint is eventually able to= succeed? By trying a list of paths that releases constraints from toughest to easies= t. We are talking about a list with typically 2-4 entries. And if it doesn't what is the client about to do? Release the path constraints - until it finds a path or constraints cannot = be released any further. In other words, how does the client network able to understand that it is b= eating a dead horse (a server network that is full), and how does it unders= tand that it actually is no more? Obviously we are talking about trying a very limited list of path options (= 2-4, typically). -Gert From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: 04 August 2013 00:00 To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich)= ; Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Gert: Firstly, the inquiry (or poking) is much controlled by Policy. It is not th= at client network will probe server network blindly. Usually this operation= will only be done during maintenance window and/ or in a well controlled f= ashion. Secondly, routing is not only about the objective function (changes). As cl= ient layer understands and dedicates the requirement for the client connect= ion (SRLG and other routing constraints, metric bound, OF, etc.), client la= yer is in better position to dedicate what path would be acceptable should = an unprotected tunnel connection goes down. If a connection cannot be resto= re using existing constraints, UNI-C may change the constraints depending o= n what is acceptable to the client layer. Please also refer to Matt's email= on this. Thanks Regards ... Zafar From: Gert Grammel > Date: Saturday, August 3, 2013 4:28 PM To: Daniele Ceccarelli >, "Margaria, Cyril (Coriant - DE/Munich)" >, zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, I don't think it is a good design to let clients blindly poke into the serv= er domain. If an objective function is met, why is the client still poking = the server? Is it for a different objective function? Then what is the crit= eria to stop poking around? Gert From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 03 August 2013 18:28 To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithew= an; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you'd like to inherit t= he priorities of the LSP you're re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks... From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards ... Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_c9aa1e49083d43e89af791bbb0dc1954BN1PR05MB041namprd05pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Matt,

&n= bsp;

there a= re several points here:

1.       Which information is actually required to exchange in order to support a c= ertain use case?

2.       What is the architecturally best way to enable this exchange?

3.       Is there prior work that can be built upon?

&n= bsp;

For 1) = an applicability statement would help to document the use case. Then 2) nee= ds to be discussed and in parallel one could already start to look at 3) to= understand how our ancestors approached similar problems and how they solved them. If you have a large server netw= ork, poking with RSVP to let client devices understand the network state is= n’t really what RSVP is about.

&n= bsp;

-Gert

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Matt Hartley (mhartley) = [mailto:mhartley@cisco.com]
Sent: 07 August 2013 18:06
To: Zafar Ali (zali); Gert Grammel; Daniele Ceccarelli; Fatai Zhang;= Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@ietf= .org)
Cc: Matt Hartley (mhartley)
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Gert, = Fatai,

&= nbsp;

Furthe= r to Zafar’s reply...

&= nbsp;

You= 217;re correct that a UNI-C could, in principle, make repeated inquiries th= at will never result in a path being found. However, hopefully a network operator will not configure a set of constraints on a tunnel that = have no chance of being met by the core network and will thus result in ind= efinite inquiries... and if they do, that problem can be fixed by removing = the unreasonable constraints.

&= nbsp;

So, ye= s, this is a tool that could be mis-used or abused, with adverse consequenc= es if that happens. But I don’t think this is sufficient reason to say that a useful tool should be denied to folks who will use it proper= ly.

&= nbsp;

Cheers=

&= nbsp;

Matt

&= nbsp;

Hi Gert- 

 

Please see in-line. 

 

Thanks

 

Regards … Zafar

 

From: = Gert Grammel <ggrammel@juniper.net>
Date: Tuesday, August 6, 2013 11:40 AM
To: zali <zali@cisco.com>= ;, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (Coriant -= DE/Munich)" <cyril.m= argaria@coriant.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Zhafar,

 

how wou= ld that policy enforced?

 

By UNI-C node having a policy from ope= rator on when it should run inquiry procedure. Usually, during maintenance = window. 

 

In the = end every topology information has to be poked out of the server network an= d how frequent/updated this information is, is not visible to the client.

 

No, as this is a UNI. =

 

When yo= u say: <snip> If a con= nection cannot be restore using existing constraints, UNI-C may c= hange the constraints depending on what is acceptable to the client layer.<= /span> <snip>

How is = the client able to figure out which constraint is eventually able to succee= d?

 

By trying a list of paths that release= s constraints from toughest to easiest. We are talking about a list with ty= pically 2-4 entries.  

 

And if = it doesn’t what is the client about to do?

 <= /span>

 

Release the path constraints – u= ntil it finds a path or constraints cannot be released any further.&nb= sp;

 

In othe= r words, how does the client network able to understand that it is beating = a dead horse (a server network that is full), and how does it understand th= at it actually is no more?

 <= /span>

 

Obviously we are talking about trying = a very limited list of path options (2-4, typically). 

 

-Gert

 <= /span>

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: 04 August 2013 00:00
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/= Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Gert= : 

 <= /span>

Firstly= , the inquiry (or poking) is much controlled by Policy. It is not that clie= nt network will probe server network blindly. Usually this operation will o= nly be done during maintenance window and/ or in a well controlled fashion. 

 <= /span>

Secondl= y, routing is not only about the objective function (changes). As client la= yer understands and dedicates the requirement for the client connection (SR= LG and other routing constraints, metric bound, OF, etc.), client layer is in better position to dedicate what path= would be acceptable should an unprotected tunnel connection goes down. If = a connection cannot be restore using existing constraints, UNI-C = may change the constraints depending on what is acceptable to the client layer. Please also refer to Matt's email = on this. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Gert Grammel <ggrammel@juniper.net>
Date: Saturday, August 3, 2013 4:28 PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (C= oriant - DE/Munich)" <cyril.margaria@coriant.com>, zali <zali@cisco.com>, Khuzema Pithewan <kpithewan@i= nfinera.com>, "ccamp@ietf.org= " <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Hi,

 <= /span>

I don&#= 8217;t think it is a good design to let clients blindly poke into the serve= r domain. If an objective function is met, why is the client still poking t= he server? Is it for a different objective function? Then what is the criteria to stop poking around?

 <= /span>

Gert

 <= /span>

From:<= a href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: 03 August 2013 18:28
To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema= Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Cyri= l,

 <= /span>

Your id= ea is a bright workaround but I would not bind the capability of setting up= inquiry LSPs to the capability of supporting priorities and supporting the= capability of changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, = I guess you’d like to inherit the priorities of the LSP you’re = re-optimizing.

 <= /span>

Re the = Admin status object VS the LSP_attributes I think the choice depends on the= relationship between the existing LSP and the inquiry LSP. If the inquiry = LSP is a new one I would suggest to use the Admin status (it is not so different from e.g. the exercise status), w= hile if the two LSP are linked, maybe the LSP_attributes is more appropriat= e.

 <= /span>

My 2 ce= nts

Daniele=

 <= /span>

PS. I h= ave the suspect that we turning RSVP-TE into a management protocol between = a client and a server networks…

 <= /span>

From:<= a href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: mercoled=EC 31 luglio 2013 13:24
To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

 <= /span>

The LSP= inquiry without resource locking (at a given priority then) mechanism is p= resent not reserve the resource for other LSPs (of same or higher priority)= or preempt lower priority.

 <= /span>

Could t= his be achieved by setting the LSP with a lower holding priority, signal is= as pre-planned AND indicate that this should not preempt other LSPs.

When th= is is instantiated a new LSP (or the same ) can be signaled with SE and exp= licit ERO with the changed flag.

 <= /span>

 <= /span>

Mit freundlichen Gr=FC=DF= en / Best Regards
Cyril Margaria

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Margaria- 

 

Resource reservation (in control plane) are always associated with = a given priority. The inquiry LSP should be signaled using the same setup a= nd hold priority as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect b= locking for the inquiry LSP (as resource may be available at the priority o= f the LSP but may not be available at the 7 (lowest) priority. =

 

Thanks

 

Regards … Zafar=

 

From: = <Margaria>, &qu= ot;Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi,

 <= /span>

For the= resource reservation aspect, this seems related to priorities, LSP inquiry= without reservation could be defined as LSP with setup, holding priority 8= (or 255). This would in addition allow for reporting when the resource are gone (preempted)

 <= /span>

Mit freundlichen Gr=FC=DF= en / Best Regards
Cyril Margaria

From:<= a href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema: 

 

Please see in-line. 

 

Thanks

 

Regards … Zafar=

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Zafa= r,

 <= /span>

The poi= nt I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes= , are exactly same in terms of object re-use and both of them defines new b= its for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which= is not desirable.

 <= /span>

 

The inquire/ potential reopt LSP is li= kely not to follow path of the currently active LSP. Hence this cannot be i= mplemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks<= /span>

Khuzema=

 <= /span>

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema:

 

For signaling inquiry LSP with resource locking, we are using the Pre-Pl= anned LSP flag as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource l= ocking.  

 

Thanks

 

Regards … Zafar

 

From: Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. = not really.

 <= /span>

You are= defining new bits for LSP_ATTRIBUTES for resource locking… aren̵= 7;t you?

 <= /span>

Instead= of doing that, you can define bits in ADMIN_STATUS and save new LSP life c= ycle management, which would be quite cumbersome.

 <= /span>

Regards=

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema:

 

The point is to reuse what already exists. The Pre-Planned LSP= flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already define= d in [RFC5420] and is a glove fit. =

 

Thanks

 

Regards … Zafar=

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Another= point I spoke about in the meeting ..

 <= /span>

Why can= ’t we extend Admin Status object to signal resource locking, checking= for re-optimization. Since this operation is typically done in maintenance= window by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin= Status object.

 <= /span>

This wi= ll save network element to manage life of additional LSP and control plane = failure related issues attached to the additional LSP.

 <= /span>

Khuzema=

 <= /span>

--_000_c9aa1e49083d43e89af791bbb0dc1954BN1PR05MB041namprd05pro_-- From jdrake@juniper.net Thu Aug 8 10:48:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA0F1F0D38 for ; Thu, 8 Aug 2013 10:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=2.316, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZeGgEXWOvCh for ; Thu, 8 Aug 2013 10:48:51 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 48B2D11E81DB for ; Thu, 8 Aug 2013 10:48:51 -0700 (PDT) Received: from mail72-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE025.bigfish.com (10.3.207.147) with Microsoft SMTP Server id 14.1.225.22; Thu, 8 Aug 2013 17:48:50 +0000 Received: from mail72-am1 (localhost [127.0.0.1]) by mail72-am1-R.bigfish.com (Postfix) with ESMTP id E1DD12C0122 for ; Thu, 8 Aug 2013 17:48:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: PS1(zzec9Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail72-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(37854004)(199002)(189002)(63696002)(59766001)(77982001)(46102001)(66066001)(65816001)(80022001)(79102001)(47736001)(76786001)(4396001)(76576001)(31966008)(81342001)(49866001)(74706001)(69226001)(83322001)(77096001)(81686001)(47976001)(80976001)(81542001)(50986001)(56816003)(76176001)(76796001)(74316001)(54316002)(33646001)(56776001)(54356001)(74662001)(76482001)(74876001)(74366001)(51856001)(16406001)(47446002)(53806001)(74502001)(83072001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.50; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail72-am1 (localhost.localdomain [127.0.0.1]) by mail72-am1 (MessageSwitch) id 1375984128826515_2475; Thu, 8 Aug 2013 17:48:48 +0000 (UTC) Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.246]) by mail72-am1.bigfish.com (Postfix) with ESMTP id C4C362E013E for ; Thu, 8 Aug 2013 17:48:48 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 8 Aug 2013 17:48:48 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.341.1; Thu, 8 Aug 2013 17:48:46 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.731.16; Thu, 8 Aug 2013 17:48:44 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Thu, 8 Aug 2013 17:48:44 +0000 From: John E Drake To: "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7w== Date: Thu, 8 Aug 2013 17:48:43 +0000 Message-ID: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.50] x-forefront-prvs: 093290AD39 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:48:58 -0000 Hi, I have a real concern with this draft because it appears to be heading us d= own the road of re-inventing PCEP in RSVP signaling with the dubious justif= ication that it is needed in those situations in which a PCE is not availab= le. However, if you re-invent PCEP in RSVP signaling, then you have effect= ively ensured that there are no situations in which a PCE or its signaling = equivalent are not available. Why is this better than simply ensuring that a PCE is available in those si= tuations in which it is needed? Yours Irrespectively, John From jdrake@juniper.net Thu Aug 8 14:15:18 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B87411E823B for ; Thu, 8 Aug 2013 14:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=1.544, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDh7MQSvl-60 for ; Thu, 8 Aug 2013 14:15:12 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1A95C11E822E for ; Thu, 8 Aug 2013 14:15:11 -0700 (PDT) Received: from mail106-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.22; Thu, 8 Aug 2013 21:15:10 +0000 Received: from mail106-ch1 (localhost [127.0.0.1]) by mail106-ch1-R.bigfish.com (Postfix) with ESMTP id DB00B401D2 for ; Thu, 8 Aug 2013 21:15:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: PS2(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail106-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(63696002)(56816003)(66066001)(77982001)(46102001)(65816001)(79102001)(80022001)(4396001)(76576001)(76786001)(47736001)(51856001)(81342001)(31966008)(59766001)(49866001)(74706001)(83322001)(77096001)(81686001)(47976001)(69226001)(81542001)(50986001)(76176001)(74316001)(76796001)(80976001)(54316002)(54356001)(33646001)(56776001)(74662001)(76482001)(74876001)(74366001)(16406001)(47446002)(53806001)(74502001)(83072001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail106-ch1 (localhost.localdomain [127.0.0.1]) by mail106-ch1 (MessageSwitch) id 13759965094459_5758; Thu, 8 Aug 2013 21:15:09 +0000 (UTC) Received: from CH1EHSMHS035.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail106-ch1.bigfish.com (Postfix) with ESMTP id F0170200075 for ; Thu, 8 Aug 2013 21:15:08 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS035.bigfish.com (10.43.70.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 8 Aug 2013 21:15:08 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Thu, 8 Aug 2013 21:15:08 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.731.16; Thu, 8 Aug 2013 21:15:05 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Thu, 8 Aug 2013 21:15:05 +0000 From: John E Drake To: "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nw== Date: Thu, 8 Aug 2013 21:15:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 093290AD39 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:15:18 -0000 Hi, I think there is a basic issue with this draft, which is that the server ne= twork manages its own TE metrics and those metrics almost certainly have no= thing in common with the TE metrics used in a given client network. Given this, would it not be better to have policy in the client nodes that = maps the characteristics of a given LSP established across the server netwo= rk into the TE metric to be advertised with that LSP in the client network? Yours Irrespectively, John From IBryskin@advaoptical.com Thu Aug 8 14:36:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEED21F9A78 for ; Thu, 8 Aug 2013 14:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdA+FOqfo8-N for ; Thu, 8 Aug 2013 14:36:24 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6E49821F9D3B for ; Thu, 8 Aug 2013 14:36:18 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id r78La8jv004707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Aug 2013 17:36:08 -0400 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0146.000; Thu, 8 Aug 2013 17:36:08 -0400 From: Igor Bryskin To: John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwABwvPQ Date: Thu, 8 Aug 2013 21:36:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-08_06:2013-08-08, 2013-08-08, 1970-01-01 signatures=0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:36:28 -0000 John, I agree completely with you. Cheers, Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Thursday, August 08, 2013 5:15 PM To: CCAMP (ccamp@ietf.org) Subject: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Hi, I think there is a basic issue with this draft, which is that the server ne= twork manages its own TE metrics and those metrics almost certainly have no= thing in common with the TE metrics used in a given client network. Given this, would it not be better to have policy in the client nodes that = maps the characteristics of a given LSP established across the server netwo= rk into the TE metric to be advertised with that LSP in the client network? Yours Irrespectively, John _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From zhangfatai@huawei.com Thu Aug 8 19:05:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17CB11E8213 for ; Thu, 8 Aug 2013 19:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[AWL=2.888, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgZUxNl0MqTC for ; Thu, 8 Aug 2013 19:04:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 02A2311E8194 for ; Thu, 8 Aug 2013 19:04:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVW09552; Fri, 09 Aug 2013 02:04:52 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 9 Aug 2013 03:04:38 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 9 Aug 2013 03:04:51 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.007; Fri, 9 Aug 2013 10:04:23 +0800 From: Fatai Zhang To: John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhA Date: Fri, 9 Aug 2013 02:04:23 +0000 Message-ID: References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 02:05:08 -0000 Hi John, Completely agree.=20 I also raised this comment in front of the mic during Berlin meeting.=20 Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Friday, August 09, 2013 1:49 AM To: CCAMP (ccamp@ietf.org) Subject: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Hi, I have a real concern with this draft because it appears to be heading us d= own the road of re-inventing PCEP in RSVP signaling with the dubious justif= ication that it is needed in those situations in which a PCE is not availab= le. However, if you re-invent PCEP in RSVP signaling, then you have effect= ively ensured that there are no situations in which a PCE or its signaling = equivalent are not available. Why is this better than simply ensuring that a PCE is available in those si= tuations in which it is needed? Yours Irrespectively, John _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Anders.Gavler@acreo.se Fri Aug 9 08:12:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92911E81AD for ; Fri, 9 Aug 2013 08:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3658Z4jBLvp9 for ; Fri, 9 Aug 2013 08:12:43 -0700 (PDT) Received: from smtp11-outgoing.stejtech.net (smtp11.stejtech.net [IPv6:2001:16d8:c001:2073::aa11]) by ietfa.amsl.com (Postfix) with ESMTP id D00C121E8134 for ; Fri, 9 Aug 2013 08:05:24 -0700 (PDT) X-Spam-STAY-ID: _CMAETAG_ Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp11.stejtech.net (Postfix) with ESMTPSA id 1EEC8135CA5; Fri, 9 Aug 2013 17:05:19 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 17:05:19 +0200 From: Anders Gavler To: Lou Berger , "diego.caviglia@ericsson.com" , =?iso-8859-1?Q?Jonas_M=E5rtensson?= , "i-nishioka@cb.jp.nec.com" , "lyong@ciena.com" , "cyril.margaria@nsn.com" , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-info Thread-Index: AQHOg+m07XU7VdmuvkitRmCaEbJDPpmNG8zQ Date: Fri, 9 Aug 2013 15:05:18 +0000 Message-ID: References: <51E83C26.2090302@labn.net> In-Reply-To: <51E83C26.2090302@labn.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.249.218.183] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-info X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:12:47 -0000 No, I'm not aware of any IPR that applies to this draft. /Anders -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: den 18 juli 2013 21:04 To: diego.caviglia@ericsson.com; Anders Gavler; Jonas M=E5rtensson; i-nishi= oka@cb.jp.nec.com; lyong@ciena.com; cyril.margaria@nsn.com; gregb@grotto-ne= tworking.com; leeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt= .co.jp Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-rwa-info Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From Anders.Gavler@acreo.se Fri Aug 9 08:13:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7655B21F9FD7 for ; Fri, 9 Aug 2013 08:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=2.776, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWBFSzyiQpE5 for ; Fri, 9 Aug 2013 08:13:30 -0700 (PDT) Received: from smtp7-outgoing.stejtech.net (smtp7.stejtech.net [83.140.31.163]) by ietfa.amsl.com (Postfix) with ESMTP id D7CC521F9F74 for ; Fri, 9 Aug 2013 08:06:12 -0700 (PDT) X-Spam-STAY-ID: _CMAETAG_ Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp7.stejtech.net (Postfix) with ESMTPSA id C12AB7520F6; Fri, 9 Aug 2013 17:06:10 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 17:06:10 +0200 From: Anders Gavler To: Lou Berger , "diego.caviglia@ericsson.com" , =?iso-8859-1?Q?Jonas_M=E5rtensson?= , "i-nishioka@cb.jp.nec.com" , "pierre.peloso@alcatel-lucent.com" , "cyril.margaria@nsn.com" , "giomarti@cisco.com" , "ggalimbe@cisco.com" , "lyong@ciena.com" , "daniele.ceccarelli@ericsson.com" , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHOg+qfirywB3gG3UyDVCuY32UPsJmNHA/w Date: Fri, 9 Aug 2013 15:06:09 +0000 Message-ID: References: <51E83C4F.8090502@labn.net> In-Reply-To: <51E83C4F.8090502@labn.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.249.218.183] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:13:35 -0000 No, I'm not aware of any IPR that applies to this draft. /Anders -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: den 18 juli 2013 21:05 To: diego.caviglia@ericsson.com; Anders Gavler; Jonas M=E5rtensson; i-nishi= oka@cb.jp.nec.com; pierre.peloso@alcatel-lucent.com; cyril.margaria@nsn.com= ; giomarti@cisco.com; ggalimbe@cisco.com; lyong@ciena.com; daniele.ceccarel= li@ericsson.com; gregb@grotto-networking.com; leeyoung@huawei.com; danli@hu= awei.com; imajuku.wataru@lab.ntt.co.jp; hanjianrui@huawei.com Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From Anders.Gavler@acreo.se Fri Aug 9 08:14:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B48311E825D for ; Fri, 9 Aug 2013 08:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-1.388, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SFVm9EqEs9W for ; Fri, 9 Aug 2013 08:14:29 -0700 (PDT) Received: from smtp9-outgoing.stejtech.net (smtp9.stejtech.net [IPv6:2001:16d8:c001:2073::aaa9]) by ietfa.amsl.com (Postfix) with ESMTP id 38E3521E8143 for ; Fri, 9 Aug 2013 08:06:35 -0700 (PDT) X-Spam-STAY-ID: _CMAETAG_ Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp9.stejtech.net (Postfix) with ESMTPSA id 0E2992CE077; Fri, 9 Aug 2013 17:06:33 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 17:06:33 +0200 From: Anders Gavler To: Lou Berger , "diego.caviglia@ericsson.com" , =?iso-8859-1?Q?Jonas_M=E5rtensson?= , "i-nishioka@cb.jp.nec.com" , "rrao@infinera.com" , "giomarti@cisco.com" , "remi.theillaud@marben-products.com" , "gregb@grotto-networking.com" , "ylee@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Thread-Index: AQHOg+mhictblDzQQE6e2aGiX1XI4ZmNHDBA Date: Fri, 9 Aug 2013 15:06:32 +0000 Message-ID: References: <51E83C33.7010802@labn.net> In-Reply-To: <51E83C33.7010802@labn.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.249.218.183] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:14:34 -0000 No, I'm not aware of any IPR that applies to this draft. /Anders -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: den 18 juli 2013 21:04 To: diego.caviglia@ericsson.com; Anders Gavler; Jonas M=E5rtensson; i-nishi= oka@cb.jp.nec.com; rrao@infinera.com; giomarti@cisco.com; remi.theillaud@ma= rben-products.com; gregb@grotto-networking.com; ylee@huawei.com; danli@huaw= ei.com; imajuku.wataru@lab.ntt.co.jp; hanjianrui@huawei.com Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From mhartley@cisco.com Fri Aug 9 08:15:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D6421F84B8 for ; Fri, 9 Aug 2013 08:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08ep1DWZoJeO for ; Fri, 9 Aug 2013 08:15:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0F11921F862B for ; Fri, 9 Aug 2013 08:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1697; q=dns/txt; s=iport; t=1376060838; x=1377270438; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/d8SPUu5/2aSzrfkQNYLTEOrXWCm4mPtu+GNPXDk7Sc=; b=X7gpntpq/x0sdikn4XTbaLrCb19sQm/OnDy9MQBDTFXCgkOm+bXeff+R oFCi2Uvo+AHrDYajtkuvTGV5D92Fgfm7KDKKSnfV8K2gkjGA+7dC4zKcP hgHamdsF9Pwj26uKjHKYNfnFqLw8recDYXAnzvcKx5fOri17kt91QjYYU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAOYEBVKtJXG+/2dsb2JhbABbgwY1UL5RgRoWdIIkAQEBAwEBAQE3NAsFCwIBCCIUECcLJQEBBAENBQiIAgYMuSEEj2oxB4MadAOpMIMYgio X-IronPort-AV: E=Sophos;i="4.89,846,1367971200"; d="scan'208";a="245453922" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 09 Aug 2013 15:07:17 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r79F7HGB027358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 15:07:17 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 10:07:17 -0500 From: "Matt Hartley (mhartley)" To: John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQ Date: Fri, 9 Aug 2013 15:07:17 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:15:22 -0000 John, The point you raise is a good one, but I don't think it has much to do with= this draft. > I think there is a basic issue with this draft, which is that the server > network manages its own TE metrics and those metrics almost certainly hav= e > nothing in common with the TE metrics used in a given client network. So if I understand you correctly, you're just saying that "cost" is a somew= hat vague thing that may mean different things to different network operato= rs? This is true sometimes, but that doesn't mean it will always be the cas= e. And I think concepts such as latency and latency variation are less pron= e to this problem; when we talk about "latency", I'm reasonably sure we all= mean the same thing. > Given this, would it not be better to have policy in the client nodes tha= t > maps the characteristics of a given LSP established across the server net= work > into the TE metric to be advertised with that LSP in the client network? Certainly that might be a good idea... but it's beyond the scope of this dr= aft. If you want to map the characteristics of a given LSP established acro= ss the server network into the TE metric to be advertised with that LSP in = the client network, you first have to know what the characteristics of the = LSP across the server network are... and that's what this draft is for; it'= s simply about the discovery of the information, not what you choose to do = with it afterwards. Cheers Matt >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From Jonas.Martensson@acreo.se Fri Aug 9 08:32:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BF021F99B0 for ; Fri, 9 Aug 2013 08:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1rQHcyoGn0u for ; Fri, 9 Aug 2013 08:32:11 -0700 (PDT) Received: from smtp200-outgoing.stejtech.net (smtp200.stejtech.net [IPv6:2001:9b0:1:704::5200]) by ietfa.amsl.com (Postfix) with ESMTP id 56A0421F9BF7 for ; Fri, 9 Aug 2013 08:24:10 -0700 (PDT) X-Spam-STAY-ID: _CMAETAG_ Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp200.stejtech.net (Postfix) with ESMTPSA id ACF5010AE1FB; Fri, 9 Aug 2013 17:24:08 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 17:24:08 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Lou Berger , "diego.caviglia@ericsson.com" , Anders Gavler , "i-nishioka@cb.jp.nec.com" , "lyong@ciena.com" , "cyril.margaria@nsn.com" , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-info Thread-Index: AQHOg+m0eGzNKbFtg06LCiFJgXH2UJmNIO8a Date: Fri, 9 Aug 2013 15:24:07 +0000 Message-ID: <7ECED07E132D4B4F89DCC0FDA683C6C2077C31@ACREOEXC02.ad.acreo.se> References: <51E83C26.2090302@labn.net> In-Reply-To: <51E83C26.2090302@labn.net> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.209.53.60] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-info X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:32:15 -0000 No, I'm not aware of any IPR that applies to this draft.=0A= =0A= /Jonas=0A= ________________________________________=0A= From: Lou Berger [lberger@labn.net]=0A= Sent: Thursday, July 18, 2013 9:04 PM=0A= To: diego.caviglia@ericsson.com; Anders Gavler; Jonas M=E5rtensson; i-nishi= oka@cb.jp.nec.com; lyong@ciena.com; cyril.margaria@nsn.com; gregb@grotto-ne= tworking.com; leeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt= .co.jp=0A= Cc: ccamp@ietf.org=0A= Subject: Regarding IPR on draft-ietf-ccamp-rwa-info=0A= =0A= Authors, Contributors, (CCAMP)=0A= =0A= As part of the preparation for WG Last Call:=0A= =0A= Are you aware of any IPR that applies to draft identified above?=0A= =0A= Please state either:=0A= =0A= "No, I'm not aware of any IPR that applies to this draft"=0A= or=0A= "Yes, I'm aware of IPR that applies to this draft"=0A= =0A= If so, has this IPR been disclosed in compliance with IETF IPR rules=0A= (see RFCs 3979, 4879, 3669 and 5378 for more details)?=0A= =0A= If yes to the above, please state either:=0A= =0A= "Yes, the IPR has been disclosed in compliance with IETF IPR rules"=0A= or=0A= "No, the IPR has not been disclosed"=0A= =0A= If you answer no, please provide any additional details you think=0A= appropriate.=0A= =0A= If you are listed as a document author or contributor please answer the=0A= above by responding to this email regardless of whether or not you are=0A= aware of any relevant IPR. This document will not advance to the next=0A= stage until a response has been received from each author and listed=0A= contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS=0A= MESSAGE'S TO LINES.=0A= =0A= If you are on the CCAMP WG email list but are not listed as an author or=0A= contributor, we remind you of your obligations under the IETF IPR rules=0A= which encourages you to notify the IETF if you are aware of IPR of=0A= others on an IETF contribution, or to refrain from participating in any=0A= contribution or discussion related to your undisclosed IPR. For more=0A= information, please see the RFCs listed above and=0A= http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.=0A= =0A= Thank you,=0A= CCAMP WG Chairs=0A= =0A= PS Please include all listed in the headers of this message in your=0A= response.=0A= From Jonas.Martensson@acreo.se Fri Aug 9 08:32:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CD221F99DD for ; Fri, 9 Aug 2013 08:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqrNiawr5IyM for ; Fri, 9 Aug 2013 08:32:24 -0700 (PDT) Received: from smtp202-outgoing.stejtech.net (smtp202.stejtech.net [213.136.34.152]) by ietfa.amsl.com (Postfix) with ESMTP id C9EC321F84B8 for ; Fri, 9 Aug 2013 08:24:33 -0700 (PDT) X-Spam-STAY-ID: _CMAETAG_ Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp202.stejtech.net (Postfix) with ESMTPSA id E71AC109422C; Fri, 9 Aug 2013 17:24:31 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 17:24:31 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Lou Berger , "diego.caviglia@ericsson.com" , Anders Gavler , "i-nishioka@cb.jp.nec.com" , "pierre.peloso@alcatel-lucent.com" , "cyril.margaria@nsn.com" , "giomarti@cisco.com" , "ggalimbe@cisco.com" , "lyong@ciena.com" , "daniele.ceccarelli@ericsson.com" , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHOg+qeNDOpuqGD7ESzKnZY5OCWLZmNIS1p Date: Fri, 9 Aug 2013 15:24:31 +0000 Message-ID: <7ECED07E132D4B4F89DCC0FDA683C6C2077C4E@ACREOEXC02.ad.acreo.se> References: <51E83C4F.8090502@labn.net> In-Reply-To: <51E83C4F.8090502@labn.net> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.209.53.60] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:32:29 -0000 No, I'm not aware of any IPR that applies to this draft.=0A= =0A= /Jonas=0A= ________________________________________=0A= From: Lou Berger [lberger@labn.net]=0A= Sent: Thursday, July 18, 2013 9:04 PM=0A= To: diego.caviglia@ericsson.com; Anders Gavler; Jonas M=E5rtensson; i-nishi= oka@cb.jp.nec.com; pierre.peloso@alcatel-lucent.com; cyril.margaria@nsn.com= ; giomarti@cisco.com; ggalimbe@cisco.com; lyong@ciena.com; daniele.ceccarel= li@ericsson.com; gregb@grotto-networking.com; leeyoung@huawei.com; danli@hu= awei.com; imajuku.wataru@lab.ntt.co.jp; hanjianrui@huawei.com=0A= Cc: ccamp@ietf.org=0A= Subject: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode=0A= =0A= Authors, Contributors, (CCAMP)=0A= =0A= As part of the preparation for WG Last Call:=0A= =0A= Are you aware of any IPR that applies to draft identified above?=0A= =0A= Please state either:=0A= =0A= "No, I'm not aware of any IPR that applies to this draft"=0A= or=0A= "Yes, I'm aware of IPR that applies to this draft"=0A= =0A= If so, has this IPR been disclosed in compliance with IETF IPR rules=0A= (see RFCs 3979, 4879, 3669 and 5378 for more details)?=0A= =0A= If yes to the above, please state either:=0A= =0A= "Yes, the IPR has been disclosed in compliance with IETF IPR rules"=0A= or=0A= "No, the IPR has not been disclosed"=0A= =0A= If you answer no, please provide any additional details you think=0A= appropriate.=0A= =0A= If you are listed as a document author or contributor please answer the=0A= above by responding to this email regardless of whether or not you are=0A= aware of any relevant IPR. This document will not advance to the next=0A= stage until a response has been received from each author and listed=0A= contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS=0A= MESSAGE'S TO LINES.=0A= =0A= If you are on the CCAMP WG email list but are not listed as an author or=0A= contributor, we remind you of your obligations under the IETF IPR rules=0A= which encourages you to notify the IETF if you are aware of IPR of=0A= others on an IETF contribution, or to refrain from participating in any=0A= contribution or discussion related to your undisclosed IPR. For more=0A= information, please see the RFCs listed above and=0A= http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.=0A= =0A= Thank you,=0A= CCAMP WG Chairs=0A= =0A= PS Please include all listed in the headers of this message in your=0A= response.=0A= From Jonas.Martensson@acreo.se Fri Aug 9 08:32:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CB411E810C for ; Fri, 9 Aug 2013 08:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZdsuwgaQUdk for ; Fri, 9 Aug 2013 08:32:31 -0700 (PDT) Received: from smtp201-outgoing.stejtech.net (smtp201.stejtech.net [213.136.34.151]) by ietfa.amsl.com (Postfix) with ESMTP id 676F321F9C53 for ; Fri, 9 Aug 2013 08:24:55 -0700 (PDT) X-Spam-STAY-ID: _CMAETAG_ Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp201.stejtech.net (Postfix) with ESMTPSA id 55F7A3C6543; Fri, 9 Aug 2013 17:24:53 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 17:24:53 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Lou Berger , "diego.caviglia@ericsson.com" , Anders Gavler , "i-nishioka@cb.jp.nec.com" , "rrao@infinera.com" , "giomarti@cisco.com" , "remi.theillaud@marben-products.com" , "gregb@grotto-networking.com" , "ylee@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Thread-Index: AQHOg+mhqRq/plxL80igTSIcacmw1pmNIUwU Date: Fri, 9 Aug 2013 15:24:52 +0000 Message-ID: <7ECED07E132D4B4F89DCC0FDA683C6C2077C65@ACREOEXC02.ad.acreo.se> References: <51E83C33.7010802@labn.net> In-Reply-To: <51E83C33.7010802@labn.net> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.209.53.60] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:32:37 -0000 No, I'm not aware of any IPR that applies to this draft.=0A= =0A= /Jonas=0A= ________________________________________=0A= From: Lou Berger [lberger@labn.net]=0A= Sent: Thursday, July 18, 2013 9:04 PM=0A= To: diego.caviglia@ericsson.com; Anders Gavler; Jonas M=E5rtensson; i-nishi= oka@cb.jp.nec.com; rrao@infinera.com; giomarti@cisco.com; remi.theillaud@ma= rben-products.com; gregb@grotto-networking.com; ylee@huawei.com; danli@huaw= ei.com; imajuku.wataru@lab.ntt.co.jp; hanjianrui@huawei.com=0A= Cc: ccamp@ietf.org=0A= Subject: Regarding IPR on draft-ietf-ccamp-general-constraint-encode=0A= =0A= Authors, Contributors, (CCAMP)=0A= =0A= As part of the preparation for WG Last Call:=0A= =0A= Are you aware of any IPR that applies to draft identified above?=0A= =0A= Please state either:=0A= =0A= "No, I'm not aware of any IPR that applies to this draft"=0A= or=0A= "Yes, I'm aware of IPR that applies to this draft"=0A= =0A= If so, has this IPR been disclosed in compliance with IETF IPR rules=0A= (see RFCs 3979, 4879, 3669 and 5378 for more details)?=0A= =0A= If yes to the above, please state either:=0A= =0A= "Yes, the IPR has been disclosed in compliance with IETF IPR rules"=0A= or=0A= "No, the IPR has not been disclosed"=0A= =0A= If you answer no, please provide any additional details you think=0A= appropriate.=0A= =0A= If you are listed as a document author or contributor please answer the=0A= above by responding to this email regardless of whether or not you are=0A= aware of any relevant IPR. This document will not advance to the next=0A= stage until a response has been received from each author and listed=0A= contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS=0A= MESSAGE'S TO LINES.=0A= =0A= If you are on the CCAMP WG email list but are not listed as an author or=0A= contributor, we remind you of your obligations under the IETF IPR rules=0A= which encourages you to notify the IETF if you are aware of IPR of=0A= others on an IETF contribution, or to refrain from participating in any=0A= contribution or discussion related to your undisclosed IPR. For more=0A= information, please see the RFCs listed above and=0A= http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.=0A= =0A= Thank you,=0A= CCAMP WG Chairs=0A= =0A= PS Please include all listed in the headers of this message in your=0A= response.=0A= From jdrake@juniper.net Fri Aug 9 08:48:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87BD11E8129 for ; Fri, 9 Aug 2013 08:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIDOw-v9F919 for ; Fri, 9 Aug 2013 08:48:00 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFB221F9A96 for ; Fri, 9 Aug 2013 08:42:13 -0700 (PDT) Received: from mail34-db8-R.bigfish.com (10.174.8.250) by DB8EHSOBE029.bigfish.com (10.174.4.92) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 15:42:12 +0000 Received: from mail34-db8 (localhost [127.0.0.1]) by mail34-db8-R.bigfish.com (Postfix) with ESMTP id 3AFF66A01E1; Fri, 9 Aug 2013 15:42:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail34-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(377454003)(189002)(51704005)(13464003)(47446002)(65816001)(74316001)(54316002)(74662001)(56816003)(74876001)(46102001)(47976001)(80022001)(53806001)(79102001)(83072001)(76482001)(76576001)(74502001)(81342001)(77982001)(77096001)(54356001)(59766001)(50986001)(33646001)(66066001)(81686001)(47736001)(49866001)(51856001)(4396001)(81542001)(74706001)(31966008)(69226001)(80976001)(63696002)(19580405001)(19580385001)(76786001)(56776001)(19580395003)(74366001)(76796001)(16406001)(83322001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail34-db8 (localhost.localdomain [127.0.0.1]) by mail34-db8 (MessageSwitch) id 1376062929529109_31640; Fri, 9 Aug 2013 15:42:09 +0000 (UTC) Received: from DB8EHSMHS005.bigfish.com (unknown [10.174.8.248]) by mail34-db8.bigfish.com (Postfix) with ESMTP id 7BD6920041; Fri, 9 Aug 2013 15:42:09 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS005.bigfish.com (10.174.4.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 15:42:08 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 15:42:02 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 15:41:59 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 15:41:59 +0000 From: John E Drake To: "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAErlUA= Date: Fri, 9 Aug 2013 15:41:58 +0000 Message-ID: <925f76c29b1a44d896e38962c33085f0@BY2PR05MB142.namprd05.prod.outlook.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:48:09 -0000 Yours Irrespectively, John > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Friday, August 09, 2013 8:07 AM > To: John E Drake; CCAMP (ccamp@ietf.org) > Cc: Matt Hartley (mhartley) > Subject: RE: draft-ietf-ccamp-te-metric-recording-02 >=20 > John, >=20 > The point you raise is a good one, but I don't think it has much to do wi= th this > draft. JD: This draft is proposing that the cumulative TE metric associated with = the establishment of an LSP in the server network be passed to the client L= SP endpoints. My point is that this is probably useless at best. =20 >=20 > > I think there is a basic issue with this draft, which is that the > > server network manages its own TE metrics and those metrics almost > > certainly have nothing in common with the TE metrics used in a given cl= ient > network. >=20 > So if I understand you correctly, you're just saying that "cost" is a som= ewhat > vague thing that may mean different things to different network operators= ? > This is true sometimes, but that doesn't mean it will always be the case. JD: You have no way of knowing whether there is any congruence between the= TE metrics in the server network and the TE metrics in a client network. > And I > think concepts such as latency and latency variation are less prone to th= is > problem; when we talk about "latency", I'm reasonably sure we all mean th= e > same thing. JD: I didn't say anything about latency, however, since you mention it, I = think it would be far better for the clients to measure latency. >=20 > > Given this, would it not be better to have policy in the client nodes > > that maps the characteristics of a given LSP established across the > > server network into the TE metric to be advertised with that LSP in the > client network? >=20 > Certainly that might be a good idea... but it's beyond the scope of this = draft. > If you want to map the characteristics of a given LSP established across = the > server network into the TE metric to be advertised with that LSP in the c= lient > network, you first have to know what the characteristics of the LSP acros= s > the server network are... and that's what this draft is for; it's simply = about the > discovery of the information, not what you choose to do with it afterward= s. JD: I think you are missing my point. The accumulated TE metric for an LS= P in the server network is not a characteristic that is of any use to the c= lient, so what I am proposing is that it be removed from the draft.=20 >=20 > Cheers >=20 > Matt >=20 > > > > Yours Irrespectively, > > > > John > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp >=20 From zali@cisco.com Fri Aug 9 08:59:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F2621F9C9A for ; Fri, 9 Aug 2013 08:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWG9VmOgNKIw for ; Fri, 9 Aug 2013 08:59:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 66C4E21F9A6A for ; Fri, 9 Aug 2013 08:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1859; q=dns/txt; s=iport; t=1376063644; x=1377273244; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=mDtIY5sxcFcnwbFdmb/l306UR8rVA4yWOkJX4yMvsU0=; b=A0avf9tBR5JBv09dSW1WBqtxYPYSbzI14h7kaSizsm7dGHJfgUbeT1Lf W4MO1mG0V71l8cObVlSD3NKA360kQhr2KOX1k3JB2ca1AHTfmjpYpG0iC k2FHVVi2CgIdp3VeIc5GkjAdJyXZGPly8ITNr+hAg5S4CtlEaZHR0k7nv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFADQQBVKtJXG//2dsb2JhbABbgwaBBb5TgRoWdIIkAQEBBIEFBgEIEQMBAQELHTkUCQgBAQQBEgiICLkqj2o4BoMUdAOpMIMYgio X-IronPort-AV: E=Sophos;i="4.89,846,1367971200"; d="scan'208";a="242503314" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 09 Aug 2013 15:54:03 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r79Fs22i004932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 15:54:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 10:54:02 -0500 From: "Zafar Ali (zali)" To: John E Drake , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAErlUAAAuecgA== Date: Fri, 9 Aug 2013 15:54:02 +0000 Message-ID: In-Reply-To: <925f76c29b1a44d896e38962c33085f0@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.215.174] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4E4777BB94A4A54F96D3674147C3D27D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:59:52 -0000 Hi John: Please see in-line. Thanks Regards =8A Zafar -----Original Message----- From: "jdrake@juniper.net" Date: Friday, August 9, 2013 11:41 AM To: "Matt Hartley (mhartley)" , "ccamp@ietf.org" Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 > > >Yours Irrespectively, > >John > >> -----Original Message----- >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> Sent: Friday, August 09, 2013 8:07 AM >> To: John E Drake; CCAMP (ccamp@ietf.org) >> Cc: Matt Hartley (mhartley) >> Subject: RE: draft-ietf-ccamp-te-metric-recording-02 >>=20 >> John, >>=20 >> The point you raise is a good one, but I don't think it has much to do >>with this >> draft. > >JD: This draft is proposing that the cumulative TE metric associated >with the establishment of an LSP in the server network be passed to the >client LSP endpoints. My point is that this is probably useless at best. This is all controlled by policy at the client layer and depends on the use cases of independent vs. dependent costs. >=20 >>=20 >> > I think there is a basic issue with this draft, which is that the >> > server network manages its own TE metrics and those metrics almost >> > certainly have nothing in common with the TE metrics used in a given >>client >> network. >>=20 >> So if I understand you correctly, you're just saying that "cost" is a >>somewhat >> vague thing that may mean different things to different network >>operators? >> This is true sometimes, but that doesn't mean it will always be the >>case. > >JD: You have no way of knowing whether there is any congruence between >the TE metrics in the server network and the TE metrics in a client >network. This is all controlled by policy at the client layer. >=20 From IBryskin@advaoptical.com Fri Aug 9 09:21:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF28021F9F86 for ; Fri, 9 Aug 2013 09:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpkKBuh+GCkZ for ; Fri, 9 Aug 2013 09:21:38 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id E212521F9CDF for ; Fri, 9 Aug 2013 09:14:19 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id r79GEH8v027642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 12:14:17 -0400 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0146.000; Fri, 9 Aug 2013 12:14:17 -0400 From: Igor Bryskin To: "Matt Hartley (mhartley)" , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAIuwnA= Date: Fri, 9 Aug 2013 16:14:17 +0000 Message-ID: References: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-09_07:2013-08-09, 2013-08-09, 1970-01-01 signatures=0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:21:43 -0000 Matt, John's point is that the costs of a TE link in a client layer are not "some= thing vague" or something absolute as you imply, rather, something that ca= n relate said TE link to other client layer TE links, and such costs have n= othing to do with the costs of the server LSPs supporting them. Consider th= e following: a) static client layer TE link 0; b) client layer TE link 1 supported by a server layer LSP1 in server domain= 1; c) client layer TE link 2 supported by a server layer LSP2 in server domai= n 2 The point is that the costs collected for, say, LSP1 do not help in any wa= y to define the costs of TE Link1 as compared to costs of TE link 0 or TE l= ink2; Cheers, Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of M= att Hartley (mhartley) Sent: Friday, August 09, 2013 11:07 AM To: John E Drake; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 John, The point you raise is a good one, but I don't think it has much to do with= this draft. > I think there is a basic issue with this draft, which is that the=20 > server network manages its own TE metrics and those metrics almost=20 > certainly have nothing in common with the TE metrics used in a given clie= nt network. So if I understand you correctly, you're just saying that "cost" is a somew= hat vague thing that may mean different things to different network operato= rs? This is true sometimes, but that doesn't mean it will always be the cas= e. And I think concepts such as latency and latency variation are less pron= e to this problem; when we talk about "latency", I'm reasonably sure we all= mean the same thing. > Given this, would it not be better to have policy in the client nodes=20 > that maps the characteristics of a given LSP established across the=20 > server network into the TE metric to be advertised with that LSP in the c= lient network? Certainly that might be a good idea... but it's beyond the scope of this dr= aft. If you want to map the characteristics of a given LSP established acro= ss the server network into the TE metric to be advertised with that LSP in = the client network, you first have to know what the characteristics of the = LSP across the server network are... and that's what this draft is for; it'= s simply about the discovery of the information, not what you choose to do = with it afterwards. Cheers Matt >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Fri Aug 9 09:39:37 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC12E21F9C8B for ; Fri, 9 Aug 2013 09:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53K7dA7nFcz8 for ; Fri, 9 Aug 2013 09:39:31 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7181611E81B8 for ; Fri, 9 Aug 2013 09:32:39 -0700 (PDT) Received: from mail22-db9-R.bigfish.com (10.174.16.235) by DB9EHSOBE035.bigfish.com (10.174.14.98) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 16:32:38 +0000 Received: from mail22-db9 (localhost [127.0.0.1]) by mail22-db9-R.bigfish.com (Postfix) with ESMTP id 51C772400F2; Fri, 9 Aug 2013 16:32:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail22-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(189002)(199002)(51704005)(377454003)(33646001)(4396001)(56776001)(76786001)(74876001)(74662001)(76482001)(54316002)(47446002)(74502001)(53806001)(83072001)(74366001)(16406001)(54356001)(81342001)(31966008)(59766001)(77982001)(79102001)(63696002)(46102001)(65816001)(76576001)(80022001)(51856001)(19580395003)(74316001)(76796001)(69226001)(80976001)(19580405001)(50986001)(83322001)(56816003)(49866001)(74706001)(47976001)(81542001)(77096001)(81686001)(47736001)(66066001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.50; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail22-db9 (localhost.localdomain [127.0.0.1]) by mail22-db9 (MessageSwitch) id 1376065955450042_4926; Fri, 9 Aug 2013 16:32:35 +0000 (UTC) Received: from DB9EHSMHS030.bigfish.com (unknown [10.174.16.253]) by mail22-db9.bigfish.com (Postfix) with ESMTP id 698043A0047; Fri, 9 Aug 2013 16:32:35 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS030.bigfish.com (10.174.14.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 16:32:34 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 16:32:33 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 16:32:31 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 16:32:31 +0000 From: John E Drake To: "Zafar Ali (zali)" , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAErlUAAAuecgAAA0JXQ Date: Fri, 9 Aug 2013 16:32:30 +0000 Message-ID: <8bc1c2885c4a406a9ebcc0a8edad3f2e@BY2PR05MB142.namprd05.prod.outlook.com> References: <925f76c29b1a44d896e38962c33085f0@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.50] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:39:38 -0000 Zafar, Given that a client has no idea what the TE metric it receives from the ser= ver network means, how exactly does this work? Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Friday, August 09, 2013 8:54 AM > To: John E Drake; Matt Hartley (mhartley); CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 > Hi John: >=20 > Please see in-line. >=20 > Thanks >=20 > Regards =A9 Zafar >=20 >=20 > -----Original Message----- > From: "jdrake@juniper.net" > Date: Friday, August 9, 2013 11:41 AM > To: "Matt Hartley (mhartley)" , "ccamp@ietf.org" > > Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 > > > > > >Yours Irrespectively, > > > >John > > > >> -----Original Message----- > >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >> Sent: Friday, August 09, 2013 8:07 AM > >> To: John E Drake; CCAMP (ccamp@ietf.org) > >> Cc: Matt Hartley (mhartley) > >> Subject: RE: draft-ietf-ccamp-te-metric-recording-02 > >> > >> John, > >> > >> The point you raise is a good one, but I don't think it has much to > >>do with this draft. > > > >JD: This draft is proposing that the cumulative TE metric associated > >with the establishment of an LSP in the server network be passed to the > >client LSP endpoints. My point is that this is probably useless at best= . >=20 > This is all controlled by policy at the client layer and depends on the u= se cases > of independent vs. dependent costs. >=20 > > > >> > >> > I think there is a basic issue with this draft, which is that the > >> > server network manages its own TE metrics and those metrics almost > >> > certainly have nothing in common with the TE metrics used in a > >> > given > >>client > >> network. > >> > >> So if I understand you correctly, you're just saying that "cost" is a > >>somewhat vague thing that may mean different things to different > >>network operators? > >> This is true sometimes, but that doesn't mean it will always be the > >>case. > > > >JD: You have no way of knowing whether there is any congruence between > >the TE metrics in the server network and the TE metrics in a client > >network. >=20 > This is all controlled by policy at the client layer. > > >=20 >=20 From zali@cisco.com Fri Aug 9 09:52:49 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1783D11E8143 for ; Fri, 9 Aug 2013 09:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.952 X-Spam-Level: X-Spam-Status: No, score=-9.952 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa3pAey+9c7o for ; Fri, 9 Aug 2013 09:52:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 936E521F9831 for ; Fri, 9 Aug 2013 09:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2377; q=dns/txt; s=iport; t=1376066793; x=1377276393; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=zyZkONJULUd7l6F0NuUv5yCq2owJz0XVBjQrhu76J6k=; b=EV6YHrr+ulR3Pw1Yz2CN0p+e5Z3jHBUH4DDujQL7RnbznJBlYrZKTlVr mFCq7TH8mcgp04TI9Pe12zva4FPKhQ3jd6xx7DzjQfie4e2Ez0j5VSwVx PW7sZlYNIAyRLLWGF+6hAkHLMu7Ft+ur1z9gsnMXXBGc7FRSCRIDCk62n Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFACMcBVKtJXG9/2dsb2JhbABbgwY1UL5RgRoWdIIkAQEBBAEBAWsXBgEIEQMBAQELHS4LFAkIAQEEARIIiAgMuSoEkAE4BoMUdQOpMYMbgio X-IronPort-AV: E=Sophos;i="4.89,846,1367971200"; d="scan'208";a="245530813" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 09 Aug 2013 16:46:18 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r79GkHmJ016748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 16:46:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 11:46:17 -0500 From: "Zafar Ali (zali)" To: Fatai Zhang , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACDxnIA= Date: Fri, 9 Aug 2013 16:46:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.215.174] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0B75DD73FC52C549931D9B672E6A6EFC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:52:49 -0000 Hi John/ Fatai- ERO expansion is an already supported functionality since early days of RSVP-TE and is widely deployed. There is a new requirement to convey latency bound in TE networks. Hence a very simple and logical extension in RSVP TE to support the newly defined TE (latency) metrics. If we go with your logic, any operator that wants to deploy latency metric will be forced to deploy a PCE (including in the existing deployments) which is a no-go. Especially given the RSVP TE extensions are so simple. Latency is an important "traffic engineering" metric and suggesting not to support it in RSVP-TE ("traffic engineering") is much odd. If we go with your logic, we should just simply retire RSVP-TE and FORCE every SP to deploy PCE (in addition of RSVP-TE) for TE. Thanks Regards =8A Zafar -----Original Message----- From: Fatai Zhang Date: Thursday, August 8, 2013 10:04 PM To: "jdrake@juniper.net" , "ccamp@ietf.org" Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt >Hi John, > >Completely agree.=20 > >I also raised this comment in front of the mic during Berlin meeting. > > > >Best Regards > >Fatai > > >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >John E Drake >Sent: Friday, August 09, 2013 1:49 AM >To: CCAMP (ccamp@ietf.org) >Subject: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt > >Hi, > >I have a real concern with this draft because it appears to be heading us >down the road of re-inventing PCEP in RSVP signaling with the dubious >justification that it is needed in those situations in which a PCE is not >available. However, if you re-invent PCEP in RSVP signaling, then you >have effectively ensured that there are no situations in which a PCE or >its signaling equivalent are not available. > >Why is this better than simply ensuring that a PCE is available in those >situations in which it is needed? > >Yours Irrespectively, > >John > > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From zali@cisco.com Fri Aug 9 10:01:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9FA11E810C for ; Fri, 9 Aug 2013 10:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8rfG8dHPQdk for ; Fri, 9 Aug 2013 10:01:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E86B421F9CAC for ; Fri, 9 Aug 2013 09:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=621; q=dns/txt; s=iport; t=1376067360; x=1377276960; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=jtJSDNBv3rR3cgYKa1zVivh07FX1SHMg59uxC31kiI0=; b=VYtS21TVpJqvHln6owvCEFT2nKa1KxdY5WNPfZm4h3bynYNg3UtNtQHI Y/BdV0tjtb0CnNWWWm2YOIDb67UHK9L40tIQ5sm79oRmZZRaKD4g4x3CQ RqKXKtDXNhUvcvatIA1XBRaVT+5EehXbr7GK8cYWtyRc7Bp3rsqM92awv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAHceBVKtJV2b/2dsb2JhbABbgwaBBYJMvAWBGhZ0giQBAQEEgQUGAQgRAwECC1YdCAEBBAESCIgIuUOQATgGgxR1A6kxgxuCKg X-IronPort-AV: E=Sophos;i="4.89,846,1367971200"; d="scan'208";a="245534845" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 09 Aug 2013 16:55:59 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r79GtxYC019638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 16:55:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 11:55:59 -0500 From: "Zafar Ali (zali)" To: John E Drake , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAErlUAAAuecgAAA0JXQAAFZTAA= Date: Fri, 9 Aug 2013 16:55:58 +0000 Message-ID: In-Reply-To: <8bc1c2885c4a406a9ebcc0a8edad3f2e@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.215.174] Content-Type: text/plain; charset="Windows-1252" Content-ID: <02E70DFAF49CF74EADAAEF82EB37F59D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:01:51 -0000 John-=20 Of course, client knows that the metric represents server layer cost of using this connection. Thanks Regards =8A Zafar -----Original Message----- From: "jdrake@juniper.net" Date: Friday, August 9, 2013 12:32 PM To: zali , "Matt Hartley (mhartley)" , "ccamp@ietf.org" Subject: RE: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >Zafar, > >Given that a client has no idea what the TE metric it receives from the >server network means, how exactly does this work? > >Yours Irrespectively, > >John > From jdrake@juniper.net Fri Aug 9 10:13:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39321F9406 for ; Fri, 9 Aug 2013 10:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.16 X-Spam-Level: X-Spam-Status: No, score=-4.16 tagged_above=-999 required=5 tests=[AWL=2.439, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwCm1cZRT9zo for ; Fri, 9 Aug 2013 10:13:47 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id AA3D721F9D2C for ; Fri, 9 Aug 2013 10:07:42 -0700 (PDT) Received: from mail159-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 17:07:41 +0000 Received: from mail159-tx2 (localhost [127.0.0.1]) by mail159-tx2-R.bigfish.com (Postfix) with ESMTP id 8E6E41001A5; Fri, 9 Aug 2013 17:07:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail159-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(37854004)(13464003)(189002)(199002)(51704005)(377454003)(33646001)(56776001)(76786001)(4396001)(74876001)(74662001)(76482001)(54316002)(47446002)(74502001)(53806001)(83072001)(74366001)(54356001)(16406001)(81342001)(31966008)(59766001)(77982001)(79102001)(63696002)(46102001)(65816001)(76576001)(80022001)(51856001)(77096001)(19580395003)(74316001)(76796001)(69226001)(80976001)(19580405001)(50986001)(83322001)(49866001)(56816003)(74706001)(47976001)(81542001)(47736001)(81686001)(66066001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail159-tx2 (localhost.localdomain [127.0.0.1]) by mail159-tx2 (MessageSwitch) id 1376068016369747_20148; Fri, 9 Aug 2013 17:06:56 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.253]) by mail159-tx2.bigfish.com (Postfix) with ESMTP id 54AD92004B; Fri, 9 Aug 2013 17:06:56 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 17:06:55 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 17:06:52 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 17:06:50 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 17:06:50 +0000 From: John E Drake To: "Zafar Ali (zali)" , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNFqQAgAACAgA= Date: Fri, 9 Aug 2013 17:06:50 +0000 Message-ID: <5016733261cf49a9a2d888b67e7a8f17@BY2PR05MB142.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:13:52 -0000 Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Friday, August 09, 2013 9:46 AM > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > Hi John/ Fatai- >=20 > ERO expansion is an already supported functionality since early days of R= SVP- > TE and is widely deployed. There is a new requirement to convey latency > bound in TE networks. Hence a very simple and logical extension in RSVP T= E > to support the newly defined TE (latency) metrics. JD: From the draft: " In these scenarios, there is a need for the ingress= node to convey the optimization criteria including the TE metrics (e.g., IGP= metric, TE metric, hop counts, latency, etc.) to be used for the path computati= on to the node performing route computation or expansion." This is a lot more than just latency and sounds like a description of PCEP. >=20 > If we go with your logic, any operator that wants to deploy latency metri= c will > be forced to deploy a PCE (including in the existing deployments) which i= s a > no-go. JD: Any operator that wishes to provide a path computation service to its = clients. The 'no-go' is simply an assertion. > Especially given the RSVP TE extensions are so simple. JD: Another assertion. >=20 > Latency is an important "traffic engineering" metric and suggesting not t= o > support it in RSVP-TE ("traffic engineering") is much odd. JD: RSVP-TE is a signaling protocol not a path computation protocol. > If we go with your > logic, we should just simply retire RSVP-TE and FORCE every SP to deploy = PCE > (in addition of RSVP-TE) for TE. JD: RSVP-TE for signaling and PCEP for path computation. >=20 > Thanks >=20 > Regards =A9 Zafar >=20 >=20 > -----Original Message----- > From: Fatai Zhang > Date: Thursday, August 8, 2013 10:04 PM > To: "jdrake@juniper.net" , "ccamp@ietf.org" > > Subject: Re: [CCAMP] > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt >=20 > >Hi John, > > > >Completely agree. > > > >I also raised this comment in front of the mic during Berlin meeting. > > > > > > > >Best Regards > > > >Fatai > > > > > >-----Original Message----- > >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > >Of John E Drake > >Sent: Friday, August 09, 2013 1:49 AM > >To: CCAMP (ccamp@ietf.org) > >Subject: [CCAMP] > >draft-ali-ccamp-rc-objective-function-metric-bound-03.txt > > > >Hi, > > > >I have a real concern with this draft because it appears to be heading > >us down the road of re-inventing PCEP in RSVP signaling with the > >dubious justification that it is needed in those situations in which a > >PCE is not available. However, if you re-invent PCEP in RSVP > >signaling, then you have effectively ensured that there are no > >situations in which a PCE or its signaling equivalent are not available. > > > >Why is this better than simply ensuring that a PCE is available in > >those situations in which it is needed? > > > >Yours Irrespectively, > > > >John > > > > > >_______________________________________________ > >CCAMP mailing list > >CCAMP@ietf.org > >https://www.ietf.org/mailman/listinfo/ccamp > >_______________________________________________ > >CCAMP mailing list > >CCAMP@ietf.org > >https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 From jdrake@juniper.net Fri Aug 9 10:41:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329D921F9B8C for ; Fri, 9 Aug 2013 10:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rTxtpuhbR9G for ; Fri, 9 Aug 2013 10:41:16 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 655C521F9A49 for ; Fri, 9 Aug 2013 10:34:31 -0700 (PDT) Received: from mail184-db8-R.bigfish.com (10.174.8.236) by DB8EHSOBE001.bigfish.com (10.174.4.64) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 17:34:30 +0000 Received: from mail184-db8 (localhost [127.0.0.1]) by mail184-db8-R.bigfish.com (Postfix) with ESMTP id 9ADE78027C; Fri, 9 Aug 2013 17:34:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail184-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(189002)(199002)(51704005)(377454003)(56776001)(33646001)(4396001)(76786001)(74876001)(76482001)(74662001)(54316002)(47446002)(74502001)(53806001)(83072001)(74366001)(54356001)(16406001)(81342001)(31966008)(59766001)(77096001)(79102001)(63696002)(46102001)(65816001)(80022001)(76576001)(51856001)(77982001)(19580395003)(74316001)(76796001)(69226001)(80976001)(19580405001)(50986001)(83322001)(49866001)(74706001)(56816003)(47976001)(81542001)(47736001)(81686001)(66066001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail184-db8 (localhost.localdomain [127.0.0.1]) by mail184-db8 (MessageSwitch) id 1376069669479061_7172; Fri, 9 Aug 2013 17:34:29 +0000 (UTC) Received: from DB8EHSMHS018.bigfish.com (unknown [10.174.8.254]) by mail184-db8.bigfish.com (Postfix) with ESMTP id 66F2D140047; Fri, 9 Aug 2013 17:34:29 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS018.bigfish.com (10.174.4.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 17:34:28 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 17:34:28 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 17:34:26 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 17:34:26 +0000 From: John E Drake To: "Zafar Ali (zali)" , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAErlUAAAuecgAAA0JXQAAFZTAAAANkAsA== Date: Fri, 9 Aug 2013 17:34:25 +0000 Message-ID: References: <8bc1c2885c4a406a9ebcc0a8edad3f2e@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:41:23 -0000 Zafar, And what normalization function does it use to turn this value, which is a = dimensionless number which has meaning only in the context of the server ne= twork, into a TE metric that has meaning in the client network?=20 Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Friday, August 09, 2013 9:56 AM > To: John E Drake; Matt Hartley (mhartley); CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 > John- >=20 > Of course, client knows that the metric represents server layer cost of u= sing > this connection. >=20 > Thanks >=20 > Regards =A9 Zafar >=20 >=20 >=20 > -----Original Message----- > From: "jdrake@juniper.net" > Date: Friday, August 9, 2013 12:32 PM > To: zali , "Matt Hartley (mhartley)" = , > "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 > >Zafar, > > > >Given that a client has no idea what the TE metric it receives from the > >server network means, how exactly does this work? > > > >Yours Irrespectively, > > > >John > > >=20 >=20 From zali@cisco.com Fri Aug 9 10:45:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D62611E819F for ; Fri, 9 Aug 2013 10:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmH2yNoge9+q for ; Fri, 9 Aug 2013 10:45:31 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C1D6F11E80D3 for ; Fri, 9 Aug 2013 10:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1755; q=dns/txt; s=iport; t=1376069933; x=1377279533; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=tMb6QvAvE//YRoJflAJ85ziCNbttO0VV1hMslaLQ3aA=; b=iSq20gRoazgY393eL/6iVVgmmpsiomFIuose/1i+1qRCNqPYCiuczeWz PmOKqy7O4Aavet74uIT5a+AxxoRDejmuoVyh4UVYf5dOLHdqe3VXr2Bm6 JIro5V+VQ/HnzQ+HGBy24l0LzlCoAK7o6IjdwpzyiLZXQY0OUX8NuRW1e Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAN8nBVKtJXG9/2dsb2JhbABbgwaBBb5RgRoWdIIkAQEBBIEFBgEIEQMBAQELHTkUCQgCBAESCIgIuSyQATgGgxR1A6kxgxuCKg X-IronPort-AV: E=Sophos;i="4.89,847,1367971200"; d="scan'208";a="245644782" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 09 Aug 2013 17:38:51 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r79Hcp4H017935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 17:38:51 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 12:38:50 -0500 From: "Zafar Ali (zali)" To: John E Drake , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAErlUAAAuecgAAA0JXQAAFZTAAAANkAsAAApc+A Date: Fri, 9 Aug 2013 17:38:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.252.237] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <639EAE655200454DB15EFA9CD995A7FC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:45:36 -0000 Hi John-=20 Client could apply a transformation (via offline policy); it can also use server cost as a measure of relative cost of the connections. Thanks Regards ... Zafar -----Original Message----- From: "jdrake@juniper.net" Date: Friday, August 9, 2013 1:34 PM To: zali , "Matt Hartley (mhartley)" , "ccamp@ietf.org" Subject: RE: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >Zafar, > >And what normalization function does it use to turn this value, which is >a dimensionless number which has meaning only in the context of the >server network, into a TE metric that has meaning in the client network? > >Yours Irrespectively, > >John > >> -----Original Message----- >> From: Zafar Ali (zali) [mailto:zali@cisco.com] >> Sent: Friday, August 09, 2013 9:56 AM >> To: John E Drake; Matt Hartley (mhartley); CCAMP (ccamp@ietf.org) >> Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >>=20 >> John- >>=20 >> Of course, client knows that the metric represents server layer cost of >>using >> this connection. >>=20 >> Thanks >>=20 >> Regards =A9 Zafar >>=20 >>=20 >>=20 >> -----Original Message----- >> From: "jdrake@juniper.net" >> Date: Friday, August 9, 2013 12:32 PM >> To: zali , "Matt Hartley (mhartley)" >>, >> "ccamp@ietf.org" >> Subject: RE: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >>=20 >> >Zafar, >> > >> >Given that a client has no idea what the TE metric it receives from the >> >server network means, how exactly does this work? >> > >> >Yours Irrespectively, >> > >> >John >> > >>=20 >>=20 > > From zali@cisco.com Fri Aug 9 10:45:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE6A11E81B0 for ; Fri, 9 Aug 2013 10:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.033 X-Spam-Level: X-Spam-Status: No, score=-10.033 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXcVLNctWlno for ; Fri, 9 Aug 2013 10:45:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CE50C21F9D3B for ; Fri, 9 Aug 2013 10:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1251; q=dns/txt; s=iport; t=1376069941; x=1377279541; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=8+wbOpwfitj1CE3JKB/ld0Fc8rabir1bWwB1R0lsoT4=; b=b96kMst28LOMtXiHzRtPIHT9YR/R6qvenwZC2EeLShVySh03I8Laqz+Q fQdMVR5I9E1Kvxj31SAnXFwrfy7C8flGd6+V5FmsiqjW2FNTVi8PgaCyl gipYBcyIqw4DoMoSGh147/wu5NBGjHDPJ7C/9e4eQwgufUVSmUb+XbydE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAN8nBVKtJXHB/2dsb2JhbABbgwaBBb5RgRoWdIIkAQEBBDpLBgEIEQMBAgsUQh0IAQEEARIIiAi5LJABOAaDFHUDqTGDG4Iq X-IronPort-AV: E=Sophos;i="4.89,847,1367971200"; d="scan'208";a="245644847" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 09 Aug 2013 17:39:00 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r79Hd0YP026937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 17:39:00 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 12:38:59 -0500 From: "Zafar Ali (zali)" To: John E Drake , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACDxnIAACRnMAP//xeaA Date: Fri, 9 Aug 2013 17:38:59 +0000 Message-ID: In-Reply-To: <5016733261cf49a9a2d888b67e7a8f17@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.252.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <688826012E3ABD4D87D44A04D06148D3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:45:47 -0000 -----Original Message----- From: "jdrake@juniper.net" Date: Friday, August 9, 2013 1:06 PM To: zali , Fatai Zhang , "ccamp@ietf.org" Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt >>Hi John/ Fatai- >>ERO expansion is an already supported functionality since early days of >>RSVP- >>TE and is widely deployed. There is a new requirement to convey latency >>bound in TE networks. Hence a very simple and logical extension in RSVP >>TE >>to support the newly defined TE (latency) metrics. > >JD: From the draft: " In these scenarios, there is a need for the >ingress node to > convey the optimization criteria including the TE metrics (e.g., >IGP metric, TE > metric, hop counts, latency, etc.) to be used for the path >computation to the > node performing route computation or expansion." John: Some text was loose w.r.t. what is defined in the draft. So the real comment is on this sentence. Nonetheless, we can explicitly confine the scope of the draft to newly defined TE metrics (most important use case is latency; latency variation for completeness). Thanks Regards...Zafar=20 From jdrake@juniper.net Fri Aug 9 10:57:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DBE11E8152 for ; Fri, 9 Aug 2013 10:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.02 X-Spam-Level: X-Spam-Status: No, score=-3.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuftMBwcBF8g for ; Fri, 9 Aug 2013 10:57:31 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id AA73C21F9E12 for ; Fri, 9 Aug 2013 10:52:29 -0700 (PDT) Received: from mail98-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 17:52:28 +0000 Received: from mail98-ch1 (localhost [127.0.0.1]) by mail98-ch1-R.bigfish.com (Postfix) with ESMTP id D21162A01F0; Fri, 9 Aug 2013 17:52:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail98-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(37854004)(189002)(199002)(377454003)(51704005)(4396001)(51856001)(49866001)(81542001)(74706001)(66066001)(83322001)(81686001)(47736001)(16406001)(74366001)(76796001)(63696002)(80976001)(31966008)(69226001)(56776001)(19580395003)(19580405001)(76786001)(47976001)(46102001)(47446002)(74662001)(74876001)(56816003)(54316002)(65816001)(74316001)(77096001)(77982001)(81342001)(74502001)(76576001)(50986001)(33646001)(59766001)(54356001)(80022001)(53806001)(76482001)(79102001)(83072001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail98-ch1 (localhost.localdomain [127.0.0.1]) by mail98-ch1 (MessageSwitch) id 1376070746882419_13285; Fri, 9 Aug 2013 17:52:26 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail98-ch1.bigfish.com (Postfix) with ESMTP id D35B14024E; Fri, 9 Aug 2013 17:52:26 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 17:52:25 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 17:52:24 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 17:52:23 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 17:52:22 +0000 From: John E Drake To: "Zafar Ali (zali)" , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNFqQAgAACAgCAAAy4gIAAA0bA Date: Fri, 9 Aug 2013 17:52:21 +0000 Message-ID: <79d884ec2ed64944baa5b6c5c1d6c5fe@BY2PR05MB142.namprd05.prod.outlook.com> References: <5016733261cf49a9a2d888b67e7a8f17@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:57:38 -0000 Zafar, I don't think this addresses the balance of my comments. AFAICT, you have = added all but one of the PCEP objective functions into RSVP-TE. Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Friday, August 09, 2013 10:39 AM > To: John E Drake; Fatai Zhang; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > -----Original Message----- >=20 > From: "jdrake@juniper.net" > Date: Friday, August 9, 2013 1:06 PM > To: zali , Fatai Zhang , > "ccamp@ietf.org" > Subject: RE: [CCAMP] > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt >=20 > >>Hi John/ Fatai- > >>ERO expansion is an already supported functionality since early days > >>of > >>RSVP- > >>TE and is widely deployed. There is a new requirement to convey > >>latency bound in TE networks. Hence a very simple and logical > >>extension in RSVP TE to support the newly defined TE (latency) > >>metrics. > > > >JD: From the draft: " In these scenarios, there is a need for the > >ingress node to > > convey the optimization criteria including the TE metrics (e.g., > >IGP metric, TE > > metric, hop counts, latency, etc.) to be used for the path > >computation to the > > node performing route computation or expansion." >=20 > John: >=20 > Some text was loose w.r.t. what is defined in the draft. So the real comm= ent > is on this sentence. Nonetheless, we can explicitly confine the scope of = the > draft to newly defined TE metrics (most important use case is latency; la= tency > variation for completeness). >=20 > Thanks >=20 > Regards...Zafar >=20 >=20 From jdrake@juniper.net Fri Aug 9 10:58:53 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F3F11E815F for ; Fri, 9 Aug 2013 10:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.584 X-Spam-Level: X-Spam-Status: No, score=-4.584 tagged_above=-999 required=5 tests=[AWL=2.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCt6AOwCjbua for ; Fri, 9 Aug 2013 10:58:47 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2417921F9D2E for ; Fri, 9 Aug 2013 10:53:49 -0700 (PDT) Received: from mail163-co9-R.bigfish.com (10.236.132.248) by CO9EHSOBE022.bigfish.com (10.236.130.85) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 17:53:48 +0000 Received: from mail163-co9 (localhost [127.0.0.1]) by mail163-co9-R.bigfish.com (Postfix) with ESMTP id 8A771C013C; Fri, 9 Aug 2013 17:53:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail163-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(51704005)(199002)(13464003)(189002)(63696002)(79102001)(51856001)(77982001)(65816001)(46102001)(80022001)(76576001)(77096001)(81342001)(59766001)(31966008)(49866001)(56816003)(74706001)(83322001)(47736001)(66066001)(81686001)(81542001)(47976001)(76796001)(74316001)(19580395003)(19580405001)(50986001)(69226001)(80976001)(54316002)(47446002)(76786001)(4396001)(33646001)(56776001)(76482001)(74662001)(74876001)(74366001)(54356001)(16406001)(83072001)(74502001)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail163-co9 (localhost.localdomain [127.0.0.1]) by mail163-co9 (MessageSwitch) id 1376070826515496_22408; Fri, 9 Aug 2013 17:53:46 +0000 (UTC) Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.235]) by mail163-co9.bigfish.com (Postfix) with ESMTP id 79A853E008F; Fri, 9 Aug 2013 17:53:46 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 17:53:45 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 17:53:43 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 17:53:41 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 17:53:41 +0000 From: John E Drake To: "Zafar Ali (zali)" , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAErlUAAAuecgAAA0JXQAAFZTAAAANkAsAAApc+AAAGc1XA= Date: Fri, 9 Aug 2013 17:53:41 +0000 Message-ID: <38627f93967f42eba4123cedeab00514@BY2PR05MB142.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:58:53 -0000 Zafar, I just don't think you understand the problem. Did you read Igor's email? Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Friday, August 09, 2013 10:39 AM > To: John E Drake; Matt Hartley (mhartley); CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 > Hi John- >=20 > Client could apply a transformation (via offline policy); it can also use= server > cost as a measure of relative cost of the connections. >=20 > Thanks >=20 > Regards ... Zafar >=20 >=20 > -----Original Message----- > From: "jdrake@juniper.net" > Date: Friday, August 9, 2013 1:34 PM > To: zali , "Matt Hartley (mhartley)" = , > "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 > >Zafar, > > > >And what normalization function does it use to turn this value, which > >is a dimensionless number which has meaning only in the context of the > >server network, into a TE metric that has meaning in the client network? > > > >Yours Irrespectively, > > > >John > > > >> -----Original Message----- > >> From: Zafar Ali (zali) [mailto:zali@cisco.com] > >> Sent: Friday, August 09, 2013 9:56 AM > >> To: John E Drake; Matt Hartley (mhartley); CCAMP (ccamp@ietf.org) > >> Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 > >> > >> John- > >> > >> Of course, client knows that the metric represents server layer cost > >>of using this connection. > >> > >> Thanks > >> > >> Regards =A9 Zafar > >> > >> > >> > >> -----Original Message----- > >> From: "jdrake@juniper.net" > >> Date: Friday, August 9, 2013 12:32 PM > >> To: zali , "Matt Hartley (mhartley)" > >>, > >> "ccamp@ietf.org" > >> Subject: RE: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 > >> > >> >Zafar, > >> > > >> >Given that a client has no idea what the TE metric it receives from > >> >the server network means, how exactly does this work? > >> > > >> >Yours Irrespectively, > >> > > >> >John > >> > > >> > >> > > > > >=20 >=20 From gregb@grotto-networking.com Fri Aug 9 11:07:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6812011E812A for ; Fri, 9 Aug 2013 11:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYReO2FWAJYl for ; Fri, 9 Aug 2013 11:07:38 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 78B5221F843F for ; Fri, 9 Aug 2013 11:01:29 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id DA39D2126495 for ; Fri, 9 Aug 2013 18:01:28 +0000 (UTC) Message-ID: <52052E76.40705@grotto-networking.com> Date: Fri, 09 Aug 2013 11:01:26 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CCAMP References: <4A1562797D64E44993C5CBF38CF1BE4812B2A0@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4812B2A0@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------080205060703050801060303" Subject: Re: [CCAMP] draft-ietf-ccamp-rwa-info - IPR declarations still missing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:07:45 -0000 This is a multi-part message in MIME format. --------------080205060703050801060303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I don't know of any IPR beyond what Young Lee may have declared. Best Regards Greg B. On 8/9/2013 7:06 AM, Daniele Ceccarelli wrote: > > Dear Authors/contributors, > > in preparation for the WG last call we still miss the IPR declarations > from the following people: > > Anders Gavler > > Jonas Martensson > > Greg Bernstein > > Imajuku Wataru > > Could you please reply on the mailing list asap? > > Many thanks > > Daniele > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------080205060703050801060303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi all, I don't know of any IPR beyond what Young Lee may have declared.
Best Regards
Greg B.
On 8/9/2013 7:06 AM, Daniele Ceccarelli wrote:

Dear Authors/contributors,

 

in preparation for the WG last call we still miss the IPR declarations from the following people:

 

Anders Gavler

Jonas Martensson

Greg Bernstein

Imajuku Wataru

 

 

Could you please reply on the mailing list asap?

 

Many thanks

Daniele

 



-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------080205060703050801060303-- From gregb@grotto-networking.com Fri Aug 9 11:10:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1BE21F9D02 for ; Fri, 9 Aug 2013 11:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoiF-8OcQrTc for ; Fri, 9 Aug 2013 11:10:13 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 05EB511E814F for ; Fri, 9 Aug 2013 11:03:06 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 74F41212654E for ; Fri, 9 Aug 2013 18:03:05 +0000 (UTC) Message-ID: <52052ED7.3080106@grotto-networking.com> Date: Fri, 09 Aug 2013 11:03:03 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CCAMP References: <4A1562797D64E44993C5CBF38CF1BE4812B2B1@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4812B2B1@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------000203050304020800070303" Subject: Re: [CCAMP] draft-ietf-ccamp-rwa-wson-encode - IPR declarations still missing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:10:22 -0000 This is a multi-part message in MIME format. --------------000203050304020800070303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee may have declared. Best Regards Greg B. On 8/9/2013 7:07 AM, Daniele Ceccarelli wrote: > > Dear Authors/contributors, > > in preparation for the WG last call we still miss the IPR declarations > from the following people: > > Anders Gavler > > Jonas Martensson > > Pierre Peloso > > Gabriele Galimberti > > Greg Bernstein > > Wataru Imajuku > > Jianrui Han > > Could you please reply on the mailing list asap? > > Many thanks > > Daniele > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------000203050304020800070303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee may have declared.
Best Regards
Greg B.
On 8/9/2013 7:07 AM, Daniele Ceccarelli wrote:

Dear Authors/contributors,

 

in preparation for the WG last call we still miss the IPR declarations from the following people:

 

Anders Gavler

Jonas Martensson

Pierre Peloso

Gabriele Galimberti

Greg Bernstein

Wataru Imajuku

Jianrui Han

 

Could you please reply on the mailing list asap?

 

Many thanks

Daniele



-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------000203050304020800070303-- From gregb@grotto-networking.com Fri Aug 9 11:11:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FB021F9ADA for ; Fri, 9 Aug 2013 11:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMSdK4rzWdHP for ; Fri, 9 Aug 2013 11:11:22 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9CC11E815E for ; Fri, 9 Aug 2013 11:03:30 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id ECDD52126559 for ; Fri, 9 Aug 2013 18:03:29 +0000 (UTC) Message-ID: <52052EEF.7010807@grotto-networking.com> Date: Fri, 09 Aug 2013 11:03:27 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CCAMP References: <4A1562797D64E44993C5CBF38CF1BE4812B2C2@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4812B2C2@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------010403080004050209090404" Subject: Re: [CCAMP] draft-ietf-ccamp-general-constraint-encode - IPR declarations still missing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:11:28 -0000 This is a multi-part message in MIME format. --------------010403080004050209090404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee may have declared. Best Regards Greg B. On 8/9/2013 7:07 AM, Daniele Ceccarelli wrote: > > Dear Authors/contributors, > > in preparation for the WG last call we still miss the IPR declarations > from the following people: > > Anders Gavler > > Jonas Matensson > > Remi Theillaud > > Greg M. Bernstein > > Wataru Imajuku > > Jianrui Han > > Could you please reply on the mailing list asap? > > Many thanks > > Daniele > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------010403080004050209090404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee may have declared.
Best Regards
Greg B.
On 8/9/2013 7:07 AM, Daniele Ceccarelli wrote:

Dear Authors/contributors,

 

in preparation for the WG last call we still miss the IPR declarations from the following people:

 

Anders Gavler

Jonas Matensson

Remi Theillaud

Greg M. Bernstein

Wataru Imajuku

Jianrui Han

 

 

Could you please reply on the mailing list asap?

 

Many thanks

Daniele

 



-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------010403080004050209090404-- From db3546@att.com Fri Aug 9 11:11:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49F711E81AD for ; Fri, 9 Aug 2013 11:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.853 X-Spam-Level: X-Spam-Status: No, score=-105.853 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Re1+O4rQahHF for ; Fri, 9 Aug 2013 11:11:28 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id CA87311E817C for ; Fri, 9 Aug 2013 11:03:38 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 9fe25025.0.1681674.00-145.4704865.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 09 Aug 2013 18:03:39 +0000 (UTC) X-MXL-Hash: 52052efb2a12b5f9-90a074097c8154f0ef97d842088ebe91442c5e54 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r79I3ajO016286; Fri, 9 Aug 2013 14:03:37 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r79I3UMQ016187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 14:03:35 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 9 Aug 2013 18:03:21 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([169.254.185.29]) with mapi id 14.02.0342.003; Fri, 9 Aug 2013 14:03:21 -0400 From: "BRUNGARD, DEBORAH A" To: "draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp Thread-Index: Ac6VKrqe1S3WHJALTP2E78hex6qYMg== Date: Fri, 9 Aug 2013 18:03:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8355F58MISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=b8MFFK6x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=seh14-D1TikA:10 a=ofMgfj31e3cA:10 a=ubG] X-AnalysisOut: [f1KvACEEA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=kIz19dg1Y1wA:10 a=48vgC7mUAAAA:8 a=NtZACVVDPvY_id] X-AnalysisOut: [1gyawA:9 a=CjuIK1q_8ugA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=O-_doWQr2yOshBC4:21] Cc: "ccamp@ietf.org" Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:11:35 -0000 --_000_F64C10EAA68C8044B33656FA214632C8355F58MISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_F64C10EAA68C8044B33656FA214632C8355F58MISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors, Contributors, (CCAMP)
 
As part of the preparation for WG Last Call:
 
Are you aware of any IPR that applies to draft identified above?
 
  Please state either:
 
  "No, I'm not aware of any IPR that applies to this draft&q= uot;
  or
  "Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?
 
   If yes to the above, please state either:
 
  "Yes, the IPR has been disclosed in compliance with IETF I= PR rules"
  or
  "No, the IPR has not been disclosed"
 
  If you answer no, please provide any additional details you thi= nk
  appropriate.
 
If you are listed as a document author or contributor please answer th= e
above by responding to this email regardless of whether or not you are=
aware of any relevant IPR.  This document will not advance to the= next
stage until a response has been received from each author and listed
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.
 
If you are on the CCAMP WG email list but are not listed as an author = or
contributor, we remind you of your obligations under the IETF IPR rule= s
which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in an= y
contribution or discussion related to your undisclosed IPR.  For = more
information, please see the RFCs listed above and
 
Thank you,
CCAMP WG Chairs
 
PS Please include all listed in the headers of this message in your
response.
 
 
 --_000_F64C10EAA68C8044B33656FA214632C8355F58MISOUT7MSGUSR9OIT_-- From gregb@grotto-networking.com Fri Aug 9 11:11:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF02521E8063 for ; Fri, 9 Aug 2013 11:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69gRLvvIxH23 for ; Fri, 9 Aug 2013 11:11:49 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D00DC21F9994 for ; Fri, 9 Aug 2013 11:04:05 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 6EAAD2126579 for ; Fri, 9 Aug 2013 18:04:05 +0000 (UTC) Message-ID: <52052F13.1020009@grotto-networking.com> Date: Fri, 09 Aug 2013 11:04:03 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CCAMP References: <4A1562797D64E44993C5CBF38CF1BE4812B2D5@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4812B2D5@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------030206060804000809030809" Subject: Re: [CCAMP] draft-ietf-ccamp-wson-signal-compatibility-ospf - IPR declarations still missing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:11:52 -0000 This is a multi-part message in MIME format. --------------030206060804000809030809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee may have declared. Best Regards Greg B. On 8/9/2013 7:08 AM, Daniele Ceccarelli wrote: > > Dear Authors/contributors, > > in preparation for the WG last call we still miss the IPR declarations > from the following people: > > Greg Bernstein > > Could you please reply on the mailing list asap? > > Many thanks > > Daniele > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------030206060804000809030809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee may have declared.
Best Regards
Greg B.
On 8/9/2013 7:08 AM, Daniele Ceccarelli wrote:

Dear Authors/contributors,

 

in preparation for the WG last call we still miss the IPR declarations from the following people:

 

Greg Bernstein

 

Could you please reply on the mailing list asap?

 

Many thanks

Daniele

 



-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------030206060804000809030809-- From gregb@grotto-networking.com Fri Aug 9 11:12:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB7621F9C13 for ; Fri, 9 Aug 2013 11:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oETjXjpjQ7hj for ; Fri, 9 Aug 2013 11:12:15 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 488B211E81A2 for ; Fri, 9 Aug 2013 11:04:31 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id D8D5721265D9 for ; Fri, 9 Aug 2013 18:04:30 +0000 (UTC) Message-ID: <52052F2C.7040805@grotto-networking.com> Date: Fri, 09 Aug 2013 11:04:28 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CCAMP References: <4A1562797D64E44993C5CBF38CF1BE4812B2E8@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4812B2E8@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------030801090207040101090303" Subject: Re: [CCAMP] draft-ietf-ccamp-wson-signaling - IPR declarations still missing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:12:21 -0000 This is a multi-part message in MIME format. --------------030801090207040101090303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee may have declared. Best Regards Greg B. On 8/9/2013 7:09 AM, Daniele Ceccarelli wrote: > > Dear Authors/contributors, > > in preparation for the WG last call we still miss the IPR declarations > from the following people: > > Greg Bernstein > > Yuefeng Ji > > Lin Guo > > Could you please reply on the mailing list asap? > > Many thanks > > Daniele > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------030801090207040101090303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee may have declared.
Best Regards
Greg B.
On 8/9/2013 7:09 AM, Daniele Ceccarelli wrote:

Dear Authors/contributors,

 

in preparation for the WG last call we still miss the IPR declarations from the following people:

 

Greg Bernstein

Yuefeng Ji

Lin Guo

 

Could you please reply on the mailing list asap?

 

Many thanks

Daniele

 



-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------030801090207040101090303-- From gregb@grotto-networking.com Fri Aug 9 11:12:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B46211E811B for ; Fri, 9 Aug 2013 11:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHbtVeXAEo0Q for ; Fri, 9 Aug 2013 11:12:41 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BC11521F9C41 for ; Fri, 9 Aug 2013 11:05:11 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 5946C21265B1 for ; Fri, 9 Aug 2013 18:05:11 +0000 (UTC) Message-ID: <52052F55.6070309@grotto-networking.com> Date: Fri, 09 Aug 2013 11:05:09 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CCAMP References: <4A1562797D64E44993C5CBF38CF1BE4812B2FD@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4812B2FD@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------020905090308030908060109" Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-general-constraints-ospf-te - IPR declarations still missing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:12:47 -0000 This is a multi-part message in MIME format. --------------020905090308030908060109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee may have declared. Best Regards Greg B. On 8/9/2013 7:09 AM, Daniele Ceccarelli wrote: > > Dear Authors/contributors, > > in preparation for the WG last call we still miss the IPR declarations > from the following people: > > Greg Bernstein > > Jianrui Han > > Yunbin Xu > > Guoying Zhang > > Ming Chen > > Yabin Ye > > Could you please reply on the mailing list asap? > > Many thanks > > Daniele > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------020905090308030908060109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee may have declared.
Best Regards
Greg B.
On 8/9/2013 7:09 AM, Daniele Ceccarelli wrote:

Dear Authors/contributors,

 

in preparation for the WG last call we still miss the IPR declarations from the following people:

 

Greg Bernstein

Jianrui Han

Yunbin Xu

Guoying Zhang

Ming Chen

Yabin Ye

 

Could you please reply on the mailing list asap?

 

Many thanks

Daniele

 



-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------020905090308030908060109-- From db3546@att.com Fri Aug 9 11:14:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D663511E80DC for ; Fri, 9 Aug 2013 11:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.226 X-Spam-Level: X-Spam-Status: No, score=-106.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5RsGtG8EdKa for ; Fri, 9 Aug 2013 11:14:02 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9A00321F8EB2 for ; Fri, 9 Aug 2013 11:07:13 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 0df25025.0.1683654.00-292.4710445.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 09 Aug 2013 18:07:13 +0000 (UTC) X-MXL-Hash: 52052fd132ab352f-c6ed61660165d8e6224cfe0bde11688a8bc907e9 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r79I7BkI019713; Fri, 9 Aug 2013 14:07:12 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r79I75Ju019699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 14:07:06 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 9 Aug 2013 18:06:44 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Fri, 9 Aug 2013 14:06:44 -0400 From: "BRUNGARD, DEBORAH A" To: "draft-ietf-ccamp-lsp-diversity@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ietf-ccamp-lsp-diversity Thread-Index: Ac6VKzMZ8xb/ji1DTkKZ/Gx8Wk3xMA== Date: Fri, 9 Aug 2013 18:06:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8355F6CMISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=b8MFFK6x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=ylEOtyi2zpgA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=51nMbOZ6S] X-AnalysisOut: [NIA:10 a=48vgC7mUAAAA:8 a=NtZACVVDPvY_id1gyawA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=O-_doWQr2yO] X-AnalysisOut: [shBC4:21] Cc: "ccamp@ietf.org" Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-lsp-diversity X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:14:07 -0000 --_000_F64C10EAA68C8044B33656FA214632C8355F6CMISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_F64C10EAA68C8044B33656FA214632C8355F6CMISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors, Contributors, (CCAMP)
 
As part of the preparation for WG Last Call:
 
Are you aware of any IPR that applies to draft identified above?
 
  Please state either:
 
  "No, I'm not aware of any IPR that applies to this draft&q= uot;
  or
  "Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?
 
   If yes to the above, please state either:
 
  "Yes, the IPR has been disclosed in compliance with IETF I= PR rules"
  or
  "No, the IPR has not been disclosed"
 
  If you answer no, please provide any additional details you thi= nk
  appropriate.
 
If you are listed as a document author or contributor please answer th= e
above by responding to this email regardless of whether or not you are=
aware of any relevant IPR.  This document will not advance to the= next
stage until a response has been received from each author and listed
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.
 
If you are on the CCAMP WG email list but are not listed as an author = or
contributor, we remind you of your obligations under the IETF IPR rule= s
which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in an= y
contribution or discussion related to your undisclosed IPR.  For = more
information, please see the RFCs listed above and
 
Thank you,
CCAMP WG Chairs
 
PS Please include all listed in the headers of this message in your
response.
 
 
 --_000_F64C10EAA68C8044B33656FA214632C8355F6CMISOUT7MSGUSR9OIT_-- From db3546@att.com Fri Aug 9 11:16:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849BB11E8168 for ; Fri, 9 Aug 2013 11:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.35 X-Spam-Level: X-Spam-Status: No, score=-106.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYiLOeTuKGYP for ; Fri, 9 Aug 2013 11:16:32 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9572021E8050 for ; Fri, 9 Aug 2013 11:11:00 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 4b035025.0.2565755.00-272.7170698.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 09 Aug 2013 18:11:00 +0000 (UTC) X-MXL-Hash: 520530b454de65ad-24a80390f6855bc0cbf8084e54d6494ac87cb346 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r79IAxQH023794; Fri, 9 Aug 2013 14:11:00 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r79IApPn023704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 14:10:51 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 9 Aug 2013 18:10:39 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([169.254.185.29]) with mapi id 14.02.0342.003; Fri, 9 Aug 2013 14:10:39 -0400 From: "BRUNGARD, DEBORAH A" To: "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-Index: Ac6VK7+mWUvlMi3uQtWQFQbgJh00TQ== Date: Fri, 9 Aug 2013 18:10:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8355F82MISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Gsn1DDJC c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=iCRO563PQ4AA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=OFmnpdCNK] X-AnalysisOut: [ywA:10 a=48vgC7mUAAAA:8 a=NtZACVVDPvY_id1gyawA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=O-_doWQr2yO] X-AnalysisOut: [shBC4:21] Cc: "ccamp@ietf.org" Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:16:38 -0000 --_000_F64C10EAA68C8044B33656FA214632C8355F82MISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_F64C10EAA68C8044B33656FA214632C8355F82MISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors, Contributors, (CCAMP)
 
As part of the preparation for WG document adoption:
 
Are you aware of any IPR that applies to draft identified above?
 
  Please state either:
 
  "No, I'm not aware of any IPR that applies to this draft&q= uot;
  or
  "Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?
 
   If yes to the above, please state either:
 
  "Yes, the IPR has been disclosed in compliance with IETF I= PR rules"
  or
  "No, the IPR has not been disclosed"
 
  If you answer no, please provide any additional details you thi= nk
  appropriate.
 
If you are listed as a document author or contributor please answer th= e
above by responding to this email regardless of whether or not you are=
aware of any relevant IPR.  This document will not advance to the= next
stage until a response has been received from each author and listed
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.
 
If you are on the CCAMP WG email list but are not listed as an author = or
contributor, we remind you of your obligations under the IETF IPR rule= s
which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in an= y
contribution or discussion related to your undisclosed IPR.  For = more
information, please see the RFCs listed above and
 
Thank you,
CCAMP WG Chairs
 
PS Please include all listed in the headers of this message in your
response.
 
 
 --_000_F64C10EAA68C8044B33656FA214632C8355F82MISOUT7MSGUSR9OIT_-- From db3546@att.com Fri Aug 9 11:24:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5878421F9F3D for ; Fri, 9 Aug 2013 11:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRgkweQ5cbbH for ; Fri, 9 Aug 2013 11:24:02 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id A70CC11E81A1 for ; Fri, 9 Aug 2013 11:16:41 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 90235025.0.1433146.00-292.4025877.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 09 Aug 2013 18:16:41 +0000 (UTC) X-MXL-Hash: 520532095ee4b500-7a40eb2668250f603c0577c1e577d27187bb68a6 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r79IGe8E029853; Fri, 9 Aug 2013 14:16:41 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r79IGZgT029785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 14:16:36 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 9 Aug 2013 18:16:22 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([169.254.21.136]) with mapi id 14.02.0342.003; Fri, 9 Aug 2013 14:16:22 -0400 From: "BRUNGARD, DEBORAH A" To: "draft-dhody-ccamp-rsvp-te-domain-subobjects@tools.ietf.org" Thread-Topic: Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects Thread-Index: Ac6VLIv04Xmy0haVR3Oh4IK1fEPtFw== Date: Fri, 9 Aug 2013 18:16:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8355FCDMISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=IuiphsDg c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=xv2sBfWs5PMA:10 a=ofMgfj31e3cA:10 a=Xrb] X-AnalysisOut: [n1SoBJ4IA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=wXOMtz7tGpAA:10 a=48vgC7mUAAAA:8 a=NtZACVVDPvY_id] X-AnalysisOut: [1gyawA:9 a=CjuIK1q_8ugA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=O-_doWQr2yOshBC4:21] Cc: "ccamp@ietf.org" Subject: [CCAMP] Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:24:08 -0000 --_000_F64C10EAA68C8044B33656FA214632C8355FCDMISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_F64C10EAA68C8044B33656FA214632C8355FCDMISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors, Contributors, (CCAMP)
 
As part of the preparation for WG document adoption:
 
Are you aware of any IPR that applies to draft identified above?
 
  Please state either:
 
  "No, I'm not aware of any IPR that applies to this draft&q= uot;
  or
  "Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?
 
   If yes to the above, please state either:
 
  "Yes, the IPR has been disclosed in compliance with IETF I= PR rules"
  or
  "No, the IPR has not been disclosed"
 
  If you answer no, please provide any additional details you thi= nk
  appropriate.
 
If you are listed as a document author or contributor please answer th= e
above by responding to this email regardless of whether or not you are=
aware of any relevant IPR.  This document will not advance to the= next
stage until a response has been received from each author and listed
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.
 
If you are on the CCAMP WG email list but are not listed as an author = or
contributor, we remind you of your obligations under the IETF IPR rule= s
which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in an= y
contribution or discussion related to your undisclosed IPR.  For = more
information, please see the RFCs listed above and
 
Thank you,
CCAMP WG Chairs
 
PS Please include all listed in the headers of this message in your
response.
 
 
 --_000_F64C10EAA68C8044B33656FA214632C8355FCDMISOUT7MSGUSR9OIT_-- From lberger@labn.net Fri Aug 9 12:12:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDF621F91CA for ; Fri, 9 Aug 2013 12:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.915 X-Spam-Level: X-Spam-Status: No, score=-101.915 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO1HbDHUw1za for ; Fri, 9 Aug 2013 12:12:09 -0700 (PDT) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id B6C4721E805F for ; Fri, 9 Aug 2013 12:03:12 -0700 (PDT) Received: (qmail 5447 invoked by uid 0); 9 Aug 2013 19:02:49 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.mail.unifiedlayer.com with SMTP; 9 Aug 2013 19:02:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yzS3XH0Q1bnFlTQlQ1/ujHhHvoroVLjrpZK7DGrbryc=; b=stj4Ytne098gunSDVIoOXywvgdH30u9wBDI2YpREnEIM5obQzRqqZnadWeOq+7X2NCqeulAkMIFw0Ulv9OCCZQ0xTrM+et+6+eXNu3blQBaoqZSmAxs2bre3/eK4ZaO1; Received: from box313.bluehost.com ([69.89.31.113]:60662 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V7rxZ-0002kg-02; Fri, 09 Aug 2013 13:02:49 -0600 Message-ID: <52053CD8.3070902@labn.net> Date: Fri, 09 Aug 2013 15:02:48 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Greg Bernstein References: <4A1562797D64E44993C5CBF38CF1BE4812B2FD@ESESSMB301.ericsson.se> <52052F55.6070309@grotto-networking.com> In-Reply-To: <52052F55.6070309@grotto-networking.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-general-constraints-ospf-te - IPR declarations still missing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 19:12:17 -0000 Greg, Your response is a bit vague. Can you respond to the original questions & thread (for all the documents)? This is particularity necessary given the past late disclosures on this topic. Thank you, Lou On 08/09/2013 02:05 PM, Greg Bernstein wrote: > Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee > may have declared. > Best Regards > Greg B. > On 8/9/2013 7:09 AM, Daniele Ceccarelli wrote: >> >> Dear Authors/contributors, >> >> >> >> in preparation for the WG last call we still miss the IPR declarations >> from the following people: >> >> >> >> Greg Bernstein >> >> Jianrui Han >> >> Yunbin Xu >> >> Guoying Zhang >> >> Ming Chen >> >> Yabin Ye >> >> >> >> Could you please reply on the mailing list asap? >> >> >> >> Many thanks >> >> Daniele >> >> >> > > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From rgandhi@cisco.com Fri Aug 9 13:13:02 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CD621F999C for ; Fri, 9 Aug 2013 13:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oll08qIjdw+r for ; Fri, 9 Aug 2013 13:12:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E5CD821F8F67 for ; Fri, 9 Aug 2013 13:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9042; q=dns/txt; s=iport; t=1376078702; x=1377288302; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=IThFFCwPp+S6wOeTabX3Lx+f4UDPFPW66k1RUsgb1QQ=; b=MxTz6baI1yN1oTmsUCY9FR7sxAMIzHBes9+Dkg3XASwixTBMoYdkUzxN 9TTOhMm81lNbuE4cg1NO1HpWNd4AucNUJ8W7vAZm4AkJxg5GJhtxbJ9TG LeYCEmROEwD2/jgkkg2ex0z4wCdyibeHuJzHotTQnnhbtjr5cUbevk3xo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAP1KBVKtJXHA/2dsb2JhbABbgkJENVCEMbFpiD2BHBZ0giQBAQEELUcFEgEIEQMBAgsdORQJCAEBBA4FCIgIDLhujmyBFQYHEw0EBwIEgxR1A5kMkCWDG4FxOQ X-IronPort-AV: E=Sophos;i="4.89,848,1367971200"; d="scan'208,217";a="245697463" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 09 Aug 2013 20:04:51 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r79K4odC005101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 20:04:51 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.69]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 15:04:50 -0500 From: "Rakesh Gandhi (rgandhi)" To: "BRUNGARD, DEBORAH A" , "draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp Thread-Index: Ac6VKrqe1S3WHJALTP2E78hex6qYMgAGVo0A Date: Fri, 9 Aug 2013 20:04:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.242.60] Content-Type: multipart/alternative; boundary="_000_B7D2A316AA32B6469D9670B6A81B7C243FA298xmbalnx07ciscocom_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "jingrq@ctbri.com.cn" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:13:02 -0000 --_000_B7D2A316AA32B6469D9670B6A81B7C243FA298xmbalnx07ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, I am a co-author of this draft. Yes, I'm aware of IPR that applies to this draft. Yes, the IPR has been disclosed in compliance with IETF IPR rules. https://datatracker.ietf.org/ipr/2139/ Thanks, Rakesh From: , DEBORAH BRUNGARD > Date: Friday, 9 August, 2013 2:03 PM To: "draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org" > Cc: CCAMP > Subject: Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-ls= p Resent-From: > Resent-To: "jingrq@ctbri.com.cn" >, Rakesh Gandhi >, "zhang.fei3@zte.com.cn= " > Resent-Date: Friday, 9 August, 2013 2:03 PM Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_B7D2A316AA32B6469D9670B6A81B7C243FA298xmbalnx07ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7066ACA9F0B4544ABE1260040502EB91@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi WG,

I am a co-author of this draft.

Yes, I'm aware of IP= R that applies to this draft.

Yes, the IPR has bee= n disclosed in compliance with IETF IPR rules.


Thanks,
Rakesh



From: <BRUNGARD>, DEBORAH BRU= NGARD <db3546@att.com>
Date: Friday, 9 August, 2013 2:03 P= M
To: "draft-ietf-ccam= p-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org" <= draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org> Cc: CCAMP <ccamp@ietf.org>
Subject: Regarding IPR on draft-iet= f-ccamp-mpls-tp-rsvpte-ext-associated-lsp
Resent-From: <draft-alias-bounces@tools.ietf.org&= gt;
Resent-To: "jingrq@ctbri.com.cn" <jingrq@ctbri.com.cn>, Rakesh Gandhi <rgandhi@cisco.com>, "zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn>=
Resent-Date: Friday, 9 August, 2013= 2:03 PM

Authors, Contributors, (CCAMP)
 
As part of the preparation for WG Last Call:
 
Are you aware of any IPR that applies to draft identified above?
 
  Please state either:
 
  "No, I'm not aware of any IPR that applies to this draft&q= uot;
  or
  "Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?
 
   If yes to the above, please state either:
 
  "Yes, the IPR has been disclosed in compliance with IETF I= PR rules"
  or
  "No, the IPR has not been disclosed"
 
  If you answer no, please provide any additional details you thi= nk
  appropriate.
 
If you are listed as a document author or contributor please answer th= e
above by responding to this email regardless of whether or not you are=
aware of any relevant IPR.  This document will not advance to the= next
stage until a response has been received from each author and listed
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.
 
If you are on the CCAMP WG email list but are not listed as an author = or
contributor, we remind you of your obligations under the IETF IPR rule= s
which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in an= y
contribution or discussion related to your undisclosed IPR.  For = more
information, please see the RFCs listed above and
 
Thank you,
CCAMP WG Chairs
 
PS Please include all listed in the headers of this message in your
response.
 
 
--_000_B7D2A316AA32B6469D9670B6A81B7C243FA298xmbalnx07ciscocom_-- From mhartley@cisco.com Fri Aug 9 13:37:09 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F661F0DB3 for ; Fri, 9 Aug 2013 13:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgHbkU9DrCUF for ; Fri, 9 Aug 2013 13:37:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1E11E81C8 for ; Fri, 9 Aug 2013 13:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4471; q=dns/txt; s=iport; t=1376080262; x=1377289862; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EZcQck6DuOOXsmPU3YYKHtxs3eBAyxYgZDxBupdZ6uY=; b=PmLm9jddX4PXZ973tW1Or/J1qr+Y+itB4hdT2P2C6HFHUe9w+E9PjcHJ HZqrZpl9B3JbS6VmGXkzkDzrTX1bzsZ2YthBGdnvsZKgq99wiUEQzXBYn VUZFRIKoboa932hZODEYtnWWOrFSIxEVchPJU3gwaSZRNGBJCiuCaw3Pt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAGdQBVKtJV2Y/2dsb2JhbABbgwY1UL5XgRwWdIIkAQEBAwEBAQE3NAsFBwQCAQgOAwQBAQsUCQcnCxQJCAEBBAENBQiIAgYMuFgEkAExBwaDFHUDqTGDG4Iq X-IronPort-AV: E=Sophos;i="4.89,848,1367971200"; d="scan'208";a="245608555" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 09 Aug 2013 20:31:00 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r79KV0cg025895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 20:31:00 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 15:30:59 -0500 From: "Matt Hartley (mhartley)" To: Igor Bryskin , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAIuwnAACK27oA== Date: Fri, 9 Aug 2013 20:30:59 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105AF282@xmb-rcd-x03.cisco.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:37:09 -0000 Igor, John, It seems that we have a simple disagreement here about whether discovering = the cost of a LSP over a server layer is any use at all. I don't agree that= it's as completely useless as you assert. While it would certainly be very hard to make much of it in the complete ab= sence of other communication between the operators of the client and server= networks, I don't think that's how things work most of the time. While the= silicon beasts that run the network may not be able to negotiate the meani= ng of "cost", the carbon-based ones that are supposed to be in charge of it= all are fully capable of doing so. At the very least there has to be an ag= reement to allow the LSP in the first place, and there's no reason why that= agreement can't cover other things, such as what costs are going to mean o= r how they should be interpreted. Granted, there will be times when this absolutely isn't the case, but I don= 't think the operators of client and server networks are always completely = at arm's length. I think this is what Zafar meant when he said it was a pol= icy matter. It seems to me that the uselessness (or usefulness) of discovering the cost= of a LSP over a server network is a decision best made by the network oper= ators, rather than a decision that should be forced onto the network operat= or by us. I'm therefore in favour of leaving it in place so that it may be = used by those who wish to. Cheers Matt > Matt, >=20 > John's point is that the costs of a TE link in a client layer are not > "something vague" or something absolute as you imply, rather, something = that > can relate said TE link to other client layer TE links, and such costs ha= ve > nothing to do with the costs of the server LSPs supporting them. Consider= the > following: > a) static client layer TE link 0; > b) client layer TE link 1 supported by a server layer LSP1 in server doma= in > 1; > c) client layer TE link 2 supported by a server layer LSP2 in server dom= ain > 2 >=20 > The point is that the costs collected for, say, LSP1 do not help in any = way > to define the costs of TE Link1 as compared to costs of TE link 0 or TE > link2; >=20 > Cheers, > Igor >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Matt Hartley (mhartley) > Sent: Friday, August 09, 2013 11:07 AM > To: John E Drake; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 > John, >=20 > The point you raise is a good one, but I don't think it has much to do wi= th > this draft. >=20 > > I think there is a basic issue with this draft, which is that the > > server network manages its own TE metrics and those metrics almost > > certainly have nothing in common with the TE metrics used in a given cl= ient > network. >=20 > So if I understand you correctly, you're just saying that "cost" is a > somewhat vague thing that may mean different things to different network > operators? This is true sometimes, but that doesn't mean it will always b= e > the case. And I think concepts such as latency and latency variation are = less > prone to this problem; when we talk about "latency", I'm reasonably sure = we > all mean the same thing. >=20 > > Given this, would it not be better to have policy in the client nodes > > that maps the characteristics of a given LSP established across the > > server network into the TE metric to be advertised with that LSP in the > client network? >=20 > Certainly that might be a good idea... but it's beyond the scope of this > draft. If you want to map the characteristics of a given LSP established > across the server network into the TE metric to be advertised with that L= SP > in the client network, you first have to know what the characteristics of= the > LSP across the server network are... and that's what this draft is for; i= t's > simply about the discovery of the information, not what you choose to do = with > it afterwards. >=20 > Cheers >=20 > Matt >=20 > > > > Yours Irrespectively, > > > > John > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From mhartley@cisco.com Fri Aug 9 13:47:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B1B21F9E31 for ; Fri, 9 Aug 2013 13:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRzjS1ylH2Ux for ; Fri, 9 Aug 2013 13:47:20 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 69C7111E80EA for ; Fri, 9 Aug 2013 13:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=723; q=dns/txt; s=iport; t=1376080824; x=1377290424; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ky0zGF2lZoHYXD+1JGkg+feED4DhOA0AksZIB4uXz3M=; b=hzVYMxMlr8kZPYIEf4NMNOezxBkIGcrgN0PEBI3VI9CETOMQcLf8mhaA yB/nLp+4HuTRdOlakXyk+yZtov7tyG6ekul4yFi4ljZ6tfc4M+hBwyYC6 bTIyIEbXudkpgIuwFAZEhId12+7a99q5Qy1ASROkppfLqWs0ym8k8/aWe g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAERSBVKtJV2Z/2dsb2JhbABbgwaBBb5XgRwWdIIkAQEBAwE6PwULAgEIIhQQMiUBAQQBDQ2IAga4ZI58gQUxB4MadQOpMYMbgXE5 X-IronPort-AV: E=Sophos;i="4.89,848,1367971200"; d="scan'208";a="245639733" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 09 Aug 2013 20:40:23 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r79KeMBq022738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 20:40:22 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 15:40:22 -0500 From: "Matt Hartley (mhartley)" To: John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAErlUAACmmzwA== Date: Fri, 9 Aug 2013 20:40:22 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105AF2C4@xmb-rcd-x03.cisco.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> <925f76c29b1a44d896e38962c33085f0@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <925f76c29b1a44d896e38962c33085f0@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:47:26 -0000 John, I think most of your mail was covered by my reply to Igor's, but one thing = that wasn't: > JD: I didn't say anything about latency, however, since you mention it, = I > think it would be far better for the clients to measure latency. If you want a truly accurate measure of what the latency is right now, then= yes. However, discovering the latency of the LSP you currently have (accor= ding to the server network) becomes much more useful once you also have oth= er tools at your disposal. In particular, you can use the discovered latenc= y to impose latency constraints on another LSP you may signal (as described= in draft-ali-ccamp-rc-objective-function-metric-bound-03). Cheers Matt From jdrake@juniper.net Fri Aug 9 13:57:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3DD11E8125 for ; Fri, 9 Aug 2013 13:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[AWL=1.813, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbUIjnfUBe9L for ; Fri, 9 Aug 2013 13:57:51 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 86C7511E8135 for ; Fri, 9 Aug 2013 13:49:55 -0700 (PDT) Received: from mail69-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 20:49:54 +0000 Received: from mail69-tx2 (localhost [127.0.0.1]) by mail69-tx2-R.bigfish.com (Postfix) with ESMTP id C2F361201F8; Fri, 9 Aug 2013 20:49:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail69-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(51704005)(13464003)(377454003)(80976001)(65816001)(59766001)(74876001)(16406001)(69226001)(83072001)(54356001)(81686001)(33646001)(53806001)(49866001)(83322001)(74662001)(31966008)(81542001)(4396001)(19580395003)(19580405001)(74316001)(51856001)(50986001)(56776001)(74366001)(56816003)(81342001)(54316002)(66066001)(47446002)(76576001)(80022001)(46102001)(77982001)(47736001)(76796001)(76482001)(77096001)(63696002)(47976001)(79102001)(74502001)(74706001)(76786001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.54; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail69-tx2 (localhost.localdomain [127.0.0.1]) by mail69-tx2 (MessageSwitch) id 1376081392538549_26303; Fri, 9 Aug 2013 20:49:52 +0000 (UTC) Received: from TX2EHSMHS013.bigfish.com (unknown [10.9.14.228]) by mail69-tx2.bigfish.com (Postfix) with ESMTP id 6B5FC3E0035; Fri, 9 Aug 2013 20:49:52 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS013.bigfish.com (10.9.99.113) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 20:49:51 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 20:49:49 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 20:49:46 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 20:49:46 +0000 From: John E Drake To: "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAErlUAACmmzwAAAgoeg Date: Fri, 9 Aug 2013 20:49:46 +0000 Message-ID: <5ae34c38de934b658c27521d26a9c91b@BY2PR05MB142.namprd05.prod.outlook.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> <925f76c29b1a44d896e38962c33085f0@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF2C4@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC105AF2C4@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:57:58 -0000 Yours Irrespectively, John > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Friday, August 09, 2013 1:40 PM > To: John E Drake; CCAMP (ccamp@ietf.org) > Cc: Matt Hartley (mhartley) > Subject: RE: draft-ietf-ccamp-te-metric-recording-02 >=20 > John, >=20 > I think most of your mail was covered by my reply to Igor's, but one thin= g that > wasn't: >=20 > > JD: I didn't say anything about latency, however, since you mention > > it, I think it would be far better for the clients to measure latency. >=20 > If you want a truly accurate measure of what the latency is right now, th= en > yes.=20 JD: Correct. > However, discovering the latency of the LSP you currently have > (according to the server network) becomes much more useful once you also > have other tools at your disposal. In particular, you can use the discove= red > latency to impose latency constraints on another LSP you may signal (as > described in draft-ali-ccamp-rc-objective-function-metric-bound-03). JD: You use the measured latency of one LSP to specify the desired latency= =20 for a subsequent LSP? If that is what you are saying then you have just ag= reed with my original point which was having the server network provide a culmul= ative estimate of an LSP's latency in the server network is not nearly as useful = as having the client measure the latency of its LSP. >=20 > Cheers >=20 > Matt >=20 From mhartley@cisco.com Fri Aug 9 14:00:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F5421F9476 for ; Fri, 9 Aug 2013 14:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsfULEPFF4s1 for ; Fri, 9 Aug 2013 14:00:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3B91C21F9C9B for ; Fri, 9 Aug 2013 13:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1605; q=dns/txt; s=iport; t=1376081591; x=1377291191; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=I7AxwgjeWTyLA2LoUVvgRqrtaHutSJfQ/bfYaIYoHpE=; b=YZ5rbOUu8k5Ft4pRFT51otqcnESTT3kbs55zQldf1FpAm8O0L4IgRvDs hAUILQsEYz65JtNmaZgtviEzcUISVFDhDjQ10/8oZGjlrHAHY1g34yCSn 4e9J9+TrfIiXee65BAL/+OrdJ9Y+3ZxHCpJ2iJ+Tvl9RsBlZf5mk2xVt5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJhVBVKtJV2b/2dsb2JhbABbgwY1UL5XgRwWdIIkAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJBycLFAkIAQEEAQ0FCIgCBgy4WwSQATEHBoMUdQOpMYMbgio X-IronPort-AV: E=Sophos;i="4.89,848,1367971200"; d="scan'208";a="245624074" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 09 Aug 2013 20:53:10 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r79KrA8O001575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 20:53:10 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 15:53:10 -0500 From: "Matt Hartley (mhartley)" To: Fatai Zhang , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACdi0mA= Date: Fri, 9 Aug 2013 20:53:09 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:00:21 -0000 Fatai, John, I don't think you can guarantee that PCE will be deployed absolutely everyw= here, or that you can guarantee the client will be permitted access to the = server PCE when it is. In those cases, this draft is useful. Cheers Matt > Hi John, >=20 > Completely agree. >=20 > I also raised this comment in front of the mic during Berlin meeting. >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > John E Drake > Sent: Friday, August 09, 2013 1:49 AM > To: CCAMP (ccamp@ietf.org) > Subject: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.tx= t >=20 > Hi, >=20 > I have a real concern with this draft because it appears to be heading us > down the road of re-inventing PCEP in RSVP signaling with the dubious > justification that it is needed in those situations in which a PCE is not > available. However, if you re-invent PCEP in RSVP signaling, then you ha= ve > effectively ensured that there are no situations in which a PCE or its > signaling equivalent are not available. >=20 > Why is this better than simply ensuring that a PCE is available in those > situations in which it is needed? >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From mhartley@cisco.com Fri Aug 9 14:04:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FC911E811F for ; Fri, 9 Aug 2013 14:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnYQPZKyeYP6 for ; Fri, 9 Aug 2013 14:04:51 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5130611E8128 for ; Fri, 9 Aug 2013 13:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1276; q=dns/txt; s=iport; t=1376081890; x=1377291490; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kzopni+DdZ6jEE5b7THP98+Loxk0jxk0i4yXSyvnkrM=; b=JjH5N/TKc9dy/9JB3vEQ6HjAYfo39lGYZ9zaxsRIUmC3mxAVxrllOE5A Oq+7dD5gKfxNAdVANlQCgdQZYTqUtDsE4ynIHKlKdr9HvSttQniwV0aFY Z2Owls1pwVS2IJChGHvuOarMtSEBMkX3v3NdvpzFPSmx83sBU4JFZmmQB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADFXBVKtJXG//2dsb2JhbABbgwaBBb5XgRwWdIIkAQEBAwE6PwULAgEIIhQQMiUBAQQBDQ2IAga4aZABMQeDGnUDqTGDG4Iq X-IronPort-AV: E=Sophos;i="4.89,848,1367971200"; d="scan'208";a="245624143" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 09 Aug 2013 20:58:10 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r79Kw9bp021585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 20:58:09 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 15:58:09 -0500 From: "Matt Hartley (mhartley)" To: John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAErlUAACmmzwAAAgoegAABbZYA= Date: Fri, 9 Aug 2013 20:58:08 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105AF366@xmb-rcd-x03.cisco.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> <925f76c29b1a44d896e38962c33085f0@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF2C4@xmb-rcd-x03.cisco.com> <5ae34c38de934b658c27521d26a9c91b@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <5ae34c38de934b658c27521d26a9c91b@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:04:57 -0000 John, > > However, discovering the latency of the LSP you currently have > > (according to the server network) becomes much more useful once you > > also have other tools at your disposal. In particular, you can use the > > discovered latency to impose latency constraints on another LSP you > > may signal (as described in draft-ali-ccamp-rc-objective-function-metri= c- > bound-03). >=20 > JD: You use the measured latency of one LSP to specify the desired laten= cy > for a subsequent LSP? =20 No. You'd use the collected latency on one LSP to specify the desired laten= cy on a subsequent one (or to give you a good idea of what specified latenc= y it might be reasonable to require). I'm being somewhat pessimistic here and assuming that there may be discrepa= ncies between the collected and measured latencies on the original LSP. Obv= iously we'd like to think there wouldn't be, but... :) Cheers Matt > If that is what you are saying then you have just > agreed with my original point which was having the server network provide= a > culmulative estimate of an LSP's latency in the server network is not nea= rly > as useful as having the client measure the latency of its LSP. >=20 > > > > Cheers > > > > Matt > > >=20 From ggrammel@juniper.net Fri Aug 9 14:10:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBCE21F9F80 for ; Fri, 9 Aug 2013 14:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-A0Oyoq9VTr for ; Fri, 9 Aug 2013 14:10:23 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id AE46C21E8063 for ; Fri, 9 Aug 2013 14:02:05 -0700 (PDT) Received: from mail115-db8-R.bigfish.com (10.174.8.242) by DB8EHSOBE035.bigfish.com (10.174.4.98) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 21:02:04 +0000 Received: from mail115-db8 (localhost [127.0.0.1]) by mail115-db8-R.bigfish.com (Postfix) with ESMTP id B07444016F; Fri, 9 Aug 2013 21:02:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail115-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=ggrammel@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(189002)(13464003)(199002)(37854004)(377454003)(53806001)(69226001)(51856001)(47446002)(83072001)(74502001)(74662001)(74876001)(54356001)(77982001)(65816001)(46102001)(59766001)(81542001)(49866001)(80022001)(4396001)(47976001)(83322001)(50986001)(33646001)(76786001)(54316002)(76576001)(31966008)(81686001)(79102001)(1941001)(74316001)(19580395003)(16406001)(76796001)(74706001)(19580385001)(19580405001)(56776001)(74366001)(80976001)(63696002)(76482001)(66066001)(76176001)(77096001)(47736001)(56816003)(81342001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB140; H:BN1PR05MB041.namprd05.prod.outlook.com; CLIP:178.239.82.32; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail115-db8 (localhost.localdomain [127.0.0.1]) by mail115-db8 (MessageSwitch) id 1376082122571967_29152; Fri, 9 Aug 2013 21:02:02 +0000 (UTC) Received: from DB8EHSMHS025.bigfish.com (unknown [10.174.8.238]) by mail115-db8.bigfish.com (Postfix) with ESMTP id 7ADEA2C0048; Fri, 9 Aug 2013 21:02:02 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS025.bigfish.com (10.174.4.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 21:02:02 +0000 Received: from BN1PR05MB140.namprd05.prod.outlook.com (10.255.205.23) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 21:02:00 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB140.namprd05.prod.outlook.com (10.255.205.23) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 21:01:58 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.216]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.216]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 21:01:58 +0000 From: Gert Grammel To: "Matt Hartley (mhartley)" , Igor Bryskin , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Thread-Index: AQHOlUOvEFcja1tdtE+PhbF+ss1Nwg== Date: Fri, 9 Aug 2013 21:01:58 +0000 Message-ID: <87c8d290bc824645a5afd0082ece8663@BN1PR05MB041.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.239.82.32] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:10:28 -0000 Matt, Let's not forget that the thread started with the question if poking with R= SVP to understand server layer TE attributes is wise to do. Now the discussion becomes whether TE information is necessary at all. That= doesn't reflect the concerns. Rather than jumping on a protocol to add a few hacks, it would be better to= define the problem space and analyze the options. -Gert ________________________________________ From: ccamp-bounces@ietf.org on behalf of Matt Har= tley (mhartley) Sent: Friday, August 09, 2013 10:30:59 PM To: Igor Bryskin; John E Drake; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Igor, John, It seems that we have a simple disagreement here about whether discovering = the cost of a LSP over a server layer is any use at all. I don't agree that= it's as completely useless as you assert. While it would certainly be very hard to make much of it in the complete ab= sence of other communication between the operators of the client and server= networks, I don't think that's how things work most of the time. While the= silicon beasts that run the network may not be able to negotiate the meani= ng of "cost", the carbon-based ones that are supposed to be in charge of it= all are fully capable of doing so. At the very least there has to be an ag= reement to allow the LSP in the first place, and there's no reason why that= agreement can't cover other things, such as what costs are going to mean o= r how they should be interpreted. Granted, there will be times when this absolutely isn't the case, but I don= 't think the operators of client and server networks are always completely = at arm's length. I think this is what Zafar meant when he said it was a pol= icy matter. It seems to me that the uselessness (or usefulness) of discovering the cost= of a LSP over a server network is a decision best made by the network oper= ators, rather than a decision that should be forced onto the network operat= or by us. I'm therefore in favour of leaving it in place so that it may be = used by those who wish to. Cheers Matt > Matt, > > John's point is that the costs of a TE link in a client layer are not > "something vague" or something absolute as you imply, rather, something = that > can relate said TE link to other client layer TE links, and such costs ha= ve > nothing to do with the costs of the server LSPs supporting them. Consider= the > following: > a) static client layer TE link 0; > b) client layer TE link 1 supported by a server layer LSP1 in server doma= in > 1; > c) client layer TE link 2 supported by a server layer LSP2 in server dom= ain > 2 > > The point is that the costs collected for, say, LSP1 do not help in any = way > to define the costs of TE Link1 as compared to costs of TE link 0 or TE > link2; > > Cheers, > Igor > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Matt Hartley (mhartley) > Sent: Friday, August 09, 2013 11:07 AM > To: John E Drake; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 > > John, > > The point you raise is a good one, but I don't think it has much to do wi= th > this draft. > > > I think there is a basic issue with this draft, which is that the > > server network manages its own TE metrics and those metrics almost > > certainly have nothing in common with the TE metrics used in a given cl= ient > network. > > So if I understand you correctly, you're just saying that "cost" is a > somewhat vague thing that may mean different things to different network > operators? This is true sometimes, but that doesn't mean it will always b= e > the case. And I think concepts such as latency and latency variation are = less > prone to this problem; when we talk about "latency", I'm reasonably sure = we > all mean the same thing. > > > Given this, would it not be better to have policy in the client nodes > > that maps the characteristics of a given LSP established across the > > server network into the TE metric to be advertised with that LSP in the > client network? > > Certainly that might be a good idea... but it's beyond the scope of this > draft. If you want to map the characteristics of a given LSP established > across the server network into the TE metric to be advertised with that L= SP > in the client network, you first have to know what the characteristics of= the > LSP across the server network are... and that's what this draft is for; i= t's > simply about the discovery of the information, not what you choose to do = with > it afterwards. > > Cheers > > Matt > > > > > Yours Irrespectively, > > > > John > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Fri Aug 9 14:17:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A5D21F9DC6 for ; Fri, 9 Aug 2013 14:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TcTq70AYJIO for ; Fri, 9 Aug 2013 14:17:22 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id E26AD21F9A16 for ; Fri, 9 Aug 2013 14:11:46 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id r79LBPjJ002413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 17:11:25 -0400 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0146.000; Fri, 9 Aug 2013 17:11:25 -0400 From: Igor Bryskin To: "Matt Hartley (mhartley)" , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAIuwnAACK27oAABUBoQ Date: Fri, 9 Aug 2013 21:11:25 +0000 Message-ID: References: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF282@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC105AF282@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-09_08:2013-08-09, 2013-08-09, 1970-01-01 signatures=0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:17:27 -0000 Martin, We (John and myself) are of a school of thought that believes a client shou= ld know what to expect from an LSP it requests from a service provider *bef= ore* the setup request is issued (e.g. through a standard virtual link adve= rtisement). Among other things this allows for the client all kinds of pre-= planning. What you and Zafar suggest is to request LSP, first, and analyze= its properties later, using a set of obscure metrics understood only by th= e provider. It is not clear, what the client can do with these metrics beca= use: a) the client may not understand them; b) the client may understand them through some other communication you ment= ioned (email?, twitter?) but don't like them. I mean, what the client is su= pposed to do in this case: try another LSP? Go to a different provider? Cheers, Igor -----Original Message----- From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]=20 Sent: Friday, August 09, 2013 4:31 PM To: Igor Bryskin; John E Drake; CCAMP (ccamp@ietf.org) Cc: Matt Hartley (mhartley) Subject: RE: draft-ietf-ccamp-te-metric-recording-02 Igor, John, It seems that we have a simple disagreement here about whether discovering = the cost of a LSP over a server layer is any use at all. I don't agree that= it's as completely useless as you assert. While it would certainly be very hard to make much of it in the complete ab= sence of other communication between the operators of the client and server= networks, I don't think that's how things work most of the time. While the= silicon beasts that run the network may not be able to negotiate the meani= ng of "cost", the carbon-based ones that are supposed to be in charge of it= all are fully capable of doing so. At the very least there has to be an ag= reement to allow the LSP in the first place, and there's no reason why that= agreement can't cover other things, such as what costs are going to mean o= r how they should be interpreted. Granted, there will be times when this absolutely isn't the case, but I don= 't think the operators of client and server networks are always completely = at arm's length. I think this is what Zafar meant when he said it was a pol= icy matter. It seems to me that the uselessness (or usefulness) of discovering the cost= of a LSP over a server network is a decision best made by the network oper= ators, rather than a decision that should be forced onto the network operat= or by us. I'm therefore in favour of leaving it in place so that it may be = used by those who wish to. Cheers Matt > Matt, >=20 > John's point is that the costs of a TE link in a client layer are not > "something vague" or something absolute as you imply, rather, something = that > can relate said TE link to other client layer TE links, and such costs ha= ve > nothing to do with the costs of the server LSPs supporting them. Consider= the > following: > a) static client layer TE link 0; > b) client layer TE link 1 supported by a server layer LSP1 in server doma= in > 1; > c) client layer TE link 2 supported by a server layer LSP2 in server dom= ain > 2 >=20 > The point is that the costs collected for, say, LSP1 do not help in any = way > to define the costs of TE Link1 as compared to costs of TE link 0 or TE > link2; >=20 > Cheers, > Igor >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Matt Hartley (mhartley) > Sent: Friday, August 09, 2013 11:07 AM > To: John E Drake; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 > John, >=20 > The point you raise is a good one, but I don't think it has much to do wi= th > this draft. >=20 > > I think there is a basic issue with this draft, which is that the > > server network manages its own TE metrics and those metrics almost > > certainly have nothing in common with the TE metrics used in a given cl= ient > network. >=20 > So if I understand you correctly, you're just saying that "cost" is a > somewhat vague thing that may mean different things to different network > operators? This is true sometimes, but that doesn't mean it will always b= e > the case. And I think concepts such as latency and latency variation are = less > prone to this problem; when we talk about "latency", I'm reasonably sure = we > all mean the same thing. >=20 > > Given this, would it not be better to have policy in the client nodes > > that maps the characteristics of a given LSP established across the > > server network into the TE metric to be advertised with that LSP in the > client network? >=20 > Certainly that might be a good idea... but it's beyond the scope of this > draft. If you want to map the characteristics of a given LSP established > across the server network into the TE metric to be advertised with that L= SP > in the client network, you first have to know what the characteristics of= the > LSP across the server network are... and that's what this draft is for; i= t's > simply about the discovery of the information, not what you choose to do = with > it afterwards. >=20 > Cheers >=20 > Matt >=20 > > > > Yours Irrespectively, > > > > John > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Fri Aug 9 14:27:18 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC43921F99D0 for ; Fri, 9 Aug 2013 14:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPBikCO9aDd6 for ; Fri, 9 Aug 2013 14:27:11 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8408E21F9D04 for ; Fri, 9 Aug 2013 14:18:15 -0700 (PDT) Received: from mail30-db9-R.bigfish.com (10.174.16.241) by DB9EHSOBE006.bigfish.com (10.174.14.69) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 21:18:14 +0000 Received: from mail30-db9 (localhost [127.0.0.1]) by mail30-db9-R.bigfish.com (Postfix) with ESMTP id 5AD73402C1; Fri, 9 Aug 2013 21:18:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail30-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(51704005)(13464003)(37854004)(377454003)(80976001)(65816001)(16406001)(74876001)(69226001)(83072001)(54356001)(81686001)(33646001)(53806001)(49866001)(83322001)(74662001)(31966008)(81542001)(4396001)(19580395003)(19580405001)(74316001)(51856001)(50986001)(56776001)(74366001)(56816003)(81342001)(54316002)(66066001)(47446002)(76576001)(80022001)(46102001)(79102001)(77982001)(47736001)(59766001)(76796001)(76482001)(77096001)(63696002)(47976001)(74502001)(76786001)(74706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.54; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail30-db9 (localhost.localdomain [127.0.0.1]) by mail30-db9 (MessageSwitch) id 1376083091916900_9899; Fri, 9 Aug 2013 21:18:11 +0000 (UTC) Received: from DB9EHSMHS019.bigfish.com (unknown [10.174.16.229]) by mail30-db9.bigfish.com (Postfix) with ESMTP id DBA4D2A004B; Fri, 9 Aug 2013 21:18:11 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS019.bigfish.com (10.174.14.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 21:18:11 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 21:18:08 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 21:18:06 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 21:18:06 +0000 From: John E Drake To: "Matt Hartley (mhartley)" , Igor Bryskin , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAIuwnAACK27oAABjshQ Date: Fri, 9 Aug 2013 21:18:05 +0000 Message-ID: <6d1d8a53a15147ad8a81a31052ea152b@BY2PR05MB142.namprd05.prod.outlook.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF282@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC105AF282@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:27:19 -0000 Yours Irrespectively, John > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Friday, August 09, 2013 1:31 PM > To: Igor Bryskin; John E Drake; CCAMP (ccamp@ietf.org) > Cc: Matt Hartley (mhartley) > Subject: RE: draft-ietf-ccamp-te-metric-recording-02 >=20 > Igor, John, >=20 > It seems that we have a simple disagreement here about whether > discovering the cost of a LSP over a server layer is any use at all. I do= n't agree > that it's as completely useless as you assert. JD: I don't think it's an assertion. There is a reason why the term 'Auto= nomous System' Is used. =20 >=20 > While it would certainly be very hard to make much of it in the complete > absence of other communication between the operators of the client and > server networks, I don't think that's how things work most of the time. W= hile > the silicon beasts that run the network may not be able to negotiate the > meaning of "cost", the carbon-based ones that are supposed to be in charg= e > of it all are fully capable of doing so. At the very least there has to b= e an > agreement to allow the LSP in the first place, and there's no reason why = that > agreement can't cover other things, such as what costs are going to mean = or > how they should be interpreted. JD: You seem to be implicitly agreeing that providing this information Is = useless unless there is an out of band mechanism that provides a context for it. = Given this, it hardly seems worth the trouble to embed TE metric accumulation in the RS= VP-TE signaling, since the out of band mechanism can provide TE metrics itself. =20 >=20 > Granted, there will be times when this absolutely isn't the case, but I d= on't > think the operators of client and server networks are always completely a= t > arm's length. I think this is what Zafar meant when he said it was a poli= cy > matter. JD: This is somewhere between speculation and assertion. >=20 > It seems to me that the uselessness (or usefulness) of discovering the co= st of > a LSP over a server network is a decision best made by the network > operators, rather than a decision that should be forced onto the network > operator by us. I'm therefore in favour of leaving it in place so that it= may be > used by those who wish to. JD: So, we are supposed to create all sorts of random protocol extensions = in the hope that someone somewhere someday will find a use for them? I have seen far too many pointless additions to RSVP-TE signaling and we ha= ve to start using some common sense. >=20 > Cheers >=20 > Matt >=20 From zali@cisco.com Fri Aug 9 14:28:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ECE21F9D28 for ; Fri, 9 Aug 2013 14:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.096 X-Spam-Level: X-Spam-Status: No, score=-10.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR5Bux-+heE5 for ; Fri, 9 Aug 2013 14:27:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EC1F811E81E3 for ; Fri, 9 Aug 2013 14:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6094; q=dns/txt; s=iport; t=1376083103; x=1377292703; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=61RmkJhrnqOItTu+u3pxgb0oaN+kgWsO3MeME4bWqtw=; b=GCgtUSPo9pmF0lUudRHlRr8aAXCARf3+cbpvhCcKtXwLtrUYlS8wADl2 gtsjYudhMvXXSCp++0mSS0s9g8G2fbeeUiYbzrbcSWDi1cfGexyUkGXCp lEzrGrUiWHdVzMCSs95iU3fHF89jkfUvg/7K+mezYnoAPdsK2smyW6da1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAN9bBVKtJV2a/2dsb2JhbABbgwY1UL5ZgRwWdIIkAQEBBAEBAWsXBgEIDgMDAQEBCx0uCxQJCAIEARIIiAgMuF0EkAEGMgIEgxR1A6kxgxuCKg X-IronPort-AV: E=Sophos;i="4.89,848,1367971200"; d="scan'208";a="245648817" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 09 Aug 2013 21:18:22 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r79LIMv3021891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 21:18:22 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 16:18:21 -0500 From: "Zafar Ali (zali)" To: Gert Grammel , "Matt Hartley (mhartley)" , Igor Bryskin , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Thread-Index: AQHOlUOvyiZvNP7VTj6v1XoohGG+n5mNcikA Date: Fri, 9 Aug 2013 21:18:20 +0000 Message-ID: In-Reply-To: <87c8d290bc824645a5afd0082ece8663@BN1PR05MB041.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.219.206] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:28:16 -0000 Hi Gert-=20 Let's not confuse/ mix inquiry with recording. The question raised here is related to "Cost recording" - for which author can take an AI and come back. Thanks Regards =8A Zafar -----Original Message----- From: Gert Grammel Date: Friday, August 9, 2013 5:01 PM To: "Matt Hartley (mhartley)" , "IBryskin@advaoptical.com" , "jdrake@juniper.net" , "ccamp@ietf.org" Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >Matt, > >Let's not forget that the thread started with the question if poking with >RSVP to understand server layer TE attributes is wise to do. >Now the discussion becomes whether TE information is necessary at all. >That doesn't reflect the concerns. > >Rather than jumping on a protocol to add a few hacks, it would be better >to define the problem space and analyze the options. > >-Gert > > > >________________________________________ >From: ccamp-bounces@ietf.org on behalf of Matt >Hartley (mhartley) >Sent: Friday, August 09, 2013 10:30:59 PM >To: Igor Bryskin; John E Drake; CCAMP (ccamp@ietf.org) >Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 > >Igor, John, > >It seems that we have a simple disagreement here about whether >discovering the cost of a LSP over a server layer is any use at all. I >don't agree that it's as completely useless as you assert. > >While it would certainly be very hard to make much of it in the complete >absence of other communication between the operators of the client and >server networks, I don't think that's how things work most of the time. >While the silicon beasts that run the network may not be able to >negotiate the meaning of "cost", the carbon-based ones that are supposed >to be in charge of it all are fully capable of doing so. At the very >least there has to be an agreement to allow the LSP in the first place, >and there's no reason why that agreement can't cover other things, such >as what costs are going to mean or how they should be interpreted. > >Granted, there will be times when this absolutely isn't the case, but I >don't think the operators of client and server networks are always >completely at arm's length. I think this is what Zafar meant when he said >it was a policy matter. > >It seems to me that the uselessness (or usefulness) of discovering the >cost of a LSP over a server network is a decision best made by the >network operators, rather than a decision that should be forced onto the >network operator by us. I'm therefore in favour of leaving it in place so >that it may be used by those who wish to. > >Cheers > >Matt > >> Matt, >> >> John's point is that the costs of a TE link in a client layer are not >> "something vague" or something absolute as you imply, rather, >>something that >> can relate said TE link to other client layer TE links, and such costs >>have >> nothing to do with the costs of the server LSPs supporting them. >>Consider the >> following: >> a) static client layer TE link 0; >> b) client layer TE link 1 supported by a server layer LSP1 in server >>domain >> 1; >> c) client layer TE link 2 supported by a server layer LSP2 in server >>domain >> 2 >> >> The point is that the costs collected for, say, LSP1 do not help in >>any way >> to define the costs of TE Link1 as compared to costs of TE link 0 or TE >> link2; >> >> Cheers, >> Igor >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>Of >> Matt Hartley (mhartley) >> Sent: Friday, August 09, 2013 11:07 AM >> To: John E Drake; CCAMP (ccamp@ietf.org) >> Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >> >> John, >> >> The point you raise is a good one, but I don't think it has much to do >>with >> this draft. >> >> > I think there is a basic issue with this draft, which is that the >> > server network manages its own TE metrics and those metrics almost >> > certainly have nothing in common with the TE metrics used in a given >>client >> network. >> >> So if I understand you correctly, you're just saying that "cost" is a >> somewhat vague thing that may mean different things to different network >> operators? This is true sometimes, but that doesn't mean it will always >>be >> the case. And I think concepts such as latency and latency variation >>are less >> prone to this problem; when we talk about "latency", I'm reasonably >>sure we >> all mean the same thing. >> >> > Given this, would it not be better to have policy in the client nodes >> > that maps the characteristics of a given LSP established across the >> > server network into the TE metric to be advertised with that LSP in >>the >> client network? >> >> Certainly that might be a good idea... but it's beyond the scope of this >> draft. If you want to map the characteristics of a given LSP established >> across the server network into the TE metric to be advertised with that >>LSP >> in the client network, you first have to know what the characteristics >>of the >> LSP across the server network are... and that's what this draft is for; >>it's >> simply about the discovery of the information, not what you choose to >>do with >> it afterwards. >> >> Cheers >> >> Matt >> >> > >> > Yours Irrespectively, >> > >> > John >> > >> > >> > _______________________________________________ >> > CCAMP mailing list >> > CCAMP@ietf.org >> > https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp > > > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Fri Aug 9 14:31:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AA011E81B5 for ; Fri, 9 Aug 2013 14:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCchqHPQfgnR for ; Fri, 9 Aug 2013 14:31:46 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id EA13C21F8F67 for ; Fri, 9 Aug 2013 14:22:46 -0700 (PDT) Received: from mail30-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 21:22:46 +0000 Received: from mail30-co1 (localhost [127.0.0.1]) by mail30-co1-R.bigfish.com (Postfix) with ESMTP id 27122D800C5; Fri, 9 Aug 2013 21:22:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail30-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(51704005)(13464003)(199002)(189002)(37854004)(33646001)(31966008)(66066001)(47446002)(74366001)(54316002)(54356001)(77982001)(81542001)(56776001)(19580405001)(80976001)(47736001)(74662001)(16406001)(50986001)(59766001)(81342001)(83072001)(65816001)(63696002)(47976001)(74316001)(19580385001)(79102001)(76482001)(4396001)(80022001)(46102001)(51856001)(77096001)(76786001)(76796001)(49866001)(69226001)(19580395003)(74876001)(74502001)(76576001)(83322001)(74706001)(81686001)(56816003)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.54; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail30-co1 (localhost.localdomain [127.0.0.1]) by mail30-co1 (MessageSwitch) id 1376083364104753_25638; Fri, 9 Aug 2013 21:22:44 +0000 (UTC) Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.250]) by mail30-co1.bigfish.com (Postfix) with ESMTP id 1464524004A; Fri, 9 Aug 2013 21:22:44 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 21:22:43 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 21:22:42 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 21:22:40 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 21:22:40 +0000 From: John E Drake To: "Matt Hartley (mhartley)" , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNW56AgAAHERA= Date: Fri, 9 Aug 2013 21:22:39 +0000 Message-ID: <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:31:52 -0000 PCEP can be deployed whenever the server network wishes to provide a path c= omputation service. What possible advantage to anyone is gained by embeddi= ng PCEP in RSVP-TE signaling?=20 Yours Irrespectively, John > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Friday, August 09, 2013 1:53 PM > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > Cc: Matt Hartley (mhartley) > Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > Fatai, John, >=20 > I don't think you can guarantee that PCE will be deployed absolutely > everywhere, or that you can guarantee the client will be permitted access= to > the server PCE when it is. In those cases, this draft is useful. >=20 > Cheers >=20 > Matt >=20 > > Hi John, > > > > Completely agree. > > > > I also raised this comment in front of the mic during Berlin meeting. > > > > > > > > Best Regards > > > > Fatai > > > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of John E Drake > > Sent: Friday, August 09, 2013 1:49 AM > > To: CCAMP (ccamp@ietf.org) > > Subject: [CCAMP] > > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt > > > > Hi, > > > > I have a real concern with this draft because it appears to be heading > > us down the road of re-inventing PCEP in RSVP signaling with the > > dubious justification that it is needed in those situations in which a > > PCE is not available. However, if you re-invent PCEP in RSVP > > signaling, then you have effectively ensured that there are no > > situations in which a PCE or its signaling equivalent are not available= . > > > > Why is this better than simply ensuring that a PCE is available in > > those situations in which it is needed? > > > > Yours Irrespectively, > > > > John > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp >=20 From IBryskin@advaoptical.com Fri Aug 9 14:34:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CC821F9C91 for ; Fri, 9 Aug 2013 14:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOEVORV+g7aN for ; Fri, 9 Aug 2013 14:34:09 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id AB29611E815B for ; Fri, 9 Aug 2013 14:28:16 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id r79LRl2h011622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 17:27:47 -0400 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0146.000; Fri, 9 Aug 2013 17:27:47 -0400 From: Igor Bryskin To: "Matt Hartley (mhartley)" , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAIuwnAACK27oAABUBoQAAFjEIA= Date: Fri, 9 Aug 2013 21:27:46 +0000 Message-ID: References: <9D50FCE7413E3D4EA5E42331115FB5BC105AD55C@xmb-rcd-x03.cisco.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF282@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-09_09:2013-08-09, 2013-08-09, 1970-01-01 signatures=0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:34:14 -0000 Matt,=20 I apologize for calling you by wrong name. Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Friday, August 09, 2013 5:11 PM To: Matt Hartley (mhartley); John E Drake; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Martin, We (John and myself) are of a school of thought that believes a client shou= ld know what to expect from an LSP it requests from a service provider *bef= ore* the setup request is issued (e.g. through a standard virtual link adve= rtisement). Among other things this allows for the client all kinds of pre-= planning. What you and Zafar suggest is to request LSP, first, and analyze= its properties later, using a set of obscure metrics understood only by th= e provider. It is not clear, what the client can do with these metrics beca= use: a) the client may not understand them; b) the client may understand them through some other communication you ment= ioned (email?, twitter?) but don't like them. I mean, what the client is su= pposed to do in this case: try another LSP? Go to a different provider? Cheers, Igor -----Original Message----- From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]=20 Sent: Friday, August 09, 2013 4:31 PM To: Igor Bryskin; John E Drake; CCAMP (ccamp@ietf.org) Cc: Matt Hartley (mhartley) Subject: RE: draft-ietf-ccamp-te-metric-recording-02 Igor, John, It seems that we have a simple disagreement here about whether discovering = the cost of a LSP over a server layer is any use at all. I don't agree that= it's as completely useless as you assert. While it would certainly be very hard to make much of it in the complete ab= sence of other communication between the operators of the client and server= networks, I don't think that's how things work most of the time. While the= silicon beasts that run the network may not be able to negotiate the meani= ng of "cost", the carbon-based ones that are supposed to be in charge of it= all are fully capable of doing so. At the very least there has to be an ag= reement to allow the LSP in the first place, and there's no reason why that= agreement can't cover other things, such as what costs are going to mean o= r how they should be interpreted. Granted, there will be times when this absolutely isn't the case, but I don= 't think the operators of client and server networks are always completely = at arm's length. I think this is what Zafar meant when he said it was a pol= icy matter. It seems to me that the uselessness (or usefulness) of discovering the cost= of a LSP over a server network is a decision best made by the network oper= ators, rather than a decision that should be forced onto the network operat= or by us. I'm therefore in favour of leaving it in place so that it may be = used by those who wish to. Cheers Matt > Matt, >=20 > John's point is that the costs of a TE link in a client layer are not > "something vague" or something absolute as you imply, rather, something = that > can relate said TE link to other client layer TE links, and such costs ha= ve > nothing to do with the costs of the server LSPs supporting them. Consider= the > following: > a) static client layer TE link 0; > b) client layer TE link 1 supported by a server layer LSP1 in server doma= in > 1; > c) client layer TE link 2 supported by a server layer LSP2 in server dom= ain > 2 >=20 > The point is that the costs collected for, say, LSP1 do not help in any = way > to define the costs of TE Link1 as compared to costs of TE link 0 or TE > link2; >=20 > Cheers, > Igor >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Matt Hartley (mhartley) > Sent: Friday, August 09, 2013 11:07 AM > To: John E Drake; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 > John, >=20 > The point you raise is a good one, but I don't think it has much to do wi= th > this draft. >=20 > > I think there is a basic issue with this draft, which is that the > > server network manages its own TE metrics and those metrics almost > > certainly have nothing in common with the TE metrics used in a given cl= ient > network. >=20 > So if I understand you correctly, you're just saying that "cost" is a > somewhat vague thing that may mean different things to different network > operators? This is true sometimes, but that doesn't mean it will always b= e > the case. And I think concepts such as latency and latency variation are = less > prone to this problem; when we talk about "latency", I'm reasonably sure = we > all mean the same thing. >=20 > > Given this, would it not be better to have policy in the client nodes > > that maps the characteristics of a given LSP established across the > > server network into the TE metric to be advertised with that LSP in the > client network? >=20 > Certainly that might be a good idea... but it's beyond the scope of this > draft. If you want to map the characteristics of a given LSP established > across the server network into the TE metric to be advertised with that L= SP > in the client network, you first have to know what the characteristics of= the > LSP across the server network are... and that's what this draft is for; i= t's > simply about the discovery of the information, not what you choose to do = with > it afterwards. >=20 > Cheers >=20 > Matt >=20 > > > > Yours Irrespectively, > > > > John > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From zali@cisco.com Fri Aug 9 14:54:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4944F21F9C78 for ; Fri, 9 Aug 2013 14:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.146 X-Spam-Level: X-Spam-Status: No, score=-10.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbQA+Sk6K1wy for ; Fri, 9 Aug 2013 14:54:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E124E11E81A9 for ; Fri, 9 Aug 2013 14:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1504; q=dns/txt; s=iport; t=1376084782; x=1377294382; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Fj5wOx4wS3eW6GPqsjieWywluJPbDM7lFxnVgMIerjw=; b=F4gn1r2pNM2SRCFaOBfIDs7+SvmhTOiJlTh+Dt/FXrFvg3w2yTNT4b9N I5F078DsvHCi5aKz+JGttlQPDxCe45AinFNpZxWRgTlU2mPXCDj+2h3s1 8npXozUPmG++Ox3ZJYRPfrKpHSp2r3wfvUHeNUXip71yL6wnKub0SM/cd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAO1iBVKtJV2d/2dsb2JhbABbgwaBBb5ZgRwWdIIkAQEBBIEFBgEIDgMDAQEBCx05FAkIAgQBEggTh3W4do5sgRUGMgaDFHUDqTGDG4FxOQ X-IronPort-AV: E=Sophos;i="4.89,848,1367971200"; d="scan'208";a="245635545" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 09 Aug 2013 21:46:07 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r79Lk78J018844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 21:46:07 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 16:46:06 -0500 From: "Zafar Ali (zali)" To: Igor Bryskin , "Matt Hartley (mhartley)" , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAIuwnAACK27oAABUBoQAAFjEIAAAs+PgA== Date: Fri, 9 Aug 2013 21:46:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.219.206] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:54:38 -0000 -----Original Message----- From: "IBryskin@advaoptical.com" Date: Friday, August 9, 2013 5:27 PM To: "Matt Hartley (mhartley)" , "jdrake@juniper.net" , "ccamp@ietf.org" Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >Matt,=20 >I apologize for calling you by wrong name. > >Igor > >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >Igor Bryskin >Sent: Friday, August 09, 2013 5:11 PM >To: Matt Hartley (mhartley); John E Drake; CCAMP (ccamp@ietf.org) >Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 > >Martin, >We (John and myself) are of a school of thought that believes a client >should know what to expect from an LSP it requests from a service >provider *before* the setup request is issued (e.g. through a standard >virtual link advertisement). Among other things this allows for the >client all kinds of pre-planning. What you and Zafar suggest is to >request LSP, first, and analyze its properties later, Igore-=20 These are building blocks and you cannot conclude on a full solution by cherry picking part of the overall solution. In another draft that we discussed via the email draft-ali-ccamp-rc-objective-function-metric-bound, we talk about client requesting metric bound (e.g., latency bound). So yes, connection requirements are driven by the clients. Thanks Regards =8A Zafar From lberger@labn.net Fri Aug 9 14:58:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E90D21F93F3 for ; Fri, 9 Aug 2013 14:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.957 X-Spam-Level: X-Spam-Status: No, score=-100.957 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftZAlPM-KTp8 for ; Fri, 9 Aug 2013 14:58:32 -0700 (PDT) Received: from oproxy5-pub.mail.unifiedlayer.com (oproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 4C07311E8149 for ; Fri, 9 Aug 2013 14:51:44 -0700 (PDT) Received: (qmail 9649 invoked by uid 0); 9 Aug 2013 21:51:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy5.mail.unifiedlayer.com with SMTP; 9 Aug 2013 21:51:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=+HchGHeg43zo/8r33CFWxLLj7oxL6snAffIuvj5Bpm0=; b=IDNsMzkWimnSPFaJfqKNcVMjRZNLui5RWWBfwdJVePOTyKEsALvm9f1v9zpaWCmWbwuwHqGRf9/biMaM+3DNydK61eQ9WLkvXT0SIuftrl1uki1sTwm6sizKNECtY2dz; Received: from box313.bluehost.com ([69.89.31.113]:33476 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V7uaU-0004Gs-8d; Fri, 09 Aug 2013 15:51:10 -0600 Message-ID: <5205644C.9080400@labn.net> Date: Fri, 09 Aug 2013 17:51:08 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John E Drake References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "CCAMP \(ccamp@ietf.org\)" Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:58:36 -0000 John, So how does a PCE *in the server layer* learn about the service parameters desired by for an LSP, e.g., desired LSP latency, signaled across a UNI? Now certainly a PCE server in the client layer is a different matter. BTW I'm not advocating any particular draft or solution in this message, I'm just trying to understand your model. I do agree that it's always best to understand what is needed/missing before jumping into discussions on solution details. Lou On 08/09/2013 05:22 PM, John E Drake wrote: > PCEP can be deployed whenever the server network wishes to provide a path computation service. What possible advantage to anyone is gained by embedding PCEP in RSVP-TE signaling? > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> Sent: Friday, August 09, 2013 1:53 PM >> To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) >> Cc: Matt Hartley (mhartley) >> Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- >> 03.txt >> >> Fatai, John, >> >> I don't think you can guarantee that PCE will be deployed absolutely >> everywhere, or that you can guarantee the client will be permitted access to >> the server PCE when it is. In those cases, this draft is useful. >> >> Cheers >> >> Matt >> >>> Hi John, >>> >>> Completely agree. >>> >>> I also raised this comment in front of the mic during Berlin meeting. >>> >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> Behalf >>> Of John E Drake >>> Sent: Friday, August 09, 2013 1:49 AM >>> To: CCAMP (ccamp@ietf.org) >>> Subject: [CCAMP] >>> draft-ali-ccamp-rc-objective-function-metric-bound-03.txt >>> >>> Hi, >>> >>> I have a real concern with this draft because it appears to be heading >>> us down the road of re-inventing PCEP in RSVP signaling with the >>> dubious justification that it is needed in those situations in which a >>> PCE is not available. However, if you re-invent PCEP in RSVP >>> signaling, then you have effectively ensured that there are no >>> situations in which a PCE or its signaling equivalent are not available. >>> >>> Why is this better than simply ensuring that a PCE is available in >>> those situations in which it is needed? >>> >>> Yours Irrespectively, >>> >>> John >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From jdrake@juniper.net Fri Aug 9 15:00:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A0E21F9C4C for ; Fri, 9 Aug 2013 15:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJF6ySO8Cfjp for ; Fri, 9 Aug 2013 15:00:39 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 816F811E81A4 for ; Fri, 9 Aug 2013 14:55:19 -0700 (PDT) Received: from mail155-db8-R.bigfish.com (10.174.8.238) by DB8EHSOBE019.bigfish.com (10.174.4.82) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 21:55:18 +0000 Received: from mail155-db8 (localhost [127.0.0.1]) by mail155-db8-R.bigfish.com (Postfix) with ESMTP id 889671202BA; Fri, 9 Aug 2013 21:55:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail155-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(377454003)(51704005)(4396001)(74706001)(81542001)(83322001)(66066001)(47736001)(76796001)(74366001)(16406001)(81686001)(63696002)(31966008)(69226001)(56776001)(19580395003)(80976001)(19580405001)(76786001)(47976001)(46102001)(51856001)(49866001)(47446002)(74662001)(74876001)(56816003)(54316002)(74316001)(65816001)(77982001)(81342001)(74502001)(76576001)(77096001)(50986001)(33646001)(54356001)(59766001)(80022001)(53806001)(79102001)(76482001)(83072001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.54; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail155-db8 (localhost.localdomain [127.0.0.1]) by mail155-db8 (MessageSwitch) id 1376085316949176_5292; Fri, 9 Aug 2013 21:55:16 +0000 (UTC) Received: from DB8EHSMHS005.bigfish.com (unknown [10.174.8.240]) by mail155-db8.bigfish.com (Postfix) with ESMTP id DA4283C0045; Fri, 9 Aug 2013 21:55:16 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS005.bigfish.com (10.174.4.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 21:55:14 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 21:55:13 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 21:55:10 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 21:55:10 +0000 From: John E Drake To: "Zafar Ali (zali)" , Igor Bryskin , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 Thread-Index: Ac6UeCOcyiZvNP7VTj6v1XoohGG+nwAmJqLQAAIuwnAACK27oAABUBoQAAFjEIAAAs+PgAAB8Img Date: Fri, 9 Aug 2013 21:55:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 22:00:47 -0000 Zafar, 'Overall solution' to what problem? Don't we normally start with requireme= nts drafts? Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Friday, August 09, 2013 2:46 PM > To: Igor Bryskin; Matt Hartley (mhartley); John E Drake; CCAMP > (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 >=20 > -----Original Message----- > From: "IBryskin@advaoptical.com" > Date: Friday, August 9, 2013 5:27 PM > To: "Matt Hartley (mhartley)" , "jdrake@juniper.net" > , "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 >=20 > >Matt, > >I apologize for calling you by wrong name. > > > >Igor > > > >-----Original Message----- > >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > >Of Igor Bryskin > >Sent: Friday, August 09, 2013 5:11 PM > >To: Matt Hartley (mhartley); John E Drake; CCAMP (ccamp@ietf.org) > >Subject: Re: [CCAMP] draft-ietf-ccamp-te-metric-recording-02 > > > >Martin, > >We (John and myself) are of a school of thought that believes a client > >should know what to expect from an LSP it requests from a service > >provider *before* the setup request is issued (e.g. through a standard > >virtual link advertisement). Among other things this allows for the > >client all kinds of pre-planning. What you and Zafar suggest is to > >request LSP, first, and analyze its properties later, >=20 > Igore- >=20 > These are building blocks and you cannot conclude on a full solution by c= herry > picking part of the overall solution. In another draft that we discussed = via the > email draft-ali-ccamp-rc-objective-function-metric-bound, we talk about > client requesting metric bound (e.g., latency bound). So yes, connection > requirements are driven by the clients. >=20 > Thanks >=20 > Regards =A9 Zafar >=20 >=20 >=20 From jdrake@juniper.net Fri Aug 9 15:10:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80ABF11E81AB for ; Fri, 9 Aug 2013 15:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.911 X-Spam-Level: X-Spam-Status: No, score=-4.911 tagged_above=-999 required=5 tests=[AWL=1.688, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcLrLe5cvwpF for ; Fri, 9 Aug 2013 15:10:22 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5C811E81A4 for ; Fri, 9 Aug 2013 15:01:39 -0700 (PDT) Received: from mail104-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE030.bigfish.com (10.236.130.93) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 22:01:37 +0000 Received: from mail104-co9 (localhost [127.0.0.1]) by mail104-co9-R.bigfish.com (Postfix) with ESMTP id 49E5210024D; Fri, 9 Aug 2013 22:01:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail104-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(479174003)(51704005)(13464003)(199002)(189002)(37854004)(24454002)(33646001)(31966008)(66066001)(47446002)(74366001)(54316002)(54356001)(77982001)(56776001)(81542001)(19580405001)(47736001)(74662001)(16406001)(50986001)(59766001)(81342001)(83072001)(65816001)(63696002)(74316001)(47976001)(80976001)(79102001)(76482001)(80022001)(4396001)(46102001)(51856001)(76796001)(77096001)(76786001)(49866001)(69226001)(74876001)(19580395003)(74502001)(19580385001)(74706001)(76576001)(83322001)(15202345003)(81686001)(56816003)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.54; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail104-co9 (localhost.localdomain [127.0.0.1]) by mail104-co9 (MessageSwitch) id 1376085695739488_13360; Fri, 9 Aug 2013 22:01:35 +0000 (UTC) Received: from CO9EHSMHS001.bigfish.com (unknown [10.236.132.245]) by mail104-co9.bigfish.com (Postfix) with ESMTP id AF89442004A; Fri, 9 Aug 2013 22:01:35 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS001.bigfish.com (10.236.130.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 22:01:35 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 22:01:34 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 22:01:31 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.57]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 22:01:31 +0000 From: John E Drake To: Lou Berger Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNW56AgAAHERCAAAkiAIAAAkaw Date: Fri, 9 Aug 2013 22:01:31 +0000 Message-ID: <988b78e813fd4815bc306dbc28f78279@BY2PR05MB142.namprd05.prod.outlook.com> References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> <5205644C.9080400@labn.net> In-Reply-To: <5205644C.9080400@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "CCAMP \(ccamp@ietf.org\)" Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 22:10:35 -0000 Lou, The last time I checked, PCE supported multi-layer path computation. Btw, = given this discussion, I found the following draft to be rather interesting= : http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ Yours Irrespectively, John > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 09, 2013 2:51 PM > To: John E Drake > Cc: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > John, > So how does a PCE *in the server layer* learn about the service > parameters desired by for an LSP, e.g., desired LSP latency, signaled acr= oss a > UNI? >=20 > Now certainly a PCE server in the client layer is a different matter. >=20 > BTW I'm not advocating any particular draft or solution in this message, = I'm > just trying to understand your model. I do agree that it's always best to > understand what is needed/missing before jumping into discussions on > solution details. >=20 > Lou >=20 > On 08/09/2013 05:22 PM, John E Drake wrote: > > PCEP can be deployed whenever the server network wishes to provide a > path computation service. What possible advantage to anyone is gained by > embedding PCEP in RSVP-TE signaling? > > > > Yours Irrespectively, > > > > John > > > >> -----Original Message----- > >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >> Sent: Friday, August 09, 2013 1:53 PM > >> To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > >> Cc: Matt Hartley (mhartley) > >> Subject: RE: [CCAMP] > >> draft-ali-ccamp-rc-objective-function-metric-bound- > >> 03.txt > >> > >> Fatai, John, > >> > >> I don't think you can guarantee that PCE will be deployed absolutely > >> everywhere, or that you can guarantee the client will be permitted > >> access to the server PCE when it is. In those cases, this draft is use= ful. > >> > >> Cheers > >> > >> Matt > >> > >>> Hi John, > >>> > >>> Completely agree. > >>> > >>> I also raised this comment in front of the mic during Berlin meeting. > >>> > >>> > >>> > >>> Best Regards > >>> > >>> Fatai > >>> > >>> > >>> -----Original Message----- > >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >> Behalf > >>> Of John E Drake > >>> Sent: Friday, August 09, 2013 1:49 AM > >>> To: CCAMP (ccamp@ietf.org) > >>> Subject: [CCAMP] > >>> draft-ali-ccamp-rc-objective-function-metric-bound-03.txt > >>> > >>> Hi, > >>> > >>> I have a real concern with this draft because it appears to be > >>> heading us down the road of re-inventing PCEP in RSVP signaling with > >>> the dubious justification that it is needed in those situations in > >>> which a PCE is not available. However, if you re-invent PCEP in > >>> RSVP signaling, then you have effectively ensured that there are no > >>> situations in which a PCE or its signaling equivalent are not availab= le. > >>> > >>> Why is this better than simply ensuring that a PCE is available in > >>> those situations in which it is needed? > >>> > >>> Yours Irrespectively, > >>> > >>> John > >>> > >>> > >>> _______________________________________________ > >>> CCAMP mailing list > >>> CCAMP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ccamp > >>> _______________________________________________ > >>> CCAMP mailing list > >>> CCAMP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ccamp > >> > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > >=20 >=20 From lberger@labn.net Fri Aug 9 15:25:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7C521F9ABB for ; Fri, 9 Aug 2013 15:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.919 X-Spam-Level: X-Spam-Status: No, score=-100.919 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxTggzfbt1GL for ; Fri, 9 Aug 2013 15:25:21 -0700 (PDT) Received: from oproxy5-pub.mail.unifiedlayer.com (oproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id A959111E8192 for ; Fri, 9 Aug 2013 15:16:50 -0700 (PDT) Received: (qmail 26944 invoked by uid 0); 9 Aug 2013 22:16:29 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy5.mail.unifiedlayer.com with SMTP; 9 Aug 2013 22:16:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=8J0jCQAopplvKVg8sQieQw3RyaA4b0wfRg4hxCRkMew=; b=ZCgbVp+UtSyH6lZIioOA6ruN2V1SJmfCwNMl9iQq7LCCHrNN9pCX6RT8ldoXgSqj9k3KNEfRPvB1A7nxfFZQbBqGQf17U+STIy7azljslxHwMDVRhlHrsiZzdb42cFNc; Received: from box313.bluehost.com ([69.89.31.113]:38193 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V7uyz-0004zB-0v; Fri, 09 Aug 2013 16:16:29 -0600 Message-ID: <52056A3C.2080008@labn.net> Date: Fri, 09 Aug 2013 18:16:28 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John E Drake References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> <5205644C.9080400@labn.net> <988b78e813fd4815bc306dbc28f78279@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <988b78e813fd4815bc306dbc28f78279@BY2PR05MB142.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "CCAMP \(ccamp@ietf.org\)" Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 22:25:31 -0000 X-List-Received-Date: Fri, 09 Aug 2013 22:25:31 -0000 On 08/09/2013 06:01 PM, John E Drake wrote: > Lou, > > The last time I checked, PCE supported multi-layer path computation. Sure, if the multi-layer PCE is accessible in the client domain. (or if have cooperating PCE-PCE communication.) That's what I was referring to in my 2nd paragraph. There are also PCE deployment approaches that have the PCE inaccessible from (untrusted) UNI clients/network and only accessed from the provider/server side of the UNI. > Btw, given this discussion, I found the following draft to be rather > interesting: > http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ > Agreed & the defined extensions & discussions seem reasonable (to me). Lou > Yours Irrespectively, > > John > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, August 09, 2013 2:51 PM >> To: John E Drake >> Cc: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org) >> Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- >> 03.txt >> >> John, >> So how does a PCE *in the server layer* learn about the service >> parameters desired by for an LSP, e.g., desired LSP latency, signaled across a >> UNI? >> >> Now certainly a PCE server in the client layer is a different matter. >> >> BTW I'm not advocating any particular draft or solution in this message, I'm >> just trying to understand your model. I do agree that it's always best to >> understand what is needed/missing before jumping into discussions on >> solution details. >> >> Lou >> >> On 08/09/2013 05:22 PM, John E Drake wrote: >>> PCEP can be deployed whenever the server network wishes to provide a >> path computation service. What possible advantage to anyone is gained by >> embedding PCEP in RSVP-TE signaling? >>> >>> Yours Irrespectively, >>> >>> John >>> >>>> -----Original Message----- >>>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >>>> Sent: Friday, August 09, 2013 1:53 PM >>>> To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) >>>> Cc: Matt Hartley (mhartley) >>>> Subject: RE: [CCAMP] >>>> draft-ali-ccamp-rc-objective-function-metric-bound- >>>> 03.txt >>>> >>>> Fatai, John, >>>> >>>> I don't think you can guarantee that PCE will be deployed absolutely >>>> everywhere, or that you can guarantee the client will be permitted >>>> access to the server PCE when it is. In those cases, this draft is useful. >>>> >>>> Cheers >>>> >>>> Matt >>>> >>>>> Hi John, >>>>> >>>>> Completely agree. >>>>> >>>>> I also raised this comment in front of the mic during Berlin meeting. >>>>> >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> Fatai >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf >>>>> Of John E Drake >>>>> Sent: Friday, August 09, 2013 1:49 AM >>>>> To: CCAMP (ccamp@ietf.org) >>>>> Subject: [CCAMP] >>>>> draft-ali-ccamp-rc-objective-function-metric-bound-03.txt >>>>> >>>>> Hi, >>>>> >>>>> I have a real concern with this draft because it appears to be >>>>> heading us down the road of re-inventing PCEP in RSVP signaling with >>>>> the dubious justification that it is needed in those situations in >>>>> which a PCE is not available. However, if you re-invent PCEP in >>>>> RSVP signaling, then you have effectively ensured that there are no >>>>> situations in which a PCE or its signaling equivalent are not available. >>>>> >>>>> Why is this better than simply ensuring that a PCE is available in >>>>> those situations in which it is needed? >>>>> >>>>> Yours Irrespectively, >>>>> >>>>> John >>>>> >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> >> > > > From ramon.casellas@cttc.es Sat Aug 10 01:57:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C3021F841A for ; Sat, 10 Aug 2013 01:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdqbYcUZ0vLd for ; Sat, 10 Aug 2013 01:57:43 -0700 (PDT) Received: from torres.puc.rediris.es (torres.puc.rediris.es [IPv6:2001:720:418:ca00::9]) by ietfa.amsl.com (Postfix) with ESMTP id E9C6D21F9C13 for ; Sat, 10 Aug 2013 01:53:13 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by torres.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V84ul-0003f4-2i; Sat, 10 Aug 2013 10:53:05 +0200 Received: from [192.168.0.192] (unknown [95.62.145.111]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 610BE1FD41; Sat, 10 Aug 2013 10:52:43 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <5205FF5C.60401@cttc.es> Date: Sat, 10 Aug 2013 10:52:44 +0200 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamina-Bogosity: Ham Cc: "ccamp@ietf.org" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 08:57:44 -0000 Dear all, No, I'm not aware of any IPR that applies to this draft Thanks, Ramon From ramon.casellas@cttc.es Sat Aug 10 02:05:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F9521E80A3 for ; Sat, 10 Aug 2013 02:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pLV0yqEFtgO for ; Sat, 10 Aug 2013 02:05:14 -0700 (PDT) Received: from torres.puc.rediris.es (torres.puc.rediris.es [IPv6:2001:720:418:ca00::9]) by ietfa.amsl.com (Postfix) with ESMTP id 6C99721F9B28 for ; Sat, 10 Aug 2013 02:00:13 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by torres.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V851w-0003lj-1r; Sat, 10 Aug 2013 11:00:12 +0200 Received: from [192.168.0.192] (unknown [95.62.145.111]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 8255D1FD41; Sat, 10 Aug 2013 11:00:08 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <5206011A.6030904@cttc.es> Date: Sat, 10 Aug 2013 11:00:10 +0200 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamina-Bogosity: Ham Cc: "ccamp@ietf.org" , "draft-dhody-ccamp-rsvp-te-domain-subobjects@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 09:05:15 -0000 Dear all, Yes, I'm aware of IPR that _may_ apply (*) to this draft, and Yes, the IPR has been disclosed in compliance with IETF IPR rules Please cfr. http://datatracker.ietf.org/ipr/1690/ (*) the disclosure applies to Internet-Draft: "Standard Representation Of Domain Sequence"(draft-dhody-pce-pcep-domain-sequence-02) and may apply to the ccamp document, but IANAL. Thanks, Ramon From gregb@grotto-networking.com Sun Aug 11 15:07:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790ED21F9F1F for ; Sun, 11 Aug 2013 15:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHeUfGZ2m05S for ; Sun, 11 Aug 2013 15:06:54 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD1321F9FF6 for ; Sun, 11 Aug 2013 15:01:21 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 2B15B2129F6F; Sun, 11 Aug 2013 22:01:21 +0000 (UTC) Message-ID: <520809AC.6010605@grotto-networking.com> Date: Sun, 11 Aug 2013 15:01:16 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Lou Berger References: <4A1562797D64E44993C5CBF38CF1BE4812B2FD@ESESSMB301.ericsson.se> <52052F55.6070309@grotto-networking.com> <52053CD8.3070902@labn.net> In-Reply-To: <52053CD8.3070902@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-general-constraints-ospf-te - IPR declarations still missing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 22:07:01 -0000 Hi Lou and CCAMPers, all granted patents that I know of are listed at http://www.grotto-networking.com/patents.html. Huawei is the assignee for all WSON related patents that I've been involved with. I cannot speak for any applications in process due to NDA. If you need a precise break down of which patent might apply to which draft, I'll be able to get to that when I return from vacation in September. Best Regards Greg B. On 8/9/2013 12:02 PM, Lou Berger wrote: > Greg, > Your response is a bit vague. Can you respond to the original questions > & thread (for all the documents)? This is particularity necessary given > the past late disclosures on this topic. > > Thank you, > Lou > > On 08/09/2013 02:05 PM, Greg Bernstein wrote: >> Hi CCAMPer's I don't know of any IPR on this draft beyond what Young Lee >> may have declared. >> Best Regards >> Greg B. >> On 8/9/2013 7:09 AM, Daniele Ceccarelli wrote: >>> Dear Authors/contributors, >>> >>> >>> >>> in preparation for the WG last call we still miss the IPR declarations >>> from the following people: >>> >>> >>> >>> Greg Bernstein >>> >>> Jianrui Han >>> >>> Yunbin Xu >>> >>> Guoying Zhang >>> >>> Ming Chen >>> >>> Yabin Ye >>> >>> >>> >>> Could you please reply on the mailing list asap? >>> >>> >>> >>> Many thanks >>> >>> Daniele >>> >>> >>> >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From zhangfatai@huawei.com Sun Aug 11 18:00:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B1A21F9E99 for ; Sun, 11 Aug 2013 18:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.973 X-Spam-Level: X-Spam-Status: No, score=-3.973 tagged_above=-999 required=5 tests=[AWL=2.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaaOHHi58VG9 for ; Sun, 11 Aug 2013 18:00:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA8DD21F9BF3 for ; Sun, 11 Aug 2013 17:55:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVX79566; Mon, 12 Aug 2013 00:55:07 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 01:54:41 +0100 Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 01:55:04 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.01.0323.007; Mon, 12 Aug 2013 08:54:59 +0800 From: Fatai Zhang To: "BRUNGARD, DEBORAH A" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-Index: Ac6VK7+mWUvlMi3uQtWQFQbgJh00TQByr5MA Date: Mon, 12 Aug 2013 00:54:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84EE4779DSZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 01:00:41 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF84EE4779DSZXEML552MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, No, I'm not aware of any IPR that applies to this draft. Best Regards Fatai From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: Saturday, August 10, 2013 2:11 AM To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_F82A4B6D50F9464B8EBA55651F541CF84EE4779DSZXEML552MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 = ;

No, = I'm not aware of any IPR that applies to this draft.

 = ;

 = ;

 

 

Best Regards

 

Fatai

 = ;

From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]
Sent: Saturday, August 10, 2013 2:11 AM
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk

 

Authors, Contributors, (= CCAMP)

 =

As part of the preparati= on for WG document adoption:

 =

Are you aware of any IPR= that applies to draft identified above?

 =

  Please state eith= er:

 =

  "No, I'm not= aware of any IPR that applies to this draft"

  or

  "Yes, I'm aw= are of IPR that applies to this draft"

 =

If so, has this IPR been= disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 36= 69 and 5378 for more details)?

 =

   If yes to t= he above, please state either:

 =

  "Yes, the IP= R has been disclosed in compliance with IETF IPR rules"

  or

  "No, the IPR= has not been disclosed"

 =

  If you answer no,= please provide any additional details you think

  appropriate.=

 =

If you are listed as a d= ocument author or contributor please answer the

above by responding to t= his email regardless of whether or not you are

aware of any relevant IP= R.  This document will not advance to the next

stage until a response h= as been received from each author and listed

contributor.  NOTE:= THIS APPLIES TO ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.=

 =

If you are on the CCAMP = WG email list but are not listed as an author or

contributor, we remind y= ou of your obligations under the IETF IPR rules

which encourages you to = notify the IETF if you are aware of IPR of

others on an IETF contri= bution, or to refrain from participating in any

contribution or discussi= on related to your undisclosed IPR.  For more

information, please see = the RFCs listed above and

 =

Thank you,

CCAMP WG Chairs

 =

PS Please include all li= sted in the headers of this message in your

response.

 =

 =

--_000_F82A4B6D50F9464B8EBA55651F541CF84EE4779DSZXEML552MBXchi_-- From fu.xihua@zte.com.cn Sun Aug 11 18:12:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8188921E8094 for ; Sun, 11 Aug 2013 18:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5OVhWbLANov for ; Sun, 11 Aug 2013 18:12:11 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E944521F9D8A for ; Sun, 11 Aug 2013 18:04:01 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 49D929011F for ; Mon, 12 Aug 2013 09:03:32 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 4C32B714823; Mon, 12 Aug 2013 09:03:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r7C13Hwq003112; Mon, 12 Aug 2013 09:03:17 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) To: db3546@att.com, daniele.ceccarelli@ericsson.com, ihussain@infinera.com, ogondio@tid.es, ramon.casellas@cttc.es, zhangfatai@huawei.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Mon, 12 Aug 2013 09:02:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-08-12 09:03:17, Serialize complete at 2013-08-12 09:03:17 Content-Type: multipart/alternative; boundary="=_alternative 0005D31C48257BC5_=" X-MAIL: mse02.zte.com.cn r7C13Hwq003112 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 01:12:30 -0000 This is a multipart message in MIME format. --=_alternative 0005D31C48257BC5_= Content-Type: text/plain; charset="US-ASCII" No, I'm not aware of any IPR that applies to this draft From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: Saturday, August 10, 2013 2:11 AM To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --=_alternative 0005D31C48257BC5_= Content-Type: text/html; charset="US-ASCII"
No, I'm not aware of any IPR that applies to this draft


From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]
Sent: Saturday, August 10, 2013 2:11 AM
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk
 
Authors, Contributors, (CCAMP)
 
As part of the preparation for WG document adoption:
 
Are you aware of any IPR that applies to draft identified above?
 
  Please state either:
 
  "No, I'm not aware of any IPR that applies to this draft"
  or
  "Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?
 
   If yes to the above, please state either:
 
  "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
  or
  "No, the IPR has not been disclosed"
 
  If you answer no, please provide any additional details you think
  appropriate.
 
If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR.  This document will not advance to the next
stage until a response has been received from each author and listed
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.
 
If you are on the CCAMP WG email list but are not listed as an author or
contributor, we remind you of your obligations under the IETF IPR rules
which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in any
contribution or discussion related to your undisclosed IPR.  For more
information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
 
Thank you,
CCAMP WG Chairs
 
PS Please include all listed in the headers of this message in your
response. --=_alternative 0005D31C48257BC5_=-- From remi.theillaud@marben-products.com Sun Aug 11 23:22:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FC721E8084 for ; Sun, 11 Aug 2013 23:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztkNW36xDeC9 for ; Sun, 11 Aug 2013 23:22:05 -0700 (PDT) Received: from srv91.mysmtp.fr (srv91.mysmtp.fr [78.41.233.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1619021F992B for ; Sun, 11 Aug 2013 23:12:13 -0700 (PDT) Received: (qmail 15366 invoked by uid 89); 12 Aug 2013 06:14:39 -0000 Received: from unknown (HELO ?192.168.7.143?) (user640@mysmtp.fr@86.65.15.130) by 0 with ESMTPA; 12 Aug 2013 06:14:39 -0000 Message-ID: <52087CA9.5060603@marben-products.com> Date: Mon, 12 Aug 2013 08:11:53 +0200 From: Remi Theillaud User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Anders Gavler , Lou Berger , "diego.caviglia@ericsson.com" , =?ISO-8859-1?Q?Jonas_M=E5rtensson?= , "i-nishioka@cb.jp.nec.com" , "rrao@infinera.com" , "giomarti@cisco.com" , "gregb@grotto-networking.com" , "ylee@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" References: <51E83C33.7010802@labn.net> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070009030408070309070406" Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 06:22:12 -0000 This is a multi-part message in MIME format. --------------070009030408070309070406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I'm not aware of any IPR that applies to this draft. Remi -------- Original Message -------- Subject: Re: Regarding IPR on draft-ietf-ccamp-general-constraint-encode From: Anders Gavler To: Lou Berger , diego.caviglia@ericsson.com , Jonas Mårtensson , i-nishioka@cb.jp.nec.com , rrao@infinera.com , giomarti@cisco.com , Rémi Theillaud , gregb@grotto-networking.com , ylee@huawei.com , danli@huawei.com , imajuku.wataru@lab.ntt.co.jp , hanjianrui@huawei.com CC: "ccamp@ietf.org" Date: 09/08/2013 17:06 > No, I'm not aware of any IPR that applies to this draft. > /Anders > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: den 18 juli 2013 21:04 > To: diego.caviglia@ericsson.com; Anders Gavler; Jonas Mårtensson; i-nishioka@cb.jp.nec.com; rrao@infinera.com; giomarti@cisco.com; remi.theillaud@marben-products.com; gregb@grotto-networking.com; ylee@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp; hanjianrui@huawei.com > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-general-constraint-encode > > Authors, Contributors, (CCAMP) > > As part of the preparation for WG Last Call: > > Are you aware of any IPR that applies to draft identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE'S TO LINES. > > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > CCAMP WG Chairs > > PS Please include all listed in the headers of this message in your > response. > . > --------------070009030408070309070406 Content-Type: text/x-vcard; charset=utf-8; name="remi_theillaud.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="remi_theillaud.vcf" begin:vcard fn:Remi Theillaud n:Theillaud;Remi org:Marben Products adr:;;176 rue Jean Jaures;Puteaux;;92800;France email;internet:remi.theillaud@marben-products.com tel;work:+33 1 79 62 10 22 tel;fax:+33 1 79 62 10 01 x-mozilla-html:TRUE version:2.1 end:vcard --------------070009030408070309070406-- From gyzhang@sina.com Sun Aug 11 23:54:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAF321F847C for ; Sun, 11 Aug 2013 23:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.199 X-Spam-Level: * X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, FR_IMPORT_CSS=1.889, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gfayHATjVL9 for ; Sun, 11 Aug 2013 23:54:25 -0700 (PDT) Received: from smtp2911-208.mail.sina.com.cn (mail2-155.sinamail.sina.com.cn [60.28.2.155]) by ietfa.amsl.com (Postfix) with SMTP id B859E21F9C2E for ; Sun, 11 Aug 2013 23:43:59 -0700 (PDT) Received: from unknown( HELO X220)([211.157.163.39]) by sina.com with ESMTP 12 Aug 2013 14:43:56 +0800 (CST) X-Sender: gyzhang@sina.com X-Auth-ID: gyzhang@sina.com X-SMAIL-MID: 59848813001842 Date: Mon, 12 Aug 2013 14:43:54 +0800 From: "=?utf-8?B?Z3l6aGFuZw==?=" To: "=?utf-8?B?TG91IEJlcmdlcg==?=" , "=?utf-8?B?ZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29t?=" , "=?utf-8?B?Sm9uYXNfTemMvHRlbnNzb24=?=" , "=?utf-8?B?aS1uaXNoaW9rYUBjYi5qcC5uZWMuY29t?=" , "=?utf-8?B?cnJhb0BpbmZpbmVyYS5jb20=?=" , "=?utf-8?B?Z2lvbWFydGlAY2lzY28uY29t?=" , "=?utf-8?B?cmVtaS50aGVpbGxhdWRAbWFyYmVuLXByb2R1Y3RzLmNvbQ==?=" , "=?utf-8?B?Z3JlZ2JAZ3JvdHRvLW5ldHdvcmtpbmcuY29t?=" , "=?utf-8?B?eWxlZUBodWF3ZWkuY29t?=" , "=?utf-8?B?QW5kZXJzIEdhdmxlcg==?=" , "=?utf-8?B?ZGFubGlAaHVhd2VpLmNvbQ==?=" , "=?utf-8?B?aW1hanVrdS53YXRhcnVAbGFiLm50dC5jby5qcA==?=" , "=?utf-8?B?aGFuamlhbnJ1aUBodWF3ZWkuY29t?=" References: <51E83C33.7010802@labn.net>, Message-ID: <201308121443537948276@sina.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon836487760148_=====" Cc: =?utf-8?B?Y2NhbXBAaWV0Zi5vcmc=?= Subject: Re: [CCAMP] =?utf-8?q?Regarding_IPR_ondraft-ietf-ccamp-general-constr?= =?utf-8?q?aint-encode?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 06:54:30 -0000 This is a multi-part message in MIME format. --=====003_Dragon836487760148_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N Cg0KR3VveWluZw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3UgQmVy Z2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiBkZW4gMTgganVsaSAyMDEzIDIx OjA0DQpUbzogZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29tOyBBbmRlcnMgR2F2bGVyOyBKb25h cyBNw6VydGVuc3NvbjsgaS1uaXNoaW9rYUBjYi5qcC5uZWMuY29tOyBycmFvQGluZmluZXJhLmNv bTsgZ2lvbWFydGlAY2lzY28uY29tOyByZW1pLnRoZWlsbGF1ZEBtYXJiZW4tcHJvZHVjdHMuY29t OyBncmVnYkBncm90dG8tbmV0d29ya2luZy5jb207IHlsZWVAaHVhd2VpLmNvbTsgZGFubGlAaHVh d2VpLmNvbTsgaW1hanVrdS53YXRhcnVAbGFiLm50dC5jby5qcDsgaGFuamlhbnJ1aUBodWF3ZWku Y29tDQpDYzogY2NhbXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQt aWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlDQpBdXRob3JzLCBDb250cmlidXRv cnMsIChDQ0FNUCkNCkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGw6 DQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZp ZWQgYWJvdmU/DQogIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQogICJObywgSSdtIG5vdCBhd2FyZSBv ZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KICBvcg0KICAiWWVzLCBJJ20g YXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KSWYgc28sIGhhcyB0aGlz IElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCihz ZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KICAg SWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCiAgIlllcywgdGhlIElQ UiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0K ICBvcg0KICAiTm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCINCiAgSWYgeW91IGFu c3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsN CiAgYXBwcm9wcmlhdGUuDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBv ciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0 aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZQ0KYXdhcmUgb2Yg YW55IHJlbGV2YW50IElQUi4gIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUg bmV4dA0Kc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2gg YXV0aG9yIGFuZCBsaXN0ZWQNCmNvbnRyaWJ1dG9yLiAgTk9URTogVEhJUyBBUFBMSUVTIFRPIEFM TCBPRiBZT1UgTElTVEVEIElOIFRISVMNCk1FU1NBR0UnUyBUTyBMSU5FUy4NCklmIHlvdSBhcmUg b24gdGhlIENDQU1QIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhv ciBvcg0KY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRl ciB0aGUgSUVURiBJUFIgcnVsZXMNCndoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUg SUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZg0Kb3RoZXJzIG9uIGFuIElFVEYgY29udHJp YnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkNCmNvbnRyaWJ1 dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuICBGb3Ig bW9yZQ0KaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZA0K aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0 dWFsUHJvcGVydHkuDQpUaGFuayB5b3UsDQpDQ0FNUCBXRyBDaGFpcnMNClBTIFBsZWFzZSBpbmNs dWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXINCnJl c3BvbnNlLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== --=====003_Dragon836487760148_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+QGltcG9ydCB1cmwo IEM6XFVzZXJzXHpoYW5nZ3VveWluZ1xBcHBEYXRhXExvY2FsXE1pY3Jvc29mdFxXaW5kb3dzXFRl bXBvcmFyeSBJbnRlcm5ldCBGaWxlc1xzY3JvbGxiYXIuY3NzICk7DQo8L1NUWUxFPg0KDQo8U1RZ TEUgdHlwZT10ZXh0L2Nzcz5AaW1wb3J0IHVybCggQzpcVXNlcnNcemhhbmdndW95aW5nXEFwcERh dGFcTG9jYWxcTWljcm9zb2Z0XFdpbmRvd3NcVGVtcG9yYXJ5IEludGVybmV0IEZpbGVzXHNjcm9s bGJhci5jc3MgKTsNCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD1VVEYtOCIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBj b250ZW50PSJNU0hUTUwgMTAuMDAuOTIwMC4xNjYzNSI+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJ Zm9udC1mYW1pbHk6IOWui+S9kzsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJk YW5hOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDlrovkvZM7DQp9DQpAcGFnZSBT ZWN0aW9uMSB7c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIu MHB0IDkwLjBwdDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCUZPTlQt U0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046 IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dy YXBoDQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTog IlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoDQp9DQpESVYuTXNvTm9ybWFsIHsNCglG T05ULVNJWkU6IDEwLjVwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFM SUdOOiBqdXN0aWZ5OyBNQVJHSU46IDBjbSAwY20gMHB0OyBURVhULUpVU1RJRlk6IGludGVyLWlk ZW9ncmFwaA0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFU SU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNP UkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9S OiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUx NyB7DQoJRk9OVC1GQU1JTFk6IFZlcmRhbmE7IEZPTlQtV0VJR0hUOiBub3JtYWw7IENPTE9SOiB3 aW5kb3d0ZXh0OyBGT05ULVNUWUxFOiBub3JtYWw7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNv LXN0eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTog U2VjdGlvbjENCn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7 DQoJTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtOyBNQVJHSU4tVE9QOiAwcHgN Cn0NCk9MIHsNCglNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweA0KfQ0KVUwgew0K CU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0K PERJVj5ObywmbmJzcDtJJ20mbmJzcDtub3QmbmJzcDthd2FyZSZuYnNwO29mJm5ic3A7YW55Jm5i c3A7SVBSJm5ic3A7dGhhdCZuYnNwO2FwcGxpZXMmbmJzcDt0byZuYnNwO3RoaXMmbmJzcDtkcmFm dC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkd1b3lpbmc8L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBj b2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj4NCjxESVY+PC9ESVY+LS0tLS1PcmlnaW5hbCZuYnNwO01lc3NhZ2UtLS0tLTwvRElWPg0KPERJ Vj4NCjxESVY+RnJvbTombmJzcDtMb3UmbmJzcDtCZXJnZXImbmJzcDtbbWFpbHRvOmxiZXJnZXJA bGFibi5uZXRdJm5ic3A7PC9ESVY+DQo8RElWPlNlbnQ6Jm5ic3A7ZGVuJm5ic3A7MTgmbmJzcDtq dWxpJm5ic3A7MjAxMyZuYnNwOzIxOjA0PC9ESVY+DQo8RElWPlRvOiZuYnNwO2RpZWdvLmNhdmln bGlhQGVyaWNzc29uLmNvbTsmbmJzcDtBbmRlcnMmbmJzcDtHYXZsZXI7Jm5ic3A7Sm9uYXMmbmJz cDtNw6VydGVuc3NvbjsmbmJzcDtpLW5pc2hpb2thQGNiLmpwLm5lYy5jb207Jm5ic3A7cnJhb0Bp bmZpbmVyYS5jb207Jm5ic3A7Z2lvbWFydGlAY2lzY28uY29tOyZuYnNwO3JlbWkudGhlaWxsYXVk QG1hcmJlbi1wcm9kdWN0cy5jb207Jm5ic3A7Z3JlZ2JAZ3JvdHRvLW5ldHdvcmtpbmcuY29tOyZu YnNwO3lsZWVAaHVhd2VpLmNvbTsmbmJzcDtkYW5saUBodWF3ZWkuY29tOyZuYnNwO2ltYWp1a3Uu d2F0YXJ1QGxhYi5udHQuY28uanA7Jm5ic3A7aGFuamlhbnJ1aUBodWF3ZWkuY29tPC9ESVY+DQo8 RElWPkNjOiZuYnNwO2NjYW1wQGlldGYub3JnPC9ESVY+DQo8RElWPlN1YmplY3Q6Jm5ic3A7UmVn YXJkaW5nJm5ic3A7SVBSJm5ic3A7b24mbmJzcDtkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29u c3RyYWludC1lbmNvZGU8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkF1dGhvcnMsJm5ic3A7Q29u dHJpYnV0b3JzLCZuYnNwOyhDQ0FNUCk8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkFzJm5ic3A7 cGFydCZuYnNwO29mJm5ic3A7dGhlJm5ic3A7cHJlcGFyYXRpb24mbmJzcDtmb3ImbmJzcDtXRyZu YnNwO0xhc3QmbmJzcDtDYWxsOjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+QXJlJm5ic3A7eW91 Jm5ic3A7YXdhcmUmbmJzcDtvZiZuYnNwO2FueSZuYnNwO0lQUiZuYnNwO3RoYXQmbmJzcDthcHBs aWVzJm5ic3A7dG8mbmJzcDtkcmFmdCZuYnNwO2lkZW50aWZpZWQmbmJzcDthYm92ZT88L0RJVj4N CjxESVY+PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwO1BsZWFzZSZuYnNwO3N0YXRlJm5ic3A7ZWl0 aGVyOjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Ik5vLCZuYnNwO0knbSZu YnNwO25vdCZuYnNwO2F3YXJlJm5ic3A7b2YmbmJzcDthbnkmbmJzcDtJUFImbmJzcDt0aGF0Jm5i c3A7YXBwbGllcyZuYnNwO3RvJm5ic3A7dGhpcyZuYnNwO2RyYWZ0IjwvRElWPg0KPERJVj4mbmJz cDsmbmJzcDtvcjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsiWWVzLCZuYnNwO0knbSZuYnNwO2F3 YXJlJm5ic3A7b2YmbmJzcDtJUFImbmJzcDt0aGF0Jm5ic3A7YXBwbGllcyZuYnNwO3RvJm5ic3A7 dGhpcyZuYnNwO2RyYWZ0IjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+SWYmbmJzcDtzbywmbmJz cDtoYXMmbmJzcDt0aGlzJm5ic3A7SVBSJm5ic3A7YmVlbiZuYnNwO2Rpc2Nsb3NlZCZuYnNwO2lu Jm5ic3A7Y29tcGxpYW5jZSZuYnNwO3dpdGgmbmJzcDtJRVRGJm5ic3A7SVBSJm5ic3A7cnVsZXM8 L0RJVj4NCjxESVY+KHNlZSZuYnNwO1JGQ3MmbmJzcDszOTc5LCZuYnNwOzQ4NzksJm5ic3A7MzY2 OSZuYnNwO2FuZCZuYnNwOzUzNzgmbmJzcDtmb3ImbmJzcDttb3JlJm5ic3A7ZGV0YWlscyk/PC9E SVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtJZiZuYnNwO3llcyZuYnNw O3RvJm5ic3A7dGhlJm5ic3A7YWJvdmUsJm5ic3A7cGxlYXNlJm5ic3A7c3RhdGUmbmJzcDtlaXRo ZXI6PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsiWWVzLCZuYnNwO3RoZSZu YnNwO0lQUiZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtkaXNjbG9zZWQmbmJzcDtpbiZuYnNwO2Nv bXBsaWFuY2UmbmJzcDt3aXRoJm5ic3A7SUVURiZuYnNwO0lQUiZuYnNwO3J1bGVzIjwvRElWPg0K PERJVj4mbmJzcDsmbmJzcDtvcjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsiTm8sJm5ic3A7dGhl Jm5ic3A7SVBSJm5ic3A7aGFzJm5ic3A7bm90Jm5ic3A7YmVlbiZuYnNwO2Rpc2Nsb3NlZCI8L0RJ Vj4NCjxESVY+PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7YW5zd2Vy Jm5ic3A7bm8sJm5ic3A7cGxlYXNlJm5ic3A7cHJvdmlkZSZuYnNwO2FueSZuYnNwO2FkZGl0aW9u YWwmbmJzcDtkZXRhaWxzJm5ic3A7eW91Jm5ic3A7dGhpbms8L0RJVj4NCjxESVY+Jm5ic3A7Jm5i c3A7YXBwcm9wcmlhdGUuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5JZiZuYnNwO3lvdSZuYnNw O2FyZSZuYnNwO2xpc3RlZCZuYnNwO2FzJm5ic3A7YSZuYnNwO2RvY3VtZW50Jm5ic3A7YXV0aG9y Jm5ic3A7b3ImbmJzcDtjb250cmlidXRvciZuYnNwO3BsZWFzZSZuYnNwO2Fuc3dlciZuYnNwO3Ro ZTwvRElWPg0KPERJVj5hYm92ZSZuYnNwO2J5Jm5ic3A7cmVzcG9uZGluZyZuYnNwO3RvJm5ic3A7 dGhpcyZuYnNwO2VtYWlsJm5ic3A7cmVnYXJkbGVzcyZuYnNwO29mJm5ic3A7d2hldGhlciZuYnNw O29yJm5ic3A7bm90Jm5ic3A7eW91Jm5ic3A7YXJlPC9ESVY+DQo8RElWPmF3YXJlJm5ic3A7b2Ym bmJzcDthbnkmbmJzcDtyZWxldmFudCZuYnNwO0lQUi4mbmJzcDsmbmJzcDtUaGlzJm5ic3A7ZG9j dW1lbnQmbmJzcDt3aWxsJm5ic3A7bm90Jm5ic3A7YWR2YW5jZSZuYnNwO3RvJm5ic3A7dGhlJm5i c3A7bmV4dDwvRElWPg0KPERJVj5zdGFnZSZuYnNwO3VudGlsJm5ic3A7YSZuYnNwO3Jlc3BvbnNl Jm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3JlY2VpdmVkJm5ic3A7ZnJvbSZuYnNwO2VhY2gmbmJz cDthdXRob3ImbmJzcDthbmQmbmJzcDtsaXN0ZWQ8L0RJVj4NCjxESVY+Y29udHJpYnV0b3IuJm5i c3A7Jm5ic3A7Tk9URTombmJzcDtUSElTJm5ic3A7QVBQTElFUyZuYnNwO1RPJm5ic3A7QUxMJm5i c3A7T0YmbmJzcDtZT1UmbmJzcDtMSVNURUQmbmJzcDtJTiZuYnNwO1RISVM8L0RJVj4NCjxESVY+ TUVTU0FHRSdTJm5ic3A7VE8mbmJzcDtMSU5FUy48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPklm Jm5ic3A7eW91Jm5ic3A7YXJlJm5ic3A7b24mbmJzcDt0aGUmbmJzcDtDQ0FNUCZuYnNwO1dHJm5i c3A7ZW1haWwmbmJzcDtsaXN0Jm5ic3A7YnV0Jm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7bGlzdGVk Jm5ic3A7YXMmbmJzcDthbiZuYnNwO2F1dGhvciZuYnNwO29yPC9ESVY+DQo8RElWPmNvbnRyaWJ1 dG9yLCZuYnNwO3dlJm5ic3A7cmVtaW5kJm5ic3A7eW91Jm5ic3A7b2YmbmJzcDt5b3VyJm5ic3A7 b2JsaWdhdGlvbnMmbmJzcDt1bmRlciZuYnNwO3RoZSZuYnNwO0lFVEYmbmJzcDtJUFImbmJzcDty dWxlczwvRElWPg0KPERJVj53aGljaCZuYnNwO2VuY291cmFnZXMmbmJzcDt5b3UmbmJzcDt0byZu YnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO0lFVEYmbmJzcDtpZiZuYnNwO3lvdSZuYnNwO2FyZSZu YnNwO2F3YXJlJm5ic3A7b2YmbmJzcDtJUFImbmJzcDtvZjwvRElWPg0KPERJVj5vdGhlcnMmbmJz cDtvbiZuYnNwO2FuJm5ic3A7SUVURiZuYnNwO2NvbnRyaWJ1dGlvbiwmbmJzcDtvciZuYnNwO3Rv Jm5ic3A7cmVmcmFpbiZuYnNwO2Zyb20mbmJzcDtwYXJ0aWNpcGF0aW5nJm5ic3A7aW4mbmJzcDth bnk8L0RJVj4NCjxESVY+Y29udHJpYnV0aW9uJm5ic3A7b3ImbmJzcDtkaXNjdXNzaW9uJm5ic3A7 cmVsYXRlZCZuYnNwO3RvJm5ic3A7eW91ciZuYnNwO3VuZGlzY2xvc2VkJm5ic3A7SVBSLiZuYnNw OyZuYnNwO0ZvciZuYnNwO21vcmU8L0RJVj4NCjxESVY+aW5mb3JtYXRpb24sJm5ic3A7cGxlYXNl Jm5ic3A7c2VlJm5ic3A7dGhlJm5ic3A7UkZDcyZuYnNwO2xpc3RlZCZuYnNwO2Fib3ZlJm5ic3A7 YW5kPC9ESVY+DQo8RElWPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJh Yy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhh bmsmbmJzcDt5b3UsPC9ESVY+DQo8RElWPkNDQU1QJm5ic3A7V0cmbmJzcDtDaGFpcnM8L0RJVj4N CjxESVY+PC9ESVY+DQo8RElWPlBTJm5ic3A7UGxlYXNlJm5ic3A7aW5jbHVkZSZuYnNwO2FsbCZu YnNwO2xpc3RlZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7aGVhZGVycyZuYnNwO29mJm5ic3A7dGhp cyZuYnNwO21lc3NhZ2UmbmJzcDtpbiZuYnNwO3lvdXI8L0RJVj4NCjxESVY+cmVzcG9uc2UuPC9E SVY+DQo8RElWPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PC9ESVY+DQo8RElWPkNDQU1QJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+Q0NB TVBAaWV0Zi5vcmc8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jY2FtcDwvRElWPg0KPERJVj48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4N Cg== --=====003_Dragon836487760148_=====-- From zhang.fei3@zte.com.cn Mon Aug 12 00:17:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1F621F9FA7 for ; Mon, 12 Aug 2013 00:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I34fTb4q8q6V for ; Mon, 12 Aug 2013 00:17:02 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 879CE21F9F51 for ; Mon, 12 Aug 2013 00:03:22 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 2490897FDE for ; Mon, 12 Aug 2013 15:02:50 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 1FD25CC7ABD; Mon, 12 Aug 2013 15:02:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r7C72puI069689; Mon, 12 Aug 2013 15:02:51 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: "BRUNGARD, DEBORAH A" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 12 Aug 2013 15:02:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-08-12 15:02:52, Serialize complete at 2013-08-12 15:02:52 Content-Type: multipart/alternative; boundary="=_alternative 0026BD5048257BC5_=" X-MAIL: mse01.zte.com.cn r7C72puI069689 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org" , "jingrq@ctbri.com.cn" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 07:17:07 -0000 This is a multipart message in MIME format. --=_alternative 0026BD5048257BC5_= Content-Type: text/plain; charset="US-ASCII" Dear all We are the co-authors of this draft No, We are not aware of any IPR that applies to this draft Best regards Fan Yang, Weilian Jiang and Fei Zhang -----Original Message----- From: , DEBORAH BRUNGARD Date: Friday, 9 August, 2013 2:03 PM To: "draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org" < draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org> Cc: CCAMP Subject: Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp Resent-From: Resent-To: "jingrq@ctbri.com.cn" , Rakesh Gandhi < rgandhi@cisco.com>, "zhang.fei3@zte.com.cn" Resent-Date: Friday, 9 August, 2013 2:03 PM Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=_alternative 0026BD5048257BC5_= Content-Type: text/html; charset="US-ASCII"
Dear all

We are the co-authors of this draft
 
No, We are not aware of any IPR that applies to this draft

Best regards

Fan Yang, Weilian Jiang and Fei Zhang



-----Original Message-----
From: <BRUNGARD>, DEBORAH BRUNGARD <db3546@att.com>
Date: Friday, 9 August, 2013 2:03 PM
To: "draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org" <draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org>
Cc: CCAMP <ccamp@ietf.org>
Subject: Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp
Resent-From: <draft-alias-bounces@tools.ietf.org>
Resent-To: "jingrq@ctbri.com.cn" <jingrq@ctbri.com.cn>, Rakesh Gandhi <rgandhi@cisco.com>, "zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn>
Resent-Date: Friday, 9 August, 2013 2:03 PM

Authors, Contributors, (CCAMP)
 
As part of the preparation for WG Last Call:
 
Are you aware of any IPR that applies to draft identified above?
 
  Please state either:
 
  "No, I'm not aware of any IPR that applies to this draft"
  or
  "Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?
 
   If yes to the above, please state either:
 
  "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
  or
  "No, the IPR has not been disclosed"
 
  If you answer no, please provide any additional details you think
  appropriate.
 
If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR.  This document will not advance to the next
stage until a response has been received from each author and listed
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.
 
If you are on the CCAMP WG email list but are not listed as an author or
contributor, we remind you of your obligations under the IETF IPR rules
which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in any
contribution or discussion related to your undisclosed IPR.  For more
information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
 
Thank you,
CCAMP WG Chairs
 
PS Please include all listed in the headers of this message in your
response.
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
 --=_alternative 0026BD5048257BC5_=-- From cyril.margaria@coriant.com Mon Aug 12 04:49:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBCD21F9D65 for ; Mon, 12 Aug 2013 04:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+K4LVWavBX8 for ; Mon, 12 Aug 2013 04:49:23 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD6921F9EFE for ; Mon, 12 Aug 2013 04:21:53 -0700 (PDT) Received: from mail100-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE027.bigfish.com (10.3.207.149) with Microsoft SMTP Server id 14.1.225.22; Mon, 12 Aug 2013 11:21:51 +0000 Received: from mail100-am1 (localhost [127.0.0.1]) by mail100-am1-R.bigfish.com (Postfix) with ESMTP id 61829300137; Mon, 12 Aug 2013 11:21:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT004.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic89bhc85dh31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah18c673h1c8fb4h1de096h8275dh1de097hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1155h) Received-SPF: pass (mail100-am1: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT004.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail100-am1 (localhost.localdomain [127.0.0.1]) by mail100-am1 (MessageSwitch) id 1376306510112239_16776; Mon, 12 Aug 2013 11:21:50 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.233]) by mail100-am1.bigfish.com (Postfix) with ESMTP id 1844C2201FD; Mon, 12 Aug 2013 11:21:50 +0000 (UTC) Received: from DB3PRD0411HT004.eurprd04.prod.outlook.com (157.56.253.53) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 12 Aug 2013 11:21:44 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.246]) by DB3PRD0411HT004.eurprd04.prod.outlook.com ([10.255.73.39]) with mapi id 14.16.0341.000; Mon, 12 Aug 2013 11:21:44 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: "BRUNGARD, DEBORAH A" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-Index: Ac6VK7+mWUvlMi3uQtWQFQbgJh00TQCIlDaA Date: Mon, 12 Aug 2013 11:21:43 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D0E79F7@DB3PRD0411MB427.eurprd04.prod.outlook.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.159.77.165] Content-Type: multipart/alternative; boundary="_000_523C37072C291347B9730C9291CCA07D0E79F7DB3PRD0411MB427eu_" MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 11:49:28 -0000 --_000_523C37072C291347B9730C9291CCA07D0E79F7DB3PRD0411MB427eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, No, I'm not aware of any IPR that applies to this draft Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Friday, August 09, 2013 8:11 PM To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_523C37072C291347B9730C9291CCA07D0E79F7DB3PRD0411MB427eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 <= /p>

No, I'm not aware of any = IPR that applies to this draft

 <= /p>

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Friday, August 09, 2013 8:11 PM
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fw= k

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG docum= ent adoption:

 

Are you aware of any IPR that applies t= o draft identified above?

 

  Please state either:<= /span>

 

  "No, I'm not aware of any I= PR that applies to this draft"

  or

  "Yes, I'm aware of IPR that= applies to this draft"

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details)?

 

   If yes to the above, pleas= e state either:

 

  "Yes, the IPR has been disc= losed in compliance with IETF IPR rules"

  or

  "No, the IPR has not been d= isclosed"

 

  If you answer no, please provide= any additional details you think

  appropriate.

 

If you are listed as a document author = or contributor please answer the

above by responding to this email regar= dless of whether or not you are

aware of any relevant IPR.  This d= ocument will not advance to the next

stage until a response has been receive= d from each author and listed

contributor.  NOTE: THIS APPLIES T= O ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list b= ut are not listed as an author or

contributor, we remind you of your obli= gations under the IETF IPR rules

which encourages you to notify the IETF= if you are aware of IPR of

others on an IETF contribution, or to r= efrain from participating in any

contribution or discussion related to y= our undisclosed IPR.  For more

information, please see the RFCs listed= above and

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the hea= ders of this message in your

response.

 

 

--_000_523C37072C291347B9730C9291CCA07D0E79F7DB3PRD0411MB427eu_-- From yeyabin@huawei.com Mon Aug 12 00:13:46 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1565921F9C8E for ; Mon, 12 Aug 2013 00:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDf-8jpsTWCE for ; Mon, 12 Aug 2013 00:13:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5903421F84D9 for ; Sun, 11 Aug 2013 23:59:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUH35521; Mon, 12 Aug 2013 06:59:38 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 07:59:26 +0100 Received: from LHREML511-MBS.china.huawei.com ([10.201.4.130]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.01.0323.007; Mon, 12 Aug 2013 07:59:23 +0100 From: "Yeyabin (Yabin)" To: "Chenming (NWResearch)" , Lou Berger , Fatai Zhang , Leeyoung , Hanjianrui , "gregb@grotto-networking.com" , "xuyunbin@mail.ritt.com.cn" , "zhangguoying@mail.ritt.com.cn" , "Lidan (Dan)" Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te Thread-Index: AQHOg+m27a2T8jk8rE+R9XltRbiOTZmRE9ZggAA3FfA= Date: Mon, 12 Aug 2013 06:59:22 +0000 Message-ID: <6EEDE9C02D465249B95ADB23596392A520CEB3D7@lhreml511-mbs> References: <51E83C58.6010602@labn.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.139.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 12 Aug 2013 05:07:28 -0700 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 07:39:54 -0000 WWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0IGFuZCB0aGUg SVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMg YXMgZm9sbG93czogDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/ b3B0aW9uPWRvY3VtZW50X3NlYXJjaCZkb2N1bWVudF9zZWFyY2g9ZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUuDQoNCg0KQmVzdCByZWdhcmRzDQoNCg0K WWFiaW4gWWUNCg0KDQpEci4gWWFiaW4gWWUNClNlbmlvciBSZXNlYXJjaGVyDQpIVUFXRUkgVEVD SE5PTE9HSUVTIERVRVNTRUxET1JGIEdtYkgNCk11bmljaCBPZmZpY2UsIEV1cm9wZWFuIFJlc2Vh cmNoIENlbnRlcg0KDQpSaWVzc3RyYcOfZSAyNQ0KODA5OTIgTcO8bmNoZW4NClRlbDogKzQ5ICgw KTg5LTE1ODgzNCA0MDUyDQpNb2JpbGU6ICs0OSAoMCkxNjIyMDQ3NTcwDQpGYXg6ICs0OSAoMCk4 OS0xNTg4MzQgNDQ0Nw0KRS1tYWlsOiB5ZXlhYmluQGh1YXdlaS5jb20gDQp3d3cuaHVhd2VpLmNv bSANCg0KSFVBV0VJIFRFQ0hOT0xPR0lFUyBEdWVzc2VsZG9yZiBHbWJIDQpBbSBTZWVzdGVybiAy NCwgNDA1NDcgRMO8c3NlbGRvcmYsIEdlcm1hbnksIHd3dy5odWF3ZWkuY29tDQpSZWdpc3RlcmVk IE9mZmljZTogRMO8c3NlbGRvcmYsIFJlZ2lzdGVyIENvdXJ0IETDvHNzZWxkb3JmLCBIUkIgNTYw NjMsDQpNYW5hZ2luZyBEaXJlY3RvcjogSmluZ3dlbiBUQU8sIFdhbnpob3UgTUVORywgTGlmYW5n IENIRU4NClNpdHogZGVyIEdlc2VsbHNjaGFmdDogRMO8c3NlbGRvcmYsIEFtdHNnZXJpY2h0IETD vHNzZWxkb3JmLCBIUkIgNTYwNjMsDQpHZXNjaMOkZnRzZsO8aHJlcjogSmluZ3dlbiBUQU8sIFdh bnpob3UgTUVORywgTGlmYW5nIENIRU4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgZS1tYWls IGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJv bSBIVUFXRUksIHdoaWNoDQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0 eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0 aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0 ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlz c2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50 KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFu ZCBkZWxldGUgaXQhDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0K5Y+R5Lu25Lq6OiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQrl j5HpgIHml7bpl7Q6IDIwMTPlubQ35pyIMTnml6UgMzowNQ0K5pS25Lu25Lq6OiBGYXRhaSBaaGFu ZzsgTGVleW91bmc7IEhhbmppYW5ydWk7IGdyZWdiQGdyb3R0by1uZXR3b3JraW5nLmNvbTsgeHV5 dW5iaW5AbWFpbC5yaXR0LmNvbS5jbjsgemhhbmdndW95aW5nQG1haWwucml0dC5jb20uY247IExp ZGFuIChEYW4pOyBDaGVubWluZyAoTldSZXNlYXJjaCk7IFlleWFiaW4gKFlhYmluKQ0K5oqE6YCB OiBjY2FtcEBpZXRmLm9yZw0K5Li76aKYOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlDQoNCkF1dGhvcnMsIENvbnRyaWJ1 dG9ycywgKENDQU1QKQ0KDQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBD YWxsOg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlk ZW50aWZpZWQgYWJvdmU/DQoNCiAgUGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAiTm8sIEknbSBu b3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCiAgb3INCiAg IlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCg0KSWYg c28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJ UFIgcnVsZXMNCihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRl dGFpbHMpPw0KDQogICBJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0K DQogICJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJ RVRGIElQUiBydWxlcyINCiAgb3INCiAgIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9z ZWQiDQoNCiAgSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwg ZGV0YWlscyB5b3UgdGhpbmsNCiAgYXBwcm9wcmlhdGUuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFz IGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3ZXIgdGhlDQphYm92 ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5v dCB5b3UgYXJlDQphd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiAgVGhpcyBkb2N1bWVudCB3aWxs IG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0DQpzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVu IHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZA0KY29udHJpYnV0b3IuICBOT1RF OiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUw0KTUVTU0FHRSdTIFRP IExJTkVTLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBDQ0FNUCBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUg bm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3INCmNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9m IHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzDQp3aGljaCBlbmNvdXJh Z2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2YNCm90 aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRpY2lw YXRpbmcgaW4gYW55DQpjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIg dW5kaXNjbG9zZWQgSVBSLiAgRm9yIG1vcmUNCmluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBS RkNzIGxpc3RlZCBhYm92ZSBhbmQNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2ll c2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpDQ0FNUCBX RyBDaGFpcnMNCg0KUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBv ZiB0aGlzIG1lc3NhZ2UgaW4geW91cg0KcmVzcG9uc2UuDQo= From ruiquan.jing@ties.itu.int Mon Aug 12 00:32:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9CA21F9F8E for ; Mon, 12 Aug 2013 00:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnFqcTS3nYa1 for ; Mon, 12 Aug 2013 00:32:07 -0700 (PDT) Received: from mail.ctbri.com.cn (mail.ctbri.com.cn [219.142.69.47]) by ietfa.amsl.com (Postfix) with ESMTP id DA3DE21F9FCA for ; Mon, 12 Aug 2013 00:20:34 -0700 (PDT) Received: from ctbrijingrq ([10.9.53.66]) by mail.ctbri.com.cn (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013081215202438-5557 ; Mon, 12 Aug 2013 15:20:24 +0800 From: "Ruiquan Jing" To: "'BRUNGARD, DEBORAH A'" References: In-Reply-To: Date: Mon, 12 Aug 2013 15:20:24 +0800 Organization: CTBRI Message-ID: <01ab01ce972c$6951d950$3bf58bf0$@jing@ties.itu.int> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6XKgnZvXwDgQw3QVO5U/rVFxOTIQAAiOAA X-MIMETrack: Itemize by SMTP Server on mailserver/ctbri(Release 8.5.3FP1|March 07, 2012) at 2013/08/12 15:20:24, Serialize by Router on mailserver/ctbri(Release 8.5.3FP1|March 07, 2012) at 2013/08/12 15:20:34, Serialize complete at 2013/08/12 15:20:34 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AC_01CE976F.77751950" Content-Language: zh-cn X-Mailman-Approved-At: Mon, 12 Aug 2013 05:07:27 -0700 Cc: ccamp@ietf.org, draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ruiquan.jing@ties.itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 08:48:19 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01AC_01CE976F.77751950 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Dear all I am the co-authors of this draft. No, I am not aware of any IPR that applies to this draft Regards Ruiquan (Rick) Jing China Telecom Beijing Research Institute From: zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn] Sent: Monday, August 12, 2013 3:03 PM To: BRUNGARD, DEBORAH A Cc: ccamp@ietf.org; draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org; jingrq@ctbri.com.cn; Rakesh Gandhi (rgandhi) Subject: Re: Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp Dear all We are the co-authors of this draft No, We are not aware of any IPR that applies to this draft Best regards Fan Yang, Weilian Jiang and Fei Zhang -----Original Message----- From: , DEBORAH BRUNGARD < db3546@att.com> Date: Friday, 9 August, 2013 2:03 PM To: " draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org" < draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org> Cc: CCAMP < ccamp@ietf.org> Subject: Regarding IPR on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp Resent-From: < draft-alias-bounces@tools.ietf.org> Resent-To: " jingrq@ctbri.com.cn" < jingrq@ctbri.com.cn>, Rakesh Gandhi < rgandhi@cisco.com>, " zhang.fei3@zte.com.cn" < zhang.fei3@zte.com.cn> Resent-Date: Friday, 9 August, 2013 2:03 PM Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp ------=_NextPart_000_01AC_01CE976F.77751950 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Dear = all
I  am =  the co-authors of this draft. =  
No, I am = not aware of any IPR that applies to this draft

Regards

Ruiquan (Rick)  Jing

China Telecom Beijing Research = Institute

 

 

 

 

From:= = zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
Sent: = Monday, August 12, 2013 3:03 PM
To: BRUNGARD, DEBORAH = A
Cc: ccamp@ietf.org; = draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org; = jingrq@ctbri.com.cn; Rakesh Gandhi (rgandhi)
Subject: Re: = Regarding IPR on = draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp

<= /div>

 


Dear = all

We are the = co-authors of this draft
 
No, We are = not aware of any IPR that applies to this draft

Best = regards

Fan Yang, = Weilian Jiang and Fei Zhang =



-----Origin= al Message-----
From: = <BRUNGAR= D>, DEBORAH BRUNGARD <db3546@att.= com>
= Date: Friday, 9 August, 2013 2:03 PM
To: = "draft-ietf-= ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'>" = <draft-ietf-= ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'>>
= Cc: CCAMP <ccamp@ietf.= org>
= Subject: Regarding IPR on = draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp
Resent-From: = <draft-alias= -bounces@tools.ietf.org>
= Resent-To: "jingrq@ctbr= i.com.cn" = <jingrq@ctbr= i.com.cn>, = Rakesh Gandhi <rgandhi@cis= co.com>, = "zhang.fei3@= zte.com.cn" = <zhang.fei3@= zte.com.cn>
= Resent-Date: Friday, 9 August, 2013 2:03 PM

Authors, = Contributors, (CCAMP)
 
As part of = the preparation for WG Last Call: =
 
Are you = aware of any IPR that applies to draft identified above?
 
  = Please state either:
 
  = "No, I'm not aware of any IPR that applies to this = draft"
  = or
  = "Yes, I'm aware of IPR that applies to this draft"
 
If so, has = this IPR been disclosed in compliance with IETF IPR rules
(see RFCs = 3979, 4879, 3669 and 5378 for more details)? =
 
  =  If yes to the above, please state either:
 
  = "Yes, the IPR has been disclosed in compliance with IETF IPR = rules"
  = or
  = "No, the IPR has not been disclosed" =
 
  If = you answer no, please provide any additional details you = think
  = appropriate.
 
If you are = listed as a document author or contributor please answer the
above by = responding to this email regardless of whether or not you = are
aware of = any relevant IPR.  This document will not advance to the = next
stage = until a response has been received from each author and = listed
contributor= .  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S = TO LINES.
 
If you are = on the CCAMP WG email list but are not listed as an author = or
contributor= , we remind you of your obligations under the IETF IPR rules
which = encourages you to notify the IETF if you are aware of IPR of
others on = an IETF contribution, or to refrain from participating in = any
contributio= n or discussion related to your undisclosed IPR.  For = more
information= , please see the RFCs listed above and
http://trac= .tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
 
Thank = you,
CCAMP WG = Chairs
 
PS Please = include all listed in the headers of this message in your
response.
___________= ____________________________________ =
CCAMP = mailing list
CCAMP@ietf.org
https://www.ietf.org= /mailman/listinfo/ccamp

------=_NextPart_000_01AC_01CE976F.77751950-- From dhruv.dhody@huawei.com Mon Aug 12 05:03:37 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0618811E80EA for ; Mon, 12 Aug 2013 05:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA42o4Jm0BEM for ; Mon, 12 Aug 2013 05:03:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 98EA711E817D for ; Mon, 12 Aug 2013 04:50:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUH62884; Mon, 12 Aug 2013 11:50:25 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 12:50:07 +0100 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 12:50:11 +0100 Received: from szxeml556-mbs.china.huawei.com ([169.254.4.147]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.007; Mon, 12 Aug 2013 19:50:05 +0800 From: Dhruv Dhody To: "BRUNGARD, DEBORAH A" , "draft-dhody-ccamp-rsvp-te-domain-subobjects@tools.ietf.org" Thread-Topic: Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects Thread-Index: Ac6VLIv04Xmy0haVR3Oh4IK1fEPtFwCJAWAw Date: Mon, 12 Aug 2013 11:50:04 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B44886624@szxeml556-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B44886624szxeml556mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 12 Aug 2013 05:07:28 -0700 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 12:03:37 -0000 --_000_23CE718903A838468A8B325B80962F9B44886624szxeml556mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I'm aware of IPR that applies to this draft & Yes, the IPR has been disclosed in compliance with IETF IPR rules (**) (**) The IPR was disclosed for "draft-dhody-pce-pcep-domain-sequence" [now = draft-ietf-pce-pcep-domain-sequence] http://datatracker.ietf.org/ipr/1690/ We are working with the IPR dept to make sure it shows up for this document= as well, when searched via the IPR search tool http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraft= -dhody-ccamp-rsvp-te-domain-subobjects Regards, Dhruv --------------------------------------------------------------- Dhruv Dhody System Architect, Huawei Technologies India Pvt. Ltd., Banagalore Mobile: +91-9845062422 This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed above. An= y use of the information contained herein in any way (including, but not limited to, tot= al or partial disclosure, reproduction, or dissemination) by persons other than the inten= ded recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by phone or email immediately and delete it! From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: 09 August 2013 23:46 To: draft-dhody-ccamp-rsvp-te-domain-subobjects@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_23CE718903A838468A8B325B80962F9B44886624szxeml556mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I'm aware of IPR that applies to this draft

&

Yes, the IPR has been disclosed in compliance with IETF IPR rules (**)

 

(**) The IPR was disclosed for "draft-dhody-pce-pcep-domain-sequenc= e" [now draft-ietf-pce-pcep-domain-sequence]
http://datatracker.ietf.o= rg/ipr/1690/

 

We are working with the IPR dept to make sure it shows up for this docum= ent as well, when searched via the IPR search tool

http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id= =3Ddraft-dhody-ccamp-rsvp-te-domain-subobjects=

 

Regards,

Dhruv

 

 

----------------------------------------= -----------------------

Dhruv Dhody

System Architect,

Huawei Technologies India = Pvt. Ltd.,

Banagalore

Mobile: +91-9845062422=

This e-mail and its attach= ments contain confidential information from HUAWEI, which

is intended only for the p= erson or entity whose address is listed above. Any use of the

information contained here= in in any way (including, but not limited to, total or partial

disclosure, reproduction, = or dissemination) by persons other than the intended

recipient(s) is prohibited= . If you receive this e-mail in error, please notify the sender by

phone or email immediately= and delete it!

 

From: BRUNGARD= , DEBORAH A [mailto:db3546@att.com]
Sent: 09 August 2013 23:46
To: draft-dhody-ccamp-rsvp-te-domain-subobjects@tools.ietf.org
Cc: ccamp@ietf.org
Subject: Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobject= s

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG docum= ent adoption:

 

Are you aware of any IPR that applies t= o draft identified above?

 

  Please state either:<= /span>

 

  "No, I'm not aware of any I= PR that applies to this draft"

  or

  "Yes, I'm aware of IPR that= applies to this draft"

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details)?

 

   If yes to the above, pleas= e state either:

 

  "Yes, the IPR has been disc= losed in compliance with IETF IPR rules"

  or

  "No, the IPR has not been d= isclosed"

 

  If you answer no, please provide= any additional details you think

  appropriate.

 

If you are listed as a document author = or contributor please answer the

above by responding to this email regar= dless of whether or not you are

aware of any relevant IPR.  This d= ocument will not advance to the next

stage until a response has been receive= d from each author and listed

contributor.  NOTE: THIS APPLIES T= O ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list b= ut are not listed as an author or

contributor, we remind you of your obli= gations under the IETF IPR rules

which encourages you to notify the IETF= if you are aware of IPR of

others on an IETF contribution, or to r= efrain from participating in any

contribution or discussion related to y= our undisclosed IPR.  For more

information, please see the RFCs listed= above and

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the hea= ders of this message in your

response.

 

 

--_000_23CE718903A838468A8B325B80962F9B44886624szxeml556mbschi_-- From daniele.ceccarelli@ericsson.com Mon Aug 12 07:36:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4354F21E829B for ; Mon, 12 Aug 2013 07:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDmDdIjhl77p for ; Mon, 12 Aug 2013 07:36:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B1F5F21F9CAD for ; Mon, 12 Aug 2013 07:28:38 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000000f62-cb-5208f1151607 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 23.92.03938.511F8025; Mon, 12 Aug 2013 16:28:37 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.105]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Mon, 12 Aug 2013 16:28:35 +0200 From: Daniele Ceccarelli To: John E Drake , "Matt Hartley (mhartley)" , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACdi0mD//+dlgP/7p/Mw Date: Mon, 12 Aug 2013 14:28:36 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se> References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvra7oR44ggwcX1C2ezLnBYjHnrrPF nJfMFn3N51kdWDym/N7I6tFy5C2rx5IlP5k8rjddZQ9gieKySUnNySxLLdK3S+DKeN/KUvBQ peLH5D9MDYxzZboYOTgkBEwkWluZuhg5gUwxiQv31rOB2EIChxkl5hzN6GLkArKXMEpM/7SK FaSeTcBK4skhH5C4iMBKRokFF06zgjQICwRIzFn+EaxZRCBQ4u3nuWwg9SICbhLL9paDhFkE VCVWHb3JCGLzCnhLLP21jRFi/gYmib4p/WBHcAqESazd9g9sJqOArMSE3YvAGpgFxCVuPZkP daiAxJI955khbFGJl48h6iUEFCXanzZA1etJ3Jg6hQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk 7CwkLbOQtMxC0rKAkWUVI3tuYmZOernhJkZgrBzc8lt3B+OpcyKHGKU5WJTEeTfpnQkUEkhP LEnNTk0tSC2KLyrNSS0+xMjEwSnVwBhR5H6Wje2U0IeT1om5MStivtR88Gx6v3syA5PfA95l Eyx8eLsTXE5m211SMg/fxppuePLxVWNBrpXG6isED9yU0PExMRDbvCIi4Fzs5IraW9pB8m2i UsL2l6NufFsY8aU/dfPntkeez3hO6nY4/H+3xEDOP07vaXxxbFLu1SVnO4RFFNLnKLEUZyQa ajEXFScCAO3tCpljAgAA Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 14:36:27 -0000 Hi John, all, I think there are cases in which the PCEP can't solve the issue. Suppose fo= r example the simple network below C1 --- C2 --- C3 C4 --- C5 --- C6 \ / S1 --- S2 --- S3 Where Cx are the client nodes and Sx the server nodes and C3-S1 and S3-C4 t= he UNIs.=20 The usual behavior for the setup of an LSP in the client domain between C1 = and C6 consists on 1. "asking" C3 to setup a link in the client layer between C3 and C4 and 2. after its provisioning, "asking" C1to setup an LSP between C1 and C6 usi= ng the link between C3 and C4. If you suppose to have a simpler approach consisting on a single step, it w= ould be possible to "ask" C1 to setup an end to end LSP between C1 and C6 w= ith loose ERO C1-C3-C4-C6. In the first case the trigger on C3 is provided by the operator with given = constraints (e.g. Objective functions and/or TE metric bounds) and it would= be easy to inject them into a PCEP request towards the PCE of the server d= omains, but what happens in the second case? The operator only issues a com= mand to C1, which starts a signaling procedure. The RSVP-TE message reaches= C3 and triggers the setup of the link C3-C4 over the UNI. IMHO putting the Objective Functions into RSVP-TE is useful to "convey" suc= h path computation requirements from C1 to C3. Once the PATH message reache= s C3, it can ask S1 to compute the path towards C4 via RSVP-TE or can ask t= he server layer PCE via PCEP. This is one of the two reasons why I think that Objective Functions and TE = metric Bounds could be useful in RSVP-TE. The second one is that I agree wi= th Matt when saying that not in all cases the client nodes will be allowed = to access the server layer PCE. BR Daniele=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of John E Drake > Sent: venerd=EC 9 agosto 2013 23:23 > To: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > PCEP can be deployed whenever the server network wishes to provide a path > computation service. What possible advantage to anyone is gained by > embedding PCEP in RSVP-TE signaling? >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > Sent: Friday, August 09, 2013 1:53 PM > > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > > Cc: Matt Hartley (mhartley) > > Subject: RE: [CCAMP] > > draft-ali-ccamp-rc-objective-function-metric-bound- > > 03.txt > > > > Fatai, John, > > > > I don't think you can guarantee that PCE will be deployed absolutely > > everywhere, or that you can guarantee the client will be permitted > > access to the server PCE when it is. In those cases, this draft is usef= ul. > > > > Cheers > > > > Matt > > > > > Hi John, > > > > > > Completely agree. > > > > > > I also raised this comment in front of the mic during Berlin meeting. > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of John E Drake > > > Sent: Friday, August 09, 2013 1:49 AM > > > To: CCAMP (ccamp@ietf.org) > > > Subject: [CCAMP] > > > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt > > > > > > Hi, > > > > > > I have a real concern with this draft because it appears to be > > > heading us down the road of re-inventing PCEP in RSVP signaling with > > > the dubious justification that it is needed in those situations in > > > which a PCE is not available. However, if you re-invent PCEP in > > > RSVP signaling, then you have effectively ensured that there are no > > > situations in which a PCE or its signaling equivalent are not availab= le. > > > > > > Why is this better than simply ensuring that a PCE is available in > > > those situations in which it is needed? > > > > > > Yours Irrespectively, > > > > > > John > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Mon Aug 12 08:49:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01BB21F938E for ; Mon, 12 Aug 2013 08:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY2RDZY9Cvwx for ; Mon, 12 Aug 2013 08:49:08 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 37DC821E80F1 for ; Mon, 12 Aug 2013 07:46:44 -0700 (PDT) X-AuditID: c1b4fb25-b7fc58e000001048-1e-5208f552341a Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 03.B0.04168.255F8025; Mon, 12 Aug 2013 16:46:42 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.105]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Mon, 12 Aug 2013 16:46:42 +0200 From: Daniele Ceccarelli To: "BRUNGARD, DEBORAH A" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-Index: Ac6VK7+mWUvlMi3uQtWQFQbgJh00TQCPvrww Date: Mon, 12 Aug 2013 14:46:41 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481362DF@ESESSMB301.ericsson.se> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE481362DFESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+JvrW7QV44ggzdXtC2ezLnBYnG5q5vd onnuZDYHZo+X/XMYPZYs+cnk8eXyZ7YA5igum5TUnMyy1CJ9uwSujCcTG5gLuosqJh15wdbA 2J3WxcjJISFgInHm/GImCFtM4sK99WxdjFwcQgKHGSWudd1nh3CWMErsadkB5HBwsAlYSTw5 5APSICIwk1Hi3fkCEJtZQFWi7fopVhBbWMBR4lXfMSaIGieJU3c/MUPYRhLLjjxgAbFZgOpv PmgBq+cV8JZYeH4uWFxIIFxi759edhCbUyBC4v3SLWC9jAKyEhN2L2KE2CUucevJfKijBSSW 7DnPDGGLSrx8/I8VwlaUaH/aAFWfL9G15jw7xC5BiZMzn7BMYBSdhWTULCRls5CUQcT1JG5M ncIGYWtLLFv4mhnC1pWY8e8QC7L4Akb2VYzsuYmZOenlRpsYgXF2cMtv1R2Md86JHGKU5mBR EufdrHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjiujpm6esv8l9j+eedUnnyW0b++z5 WWu/3EyRe7z2zHtu4Yumz2p3rL/AWyce6nD6S8gVp5YKi7sH3TztHq7Vz3samsu5rrFf7Xtl 2vKopH4rm6M9RvY1E2Ie/2XNNfr+T3/tKvYl0g7tGdFbr0yMmfP+hl8DW6GKpOWOv2cXfTAP kulOU9uqxFKckWioxVxUnAgASkiSAYECAAA= Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 15:49:13 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE481362DFESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "No, I'm not aware of any IPR that applies to this draft" BR Daniele From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: venerd=EC 9 agosto 2013 20:11 To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_4A1562797D64E44993C5CBF38CF1BE481362DFESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

  "No, I'm not aware of any I= PR that applies to this draft"

 <= /p>

BR

Daniele=

 <= /p>

From: BRUNGARD= , DEBORAH A [mailto:db3546@att.com]
Sent: venerd=EC 9 agosto 2013 20:11
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG docum= ent adoption:

 

Are you aware of any IPR that applies t= o draft identified above?

 

  Please state either:<= /span>

 

  "No, I'm not aware of any I= PR that applies to this draft"

  or

  "Yes, I'm aware of IPR that= applies to this draft"

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details)?

 

   If yes to the above, pleas= e state either:

 

  "Yes, the IPR has been disc= losed in compliance with IETF IPR rules"

  or

  "No, the IPR has not been d= isclosed"

 

  If you answer no, please provide= any additional details you think

  appropriate.

 

If you are listed as a document author = or contributor please answer the

above by responding to this email regar= dless of whether or not you are

aware of any relevant IPR.  This d= ocument will not advance to the next

stage until a response has been receive= d from each author and listed

contributor.  NOTE: THIS APPLIES T= O ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list b= ut are not listed as an author or

contributor, we remind you of your obli= gations under the IETF IPR rules

which encourages you to notify the IETF= if you are aware of IPR of

others on an IETF contribution, or to r= efrain from participating in any

contribution or discussion related to y= our undisclosed IPR.  For more

information, please see the RFCs listed= above and

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the hea= ders of this message in your

response.

 

 

--_000_4A1562797D64E44993C5CBF38CF1BE481362DFESESSMB301ericsso_-- From mhartley@cisco.com Mon Aug 12 08:52:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8911E21E8152 for ; Mon, 12 Aug 2013 08:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvQajW27dV9P for ; Mon, 12 Aug 2013 08:52:17 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id F018B21E816E for ; Mon, 12 Aug 2013 07:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15895; q=dns/txt; s=iport; t=1376319272; x=1377528872; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3fWWuLb7MaBegCLMx2bXy7EUdenA0Fqf75HIbIIpjM4=; b=ObUi3kq6kBcS3ippDVdyvjRQfM3xwypMJB62x+MjcS6SSFkM63hkYiND FZUukmq/MbyN3pleX1nGcup29ZSZDxIspuTQVR3v2BxwV62FlmLFZm23r qRuHiGvH8dwjI2wRJiJVDxWwK9dAevGC4VSVUyQtxgo/a7HMpm7VXUutB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAOv1CFKtJV2c/2dsb2JhbABbgkJENVCFdLAjiD2BGRZ0giQBAQEELUcFEAIBCBEEAQELHQcyFAkIAQEEAQ0FCIgIDLY9jnWBFS0EBgEGgxV2A5kQkCWBOYFigXE5 X-IronPort-AV: E=Sophos;i="4.89,862,1367971200"; d="scan'208,217";a="246245791" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 12 Aug 2013 14:54:18 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7CEsIu6029579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 14:54:18 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 09:54:18 -0500 From: "Matt Hartley (mhartley)" To: "BRUNGARD, DEBORAH A" , "draft-ietf-ccamp-lsp-diversity@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ietf-ccamp-lsp-diversity Thread-Index: Ac6VKzMZ8xb/ji1DTkKZ/Gx8Wk3xMACQCtMg Date: Mon, 12 Aug 2013 14:54:17 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105B132E@xmb-rcd-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.251] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC105B132Exmbrcdx03ciscoc_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-lsp-diversity X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 15:52:25 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC105B132Exmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm aware of IPR that applies to this draft. It has been disclosed in compl= iance with IETF IPR rules. It was originally disclosed when this draft was adopted by the WG and can b= e found at https://datatracker.ietf.org/ipr/1943/ Cheers Matt From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: Friday, August 09, 2013 2:07 PM To: draft-ietf-ccamp-lsp-diversity@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-lsp-diversity Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_9D50FCE7413E3D4EA5E42331115FB5BC105B132Exmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m aware of IP= R that applies to this draft. It has been disclosed in compliance with IETF= IPR rules.

 

It was originally dis= closed when this draft was adopted by the WG and can be found at https://datatracker.ietf= .org/ipr/1943/

 

Cheers

 

Matt

 

From: BRUNGARD= , DEBORAH A [mailto:db3546@att.com]
Sent: Friday, August 09, 2013 2:07 PM
To: draft-ietf-ccamp-lsp-diversity@tools.ietf.org
Cc: ccamp@ietf.org
Subject: Regarding IPR on draft-ietf-ccamp-lsp-diversity<= /span>

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG Last = Call:

 

Are you aware of any IPR that applies t= o draft identified above?

 

  Please state either:<= /span>

 

  "No, I'm not aware of any I= PR that applies to this draft"

  or

  "Yes, I'm aware of IPR that= applies to this draft"

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details)?

 

   If yes to the above, pleas= e state either:

 

  "Yes, the IPR has been disc= losed in compliance with IETF IPR rules"

  or

  "No, the IPR has not been d= isclosed"

 

  If you answer no, please provide= any additional details you think

  appropriate.

 

If you are listed as a document author = or contributor please answer the

above by responding to this email regar= dless of whether or not you are

aware of any relevant IPR.  This d= ocument will not advance to the next

stage until a response has been receive= d from each author and listed

contributor.  NOTE: THIS APPLIES T= O ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list b= ut are not listed as an author or

contributor, we remind you of your obli= gations under the IETF IPR rules

which encourages you to notify the IETF= if you are aware of IPR of

others on an IETF contribution, or to r= efrain from participating in any

contribution or discussion related to y= our undisclosed IPR.  For more

information, please see the RFCs listed= above and

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the hea= ders of this message in your

response.

 

 

--_000_9D50FCE7413E3D4EA5E42331115FB5BC105B132Exmbrcdx03ciscoc_-- From IHussain@infinera.com Mon Aug 12 09:32:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B864421F9B60 for ; Mon, 12 Aug 2013 09:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAfjaQz8yf19 for ; Mon, 12 Aug 2013 09:32:19 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 281F521E8055 for ; Mon, 12 Aug 2013 08:46:16 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Mon, 12 Aug 2013 08:46:15 -0700 From: Iftekhar Hussain To: "BRUNGARD, DEBORAH A" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-Index: Ac6VK7+mWUvlMi3uQtWQFQbgJh00TQCRyEqw Date: Mon, 12 Aug 2013 15:46:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE53FA8720DSVEXDBPROD1infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 16:32:23 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE53FA8720DSVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, No, I'm not aware of any IPR that applies to this draft. Regards, Iftekhar From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: Friday, August 09, 2013 11:11 AM To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_D7D7AB44C06A2440B716F1F1F5E70AE53FA8720DSVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

No, I'm not aware of any = IPR that applies to this draft.

 <= /p>

Regards,

Iftekhar

From: BRUNGARD= , DEBORAH A [mailto:db3546@att.com]
Sent: Friday, August 09, 2013 11:11 AM
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG docum= ent adoption:

 

Are you aware of any IPR that applies t= o draft identified above?

 

  Please state either:<= /span>

 

  "No, I'm not aware of any I= PR that applies to this draft"

  or

  "Yes, I'm aware of IPR that= applies to this draft"

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details)?

 

   If yes to the above, pleas= e state either:

 

  "Yes, the IPR has been disc= losed in compliance with IETF IPR rules"

  or

  "No, the IPR has not been d= isclosed"

 

  If you answer no, please provide= any additional details you think

  appropriate.

 

If you are listed as a document author = or contributor please answer the

above by responding to this email regar= dless of whether or not you are

aware of any relevant IPR.  This d= ocument will not advance to the next

stage until a response has been receive= d from each author and listed

contributor.  NOTE: THIS APPLIES T= O ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list b= ut are not listed as an author or

contributor, we remind you of your obli= gations under the IETF IPR rules

which encourages you to notify the IETF= if you are aware of IPR of

others on an IETF contribution, or to r= efrain from participating in any

contribution or discussion related to y= our undisclosed IPR.  For more

information, please see the RFCs listed= above and

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the hea= ders of this message in your

response.

 

 

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53FA8720DSVEXDBPROD1infi_-- From jdrake@juniper.net Mon Aug 12 10:12:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD27121F9A2A for ; Mon, 12 Aug 2013 10:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SNgruEHxSyq for ; Mon, 12 Aug 2013 10:11:51 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDF621F9A33 for ; Mon, 12 Aug 2013 09:55:52 -0700 (PDT) Received: from mail128-va3-R.bigfish.com (10.7.14.229) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Mon, 12 Aug 2013 16:55:49 +0000 Received: from mail128-va3 (localhost [127.0.0.1]) by mail128-va3-R.bigfish.com (Postfix) with ESMTP id B0B252000FE; Mon, 12 Aug 2013 16:55:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371Ic89bh542Iec9I1432I1418Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h668h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail128-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(51704005)(13464003)(199002)(189002)(51444003)(37854004)(31966008)(47446002)(33646001)(66066001)(74366001)(77982001)(81542001)(56776001)(54316002)(47736001)(74662001)(74316001)(54356001)(81342001)(65816001)(83072001)(80976001)(59766001)(50986001)(63696002)(47976001)(16406001)(74876001)(80022001)(19580395003)(51856001)(19580405001)(76796001)(69226001)(77096001)(49866001)(76786001)(79102001)(56816003)(19580385001)(4396001)(46102001)(74706001)(76482001)(76576001)(15202345003)(81686001)(83322001)(74502001)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail128-va3 (localhost.localdomain [127.0.0.1]) by mail128-va3 (MessageSwitch) id 1376326547674533_11916; Mon, 12 Aug 2013 16:55:47 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.254]) by mail128-va3.bigfish.com (Postfix) with ESMTP id 9F1F418004C; Mon, 12 Aug 2013 16:55:47 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 12 Aug 2013 16:55:47 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 12 Aug 2013 16:55:46 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 12 Aug 2013 16:55:44 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.235]) with mapi id 15.00.0731.000; Mon, 12 Aug 2013 16:55:43 +0000 From: John E Drake To: Daniele Ceccarelli , "Matt Hartley (mhartley)" , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNW56AgAAHERCABER8AIAAGcGw Date: Mon, 12 Aug 2013 16:55:43 +0000 Message-ID: <403c214579834abf91393c4a1cd2c4dd@BY2PR05MB142.namprd05.prod.outlook.com> References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 09368DB063 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:12:09 -0000 Daniele, Comments inline. However, the discussions since Berlin on UNI enhancements= and/or adding additional information related to path computation into the = PATH message lead me to the conclusion that we have a problem in CCAMP and = that we really should suspend all solutions related work until we have a be= tter idea of the problem we wish to solve. If you don't think we have a problem, please consider the list of active CC= AMP drafts: http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro/ http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/ http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-srlg-collect/ http://datatracker.ietf.org/doc/draft-ietf-ccamp-te-metric-recording/ http://datatracker.ietf.org/doc/draft-ali-ccamp-extended-srlg/ http://datatracker.ietf.org/doc/draft-ali-ccamp-gmpls-uni-error-notificatio= n/ http://datatracker.ietf.org/doc/draft-ali-ccamp-lsp-inquiry/ http://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function-metri= c-bound/ http://datatracker.ietf.org/doc/draft-bardalai-ccamp-overlay-path-comp/ http://datatracker.ietf.org/doc/draft-ceccadedios-ccamp-overlay-use-cases/ http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain-subobjects= / http://datatracker.ietf.org/doc/draft-fedyk-ccamp-uni-extensions/ http://datatracker.ietf.org/doc/draft-gandhi-ccamp-gmpls-restoration-lsp/ Yours Irrespectively, John > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Monday, August 12, 2013 7:29 AM > To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP > (ccamp@ietf.org) > Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > Hi John, all, >=20 > I think there are cases in which the PCEP can't solve the issue. Suppose = for > example the simple network below >=20 > C1 --- C2 --- C3 C4 --- C5 --- C6 > \ / > S1 --- S2 --- S3 >=20 > Where Cx are the client nodes and Sx the server nodes and C3-S1 and S3-C4 > the UNIs. > The usual behavior for the setup of an LSP in the client domain between C= 1 > and C6 consists on 1. "asking" C3 to setup a link in the client layer be= tween > C3 and C4 and 2. after its provisioning, "asking" C1to setup an LSP betwe= en > C1 and C6 using the link between C3 and C4. JD: No, that's incorrect. The C1-C6 Path message arrives at C3. It trigg= ers C3 to establish a C3-C4 LSP. After this LSP is established, C3 forwards the C1-C= 6 Path message to C4. We already have CCAMP drafts from, I believe, Cyril and/or = Fatai that describe how to embed the desired characteristics of the C3-C4 LSP wit= hin the ERO of the C1-C6 Path message. =20 >=20 > If you suppose to have a simpler approach consisting on a single step, it > would be possible to "ask" C1 to setup an end to end LSP between C1 and C= 6 > with loose ERO C1-C3-C4-C6. JD: See above. This has been a part of GMPLS since its inception. >=20 > In the first case the trigger on C3 is provided by the operator with give= n > constraints (e.g. Objective functions and/or TE metric bounds) and it wou= ld > be easy to inject them into a PCEP request towards the PCE of the server > domains, but what happens in the second case? The operator only issues a > command to C1, which starts a signaling procedure. The RSVP-TE message > reaches C3 and triggers the setup of the link C3-C4 over the UNI. JD: See above. The second case is actually the GMPLS baseline behavior. >=20 > IMHO putting the Objective Functions into RSVP-TE is useful to "convey" > such path computation requirements from C1 to C3. Once the PATH message > reaches C3, it can ask S1 to compute the path towards C4 via RSVP-TE or c= an > ask the server layer PCE via PCEP. JD: In addition to what is described above, it is also possible for C1 to= use PCEP to expand the C3-C4 ERO and place the key associated with this expansion in= the ERO of the C1-C6 Path message. =20 >=20 > This is one of the two reasons why I think that Objective Functions and T= E > metric Bounds could be useful in RSVP-TE. The second one is that I agree > with Matt when saying that not in all cases the client nodes will be allo= wed to > access the server layer PCE. JD: The draft is proposing to embed PCEP within signaling. By definition,= this *is* allowing the client to access the server layer PCE. This is no differ= ent than allowing the client to access the server layer PCE without embedding PCE within signaling. >=20 > BR > Daniele >=20 >=20 >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of John E Drake > > Sent: venerd=EC 9 agosto 2013 23:23 > > To: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org) > > Subject: Re: [CCAMP] > > draft-ali-ccamp-rc-objective-function-metric-bound- > > 03.txt > > > > PCEP can be deployed whenever the server network wishes to provide a > > path computation service. What possible advantage to anyone is gained > > by embedding PCEP in RSVP-TE signaling? > > > > Yours Irrespectively, > > > > John > > > > > -----Original Message----- > > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > > Sent: Friday, August 09, 2013 1:53 PM > > > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > > > Cc: Matt Hartley (mhartley) > > > Subject: RE: [CCAMP] > > > draft-ali-ccamp-rc-objective-function-metric-bound- > > > 03.txt > > > > > > Fatai, John, > > > > > > I don't think you can guarantee that PCE will be deployed absolutely > > > everywhere, or that you can guarantee the client will be permitted > > > access to the server PCE when it is. In those cases, this draft is us= eful. > > > > > > Cheers > > > > > > Matt > > > > > > > Hi John, > > > > > > > > Completely agree. > > > > > > > > I also raised this comment in front of the mic during Berlin meetin= g. > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of John E Drake > > > > Sent: Friday, August 09, 2013 1:49 AM > > > > To: CCAMP (ccamp@ietf.org) > > > > Subject: [CCAMP] > > > > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt > > > > > > > > Hi, > > > > > > > > I have a real concern with this draft because it appears to be > > > > heading us down the road of re-inventing PCEP in RSVP signaling > > > > with the dubious justification that it is needed in those > > > > situations in which a PCE is not available. However, if you > > > > re-invent PCEP in RSVP signaling, then you have effectively > > > > ensured that there are no situations in which a PCE or its signalin= g > equivalent are not available. > > > > > > > > Why is this better than simply ensuring that a PCE is available in > > > > those situations in which it is needed? > > > > > > > > Yours Irrespectively, > > > > > > > > John > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp >=20 From db3546@att.com Mon Aug 12 12:54:53 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1B221F9C86; Mon, 12 Aug 2013 12:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy+mB-aSep56; Mon, 12 Aug 2013 12:54:40 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 96B8D21F91B7; Mon, 12 Aug 2013 12:54:39 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id c7d39025.0.2648435.00-324.7372407.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 12 Aug 2013 19:54:39 +0000 (UTC) X-MXL-Hash: 52093d7f341fd9f0-3a7ef2eae2f55b9b744a058a6f225f208fd4a6a6 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r7CJsaKU010036; Mon, 12 Aug 2013 15:54:36 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r7CJsPcf009820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Aug 2013 15:54:28 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 12 Aug 2013 19:54:11 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([169.254.202.226]) with mapi id 14.02.0342.003; Mon, 12 Aug 2013 15:54:11 -0400 From: "BRUNGARD, DEBORAH A" To: "adrian@olddog.co.uk" Thread-Topic: Please publish draft-ietf-ccamp-swcaps-update Thread-Index: Ac6XlbXRPgywAhkDTfywi2OTBPXJrQ== Date: Mon, 12 Aug 2013 19:54:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8356C13MISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=IuiphsDg c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=H_oZ9FUghigA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=pI8yKTvDo] X-AnalysisOut: [BkA:10 a=48vgC7mUAAAA:8 a=XcE0-7MdDHAYdLpWxRsA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=a8MVPLD9OnnsBdfLGVoA:9 a=_W_S_7VecoQA:10 a=frz4] X-AnalysisOut: [AuCg-hUA:10 a=AJAz9rZc4z-Czret:21] Cc: "ccamp@ietf.org" , "iesg-secretary@ietf.org" Subject: [CCAMP] Please publish draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:54:55 -0000 --_000_F64C10EAA68C8044B33656FA214632C8356C13MISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proto write-up for: draft-ietf-ccamp-swcaps-update (1) What type of RFC is being requested (BCP, Proposed Standard, Intern= et Standard, Informational, Experimental, or Historic)? Why is this the pro= per type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. Updates Standards Track documents. Yes. (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. The approv= al announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introd= uction of the document. If not, this may be an indication that there are de= ficiencies in the abstract or introduction. GMPLS provides control for multiple switching technologies, and hierar= chical switching within a technology. GMPLS routing and signaling use comm= on values to indicate switching technology type. These values are carried i= n routing in the Switching Capability field, and in signaling in the Switch= ing Type field. While the values used in these fields are the primary indic= ators of the technology and hierarchy level being controlled, the values ar= e not consistently defined and used across the different technologies suppo= rted by GMPLS. This document is intended to resolve the inconsistent defin= ition and use of the Switching Capability and Type fields by narrowly scopi= ng the meaning and use of the fields. This document updates any document t= hat uses the GMPLS Switching Capability and Types fields, in particular RFC= 3471, RFC 4202, RFC 4203, and RFC 5307. Working Group Summary: Was there anything in WG process that is worth noting? For example, wa= s there controversy about particular points or were there decisions where t= he consensus was particularly rough? No. Good support by the WG. Document Quality: Are there existing implementations of the protocol? Have a significant= number of vendors indicated their plan to implement the specification? Are= there any reviewers that merit special mention as having done a thorough r= eview, e.g., one that resulted in important changes or a conclusion that th= e document had no substantive issues? If there was a MIB Doctor, Media Type= or other expert review, what was its course (briefly)? In the case of a Me= dia Type review, on what date was the request posted? This document updates the definitions for the Switching Type field to = be consistent and deprecates three previously defined switching types. For = existing implementations, the primary impact of this document is deprecatin= g the use of PSC-2, 3 and 4. At the time of publication, there are no know= n deployments (or even implementations) that make use of these values so th= ere is no compatibility issues for current routing and signaling implementa= tions. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Deborah Brungard is the Document Shepherd. Adrian Farrel is the Area D= irector. (2) Briefly describe the review of this document that was performed by = the Document Shepherd. If this version of the document is not ready for pub= lication, please explain why the document is being forwarded to the IESG. This document has been adequately reviewed. (3) Does the document Shepherd have any concerns about the depth or bre= adth of the reviews that have been performed? No concerns. (4) Do portions of the document need review from a particular or from b= roader perspective, e.g., security, operational complexity, AAA, DNS, DHCP,= XML, or internationalization? If so, describe the review that took place. No. (5) Describe any specific concerns or issues that the Document Shepherd= has with this document that the Responsible Area Director and/or the IESG = should be aware of? For example, perhaps he or she is uncomfortable with ce= rtain parts of the document, or has concerns whether there really is a need= for it. In any event, if the WG has discussed those issues and has indicat= ed that it still wishes to advance the document, detail those concerns here= . No concerns. (6) Has each author confirmed that any and all appropriate IPR disclosu= res required for full conformance with the provisions of BCP 78 and BCP 79 = have already been filed. If not, explain why? Yes. (7) Has an IPR disclosure been filed that references this document? If = so, summarize any WG discussion and conclusion regarding the IPR disclosure= s. No IPR. (8) How solid is the WG consensus behind this document? Does it represe= nt the strong concurrence of a few individuals, with others being silent, o= r does the WG as a whole understand and agree with it? WG supports this document. (9) Has anyone threatened an appeal or otherwise indicated extreme disc= ontent? If so, please summarise the areas of conflict in separate email mes= sages to the Responsible Area Director. (It should be in a separate email b= ecause this questionnaire is publicly available.) No. (10) Identify any ID nits the Document Shepherd has found in this docume= nt. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklis= t). Boilerplate checks are not enough; this check needs to be thorough. No issues. (11) Describe how the document meets any required formal review criteria= , such as the MIB Doctor, media type, and URI type reviews. Not applicable. (12) Have all references within this document been identified as either = normative or informative? Yes. (13) Are there normative references to documents that are not ready for = advancement or are otherwise in an unclear state? If such normative referen= ces exist, what is the plan for their completion? No. (14) Are there downward normative references references (see RFC 3967)? = If so, list these downward references to support the Area Director in the L= ast Call procedure. No. (15) Will publication of this document change the status of any existing= RFCs? Are those RFCs listed on the title page header, listed in the abstra= ct, and discussed in the introduction? If the RFCs are not listed in the Ab= stract and Introduction, explain why, and point to the part of the document= where the relationship of this document to the other RFCs is discussed. If= this information is not in the document, explain why the WG considers it u= nnecessary. Yes, the RFCs are listed. Updates: 3471, 4202, 4203, 5307. (16) Describe the Document Shepherd's review of the IANA considerations = section, especially with regard to its consistency with the body of the doc= ument. Confirm that all protocol extensions that the document makes are ass= ociated with the appropriate reservations in IANA registries. Confirm that = any referenced IANA registries have been clearly identified. Confirm that n= ewly created IANA registries include a detailed specification of the initia= l contents for the registry, that allocations procedures for future registr= ations are defined, and a reasonable name for the new registry has been sug= gested (see RFC 5226). IANA considerations section is clearly identified and appears appropriat= e. (17) List any new IANA registries that require Expert Review for future = allocations. Provide any public guidance that the IESG would find useful in= selecting the IANA Experts for these new registries. Not applicable. (18) Describe reviews and automated checks performed by the Document She= pherd to validate sections of the document written in a formal language, su= ch as XML code, BNF rules, MIB definitions, etc. Not applicable. --_000_F64C10EAA68C8044B33656FA214632C8356C13MISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Proto write-up for: draft-ietf-ccamp-swcaps-update
  1. What type of RFC is being r= equested (BCP, Proposed Standard, Internet Standard, Informational, Experim= ental, or Historic)? Why is this the proper type of RFC? Is this type of RF= C indicated in the title page header?
    2.
Proposed Standar= d. Updates Standards Track documents. Yes.
(2) The IESG approval announcement= includes a Document Announcement Write-Up. Please provide such a Document = Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Th= e approval announcement contains the following sections:
Technical Summar= y:
Relevant content= can frequently be found in the abstract and/or introduction of the documen= t. If not, this may be an indication that there are deficiencies in the abstract or introduction.
GMPLS provides c= ontrol for multiple switching technologies, and hierarchical switching with= in a technology.  GMPLS routing and signaling use common values to indicate switching technology type. These values are c= arried in routing in the Switching Capability field, and in signaling in th= e Switching Type field. While the values used in these fields are the prima= ry indicators of the technology and hierarchy level being controlled, the values are not consistently defin= ed and used across the different technologies supported by GMPLS.  Thi= s document is intended to resolve the inconsistent definition and use of th= e Switching Capability and Type fields by narrowly scoping the meaning and use of the fields.  This document = updates any document that uses the GMPLS Switching Capability and Types fie= lds, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307.
Working Group Su= mmary:
Was there anythi= ng in WG process that is worth noting? For example, was there controversy a= bout particular points or were there decisions where the consensus was particularly rough?
No. Good support= by the WG.
Document Quality= :
Are there existi= ng implementations of the protocol? Have a significant number of vendors in= dicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thoroug= h review, e.g., one that resulted in important changes or a conclusion that= the document had no substantive issues? If there was a MIB Doctor, Media T= ype or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date = was the request posted?
This document up= dates the definitions for the Switching Type field to be consistent and dep= recates three previously defined switching types. For existing implementations, the primary impact of this document is= deprecating the use of PSC-2, 3 and 4.  At the time of publication, t= here are no known deployments (or even implementations) that make use of th= ese values so there is no compatibility issues for current routing and signaling implementations.
Personnel:
Who is the Docum= ent Shepherd? Who is the Responsible Area Director?
Deborah Brungard= is the Document Shepherd. Adrian Farrel is the Area Director.
  1. Briefly describe the review= of this document that was performed by the Document Shepherd. If this vers= ion of the document is not ready for publication, please explain why the do= cument is being forwarded to the IESG.
This document= has been adequately reviewed.
  1. Does the document Shepherd = have any concerns about the depth or breadth of the reviews that have been = performed?
No concerns.<= /span>
  1. Do portions of the document= need review from a particular or from broader perspective, e.g., security,= operational complexity, AAA, DNS, DHCP, XML, or internationalization? If s= o, describe the review that took place.
No.
  1. Describe any specific conce= rns or issues that the Document Shepherd has with this document that the Re= sponsible Area Director and/or the IESG should be aware of? For example, pe= rhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a ne= ed for it. In any event, if the WG has discussed those issues and has indic= ated that it still wishes to advance the document, detail those concerns he= re.
No concerns.<= /span>
  1. Has each author confirmed t= hat any and all appropriate IPR disclosures required for full conformance w= ith the provisions of BCP 78 and BCP 79 have already been filed. If not, ex= plain why?
    2.
Yes.
  1. Has an IPR disclosure been = filed that references this document? If so, summarize any WG discussion and= conclusion regarding the IPR disclosures.
No IPR.
  1. How solid is the WG consens= us behind this document? Does it represent the strong concurrence of a few = individuals, with others being silent, or does the WG as a whole understand= and agree with it?
WG supports t= his document.
  1. Has anyone threatened an ap= peal or otherwise indicated extreme discontent? If so, please summarise the= areas of conflict in separate email messages to the Responsible Area Direc= tor. (It should be in a separate email because this questionnaire is publicly available.)
No.
  1. Identify any ID nits the Do= cument Shepherd has found in this document. (See http://www.ietf.org/tools/idn= its/ and the Internet-Drafts Checklist). Boilerplate checks are not eno= ugh; this check needs to be thorough.
No issues.
  1. Describe how the document m= eets any required formal review criteria, such as the MIB Doctor, media typ= e, and URI type reviews.
Not applicabl= e.
  1. Have all references within = this document been identified as either normative or informative?
Yes.
  1. Are there normative referen= ces to documents that are not ready for advancement or are otherwise in an = unclear state? If such normative references exist, what is the plan for the= ir completion?
No.
  1. Are there downward normativ= e references references (see RFC 3967)? If so, list these downward referenc= es to support the Area Director in the Last Call procedure.
No.
  1. Will publication of this do= cument change the status of any existing RFCs? Are those RFCs listed on the= title page header, listed in the abstract, and discussed in the introducti= on? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the do= cument where the relationship of this document to the other RFCs is discuss= ed. If this information is not in the document, explain why the WG consider= s it unnecessary.
Yes, the RFCs= are listed. Updates: 3471, 4202, 4203, 5307.
  1. Describe the Document Sheph= erd's review of the IANA considerations section, especially with regard to = its consistency with the body of the document. Confirm that all protocol ex= tensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm th= at any referenced IANA registries have been clearly identified. Confirm tha= t newly created IANA registries include a detailed specification of the ini= tial contents for the registry, that allocations procedures for future registrations are defined, and a rea= sonable name for the new registry has been suggested (see RFC 5226).
    2. <= /span>
IANA consider= ations section is clearly identified and appears appropriate.=
  1. List any new IANA registrie= s that require Expert Review for future allocations. Provide any public gui= dance that the IESG would find useful in selecting the IANA Experts for the= se new registries.
Not applicabl= e.
  1. Describe reviews and automa= ted checks performed by the Document Shepherd to validate sections of the d= ocument written in a formal language, such as XML code, BNF rules, MIB defi= nitions, etc.
Not applicabl= e.
 
 
--_000_F64C10EAA68C8044B33656FA214632C8356C13MISOUT7MSGUSR9OIT_-- From wang.qilei@zte.com.cn Mon Aug 12 17:23:37 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879C021F9C12 for ; Mon, 12 Aug 2013 17:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.175 X-Spam-Level: X-Spam-Status: No, score=-100.175 tagged_above=-999 required=5 tests=[AWL=2.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkmWJbsgK3BP for ; Mon, 12 Aug 2013 17:23:20 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA3521F9C4A for ; Mon, 12 Aug 2013 17:23:19 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id A25D0107E2C for ; Tue, 13 Aug 2013 08:22:53 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 753C2720385; Tue, 13 Aug 2013 08:22:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r7D0MsQx005423; Tue, 13 Aug 2013 08:22:54 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn) In-Reply-To: References: To: "BRUNGARD, DEBORAH A" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" MIME-Version: 1.0 X-KeepSent: B58FF456:BE7A05B3-48257BC6:000197FE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.qilei@zte.com.cn Date: Tue, 13 Aug 2013 08:22:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-08-13 08:22:52, Serialize complete at 2013-08-13 08:22:52 Content-Type: multipart/alternative; boundary="=_alternative 0002206848257BC6_=" X-MAIL: mse01.zte.com.cn r7D0MsQx005423 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 00:23:37 -0000 This is a multipart message in MIME format. --=_alternative 0002206848257BC6_= Content-Type: text/plain; charset="US-ASCII" Hi, all No, I'm not aware of any IPR that applies to this draft. Thanks Qilei Wang --=_alternative 0002206848257BC6_= Content-Type: text/html; charset="US-ASCII" Hi, all

No, I'm not aware of any IPR that applies to this draft.

Thanks
Qilei Wang --=_alternative 0002206848257BC6_=-- From zhangfatai@huawei.com Mon Aug 12 18:57:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C1421F91B7 for ; Mon, 12 Aug 2013 18:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZCLaFDVSYPx for ; Mon, 12 Aug 2013 18:56:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4648921F9935 for ; Mon, 12 Aug 2013 18:54:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUI07429; Tue, 13 Aug 2013 01:54:11 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 13 Aug 2013 02:53:42 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 13 Aug 2013 02:54:09 +0100 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.110]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Tue, 13 Aug 2013 09:54:03 +0800 From: Fatai Zhang To: John E Drake , Daniele Ceccarelli , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACdi0mD//4LQgIAEQ08AgAApG4D//uUdoA== Date: Tue, 13 Aug 2013 01:54:02 +0000 Message-ID: References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se> <403c214579834abf91393c4a1cd2c4dd@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <403c214579834abf91393c4a1cd2c4dd@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 01:57:21 -0000 Hi John, Agree.=20 We should figure out use case, applicability, requirement, framework, etc, = and then go to solution. Otherwise, it is really not a good idea to drive s= omething by some specific solutions.=20 Best Regards Fatai -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Tuesday, August 13, 2013 12:56 AM To: Daniele Ceccarelli; Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@= ietf.org) Cc: Adrian Farrel Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.= txt Daniele, Comments inline. However, the discussions since Berlin on UNI enhancements= and/or adding additional information related to path computation into the = PATH message lead me to the conclusion that we have a problem in CCAMP and = that we really should suspend all solutions related work until we have a be= tter idea of the problem we wish to solve. If you don't think we have a problem, please consider the list of active CC= AMP drafts: http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro/ http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/ http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-srlg-collect/ http://datatracker.ietf.org/doc/draft-ietf-ccamp-te-metric-recording/ http://datatracker.ietf.org/doc/draft-ali-ccamp-extended-srlg/ http://datatracker.ietf.org/doc/draft-ali-ccamp-gmpls-uni-error-notificatio= n/ http://datatracker.ietf.org/doc/draft-ali-ccamp-lsp-inquiry/ http://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function-metri= c-bound/ http://datatracker.ietf.org/doc/draft-bardalai-ccamp-overlay-path-comp/ http://datatracker.ietf.org/doc/draft-ceccadedios-ccamp-overlay-use-cases/ http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain-subobjects= / http://datatracker.ietf.org/doc/draft-fedyk-ccamp-uni-extensions/ http://datatracker.ietf.org/doc/draft-gandhi-ccamp-gmpls-restoration-lsp/ Yours Irrespectively, John > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Monday, August 12, 2013 7:29 AM > To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP > (ccamp@ietf.org) > Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > Hi John, all, >=20 > I think there are cases in which the PCEP can't solve the issue. Suppose = for > example the simple network below >=20 > C1 --- C2 --- C3 C4 --- C5 --- C6 > \ / > S1 --- S2 --- S3 >=20 > Where Cx are the client nodes and Sx the server nodes and C3-S1 and S3-C4 > the UNIs. > The usual behavior for the setup of an LSP in the client domain between C= 1 > and C6 consists on 1. "asking" C3 to setup a link in the client layer be= tween > C3 and C4 and 2. after its provisioning, "asking" C1to setup an LSP betwe= en > C1 and C6 using the link between C3 and C4. JD: No, that's incorrect. The C1-C6 Path message arrives at C3. It trigg= ers C3 to establish a C3-C4 LSP. After this LSP is established, C3 forwards the C1-C= 6 Path message to C4. We already have CCAMP drafts from, I believe, Cyril and/or = Fatai that describe how to embed the desired characteristics of the C3-C4 LSP wit= hin the ERO of the C1-C6 Path message. =20 >=20 > If you suppose to have a simpler approach consisting on a single step, it > would be possible to "ask" C1 to setup an end to end LSP between C1 and C= 6 > with loose ERO C1-C3-C4-C6. JD: See above. This has been a part of GMPLS since its inception. >=20 > In the first case the trigger on C3 is provided by the operator with give= n > constraints (e.g. Objective functions and/or TE metric bounds) and it wou= ld > be easy to inject them into a PCEP request towards the PCE of the server > domains, but what happens in the second case? The operator only issues a > command to C1, which starts a signaling procedure. The RSVP-TE message > reaches C3 and triggers the setup of the link C3-C4 over the UNI. JD: See above. The second case is actually the GMPLS baseline behavior. >=20 > IMHO putting the Objective Functions into RSVP-TE is useful to "convey" > such path computation requirements from C1 to C3. Once the PATH message > reaches C3, it can ask S1 to compute the path towards C4 via RSVP-TE or c= an > ask the server layer PCE via PCEP. JD: In addition to what is described above, it is also possible for C1 to= use PCEP to expand the C3-C4 ERO and place the key associated with this expansion in= the ERO of the C1-C6 Path message. =20 >=20 > This is one of the two reasons why I think that Objective Functions and T= E > metric Bounds could be useful in RSVP-TE. The second one is that I agree > with Matt when saying that not in all cases the client nodes will be allo= wed to > access the server layer PCE. JD: The draft is proposing to embed PCEP within signaling. By definition,= this *is* allowing the client to access the server layer PCE. This is no differ= ent than allowing the client to access the server layer PCE without embedding PCE within signaling. >=20 > BR > Daniele >=20 >=20 >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of John E Drake > > Sent: venerd=EC 9 agosto 2013 23:23 > > To: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org) > > Subject: Re: [CCAMP] > > draft-ali-ccamp-rc-objective-function-metric-bound- > > 03.txt > > > > PCEP can be deployed whenever the server network wishes to provide a > > path computation service. What possible advantage to anyone is gained > > by embedding PCEP in RSVP-TE signaling? > > > > Yours Irrespectively, > > > > John > > > > > -----Original Message----- > > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > > Sent: Friday, August 09, 2013 1:53 PM > > > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > > > Cc: Matt Hartley (mhartley) > > > Subject: RE: [CCAMP] > > > draft-ali-ccamp-rc-objective-function-metric-bound- > > > 03.txt > > > > > > Fatai, John, > > > > > > I don't think you can guarantee that PCE will be deployed absolutely > > > everywhere, or that you can guarantee the client will be permitted > > > access to the server PCE when it is. In those cases, this draft is us= eful. > > > > > > Cheers > > > > > > Matt > > > > > > > Hi John, > > > > > > > > Completely agree. > > > > > > > > I also raised this comment in front of the mic during Berlin meetin= g. > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of John E Drake > > > > Sent: Friday, August 09, 2013 1:49 AM > > > > To: CCAMP (ccamp@ietf.org) > > > > Subject: [CCAMP] > > > > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt > > > > > > > > Hi, > > > > > > > > I have a real concern with this draft because it appears to be > > > > heading us down the road of re-inventing PCEP in RSVP signaling > > > > with the dubious justification that it is needed in those > > > > situations in which a PCE is not available. However, if you > > > > re-invent PCEP in RSVP signaling, then you have effectively > > > > ensured that there are no situations in which a PCE or its signalin= g > equivalent are not available. > > > > > > > > Why is this better than simply ensuring that a PCE is available in > > > > those situations in which it is needed? > > > > > > > > Yours Irrespectively, > > > > > > > > John > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp >=20 From ke-kumaki@kddi.com Mon Aug 12 19:05:11 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3211E8104 for ; Mon, 12 Aug 2013 19:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3nXuE2yzxbv for ; Mon, 12 Aug 2013 19:05:06 -0700 (PDT) Received: from UTMC1103.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id C963F11E8103 for ; Mon, 12 Aug 2013 19:05:03 -0700 (PDT) Received: from UTMC1131 (unknown [10.5.16.192]) by UTMC1103.kddi.com (Postfix) with SMTP id 65C971D26; Tue, 13 Aug 2013 11:05:01 +0900 (JST) Received: from UTMC1122.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 0BE1121E1; Tue, 13 Aug 2013 11:05:00 +0900 (JST) Received: from LTMC1004.kddi.com (unknown [10.5.16.215]) by UTMC1122.kddi.com (Postfix) with ESMTP id E53601EEC; Tue, 13 Aug 2013 11:04:59 +0900 (JST) Received: from LTMC1004.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1004.kddi.com with ESMTP id r7D24x1R013739; Tue, 13 Aug 2013 11:04:59 +0900 Received: from LTMC1004.kddi.com.mid_20100659 (localhost.localdomain [127.0.0.1]) by LTMC1004.kddi.com with ESMTP id r7D24cnX013491; Tue, 13 Aug 2013 11:04:39 +0900 Received: from KDDI1202PC0730 ([10.200.129.120] [10.200.129.120]) by post-zip.kddi.com with ESMTPA; Tue, 13 Aug 2013 11:04:38 +0900 From: "Kenji Kumaki" To: "'BRUNGARD, DEBORAH A'" , References: <9D50FCE7413E3D4EA5E42331115FB5BC105B132E@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC105B132E@xmb-rcd-x03.cisco.com> Date: Tue, 13 Aug 2013 11:04:38 +0900 Message-Id: <002e01ce97c9$774e1670$65ea4350$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+WN5Kn+fyUNr8lLW+VpaEQLokxQE8Ks4lmCj+hvA= Content-Language: ja X-SA-MID: 20100659 X-WAuditID: 1308131105000000109650 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-lsp-diversity X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 02:05:11 -0000 Hi, No, I'm not aware of any IPR that applies to this draft. Thanks, Kenji -----Original Message----- From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: Friday, August 09, 2013 2:07 PM To: draft-ietf-ccamp-lsp-diversity@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-lsp-diversity Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From gyzhang@sina.com Mon Aug 12 19:23:48 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E530611E80FE for ; Mon, 12 Aug 2013 19:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.026 X-Spam-Level: **** X-Spam-Status: No, score=4.026 tagged_above=-999 required=5 tests=[FROM_EXCESS_BASE64=1.984, FR_IMPORT_CSS=1.889, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpMYexPCO9U4 for ; Mon, 12 Aug 2013 19:23:43 -0700 (PDT) Received: from smtp2911-211.mail.sina.com.cn (mail2-157.sinamail.sina.com.cn [60.28.2.157]) by ietfa.amsl.com (Postfix) with SMTP id E295121E8054 for ; Mon, 12 Aug 2013 19:23:41 -0700 (PDT) Received: from unknown( HELO X220)([211.157.163.39]) by sina.com with ESMTP 13 Aug 2013 10:23:39 +0800 (CST) X-Sender: gyzhang@sina.com X-Auth-ID: gyzhang@sina.com X-SMAIL-MID: 5037218668429 Date: Tue, 13 Aug 2013 10:23:36 +0800 From: "=?utf-8?B?Z3l6aGFuZw==?=" To: "=?utf-8?B?TG91IEJlcmdlcg==?=" , "=?utf-8?B?WWV5YWJpbiAoWWFiaW4p?=" , "=?utf-8?B?Q2hlbm1pbmcgKE5XUmVzZWFyY2gp?=" , "=?utf-8?B?RmF0YWkgWmhhbmc=?=" , "=?utf-8?B?TGVleW91bmc=?=" , "=?utf-8?B?SGFuamlhbnJ1aQ==?=" , "=?utf-8?B?Z3JlZ2JAZ3JvdHRvLW5ldHdvcmtpbmcuY29t?=" , "=?utf-8?B?eHV5dW5iaW5AbWFpbC5yaXR0LmNvbS5jbg==?=" , "=?utf-8?B?emhhbmdndW95aW5nQG1haWwucml0dC5jb20uY24=?=" , "=?utf-8?B?TGlkYW4oRGFuKQ==?=" References: <51E83C58.6010602@labn.net>, , <576290786.09235@mail.ritt.com.cn> Message-ID: <201308131023365047305@sina.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon318602817783_=====" Cc: =?utf-8?B?Y2NhbXBAaWV0Zi5vcmc=?= Subject: Re: [CCAMP] =?utf-8?q?Regarding_IPR_ondraft-ietf-ccamp-gmpls-general-?= =?utf-8?q?constraints-ospf-te?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 02:23:48 -0000 This is a multi-part message in MIME format. --=====003_Dragon318602817783_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdC4NCg0KR3VveWluZyBaaGFuZyAgIA0KUmVzZWFyY2ggSW5zdGl0dXRlIG9mIFRlbGVj b21tdW5pY2F0aW9ucyBUcmFuc21pc3Npb24gKFJJVFQpLA0KQ2hpbmEgQWNhZGVteSBvZiBUZWxl Y29tLiBSZXNlYXJjaCAoQ0FUUiksIE1JSVQNCiANClRFTDogODYtMTAtNjIzMDAxMDMsIDE4OTEw ODQ1MDI2LCAxMzkxMDM5NTAyNg0KRS1tYWlsOiB6aGFuZ2d1b3lpbmdAcml0dC5jbiAsIHpoYW5n Z3VveWluZ0BjYXRyLmNuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIA0KDQpMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdl ckBsYWJuLm5ldF0gDQoyMDEz5bm0N+aciDE55pelIDM6MDUNCkZhdGFpIFpoYW5nOyBMZWV5b3Vu ZzsgSGFuamlhbnJ1aTsgZ3JlZ2JAZ3JvdHRvLW5ldHdvcmtpbmcuY29tOyB4dXl1bmJpbkBtYWls LnJpdHQuY29tLmNuOyB6aGFuZ2d1b3lpbmdAbWFpbC5yaXR0LmNvbS5jbjsgTGlkYW4gKERhbik7 IENoZW5taW5nIChOV1Jlc2VhcmNoKTsgWWV5YWJpbiAoWWFiaW4pDQpjY2FtcEBpZXRmLm9yZw0K UmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWlu dHMtb3NwZi10ZQ0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCAoQ0NBTVApDQpBcyBwYXJ0IG9mIHRo ZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBDYWxsOg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBS IHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPw0KICBQbGVhc2Ugc3RhdGUg ZWl0aGVyOg0KICAiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8g dGhpcyBkcmFmdCINCiAgb3INCiAgIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMg dG8gdGhpcyBkcmFmdCINCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29t cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBh bmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCiAgIElmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFz ZSBzdGF0ZSBlaXRoZXI6DQogICJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNv bXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCiAgb3INCiAgIk5vLCB0aGUgSVBSIGhhcyBu b3QgYmVlbiBkaXNjbG9zZWQiDQogIElmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFu eSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rDQogIGFwcHJvcHJpYXRlLg0KSWYgeW91IGFy ZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dl ciB0aGUNCmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdo ZXRoZXIgb3Igbm90IHlvdSBhcmUNCmF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuICBUaGlzIGRv Y3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCnN0YWdlIHVudGlsIGEgcmVzcG9u c2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkDQpjb250cmli dXRvci4gIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTDQpN RVNTQUdFJ1MgVE8gTElORVMuDQpJZiB5b3UgYXJlIG9uIHRoZSBDQ0FNUCBXRyBlbWFpbCBsaXN0 IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3INCmNvbnRyaWJ1dG9yLCB3ZSByZW1p bmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzDQp3aGlj aCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJ UFIgb2YNCm90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9t IHBhcnRpY2lwYXRpbmcgaW4gYW55DQpjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVk IHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiAgRm9yIG1vcmUNCmluZm9ybWF0aW9uLCBwbGVhc2Ug c2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KVGhhbmsgeW91LA0K Q0NBTVAgV0cgQ2hhaXJzDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFk ZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQpyZXNwb25zZS4NCg== --=====003_Dragon318602817783_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6b2ZmaWNlIj48SEVBRD4NCjxTVFlMRSB0eXBlPXRleHQvY3NzPkBpbXBvcnQgdXJsKCBDOlxV c2Vyc1x6aGFuZ2d1b3lpbmdcQXBwRGF0YVxMb2NhbFxNaWNyb3NvZnRcV2luZG93c1xUZW1wb3Jh cnkgSW50ZXJuZXQgRmlsZXNcc2Nyb2xsYmFyLmNzcyApOw0KPC9TVFlMRT4NCg0KPFNUWUxFIHR5 cGU9dGV4dC9jc3M+QGltcG9ydCB1cmwoIEM6XFVzZXJzXHpoYW5nZ3VveWluZ1xBcHBEYXRhXExv Y2FsXE1pY3Jvc29mdFxXaW5kb3dzXFRlbXBvcmFyeSBJbnRlcm5ldCBGaWxlc1xzY3JvbGxiYXIu Y3NzICk7DQo8L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRG LTgiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVu dD0iTVNIVE1MIDEwLjAwLjkyMDAuMTY2MzUiPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDlrovkvZM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFuYTsN Cn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L5L2TOw0KfQ0KQHBhZ2UgU2VjdGlv bjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6 IDEwLjVwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0 aWZ5OyBNQVJHSU46IDBjbSAwY20gMHB0OyBURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaA0K fQ0KTEkuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEwLjVwdDsgRk9OVC1GQU1JTFk6ICJUaW1l cyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5OyBNQVJHSU46IDBjbSAwY20gMHB0OyBU RVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJRk9OVC1T SVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjog anVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3Jh cGgNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5l DQp9DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElP TjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVy cGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0K CUZPTlQtRkFNSUxZOiBWZXJkYW5hOyBGT05ULVdFSUdIVDogbm9ybWFsOyBDT0xPUjogd2luZG93 dGV4dDsgRk9OVC1TVFlMRTogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHls ZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rp b24xDQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1B UkdJTi1CT1RUT006IDBweDsgTUFSR0lOLUxFRlQ6IDJlbTsgTUFSR0lOLVRPUDogMHB4DQp9DQpP TCB7DQoJTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgNCn0NClVMIHsNCglNQVJH SU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hIj4NCjxESVY+ PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT5IaSBhbGwsPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTIgDQpmYWNlPVZlcmRhbmE+Tm8sJm5ic3A7SSdtJm5ic3A7bm90Jm5ic3A7YXdhcmUm bmJzcDtvZiZuYnNwO2FueSZuYnNwO0lQUiZuYnNwO3RoYXQmbmJzcDthcHBsaWVzJm5ic3A7dG8m bmJzcDt0aGlzJm5ic3A7ZHJhZnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAw MDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBj b2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNQQU4+PFNQQU4gY2xhc3M9U3BlbGxF IA0Kc3R5bGU9Im1zby1zdHlsZS1uYW1lOiAnJzsgbXNvLXNwbC1lOiB5ZXMiPjxTUEFOIGxhbmc9 RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBS b21hbicsJ3NlcmlmJzsgQ09MT1I6ICMxNzM2NWQ7IG1zby10aGVtZWNvbG9yOiB0ZXh0MjsgbXNv LWJpZGktZm9udC1zaXplOiAxMC41cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTVFhpaGVp OyBtc28tdGhlbWVzaGFkZTogMTkxIj5HdW95aW5nPC9TUEFOPjwvU1BBTj48U1BBTiANCmxhbmc9 RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBS b21hbicsJ3NlcmlmJzsgQ09MT1I6ICMxNzM2NWQ7IG1zby10aGVtZWNvbG9yOiB0ZXh0MjsgbXNv LWJpZGktZm9udC1zaXplOiAxMC41cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTVFhpaGVp OyBtc28tdGhlbWVzaGFkZTogMTkxIj4gDQpaaGFuZzxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7Jm5ic3A7PC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9 IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7 IENPTE9SOiAjMTczNjVkOyBtc28tdGhlbWVjb2xvcjogdGV4dDI7IG1zby1iaWRpLWZvbnQtc2l6 ZTogMTAuNXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU1RYaWhlaTsgbXNvLXRoZW1lc2hh ZGU6IDE5MSI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9ESVY+DQo8RElWPg0KPERJVj4NCjxE SVYgY2xhc3M9U2VjdGlvbjEgc3R5bGU9InBhZ2U6IFNlY3Rpb24xIj4NCjxESVY+DQo8RElWPg0K PFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6 IFNpbVN1bjsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXN0eWxlLXVuaGlkZTogbm87IG1zby1z dHlsZS1xZm9ybWF0OiB5ZXM7IG1zby1zdHlsZS1wYXJlbnQ6ICcnOyBtc28tcGFnaW5hdGlvbjog d2lkb3ctb3JwaGFuOyBtc28tYmlkaS1mb250LWZhbWlseTogU2ltU3VuIj48U1BBTiANCmxhbmc9 RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBS b21hbicsJ3NlcmlmJzsgQ09MT1I6ICMxNzM2NWQ7IG1zby10aGVtZWNvbG9yOiB0ZXh0MjsgbXNv LWJpZGktZm9udC1zaXplOiAxMC41cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTVFhpaGVp OyBtc28tdGhlbWVzaGFkZTogMTkxIj5SZXNlYXJjaCANCkluc3RpdHV0ZSBvZiBUZWxlY29tbXVu aWNhdGlvbnMgVHJhbnNtaXNzaW9uIChSSVRUKSw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogU2lt U3VuOyBNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tc3R5bGUtdW5oaWRlOiBubzsgbXNvLXN0eWxl LXFmb3JtYXQ6IHllczsgbXNvLXN0eWxlLXBhcmVudDogJyc7IG1zby1wYWdpbmF0aW9uOiB3aWRv dy1vcnBoYW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBTaW1TdW4iPjxTUEFOIA0KY2xhc3M9R3Jh bUUgc3R5bGU9Im1zby1zdHlsZS1uYW1lOiAnJzsgbXNvLWdyYW0tZTogeWVzIj48U1BBTiBsYW5n PUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcg Um9tYW4nLCdzZXJpZic7IENPTE9SOiAjMTczNjVkOyBtc28tdGhlbWVjb2xvcjogdGV4dDI7IG1z by1iaWRpLWZvbnQtc2l6ZTogMTAuNXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU1RYaWhl aTsgbXNvLXRoZW1lc2hhZGU6IDE5MSI+Q2hpbmEgDQpBY2FkZW15IG9mIFRlbGVjb20uPC9TUEFO PjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1G QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiAjMTczNjVkOyBtc28tdGhl bWVjb2xvcjogdGV4dDI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuNXB0OyBtc28tZmFyZWFzdC1m b250LWZhbWlseTogU1RYaWhlaTsgbXNvLXRoZW1lc2hhZGU6IDE5MSI+IA0KUmVzZWFyY2ggKENB VFIpLCBNSUlUPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5 bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IFNpbVN1bjsgTUFSR0lOOiAwY20gMGNt IDBwdDsgbXNvLXN0eWxlLXVuaGlkZTogbm87IG1zby1zdHlsZS1xZm9ybWF0OiB5ZXM7IG1zby1z dHlsZS1wYXJlbnQ6ICcnOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyBtc28tYmlkaS1m b250LWZhbWlseTogU2ltU3VuIj48U1BBTiANCmxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpF OiAxMXB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6ICMx NzM2NWQ7IG1zby10aGVtZWNvbG9yOiB0ZXh0MjsgbXNvLWJpZGktZm9udC1zaXplOiAxMC41cHQ7 IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTVFhpaGVpOyBtc28tdGhlbWVzaGFkZTogMTkxIj48 bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogU2ltU3VuOyBNQVJHSU46IDBjbSAwY20gMHB0 OyBtc28tc3R5bGUtdW5oaWRlOiBubzsgbXNvLXN0eWxlLXFmb3JtYXQ6IHllczsgbXNvLXN0eWxl LXBhcmVudDogJyc7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IG1zby1iaWRpLWZvbnQt ZmFtaWx5OiBTaW1TdW4iPjxTUEFOIA0KbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEx cHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogIzE3MzY1 ZDsgbXNvLXRoZW1lY29sb3I6IHRleHQyOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjVwdDsgbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IFNUWGloZWk7IG1zby10aGVtZXNoYWRlOiAxOTEiPlRFTDog DQo4Ni0xMC02MjMwMDEwMywgMTg5MTA4NDUwMjYsIDEzOTEwMzk1MDI2PG86cD48L286cD48L1NQ QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9O VC1GQU1JTFk6IFNpbVN1bjsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXN0eWxlLXVuaGlkZTog bm87IG1zby1zdHlsZS1xZm9ybWF0OiB5ZXM7IG1zby1zdHlsZS1wYXJlbnQ6ICcnOyBtc28tcGFn aW5hdGlvbjogd2lkb3ctb3JwaGFuOyBtc28tYmlkaS1mb250LWZhbWlseTogU2ltU3VuIj48U1BB TiANCmxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6ICMxNzM2NWQ7IG1zby10aGVtZWNvbG9yOiB0 ZXh0MjsgbXNvLWJpZGktZm9udC1zaXplOiAxMC41cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiBTVFhpaGVpOyBtc28tdGhlbWVzaGFkZTogMTkxIj5FLW1haWw6IA0KPC9TUEFOPjxTUEFOIGxh bmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5l dyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6ICMxNzM2NWQ7IG1zby10aGVtZWNvbG9yOiB0ZXh0Mjsg bXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTVFhp aGVpOyBtc28tdGhlbWVzaGFkZTogMTkxIj48QSANCmhyZWY9Im1haWx0bzp5YW5nbGl3ZWlAcml0 dC5jbiIgdGFyZ2V0PV9ibGFuaz48U1BBTiANCnN0eWxlPSJDT0xPUjogIzE3MzY1ZDsgVEVYVC1E RUNPUkFUSU9OOiBub25lOyBtc28tdGhlbWVjb2xvcjogdGV4dDI7IG1zby1iaWRpLWZvbnQtc2l6 ZTogMTAuNXB0OyBtc28tdGhlbWVzaGFkZTogMTkxOyB0ZXh0LXVuZGVybGluZTogbm9uZSI+emhh bmdndW95aW5nQHJpdHQuY248L1NQQU4+PC9BPiANCiwgPEEgaHJlZj0ibWFpbHRvOnlhbmdsaXdl aUBjYXRyLmNuIj48U1BBTiANCnN0eWxlPSJDT0xPUjogIzE3MzY1ZDsgVEVYVC1ERUNPUkFUSU9O OiBub25lOyBtc28tdGhlbWVjb2xvcjogdGV4dDI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuNXB0 OyBtc28tdGhlbWVzaGFkZTogMTkxOyB0ZXh0LXVuZGVybGluZTogbm9uZSI+emhhbmdndW95aW5n QGNhdHIuY248L1NQQU4+PC9BPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05v cm1hbCANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW47IE1BUkdJ TjogMGNtIDBjbSAwcHQ7IG1zby1zdHlsZS11bmhpZGU6IG5vOyBtc28tc3R5bGUtcWZvcm1hdDog eWVzOyBtc28tc3R5bGUtcGFyZW50OiAnJzsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsg bXNvLWJpZGktZm9udC1mYW1pbHk6IFNpbVN1biI+PFNQQU4gDQpsYW5nPUVOLVVTIA0Kc3R5bGU9 IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7 IENPTE9SOiAjMTczNjVkOyBtc28tdGhlbWVjb2xvcjogdGV4dDI7IG1zby1iaWRpLWZvbnQtc2l6 ZTogMTAuNXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU1RYaWhlaTsgbXNvLXRoZW1lc2hh ZGU6IDE5MSI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3Jt YWwgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogU2ltU3VuOyBNQVJHSU46 IDBjbSAwY20gMHB0OyBtc28tc3R5bGUtdW5oaWRlOiBubzsgbXNvLXN0eWxlLXFmb3JtYXQ6IHll czsgbXNvLXN0eWxlLXBhcmVudDogJyc7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IG1z by1iaWRpLWZvbnQtZmFtaWx5OiBTaW1TdW4iPjxTUEFOIA0KbGFuZz1FTi1VUyANCnN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnIj48bzpw PiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9TUEFOPjwv Rk9OVD48L0RJVj48Rk9OVCANCnNpemU9MiBmYWNlPVZlcmRhbmE+DQo8RElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+TG91Jm5ic3A7QmVyZ2VyJm5ic3A7W21haWx0bzpsYmVyZ2VyQGxhYm4u bmV0XSZuYnNwOzwvRElWPg0KPERJVj4yMDEz5bm0N+aciDE55pelJm5ic3A7MzowNTwvRElWPg0K PERJVj5GYXRhaSZuYnNwO1poYW5nOyZuYnNwO0xlZXlvdW5nOyZuYnNwO0hhbmppYW5ydWk7Jm5i c3A7Z3JlZ2JAZ3JvdHRvLW5ldHdvcmtpbmcuY29tOyZuYnNwO3h1eXVuYmluQG1haWwucml0dC5j b20uY247Jm5ic3A7emhhbmdndW95aW5nQG1haWwucml0dC5jb20uY247Jm5ic3A7TGlkYW4mbmJz cDsoRGFuKTsmbmJzcDtDaGVubWluZyZuYnNwOyhOV1Jlc2VhcmNoKTsmbmJzcDtZZXlhYmluJm5i c3A7KFlhYmluKTwvRElWPg0KPERJVj48QSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNj YW1wQGlldGYub3JnPC9BPjwvRElWPg0KPERJVj5SZWdhcmRpbmcmbmJzcDtJUFImbmJzcDtvbiZu YnNwO2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlPC9E SVY+DQo8RElWPjwvRElWPg0KPERJVj5BdXRob3JzLCZuYnNwO0NvbnRyaWJ1dG9ycywmbmJzcDso Q0NBTVApPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5BcyZuYnNwO3BhcnQmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO3ByZXBhcmF0aW9uJm5ic3A7Zm9yJm5ic3A7V0cmbmJzcDtMYXN0Jm5ic3A7Q2Fs bDo8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkFyZSZuYnNwO3lvdSZuYnNwO2F3YXJlJm5ic3A7 b2YmbmJzcDthbnkmbmJzcDtJUFImbmJzcDt0aGF0Jm5ic3A7YXBwbGllcyZuYnNwO3RvJm5ic3A7 ZHJhZnQmbmJzcDtpZGVudGlmaWVkJm5ic3A7YWJvdmU/PC9ESVY+DQo8RElWPjwvRElWPg0KPERJ Vj4mbmJzcDsmbmJzcDtQbGVhc2UmbmJzcDtzdGF0ZSZuYnNwO2VpdGhlcjo8L0RJVj4NCjxESVY+ PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyJObywmbmJzcDtJJ20mbmJzcDtub3QmbmJzcDthd2Fy ZSZuYnNwO29mJm5ic3A7YW55Jm5ic3A7SVBSJm5ic3A7dGhhdCZuYnNwO2FwcGxpZXMmbmJzcDt0 byZuYnNwO3RoaXMmbmJzcDtkcmFmdCI8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7b3I8L0RJVj4N CjxESVY+Jm5ic3A7Jm5ic3A7IlllcywmbmJzcDtJJ20mbmJzcDthd2FyZSZuYnNwO29mJm5ic3A7 SVBSJm5ic3A7dGhhdCZuYnNwO2FwcGxpZXMmbmJzcDt0byZuYnNwO3RoaXMmbmJzcDtkcmFmdCI8 L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPklmJm5ic3A7c28sJm5ic3A7aGFzJm5ic3A7dGhpcyZu YnNwO0lQUiZuYnNwO2JlZW4mbmJzcDtkaXNjbG9zZWQmbmJzcDtpbiZuYnNwO2NvbXBsaWFuY2Um bmJzcDt3aXRoJm5ic3A7SUVURiZuYnNwO0lQUiZuYnNwO3J1bGVzPC9ESVY+DQo8RElWPihzZWUm bmJzcDtSRkNzJm5ic3A7Mzk3OSwmbmJzcDs0ODc5LCZuYnNwOzM2NjkmbmJzcDthbmQmbmJzcDs1 Mzc4Jm5ic3A7Zm9yJm5ic3A7bW9yZSZuYnNwO2RldGFpbHMpPzwvRElWPg0KPERJVj48L0RJVj4N CjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYmbmJzcDt5ZXMmbmJzcDt0byZuYnNwO3RoZSZuYnNw O2Fib3ZlLCZuYnNwO3BsZWFzZSZuYnNwO3N0YXRlJm5ic3A7ZWl0aGVyOjwvRElWPg0KPERJVj48 L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7IlllcywmbmJzcDt0aGUmbmJzcDtJUFImbmJzcDtoYXMm bmJzcDtiZWVuJm5ic3A7ZGlzY2xvc2VkJm5ic3A7aW4mbmJzcDtjb21wbGlhbmNlJm5ic3A7d2l0 aCZuYnNwO0lFVEYmbmJzcDtJUFImbmJzcDtydWxlcyI8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7 b3I8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Ik5vLCZuYnNwO3RoZSZuYnNwO0lQUiZuYnNwO2hh cyZuYnNwO25vdCZuYnNwO2JlZW4mbmJzcDtkaXNjbG9zZWQiPC9ESVY+DQo8RElWPjwvRElWPg0K PERJVj4mbmJzcDsmbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2Fuc3dlciZuYnNwO25vLCZuYnNwO3Bs ZWFzZSZuYnNwO3Byb3ZpZGUmbmJzcDthbnkmbmJzcDthZGRpdGlvbmFsJm5ic3A7ZGV0YWlscyZu YnNwO3lvdSZuYnNwO3RoaW5rPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwO2FwcHJvcHJpYXRlLjwv RElWPg0KPERJVj48L0RJVj4NCjxESVY+SWYmbmJzcDt5b3UmbmJzcDthcmUmbmJzcDtsaXN0ZWQm bmJzcDthcyZuYnNwO2EmbmJzcDtkb2N1bWVudCZuYnNwO2F1dGhvciZuYnNwO29yJm5ic3A7Y29u dHJpYnV0b3ImbmJzcDtwbGVhc2UmbmJzcDthbnN3ZXImbmJzcDt0aGU8L0RJVj4NCjxESVY+YWJv dmUmbmJzcDtieSZuYnNwO3Jlc3BvbmRpbmcmbmJzcDt0byZuYnNwO3RoaXMmbmJzcDtlbWFpbCZu YnNwO3JlZ2FyZGxlc3MmbmJzcDtvZiZuYnNwO3doZXRoZXImbmJzcDtvciZuYnNwO25vdCZuYnNw O3lvdSZuYnNwO2FyZTwvRElWPg0KPERJVj5hd2FyZSZuYnNwO29mJm5ic3A7YW55Jm5ic3A7cmVs ZXZhbnQmbmJzcDtJUFIuJm5ic3A7Jm5ic3A7VGhpcyZuYnNwO2RvY3VtZW50Jm5ic3A7d2lsbCZu YnNwO25vdCZuYnNwO2FkdmFuY2UmbmJzcDt0byZuYnNwO3RoZSZuYnNwO25leHQ8L0RJVj4NCjxE SVY+c3RhZ2UmbmJzcDt1bnRpbCZuYnNwO2EmbmJzcDtyZXNwb25zZSZuYnNwO2hhcyZuYnNwO2Jl ZW4mbmJzcDtyZWNlaXZlZCZuYnNwO2Zyb20mbmJzcDtlYWNoJm5ic3A7YXV0aG9yJm5ic3A7YW5k Jm5ic3A7bGlzdGVkPC9ESVY+DQo8RElWPmNvbnRyaWJ1dG9yLiZuYnNwOyZuYnNwO05PVEU6Jm5i c3A7VEhJUyZuYnNwO0FQUExJRVMmbmJzcDtUTyZuYnNwO0FMTCZuYnNwO09GJm5ic3A7WU9VJm5i c3A7TElTVEVEJm5ic3A7SU4mbmJzcDtUSElTPC9ESVY+DQo8RElWPk1FU1NBR0UnUyZuYnNwO1RP Jm5ic3A7TElORVMuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5JZiZuYnNwO3lvdSZuYnNwO2Fy ZSZuYnNwO29uJm5ic3A7dGhlJm5ic3A7Q0NBTVAmbmJzcDtXRyZuYnNwO2VtYWlsJm5ic3A7bGlz dCZuYnNwO2J1dCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO2xpc3RlZCZuYnNwO2FzJm5ic3A7YW4m bmJzcDthdXRob3ImbmJzcDtvcjwvRElWPg0KPERJVj5jb250cmlidXRvciwmbmJzcDt3ZSZuYnNw O3JlbWluZCZuYnNwO3lvdSZuYnNwO29mJm5ic3A7eW91ciZuYnNwO29ibGlnYXRpb25zJm5ic3A7 dW5kZXImbmJzcDt0aGUmbmJzcDtJRVRGJm5ic3A7SVBSJm5ic3A7cnVsZXM8L0RJVj4NCjxESVY+ d2hpY2gmbmJzcDtlbmNvdXJhZ2VzJm5ic3A7eW91Jm5ic3A7dG8mbmJzcDtub3RpZnkmbmJzcDt0 aGUmbmJzcDtJRVRGJm5ic3A7aWYmbmJzcDt5b3UmbmJzcDthcmUmbmJzcDthd2FyZSZuYnNwO29m Jm5ic3A7SVBSJm5ic3A7b2Y8L0RJVj4NCjxESVY+b3RoZXJzJm5ic3A7b24mbmJzcDthbiZuYnNw O0lFVEYmbmJzcDtjb250cmlidXRpb24sJm5ic3A7b3ImbmJzcDt0byZuYnNwO3JlZnJhaW4mbmJz cDtmcm9tJm5ic3A7cGFydGljaXBhdGluZyZuYnNwO2luJm5ic3A7YW55PC9ESVY+DQo8RElWPmNv bnRyaWJ1dGlvbiZuYnNwO29yJm5ic3A7ZGlzY3Vzc2lvbiZuYnNwO3JlbGF0ZWQmbmJzcDt0byZu YnNwO3lvdXImbmJzcDt1bmRpc2Nsb3NlZCZuYnNwO0lQUi4mbmJzcDsmbmJzcDtGb3ImbmJzcDtt b3JlPC9ESVY+DQo8RElWPmluZm9ybWF0aW9uLCZuYnNwO3BsZWFzZSZuYnNwO3NlZSZuYnNwO3Ro ZSZuYnNwO1JGQ3MmbmJzcDtsaXN0ZWQmbmJzcDthYm92ZSZuYnNwO2FuZDwvRElWPg0KPERJVj5o dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1 YWxQcm9wZXJ0eS48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRoYW5rJm5ic3A7eW91LDwvRElW Pg0KPERJVj5DQ0FNUCZuYnNwO1dHJm5ic3A7Q2hhaXJzPC9ESVY+DQo8RElWPjwvRElWPg0KPERJ Vj5QUyZuYnNwO1BsZWFzZSZuYnNwO2luY2x1ZGUmbmJzcDthbGwmbmJzcDtsaXN0ZWQmbmJzcDtp biZuYnNwO3RoZSZuYnNwO2hlYWRlcnMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5i c3A7aW4mbmJzcDt5b3VyPC9ESVY+DQo8RElWPnJlc3BvbnNlLjwvRElWPjwvRk9OVD48L0RJVj48 L0JPRFk+PC9IVE1MPg0K --=====003_Dragon318602817783_=====-- From daniele.ceccarelli@ericsson.com Tue Aug 13 01:21:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DE921F999E for ; Tue, 13 Aug 2013 01:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOo-3MyGmnMC for ; Tue, 13 Aug 2013 01:21:42 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 89C2E21F9ADF for ; Tue, 13 Aug 2013 01:21:39 -0700 (PDT) X-AuditID: c1b4fb38-b7f6d8e000006193-f8-5209ec915769 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 68.08.24979.19CE9025; Tue, 13 Aug 2013 10:21:38 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.105]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Tue, 13 Aug 2013 10:21:38 +0200 From: Daniele Ceccarelli To: John E Drake , "Matt Hartley (mhartley)" , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACdi0mD//+dlgP/7p/MwgAjEd4D//uHWkA== Date: Tue, 13 Aug 2013 08:21:37 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48137622@ESESSMB301.ericsson.se> References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se> <403c214579834abf91393c4a1cd2c4dd@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <403c214579834abf91393c4a1cd2c4dd@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvre6kN5xBBo828ln86LnBbPFkzg0W izl3nS3mvGS26Gs+z+rA6jHl90ZWj5Yjb1k9liz5yeRxvekqu8eKzSsZA1ijuGxSUnMyy1KL 9O0SuDKut3sV/PWp+HonpoGxwaaLkZNDQsBEYuHG/cwQtpjEhXvr2boYuTiEBI4ySmw9MYsR wlnCKPHq72KgKg4ONgEriSeHfEDiIgIrGSUWXDjNCtLNLKAucbT3EZgtLBAgMWf5RzYQW0Qg UOLt57lQdpjE+e3zwGpYBFQlXre+ZwGZySvgLfF3ez7Ern3MEvcXvASr4QSq3zvvPROIzSgg KzFh9yJGiF3iEreezGeCuFpAYsme81AfiEq8fPyPFcJWlGh/2gBVrydxY+oUNghbW2LZwtdg 9bwCghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRo7i1OKk3HQjg02MwNg6uOW3xQ7Gy39t DjFKc7AoifNu0TsTKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHx9BKFfR/2vtR2D3Y5e6S6 at2Vozn8K//OyUuTOODb/CHH5argi7+d3WbfhcM/hbzbl73gdNbceYwCfw3XxmW+i7ezMrs0 Wzvd4fE8r2NvS7tXKT46nfA7Us2n7doxn6CDkryJcsuaUxPv9xTc8zD41OhsWvDvdGHdZRX2 w3XHN/VFp5++aTxViaU4I9FQi7moOBEAz111PXsCAAA= Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 08:21:55 -0000 Hi John, That's an option, maybe a good one. By the way while it may seem like a large amount of documents, they do alig= n somewhat. The use cases do point to these other specific signaling extens= ions drafts, including the objective function draft.=20 We need to work a lot towards aligning the documents better. WRT your comments in line what I meant is that (as you pointed out) the GMP= LS already supports both of them, either the signaling of an end to end LSP= initiated by C1 via RSVP-TE or the signaling between C3 and C4 that genera= tes a link in the client layer (e.g. FA) and allows for its advertisement (= draft-previdi-isis-te-metric-extensions-03 and OSPF Traffic Engineering (TE= ) Metric Extensions) utilization e.g. via LDP. Finally, wrt your comment: > JD: The draft is proposing to embed PCEP within signaling. By definitio= n, this > *is* allowing the client to access the server layer PCE. This is no diff= erent > than allowing the client to access the server layer PCE without embedding= PCE > within signaling. There is a subtle difference: what the client node has access to is the ser= ver border node (policy, addressing and so on) and not the PCE. Then the se= rver border node is in charge of querying the PCE. BR Daniele > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: luned=EC 12 agosto 2013 18:56 > To: Daniele Ceccarelli; Matt Hartley (mhartley); Fatai Zhang; CCAMP > (ccamp@ietf.org) > Cc: Adrian Farrel > Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > Daniele, >=20 > Comments inline. However, the discussions since Berlin on UNI > enhancements and/or adding additional information related to path > computation into the PATH message lead me to the conclusion that we have = a > problem in CCAMP and that we really should suspend all solutions related > work until we have a better idea of the problem we wish to solve. >=20 > If you don't think we have a problem, please consider the list of active = CCAMP > drafts: >=20 > http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro/ >=20 > http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/ >=20 > http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-srlg-collect/ >=20 > http://datatracker.ietf.org/doc/draft-ietf-ccamp-te-metric-recording/ >=20 > http://datatracker.ietf.org/doc/draft-ali-ccamp-extended-srlg/ >=20 > http://datatracker.ietf.org/doc/draft-ali-ccamp-gmpls-uni-error-notificat= ion/ >=20 > http://datatracker.ietf.org/doc/draft-ali-ccamp-lsp-inquiry/ >=20 > http://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function-met= ric- > bound/ >=20 > http://datatracker.ietf.org/doc/draft-bardalai-ccamp-overlay-path-comp/ >=20 > http://datatracker.ietf.org/doc/draft-ceccadedios-ccamp-overlay-use-cases= / >=20 > http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain- > subobjects/ >=20 > http://datatracker.ietf.org/doc/draft-fedyk-ccamp-uni-extensions/ >=20 > http://datatracker.ietf.org/doc/draft-gandhi-ccamp-gmpls-restoration-lsp/ >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Monday, August 12, 2013 7:29 AM > > To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP > > (ccamp@ietf.org) > > Subject: RE: [CCAMP] > > draft-ali-ccamp-rc-objective-function-metric-bound- > > 03.txt > > > > Hi John, all, > > > > I think there are cases in which the PCEP can't solve the issue. > > Suppose for example the simple network below > > > > C1 --- C2 --- C3 C4 --- C5 --- C6 > > \ / > > S1 --- S2 --- S3 > > > > Where Cx are the client nodes and Sx the server nodes and C3-S1 and > > S3-C4 the UNIs. > > The usual behavior for the setup of an LSP in the client domain > > between C1 and C6 consists on 1. "asking" C3 to setup a link in the > > client layer between > > C3 and C4 and 2. after its provisioning, "asking" C1to setup an LSP > > between > > C1 and C6 using the link between C3 and C4. >=20 > JD: No, that's incorrect. The C1-C6 Path message arrives at C3. It tri= ggers C3 > to establish a C3-C4 LSP. After this LSP is established, C3 forwards the= C1-C6 > Path message to C4. We already have CCAMP drafts from, I believe, Cyril > and/or Fatai that describe how to embed the desired characteristics of th= e > C3-C4 LSP within the ERO of the C1-C6 Path message. >=20 > > > > If you suppose to have a simpler approach consisting on a single step, > > it would be possible to "ask" C1 to setup an end to end LSP between C1 > > and C6 with loose ERO C1-C3-C4-C6. >=20 > JD: See above. This has been a part of GMPLS since its inception. >=20 > > > > In the first case the trigger on C3 is provided by the operator with > > given constraints (e.g. Objective functions and/or TE metric bounds) > > and it would be easy to inject them into a PCEP request towards the > > PCE of the server domains, but what happens in the second case? The > > operator only issues a command to C1, which starts a signaling > > procedure. The RSVP-TE message reaches C3 and triggers the setup of the > link C3-C4 over the UNI. >=20 > JD: See above. The second case is actually the GMPLS baseline behavior. >=20 > > > > IMHO putting the Objective Functions into RSVP-TE is useful to "convey" > > such path computation requirements from C1 to C3. Once the PATH > > message reaches C3, it can ask S1 to compute the path towards C4 via > > RSVP-TE or can ask the server layer PCE via PCEP. >=20 > JD: In addition to what is described above, it is also possible for C1 = to use > PCEP > to expand the C3-C4 ERO and place the key associated with this expansion = in > the ERO of the C1-C6 Path message. >=20 > > > > This is one of the two reasons why I think that Objective Functions > > and TE metric Bounds could be useful in RSVP-TE. The second one is > > that I agree with Matt when saying that not in all cases the client > > nodes will be allowed to access the server layer PCE. >=20 > JD: The draft is proposing to embed PCEP within signaling. By definitio= n, this > *is* allowing the client to access the server layer PCE. This is no diff= erent > than allowing the client to access the server layer PCE without embedding= PCE > within signaling. >=20 > > > > BR > > Daniele > > > > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of John E Drake > > > Sent: venerd=EC 9 agosto 2013 23:23 > > > To: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org) > > > Subject: Re: [CCAMP] > > > draft-ali-ccamp-rc-objective-function-metric-bound- > > > 03.txt > > > > > > PCEP can be deployed whenever the server network wishes to provide a > > > path computation service. What possible advantage to anyone is > > > gained by embedding PCEP in RSVP-TE signaling? > > > > > > Yours Irrespectively, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > > > Sent: Friday, August 09, 2013 1:53 PM > > > > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > > > > Cc: Matt Hartley (mhartley) > > > > Subject: RE: [CCAMP] > > > > draft-ali-ccamp-rc-objective-function-metric-bound- > > > > 03.txt > > > > > > > > Fatai, John, > > > > > > > > I don't think you can guarantee that PCE will be deployed > > > > absolutely everywhere, or that you can guarantee the client will > > > > be permitted access to the server PCE when it is. In those cases, t= his > draft is useful. > > > > > > > > Cheers > > > > > > > > Matt > > > > > > > > > Hi John, > > > > > > > > > > Completely agree. > > > > > > > > > > I also raised this comment in front of the mic during Berlin meet= ing. > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of John E Drake > > > > > Sent: Friday, August 09, 2013 1:49 AM > > > > > To: CCAMP (ccamp@ietf.org) > > > > > Subject: [CCAMP] > > > > > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt > > > > > > > > > > Hi, > > > > > > > > > > I have a real concern with this draft because it appears to be > > > > > heading us down the road of re-inventing PCEP in RSVP signaling > > > > > with the dubious justification that it is needed in those > > > > > situations in which a PCE is not available. However, if you > > > > > re-invent PCEP in RSVP signaling, then you have effectively > > > > > ensured that there are no situations in which a PCE or its > > > > > signaling > > equivalent are not available. > > > > > > > > > > Why is this better than simply ensuring that a PCE is available > > > > > in those situations in which it is needed? > > > > > > > > > > Yours Irrespectively, > > > > > > > > > > John > > > > > > > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > >=20 From udayasree.palle@huawei.com Tue Aug 13 03:56:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B643411E8102 for ; Tue, 13 Aug 2013 03:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyE4sUfQlLJ9 for ; Tue, 13 Aug 2013 03:56:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C26121E80E1 for ; Tue, 13 Aug 2013 03:56:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUI50176; Tue, 13 Aug 2013 10:56:28 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 13 Aug 2013 11:55:32 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 13 Aug 2013 11:55:59 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.161]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Tue, 13 Aug 2013 18:55:54 +0800 From: Udayasree palle To: "BRUNGARD, DEBORAH A" , "draft-dhody-ccamp-rsvp-te-domain-subobjects@tools.ietf.org" Thread-Topic: Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects Thread-Index: Ac6VLIv04Xmy0haVR3Oh4IK1fEPtFwC5tQ6Q Date: Tue, 13 Aug 2013 10:55:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.131] Content-Type: multipart/alternative; boundary="_000_EFF3DD5FFB75AC4D89158F068C24F4BB2CA9259Bszxeml561mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 10:56:35 -0000 --_000_EFF3DD5FFB75AC4D89158F068C24F4BB2CA9259Bszxeml561mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I'm aware of IPR that applies to this draft & Yes, the IPR has been disclosed in compliance with IETF IPR rules (**) (**) The IPR was disclosed for "draft-dhody-pce-pcep-domain-sequence" [now = draft-ietf-pce-pcep-domain-sequence] http://datatracker.ietf.org/ipr/1690/ As mentioned by Dhruv, we are working with the legal dept to make sure it s= hows up for this document as well, when searched via the IPR search tool - http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraft= -dhody-ccamp-rsvp-te-domain-subobjects Regards, Udaya From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: 09 August 2013 23:46 To: draft-dhody-ccamp-rsvp-te-domain-subobjects@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_EFF3DD5FFB75AC4D89158F068C24F4BB2CA9259Bszxeml561mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I'm aware of IPR that applies to this draft=

&

Yes, the IPR has been disclosed in compliance with IE= TF IPR rules (**)

 

(**) The IPR was disclosed for "draft-dhody-pce-= pcep-domain-sequence" [now draft-ietf-pce-pcep-domain-sequence]

http://datatracker.ietf.org/ipr/1690/

 

As mentioned by Dhruv, we are working with the legal = dept to make sure it shows up for this document as well, when searched via = the IPR search tool -

http://datatracker.ietf.org/ipr/search/?option=3Ddocu= ment_search&id=3Ddraft-dhody-ccamp-rsvp-te-domain-subobjects=

 

Regards,

Udaya

 

 

From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]=

Sent: 09 August 2013 23:46

To: draft-dhody-ccamp-rsvp-te-domain-subobjects@t= ools.ietf.org

Cc: ccamp@ietf.org

Subject: Regarding IPR on draft-dhody-ccamp-rsvp-= te-domain-subobjects

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG document adopti= on:

 

Are you aware of any IPR that applies to draft id= entified above?

 

  Please state either:

 

  "No, I'm not aware of any IPR that ap= plies to this draft"

  or

  "Yes, I'm aware of IPR that applies t= o this draft"

 

If so, has this IPR been disclosed in compliance = with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more deta= ils)?

 

   If yes to the above, please state ei= ther:

 

  "Yes, the IPR has been disclosed in c= ompliance with IETF IPR rules"

  or

  "No, the IPR has not been disclosed&q= uot;

 

  If you answer no, please provide any addit= ional details you think

  appropriate.

 

If you are listed as a document author or contrib= utor please answer the

above by responding to this email regardless of w= hether or not you are

aware of any relevant IPR.  This document wi= ll not advance to the next

stage until a response has been received from eac= h author and listed

contributor.  NOTE: THIS APPLIES TO ALL OF Y= OU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list but are not= listed as an author or

contributor, we remind you of your obligations un= der the IETF IPR rules

which encourages you to notify the IETF if you ar= e aware of IPR of

others on an IETF contribution, or to refrain fro= m participating in any

contribution or discussion related to your undisc= losed IPR.  For more

information, please see the RFCs listed above and=

http://trac.tools.ietf.org/group/iesg/trac/wiki/I= ntellectualProperty.

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the headers of th= is message in your

response.

 

 

--_000_EFF3DD5FFB75AC4D89158F068C24F4BB2CA9259Bszxeml561mbxchi_-- From jdrake@juniper.net Tue Aug 13 05:47:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8434421E8151 for ; Tue, 13 Aug 2013 05:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2tnQGNQzX+1 for ; Tue, 13 Aug 2013 05:47:51 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2D921E8125 for ; Tue, 13 Aug 2013 05:47:47 -0700 (PDT) Received: from mail113-db9-R.bigfish.com (10.174.16.248) by DB9EHSOBE025.bigfish.com (10.174.14.88) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Aug 2013 12:47:46 +0000 Received: from mail113-db9 (localhost [127.0.0.1]) by mail113-db9-R.bigfish.com (Postfix) with ESMTP id 740E014013F; Tue, 13 Aug 2013 12:47:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: PS1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail113-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(51704005)(51856001)(49866001)(47446002)(65816001)(46102001)(74876001)(74662001)(56816003)(54316002)(74316001)(16406001)(80022001)(79102001)(53806001)(83072001)(47976001)(54356001)(76576001)(77096001)(74502001)(81342001)(77982001)(33646001)(59766001)(50986001)(83322001)(76482001)(81542001)(74706001)(47736001)(4396001)(66066001)(31966008)(69226001)(80976001)(76786001)(56776001)(63696002)(76796001)(74366001)(81686001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.54; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail113-db9 (localhost.localdomain [127.0.0.1]) by mail113-db9 (MessageSwitch) id 1376398062705248_30292; Tue, 13 Aug 2013 12:47:42 +0000 (UTC) Received: from DB9EHSMHS031.bigfish.com (unknown [10.174.16.253]) by mail113-db9.bigfish.com (Postfix) with ESMTP id 9E7D34C0049; Tue, 13 Aug 2013 12:47:42 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS031.bigfish.com (10.174.14.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 13 Aug 2013 12:47:39 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 13 Aug 2013 12:47:37 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 13 Aug 2013 12:47:34 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.235]) with mapi id 15.00.0731.000; Tue, 13 Aug 2013 12:47:34 +0000 From: John E Drake To: Daniele Ceccarelli , "Matt Hartley (mhartley)" , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNW56AgAAHERCABER8AIAAGcGwgAESDICAAEhFIA== Date: Tue, 13 Aug 2013 12:47:33 +0000 Message-ID: <10d3e2d47da8492782fff324f2d93372@BY2PR05MB142.namprd05.prod.outlook.com> References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se> <403c214579834abf91393c4a1cd2c4dd@BY2PR05MB142.namprd05.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE48137622@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48137622@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] x-forefront-prvs: 0937FB07C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:47:57 -0000 Daniele, Snipped, comment inline. Yours Irrespectively, John > Finally, wrt your comment: >=20 > > JD: The draft is proposing to embed PCEP within signaling. By > > definition, this > > *is* allowing the client to access the server layer PCE. This is no > > different than allowing the client to access the server layer PCE > > without embedding PCE within signaling. >=20 > There is a subtle difference: what the client node has access to is the s= erver > border node (policy, addressing and so on) and not the PCE. Then the serv= er > border node is in charge of querying the PCE. JD: We had this discussion about a year ago. If you think of the UNI as a= set of adjacencies, one each for signaling, routing (optional), and PCE (optional), then in eit= her case the PCE adjacency is with the node on the network side of the UNI, and in either ca= se that node acts as a surrogate for the server network. >=20 >=20 >=20 From venugopalreddyk@huawei.com Tue Aug 13 23:14:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D4121E80A1 for ; Tue, 13 Aug 2013 23:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZeKCvVqQT0w for ; Tue, 13 Aug 2013 23:14:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 452B311E8122 for ; Tue, 13 Aug 2013 23:14:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUJ13779; Wed, 14 Aug 2013 06:13:59 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 14 Aug 2013 07:13:46 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 14 Aug 2013 07:13:55 +0100 Received: from blrprnc09ns (10.18.96.98) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server id 14.1.323.7; Wed, 14 Aug 2013 14:13:49 +0800 From: KONDREDDY VENUGOPAL REDDY To: "'BRUNGARD, DEBORAH A'" , References: In-Reply-To: Date: Wed, 14 Aug 2013 11:43:48 +0530 Message-ID: <005801ce98b5$70fec390$52fc4ab0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01CE98E3.8AB6FF90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6VLIv04Xmy0haVR3Oh4IK1fEPtFwDiMJ0Q Content-Language: en-us X-Originating-IP: [10.18.96.98] X-CFilter-Loop: Reflected Cc: ccamp@ietf.org Subject: Re: [CCAMP] Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 06:14:07 -0000 ------=_NextPart_000_0059_01CE98E3.8AB6FF90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, I'm aware of IPR that applies to this draft & Yes, the IPR has been disclosed in compliance with IETF IPR rules (**) (**) The IPR was disclosed for "draft-dhody-pce-pcep-domain-sequence" [now draft-ietf-pce-pcep-domain-sequence] http://datatracker.ietf.org/ipr/1690/ As mentioned by Dhruv, we are working with the legal dept to make sure it shows up for this document as well, when searched via the IPR search tool - http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-dhod y-ccamp-rsvp-te-domain-subobjects Regards, Venu From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: Friday, August 09, 2013 11:46 PM To: draft-dhody-ccamp-rsvp-te-domain-subobjects@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-dhody-ccamp-rsvp-te-domain-subobjects Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. ------=_NextPart_000_0059_01CE98E3.8AB6FF90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I'm aware of IPR that = applies to this draft

&

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Yes, the IPR has been = disclosed in compliance with IETF IPR rules (**)

 

=

(**) The IPR was disclosed = for "draft-dhody-pce-pcep-domain-sequence" [now = draft-ietf-pce-pcep-domain-sequence]

http://datatracker.ietf.org/= ipr/1690/

 

=

As mentioned by Dhruv, we = are working with the legal dept to make sure it shows up for this = document as well, when searched via the IPR search tool - =

http://datatracker.ietf.org/= ipr/search/?option=3Ddocument_search&id=3Ddraft-dhody-ccamp-rsvp-te-d= omain-subobjects

 

=

Regards,

Venu

 

From:= = BRUNGARD, DEBORAH A [mailto:db3546@att.com]
Sent: Friday, = August 09, 2013 11:46 PM
To: = draft-dhody-ccamp-rsvp-te-domain-subobjects@tools.ietf.org
Cc: = ccamp@ietf.org
Subject: Regarding IPR on = draft-dhody-ccamp-rsvp-te-domain-subobjects

 

Authors, = Contributors, (CCAMP)

 =

As part of = the preparation for WG document = adoption:

 =

Are you = aware of any IPR that applies to draft identified = above?

 =

  = Please state either:

 =

  = "No, I'm not aware of any IPR that applies to this = draft"

  = or

  = "Yes, I'm aware of IPR that applies to this = draft"

 =

If so, has = this IPR been disclosed in compliance with IETF IPR = rules

(see RFCs = 3979, 4879, 3669 and 5378 for more = details)?

 =

  = ; If yes to the above, please state = either:

 =

  = "Yes, the IPR has been disclosed in compliance with IETF IPR = rules"

  = or

  = "No, the IPR has not been = disclosed"

 =

  If = you answer no, please provide any additional details you = think

  = appropriate.

 =

If you are = listed as a document author or contributor please answer = the

above by = responding to this email regardless of whether or not you = are

aware of = any relevant IPR.  This document will not advance to the = next

stage = until a response has been received from each author and = listed

contributor= .  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN = THIS

MESSAGE'S = TO LINES.

 =

If you are = on the CCAMP WG email list but are not listed as an author = or

contributor= , we remind you of your obligations under the IETF IPR = rules

which = encourages you to notify the IETF if you are aware of IPR = of

others on = an IETF contribution, or to refrain from participating in = any

contributio= n or discussion related to your undisclosed IPR.  For = more

information= , please see the RFCs listed above = and

 =

Thank = you,

CCAMP WG = Chairs

 =

PS Please = include all listed in the headers of this message in = your

response.

 =

 =

------=_NextPart_000_0059_01CE98E3.8AB6FF90-- From hanjianrui@huawei.com Tue Aug 13 23:47:14 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FC611E8132 for ; Tue, 13 Aug 2013 23:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk7ehAacIfic for ; Tue, 13 Aug 2013 23:47:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D765E11E8122 for ; Tue, 13 Aug 2013 23:47:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUJ16299; Wed, 14 Aug 2013 06:47:04 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 14 Aug 2013 07:46:32 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 14 Aug 2013 07:47:02 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.5.151]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Wed, 14 Aug 2013 14:45:15 +0800 From: Hanjianrui To: Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "rrao@infinera.com" , "giomarti@cisco.com" , "remi.theillaud@marben-products.com" , "gregb@grotto-networking.com" , Leeyoung , "Lidan (Dan)" , "imajuku.wataru@lab.ntt.co.jp" Thread-Topic: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Thread-Index: AQHOg+meDdvPHVF0lkW2r5QujnYrPpmUa6cA Date: Wed, 14 Aug 2013 06:45:14 +0000 Message-ID: <984B86948E312F4E90A05B59E83A740F4044DD13@szxeml511-mbx.china.huawei.com> References: <51E83C33.7010802@labn.net> In-Reply-To: <51E83C33.7010802@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.143] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWdlbmVyYWwtY29uc3RyYWludC1lbmNvZGU=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 06:47:14 -0000 Tm8sIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQu DQoNClRoYW5rcw0KSmlhbnJ1aSBIQU4gDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBM b3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQq3osvNyrG85DogMjAxM8TqN9TC MTnI1SAzOjA0DQrK1bz+yMs6IGRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbTsgYW5kZXJzLmdh dmxlckBhY3Jlby5zZTsgam9uYXMubWFydGVuc3NvbkBhY3Jlby5zZTsgaS1uaXNoaW9rYUBjYi5q cC5uZWMuY29tOyBycmFvQGluZmluZXJhLmNvbTsgZ2lvbWFydGlAY2lzY28uY29tOyByZW1pLnRo ZWlsbGF1ZEBtYXJiZW4tcHJvZHVjdHMuY29tOyBncmVnYkBncm90dG8tbmV0d29ya2luZy5jb207 IExlZXlvdW5nOyBMaWRhbiAoRGFuKTsgaW1hanVrdS53YXRhcnVAbGFiLm50dC5jby5qcDsgSGFu amlhbnJ1aQ0Ks63LzTogY2NhbXBAaWV0Zi5vcmcNCtb3zOI6IFJlZ2FyZGluZyBJUFIgb24gZHJh ZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlDQoNCkF1dGhvcnMsIENvbnRy aWJ1dG9ycywgKENDQU1QKQ0KDQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFz dCBDYWxsOg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0 IGlkZW50aWZpZWQgYWJvdmU/DQoNCiAgUGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAiTm8sIEkn bSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCiAgb3IN CiAgIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCg0K SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVU RiBJUFIgcnVsZXMNCihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3Jl IGRldGFpbHMpPw0KDQogICBJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVy Og0KDQogICJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0 aCBJRVRGIElQUiBydWxlcyINCiAgb3INCiAgIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNj bG9zZWQiDQoNCiAgSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9u YWwgZGV0YWlscyB5b3UgdGhpbmsNCiAgYXBwcm9wcmlhdGUuDQoNCklmIHlvdSBhcmUgbGlzdGVk IGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3ZXIgdGhlDQph Ym92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9y IG5vdCB5b3UgYXJlDQphd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiAgVGhpcyBkb2N1bWVudCB3 aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0DQpzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBi ZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZA0KY29udHJpYnV0b3IuICBO T1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUw0KTUVTU0FHRSdT IFRPIExJTkVTLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBDQ0FNUCBXRyBlbWFpbCBsaXN0IGJ1dCBh cmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3INCmNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91 IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzDQp3aGljaCBlbmNv dXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2YN Cm90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRp Y2lwYXRpbmcgaW4gYW55DQpjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlv dXIgdW5kaXNjbG9zZWQgSVBSLiAgRm9yIG1vcmUNCmluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRo ZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3Vw L2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpDQ0FN UCBXRyBDaGFpcnMNCg0KUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVy cyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91cg0KcmVzcG9uc2UuDQo= From hanjianrui@huawei.com Tue Aug 13 23:52:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCE611E8133 for ; Tue, 13 Aug 2013 23:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jIZPfzcOIBv for ; Tue, 13 Aug 2013 23:52:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7389B11E8122 for ; Tue, 13 Aug 2013 23:52:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVZ84209; Wed, 14 Aug 2013 06:52:46 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 14 Aug 2013 07:52:14 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 14 Aug 2013 07:52:44 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.5.151]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Wed, 14 Aug 2013 14:52:33 +0800 From: Hanjianrui To: Lou Berger , Fatai Zhang , Leeyoung , "gregb@grotto-networking.com" , "xuyunbin@mail.ritt.com.cn" , "zhangguoying@mail.ritt.com.cn" , "Lidan (Dan)" , "Chenming (NWResearch)" , "Yeyabin (Yabin)" Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te Thread-Index: AQHOg+m3SwQEkS5+z0Wl7A23uF/LaZmUYhiQ Date: Wed, 14 Aug 2013 06:52:32 +0000 Message-ID: <984B86948E312F4E90A05B59E83A740F4044DD49@szxeml511-mbx.china.huawei.com> References: <51E83C58.6010602@labn.net> In-Reply-To: <51E83C58.6010602@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.143] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZQ==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 06:52:55 -0000 WWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0IGFuZCB0aGUg SVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMg YXMgZm9sbG93czogDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/ b3B0aW9uPWRvY3VtZW50X3NlYXJjaCZkb2N1bWVudF9zZWFyY2g9ZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0N CreivP7IyzogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0Kt6LLzcqxvOQ6 IDIwMTPE6jfUwjE5yNUgMzowNQ0KytW8/sjLOiBGYXRhaSBaaGFuZzsgTGVleW91bmc7IEhhbmpp YW5ydWk7IGdyZWdiQGdyb3R0by1uZXR3b3JraW5nLmNvbTsgeHV5dW5iaW5AbWFpbC5yaXR0LmNv bS5jbjsgemhhbmdndW95aW5nQG1haWwucml0dC5jb20uY247IExpZGFuIChEYW4pOyBDaGVubWlu ZyAoTldSZXNlYXJjaCk7IFlleWFiaW4gKFlhYmluKQ0Ks63LzTogY2NhbXBAaWV0Zi5vcmcNCtb3 zOI6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0 cmFpbnRzLW9zcGYtdGUNCg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCAoQ0NBTVApDQoNCkFzIHBh cnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGw6DQoNCkFyZSB5b3UgYXdhcmUg b2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT8NCg0KICBQ bGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQogICJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRo YXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KICBvcg0KICAiWWVzLCBJJ20gYXdhcmUgb2YgSVBS IHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4g ZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KKHNlZSBSRkNzIDM5 NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/DQoNCiAgIElmIHllcyB0 byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiAgIlllcywgdGhlIElQUiBoYXMg YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0KICBvcg0K ICAiTm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCINCg0KICBJZiB5b3UgYW5zd2Vy IG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluaw0KICBh cHByb3ByaWF0ZS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3Ig Y29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhp cyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCmF3YXJlIG9mIGFu eSByZWxldmFudCBJUFIuICBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5l eHQNCnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1 dGhvciBhbmQgbGlzdGVkDQpjb250cmlidXRvci4gIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwg T0YgWU9VIExJU1RFRCBJTiBUSElTDQpNRVNTQUdFJ1MgVE8gTElORVMuDQoNCklmIHlvdSBhcmUg b24gdGhlIENDQU1QIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhv ciBvcg0KY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRl ciB0aGUgSUVURiBJUFIgcnVsZXMNCndoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUg SUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZg0Kb3RoZXJzIG9uIGFuIElFVEYgY29udHJp YnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkNCmNvbnRyaWJ1 dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuICBGb3Ig bW9yZQ0KaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZA0K aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0 dWFsUHJvcGVydHkuDQoNClRoYW5rIHlvdSwNCkNDQU1QIFdHIENoYWlycw0KDQpQUyBQbGVhc2Ug aW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3Vy DQpyZXNwb25zZS4NCg== From zhangfatai@huawei.com Wed Aug 14 01:09:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD8921F9A50 for ; Wed, 14 Aug 2013 01:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SLHQcHjXrhs for ; Wed, 14 Aug 2013 01:09:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC5D21F9AA9 for ; Wed, 14 Aug 2013 01:09:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVZ91553; Wed, 14 Aug 2013 08:09:22 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 14 Aug 2013 09:08:53 +0100 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 14 Aug 2013 09:09:02 +0100 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.110]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.007; Wed, 14 Aug 2013 16:08:57 +0800 From: Fatai Zhang To: Daniele Ceccarelli , John E Drake , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACdi0mD//4LQgIAEQ08AgAApG4CAAQKxgP/98AIQ Date: Wed, 14 Aug 2013 08:08:57 +0000 Message-ID: References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se> <403c214579834abf91393c4a1cd2c4dd@BY2PR05MB142.namprd05.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE48137622@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48137622@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: EoMy LxTh OBvG VkXU WMP1 bx8u eAcu eVhW h2II icSY qWwj vfA/ xCca y41T zq4S 2Isi; 5; YQBkAHIAaQBhAG4AQABvAGwAZABkAG8AZwAuAGMAbwAuAHUAawA7AGMAYwBhAG0AcABAAGkAZQB0AGYALgBvAHIAZwA7AGQAYQBuAGkAZQBsAGUALgBjAGUAYwBjAGEAcgBlAGwAbABpAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBqAGQAcgBhAGsAZQBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA7AG0AaABhAHIAdABsAGUAeQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Sosha1_v1; 7; {CA20DF14-718A-4684-90E6-8A173EDE9D64}; egBoAGEAbgBnAGYAYQB0AGEAaQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Wed, 14 Aug 2013 08:08:46 GMT; UgBFADoAIABbAEMAQwBBAE0AUABdACAAZAByAGEAZgB0AC0AYQBsAGkALQBjAGMAYQBtAHAALQByAGMALQBvAGIAagBlAGMAdABpAHYAZQAtAGYAdQBuAGMAdABpAG8AbgAtAG0AZQB0AHIAaQBjAC0AYgBvAHUAbgBkAC0AMAAzAC4AdAB4AHQA x-cr-puzzleid: {CA20DF14-718A-4684-90E6-8A173EDE9D64} x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 08:09:29 -0000 Hi Daniele and John, I totally agree with John on his following main points. [draft-zhang-ccamp-= gmpls-h-lsp-mln] is to address what John said. Let's go further to see how the second case works.=20 If there are no multiple PCEs for inter-layer or multi-domain communication= s (or edge node as a surrogate as John said), what is the value to carry th= e latency info in the signaling? For example, if you want to create an E2E = connection from C1 to C6 with latency like X, and it takes latency Y from C= 1 to C3, how does it know how much latency needed from C3 to C4 when the la= tency of C4 to C6 is unknown (even the route of C4-C6 is not known).=20 =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D JD: No, that's incorrect. The C1-C6 Path message arrives at C3. It trigg= ers C3 to establish a C3-C4 LSP. After this LSP is established, C3 forward= s the C1-C6 Path message to C4. We already have CCAMP drafts from, I belie= ve, Cyril and/or Fatai that describe how to embed the desired characteristi= cs of the C3-C4 LSP within the ERO of the C1-C6 Path message. JD: In addition to what is described above, it is also possible for C1 to = use PCEP to expand the C3-C4 ERO and place the key associated with this exp= ansion in the ERO of the C1-C6 Path message. Best Regards Fatai -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]=20 Sent: Tuesday, August 13, 2013 4:22 PM To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.o= rg) Cc: Adrian Farrel Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.= txt Hi John, That's an option, maybe a good one. By the way while it may seem like a large amount of documents, they do alig= n somewhat. The use cases do point to these other specific signaling extens= ions drafts, including the objective function draft.=20 We need to work a lot towards aligning the documents better. WRT your comments in line what I meant is that (as you pointed out) the GMP= LS already supports both of them, either the signaling of an end to end LSP= initiated by C1 via RSVP-TE or the signaling between C3 and C4 that genera= tes a link in the client layer (e.g. FA) and allows for its advertisement (= draft-previdi-isis-te-metric-extensions-03 and OSPF Traffic Engineering (TE= ) Metric Extensions) utilization e.g. via LDP. Finally, wrt your comment: > JD: The draft is proposing to embed PCEP within signaling. By definitio= n, this > *is* allowing the client to access the server layer PCE. This is no diff= erent > than allowing the client to access the server layer PCE without embedding= PCE > within signaling. There is a subtle difference: what the client node has access to is the ser= ver border node (policy, addressing and so on) and not the PCE. Then the se= rver border node is in charge of querying the PCE. BR Daniele > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: luned=EC 12 agosto 2013 18:56 > To: Daniele Ceccarelli; Matt Hartley (mhartley); Fatai Zhang; CCAMP > (ccamp@ietf.org) > Cc: Adrian Farrel > Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > Daniele, >=20 > Comments inline. However, the discussions since Berlin on UNI > enhancements and/or adding additional information related to path > computation into the PATH message lead me to the conclusion that we have = a > problem in CCAMP and that we really should suspend all solutions related > work until we have a better idea of the problem we wish to solve. >=20 > If you don't think we have a problem, please consider the list of active = CCAMP > drafts: >=20 > http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro/ >=20 > http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/ >=20 > http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-srlg-collect/ >=20 > http://datatracker.ietf.org/doc/draft-ietf-ccamp-te-metric-recording/ >=20 > http://datatracker.ietf.org/doc/draft-ali-ccamp-extended-srlg/ >=20 > http://datatracker.ietf.org/doc/draft-ali-ccamp-gmpls-uni-error-notificat= ion/ >=20 > http://datatracker.ietf.org/doc/draft-ali-ccamp-lsp-inquiry/ >=20 > http://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function-met= ric- > bound/ >=20 > http://datatracker.ietf.org/doc/draft-bardalai-ccamp-overlay-path-comp/ >=20 > http://datatracker.ietf.org/doc/draft-ceccadedios-ccamp-overlay-use-cases= / >=20 > http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain- > subobjects/ >=20 > http://datatracker.ietf.org/doc/draft-fedyk-ccamp-uni-extensions/ >=20 > http://datatracker.ietf.org/doc/draft-gandhi-ccamp-gmpls-restoration-lsp/ >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Monday, August 12, 2013 7:29 AM > > To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP > > (ccamp@ietf.org) > > Subject: RE: [CCAMP] > > draft-ali-ccamp-rc-objective-function-metric-bound- > > 03.txt > > > > Hi John, all, > > > > I think there are cases in which the PCEP can't solve the issue. > > Suppose for example the simple network below > > > > C1 --- C2 --- C3 C4 --- C5 --- C6 > > \ / > > S1 --- S2 --- S3 > > > > Where Cx are the client nodes and Sx the server nodes and C3-S1 and > > S3-C4 the UNIs. > > The usual behavior for the setup of an LSP in the client domain > > between C1 and C6 consists on 1. "asking" C3 to setup a link in the > > client layer between > > C3 and C4 and 2. after its provisioning, "asking" C1to setup an LSP > > between > > C1 and C6 using the link between C3 and C4. >=20 > JD: No, that's incorrect. The C1-C6 Path message arrives at C3. It tri= ggers C3 > to establish a C3-C4 LSP. After this LSP is established, C3 forwards the= C1-C6 > Path message to C4. We already have CCAMP drafts from, I believe, Cyril > and/or Fatai that describe how to embed the desired characteristics of th= e > C3-C4 LSP within the ERO of the C1-C6 Path message. >=20 > > > > If you suppose to have a simpler approach consisting on a single step, > > it would be possible to "ask" C1 to setup an end to end LSP between C1 > > and C6 with loose ERO C1-C3-C4-C6. >=20 > JD: See above. This has been a part of GMPLS since its inception. >=20 > > > > In the first case the trigger on C3 is provided by the operator with > > given constraints (e.g. Objective functions and/or TE metric bounds) > > and it would be easy to inject them into a PCEP request towards the > > PCE of the server domains, but what happens in the second case? The > > operator only issues a command to C1, which starts a signaling > > procedure. The RSVP-TE message reaches C3 and triggers the setup of the > link C3-C4 over the UNI. >=20 > JD: See above. The second case is actually the GMPLS baseline behavior. >=20 > > > > IMHO putting the Objective Functions into RSVP-TE is useful to "convey" > > such path computation requirements from C1 to C3. Once the PATH > > message reaches C3, it can ask S1 to compute the path towards C4 via > > RSVP-TE or can ask the server layer PCE via PCEP. >=20 > JD: In addition to what is described above, it is also possible for C1 = to use > PCEP > to expand the C3-C4 ERO and place the key associated with this expansion = in > the ERO of the C1-C6 Path message. >=20 > > > > This is one of the two reasons why I think that Objective Functions > > and TE metric Bounds could be useful in RSVP-TE. The second one is > > that I agree with Matt when saying that not in all cases the client > > nodes will be allowed to access the server layer PCE. >=20 > JD: The draft is proposing to embed PCEP within signaling. By definitio= n, this > *is* allowing the client to access the server layer PCE. This is no diff= erent > than allowing the client to access the server layer PCE without embedding= PCE > within signaling. >=20 > > > > BR > > Daniele > > > > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of John E Drake > > > Sent: venerd=EC 9 agosto 2013 23:23 > > > To: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org) > > > Subject: Re: [CCAMP] > > > draft-ali-ccamp-rc-objective-function-metric-bound- > > > 03.txt > > > > > > PCEP can be deployed whenever the server network wishes to provide a > > > path computation service. What possible advantage to anyone is > > > gained by embedding PCEP in RSVP-TE signaling? > > > > > > Yours Irrespectively, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > > > Sent: Friday, August 09, 2013 1:53 PM > > > > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > > > > Cc: Matt Hartley (mhartley) > > > > Subject: RE: [CCAMP] > > > > draft-ali-ccamp-rc-objective-function-metric-bound- > > > > 03.txt > > > > > > > > Fatai, John, > > > > > > > > I don't think you can guarantee that PCE will be deployed > > > > absolutely everywhere, or that you can guarantee the client will > > > > be permitted access to the server PCE when it is. In those cases, t= his > draft is useful. > > > > > > > > Cheers > > > > > > > > Matt > > > > > > > > > Hi John, > > > > > > > > > > Completely agree. > > > > > > > > > > I also raised this comment in front of the mic during Berlin meet= ing. > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of John E Drake > > > > > Sent: Friday, August 09, 2013 1:49 AM > > > > > To: CCAMP (ccamp@ietf.org) > > > > > Subject: [CCAMP] > > > > > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt > > > > > > > > > > Hi, > > > > > > > > > > I have a real concern with this draft because it appears to be > > > > > heading us down the road of re-inventing PCEP in RSVP signaling > > > > > with the dubious justification that it is needed in those > > > > > situations in which a PCE is not available. However, if you > > > > > re-invent PCEP in RSVP signaling, then you have effectively > > > > > ensured that there are no situations in which a PCE or its > > > > > signaling > > equivalent are not available. > > > > > > > > > > Why is this better than simply ensuring that a PCE is available > > > > > in those situations in which it is needed? > > > > > > > > > > Yours Irrespectively, > > > > > > > > > > John > > > > > > > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > >=20 From daniele.ceccarelli@ericsson.com Wed Aug 14 06:35:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F26921F9D4F for ; Wed, 14 Aug 2013 06:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.824 X-Spam-Level: X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVZqf-O2HMK8 for ; Wed, 14 Aug 2013 06:35:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 61FAF21F8F9A for ; Wed, 14 Aug 2013 06:35:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-82-520b87a26505 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FF.55.22048.2A78B025; Wed, 14 Aug 2013 15:35:30 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.105]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Wed, 14 Aug 2013 15:35:30 +0200 From: Daniele Ceccarelli To: Fatai Zhang , John E Drake , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACdi0mD//+dlgP/7p/MwgAjEd4D//uHWkIADr6aA//+DwWA= Date: Wed, 14 Aug 2013 13:35:29 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48138D4D@ESESSMB301.ericsson.se> References: <6a054c6778634c0f9d84db0f09b9dfda@BY2PR05MB142.namprd05.prod.outlook.com> <9D50FCE7413E3D4EA5E42331115FB5BC105AF32C@xmb-rcd-x03.cisco.com> <9895b66535d3425aa6954280befed5fa@BY2PR05MB142.namprd05.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE481360CC@ESESSMB301.ericsson.se> <403c214579834abf91393c4a1cd2c4dd@BY2PR05MB142.namprd05.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE48137622@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvre6idu4ggxtfDS1+9Nxgtngy5waL xZy7zhZzXjJb9DWfZ3Vg9ZjyeyOrR8uRt6weS5b8ZPK43nSV3WPF5pWMAaxRXDYpqTmZZalF +nYJXBkr531mKTibUvF30w22Bsa3vl2MHBwSAiYSdzt4uxg5gUwxiQv31rN1MXJxCAkcZpR4 fu4klLOEUeL7tZWMIA1sAlYSTw75gDSICKxklNj0KRfEZhZQlzja+4gVxBYWCJCYs/wjG0RN oMTbz3Oh7CSJ5ffmg9WwCKhKPOr9BxbnFfCW+LV2PzPErjMsEs93v2UGSXAKhEm8nv6NBcRm FJCVmLB7ESPEMnGJW0/mM0FcLSCxZM95ZghbVOLl43+sELaSxI8Nl1gg6vUkbkydwgZha0ss W/iaGWKxoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKKkT03MTMnvdx8EyMwtg5u+W2wg3HT fbFDjNIcLErivJv1zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYLTpq6xVaNsZku+76UOR 49eg6PO92he297SzaGVvM/9lZx2+7ruw/ImDRevqc2baRMbGtGyWv7Dt2KuZ53w3XX0pZb+r +NDWpOWrtOYFBq3RXimxninD1PHqzksLQ5r7zUuXiOQKr+XZYtLPNW8RV1ix6mOFh0x/ns7V 7f4osuOpLdvZS+VmDUosxRmJhlrMRcWJAGC3EKp7AgAA Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 13:35:38 -0000 Fatai, John and I are saying exactly the same thing. We don't disagree on procedur= es, we only disagree on PCEP vs RSVP-TE BR Daniele > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: mercoled=EC 14 agosto 2013 10:09 > To: Daniele Ceccarelli; John E Drake; Matt Hartley (mhartley); CCAMP > (ccamp@ietf.org) > Cc: Adrian Farrel > Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > Hi Daniele and John, >=20 > I totally agree with John on his following main points. [draft-zhang-ccam= p- > gmpls-h-lsp-mln] is to address what John said. >=20 > Let's go further to see how the second case works. >=20 > If there are no multiple PCEs for inter-layer or multi-domain communicati= ons > (or edge node as a surrogate as John said), what is the value to carry th= e > latency info in the signaling? For example, if you want to create an E2E > connection from C1 to C6 with latency like X, and it takes latency Y from= C1 to > C3, how does it know how much latency needed from C3 to C4 when the > latency of C4 to C6 is unknown (even the route of C4-C6 is not known). >=20 >=20 > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > JD: No, that's incorrect. The C1-C6 Path message arrives at C3. It tri= ggers C3 > to establish a C3-C4 LSP. After this LSP is established, C3 forwards the= C1-C6 > Path message to C4. We already have CCAMP drafts from, I believe, Cyril > and/or Fatai that describe how to embed the desired characteristics of th= e > C3-C4 LSP within the ERO of the C1-C6 Path message. >=20 > JD: In addition to what is described above, it is also possible for C1 t= o use > PCEP to expand the C3-C4 ERO and place the key associated with this > expansion in the ERO of the C1-C6 Path message. >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, August 13, 2013 4:22 PM > To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP > (ccamp@ietf.org) > Cc: Adrian Farrel > Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > Hi John, >=20 > That's an option, maybe a good one. >=20 > By the way while it may seem like a large amount of documents, they do al= ign > somewhat. The use cases do point to these other specific signaling extens= ions > drafts, including the objective function draft. > We need to work a lot towards aligning the documents better. >=20 > WRT your comments in line what I meant is that (as you pointed out) the > GMPLS already supports both of them, either the signaling of an end to en= d > LSP initiated by C1 via RSVP-TE or the signaling between C3 and C4 that > generates a link in the client layer (e.g. FA) and allows for its adverti= sement > (draft-previdi-isis-te-metric-extensions-03 and OSPF Traffic Engineering = (TE) > Metric Extensions) utilization e.g. via LDP. >=20 > Finally, wrt your comment: >=20 > > JD: The draft is proposing to embed PCEP within signaling. By > > definition, this > > *is* allowing the client to access the server layer PCE. This is no > > different than allowing the client to access the server layer PCE > > without embedding PCE within signaling. >=20 > There is a subtle difference: what the client node has access to is the s= erver > border node (policy, addressing and so on) and not the PCE. Then the serv= er > border node is in charge of querying the PCE. >=20 > BR > Daniele >=20 >=20 >=20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: luned=EC 12 agosto 2013 18:56 > > To: Daniele Ceccarelli; Matt Hartley (mhartley); Fatai Zhang; CCAMP > > (ccamp@ietf.org) > > Cc: Adrian Farrel > > Subject: RE: [CCAMP] > > draft-ali-ccamp-rc-objective-function-metric-bound- > > 03.txt > > > > Daniele, > > > > Comments inline. However, the discussions since Berlin on UNI > > enhancements and/or adding additional information related to path > > computation into the PATH message lead me to the conclusion that we > > have a problem in CCAMP and that we really should suspend all > > solutions related work until we have a better idea of the problem we wi= sh to > solve. > > > > If you don't think we have a problem, please consider the list of > > active CCAMP > > drafts: > > > > http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro/ > > > > http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/ > > > > http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-srlg-collect/ > > > > http://datatracker.ietf.org/doc/draft-ietf-ccamp-te-metric-recording/ > > > > http://datatracker.ietf.org/doc/draft-ali-ccamp-extended-srlg/ > > > > http://datatracker.ietf.org/doc/draft-ali-ccamp-gmpls-uni-error-notifi > > cation/ > > > > http://datatracker.ietf.org/doc/draft-ali-ccamp-lsp-inquiry/ > > > > http://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function- > > metric- > > bound/ > > > > http://datatracker.ietf.org/doc/draft-bardalai-ccamp-overlay-path-comp > > / > > > > http://datatracker.ietf.org/doc/draft-ceccadedios-ccamp-overlay-use-ca > > ses/ > > > > http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain- > > subobjects/ > > > > http://datatracker.ietf.org/doc/draft-fedyk-ccamp-uni-extensions/ > > > > http://datatracker.ietf.org/doc/draft-gandhi-ccamp-gmpls-restoration-l > > sp/ > > > > Yours Irrespectively, > > > > John > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Monday, August 12, 2013 7:29 AM > > > To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP > > > (ccamp@ietf.org) > > > Subject: RE: [CCAMP] > > > draft-ali-ccamp-rc-objective-function-metric-bound- > > > 03.txt > > > > > > Hi John, all, > > > > > > I think there are cases in which the PCEP can't solve the issue. > > > Suppose for example the simple network below > > > > > > C1 --- C2 --- C3 C4 --- C5 --- C6 > > > \ / > > > S1 --- S2 --- S3 > > > > > > Where Cx are the client nodes and Sx the server nodes and C3-S1 and > > > S3-C4 the UNIs. > > > The usual behavior for the setup of an LSP in the client domain > > > between C1 and C6 consists on 1. "asking" C3 to setup a link in the > > > client layer between > > > C3 and C4 and 2. after its provisioning, "asking" C1to setup an LSP > > > between > > > C1 and C6 using the link between C3 and C4. > > > > JD: No, that's incorrect. The C1-C6 Path message arrives at C3. It > > triggers C3 to establish a C3-C4 LSP. After this LSP is established, > > C3 forwards the C1-C6 Path message to C4. We already have CCAMP > > drafts from, I believe, Cyril and/or Fatai that describe how to embed > > the desired characteristics of the > > C3-C4 LSP within the ERO of the C1-C6 Path message. > > > > > > > > If you suppose to have a simpler approach consisting on a single > > > step, it would be possible to "ask" C1 to setup an end to end LSP > > > between C1 and C6 with loose ERO C1-C3-C4-C6. > > > > JD: See above. This has been a part of GMPLS since its inception. > > > > > > > > In the first case the trigger on C3 is provided by the operator with > > > given constraints (e.g. Objective functions and/or TE metric bounds) > > > and it would be easy to inject them into a PCEP request towards the > > > PCE of the server domains, but what happens in the second case? The > > > operator only issues a command to C1, which starts a signaling > > > procedure. The RSVP-TE message reaches C3 and triggers the setup of > > > the > > link C3-C4 over the UNI. > > > > JD: See above. The second case is actually the GMPLS baseline behavio= r. > > > > > > > > IMHO putting the Objective Functions into RSVP-TE is useful to "conve= y" > > > such path computation requirements from C1 to C3. Once the PATH > > > message reaches C3, it can ask S1 to compute the path towards C4 via > > > RSVP-TE or can ask the server layer PCE via PCEP. > > > > JD: In addition to what is described above, it is also possible for C= 1 to use > > PCEP > > to expand the C3-C4 ERO and place the key associated with this > > expansion in the ERO of the C1-C6 Path message. > > > > > > > > This is one of the two reasons why I think that Objective Functions > > > and TE metric Bounds could be useful in RSVP-TE. The second one is > > > that I agree with Matt when saying that not in all cases the client > > > nodes will be allowed to access the server layer PCE. > > > > JD: The draft is proposing to embed PCEP within signaling. By > > definition, this > > *is* allowing the client to access the server layer PCE. This is no > > different than allowing the client to access the server layer PCE > > without embedding PCE within signaling. > > > > > > > > BR > > > Daniele > > > > > > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of John E Drake > > > > Sent: venerd=EC 9 agosto 2013 23:23 > > > > To: Matt Hartley (mhartley); Fatai Zhang; CCAMP (ccamp@ietf.org) > > > > Subject: Re: [CCAMP] > > > > draft-ali-ccamp-rc-objective-function-metric-bound- > > > > 03.txt > > > > > > > > PCEP can be deployed whenever the server network wishes to provide > > > > a path computation service. What possible advantage to anyone is > > > > gained by embedding PCEP in RSVP-TE signaling? > > > > > > > > Yours Irrespectively, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > > > > Sent: Friday, August 09, 2013 1:53 PM > > > > > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > > > > > Cc: Matt Hartley (mhartley) > > > > > Subject: RE: [CCAMP] > > > > > draft-ali-ccamp-rc-objective-function-metric-bound- > > > > > 03.txt > > > > > > > > > > Fatai, John, > > > > > > > > > > I don't think you can guarantee that PCE will be deployed > > > > > absolutely everywhere, or that you can guarantee the client will > > > > > be permitted access to the server PCE when it is. In those > > > > > cases, this > > draft is useful. > > > > > > > > > > Cheers > > > > > > > > > > Matt > > > > > > > > > > > Hi John, > > > > > > > > > > > > Completely agree. > > > > > > > > > > > > I also raised this comment in front of the mic during Berlin me= eting. > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > > > > > > On > > > > > Behalf > > > > > > Of John E Drake > > > > > > Sent: Friday, August 09, 2013 1:49 AM > > > > > > To: CCAMP (ccamp@ietf.org) > > > > > > Subject: [CCAMP] > > > > > > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt > > > > > > > > > > > > Hi, > > > > > > > > > > > > I have a real concern with this draft because it appears to be > > > > > > heading us down the road of re-inventing PCEP in RSVP > > > > > > signaling with the dubious justification that it is needed in > > > > > > those situations in which a PCE is not available. However, if > > > > > > you re-invent PCEP in RSVP signaling, then you have > > > > > > effectively ensured that there are no situations in which a > > > > > > PCE or its signaling > > > equivalent are not available. > > > > > > > > > > > > Why is this better than simply ensuring that a PCE is > > > > > > available in those situations in which it is needed? > > > > > > > > > > > > Yours Irrespectively, > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > From zali@cisco.com Wed Aug 14 07:21:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B58F11E81DD for ; Wed, 14 Aug 2013 07:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7J3ewhLyPEH for ; Wed, 14 Aug 2013 07:21:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE3511E8170 for ; Wed, 14 Aug 2013 07:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=258; q=dns/txt; s=iport; t=1376490054; x=1377699654; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=qs00SkemEllkXXCCFcG9BOkgjUC8ZTqEmtU4Suxg0gw=; b=EJnWWC0p4Jon5zR5XQp+8iaXBQuzgnigVoVFZSgNPAtewf0tMeZ3nMu+ w3c5ipO0VPa00baWmNc3+SZ1mP1jQaBEIESlleqWidavuvf85k23r6WHy 1Z7TTzKKDy7dx5PqA7lcil6j3g7N9G9/rAipmqywaEhnsj4PgCsTtwN27 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAKeRC1KtJXG+/2dsb2JhbABbgwaBBb5lgSMWdIImAQQ6UQEIIhRCJQIEARqICLklkB84gxt3A6k2gxuCKg X-IronPort-AV: E=Sophos;i="4.89,877,1367971200"; d="scan'208";a="247222397" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 14 Aug 2013 14:20:44 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7EEKhio009826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 14:20:43 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.190]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 09:20:43 -0500 From: "Zafar Ali (zali)" To: Daniele Ceccarelli , Fatai Zhang , John E Drake , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACdi0mAAC5fEgACIaeoAAAUjU4AAIFYxgAAx2VuAAAtnb4D//8mUAA== Date: Wed, 14 Aug 2013 14:20:42 +0000 Message-ID: In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48138D4D@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.241.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <03CABE7849B90843A3C43AF02305D48E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:21:07 -0000 >John and I are saying exactly the same thing. We don't disagree on >procedures, we only disagree on PCEP vs RSVP-TE > I have the same disagreement with John. We have a situation that we should let the Market decide. Thanks Regards...Zafar=20 From ggrammel@juniper.net Wed Aug 14 08:00:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B90E21E80B5 for ; Wed, 14 Aug 2013 08:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvwkddccWlDK for ; Wed, 14 Aug 2013 08:00:47 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7F85121E80B9 for ; Wed, 14 Aug 2013 08:00:47 -0700 (PDT) Received: from mail16-co9-R.bigfish.com (10.236.132.234) by CO9EHSOBE030.bigfish.com (10.236.130.93) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Aug 2013 15:00:46 +0000 Received: from mail16-co9 (localhost [127.0.0.1]) by mail16-co9-R.bigfish.com (Postfix) with ESMTP id 8A4524E021D; Wed, 14 Aug 2013 15:00:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz9371Iec9Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail16-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=ggrammel@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(37854004)(377454003)(47446002)(51856001)(83072001)(53806001)(65816001)(76786001)(69226001)(77982001)(74662001)(76576001)(81542001)(74876001)(49866001)(46102001)(50986001)(74502001)(54356001)(80022001)(4396001)(16406001)(83322001)(79102001)(47976001)(81686001)(19580395003)(74316001)(74706001)(1941001)(56776001)(59766001)(56816003)(33646001)(63696002)(76482001)(80976001)(54316002)(76796001)(74366001)(66066001)(31966008)(19580405001)(19580385001)(47736001)(77096001)(81342001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB140; H:BN1PR05MB041.namprd05.prod.outlook.com; CLIP:178.239.82.32; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail16-co9 (localhost.localdomain [127.0.0.1]) by mail16-co9 (MessageSwitch) id 1376492445684762_2197; Wed, 14 Aug 2013 15:00:45 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.245]) by mail16-co9.bigfish.com (Postfix) with ESMTP id 91DB63C006A; Wed, 14 Aug 2013 15:00:45 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 14 Aug 2013 15:00:42 +0000 Received: from BN1PR05MB140.namprd05.prod.outlook.com (10.255.205.23) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 14 Aug 2013 15:00:36 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB140.namprd05.prod.outlook.com (10.255.205.23) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 14 Aug 2013 15:00:35 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.216]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.216]) with mapi id 15.00.0731.000; Wed, 14 Aug 2013 15:00:35 +0000 From: Gert Grammel To: "Zafar Ali (zali)" , Daniele Ceccarelli , Fatai Zhang , John E Drake , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACdi0mAAAR2OgACIaeoAAAUjVIAAIFYwgAAx2VuAAAtncIAAAZREAAABZHur Date: Wed, 14 Aug 2013 15:00:35 +0000 Message-ID: <6eea8117750e439ca87ecd608e416ccc@BN1PR05MB041.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE48138D4D@ESESSMB301.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.239.82.32] x-forefront-prvs: 0938781D02 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 15:00:54 -0000 Hi Zhafar, Daniele, If PCEP is not good enough to cover the cases you have in mind, it would be= worth to document those gaps. On the other hand, if PCEP is good enough, so why re-invent it in RSVP? A serious problem and applicability statement would be advantageous. -Gert ________________________________________ From: ccamp-bounces@ietf.org on behalf of Zafar Al= i (zali) Sent: Wednesday, August 14, 2013 4:20:42 PM To: Daniele Ceccarelli; Fatai Zhang; John E Drake; Matt Hartley (mhartley);= CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.= txt >John and I are saying exactly the same thing. We don't disagree on >procedures, we only disagree on PCEP vs RSVP-TE > I have the same disagreement with John. We have a situation that we should let the Market decide. Thanks Regards...Zafar _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Wed Aug 14 08:55:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29011E817D for ; Wed, 14 Aug 2013 08:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv+Ynigct6EJ for ; Wed, 14 Aug 2013 08:55:37 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5644F11E8186 for ; Wed, 14 Aug 2013 08:55:32 -0700 (PDT) Received: from mail56-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Aug 2013 15:55:31 +0000 Received: from mail56-ch1 (localhost [127.0.0.1]) by mail56-ch1-R.bigfish.com (Postfix) with ESMTP id 56284300106; Wed, 14 Aug 2013 15:55:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail56-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(13464003)(37854004)(51704005)(377454003)(76786001)(76796001)(19580405001)(51856001)(77096001)(76576001)(49866001)(46102001)(69226001)(76482001)(83322001)(19580395003)(4396001)(74502001)(81686001)(81816001)(53806001)(56816003)(80022001)(74876001)(74706001)(79102001)(74366001)(74316001)(77982001)(16406001)(81542001)(56776001)(54356001)(47736001)(74662001)(31966008)(47446002)(59766001)(50986001)(66066001)(33646001)(80976001)(65816001)(47976001)(63696002)(81342001)(54316002)(83072001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail56-ch1 (localhost.localdomain [127.0.0.1]) by mail56-ch1 (MessageSwitch) id 1376495728681353_15770; Wed, 14 Aug 2013 15:55:28 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail56-ch1.bigfish.com (Postfix) with ESMTP id 8CA4518004A; Wed, 14 Aug 2013 15:55:28 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 14 Aug 2013 15:55:28 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 14 Aug 2013 15:55:27 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 14 Aug 2013 15:55:25 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.235]) with mapi id 15.00.0731.000; Wed, 14 Aug 2013 15:55:25 +0000 From: John E Drake To: "Zafar Ali (zali)" , Daniele Ceccarelli , Fatai Zhang , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNW56AgAAHERCABER8AIAAGcGwgAESDICAAY7KgIAAWzyAgAAMogCAABmgUA== Date: Wed, 14 Aug 2013 15:55:24 +0000 Message-ID: <4591527cdda44db8b86060f1eaf8e713@BY2PR05MB142.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE48138D4D@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0938781D02 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 15:55:56 -0000 Zafar, Neither Daniele nor you has offered any reason, technical or otherwise, why= a PCEP adjacency across the UNI is not sufficient, or why embedding PCEP w= ithin RSVP-TE is either necessary or desirable. I think the WG should decide, *not* the Market . Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Wednesday, August 14, 2013 7:21 AM > To: Daniele Ceccarelli; Fatai Zhang; John E Drake; Matt Hartley (mhartley= ); > CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 >=20 > >John and I are saying exactly the same thing. We don't disagree on > >procedures, we only disagree on PCEP vs RSVP-TE > > >=20 > I have the same disagreement with John. We have a situation that we shoul= d > let the Market decide. >=20 > Thanks >=20 > Regards...Zafar >=20 >=20 From zali@cisco.com Wed Aug 14 09:27:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B7D11E81F0 for ; Wed, 14 Aug 2013 09:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxLbfKYNC-y4 for ; Wed, 14 Aug 2013 09:27:51 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2811E817D for ; Wed, 14 Aug 2013 09:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2057; q=dns/txt; s=iport; t=1376497671; x=1377707271; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=hrXUzVCwcP+JT3BSOPVw3jQz57h19XCWjZXv1d6MZ3g=; b=KblshP+fPpvSVJVvvg4iAe7/uZAs57oHWsvDMwANI0L61gbYu6QRm047 NC9LggDcaDBchXKV6j8mAd6bdmpb0+d2phXe/nw7dZ90bhiN1DWJBP2Ks 3svqHLogIfDDLpszzJVmDsrunK1PSLKRQRrD4ecS8qRdSjduCEo3XHAl7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAPiuC1KtJXG//2dsb2JhbABbgwaBBb5lgSQWdIIkAQEBBIEFBgEIEQMBAQELHTkUCQgCBAESCBOHdbkrkB84BoMVdwOpNoMbgio X-IronPort-AV: E=Sophos;i="4.89,878,1367971200"; d="scan'208";a="247304991" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 14 Aug 2013 16:27:45 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7EGRjaE000982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 16:27:45 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.190]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 11:27:45 -0500 From: "Zafar Ali (zali)" To: John E Drake , Daniele Ceccarelli , Fatai Zhang , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: Ac6UXh3OMYPEaNUmSzSE7m3SYlvx7wARnPhAACdi0mAAC5fEgACIaeoAAAUjU4AAIFYxgAAx2VuAAAtnb4D//8mUAIAAXYMA///F+AA= Date: Wed, 14 Aug 2013 16:27:44 +0000 Message-ID: In-Reply-To: <4591527cdda44db8b86060f1eaf8e713@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.236.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <483B6D8530DB3D4ABCCD7C6654F2881D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:27:56 -0000 John:=20 BTW I can say the same for the PCEP only based solution you have been enforcing.=20 You have been constantly ignoring everything said to force a PCEP only based solution, including requirements that there are existing and new deployment scenarios in which having a PCE is not a luxury (just to suite "your" solution). Some of this is just OAM and other cost considerations. I may detail more in a future response but really running out of stream and feel like I am hitting a brick wall. N. b. Some of your objections are for solutions outlined in WG documents (e.g., metric and SRLG recording), for which WG has already spoken. Thanks Regards =8A Zafar -----Original Message----- From: "jdrake@juniper.net" Date: Wednesday, August 14, 2013 11:55 AM To: zali , Daniele Ceccarelli , Fatai Zhang , "Matt Hartley (mhartley)" , "ccamp@ietf.org" Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt >Zafar, > >Neither Daniele nor you has offered any reason, technical or otherwise, >why a PCEP adjacency across the UNI is not sufficient, or why embedding >PCEP within RSVP-TE is either necessary or desirable. > >I think the WG should decide, *not* the Market . > >Yours Irrespectively, > >John > >> -----Original Message----- >> From: Zafar Ali (zali) [mailto:zali@cisco.com] >> Sent: Wednesday, August 14, 2013 7:21 AM >> To: Daniele Ceccarelli; Fatai Zhang; John E Drake; Matt Hartley >>(mhartley); >> CCAMP (ccamp@ietf.org) >> Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- >> 03.txt >>=20 >>=20 >> >John and I are saying exactly the same thing. We don't disagree on >> >procedures, we only disagree on PCEP vs RSVP-TE >> > >>=20 >> I have the same disagreement with John. We have a situation that we >>should >> let the Market decide. >>=20 >> Thanks >>=20 >> Regards...Zafar >>=20 >>=20 > > From jdrake@juniper.net Wed Aug 14 09:52:48 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562DB11E817B for ; Wed, 14 Aug 2013 09:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMbJ37q+Gf7h for ; Wed, 14 Aug 2013 09:52:42 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 08B4121E808C for ; Wed, 14 Aug 2013 09:52:41 -0700 (PDT) Received: from mail82-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Aug 2013 16:52:41 +0000 Received: from mail82-co1 (localhost [127.0.0.1]) by mail82-co1-R.bigfish.com (Postfix) with ESMTP id 341F8D20222; Wed, 14 Aug 2013 16:52:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail82-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(189002)(37854004)(199002)(51704005)(13464003)(69226001)(74316001)(31966008)(80976001)(74662001)(56816003)(81342001)(80022001)(47446002)(81816001)(74502001)(81686001)(83072001)(16406001)(47736001)(50986001)(74366001)(76796001)(49866001)(4396001)(79102001)(33646001)(76482001)(19580405001)(83322001)(19580395003)(74876001)(76786001)(56776001)(81542001)(74706001)(54356001)(66066001)(65816001)(77982001)(63696002)(59766001)(77096001)(46102001)(51856001)(53806001)(54316002)(47976001)(76576001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail82-co1 (localhost.localdomain [127.0.0.1]) by mail82-co1 (MessageSwitch) id 1376499145427198_1179; Wed, 14 Aug 2013 16:52:25 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.245]) by mail82-co1.bigfish.com (Postfix) with ESMTP id 63E8FD00047; Wed, 14 Aug 2013 16:52:25 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 14 Aug 2013 16:52:25 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 14 Aug 2013 16:52:21 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 14 Aug 2013 16:52:18 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.229]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.235]) with mapi id 15.00.0731.000; Wed, 14 Aug 2013 16:52:18 +0000 From: John E Drake To: "Zafar Ali (zali)" , Daniele Ceccarelli , Fatai Zhang , "Matt Hartley (mhartley)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt Thread-Index: AQHOlKTo7V3wOvni1UKQZtjobSuhG5mNW56AgAAHERCABER8AIAAGcGwgAESDICAAY7KgIAAWzyAgAAMogCAABmgUIAACd4AgAAB9sA= Date: Wed, 14 Aug 2013 16:52:18 +0000 Message-ID: <26a06e15e32146eb9f3d50a3c5c6f9e5@BY2PR05MB142.namprd05.prod.outlook.com> References: <4591527cdda44db8b86060f1eaf8e713@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0938781D02 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:52:48 -0000 Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Wednesday, August 14, 2013 9:28 AM > To: John E Drake; Daniele Ceccarelli; Fatai Zhang; Matt Hartley (mhartley= ); > CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound- > 03.txt >=20 > John: >=20 > BTW I can say the same for the PCEP only based solution you have been > enforcing. JD: PCEP is a given. You are insisting that it needs to be embedded withi= n RSVP-TE and I am merely asking why that is either necessary or desirable. >=20 > You have been constantly ignoring everything said to force a PCEP only ba= sed > solution, including requirements that there are existing and new deployme= nt > scenarios in which having a PCE is not a luxury (just to suite "your" sol= ution). JD: As above, the only point of discussion is why you feel it is necessary= to embed it within RSVP-TE signaling. The draft says that this is necessa= ry in environments where PCEP is not available. Since you are, in fact, us= ing PCEP this argument is clearly nonsensical. > Some of this is just OAM and other cost considerations. > I may detail more in a future response but really running out of stream a= nd > feel like I am hitting a brick wall. JD: As an exercise in character development, I will be kind and restrain m= yself from commenting. >=20 > N. b. Some of your objections are for solutions outlined in WG documents > (e.g., metric and SRLG recording), for which WG has already spoken. JD: Just because they are WG documents does not mean they are inviolable. = Ill-advised technical solutions, such as TE metric recording, can be ident= ified and corrected at any point in the process. =20 =20 >=20 > Thanks >=20 > Regards =A9 Zafar >=20 >=20 > -----Original Message----- > From: "jdrake@juniper.net" > Date: Wednesday, August 14, 2013 11:55 AM > To: zali , Daniele Ceccarelli > , Fatai Zhang , > "Matt Hartley (mhartley)" , "ccamp@ietf.org" > > Subject: RE: [CCAMP] > draft-ali-ccamp-rc-objective-function-metric-bound-03.txt >=20 > >Zafar, > > > >Neither Daniele nor you has offered any reason, technical or otherwise, > >why a PCEP adjacency across the UNI is not sufficient, or why embedding > >PCEP within RSVP-TE is either necessary or desirable. > > > >I think the WG should decide, *not* the Market . > > > >Yours Irrespectively, > > > >John > > > >> -----Original Message----- > >> From: Zafar Ali (zali) [mailto:zali@cisco.com] > >> Sent: Wednesday, August 14, 2013 7:21 AM > >> To: Daniele Ceccarelli; Fatai Zhang; John E Drake; Matt Hartley > >>(mhartley); CCAMP (ccamp@ietf.org) > >> Subject: Re: [CCAMP] > >>draft-ali-ccamp-rc-objective-function-metric-bound- > >> 03.txt > >> > >> > >> >John and I are saying exactly the same thing. We don't disagree on > >> >procedures, we only disagree on PCEP vs RSVP-TE > >> > > >> > >> I have the same disagreement with John. We have a situation that we > >>should let the Market decide. > >> > >> Thanks > >> > >> Regards...Zafar > >> > >> > > > > >=20 >=20 From adrian@olddog.co.uk Thu Aug 15 14:18:31 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA66311E81F3 for ; Thu, 15 Aug 2013 14:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WospKgCNoTUS for ; Thu, 15 Aug 2013 14:18:24 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3CA11E817E for ; Thu, 15 Aug 2013 14:18:23 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7FLIF2A013293; Thu, 15 Aug 2013 22:18:15 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7FLIEQI013272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Aug 2013 22:18:14 +0100 From: "Adrian Farrel" To: "'BRUNGARD, DEBORAH A'" References: In-Reply-To: Date: Thu, 15 Aug 2013 22:18:11 +0100 Message-ID: <013901ce99fc$f2c68d70$d853a850$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01CE9A05.548FFE80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF383DJuOr2os8rT4SGolFrdggyBJpEElQg Content-Language: en-gb Cc: ccamp@ietf.org Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 21:18:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013A_01CE9A05.548FFE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am listed as a contributing author of this document. I'm not aware of any IPR that applies to this draft other than that which others have disclosed. Adrian From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: 09 August 2013 19:11 To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. ------=_NextPart_000_013A_01CE9A05.548FFE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am listed as a contributing = author of this document.

 

I'm not aware of any IPR that = applies to this draft other than that which others have = disclosed.

 

Adrian

 

From: = ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = BRUNGARD, DEBORAH A
Sent: 09 August 2013 = 19:11
To: = draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: = ccamp@ietf.org
Subject: [CCAMP] Regarding IPR on = draft-ogrcetal-ccamp-flexi-grid-fwk

 

Authors, Contributors, = (CCAMP)

 

As part of the preparation for WG = document adoption:

 

Are you aware of any IPR that applies to = draft identified above?

 

  Please state = either:

 

  "No, I'm not aware of any IPR = that applies to this draft"

  = or

  "Yes, I'm aware of IPR that = applies to this draft"

 

If so, has this IPR been disclosed in = compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for = more details)?

 

   If yes to the above, please = state either:

 

  "Yes, the IPR has been = disclosed in compliance with IETF IPR = rules"

  = or

  "No, the IPR has not been = disclosed"

 

  If you answer no, please provide = any additional details you think

  = appropriate.

 

If you are listed as a document author or = contributor please answer the

above by responding to this email = regardless of whether or not you are

aware of any relevant IPR.  This = document will not advance to the next

stage until a response has been received = from each author and listed

contributor.  NOTE: THIS APPLIES TO = ALL OF YOU LISTED IN THIS

MESSAGE'S TO = LINES.

 

If you are on the CCAMP WG email list but = are not listed as an author or

contributor, we remind you of your = obligations under the IETF IPR rules

which encourages you to notify the IETF = if you are aware of IPR of

others on an IETF contribution, or to = refrain from participating in any

contribution or discussion related to = your undisclosed IPR.  For more

information, please see the RFCs listed = above and

 

Thank = you,

CCAMP WG = Chairs

 

PS Please include all listed in the = headers of this message in your

response.

 

 

------=_NextPart_000_013A_01CE9A05.548FFE80-- From adrian@olddog.co.uk Sun Aug 18 11:03:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314A011E8171 for ; Sun, 18 Aug 2013 11:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sD5HprL6goWE for ; Sun, 18 Aug 2013 11:03:49 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id EA0C611E814B for ; Sun, 18 Aug 2013 11:03:48 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7II3jGH024666; Sun, 18 Aug 2013 19:03:45 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7II3hRk024637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Aug 2013 19:03:44 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , "'Daniele Ceccarelli'" References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> <51F94497.8010402@labn.net> In-Reply-To: <51F94497.8010402@labn.net> Date: Sun, 18 Aug 2013 19:03:44 +0100 Message-ID: <044501ce9c3d$48007250$d80156f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXx93VA/UdhQko2wImjUTLAiqMbQK/MUvxAZHZ7gGY5mF6IA== Content-Language: en-gb Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 18:03:55 -0000 Hi all, > > At the end of the intro we added the following sentence: > > " As far as it concerns routing, analogous considerations apply to IS-IS > > [RFC5307] but in the following only a gap analysis with respect to OSPF-TE is > > provided." > > > > Given that the analysis for 5307 is pretty similar to 4203, I think you > should take a pass at including it as well. I'm happy to > review/contribute as needed. > > Thanks, > Lou (chair & doc shepherd) Was there any further progress on this? I see that the current revision addresses all other points. The note added to excuse mentioning IS-IS is a bit skinny, and I would not like to bet money on you having actually done the analysis to support adding it :-) It may be the case that only a small proportion of CCAMP is interested in IS-IS, and it may be the case that the intersection of those people with those interested in OTN is vanishingly small. If that is the case (I guess Lou can find out) we should excuse IS-IS in a more open and blatant way while soliciting and offering to help work on IS-IS for OTN. Cheers, Adrian From adrian@olddog.co.uk Sun Aug 18 12:11:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFBB21F9E45 for ; Sun, 18 Aug 2013 12:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm8hasxcMV6S for ; Sun, 18 Aug 2013 12:11:35 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3597B21F9D0D for ; Sun, 18 Aug 2013 12:11:34 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7IJBX6E020142; Sun, 18 Aug 2013 20:11:33 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7IJBWin020132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Aug 2013 20:11:33 +0100 From: "Adrian Farrel" To: Date: Sun, 18 Aug 2013 20:11:33 +0100 Message-ID: <045e01ce9c46$c1042080$430c6180$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6cRrn+HX0rSFNVT2WODMAhTBetcA== Content-Language: en-gb Cc: ccamp@ietf.org Subject: [CCAMP] AD review of draft-ietf-ccamp-gmpls-signaling-g709v3 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 19:11:40 -0000 Hi, Here is my usual AD review of this document. You have approached a pretty icky-complex topic well, and produced a readable (if technical) document. Well done! I have only a few nits as comments and propose to enter them as IETF last-call comments as the document moves forward. (They care copied below for your information). The next thing you should see is the IETF last call announcement. Thanks, Adrian --- Please fix the two lines that are too long (see idnits) --- Please expand "OTN" on first use in the main text. Please expand "TS" on its first use. --- 6.2 The ingress node of an LSP MAY include Label ERO (Explicit Route Object) to indicate the label in each hops along the path. Missing "subobject". --- 6.2.1 When an upstream node receives a Resv message containing an GENERALIZED_LABEL object s/an/a/ --- Please consider and note what updates to GMPLS management tools are needed. Are there any changes to the Alarms that might arise? We have a document for that. Are there any changes to the way OAM is controlled? We have a document for that. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? --- Please fix so that you have three sections: Authors' Addresses (only those people on the front page) Contributors (other people who made significant text contributions to the document) Acknowledgements (other people who helped with the work) --- [OTN-OSPF] should be a normative reference for its use to define the value of the switching type used in signaling. From iesg-secretary@ietf.org Mon Aug 19 06:07:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8B011E8271; Mon, 19 Aug 2013 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfXagEDrOEkc; Mon, 19 Aug 2013 06:07:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E925311E826F; Mon, 19 Aug 2013 06:07:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Sender: Message-ID: <20130819130720.29345.36809.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 06:07:20 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: (Framework for GMPLS and PCE Control of G.709 Optical Transport Networks) to Informational RFC X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 13:07:25 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Framework for GMPLS and PCE Control of G.709 Optical Transport Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as published in 2012. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-g709-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-g709-framework/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Aug 19 06:14:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1480811E827E; Mon, 19 Aug 2013 06:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BANuawSF2lKu; Mon, 19 Aug 2013 06:14:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00711E822F; Mon, 19 Aug 2013 06:14:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Sender: Message-ID: <20130819131425.18548.82816.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 06:14:25 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 13:14:28 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract ITU-T Recommendation G.709 [G709-2012] has introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. This document updates the ODU-related portions of RFC4328 to to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the full set of OTN features including ODU0, ODU4, ODU2e and ODUflex. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1836/ http://datatracker.ietf.org/ipr/1790/ From lberger@labn.net Mon Aug 19 13:35:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B5511E82EB for ; Mon, 19 Aug 2013 13:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqCutw9V3x5z for ; Mon, 19 Aug 2013 13:35:49 -0700 (PDT) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 026A411E80EF for ; Mon, 19 Aug 2013 13:35:48 -0700 (PDT) Received: (qmail 23756 invoked by uid 0); 19 Aug 2013 20:35:25 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.mail.unifiedlayer.com with SMTP; 19 Aug 2013 20:35:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=xQnKZcWzYb5uVUT4RbLqZk8GwNiOHRbV8mT63Gx7DgQ=; b=0Jrgq6C+cudNVGNvcCvTxyiP2RU4VzI5H1zfc2cuhrYht0O3p6hLdXXxMDeZ8Axk9UG1mDL6nWoS869QVqShsV90DaSFZXme195XomLd3cW/jKVlBugipJ+jRTyUwWqm; Received: from box313.bluehost.com ([69.89.31.113]:56554 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBWAe-0002oD-Pt; Mon, 19 Aug 2013 14:35:24 -0600 Message-ID: <5212818C.8030409@labn.net> Date: Mon, 19 Aug 2013 16:35:24 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Daniele Ceccarelli' , draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> <51F94497.8010402@labn.net> <044501ce9c3d$48007250$d80156f0$@olddog.co.uk> In-Reply-To: <044501ce9c3d$48007250$d80156f0$@olddog.co.uk> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:35:54 -0000 Adrian, I suspect that we've been hit by some post-IETF vacationing. Daniele, Authors, Any additional thoughts on this one remaining open issue? Thanks, Lou On 8/18/2013 2:03 PM, Adrian Farrel wrote: > Hi all, > >>> At the end of the intro we added the following sentence: >>> " As far as it concerns routing, analogous considerations apply to IS-IS >>> [RFC5307] but in the following only a gap analysis with respect to OSPF-TE > is >>> provided." >>> >> >> Given that the analysis for 5307 is pretty similar to 4203, I think you >> should take a pass at including it as well. I'm happy to >> review/contribute as needed. >> >> Thanks, >> Lou (chair & doc shepherd) > > Was there any further progress on this? > > I see that the current revision addresses all other points. The note added to > excuse mentioning IS-IS is a bit skinny, and I would not like to bet money on > you having actually done the analysis to support adding it :-) > > It may be the case that only a small proportion of CCAMP is interested in IS-IS, > and it may be the case that the intersection of those people with those > interested in OTN is vanishingly small. If that is the case (I guess Lou can > find out) we should excuse IS-IS in a more open and blatant way while soliciting > and offering to help work on IS-IS for OTN. > > Cheers, > Adrian > > > > > From adrian@olddog.co.uk Mon Aug 19 19:25:02 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3281211E832B for ; Mon, 19 Aug 2013 19:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsM-SBravSGd for ; Mon, 19 Aug 2013 19:24:57 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 4E71711E8328 for ; Mon, 19 Aug 2013 19:24:56 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7K2Otsl031966; Tue, 20 Aug 2013 03:24:55 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7K2OsHA031952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Aug 2013 03:24:55 +0100 From: "Adrian Farrel" To: Date: Tue, 20 Aug 2013 03:24:53 +0100 Message-ID: <070d01ce9d4c$7494d7b0$5dbe8710$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6dTEcKu+t/jfNZQGSgn8j1NS4jFw== Content-Language: en-gb Cc: ccamp@ietf.org Subject: [CCAMP] Nit in CCAMP minutes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 02:25:02 -0000 Hi, The minutes for items 20 and 21 show me saying: > Adrian Farrel: AD hat off - My name appears on applicability I-D, but not on the use > cases. This is not an accident, if we go for option 1 fine, if we go for option 2 I would > not support. I do not think the approach is good or even possible. This is not how we > should build networks. This is an unfortunate reversal of what I said. At around minute 56 of the audio file https://www.ietf.org/audio/ietf87/ietf87-potsdam1-20130731-1300-pm1.mp3 you can hear me say... "AD hat off - My name appears on applicability I-D, but not on the use cases. This is not an accident. If we were to go for option 1 I would have severe problems. I'm definitely an option 2 person, so I can be in favour of one document and opposed to the other. I don't think the ONI approach is good or desirable. I don't like the mechanism proposed for sharing routing information. It's not that I see the UNI definition as being you must, must not share routing information, I just don't see that that's the way we should build networks." Later on in the same section I am reported as saying: > Adrian Farrel: Which is perhaps a little terse :-) The audio records... "The enhanced mode in L1VPN recognised there was function there, but didn't need to call it any other special type of interface. It was just two networks talking to each other." I'm not asking for a verbatim record (I like the way the minutes are reported as salient points not a transcript), but I would like the initial point sorted out a bit, please. Thanks, Adrian From daniele.ceccarelli@ericsson.com Tue Aug 20 00:18:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595D311E81DE for ; Tue, 20 Aug 2013 00:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.616 X-Spam-Level: X-Spam-Status: No, score=-3.616 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJZHhkEtEV5d for ; Tue, 20 Aug 2013 00:18:16 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 901AF11E81DB for ; Tue, 20 Aug 2013 00:18:15 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-2f-521318358084 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8D.77.25272.53813125; Tue, 20 Aug 2013 09:18:14 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Tue, 20 Aug 2013 09:18:13 +0200 From: Daniele Ceccarelli To: Lou Berger , "adrian@olddog.co.uk" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model Thread-Index: Ac6LhtnSfQOotGSxTSGTJyWDc179HQCSrD6AAAuS2YADiytYAAA3lpwAABeT68A= Date: Tue, 20 Aug 2013 07:18:12 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481443D9@ESESSMB301.ericsson.se> References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> <51F94497.8010402@labn.net> <044501ce9c3d$48007250$d80156f0$@olddog.co.uk> <5212818C.8030409@labn.net> In-Reply-To: <5212818C.8030409@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja6ZhHCQweyP/BY/em4wWzyZc4PF Ysrs7ywWHc1vWRxYPJYs+cnk8WFTM5vHis0rGT2+XP7MFsASxWWTkpqTWZZapG+XwJXxY9tb xoLrmhVrDzSxNzDeUuhi5OSQEDCReHx9PRuELSZx4R6ELSRwlFGid7VaFyMXkL2EUaLn1gyg BAcHm4CVxJNDPiA1IgL7GSXOtIuA2MwCqhJt10+xgtjCAm4Sv7bPY4aocZdY1nWUCcL2k5iw 7ivYfBag+jnz/jKC2LwC3hL9vxug9j5nlNjwhx3E5hTQkOjtaAWLMwrISkzYvYgRYpe4xK0n 85kgbhaQWLLnPDOELSrx8vE/VghbSaJxyRNWiHo9iRtTp7BB2NoSyxa+ZobYKyhxcuYTlgmM YrOQjJ2FpGUWkpZZSFoWMLKsYuQoTi1Oyk03MtjECIylg1t+W+xgvPzX5hCjNAeLkjjvFr0z gUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYmwMMmjM2m/2JjJy4pJO/x3hny+PrAn8VJn5Y YR63t+DvjoOz3rJ3ZPPfFujfaK9Wd+2lbbS7aSrnA0HHvc6LWiIlf1R5PdigmPZrnvL5l9pH H03ff4slT+WB/Y5fux1kxQ/LPOdfsvKB5a+ryQoXXjv9N3spPqWc89+Xy+uv1NuqzTvJlCM+ VYmlOCPRUIu5qDgRAKgT5yxzAgAA Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 07:18:22 -0000 Lou, Adrian, > > It may be the case that only a small proportion of CCAMP is interested > > in IS-IS, and it may be the case that the intersection of those people > > with those interested in OTN is vanishingly small. If that is the case I think that's the case > > (I guess Lou can find out) we should excuse IS-IS in a more open and > > blatant way while soliciting and offering to help work on IS-IS for OTN= . I've searched the words routing and OSPF in the text. The word routing occu= rs 13 times (6 meaningful, i.e. not references, abstract etc) and OSPF 11 t= imes (4 meaningful). We might focus on the meaningful ones and see where IS-IS can be brought in= . -Routing occurrence #6 "ODU3 H-LSP is eligible from ODU2 LSP perspective since from the routing it is known that this ODU3 interface at node Z, supports an ODU2 termination exporting a TS granularity 1.25Gbps/2.5Gbps." [DC] it should be generic enough to cover both OSPF and IS-IS -Routing occurrence #7 "The TS granularity information is needed in the routing protocol as the ingress node (A in the previous example) needs to know" [DC] it should be generic enough to cover both OSPF and IS-IS -Routing occurrences #8 and #9 "In conclusion both routing and signaling needs to be extended to appropriately represent the TS granularity/PT information. Routing needs to represent a link's TS granularity and PT capabilities as well as the supported multiplexing hierarchy" [DC] it should be generic enough to cover both OSPF and IS-IS -Routing occurrence #10 " From a routing perspective, [RFC4203] allows advertising [RFC4328] interfaces (single TS type) without the capability of providing precise information about bandwidth specific allocation." [DC] We could change this into: " From an OSPF perspective, [RFC4203] allows advertising [RFC4328] interfaces (single TS type) without the capability of providing precise information about bandwidth specific allocation. In the case of IS-IS no extension is defined for [RFC4328]. - Routing occurrence #11 "With respect to the routing, please note that in case of multi stage multiplexing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/ OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, but also the intermediate one (ODU2). This is a typical case of spatial allocation problem." [DC] it should be generic enough to cover both OSPF and IS-IS - OSPF occurrence #3 "In conclusion, the OSPF-TE extensions defined in [RFC4203] require a different ISCD per signal type in order to advertise each supported container." [DC] We could change this into: "In conclusion, the OSPF-TE extensions defined in [RFC4203] require a different ISCD per signal type in order to advertise each supported container, while in the case of IS-IS... (suggestions welcome). - OSPF occurrence #4 "Per [RFC2328], OSPF messages are directly encapsulated in IP datagrams and depend on IP fragmentation when transmitting packets larger than the network MTU." - OSPF occurrences #5 and #6 "[RFC2328] recommends that "IP fragmentation should be avoided whenever possible." This recommendation further constraints solutions as OSPF does not support any generic mechanism to fragment OSPF LSAs." [DC] I only could find an expired draft regarding IS-IS encapsulation in IP= datagrams BR Daniele > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: luned=EC 19 agosto 2013 22:35 > To: adrian@olddog.co.uk; Daniele Ceccarelli; draft-ietf-ccamp-otn-g709-in= fo- > model@tools.ietf.org > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model >=20 > Adrian, >=20 > I suspect that we've been hit by some post-IETF vacationing. >=20 > Daniele, Authors, >=20 > Any additional thoughts on this one remaining open issue? >=20 > Thanks, > Lou >=20 > On 8/18/2013 2:03 PM, Adrian Farrel wrote: > > Hi all, > > > >>> At the end of the intro we added the following sentence: > >>> " As far as it concerns routing, analogous considerations apply to I= S-IS > >>> [RFC5307] but in the following only a gap analysis with respect to > >>> OSPF-TE > > is > >>> provided." > >>> > >> > >> Given that the analysis for 5307 is pretty similar to 4203, I think > >> you should take a pass at including it as well. I'm happy to > >> review/contribute as needed. > >> > >> Thanks, > >> Lou (chair & doc shepherd) > > > > Was there any further progress on this? > > > > I see that the current revision addresses all other points. The note > > added to excuse mentioning IS-IS is a bit skinny, and I would not like > > to bet money on you having actually done the analysis to support > > adding it :-) > > > > It may be the case that only a small proportion of CCAMP is interested > > in IS-IS, and it may be the case that the intersection of those people > > with those interested in OTN is vanishingly small. If that is the case > > (I guess Lou can find out) we should excuse IS-IS in a more open and > > blatant way while soliciting and offering to help work on IS-IS for OTN= . > > > > Cheers, > > Adrian > > > > > > > > > > From lberger@labn.net Tue Aug 20 06:51:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E32321F995F for ; Tue, 20 Aug 2013 06:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.132 X-Spam-Level: X-Spam-Status: No, score=-102.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DagDDQmHai8p for ; Tue, 20 Aug 2013 06:51:39 -0700 (PDT) Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 99E1421F84E0 for ; Tue, 20 Aug 2013 06:51:38 -0700 (PDT) Received: (qmail 32058 invoked by uid 0); 20 Aug 2013 13:51:13 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 20 Aug 2013 13:51:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=7qHZ+DNzFXs+Pgb7Yb7WnxxKGkJ2oZHBDe+jlnceoec=; b=MV/zvC7wC6iYvJYQxWqeExQdfSk3nS7MU2M5QJpe9gjvjkLLSFsoWLSH/ofDTBorSEgIBj6sO34Zublr8PB3q1BW6V7IZWZHIFWsDPK7kFA7cU8ha71QCqGogrrPbQcN; Received: from box313.bluehost.com ([69.89.31.113]:51997 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBmL3-000434-KX; Tue, 20 Aug 2013 07:51:13 -0600 Message-ID: <5213744D.201@labn.net> Date: Tue, 20 Aug 2013 09:51:09 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <070d01ce9d4c$7494d7b0$5dbe8710$@olddog.co.uk> In-Reply-To: <070d01ce9d4c$7494d7b0$5dbe8710$@olddog.co.uk> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org Subject: Re: [CCAMP] Nit in CCAMP minutes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 13:51:43 -0000 Adrian, Your corrections have been posted. Any additional corrections would be most welcome! Lou On 8/19/2013 10:24 PM, Adrian Farrel wrote: > Hi, > > The minutes for items 20 and 21 show me saying: > >> Adrian Farrel: AD hat off - My name appears on applicability I-D, but not on > the use >> cases. This is not an accident, if we go for option 1 fine, if we go for > option 2 I would >> not support. I do not think the approach is good or even possible. This is not > how we >> should build networks. > > This is an unfortunate reversal of what I said. > At around minute 56 of the audio file > https://www.ietf.org/audio/ietf87/ietf87-potsdam1-20130731-1300-pm1.mp3 you can > hear me say... > > "AD hat off - My name appears on applicability I-D, but not on the use cases. > This is not an accident. If we were to go for option 1 I would have severe > problems. I'm definitely an option 2 person, so I can be in favour of one > document and opposed to the other. I don't think the ONI approach is good or > desirable. I don't like the mechanism proposed for sharing routing information. > It's not that I see the UNI definition as being you must, must not share routing > information, I just don't see that that's the way we should build networks." > > Later on in the same section I am reported as saying: > >> Adrian Farrel: > > Which is perhaps a little terse :-) > > The audio records... > > "The enhanced mode in L1VPN recognised there was function there, but didn't need > to call it any other special type of interface. It was just two networks talking > to each other." > > > I'm not asking for a verbatim record (I like the way the minutes are reported as > salient points not a transcript), but I would like the initial point sorted out > a bit, please. > > Thanks, > Adrian > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Tue Aug 20 07:28:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E9D11E8228 for ; Tue, 20 Aug 2013 07:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.221 X-Spam-Level: X-Spam-Status: No, score=-102.221 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uqAoXB68qXb for ; Tue, 20 Aug 2013 07:27:59 -0700 (PDT) Received: from oproxy9-pub.mail.unifiedlayer.com (oproxy9-pub.mail.unifiedlayer.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 384FA21F9C37 for ; Tue, 20 Aug 2013 07:27:56 -0700 (PDT) Received: (qmail 30703 invoked by uid 0); 20 Aug 2013 14:27:33 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.mail.unifiedlayer.com with SMTP; 20 Aug 2013 14:27:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=xMwDPMGJweuydlbuPIEkEsHuvFc+tQGE51FkM/Lrg6Y=; b=RiAk/O0iRt4ZkljQvs06ZjXskxTGFjaKVoOGqv1CO181SopVq6SPmPeJFD+D2yHcEquIgU+z55ilNKpSHXl8Nu5h0RYH+qstHHZJz31j2mg+pUc3ilFsOsSUL7JPemFo; Received: from box313.bluehost.com ([69.89.31.113]:58555 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBmuD-0003hr-5d; Tue, 20 Aug 2013 08:27:33 -0600 Message-ID: <52137CD5.7000206@labn.net> Date: Tue, 20 Aug 2013 10:27:33 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Daniele Ceccarelli References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> <51F94497.8010402@labn.net> <044501ce9c3d$48007250$d80156f0$@olddog.co.uk> <5212818C.8030409@labn.net> <4A1562797D64E44993C5CBF38CF1BE481443D9@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481443D9@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , "ccamp@ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 14:28:04 -0000 Daniele, Thanks for looking at this. I think we're almost there. See below for details that hopefully let us close on this. On 8/20/2013 3:18 AM, Daniele Ceccarelli wrote: > Lou, Adrian, > >>> It may be the case that only a small proportion of CCAMP is interested >>> in IS-IS, and it may be the case that the intersection of those people >>> with those interested in OTN is vanishingly small. If that is the case > > I think that's the case > >>> (I guess Lou can find out) we should excuse IS-IS in a more open and >>> blatant way while soliciting and offering to help work on IS-IS for OTN. > > I've searched the words routing and OSPF in the text. The word routing occurs 13 times (6 meaningful, i.e. not references, abstract etc) and OSPF 11 times (4 meaningful). > I think you need to expand your search to include [RFC4203]. s/as defined by [RFC4203],/as defined by [RFC4203], [RFC5307], s/[RFC4203] only allows/GMPLS OSPF [RFC4203] and GMPLS IS-IS [RFC5307] only allow s/tools provided by [RFC4203]/tools provided by [RFC4203] and [RFC5307] s/the OSPF-TE extensions defined in [RFC4203] require/the routing extensions defined in [RFC4203] and [RFC5307] require s/[RFC4202] and [RFC4203]/[RFC4202], [RFC4203] and [RFC5307] Can now drop: As far as it concerns routing, analogous considerations apply to IS-IS [RFC5307] but in the following only a gap analysis with respect to OSPF-TE is provided. > We might focus on the meaningful ones and see where IS-IS can be brought in. > > -Routing occurrence #6 > "ODU3 H-LSP is eligible from ODU2 LSP > perspective since from the routing it is known that this ODU3 > interface at node Z, supports an ODU2 termination exporting a TS > granularity 1.25Gbps/2.5Gbps." > [DC] it should be generic enough to cover both OSPF and IS-IS > > -Routing occurrence #7 > "The TS granularity information is needed in the routing protocol as > the ingress node (A in the previous example) needs to know" > [DC] it should be generic enough to cover both OSPF and IS-IS > > -Routing occurrences #8 and #9 > "In conclusion both routing and signaling needs to be extended to > appropriately represent the TS granularity/PT information. Routing > needs to represent a link's TS granularity and PT capabilities as > well as the supported multiplexing hierarchy" > [DC] it should be generic enough to cover both OSPF and IS-IS > > -Routing occurrence #10 > " From a routing perspective, [RFC4203] allows advertising [RFC4328] > interfaces (single TS type) without the capability of providing > precise information about bandwidth specific allocation." > [DC] We could change this into: > " From an OSPF perspective, [RFC4203] allows advertising [RFC4328] > interfaces (single TS type) without the capability of providing > precise information about bandwidth specific allocation. In the case of > IS-IS no extension is defined for [RFC4328]. > see above for an alternate proposal. > - Routing occurrence #11 > "With respect to the routing, please note that in case of multi stage > multiplexing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/ > OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, > but also the intermediate one (ODU2). This is a typical case of > spatial allocation problem." > [DC] it should be generic enough to cover both OSPF and IS-IS should be "With respect to routing," (drop the) > > - OSPF occurrence #3 > "In conclusion, the OSPF-TE extensions defined in [RFC4203] require a > different ISCD per signal type in order to advertise each supported > container." > [DC] We could change this into: > "In conclusion, the OSPF-TE extensions defined in [RFC4203] require a > different ISCD per signal type in order to advertise each supported > container, while in the case of IS-IS... (suggestions welcome). > see above. > - OSPF occurrence #4 > "Per [RFC2328], OSPF messages are directly encapsulated in IP > datagrams and depend on IP fragmentation when transmitting packets > larger than the network MTU." > - OSPF occurrences #5 and #6 > "[RFC2328] recommends that "IP > fragmentation should be avoided whenever possible." This > recommendation further constraints solutions as OSPF does not support > any generic mechanism to fragment OSPF LSAs." > [DC] I only could find an expired draft regarding IS-IS encapsulation in IP datagrams > Per [RFC2328] should start a new paragraph. You could add. "Even when used in IP environments IS-IS [RFC1195], does not support message sizes larger than a link's maximum frame size." I think that's it. Lou > BR > Daniele > > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: lunedì 19 agosto 2013 22:35 >> To: adrian@olddog.co.uk; Daniele Ceccarelli; draft-ietf-ccamp-otn-g709-info- >> model@tools.ietf.org >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model >> >> Adrian, >> >> I suspect that we've been hit by some post-IETF vacationing. >> >> Daniele, Authors, >> >> Any additional thoughts on this one remaining open issue? >> >> Thanks, >> Lou >> >> On 8/18/2013 2:03 PM, Adrian Farrel wrote: >>> Hi all, >>> >>>>> At the end of the intro we added the following sentence: >>>>> " As far as it concerns routing, analogous considerations apply to IS-IS >>>>> [RFC5307] but in the following only a gap analysis with respect to >>>>> OSPF-TE >>> is >>>>> provided." >>>>> >>>> >>>> Given that the analysis for 5307 is pretty similar to 4203, I think >>>> you should take a pass at including it as well. I'm happy to >>>> review/contribute as needed. >>>> >>>> Thanks, >>>> Lou (chair & doc shepherd) >>> >>> Was there any further progress on this? >>> >>> I see that the current revision addresses all other points. The note >>> added to excuse mentioning IS-IS is a bit skinny, and I would not like >>> to bet money on you having actually done the analysis to support >>> adding it :-) >>> >>> It may be the case that only a small proportion of CCAMP is interested >>> in IS-IS, and it may be the case that the intersection of those people >>> with those interested in OTN is vanishingly small. If that is the case >>> (I guess Lou can find out) we should excuse IS-IS in a more open and >>> blatant way while soliciting and offering to help work on IS-IS for OTN. >>> >>> Cheers, >>> Adrian >>> >>> >>> >>> >>> > > > > From adrian@olddog.co.uk Tue Aug 20 11:37:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC5A11E813A for ; Tue, 20 Aug 2013 11:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DFnKwr0bQa7 for ; Tue, 20 Aug 2013 11:37:48 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id BAA0A11E8130 for ; Tue, 20 Aug 2013 11:37:44 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7KIbhFe007627; Tue, 20 Aug 2013 19:37:43 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7KIbgrD007617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Aug 2013 19:37:42 +0100 From: "Adrian Farrel" To: Date: Tue, 20 Aug 2013 19:37:40 +0100 Message-ID: <00fd01ce9dd4$5a604810$0f20d830$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6d1CBdLWT5anYNRz+hBZXctBvidQ== Content-Language: en-gb Cc: ccamp@ietf.org Subject: [CCAMP] Question on draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:37:52 -0000 Hello authors of draft-ietf-ccamp-swcaps-update, I'm reviewing your document in response to the publication request. It looks quite straight-forward, but I have an early question. In this document you are deprecating PSC-2, PSC-3, and PSC-4. I believe that the IANA action will cause IANA to update the GMPLS-TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib Just wanted to check that you are OK with this. If you are, we will add a note to the IANA considerations section to make sure they catch this. (No need for document changes at this point - my complete review will come later.) Cheers, Adrian From adrian@olddog.co.uk Tue Aug 20 11:50:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BC511E8131; Tue, 20 Aug 2013 11:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgBjOmlJ3I53; Tue, 20 Aug 2013 11:50:49 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id E6DD711E8144; Tue, 20 Aug 2013 11:50:48 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7KIolaf027502; Tue, 20 Aug 2013 19:50:47 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7KIokYD027494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Aug 2013 19:50:47 +0100 From: "Adrian Farrel" To: Date: Tue, 20 Aug 2013 19:50:44 +0100 Message-ID: <00fe01ce9dd6$2dc59a10$8950ce30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6d1f8U/0fVrXNNRjCEO33cHnCIig== Content-Language: en-gb Cc: ccamp@ietf.org Subject: Re: [CCAMP] Last Call: (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:50:54 -0000 As sponsoring AD I have the following last call comments I hope you will take on board. Thanks, Adrian Please fix the two lines that are too long (see idnits) --- Please expand "OTN" on first use in the main text. Please expand "TS" on its first use. --- 6.2 The ingress node of an LSP MAY include Label ERO (Explicit Route Object) to indicate the label in each hops along the path. Missing "subobject". --- 6.2.1 When an upstream node receives a Resv message containing an GENERALIZED_LABEL object s/an/a/ --- Please consider and note what updates to GMPLS management tools are needed. Are there any changes to the Alarms that might arise? We have a document for that. Are there any changes to the way OAM is controlled? We have a document for that. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? --- Please fix so that you have three sections: Authors' Addresses (only those people on the front page) Contributors (other people who made significant text contributions to the document) Acknowledgements (other people who helped with the work) --- [OTN-OSPF] should be a normative reference for its use to define the value of the switching type used in signaling. From lberger@labn.net Tue Aug 20 13:12:48 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4A611E8142 for ; Tue, 20 Aug 2013 13:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.232 X-Spam-Level: X-Spam-Status: No, score=-102.232 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM7AU7TxvOXw for ; Tue, 20 Aug 2013 13:12:44 -0700 (PDT) Received: from oproxy9-pub.mail.unifiedlayer.com (oproxy9-pub.mail.unifiedlayer.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 9799211E8130 for ; Tue, 20 Aug 2013 13:12:44 -0700 (PDT) Received: (qmail 25727 invoked by uid 0); 20 Aug 2013 20:12:20 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.mail.unifiedlayer.com with SMTP; 20 Aug 2013 20:12:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=FD3bxu3yMNdgHGXgewNd1JiINSdR0UsVfihp/TP60gc=; b=kO68H802lVBjiIQ7jxIyumGKudYh3QjPcOX4C284ICxM0MUedy2LC9LVcLvNpZbvexIZOCUl6m7UEO/3YhNb0kx9PffohyDD1kQhUQTnXr6vZ3OQsPf4IdND+9eGOE9L; Received: from box313.bluehost.com ([69.89.31.113]:60367 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBsHs-0000GO-H5; Tue, 20 Aug 2013 14:12:20 -0600 Message-ID: <5213CDA3.7020503@labn.net> Date: Tue, 20 Aug 2013 16:12:19 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <00fd01ce9dd4$5a604810$0f20d830$@olddog.co.uk> In-Reply-To: <00fd01ce9dd4$5a604810$0f20d830$@olddog.co.uk> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] Question on draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 20:12:48 -0000 Adrian, I think this is correct. Good catch. Lou (document co-author) On 08/20/2013 02:37 PM, Adrian Farrel wrote: > Hello authors of draft-ietf-ccamp-swcaps-update, > > I'm reviewing your document in response to the publication request. It looks > quite straight-forward, but I have an early question. > > In this document you are deprecating PSC-2, PSC-3, and PSC-4. > > I believe that the IANA action will cause IANA to update the GMPLS-TC-MIB at > https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib > > Just wanted to check that you are OK with this. If you are, we will add a note > to the IANA considerations section to make sure they catch this. > > (No need for document changes at this point - my complete review will come > later.) > > Cheers, > Adrian > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From zhangfatai@huawei.com Wed Aug 21 00:41:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4108B11E81C0; Wed, 21 Aug 2013 00:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc+TfkdK0xpN; Wed, 21 Aug 2013 00:41:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 31D6B11E81D7; Wed, 21 Aug 2013 00:41:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUO65662; Wed, 21 Aug 2013 07:41:28 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 21 Aug 2013 08:40:58 +0100 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 21 Aug 2013 08:41:26 +0100 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.110]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Wed, 21 Aug 2013 15:39:33 +0800 From: Fatai Zhang To: "adrian@olddog.co.uk" , "ietf@ietf.org" Thread-Topic: [CCAMP] Last Call: (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard Thread-Index: Ac6d1f8U/0fVrXNNRjCEO33cHnCIigAaKmFg Date: Wed, 21 Aug 2013 07:39:32 +0000 Message-ID: References: <00fe01ce9dd6$2dc59a10$8950ce30$@olddog.co.uk> In-Reply-To: <00fe01ce9dd6$2dc59a10$8950ce30$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85AF38E3ASZXEML552MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Last Call: (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 07:41:34 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF85AF38E3ASZXEML552MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, Thanks very much. I can update the nits and editorial issues quickly, but I would like to dis= cuss more with you for the following points to make things clear before I u= pdate the draft. =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=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=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 Please consider and note what updates to GMPLS management tools are needed. [Fatai]This has been mentioned in [Framework] document. Did you mean that w= e need add one sentence in some place of this document to refer to [Framewo= rk] document to mention management tools? Are there any changes to the Alarms that might arise? We have a document fo= r that. [Fatai] No. RFC4783 is still applicable. Are there any changes to the way OAM is controlled? We have a document for = that. [Fatai] No, it could be done through NMS or [draft-ietf-ccamp-rsvp-te-sdh-o= tn-oam-ext]. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. [Fatai] Will do that. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? [Fatai] I am not sure. I asked the similar question (not on this draft) dur= ing Berlin meeting. The chairs answered that it could be driven by drafts. Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: Wednesday, August 21, 2013 2:51 AM To: ietf@ietf.org Cc: ccamp@ietf.org Subject: Re: [CCAMP] Last Call: (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensi= ons for the evolving G.709 Optical Transport Networks Control) to Proposed = Standard As sponsoring AD I have the following last call comments I hope you will ta= ke on board. Thanks, Adrian Please fix the two lines that are too long (see idnits) --- Please expand "OTN" on first use in the main text. Please expand "TS" on its first use. --- 6.2 The ingress node of an LSP MAY include Label ERO (Explicit Route Object) to indicate the label in each hops along the path. Missing "subobject". --- 6.2.1 When an upstream node receives a Resv message containing an GENERALIZED_LABEL object s/an/a/ --- Please consider and note what updates to GMPLS management tools are needed. Are there any changes to the Alarms that might arise? We have a document for that. Are there any changes to the way OAM is controlled? We have a document for that. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? --- Please fix so that you have three sections: Authors' Addresses (only those people on the front page) Contributors (other people who made significant text contributions to the document) Acknowledgements (other people who helped with the work) --- [OTN-OSPF] should be a normative reference for its use to define the value of the switching type used in signaling. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_F82A4B6D50F9464B8EBA55651F541CF85AF38E3ASZXEML552MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adrian,=

 

Thanks very much.

 

I can update the nits and ed= itorial issues quickly, but I would like to discuss more with you for the f= ollowing points to make things clear before I update the draft.

 

=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=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=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

Please consider and note wha= t updates to GMPLS management tools are needed.

 

[Fat= ai]This has been mentioned in [Framework] document. Did you mean that we ne= ed add one sentence in some place of this document to refer to [Framework] = document to mention management tools?

 

Are there any changes to the= Alarms that might arise? We have a document for that.

 

[Fat= ai] No. RFC4783 is still applicable.=

 

Are there any changes to the= way OAM is controlled? We have a document for that.

 

[Fat= ai] No, it could be done through NMS or [draft-ietf-ccamp-rsvp-te-sdh-otn-o= am-ext].

 

Should the new G-PIDs show i= n the TC MIB managed by IANA at

https://www.iana.org/assignm= ents/ianagmplstc-mib/ianagmplstc-mib.xhtml

This should happen automgica= lly when the feeding registries are updated

but it is probably best to a= dd a specific request for IANA.

 

[Fat= ai] Will do that.

 

Will other MIB work be neede= d (in the future) to make it possible to

read new information (labels= , tspecs) from network devices?

 

[Fat= ai] I am not sure. I asked the similar question (not on this draft) during = Berlin meeting. The chairs answered that it could be driven by drafts.

 

 

 

Best Regards

 

Fatai

 

-----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of A= drian Farrel
Sent: Wednesday, August 21, 2013 2:51 AM
To: ietf@ietf.org
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Last Call: <draft-ietf-ccamp-gmpls-signaling-g709v3= -11.txt> (Generalized Multi-Protocol Label Switching (GMPLS) Signaling E= xtensions for the evolving G.709 Optical Transport Networks Control) to Pro= posed Standard

 

As sponsoring AD I have the = following last call comments I hope you will take on

board.

 

Thanks,

Adrian

 

Please fix the two lines tha= t are too long (see idnits)

 

---

 

Please expand "OTN"= ; on first use in the main text.

Please expand "TS"= on its first use.

 

---

 

6.2

 

   The ingress nod= e of an LSP MAY include Label ERO (Explicit Route

   Object) to= indicate the label in each hops along the path.

 

Missing "subobject"= ;.

 

---

 

6.2.1

 

   When an upstrea= m node receives a Resv message containing an

   GENERALIZE= D_LABEL object

 

s/an/a/

 

---

 

Please consider and note wha= t updates to GMPLS management tools are

needed.

 

Are there any changes to the= Alarms that might arise? We have a document

for that.<= /p>

 

Are there any changes to the= way OAM is controlled? We have a document

for that.<= /p>

 

Should the new G-PIDs show i= n the TC MIB managed by IANA at

https://www.iana.org/assignm= ents/ianagmplstc-mib/ianagmplstc-mib.xhtml

This should happen automgica= lly when the feeding registries are updated

but it is probably best to a= dd a specific request for IANA.

 

Will other MIB work be neede= d (in the future) to make it possible to

read new information (labels= , tspecs) from network devices?

 

---

 

Please fix so that you have = three sections:

 

Authors' Addresses (only tho= se people on the front page)

Contributors (other people w= ho made significant text contributions to

the document)

Acknowledgements (other peop= le who helped with the work)

 

---

 

[OTN-OSPF] should be a norma= tive reference for its use to define the

value of the switching type = used in signaling.

 

____________________________= ___________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman= /listinfo/ccamp

--_000_F82A4B6D50F9464B8EBA55651F541CF85AF38E3ASZXEML552MBSchi_-- From adrian@olddog.co.uk Wed Aug 21 03:12:46 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675BD11E81FE; Wed, 21 Aug 2013 03:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id day94XmTs7Rz; Wed, 21 Aug 2013 03:12:41 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id E598E11E8101; Wed, 21 Aug 2013 03:12:40 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7LACSwV032503; Wed, 21 Aug 2013 11:12:28 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7LACPwc032470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Aug 2013 11:12:26 +0100 From: "Adrian Farrel" To: "'Fatai Zhang'" , References: <00fe01ce9dd6$2dc59a10$8950ce30$@olddog.co.uk> In-Reply-To: Date: Wed, 21 Aug 2013 11:12:24 +0100 Message-ID: <008e01ce9e56$ef180d30$cd482790$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01CE9E5F.50DFF7A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIsbNb5TgnC0suQ8+Rs20wgK20xygJciecUmNDvnBA= Content-Language: en-gb Cc: ccamp@ietf.org Subject: Re: [CCAMP] Last Call: (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 10:12:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008F_01CE9E5F.50DFF7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Fatai, I think you nicely answered your own questions :-) I would suggest adding a small section including all of the statements you made in your email. (Well, no need to refer to Berlin and the CCAMP chairs :-) Cheers, Adrian From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: 21 August 2013 08:40 To: adrian@olddog.co.uk; ietf@ietf.org Cc: ccamp@ietf.org Subject: RE: [CCAMP] Last Call: (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard Hi Adrian, Thanks very much. I can update the nits and editorial issues quickly, but I would like to discuss more with you for the following points to make things clear before I update the draft. ================================================================================ ========= Please consider and note what updates to GMPLS management tools are needed. [Fatai]This has been mentioned in [Framework] document. Did you mean that we need add one sentence in some place of this document to refer to [Framework] document to mention management tools? Are there any changes to the Alarms that might arise? We have a document for that. [Fatai] No. RFC4783 is still applicable. Are there any changes to the way OAM is controlled? We have a document for that. [Fatai] No, it could be done through NMS or [draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext]. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. [Fatai] Will do that. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? [Fatai] I am not sure. I asked the similar question (not on this draft) during Berlin meeting. The chairs answered that it could be driven by drafts. Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, August 21, 2013 2:51 AM To: ietf@ietf.org Cc: ccamp@ietf.org Subject: Re: [CCAMP] Last Call: (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard As sponsoring AD I have the following last call comments I hope you will take on board. Thanks, Adrian Please fix the two lines that are too long (see idnits) --- Please expand "OTN" on first use in the main text. Please expand "TS" on its first use. --- 6.2 The ingress node of an LSP MAY include Label ERO (Explicit Route Object) to indicate the label in each hops along the path. Missing "subobject". --- 6.2.1 When an upstream node receives a Resv message containing an GENERALIZED_LABEL object s/an/a/ --- Please consider and note what updates to GMPLS management tools are needed. Are there any changes to the Alarms that might arise? We have a document for that. Are there any changes to the way OAM is controlled? We have a document for that. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? --- Please fix so that you have three sections: Authors' Addresses (only those people on the front page) Contributors (other people who made significant text contributions to the document) Acknowledgements (other people who helped with the work) --- [OTN-OSPF] should be a normative reference for its use to define the value of the switching type used in signaling. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp ------=_NextPart_000_008F_01CE9E5F.50DFF7A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Fatai,

 

I = think you nicely answered your own questions :-)

 

I = would suggest adding a small section including all of the statements you = made in your email. (Well, no need to refer to Berlin and the CCAMP = chairs :-)

 

Cheers,

Adrian

 

From: Fatai Zhang = [mailto:zhangfatai@huawei.com]
Sent: 21 August 2013 = 08:40
To: adrian@olddog.co.uk; ietf@ietf.org
Cc: = ccamp@ietf.org
Subject: RE: [CCAMP] Last Call: = <draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt> (Generalized = Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the = evolving G.709 Optical Transport Networks Control) to Proposed = Standard

 

Hi = Adrian,

 <= /o:p>

Thanks very = much.

 <= /o:p>

I can = update the nits and editorial issues quickly, but I would like to = discuss more with you for the following points to make things clear = before I update the draft.

 <= /o:p>

=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=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=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

Please = consider and note what updates to GMPLS management tools are = needed.

 <= /o:p>

[Fatai]This has been mentioned in [Framework] document. Did you mean = that we need add one sentence in some place of this document to refer to = [Framework] document to mention management = tools?

 <= /o:p>

Are there = any changes to the Alarms that might arise? We have a document for = that.

 <= /o:p>

[Fatai] No. RFC4783 is still applicable.<= /span>

 <= /o:p>

Are there = any changes to the way OAM is controlled? We have a document for = that.

 <= /o:p>

[Fatai] No, it could be done through NMS or = [draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext].<= /span>

 <= /o:p>

Should the = new G-PIDs show in the TC MIB managed by IANA at

https://www.= iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml

This should = happen automgically when the feeding registries are = updated

but it is = probably best to add a specific request for = IANA.

 <= /o:p>

[Fatai] Will do that.<= /span>

 <= /o:p>

Will other = MIB work be needed (in the future) to make it possible to =

read new = information (labels, tspecs) from network = devices?

 <= /o:p>

[Fatai] I am not sure. I asked the similar question (not on this = draft) during Berlin meeting. The chairs answered that it could be = driven by drafts.<= /span>

 <= /o:p>

 <= /o:p>

 <= /o:p>

Best = Regards

 <= /o:p>

Fatai

 <= /o:p>

-----Origina= l Message-----
From: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: = Wednesday, August 21, 2013 2:51 AM
To: ietf@ietf.org
Cc: = ccamp@ietf.org
Subject: Re: [CCAMP] Last Call: = <draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt> (Generalized = Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the = evolving G.709 Optical Transport Networks Control) to Proposed = Standard

 <= /o:p>

As = sponsoring AD I have the following last call comments I hope you will = take on

board.<= /o:p>

 <= /o:p>

Thanks,=

Adrian<= /o:p>

 <= /o:p>

Please fix = the two lines that are too long (see idnits)

 <= /o:p>

---

 <= /o:p>

Please = expand "OTN" on first use in the main = text.

Please = expand "TS" on its first use.

 <= /o:p>

---

 <= /o:p>

6.2

 <= /o:p>

  = The ingress node of an LSP MAY include Label ERO (Explicit Route =

  =  Object) to indicate the label in each hops along the = path.

 <= /o:p>

Missing = "subobject".

 <= /o:p>

---

 <= /o:p>

6.2.1

 <= /o:p>

  = When an upstream node receives a Resv message containing an =

  =  GENERALIZED_LABEL object

 <= /o:p>

s/an/a/=

 <= /o:p>

---

 <= /o:p>

Please = consider and note what updates to GMPLS management tools = are

needed.=

 <= /o:p>

Are there = any changes to the Alarms that might arise? We have a = document

for = that.

 <= /o:p>

Are there = any changes to the way OAM is controlled? We have a = document

for = that.

 <= /o:p>

Should the = new G-PIDs show in the TC MIB managed by IANA at

https://www.= iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml

This should = happen automgically when the feeding registries are = updated

but it is = probably best to add a specific request for = IANA.

 <= /o:p>

Will other = MIB work be needed (in the future) to make it possible to =

read new = information (labels, tspecs) from network = devices?

 <= /o:p>

---

 <= /o:p>

Please fix = so that you have three sections:

 <= /o:p>

Authors' = Addresses (only those people on the front page)

Contributors= (other people who made significant text contributions = to

the = document)

Acknowledgem= ents (other people who helped with the work)

 <= /o:p>

---

 <= /o:p>

[OTN-OSPF] = should be a normative reference for its use to define the =

value of = the switching type used in signaling.

 <= /o:p>

____________= ___________________________________

CCAMP = mailing list

CCAMP@ietf.o= rg

https://www.= ietf.org/mailman/listinfo/ccamp

<= /html> ------=_NextPart_000_008F_01CE9E5F.50DFF7A0-- From adrian@olddog.co.uk Wed Aug 21 03:56:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1496E11E81FA for ; Wed, 21 Aug 2013 03:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na+uEYcVLRga for ; Wed, 21 Aug 2013 03:55:57 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id E1D0111E8128 for ; Wed, 21 Aug 2013 03:55:56 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7LAttsj017153; Wed, 21 Aug 2013 11:55:55 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7LAtsYv017143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Aug 2013 11:55:54 +0100 From: "Adrian Farrel" To: Date: Wed, 21 Aug 2013 11:55:52 +0100 Message-ID: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6eXPt4rBZeUUS6Sf+PiLTjktojNQ== Content-Language: en-gb Cc: ccamp@ietf.org Subject: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 10:56:16 -0000 Thanks for this simple document. I have carried out my review as AD as part of the publication request process. The purpose of the review is to catch any issues before the document goes to IETF last call and IESG evaluation and to improve the quality of the document. I have not found any thing substantial, but I have three points I would like you to look at before we move forward. All points are open for discussion. For the moment I have put the document in "Revised I-D Needed" state. Thanks for the work. Adrian === Please add a note to the IANA considerations section to request an update to https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml Possibly you should refer to it as IANA-GMPLS-TC-MIB rather than through the URL. --- I would prefer if the message formats were left out of section 1.1. You could leave the paragraphs: The Switching Type values are carried in both routing and signaling protocols. Values are identified in the IANA GMPLS Signaling Parameters Switching Type registry, which is currently located at http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig- parameters.xml For routing, a common information element is defined to carry switching type values for both OSPF and IS-IS routing protocols in [RFC4202]. Per [RFC4202], switching type values are carried in a Switching Capability (Switching Cap) field in an Interface Switching Capability Descriptor. This information shares a common formatting in both OSPF, as defined by [RFC4203], and in IS-IS, as defined by [RFC5307]. Similarly, the Switching Type field is defined as part of a common format for use by GMPLS signaling protocols in [RFC3471] and is used by [RFC3473]. ...and delete the rest without damaging the document. My concern, as usual, is that copying normative material leads to the risk of error, and creates problems if material has to be revised. It is perfectly fine to reference it in nearly every case. --- Section 2.3... These values SHOULD NOT be treated as reserved values, i.e., SHOULD NOT be generated and SHOULD be ignored upon receipt. But in 3473... Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. If the type cannot be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication. Is it your intention to update that piece of 3473? If so, you should call it out more clearly. If not, there is some work needed to reconcile the text. From daniele.ceccarelli@ericsson.com Wed Aug 21 07:39:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB6611E80D9 for ; Wed, 21 Aug 2013 07:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.186 X-Spam-Level: X-Spam-Status: No, score=-5.186 tagged_above=-999 required=5 tests=[AWL=1.063, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7kpadSnFzTx for ; Wed, 21 Aug 2013 07:39:34 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7BE11E83A0 for ; Wed, 21 Aug 2013 07:39:33 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-8d-5214d1220661 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C5.73.03802.221D4125; Wed, 21 Aug 2013 16:39:31 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Wed, 21 Aug 2013 16:39:30 +0200 From: Daniele Ceccarelli To: Lou Berger Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model Thread-Index: Ac6LhtnSfQOotGSxTSGTJyWDc179HQCSrD6AAAuS2YADiytYAAA3lpwAABeT68AADd3ZgAA2xlcg Date: Wed, 21 Aug 2013 14:39:30 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4814846C@ESESSMB301.ericsson.se> References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> <51F94497.8010402@labn.net> <044501ce9c3d$48007250$d80156f0$@olddog.co.uk> <5212818C.8030409@labn.net> <4A1562797D64E44993C5CBF38CF1BE481443D9@ESESSMB301.ericsson.se> <52137CD5.7000206@labn.net> In-Reply-To: <52137CD5.7000206@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja7yRZEgg+Wd3BY/em4wWzyZc4PF Ysrs7ywWHc1vWRxYPJYs+cnk8WFTM5vHis0rGT2+XP7MFsASxWWTkpqTWZZapG+XwJVx869Z wTHrisU7OpgaGDfpdTFyckgImEi8PP6QBcIWk7hwbz1bFyMXh5DAYUaJh/17oZwljBKnt/cz dTFycLAJWEk8OeQD0iAioCjx9eMiJpAaZoGjjBIdj1cxgySEBdwkfm2fxwxR5C6xrOsoE4Qd JbH93m82EJtFQFXi9vqFYHFeAW+JFR+es0MsO84kcWHrK7CTOAU0JL79W8gOYjMKyEpM2L2I EcRmFhCXuPVkPhPE2QISS/acZ4awRSVePv7HCmErSuw8284MUa8ncWPqFDYIW1ti2cLXzBCL BSVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZVjOy5iZk56eVGmxiB0XRwy2/VHYx3zokcYpTm YFES592sdyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Oh/FMF/7PxD6amZ1xj3dnhsPm0 AZO7yZWdK/llZ6+6axbocHFLS8CMGNHzsVN1pk7cdnLp55/8VSsCmnkOS1kIdhps/MU1qSqk 1HKbs7rbkjuHt/PL3BGPf7tfP8vo9v4X5xRa2tdtTJz5MjN1S1vWL0v5XcqT34Q6Rmd26NtG mewL7pE+tUyJpTgj0VCLuag4EQDrwbg8dAIAAA== Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , "ccamp@ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 14:39:40 -0000 Lou, I've applied the text changes you proposed and added RFC1195 and RFC5307 as= normative (correct?) references. If there is no other comment i go ahead with the ID submission. Thanks Daniele > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: marted=EC 20 agosto 2013 16:28 > To: Daniele Ceccarelli > Cc: adrian@olddog.co.uk; draft-ietf-ccamp-otn-g709-info- > model@tools.ietf.org; ccamp@ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model >=20 > Daniele, > Thanks for looking at this. I think we're almost there. See below for > details that hopefully let us close on this. >=20 > On 8/20/2013 3:18 AM, Daniele Ceccarelli wrote: > > Lou, Adrian, > > > >>> It may be the case that only a small proportion of CCAMP is > >>> interested in IS-IS, and it may be the case that the intersection of > >>> those people with those interested in OTN is vanishingly small. If > >>> that is the case > > > > I think that's the case > > > >>> (I guess Lou can find out) we should excuse IS-IS in a more open and > >>> blatant way while soliciting and offering to help work on IS-IS for O= TN. > > > > I've searched the words routing and OSPF in the text. The word routing > occurs 13 times (6 meaningful, i.e. not references, abstract etc) and OSP= F 11 > times (4 meaningful). > > >=20 > I think you need to expand your search to include [RFC4203]. >=20 > s/as defined by [RFC4203],/as defined by [RFC4203], [RFC5307], >=20 > s/[RFC4203] only allows/GMPLS OSPF [RFC4203] and GMPLS IS-IS [RFC5307] > only allow >=20 > s/tools provided by [RFC4203]/tools provided by [RFC4203] and [RFC5307] >=20 > s/the OSPF-TE extensions defined in [RFC4203] require/the routing > extensions defined in [RFC4203] and [RFC5307] require >=20 > s/[RFC4202] and [RFC4203]/[RFC4202], [RFC4203] and [RFC5307] >=20 > Can now drop: >=20 > As far as it concerns routing, analogous considerations apply to > IS-IS [RFC5307] but in the following only a gap analysis with respect > to OSPF-TE is provided. >=20 > > We might focus on the meaningful ones and see where IS-IS can be > brought in. > > > > -Routing occurrence #6 > > "ODU3 H-LSP is eligible from ODU2 LSP > > perspective since from the routing it is known that this ODU3 > > interface at node Z, supports an ODU2 termination exporting a TS > > granularity 1.25Gbps/2.5Gbps." > > [DC] it should be generic enough to cover both OSPF and IS-IS > > > > -Routing occurrence #7 > > "The TS granularity information is needed in the routing protocol as > > the ingress node (A in the previous example) needs to know" > > [DC] it should be generic enough to cover both OSPF and IS-IS > > > > -Routing occurrences #8 and #9 > > "In conclusion both routing and signaling needs to be extended to > > appropriately represent the TS granularity/PT information. Routing > > needs to represent a link's TS granularity and PT capabilities as > > well as the supported multiplexing hierarchy" > > [DC] it should be generic enough to cover both OSPF and IS-IS > > > > -Routing occurrence #10 > > " From a routing perspective, [RFC4203] allows advertising [RFC4328] > > interfaces (single TS type) without the capability of providing > > precise information about bandwidth specific allocation." > > [DC] We could change this into: > > " From an OSPF perspective, [RFC4203] allows advertising [RFC4328] > > interfaces (single TS type) without the capability of providing > > precise information about bandwidth specific allocation. In the case= of > > IS-IS no extension is defined for [RFC4328]. > > >=20 > see above for an alternate proposal. >=20 > > - Routing occurrence #11 > > "With respect to the routing, please note that in case of multi stag= e > > multiplexing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/ > > OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are > needed, > > but also the intermediate one (ODU2). This is a typical case of > > spatial allocation problem." > > [DC] it should be generic enough to cover both OSPF and IS-IS >=20 > should be "With respect to routing," (drop the) > > > > - OSPF occurrence #3 > > "In conclusion, the OSPF-TE extensions defined in [RFC4203] require a > > different ISCD per signal type in order to advertise each supported > > container." > > [DC] We could change this into: > > "In conclusion, the OSPF-TE extensions defined in [RFC4203] require a > > different ISCD per signal type in order to advertise each supported > > container, while in the case of IS-IS... (suggestions welcome). > > >=20 > see above. >=20 > > - OSPF occurrence #4 > > "Per [RFC2328], OSPF messages are directly encapsulated in IP > > datagrams and depend on IP fragmentation when transmitting packets > > larger than the network MTU." > > - OSPF occurrences #5 and #6 > > "[RFC2328] recommends that "IP > > fragmentation should be avoided whenever possible." This > > recommendation further constraints solutions as OSPF does not suppor= t > > any generic mechanism to fragment OSPF LSAs." > > [DC] I only could find an expired draft regarding IS-IS encapsulation > > in IP datagrams > > >=20 > Per [RFC2328] should start a new paragraph. >=20 > You could add. "Even when used in IP environments IS-IS [RFC1195], does > not support message sizes larger than a link's maximum frame size." >=20 > I think that's it. >=20 > Lou >=20 > > BR > > Daniele > > > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: luned=EC 19 agosto 2013 22:35 > >> To: adrian@olddog.co.uk; Daniele Ceccarelli; > >> draft-ietf-ccamp-otn-g709-info- model@tools.ietf.org > >> Cc: ccamp@ietf.org > >> Subject: Re: [CCAMP] AD review of > >> draft-ietf-ccamp-otn-g709-info-model > >> > >> Adrian, > >> > >> I suspect that we've been hit by some post-IETF vacationing. > >> > >> Daniele, Authors, > >> > >> Any additional thoughts on this one remaining open issue? > >> > >> Thanks, > >> Lou > >> > >> On 8/18/2013 2:03 PM, Adrian Farrel wrote: > >>> Hi all, > >>> > >>>>> At the end of the intro we added the following sentence: > >>>>> " As far as it concerns routing, analogous considerations apply to= IS-IS > >>>>> [RFC5307] but in the following only a gap analysis with respect > >>>>> to OSPF-TE > >>> is > >>>>> provided." > >>>>> > >>>> > >>>> Given that the analysis for 5307 is pretty similar to 4203, I think > >>>> you should take a pass at including it as well. I'm happy to > >>>> review/contribute as needed. > >>>> > >>>> Thanks, > >>>> Lou (chair & doc shepherd) > >>> > >>> Was there any further progress on this? > >>> > >>> I see that the current revision addresses all other points. The note > >>> added to excuse mentioning IS-IS is a bit skinny, and I would not > >>> like to bet money on you having actually done the analysis to > >>> support adding it :-) > >>> > >>> It may be the case that only a small proportion of CCAMP is > >>> interested in IS-IS, and it may be the case that the intersection of > >>> those people with those interested in OTN is vanishingly small. If > >>> that is the case (I guess Lou can find out) we should excuse IS-IS > >>> in a more open and blatant way while soliciting and offering to help = work > on IS-IS for OTN. > >>> > >>> Cheers, > >>> Adrian > >>> > >>> > >>> > >>> > >>> > > > > > > > > From lberger@labn.net Wed Aug 21 08:41:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6449411E80E3 for ; Wed, 21 Aug 2013 08:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PClr2g8hP6uu for ; Wed, 21 Aug 2013 08:41:18 -0700 (PDT) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 2F40511E80FC for ; Wed, 21 Aug 2013 08:41:18 -0700 (PDT) Received: (qmail 26956 invoked by uid 0); 21 Aug 2013 15:40:55 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.mail.unifiedlayer.com with SMTP; 21 Aug 2013 15:40:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:Content-Transfer-Encoding:Date:MIME-Version:Message-ID:References:Cc:To:Subject:From; bh=yhBN/ANsfyRw0X2yvgZ4LQKMLIEB/ApOBV92lYOP6vU=; b=M+S+1tFQWV2JoXUY8THSVxewwuFm6ubeaGmClfIQaCBh0NCQMpvRKmBDg2Aw3gBzCV+C/WDes2eGUFht2Uwchhu0fIZ07aTHHGBJ1GaG8fs049kRAEllmN5YSmjODvPs; Received: from [69.89.31.113] (port=34023 helo=localhost) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VCAWl-0005CO-82; Wed, 21 Aug 2013 09:40:55 -0600 From: Lou Berger To: Daniele Ceccarelli References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> <51F94497.8010402@labn.net> <044501ce9c3d$48007250$d80156f0$@olddog.co.uk> <5212818C.8030409@labn.net> <4A1562797D64E44993C5CBF38CF1BE481443D9@ESESSMB301.ericsson.se> <52137CD5.7000206@labn.net> Message-ID: <2517783c.1377099588810@mail.labn.net> MIME-Version: 1.0 Date: Wed, 21 Aug 2013 11:40:51 -0400 (EDT) User-Agent: ProfiMailGo/4.12.00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , "ccamp@ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 15:41:23 -0000 Great! I think this closes the issue. As Adrian raised it we should confirm= with him too.=20 Adrian? Thanks, Lou On 10:39am, August 21, 2013, Daniele Ceccarelli wrote: > Lou, >=20 > I've applied the text changes you proposed and added RFC1195 and RFC5307 = as normative (correct?) references. >=20 > If there is no other comment i go ahead with the ID submission. >=20 > Thanks > Daniele >=20 > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: marted=C3=AC 20 agosto 2013 16:28 > > To: Daniele Ceccarelli > > Cc: adrian@olddog.co.uk; draft-ietf-ccamp-otn-g709-info- > > model@tools.ietf.org; ccamp@ietf.org > > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model > >=20 > > Daniele, > > Thanks for looking at this.=C2=A0 I think we're almost there.=C2=A0 See= below for > > details that hopefully let us close on this. > >=20 > > On 8/20/2013 3:18 AM, Daniele Ceccarelli wrote: > > > Lou, Adrian, > > >=20 > > > > > It may be the case that only a small proportion of CCAMP is > > > > > interested in IS-IS, and it may be the case that the intersection= of > > > > > those people with those interested in OTN is vanishingly small. I= f > > > > > that is the case > > >=20 > > > I think that's the case > > >=20 > > > > > (I guess Lou can find out) we should excuse IS-IS in a more open = and > > > > > blatant way while soliciting and offering to help work on IS-IS f= or OTN. > > >=20 > > > I've searched the words routing and OSPF in the text. The word routin= g > > occurs 13 times (6 meaningful, i.e. not references, abstract etc) and O= SPF 11 > > times (4 meaningful). > > >=20 > >=20 > > I think you need to expand your search to include [RFC4203]. > >=20 > > s/as defined by [RFC4203],/as defined by [RFC4203], [RFC5307], > >=20 > > s/[RFC4203] only allows/GMPLS OSPF [RFC4203] and GMPLS IS-IS [RFC5307] > > only allow > >=20 > > s/tools provided by [RFC4203]/tools provided by [RFC4203] and [RFC5307] > >=20 > > s/the OSPF-TE extensions defined in [RFC4203] require/the routing > > extensions defined in [RFC4203] and [RFC5307] require > >=20 > > s/[RFC4202] and [RFC4203]/[RFC4202], [RFC4203] and [RFC5307] > >=20 > > Can now drop: > >=20 > > As far as it concerns routing, analogous considerations apply to > > IS-IS [RFC5307] but in the following only a gap analysis with respect > > to OSPF-TE is provided. > >=20 > > > We might focus on the meaningful ones and see where IS-IS can be > > brought in. > > >=20 > > > -Routing occurrence #6 > > > "ODU3 H-LSP is eligible from ODU2 LSP > > > perspective since from the routing it is known that this ODU3 > > > interface at node Z, supports an ODU2 termination exporting a TS > > > granularity 1.25Gbps/2.5Gbps." > > > [DC] it should be generic enough to cover both OSPF and IS-IS > > >=20 > > > -Routing occurrence #7 > > > "The TS granularity information is needed in the routing protocol as > > > the ingress node (A in the previous example) needs to know" > > > [DC] it should be generic enough to cover both OSPF and IS-IS > > >=20 > > > -Routing occurrences #8 and #9 > > > "In conclusion both routing and signaling needs to be extended to > > > appropriately represent the TS granularity/PT information.=C2=A0 Rout= ing > > > needs to represent a link's TS granularity and PT capabilities as > > > well as the supported multiplexing hierarchy" > > > [DC] it should be generic enough to cover both OSPF and IS-IS > > >=20 > > > -Routing occurrence #10 > > > " From a routing perspective, [RFC4203] allows advertising [RFC4328] > > > interfaces (single TS type) without the capability of providing > > > precise information about bandwidth specific allocation." > > > [DC] We could change this into: > > > " From an OSPF perspective, [RFC4203] allows advertising [RFC4328] > > > interfaces (single TS type) without the capability of providing > > > precise information about bandwidth specific allocation. In the case = of > > > IS-IS no extension is defined for [RFC4328]. > > >=20 > >=20 > > see above for an alternate proposal. > >=20 > > > - Routing occurrence #11 > > > "With respect to the routing, please note that in case of multi stage > > > multiplexing hierarchy (e.g.=C2=A0 ODU1->ODU2->ODU3), not only the OD= Uk/ > > > OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are > > needed, > > > but also the intermediate one (ODU2).=C2=A0 This is a typical case of > > > spatial allocation problem." > > > [DC] it should be generic enough to cover both OSPF and IS-IS > >=20 > > should be "With respect to routing," (drop the) > > >=20 > > > - OSPF occurrence #3 > > > "In conclusion, the OSPF-TE extensions defined in [RFC4203] require a > > > different ISCD per signal type in order to advertise each supported > > > container." > > > [DC] We could change this into: > > > "In conclusion, the OSPF-TE extensions defined in [RFC4203] require a > > > different ISCD per signal type in order to advertise each supported > > > container, while in the case of IS-IS... (suggestions welcome). > > >=20 > >=20 > > see above. > >=20 > > > - OSPF occurrence #4 > > > "Per [RFC2328], OSPF messages are directly encapsulated in IP > > > datagrams and depend on IP fragmentation when transmitting packets > > > larger than the network MTU." > > > - OSPF occurrences #5 and #6 > > > "[RFC2328] recommends that "IP > > > fragmentation should be avoided whenever possible."=C2=A0 This > > > recommendation further constraints solutions as OSPF does not support > > > any generic mechanism to fragment OSPF LSAs." > > > [DC] I only could find an expired draft regarding IS-IS encapsulation > > > in IP datagrams > > >=20 > >=20 > > Per [RFC2328] should start a new paragraph. > >=20 > > You could add. "Even when used in IP environments IS-IS [RFC1195], does > > not support message sizes larger than a link's maximum frame size." > >=20 > > I think that's it. > >=20 > > Lou > >=20 > > > BR > > > Daniele > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: luned=C3=AC 19 agosto 2013 22:35 > > > > To: adrian@olddog.co.uk; Daniele Ceccarelli; > > > > draft-ietf-ccamp-otn-g709-info- model@tools.ietf.org > > > > Cc: ccamp@ietf.org > > > > Subject: Re: [CCAMP] AD review of > > > > draft-ietf-ccamp-otn-g709-info-model > > > >=20 > > > > Adrian, > > > >=20 > > > > I suspect that we've been hit by some post-IETF vacationing. > > > >=20 > > > > Daniele, Authors, > > > >=20 > > > > Any additional thoughts on this one remaining open issue? > > > >=20 > > > > Thanks, > > > > Lou > > > >=20 > > > > On 8/18/2013 2:03 PM, Adrian Farrel wrote: > > > > > Hi all, > > > > >=20 > > > > > > > At the end of the intro we added the following sentence: > > > > > > > "=C2=A0 As far as it concerns routing, analogous consideratio= ns apply to IS-IS > > > > > > > [RFC5307] but in the following only a gap analysis with respe= ct > > > > > > > to OSPF-TE > > > > > is > > > > > > > provided." > > > > > > >=20 > > > > > >=20 > > > > > > Given that the analysis for 5307 is pretty similar to 4203, I t= hink > > > > > > you should take a pass at including it as well.=C2=A0 I'm happy= to > > > > > > review/contribute as needed. > > > > > >=20 > > > > > > Thanks, > > > > > > Lou (chair & doc shepherd) > > > > >=20 > > > > > Was there any further progress on this? > > > > >=20 > > > > > I see that the current revision addresses all other points. The n= ote > > > > > added to excuse mentioning IS-IS is a bit skinny, and I would not > > > > > like to bet money on you having actually done the analysis to > > > > > support adding it :-) > > > > >=20 > > > > > It may be the case that only a small proportion of CCAMP is > > > > > interested in IS-IS, and it may be the case that the intersection= of > > > > > those people with those interested in OTN is vanishingly small. I= f > > > > > that is the case (I guess Lou can find out) we should excuse IS-I= S > > > > > in a more open and blatant way while soliciting and offering to h= elp work > > on IS-IS for OTN. > > > > >=20 > > > > > Cheers, > > > > > Adrian > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 >=20 From adrian@olddog.co.uk Wed Aug 21 10:30:39 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A9411E8120 for ; Wed, 21 Aug 2013 10:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU8Q9XwgYwpF for ; Wed, 21 Aug 2013 10:30:34 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB6E11E80FA for ; Wed, 21 Aug 2013 10:30:32 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7LHUTmt021340; Wed, 21 Aug 2013 18:30:29 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7LHUSYt021323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Aug 2013 18:30:28 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , "'Daniele Ceccarelli'" References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> <51F94497.8010402@labn.net> <044501ce9c3d$48007250$d80156f0$@olddog.co.uk> <5212818C.8030409@labn.net> <4A1562797D64E44993C5CBF38CF1BE481443D9@ESESSMB301.ericsson.se> <52137CD5.7000206@labn.net> <2517783c.1377099588810@mail.labn.net> In-Reply-To: <2517783c.1377099588810@mail.labn.net> Date: Wed, 21 Aug 2013 18:30:26 +0100 Message-ID: <013401ce9e94$20850520$618f0f60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXx93VA/UdhQko2wImjUTLAiqMbQK/MUvxAZHZ7gEBQfO11AHnqtqbAcOLrCMBduV/kgG5y/GfmKohKMA= Content-Language: en-gb Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:30:40 -0000 Go for it. Thanks, Adrian > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 21 August 2013 16:41 > To: Daniele Ceccarelli > Cc: adrian@olddog.co.uk; = draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > ccamp@ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model >=20 > Great! I think this closes the issue. As Adrian raised it we should = confirm with him > too. >=20 > Adrian? >=20 > Thanks, > Lou >=20 > On 10:39am, August 21, 2013, Daniele Ceccarelli wrote: > > Lou, > > > > I've applied the text changes you proposed and added RFC1195 and = RFC5307 as > normative (correct?) references. > > > > If there is no other comment i go ahead with the ID submission. > > > > Thanks > > Daniele > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: marted=C3=AC 20 agosto 2013 16:28 > > > To: Daniele Ceccarelli > > > Cc: adrian@olddog.co.uk; draft-ietf-ccamp-otn-g709-info- > > > model@tools.ietf.org; ccamp@ietf.org > > > Subject: Re: [CCAMP] AD review of = draft-ietf-ccamp-otn-g709-info-model > > > > > > Daniele, > > > Thanks for looking at this. I think we're almost there. See = below for > > > details that hopefully let us close on this. > > > > > > On 8/20/2013 3:18 AM, Daniele Ceccarelli wrote: > > > > Lou, Adrian, > > > > > > > > > > It may be the case that only a small proportion of CCAMP is > > > > > > interested in IS-IS, and it may be the case that the = intersection of > > > > > > those people with those interested in OTN is vanishingly = small. If > > > > > > that is the case > > > > > > > > I think that's the case > > > > > > > > > > (I guess Lou can find out) we should excuse IS-IS in a more = open and > > > > > > blatant way while soliciting and offering to help work on = IS-IS for OTN. > > > > > > > > I've searched the words routing and OSPF in the text. The word = routing > > > occurs 13 times (6 meaningful, i.e. not references, abstract etc) = and OSPF 11 > > > times (4 meaningful). > > > > > > > > > > I think you need to expand your search to include [RFC4203]. > > > > > > s/as defined by [RFC4203],/as defined by [RFC4203], [RFC5307], > > > > > > s/[RFC4203] only allows/GMPLS OSPF [RFC4203] and GMPLS IS-IS = [RFC5307] > > > only allow > > > > > > s/tools provided by [RFC4203]/tools provided by [RFC4203] and = [RFC5307] > > > > > > s/the OSPF-TE extensions defined in [RFC4203] require/the routing > > > extensions defined in [RFC4203] and [RFC5307] require > > > > > > s/[RFC4202] and [RFC4203]/[RFC4202], [RFC4203] and [RFC5307] > > > > > > Can now drop: > > > > > > As far as it concerns routing, analogous considerations apply to > > > IS-IS [RFC5307] but in the following only a gap analysis with = respect > > > to OSPF-TE is provided. > > > > > > > We might focus on the meaningful ones and see where IS-IS can be > > > brought in. > > > > > > > > -Routing occurrence #6 > > > > "ODU3 H-LSP is eligible from ODU2 LSP > > > > perspective since from the routing it is known that this ODU3 > > > > interface at node Z, supports an ODU2 termination exporting a TS > > > > granularity 1.25Gbps/2.5Gbps." > > > > [DC] it should be generic enough to cover both OSPF and IS-IS > > > > > > > > -Routing occurrence #7 > > > > "The TS granularity information is needed in the routing = protocol as > > > > the ingress node (A in the previous example) needs to know" > > > > [DC] it should be generic enough to cover both OSPF and IS-IS > > > > > > > > -Routing occurrences #8 and #9 > > > > "In conclusion both routing and signaling needs to be extended = to > > > > appropriately represent the TS granularity/PT information. = Routing > > > > needs to represent a link's TS granularity and PT capabilities = as > > > > well as the supported multiplexing hierarchy" > > > > [DC] it should be generic enough to cover both OSPF and IS-IS > > > > > > > > -Routing occurrence #10 > > > > " From a routing perspective, [RFC4203] allows advertising = [RFC4328] > > > > interfaces (single TS type) without the capability of providing > > > > precise information about bandwidth specific allocation." > > > > [DC] We could change this into: > > > > " From an OSPF perspective, [RFC4203] allows advertising = [RFC4328] > > > > interfaces (single TS type) without the capability of providing > > > > precise information about bandwidth specific allocation. In the = case of > > > > IS-IS no extension is defined for [RFC4328]. > > > > > > > > > > see above for an alternate proposal. > > > > > > > - Routing occurrence #11 > > > > "With respect to the routing, please note that in case of multi = stage > > > > multiplexing hierarchy (e.g. ODU1->ODU2->ODU3), not only the = ODUk/ > > > > OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are > > > needed, > > > > but also the intermediate one (ODU2). This is a typical case of > > > > spatial allocation problem." > > > > [DC] it should be generic enough to cover both OSPF and IS-IS > > > > > > should be "With respect to routing," (drop the) > > > > > > > > - OSPF occurrence #3 > > > > "In conclusion, the OSPF-TE extensions defined in [RFC4203] = require a > > > > different ISCD per signal type in order to advertise each = supported > > > > container." > > > > [DC] We could change this into: > > > > "In conclusion, the OSPF-TE extensions defined in [RFC4203] = require a > > > > different ISCD per signal type in order to advertise each = supported > > > > container, while in the case of IS-IS... (suggestions welcome). > > > > > > > > > > see above. > > > > > > > - OSPF occurrence #4 > > > > "Per [RFC2328], OSPF messages are directly encapsulated in IP > > > > datagrams and depend on IP fragmentation when transmitting = packets > > > > larger than the network MTU." > > > > - OSPF occurrences #5 and #6 > > > > "[RFC2328] recommends that "IP > > > > fragmentation should be avoided whenever possible." This > > > > recommendation further constraints solutions as OSPF does not = support > > > > any generic mechanism to fragment OSPF LSAs." > > > > [DC] I only could find an expired draft regarding IS-IS = encapsulation > > > > in IP datagrams > > > > > > > > > > Per [RFC2328] should start a new paragraph. > > > > > > You could add. "Even when used in IP environments IS-IS [RFC1195], = does > > > not support message sizes larger than a link's maximum frame = size." > > > > > > I think that's it. > > > > > > Lou > > > > > > > BR > > > > Daniele > > > > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: luned=C3=AC 19 agosto 2013 22:35 > > > > > To: adrian@olddog.co.uk; Daniele Ceccarelli; > > > > > draft-ietf-ccamp-otn-g709-info- model@tools.ietf.org > > > > > Cc: ccamp@ietf.org > > > > > Subject: Re: [CCAMP] AD review of > > > > > draft-ietf-ccamp-otn-g709-info-model > > > > > > > > > > Adrian, > > > > > > > > > > I suspect that we've been hit by some post-IETF vacationing. > > > > > > > > > > Daniele, Authors, > > > > > > > > > > Any additional thoughts on this one remaining open issue? > > > > > > > > > > Thanks, > > > > > Lou > > > > > > > > > > On 8/18/2013 2:03 PM, Adrian Farrel wrote: > > > > > > Hi all, > > > > > > > > > > > > > > At the end of the intro we added the following sentence: > > > > > > > > " As far as it concerns routing, analogous = considerations apply to IS- > IS > > > > > > > > [RFC5307] but in the following only a gap analysis with = respect > > > > > > > > to OSPF-TE > > > > > > is > > > > > > > > provided." > > > > > > > > > > > > > > > > > > > > > > Given that the analysis for 5307 is pretty similar to = 4203, I think > > > > > > > you should take a pass at including it as well. I'm happy = to > > > > > > > review/contribute as needed. > > > > > > > > > > > > > > Thanks, > > > > > > > Lou (chair & doc shepherd) > > > > > > > > > > > > Was there any further progress on this? > > > > > > > > > > > > I see that the current revision addresses all other points. = The note > > > > > > added to excuse mentioning IS-IS is a bit skinny, and I = would not > > > > > > like to bet money on you having actually done the analysis = to > > > > > > support adding it :-) > > > > > > > > > > > > It may be the case that only a small proportion of CCAMP is > > > > > > interested in IS-IS, and it may be the case that the = intersection of > > > > > > those people with those interested in OTN is vanishingly = small. If > > > > > > that is the case (I guess Lou can find out) we should excuse = IS-IS > > > > > > in a more open and blatant way while soliciting and offering = to help work > > > on IS-IS for OTN. > > > > > > > > > > > > Cheers, > > > > > > Adrian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From lberger@labn.net Wed Aug 21 15:25:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0F511E8271 for ; Wed, 21 Aug 2013 15:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyPKQbJeFysK for ; Wed, 21 Aug 2013 15:25:53 -0700 (PDT) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id B58F611E8264 for ; Wed, 21 Aug 2013 15:25:49 -0700 (PDT) Received: (qmail 11915 invoked by uid 0); 21 Aug 2013 22:25:12 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.mail.unifiedlayer.com with SMTP; 21 Aug 2013 22:25:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=CJAazORxc9HBF76dTdl10Amk3hc9vFOcD5RBxgGUpys=; b=1BwRREBdYctaFGyZHQfgxLtfrAl9DVX1ofwP6gvDqYk5r4H8xPRvow/tIr2T4ihbVFolaezgomAskTwlLF1kXAfi3BonA2FzAp3GPy2lIV8qL7qj2KgnqaYjLrzHvnYX; Received: from box313.bluehost.com ([69.89.31.113]:45619 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VCGpz-0007Cf-Ut; Wed, 21 Aug 2013 16:25:12 -0600 Message-ID: <52153E45.1030505@labn.net> Date: Wed, 21 Aug 2013 18:25:09 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk> In-Reply-To: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 22:25:58 -0000 Adrian, I'm replying as co-author.See below for responses. On 8/21/2013 6:55 AM, Adrian Farrel wrote: > Thanks for this simple document. > > I have carried out my review as AD as part of the publication request > process. The purpose of the review is to catch any issues before the > document goes to IETF last call and IESG evaluation and to improve the > quality of the document. > > I have not found any thing substantial, but I have three points I would > like you to look at before we move forward. All points are open for > discussion. > > For the moment I have put the document in "Revised I-D Needed" state. > > Thanks for the work. > > Adrian > > === > > Please add a note to the IANA considerations section to request an > update to > https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml > > Possibly you should refer to it as IANA-GMPLS-TC-MIB rather than through > the URL. The proposed text to be added to the end of the section is: A parallel change to IANA-GMPLS-TC-MIB is also required. In particular, under IANAGmplsSwitchingTypeTC a reference to this document should be added as item 3. Also the following changes should be made to the related values: deprecated(2), -- Deprecated deprecated(3), -- Deprecated deprecated(4), -- Deprecated > > --- > > I would prefer if the message formats were left out of section 1.1. > > You could leave the paragraphs: > > The Switching Type values are carried in both routing and signaling > protocols. Values are identified in the IANA GMPLS Signaling > Parameters Switching Type registry, which is currently located at > http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig- > parameters.xml > > For routing, a common information element is defined to carry > switching type values for both OSPF and IS-IS routing protocols in > [RFC4202]. Per [RFC4202], switching type values are carried in a > Switching Capability (Switching Cap) field in an Interface Switching > Capability Descriptor. This information shares a common formatting > in both OSPF, as defined by [RFC4203], and in IS-IS, as defined by > [RFC5307]. > > Similarly, the Switching Type field is defined as part of a common > format for use by GMPLS signaling protocols in [RFC3471] and is used > by [RFC3473]. > > ...and delete the rest without damaging the document. > > My concern, as usual, is that copying normative material leads to the > risk of error, and creates problems if material has to be revised. It > is perfectly fine to reference it in nearly every case. > > --- While I agree with the sentiment 100% in normative text, this section is informative and labeled as such. I just don't see there being any risk of poor implementation as a result of this section. I do think it would diminish the value of the section if the text was removed. That said, if you felt strongly about this I'd revisit the point. > > Section 2.3... > > These values SHOULD NOT be treated as reserved values, i.e., > SHOULD NOT be generated and SHOULD be ignored upon receipt. > > But in 3473... > > Nodes MUST verify that the type indicated in the Switching Type > parameter is supported on the corresponding incoming interface. If > the type cannot be supported, the node MUST generate a PathErr > message with a "Routing problem/Switching Type" indication. > > Is it your intention to update that piece of 3473? > If so, you should call it out more clearly. > If not, there is some work needed to reconcile the text. > Yeah. This is a case where a pointer back to the original, as you mentioned above, is the right thing. How about: These values SHOULD be treated as unsupported types and processed according to Section 2.1.1 of [RFC3473]. Great catch. Thanks for the review! Lou From internet-drafts@ietf.org Wed Aug 21 23:52:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424BF21F9D89; Wed, 21 Aug 2013 23:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiGuWcXZLp6I; Wed, 21 Aug 2013 23:52:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C95AC21F8F6D; Wed, 21 Aug 2013 23:52:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130822065202.17172.66254.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 23:52:02 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 06:52:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Evaluation of existing GMPLS encoding against G.709v3 Op= tical Transport Networks (OTN) Author(s) : Sergio Belotti Pietro Vittorio Grandi Daniele Ceccarelli Diego Caviglia Fatai Zhang Dan Li Filename : draft-ietf-ccamp-otn-g709-info-model-11.txt Pages : 22 Date : 2013-08-21 Abstract: ITU-T recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 [G.709-2012] OTN networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-otn-g709-info-model-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Thu Aug 22 05:04:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B8A11E8161 for ; Thu, 22 Aug 2013 05:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAhA7y5PTVC1 for ; Thu, 22 Aug 2013 05:04:13 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4917F21F9F40 for ; Thu, 22 Aug 2013 05:04:13 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7MC44C5025649; Thu, 22 Aug 2013 13:04:11 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7MC43s8025636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Aug 2013 13:04:04 +0100 From: "Adrian Farrel" To: "'Lou Berger'" References: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk> <52153E45.1030505@labn.net> In-Reply-To: <52153E45.1030505@labn.net> Date: Thu, 22 Aug 2013 13:04:00 +0100 Message-ID: <02a801ce9f2f$b0af7090$120e51b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1T0XVKoT/47lpBeUkJvBRZWb0sgH2nusjmsQKjVA= Content-Language: en-gb Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:04:19 -0000 OK, two out of three ain't bad (as Jim Steinman wrote) Can you post a new revision and we'll move forward. Thanks, Adrian > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 21 August 2013 23:25 > To: adrian@olddog.co.uk > Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org; ccamp@ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update > > Adrian, > I'm replying as co-author.See below for responses. > > On 8/21/2013 6:55 AM, Adrian Farrel wrote: > > Thanks for this simple document. > > > > I have carried out my review as AD as part of the publication request > > process. The purpose of the review is to catch any issues before the > > document goes to IETF last call and IESG evaluation and to improve the > > quality of the document. > > > > I have not found any thing substantial, but I have three points I would > > like you to look at before we move forward. All points are open for > > discussion. > > > > For the moment I have put the document in "Revised I-D Needed" state. > > > > Thanks for the work. > > > > Adrian > > > > === > > > > Please add a note to the IANA considerations section to request an > > update to > > https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml > > > > Possibly you should refer to it as IANA-GMPLS-TC-MIB rather than through > > the URL. > The proposed text to be added to the end of the section is: > > A parallel change to IANA-GMPLS-TC-MIB is also required. In > particular, under IANAGmplsSwitchingTypeTC a reference to this > document should be added as item 3. Also the following changes should > be made to the related values: > > deprecated(2), -- Deprecated > deprecated(3), -- Deprecated > deprecated(4), -- Deprecated > > > > > > --- > > > > I would prefer if the message formats were left out of section 1.1. > > > > You could leave the paragraphs: > > > > The Switching Type values are carried in both routing and signaling > > protocols. Values are identified in the IANA GMPLS Signaling > > Parameters Switching Type registry, which is currently located at > > http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig- > > parameters.xml > > > > For routing, a common information element is defined to carry > > switching type values for both OSPF and IS-IS routing protocols in > > [RFC4202]. Per [RFC4202], switching type values are carried in a > > Switching Capability (Switching Cap) field in an Interface Switching > > Capability Descriptor. This information shares a common formatting > > in both OSPF, as defined by [RFC4203], and in IS-IS, as defined by > > [RFC5307]. > > > > Similarly, the Switching Type field is defined as part of a common > > format for use by GMPLS signaling protocols in [RFC3471] and is used > > by [RFC3473]. > > > > ...and delete the rest without damaging the document. > > > > My concern, as usual, is that copying normative material leads to the > > risk of error, and creates problems if material has to be revised. It > > is perfectly fine to reference it in nearly every case. > > > > --- > > While I agree with the sentiment 100% in normative text, this section is > informative and labeled as such. I just don't see there being any risk > of poor implementation as a result of this section. I do think it would > diminish the value of the section if the text was removed. That said, > if you felt strongly about this I'd revisit the point. > > > > Section 2.3... > > > > These values SHOULD NOT be treated as reserved values, i.e., > > SHOULD NOT be generated and SHOULD be ignored upon receipt. > > > > But in 3473... > > > > Nodes MUST verify that the type indicated in the Switching Type > > parameter is supported on the corresponding incoming interface. If > > the type cannot be supported, the node MUST generate a PathErr > > message with a "Routing problem/Switching Type" indication. > > > > Is it your intention to update that piece of 3473? > > If so, you should call it out more clearly. > > If not, there is some work needed to reconcile the text. > > > > Yeah. This is a case where a pointer back to the original, as you > mentioned above, is the right thing. How about: > > These values SHOULD be treated as unsupported types and > processed according to Section 2.1.1 of [RFC3473]. > > Great catch. > > Thanks for the review! > > Lou From internet-drafts@ietf.org Thu Aug 22 06:52:49 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBDF21F9BCA; Thu, 22 Aug 2013 06:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEjQfc4QcYA4; Thu, 22 Aug 2013 06:52:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 702E921F9B4B; Thu, 22 Aug 2013 06:52:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130822135249.28017.4388.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2013 06:52:49 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-swcaps-update-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 13:52:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Revised Definition of The GMPLS Switching Capability and= Type Fields Author(s) : Lou Berger Julien Meuric Filename : draft-ietf-ccamp-swcaps-update-02.txt Pages : 9 Date : 2013-08-22 Abstract: GMPLS provides control for multiple switching technologies, and hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate switching technology type. These values are carried in routing in the Switching Capability field, and in signaling in the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates any document that uses the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-swcaps-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-swcaps-update-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-swcaps-update-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lberger@labn.net Thu Aug 22 06:58:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D5711E81BA for ; Thu, 22 Aug 2013 06:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWSGlsGj+SJA for ; Thu, 22 Aug 2013 06:58:17 -0700 (PDT) Received: from oproxy14-pub.mail.unifiedlayer.com (oproxy14-pub.mail.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 20DD011E80E2 for ; Thu, 22 Aug 2013 06:58:04 -0700 (PDT) Received: (qmail 10251 invoked by uid 0); 22 Aug 2013 13:58:01 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 22 Aug 2013 13:58:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=U516jq9YXcnva09abWF44Ni2pNJ6QMGs/AE/Xzdq6gI=; b=FNVNQ1vgXdPy2whYnnx/JGUEtWykulGoH9beSUXkV4tyN3puc3qU/p3QLl3shn58Hs53mE6O1nx036OsK2VjRsMr58nSpSf2rryy087kFHZRVvtsRZjEE/BYztVQ8pFy; Received: from box313.bluehost.com ([69.89.31.113]:54485 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VCVOj-0000ma-3b for ccamp@ietf.org; Thu, 22 Aug 2013 07:58:01 -0600 Message-ID: <521618DE.4020706@labn.net> Date: Thu, 22 Aug 2013 09:57:50 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ccamp@ietf.org References: <20130822135249.28017.4388.idtracker@ietfa.amsl.com> In-Reply-To: <20130822135249.28017.4388.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-swcaps-update-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 13:58:21 -0000 All, This version covers the changes discussed on-list with Adrian: - Corrected text in section 2.3 to be aligned and point to 3473 - Added IANA considerations for GMPLS TC MIB. Comments are welcome... Lou On 08/22/2013 09:52 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Revised Definition of The GMPLS Switching Capability and Type Fields > Author(s) : Lou Berger > Julien Meuric > Filename : draft-ietf-ccamp-swcaps-update-02.txt > Pages : 9 > Date : 2013-08-22 > > Abstract: > GMPLS provides control for multiple switching technologies, and > hierarchical switching within a technology. GMPLS routing and > signaling use common values to indicate switching technology type. > These values are carried in routing in the Switching Capability > field, and in signaling in the Switching Type field. While the > values used in these fields are the primary indicators of the > technology and hierarchy level being controlled, the values are > not consistently defined and used across the different > technologies supported by GMPLS. This document is intended to > resolve the inconsistent definition and use of the Switching > Capability and Type fields by narrowly scoping the meaning and use > of the fields. This document updates any document that uses the > GMPLS Switching Capability and Types fields, in particular RFC > 3471, RFC 4202, RFC 4203, and RFC 5307. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-swcaps-update > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-swcaps-update-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-swcaps-update-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From ietfc@btconnect.com Thu Aug 22 10:23:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CC921F9C69 for ; Thu, 22 Aug 2013 10:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+kPhJfRmD+c for ; Thu, 22 Aug 2013 10:23:21 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5029811E8106 for ; Thu, 22 Aug 2013 10:23:20 -0700 (PDT) Received: from mail168-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Aug 2013 17:23:20 +0000 Received: from mail168-co1 (localhost [127.0.0.1]) by mail168-co1-R.bigfish.com (Postfix) with ESMTP id 08270AC03A2; Thu, 22 Aug 2013 17:23:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zzbb2dI98dI9371I542I1432I1447Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de096h8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail168-co1 (localhost.localdomain [127.0.0.1]) by mail168-co1 (MessageSwitch) id 1377192167918929_23013; Thu, 22 Aug 2013 17:22:47 +0000 (UTC) Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.244]) by mail168-co1.bigfish.com (Postfix) with ESMTP id DD0B490021C; Thu, 22 Aug 2013 17:22:47 +0000 (UTC) Received: from AM2PRD0710HT001.eurprd07.prod.outlook.com (157.56.249.213) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 22 Aug 2013 17:22:47 +0000 Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.165.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Thu, 22 Aug 2013 17:22:34 +0000 Message-ID: <025701ce9f5c$185bcc80$4001a8c0@gateway.2wire.net> From: t.petch To: Lou Berger , References: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk> <52153E45.1030505@labn.net> Date: Thu, 22 Aug 2013 18:21:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 17:23:26 -0000 ----- Original Message ----- From: "Lou Berger" To: Cc: ; Sent: Wednesday, August 21, 2013 11:25 PM > Adrian, > I'm replying as co-author.See below for responses. > > On 8/21/2013 6:55 AM, Adrian Farrel wrote: > > Thanks for this simple document. > > > > I have carried out my review as AD as part of the publication request > > process. The purpose of the review is to catch any issues before the > > document goes to IETF last call and IESG evaluation and to improve the > > quality of the document. > > > > I have not found any thing substantial, but I have three points I would > > like you to look at before we move forward. All points are open for > > discussion. > > > > For the moment I have put the document in "Revised I-D Needed" state. > > > > Thanks for the work. > > > > Adrian > > > > === > > > > Please add a note to the IANA considerations section to request an > > update to > > https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml > > > > Possibly you should refer to it as IANA-GMPLS-TC-MIB rather than through > > the URL. > The proposed text to be added to the end of the section is: > > A parallel change to IANA-GMPLS-TC-MIB is also required. In > particular, under IANAGmplsSwitchingTypeTC a reference to this > document should be added as item 3. Also the following changes should > be made to the related values: > > deprecated(2), -- Deprecated > deprecated(3), -- Deprecated > deprecated(4), -- Deprecated Mmmmm RFC4181 says "Therefore, labels of named numbers and named bits MUST NOT be changed when revising IETF MIB modules (except to correct typographical errors), and they SHOULD NOT be changed when revising enterprise MIB modules. " so I do not think that you can do that. Change of STATUS (which applies to the whole TC) yes, label no. (Don't you love SNMP?) Tom Petch > > --- > > > > I would prefer if t he message formats were left out of section 1.1. > > > > You could leave the paragraphs: > > > > The Switching Type values are carried in both routing and signaling > > protocols. Values are identified in the IANA GMPLS Signaling > > Parameters Switching Type registry, which is currently located at > > http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig- > > parameters.xml > > > > For routing, a common information element is defined to carry > > switching type values for both OSPF and IS-IS routing protocols in > > [RFC4202]. Per [RFC4202], switching type values are carried in a > > Switching Capability (Switching Cap) field in an Interface Switching > > Capability Descriptor. This information shares a common formatting > > in both OSPF, as defined by [RFC4203], and in IS-IS, as defined by > > [RFC5307]. > > > > Similarly, the Switching Type field is defined as part of a common > > format for use by GMPLS signaling protocols in [RFC3471] and is used > > by [RFC3473]. > > > > ...and delete the rest without damaging the document. > > > > My concern, as usual, is that copying normative material leads to the > > risk of error, and creates problems if material has to be revised. It > > is perfectly fine to reference it in nearly every case. > > > > --- > > While I agree with the sentiment 100% in normative text, this section is > informative and labeled as such. I just don't see there being any risk > of poor implementation as a result of this section. I do think it would > diminish the value of the section if the text was removed. That said, > if you felt strongly about this I'd revisit the point. > > > > Section 2.3... > > > > These values SHOULD NOT be treated as reserved values, i.e., > > SHOULD NOT be generated and SHOULD be ignored upon receipt. > > > > But in 3473... > > > > Nodes MUST verify that the type indicated in the Switching Type > > parameter is supported on the corresponding incoming interface. If > > the type cannot be supported, the node MUST generate a PathErr > > message with a "Routing problem/Switching Type" indication. > > > > Is it your intention to update that piece of 3473? > > If so, you should call it out more clearly. > > If not, there is some work needed to reconcile the text. > > > > Yeah. This is a case where a pointer back to the original, as you > mentioned above, is the right thing. How about: > > These values SHOULD be treated as unsupported types and > processed according to Section 2.1.1 of [RFC3473]. > > Great catch. > > Thanks for the review! > > Lou From lberger@labn.net Fri Aug 23 06:38:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1038C11E81B3 for ; Fri, 23 Aug 2013 06:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95TVelrHzeo2 for ; Fri, 23 Aug 2013 06:38:46 -0700 (PDT) Received: from oproxy9-pub.mail.unifiedlayer.com (oproxy9-pub.mail.unifiedlayer.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 0161811E811D for ; Fri, 23 Aug 2013 06:38:44 -0700 (PDT) Received: (qmail 23320 invoked by uid 0); 23 Aug 2013 13:38:22 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.mail.unifiedlayer.com with SMTP; 23 Aug 2013 13:38:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=crMkEanb+toC/Nm9wRPErwPfl7rKF0/CR/BJZxUXclg=; b=NveLsxwwp5wg3g/qP4rjLxD01yJWJtkr3qHjPX5dimUceUcYgo2ygmk+V8xthXxrf0m6hSQDQ9290uU4OQS6c6AJee62ULcXqpbnLGxVS69uKWgyO0cuHXF5O/isiE6H; Received: from box313.bluehost.com ([69.89.31.113]:59599 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VCrZG-0002dI-8e; Fri, 23 Aug 2013 07:38:22 -0600 Message-ID: <521765CC.4030306@labn.net> Date: Fri, 23 Aug 2013 09:38:20 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "t.petch" , adrian@olddog.co.uk References: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk> <52153E45.1030505@labn.net> <025701ce9f5c$185bcc80$4001a8c0@gateway.2wire.net> In-Reply-To: <025701ce9f5c$185bcc80$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 13:38:51 -0000 Tom, See below. ... >> On 8/21/2013 6:55 AM, Adrian Farrel wrote: ... >>> >>> Please add a note to the IANA considerations section to request an >>> update to >>> > https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml >>> >>> Possibly you should refer to it as IANA-GMPLS-TC-MIB rather than > through >>> the URL. >> The proposed text to be added to the end of the section is: >> >> A parallel change to IANA-GMPLS-TC-MIB is also required. In >> particular, under IANAGmplsSwitchingTypeTC a reference to this >> document should be added as item 3. Also the following changes > should >> be made to the related values: >> >> deprecated(2), -- Deprecated >> deprecated(3), -- Deprecated >> deprecated(4), -- Deprecated > > Mmmmm RFC4181 says > > "Therefore, labels of named numbers and named > bits MUST NOT be changed when revising IETF MIB modules (except to > correct typographical errors), and they SHOULD NOT be changed when > revising enterprise MIB modules. > " > > so I do not think that you can do that. Change of STATUS (which applies > to the whole TC) yes, label no. (Don't you love SNMP?) > > Tom Petch > Looks like you're right. Perhaps the following is the "right" middle ground: Existing: psc2(2), -- Packet-Switch-Capable 2 psc3(3), -- Packet-Switch-Capable 3 psc4(4), -- Packet-Switch-Capable 4 Revised: psc2(2), -- Deprecated [This.document] psc3(3), -- Deprecated [This.document] psc4(4), -- Deprecated [This.document] Adrian, Do you agree with the above? This is a bit different than your request. Much thanks, Lou From adrian@olddog.co.uk Fri Aug 23 07:16:46 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB5611E82F7 for ; Fri, 23 Aug 2013 07:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 519OVv+rcEGq for ; Fri, 23 Aug 2013 07:16:38 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 87FA411E81C0 for ; Fri, 23 Aug 2013 07:16:35 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7NEGQ99013791; Fri, 23 Aug 2013 15:16:28 +0100 Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [10.12.10.176]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7NEGQa1013786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 15:16:26 +0100 Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7NEGPxc003661; Fri, 23 Aug 2013 15:16:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7NEGNEg003655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Aug 2013 15:16:24 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , "'t.petch'" References: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk> <52153E45.1030505@labn.net> <025701ce9f5c$185bcc80$4001a8c0@gateway.2wire.net> <521765CC.4030306@labn.net> In-Reply-To: <521765CC.4030306@labn.net> Date: Fri, 23 Aug 2013 15:16:19 +0100 Message-ID: <045f01cea00b$573700f0$05a502d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1T0XVKoT/47lpBeUkJvBRZWb0sgH2nusjAc6mx8kBbZryTJqr4P7w Content-Language: en-gb Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 14:16:46 -0000 Really good catch, Tom. What Lou suggests looks the best way to handle it. A > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 23 August 2013 14:38 > To: t.petch; adrian@olddog.co.uk > Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org; ccamp@ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update > > Tom, > See below. > > ... > > >> On 8/21/2013 6:55 AM, Adrian Farrel wrote: > ... > > >>> > >>> Please add a note to the IANA considerations section to request an > >>> update to > >>> > > https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml > >>> > >>> Possibly you should refer to it as IANA-GMPLS-TC-MIB rather than > > through > >>> the URL. > >> The proposed text to be added to the end of the section is: > >> > >> A parallel change to IANA-GMPLS-TC-MIB is also required. In > >> particular, under IANAGmplsSwitchingTypeTC a reference to this > >> document should be added as item 3. Also the following changes > > should > >> be made to the related values: > >> > >> deprecated(2), -- Deprecated > >> deprecated(3), -- Deprecated > >> deprecated(4), -- Deprecated > > > > Mmmmm RFC4181 says > > > > "Therefore, labels of named numbers and named > > bits MUST NOT be changed when revising IETF MIB modules (except to > > correct typographical errors), and they SHOULD NOT be changed when > > revising enterprise MIB modules. > > " > > > > so I do not think that you can do that. Change of STATUS (which applies > > to the whole TC) yes, label no. (Don't you love SNMP?) > > > > Tom Petch > > > > Looks like you're right. > > Perhaps the following is the "right" middle ground: > Existing: > psc2(2), -- Packet-Switch-Capable 2 > psc3(3), -- Packet-Switch-Capable 3 > psc4(4), -- Packet-Switch-Capable 4 > Revised: > psc2(2), -- Deprecated [This.document] > psc3(3), -- Deprecated [This.document] > psc4(4), -- Deprecated [This.document] > > Adrian, > > Do you agree with the above? This is a bit different than your request. > > Much thanks, > Lou From lberger@labn.net Fri Aug 23 08:14:50 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52F411E81D1 for ; Fri, 23 Aug 2013 08:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYUuR0jxOZhX for ; Fri, 23 Aug 2013 08:14:46 -0700 (PDT) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 343D911E8105 for ; Fri, 23 Aug 2013 08:14:45 -0700 (PDT) Received: (qmail 28849 invoked by uid 0); 23 Aug 2013 15:14:17 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.mail.unifiedlayer.com with SMTP; 23 Aug 2013 15:14:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=SjAui+swxcSfy34AoS+CAILMMj3snXHUwreW/Fyf904=; b=FOO/MSOTvbaT4gxQIFPguHOekO1AfW4LxS53B7+muwpDORr6CP3OjSZX2hJXc9fqByccj9cXQ6awUt0o+rWtjb6DFQt5YpmeqigtHTA2UdPlBjpTASNAMZXTrAO6MYIs; Received: from box313.bluehost.com ([69.89.31.113]:52614 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VCt45-0005iH-J5 for ccamp@ietf.org; Fri, 23 Aug 2013 09:14:17 -0600 Message-ID: <52177C48.8010009@labn.net> Date: Fri, 23 Aug 2013 11:14:16 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Updated minutes for Berlin posted X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 15:14:50 -0000 Updated minutes have been posted to http://www.ietf.org/proceedings/87/minutes/minutes-87-ccamp Much thanks to our minute takers Dan and Daniele! Lou (and Deborah) From lberger@labn.net Fri Aug 23 08:22:11 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DF511E8105 for ; Fri, 23 Aug 2013 08:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsesCF+-uw9N for ; Fri, 23 Aug 2013 08:22:06 -0700 (PDT) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id E8AD711E80D2 for ; Fri, 23 Aug 2013 08:22:05 -0700 (PDT) Received: (qmail 31308 invoked by uid 0); 23 Aug 2013 15:21:42 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.mail.unifiedlayer.com with SMTP; 23 Aug 2013 15:21:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=eRGjtaosVy6AUTd8UTeoDsbyrQRrsreMNl5ZOA44G+4=; b=mgsHxO2V/0XX5pXxw+4nVSjhoBnpCtl6s3GpM1/cMCwR7fsD2SKXPR7Qw8dBSwzX3sRcnUmsTUvFkYEfkw1HNfkw+AKeHCCCCKfG0t1aL9U8Srv5v7mdsFuQBj7YjCvK; Received: from box313.bluehost.com ([69.89.31.113]:54219 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VCtBG-0000AN-FB; Fri, 23 Aug 2013 09:21:42 -0600 Message-ID: <52177E05.3040509@labn.net> Date: Fri, 23 Aug 2013 11:21:41 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk> <52153E45.1030505@labn.net> <025701ce9f5c$185bcc80$4001a8c0@gateway.2wire.net> <521765CC.4030306@labn.net> <045f01cea00b$573700f0$05a502d0$@olddog.co.uk> In-Reply-To: <045f01cea00b$573700f0$05a502d0$@olddog.co.uk> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 15:22:11 -0000 On 08/23/2013 10:16 AM, Adrian Farrel wrote: > Really good catch, Tom. > > What Lou suggests looks the best way to handle it. > Great. Look for the publication announcement in a few minutes. Lou > A > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: 23 August 2013 14:38 >> To: t.petch; adrian@olddog.co.uk >> Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org; ccamp@ietf.org >> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update >> >> Tom, >> See below. >> >> ... >> >>>> On 8/21/2013 6:55 AM, Adrian Farrel wrote: >> ... >> >>>>> >>>>> Please add a note to the IANA considerations section to request an >>>>> update to >>>>> >>> https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml >>>>> >>>>> Possibly you should refer to it as IANA-GMPLS-TC-MIB rather than >>> through >>>>> the URL. >>>> The proposed text to be added to the end of the section is: >>>> >>>> A parallel change to IANA-GMPLS-TC-MIB is also required. In >>>> particular, under IANAGmplsSwitchingTypeTC a reference to this >>>> document should be added as item 3. Also the following changes >>> should >>>> be made to the related values: >>>> >>>> deprecated(2), -- Deprecated >>>> deprecated(3), -- Deprecated >>>> deprecated(4), -- Deprecated >>> >>> Mmmmm RFC4181 says >>> >>> "Therefore, labels of named numbers and named >>> bits MUST NOT be changed when revising IETF MIB modules (except to >>> correct typographical errors), and they SHOULD NOT be changed when >>> revising enterprise MIB modules. >>> " >>> >>> so I do not think that you can do that. Change of STATUS (which applies >>> to the whole TC) yes, label no. (Don't you love SNMP?) >>> >>> Tom Petch >>> >> >> Looks like you're right. >> >> Perhaps the following is the "right" middle ground: >> Existing: >> psc2(2), -- Packet-Switch-Capable 2 >> psc3(3), -- Packet-Switch-Capable 3 >> psc4(4), -- Packet-Switch-Capable 4 >> Revised: >> psc2(2), -- Deprecated [This.document] >> psc3(3), -- Deprecated [This.document] >> psc4(4), -- Deprecated [This.document] >> >> Adrian, >> >> Do you agree with the above? This is a bit different than your request. >> >> Much thanks, >> Lou > > From internet-drafts@ietf.org Fri Aug 23 08:29:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3424111E81C3; Fri, 23 Aug 2013 08:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM4WeA5PxtIu; Fri, 23 Aug 2013 08:29:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B2911E80D2; Fri, 23 Aug 2013 08:29:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130823152920.27162.79800.idtracker@ietfa.amsl.com> Date: Fri, 23 Aug 2013 08:29:20 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-swcaps-update-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 15:29:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Revised Definition of The GMPLS Switching Capability and= Type Fields Author(s) : Lou Berger Julien Meuric Filename : draft-ietf-ccamp-swcaps-update-03.txt Pages : 9 Date : 2013-08-23 Abstract: GMPLS provides control for multiple switching technologies, and hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate switching technology type. These values are carried in routing in the Switching Capability field, and in signaling in the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates any document that uses the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-swcaps-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-swcaps-update-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-swcaps-update-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietfc@btconnect.com Fri Aug 23 09:39:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D882811E819C for ; Fri, 23 Aug 2013 09:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K89CGJSp8z5G for ; Fri, 23 Aug 2013 09:39:01 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB0511E81BB for ; Fri, 23 Aug 2013 09:38:55 -0700 (PDT) Received: from mail1-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.22; Fri, 23 Aug 2013 16:38:54 +0000 Received: from mail1-co1 (localhost [127.0.0.1]) by mail1-co1-R.bigfish.com (Postfix) with ESMTP id 480DD8E019B; Fri, 23 Aug 2013 16:38:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah186068h8275bh8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail1-co1 (localhost.localdomain [127.0.0.1]) by mail1-co1 (MessageSwitch) id 1377275932922066_12751; Fri, 23 Aug 2013 16:38:52 +0000 (UTC) Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.245]) by mail1-co1.bigfish.com (Postfix) with ESMTP id DCFAB7E0188; Fri, 23 Aug 2013 16:38:52 +0000 (UTC) Received: from DBXPRD0710HT003.eurprd07.prod.outlook.com (157.56.253.197) by CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 23 Aug 2013 16:38:52 +0000 Received: from AMXPRD0111HT001.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.79.166) with Microsoft SMTP Server (TLS) id 14.16.347.3; Fri, 23 Aug 2013 16:38:49 +0000 Message-ID: <00c201cea01f$25d269a0$4001a8c0@gateway.2wire.net> From: t.petch To: Lou Berger , References: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk> <52153E45.1030505@labn.net> <025701ce9f5c$185bcc80$4001a8c0@gateway.2wire.net> <521765CC.4030306@labn.net> <045f01cea00b$573700f0$05a502d0$@olddog.co.uk> <52177E05.3040509@labn.net> Date: Fri, 23 Aug 2013 17:37:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 16:39:07 -0000 ----- Original Message ----- From: "Lou Berger" To: Cc: "'t.petch'" ; ; Sent: Friday, August 23, 2013 4:21 PM > On 08/23/2013 10:16 AM, Adrian Farrel wrote: > > Really good catch, Tom. > > > > What Lou suggests looks the best way to handle it. > > > > Great. Look for the publication announcement in a few minutes. Yes. I would prefer that the Switching Types portion of the GMPLS Signaling Parameters was handled in a comparable manner, as for example http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#ic mp-parameters-types does so that PSC-2 PSC-3 PSC-4 still appeared in the registry but with 'deprecated' alongside each of them. Given the updated reference to whatever RFC this I-D becomes, then it will be relatively easy to follow that link and see what these deprecated entries once were so it is a minor consideration. Tom Petch > Lou > > > A > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: 23 August 2013 14:38 > >> To: t.petch; adrian@olddog.co.uk > >> Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org; ccamp@ietf.org > >> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update > >> > >> Tom, > >> See below. > >> > >> ... > >> > >>>> On 8/21/2013 6:55 AM, Adrian Farrel wrote: > >> ... > >> > >>>>> > >>>>> Please add a note to the IANA considerations section to request an > >>>>> update to > >>>>> > >>> https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml > >>>>> > >>>>> Possibly you should refer to it as IANA-GMPLS-TC-MIB rather than > >>> through > >>>>> the URL. > >>>> The proposed text to be added to the end of the section is: > >>>> > >>>> A parallel change to IANA-GMPLS-TC-MIB is also required. In > >>>> particular, under IANAGmplsSwitchingTypeTC a reference to this > >>>> document should be added as item 3. Also the following changes > >>> should > >>>> be made to the related values: > >>>> > >>>> deprecated(2), -- Deprecated > >>>> deprecated(3), -- Deprecated > >>>> deprecated(4), -- Deprecated > >>> > >>> Mmmmm RFC4181 says > >>> > >>> "Therefore, labels of named numbers and named > >>> bits MUST NOT be changed when revising IETF MIB modules (except to > >>> correct typographical errors), and they SHOULD NOT be changed when > >>> revising enterprise MIB modules. > >>> " > >>> > >>> so I do not think that you can do that. Change of STATUS (which applies > >>> to the whole TC) yes, label no. (Don't you love SNMP?) > >>> > >>> Tom Petch > >>> > >> > >> Looks like you're right. > >> > >> Perhaps the following is the "right" middle ground: > >> Existing: > >> psc2(2), -- Packet-Switch-Capable 2 > >> psc3(3), -- Packet-Switch-Capable 3 > >> psc4(4), -- Packet-Switch-Capable 4 > >> Revised: > >> psc2(2), -- Deprecated [This.document] > >> psc3(3), -- Deprecated [This.document] > >> psc4(4), -- Deprecated [This.document] > >> > >> Adrian, > >> > >> Do you agree with the above? This is a bit different than your request. > >> > >> Much thanks, > >> Lou > > > > > > From adrian@olddog.co.uk Fri Aug 23 11:25:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD69221F9B03 for ; Fri, 23 Aug 2013 11:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8ls-wDUm6CD for ; Fri, 23 Aug 2013 11:24:56 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9668B11E80C5 for ; Fri, 23 Aug 2013 11:24:54 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7NIOrvN010404; Fri, 23 Aug 2013 19:24:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7NIOpDd010394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Aug 2013 19:24:52 +0100 From: "Adrian Farrel" To: Date: Fri, 23 Aug 2013 19:24:47 +0100 Message-ID: <04eb01cea02e$0d005b30$27011190$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6gLgpkZoIREJ3nTwOKEbtl2Arm1A== Content-Language: en-gb Cc: ccamp@ietf.org Subject: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ospf-g709v3 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 18:25:02 -0000 Hi authors and working group, I have done my usual AD review on receiving a publication request for this document to smooth out any issues before IETF last call and IESG evaluation. As you'll see below, I have a few small issues that I would like to work through. The result will either be some email discussion where you convince me that no change is needed, or a revised version of the document. Thanks for the work, Adrian === I have a thread with the authors about why they need to list nine authors on the front page. The RFC Editor has a norm of no more than five unless there is a specific reason. --- This document does not update 4203. Extending mechanisms is not an update, and this document doesn't really even extend the mechanisms; it simply defines a new ISCD and describes how it is used. --- Section 2 has a reference to [swcaps-update]. I suspect this is meant to be draft-ietf-ccamp-swcaps-update. You need to add this to the informative references section. --- Section 2 is wrongly named! The section does describe the requirements, but there is actually nothing in the section that is specific to OSPF and certainly no description of OSPF extensions. I found the material useful, but wondered why it was in this document and not in the information model document since it perfectly describes the information model that needs to be applied. I am not requiring you to do anything about this, but I would ask you think hard about whether this text should be moved to the other document and simply pointed to from here. --- Section 3 is a fine and concise section. But it seems to me that this material also belongs in the information model document, not here. Again, I am not requiring you to make a change here, but please think about whether the section could be moved and replaced with a pointer. --- Section 4 OLD - Encoding Type = G.709 ODUk (Digital Path) [as defined in RFC4328] NEW - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328] END --- The description of the table in section 4 caused me some grief. You have... The bandwidth unit is in bytes per second and the encoding MUST be in Institute of Electrical and Electronic Engineers (IEEE) floating point format. The discrete values for various ODUs is shown in the table below. Could you please do two things: 1. Remind the reader that there are 1000 bits in a kbit according to normal practices in telecommunications. (Probably add a note to the quoted text.) 2. Clarify that the third column shows a floating point value. (Update the column heading.) However, I do also note that the use of bandwidth in section 4.1.3 are described as (for example)... This field MUST be set to the bandwidth, in bits/s in IEEE floating point format, available at the indicated Signal Type for a particular priority level. So you also need to sort that out. --- Section 4. In the table, could you fix up the notation of ODU3 to use 0x not 0X --- I wonder whether the text and figure for the example in Figure 10 needs its own section. --- I think there are some issues (or possibly some unspoken points) with section 6. 1. Suppose you have an old implementation. How will it treat these new advertisements? For this you are just stating facts. There is nothing you can define because you cannot influence how old implementations work. But you can say how they will behave according to existing specs. 2. If a new implementation only supports this spec and not RFC 4328 how will it handle an RFC 4328 advertisement? This is something you can and must describe. 3. For a new implementation that supports this spec and RFC 4328, I don't understand what you have written. When nodes support both advertisement methods, implementations MUST support the configuration of which advertisement method is followed. I *think* this says that - a node MUST NOT use more than one advertisement method to advertise the resources on a single OTN link It also appears to say that - a node MUST NOT use more than one advertisement method to advertise across *all* of its advertisements You go on to say... This enables nodes following each method to identify similar supporting nodes and compute paths using only the appropriate nodes. ...which seems to imply that it is not possible to compute a path end-to-end across nodes using a mix of the old and new advertisement types. Is that *really* what you want to say? --- It might be helpful to break section 8 into subsections. --- Section 8 For the new Switching Type you need to remind IANA to make the update in the IANA-GMPLS-TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib --- Section 8 Upon approval of this document, IANA will create and maintain a new registry, the "Types for sub-TLVs of OTN-TDM SCSI (Switch Capability Specific Information)" registry under the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry, see http://www.iana.org/ assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xml, with the TLV types as follows: This document defines new TLV types as follows: Value Sub-TLV Reference --------- -------------------------- ---------- 0 Reserved [This.I-D] 1. What does "Reserved" mean? Does it mean "Reserved and not to be allocated"? Does it mean "Reserved but a future RFC may assign it"? Does it mean "Unassigned and available for normal allocation"? You need to decide and make it clear for IANA 2. IANA will need to know what the range of available values is. 3 up to what limit? From julien.meuric@orange.com Mon Aug 26 08:20:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D83F21E8091 for ; Mon, 26 Aug 2013 08:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5lJugQradoq for ; Mon, 26 Aug 2013 08:20:16 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0459C21E8089 for ; Mon, 26 Aug 2013 08:20:16 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 053FC410220; Mon, 26 Aug 2013 17:20:15 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 1307541021E; Mon, 26 Aug 2013 17:20:14 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Aug 2013 17:20:13 +0200 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Aug 2013 17:20:13 +0200 Message-ID: <521B722C.5060807@orange.com> Date: Mon, 26 Aug 2013 17:20:12 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Aug 2013 15:20:13.0635 (UTC) FILETIME=[C2F6D930:01CEA26F] Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-lsp-diversity@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-lsp-diversity X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 15:20:20 -0000 Hi Deborah. No, I'm not aware of any IPR that applies to this draft. Julien On 08/09/2013 20:06, BRUNGARD, DEBORAH A wrote: > Authors, Contributors, (CCAMP) > > As part of the preparation for WG Last Call: > > Are you aware of any IPR that applies to draft identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" or "Yes, > I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer > the above by responding to this email regardless of whether or not > you are aware of any relevant IPR. This document will not advance to > the next stage until a response has been received from each author > and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN > THIS MESSAGE'S TO LINES. > > If you are on the CCAMP WG email list but are not listed as an author > or contributor, we remind you of your obligations under the IETF IPR > rules which encourages you to notify the IETF if you are aware of IPR > of others on an IETF contribution, or to refrain from participating > in any contribution or discussion related to your undisclosed IPR. > For more information, please see the RFCs listed above and > _http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty_. > > Thank you, CCAMP WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > From ogondio@tid.es Mon Aug 26 17:20:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDC411E810A for ; Mon, 26 Aug 2013 17:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OuLaozlRgdr for ; Mon, 26 Aug 2013 17:20:40 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF22711E8103 for ; Mon, 26 Aug 2013 17:20:39 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MS500EVYYADP8@tid.hi.inet> for ccamp@ietf.org; Tue, 27 Aug 2013 02:20:37 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 65.8A.24502.5D0FB125; Tue, 27 Aug 2013 02:20:37 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MS500EVTYADP8@tid.hi.inet> for ccamp@ietf.org; Tue, 27 Aug 2013 02:20:37 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Tue, 27 Aug 2013 02:20:37 +0200 Date: Tue, 27 Aug 2013 00:20:35 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: X-Originating-IP: [10.95.64.115] To: "BRUNGARD, DEBORAH A" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TdB09qiYTbWM4gUt54TRig)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-index: Ac6VK7+mWUvlMi3uQtWQFQbgJh00TQNj4LsA user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4068-b7fab8e000005fb6-a8-521bf0d5729a X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42Lhinfg0r36QTrIYNoFI4snc26wODB6LFny kymAMYrLJiU1J7MstUjfLoEro/ucfcEMj4rpayQaGI/ZdTFycEgImEjcOZPVxcgJZIpJXLi3 nq2LkYtDSGAjo8T9q5eYIJwfjBJPDnQzQzgzgZzJb5lBulkEVCUetyiCdLMJOEisW9TLBmIL CzhKzHt/nx2khFMgSmLdPEWIBQoSf849ZgEZIwIy5krTSbB6ZqAxbzf8ZgSp5xXQljj6yQEk zCsgKPFj8j0WiBJfiQPHdkLZ4hJzfk1kBbEZBWQlVp4/zQhiiwg4STxY08IGYRtJHLr6AMwW FdCTaDt2hh3iBgGJJXvOM0PYohIvH/9jncAoNgvJullI1s1Csg7C1pO4MXUKG4StLbFs4Wtm CFtXYsa/Q1D1ZhItr18yIqtZwMixilGsOKkoMz2jJDcxMyfdwFAvI1MvMy+1ZBMjJA4zdjAu 36lyiFGAg1GJh7ejSTpIiDWxrLgy9xCjBAezkggv1x2gEG9KYmVValF+fFFpTmrxIUYmDk6p BsaDuRsWB79+r9Nk/La5Z2pDoNevuLTfiUzh+yzTJHZUdr84PY01k7+kIe/2RuXZl36/dpUs X/n7seGEpW+3lZpszlujuvnKqfYLZ6LOqr8590Fxx+JOi+d88xljlYVneqk/TWV1P/ktM6Ax N+G6UeBdq2UMl7adEWK+Mmd5jfCkTI449TlyMX5KLMUZiYZazEXFiQCfZt/MoQIAAA== Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 00:20:51 -0000 --Boundary_(ID_TdB09qiYTbWM4gUt54TRig) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft Best Regards, Oscar De: , DEBORAH A BRUNGARD > Fecha: viernes, 9 de agosto de 2013 20:10 Para: "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" > CC: CCAMP > Asunto: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Nuevo env=EDo para: Daniele Ceccarelli >, "fu.xihua@zte.com.cn" >, Iftekhar H= ussain >, Oscar Gonzale= z de Dios >, Ramon Casellas >, Fatai Zhang > Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_TdB09qiYTbWM4gUt54TRig) Content-id: Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
No, I'm not aware = of any IPR that applies to this draft

Best Regards,

Oscar

De: <BRUNGARD>, DEBORAH A BRU= NGARD <db3546@att.com>
Fecha: viernes, 9 de agosto de 2013= 20:10
Para: "draft-ogrcetal-ccamp-flexi-g= rid-fwk@tools.ietf.org" <draft-ogrcetal-ccamp-flexi-grid-fwk@tools.i= etf.org>
CC: CCAMP <ccamp@ietf.org>
Asunto: Regarding IPR on draft-ogrc= etal-ccamp-flexi-grid-fwk
Nuevo env=EDo para: Daniele Ceccare= lli <daniele.ceccarel= li@ericsson.com>, "fu.xi= hua@zte.com.cn" <fu.xihu= a@zte.com.cn>, Iftekhar Hussain <IHussain@inf= inera.com>, Oscar Gonzalez de Dios <ogondio@tid.es>, Ramon Casellas <ramon.casellas@cttc.es>, Fatai Zhang <zhangfatai@huawei.com>=

Authors, Contributors, (CCAMP)
 
As part of the preparation for WG document adoption:
 
Are you aware of any IPR that applies to draft identified above?
 
  Please state either:
 
  "No, I'm not aware of any IPR that applies to this draft&q= uot;
  or
  "Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?
 
   If yes to the above, please state either:
 
  "Yes, the IPR has been disclosed in compliance with IETF I= PR rules"
  or
  "No, the IPR has not been disclosed"
 
  If you answer no, please provide any additional details you thi= nk
  appropriate.
 
If you are listed as a document author or contributor please answer th= e
above by responding to this email regardless of whether or not you are=
aware of any relevant IPR.  This document will not advance to the= next
stage until a response has been received from each author and listed
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.
 
If you are on the CCAMP WG email list but are not listed as an author = or
contributor, we remind you of your obligations under the IETF IPR rule= s
which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in an= y
contribution or discussion related to your undisclosed IPR.  For = more
information, please see the RFCs listed above and
 
Thank you,
CCAMP WG Chairs
 
PS Please include all listed in the headers of this message in your
response.
 
 


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_TdB09qiYTbWM4gUt54TRig)-- From daniele.ceccarelli@ericsson.com Tue Aug 27 08:00:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFCA11E8381 for ; Tue, 27 Aug 2013 08:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEPwq6T57KOd for ; Tue, 27 Aug 2013 08:00:33 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7664D11E836F for ; Tue, 27 Aug 2013 08:00:32 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-ae-521cbf0a74cb Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8E.0E.03802.A0FBC125; Tue, 27 Aug 2013 17:00:26 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Tue, 27 Aug 2013 17:00:26 +0200 From: Daniele Ceccarelli To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ospf-g709v3 Thread-Index: Ac6gLgpkZoIREJ3nTwOKEbtl2Arm1AC60ZZg Date: Tue, 27 Aug 2013 15:00:25 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4814ACAB@ESESSMB301.ericsson.se> References: <04eb01cea02e$0d005b30$27011190$@olddog.co.uk> In-Reply-To: <04eb01cea02e$0d005b30$27011190$@olddog.co.uk> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjS7Xfpkgg+Y7ChY/em4wWzyZc4PF 4m/DaxYHZo8lS34yeazYvJLR48vlz2wBzFFcNimpOZllqUX6dglcGbNeT2QvWOFVMenMZ6YG xlWWXYycHBICJhKrj0xmgbDFJC7cW88GYgsJHGaU2NDo38XIBWQvYZR4PXUNUIKDg03ASuLJ IR+QuIjAHEaJD1umMoM0MAuoSrRdP8UKUiMs4CLR8LMIJCwi4Cpxdu4iJgjbSOLgqiNg5SxA 5T9/TmEEsXkFvCVaL61gAmkVAhr/YKcLSJhTwFpiefNzsHMYBWQlJuxexAixSVzi1pP5TBAn C0gs2XOeGcIWlXj5+B8rhK0o0f60AapeT+LG1ClsELa2xLKFr5kh1gpKnJz5hGUCo9gsJGNn IWmZhaRlFpKWBYwsqxjZcxMzc9LLjTYxAmPm4JbfqjsY75wTOcQozcGiJM67We9MoJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGKqWO/OzqUyni3/9JBu6NO7ptSmVL2G2uN2em5XGK3Lsi tUXrru1r5s7aRRv3T+GzKMhWfuLUVBq/ord2ruf/RIYpiwOuOtw+3+ub1NcV47Kr1Sn1y+Vv P+Vv7V0naPpp5cbdoqkTU5TYz26oXPhSx32DD5cP4+pTTYzrzjdOm2V/Zt1FW745SizFGYmG WsxFxYkAnlQ8xWcCAAA= Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ospf-g709v3 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 15:00:38 -0000 Hi Adrian, Thanks for the review. Let's see in line if I manage to convince you. BR Daniele > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Adrian Farrel > Sent: venerd=EC 23 agosto 2013 20:25 > To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org > Cc: ccamp@ietf.org > Subject: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ospf-g709v3 >=20 > Hi authors and working group, >=20 > I have done my usual AD review on receiving a publication request for thi= s > document to smooth out any issues before IETF last call and IESG evaluati= on. >=20 > As you'll see below, I have a few small issues that I would like to work > through. The result will either be some email discussion where you convi= nce > me that no change is needed, or a revised version of the document. >=20 > Thanks for the work, > Adrian >=20 > =3D=3D=3D >=20 > I have a thread with the authors about why they need to list nine authors= on > the front page. The RFC Editor has a norm of no more than five unless the= re > is a specific reason. >=20 [[DC]] working on that to reduce to <=3D5 > --- >=20 > This document does not update 4203. Extending mechanisms is not an > update, and this document doesn't really even extend the mechanisms; it > simply defines a new ISCD and describes how it is used. [[DC]] Reasonable. Removed. >=20 > --- >=20 > Section 2 has a reference to [swcaps-update]. I suspect this is meant to = be > draft-ietf-ccamp-swcaps-update. You need to add this to the informative > references section. >=20 [[DC]] added > --- >=20 > Section 2 is wrongly named! The section does describe the requirements, b= ut > there is actually nothing in the section that is specific to OSPF and cer= tainly no > description of OSPF extensions. >=20 > I found the material useful, but wondered why it was in this document and > not in the information model document since it perfectly describes the > information model that needs to be applied. I am not requiring you to do > anything about this, but I would ask you think hard about whether this te= xt > should be moved to the other document and simply pointed to from here. [[DC]] you're right, there is no OSPF extension but I think the section is = a good intro to what comes next. How about deleting section 2 and moving all the text at the end of the intr= o? (section1). >=20 > --- >=20 > Section 3 is a fine and concise section. But it seems to me that this mat= erial > also belongs in the information model document, not here. > Again, I am not requiring you to make a change here, but please think abo= ut > whether the section could be moved and replaced with a pointer. [[DC]] Maybe this one is a better candidate for moving to the info model dr= aft. How about between section 2 and section 3 of the info model draft? >=20 > --- >=20 > Section 4 >=20 > OLD > - Encoding Type =3D G.709 ODUk (Digital Path) [as defined in RFC4328] = NEW > - Encoding Type =3D G.709 ODUk (Digital Path) as defined in [RFC4328] = END >=20 [[DC]] ok > --- >=20 > The description of the table in section 4 caused me some grief. You have.= .. >=20 > The bandwidth unit is in bytes per second and the encoding MUST > be in Institute of Electrical and Electronic Engineers (IEEE) > floating point format. The discrete values for various ODUs is shown > in the table below. >=20 > Could you please do two things: >=20 > 1. Remind the reader that there are 1000 bits in a kbit according to > normal practices in telecommunications. (Probably add a note to the > quoted text.) > 2. Clarify that the third column shows a floating point value. (Update > the column heading.) >=20 [[DC]] done >=20 > However, I do also note that the use of bandwidth in section 4.1.3 are > described as (for example)... >=20 > This field > MUST be set to the bandwidth, in bits/s in IEEE floating point > format, available at the indicated Signal Type for a particular > priority level. >=20 > So you also need to sort that out. [[DC]] right, either we need to express the bandwidth in bits/s or bytes/se= c everywhere. Any preference? Bytes/sec is ok?=20 >=20 > --- >=20 > Section 4. > In the table, could you fix up the notation of ODU3 to use 0x not 0X >=20 [[DC]] done > --- >=20 > I wonder whether the text and figure for the example in Figure 10 needs i= ts > own section. >=20 [[DC]] the whole example 5.2.1 is an example of different TS granularities = utilization. Figure 9 shows the encoding and figure 10 shows when such a ca= n occur. I would say it make sense to have them in the same section but I a= m open to change if needed.=20 > --- >=20 > I think there are some issues (or possibly some unspoken points) with > section 6. >=20 > 1. Suppose you have an old implementation. How will it treat these new > advertisements? > For this you are just stating facts. There is nothing you can define > because you cannot influence how old implementations work. But you > can say how they will behave according to existing specs. [[DC]] don't remember if unknown values are silently discarded or blindly f= orwarded but if we say something we fall in the same issue of information r= epeated over different documents. I.e. if some day RFC4203 is updated we ne= ed to update this id also. Maybe we could say that "old nodes" behave as de= scribed in RFC4203 >=20 > 2. If a new implementation only supports this spec and not RFC 4328 how > will it handle an RFC 4328 advertisement? > This is something you can and must describe. [[DC]] ok. How about:=20 "All implementations of this document MAY support also advertisement as defined in RFC4328. In case they don't, they MUST flood OSPF message wi= thout modifying them. " >=20 > 3. For a new implementation that supports this spec and RFC 4328, I don't > understand what you have written. >=20 > When nodes support both advertisement > methods, implementations MUST support the configuration of which > advertisement method is followed. >=20 > I *think* this says that > - a node MUST NOT use more than one advertisement method to advertise > the resources on a single OTN link > It also appears to say that > - a node MUST NOT use more than one advertisement method to advertise > across *all* of its advertisements [[DC]] How about: " When nodes support both advertisement methods, they MUST NOT use more than one advertisement method to advert= ise the resources on a single OTN link and across all of its advertisements. >=20 > You go on to say... >=20 > This enables > nodes following each method to identify similar supporting nodes > and compute paths using only the appropriate nodes. >=20 > ...which seems to imply that it is not possible to compute a path > end-to-end across nodes using a mix of the old and new advertisement > types. Is that *really* what you want to say? [[DC]] An old node cannot understand new advertisement, hence can only esta= blish lsps along a path of old nodes only. A new node may not understand old advertisement and hence only e able to se= tup an lsp along a path of new nodes only. If a new node understands old advertisement it is possible to setup lsps al= ong a path including a mix of new and old nodes. This is the idea. If it is acceptable could you please help me with some te= xt clearly stating it? >=20 > --- >=20 > It might be helpful to break section 8 into subsections. >=20 [[DC]] switching types and new tlvs I guess. Correct? > --- >=20 > Section 8 >=20 > For the new Switching Type you need to remind IANA to make the update in > the IANA-GMPLS-TC-MIB at > https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib >=20 [[DC]] ok > --- >=20 > Section 8 >=20 >=20 > Upon approval of this document, IANA will create and maintain a new > registry, the "Types for sub-TLVs of OTN-TDM SCSI (Switch Capability > Specific Information)" registry under the "Open Shortest Path First > (OSPF) Traffic Engineering TLVs" registry, see http://www.iana.org/ > assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xml, with the > TLV types as follows: >=20 >=20 > This document defines new TLV types as follows: >=20 > Value Sub-TLV Reference > --------- -------------------------- ---------- > 0 Reserved [This.I-D] >=20 > 1. What does "Reserved" mean? Does it mean "Reserved and not to be > allocated"? Does it mean "Reserved but a future RFC may assign it"? > Does it mean "Unassigned and available for normal allocation"? > You need to decide and make it clear for IANA [[DC]] personally don't care. Looking at recent RFCs I only found "reserved= ". Suggestions are welcome. >=20 > 2. IANA will need to know what the range of available values is. > 3 up to what limit? [[DC]] I've added:=20 3-65535 Unassigned.=20 We might consider splitting into two ranges. A range unassigned and one for= experimental use? (just loud thinking). Suggestions? >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Tue Aug 27 11:31:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA3221E8084 for ; Tue, 27 Aug 2013 11:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.598 X-Spam-Level: X-Spam-Status: No, score=-86.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNM31uJVBb8S for ; Tue, 27 Aug 2013 11:31:52 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id A08F021E80D6 for ; Tue, 27 Aug 2013 11:31:51 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 790fc125.0.2461563.00-405.6744460.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 27 Aug 2013 18:31:51 +0000 (UTC) X-MXL-Hash: 521cf0975054d837-beb103f8a5bfc3923f2e2039a59b15058c7c14ca Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7RIVohe003344 for ; Tue, 27 Aug 2013 14:31:50 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7RIVXjT003023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Aug 2013 14:31:44 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Tue, 27 Aug 2013 18:31:18 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0123.003; Tue, 27 Aug 2013 14:31:18 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: MPLS/SDN 2013 Program Information Thread-Index: Ac6jU51SX+a2GKDnQhCnoKKMz+35Ow== Date: Tue, 27 Aug 2013 18:31:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8370118MISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=E6l6U9hl c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Spb-YzarxCcA:10 a=c5NDYQCSA] X-AnalysisOut: [AAA:8 a=hI4hXzlpAAAA:8 a=vsjc1QakAAAA:8 a=bAw8GziROgPobwlO] X-AnalysisOut: [AKsA:9 a=CjuIK1q_8ugA:10 a=JhryCXmUXmcA:10 a=4uL6tO0EGlkA:] X-AnalysisOut: [10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=Va0vWtVP2DLCu4nI:] X-AnalysisOut: [21] Subject: [CCAMP] MPLS/SDN 2013 Program Information X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 18:31:58 -0000 --_000_F64C10EAA68C8044B33656FA214632C8370118MISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The MPLS/SDN 2013 Conference (the 16th annual event) program is now posted and is available at www.mpls2013.com, or sp= ecifically Tutorials (Sun): http://www.isocore.com/mpls2013/program/tutorials.htm Technical sessions (Mon-Wed): http://www.isocore.com/mpls2013/program/technical_sessions.htm The conference will take place November 17-20 in Washington DC and will include an extensive four day program consisting of tutorials, technical sessions, panels, and exhibits. The key topics to be discussed at this year's conference include: Virtualization, SDN, Cloud and Data Centers, Mobility and SDN, PCE, Traffic Engineering and Emerging Technologies, Transport SDN, Orchestration, and emerging multi-play applications across common infrastructure. The conference hotel is the Marriott Wardman Park in Washington DC. Please note that there are only a limited number of rooms available this year at a reduced rate. Please make reservations at: https://resweb.passkey.com/Resweb.do?mode=3Dwelcome_ei_new&eventID=3D105835= 03&utm_source=3D1786&utm_medium=3Demail&utm_campaign=3D23303762 --_000_F64C10EAA68C8044B33656FA214632C8370118MISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The MPLS/SDN 2013 Conference (the 16th annual event) program is now
posted and is available at www.mpls2013.com, or specifically
 
 
Technical sessions (Mon-Wed):
 
The conference will take place November 17-20 in Washington DC and wil= l
include an extensive four day program consisting of tutorials, technic= al
sessions, panels, and exhibits. The key topics to be discussed at this=
year's conference include: Virtualization, SDN, Cloud and Data Centers= ,
Mobility and SDN, PCE, Traffic Engineering and Emerging Technologies,<= /div>
Transport SDN, Orchestration, and emerging multi-play applications
across common infrastructure.
 
The conference hotel is the Marriott Wardman Park in Washington DC. Pl= ease
note that there are only a limited number of rooms available this year= at a
reduced rate.
 
Please make reservations at:
 
 
 
 
 --_000_F64C10EAA68C8044B33656FA214632C8370118MISOUT7MSGUSR9OIT_-- From lberger@labn.net Thu Aug 29 08:23:09 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E476F11E8125 for ; Thu, 29 Aug 2013 08:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imktBlA3CfkO for ; Thu, 29 Aug 2013 08:23:03 -0700 (PDT) Received: from oproxy12-pub.mail.unifiedlayer.com (oproxy12-pub.mail.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id E9EFE11E8121 for ; Thu, 29 Aug 2013 08:23:00 -0700 (PDT) Received: (qmail 32227 invoked by uid 0); 29 Aug 2013 15:22:38 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.mail.unifiedlayer.com with SMTP; 29 Aug 2013 15:22:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=qz+QRTNDYuHkL+JOkCr5xzDtk5K6u3r1y110Yo1g2g8=; b=XbT+3GNRVDs53m07ZqCM6TJhhpudl+3gUxRCcMKK8eh2MsC6wjPjXnTo/p0ahIHzQIAAiEsQMCkqD+cIPFxAASCmKkhyvsHtlBLhuWtx6x8c7HKqtbbti/ok+VZFJohv; Received: from box313.bluehost.com ([69.89.31.113]:57058 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VF43S-0001fU-Hj for ccamp@ietf.org; Thu, 29 Aug 2013 09:22:38 -0600 Message-ID: <521F673D.9040802@labn.net> Date: Thu, 29 Aug 2013 11:22:37 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CCAMP References: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> In-Reply-To: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Fwd: FW: Mail lost yesterday X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:23:10 -0000 FYI -------- Original Message -------- Subject: FW: Mail lost yesterday Resent-Date: Thu, 29 Aug 2013 08:47:32 -0600 Resent-From: wg-alias-bounces@tools.ietf.org Resent-To: jhaas@pfrc.org, nobo@cisco.com, dbrungard@att.com, lberger@labn.net, hadi@mojatatu.com, damascene.joachimpillai@verizon.com, akatlas@juniper.net, edc@google.com, shares@ndzh.com, jgs@juniper.net, chopps@rawdofmt.org, hannes@juniper.net, jmh@joelhalpern.com, bew@cisco.com, nabil.n.bitar@verizon.com, giheron@cisco.com, thomas.morin@orange.com, martin.vigoureux@alcatel-lucent.com, macker@itd.nrl.navy.mil, sratliff@cisco.com, swallow@cisco.com, loa@pi.nu, rcallon@juniper.net, bensons@queuefull.net, matthew.bocci@alcatel-lucent.com, akr@cisco.com, acee.lindem@ericsson.com, jpv@cisco.com, julien.meuric@orange.com, mmcbride7@gmail.com, stig@venaas.com, matthew.bocci@alcatel-lucent.com, andrew.g.malis@verizon.com, jpv@cisco.com, mcr+ietf@sandelman.ca, aretana@cisco.com, akatlas@gmail.com, Sandra.Murphy@sparta.com, morrowc@ops-netman.net, stbryant@cisco.com, adrian@olddog.co.uk, Date: Thu, 29 Aug 2013 15:46:09 +0100 From: Adrian Farrel Reply-To: To: For those of you who haven't noticed the message from Steve Young in your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific Time yesterday seems to have been lost. Aside from needing to re-send all mail you personally sent during that time period, you also need to inform your working groups. From takeda.tomonori@lab.ntt.co.jp Thu Aug 29 22:47:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A92311E819C; Thu, 29 Aug 2013 22:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWKUzJPFUjqJ; Thu, 29 Aug 2013 22:47:14 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id BBB2A11E819B; Thu, 29 Aug 2013 22:47:13 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id r7U5l56A007659; Fri, 30 Aug 2013 14:47:05 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 2CB3CE013D; Fri, 30 Aug 2013 14:47:05 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 20CEDE0141; Fri, 30 Aug 2013 14:47:05 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id r7U5l5MQ014566; Fri, 30 Aug 2013 14:47:05 +0900 Message-Id: <201308300547.r7U5l5MQ014566@imail2.m.ecl.ntt.co.jp> To: rtg-ads@tools.ietf.org From: Tomonori TAKEDA Date: Fri, 30 Aug 2013 14:47:05 +0900 X-Mailer: WebMail V3.7 PL3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: No Cc: rtg-dir@ietf.org, ccamp@ietf.org, draft-ietf-ccamp-gmpls-g709-framework.all@tools.ietf.org Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-g709-framework-14.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 05:47:19 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ccamp-gmpls-g709-framework-14.txt Reviewer: Tomonori Takeda Review Date: 30 August 2013 IETF LC End Date: 02 September 2013 Intended Status: Informational o Summary: This document describes framework for GMPLS/PCE control of OTN and impacts on GMPLS/PCE protocols. Overview of OTN is mentioned, which is helpful to understand the document. o Comments: I have some minor concerns about this document that I think should be resolved before publication. (I think these are mostly related to clarification questions.) o Major Issues: No major issues found. o Minor Issues: 1) In Section 5.3., it says the following requirement for GMPLS routing. - Support different priorities for resource reservation I think this is a valid requirement, but I do not think this is specific to OTN. Does this imply the need for protocol extensions or just the usage of protocols? 2) Section 5.4., it says: Furthermore, since multiplexing hierarchy was not allowed by the legacy OTN referenced by [RFC4328], .... By reading RFC4328 section 2, it refers to ODU multiplexing. Am I missing something? 3) In Section 5.5., it says. Note that this case is supported by the procedures defined in [RFC3473] as a different Switching Capability/Type value is used for the different control plane versions. I am not sure which part of RFC3473 metions such procedures. Could you please point it? o Nits: Section 4.1 s/Lo ODU/LO ODU/ Section 4.1 s/substitute/substituted Section 5.6 s/section 5.2.1/section 5.2 Thanks, Tomonori From huubatwork@gmail.com Fri Aug 30 01:04:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E6C21E80A7 for ; Fri, 30 Aug 2013 01:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2+SfWTxCbeA for ; Fri, 30 Aug 2013 01:04:51 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0902521E80A3 for ; Fri, 30 Aug 2013 01:04:50 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h14so740351eak.29 for ; Fri, 30 Aug 2013 01:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=MReGVF4tQMBhjZSlQktW3TBqDO4PC/3YX8E/Me8VgPc=; b=r35dxBv1mpCLKy71LU1bDphw1+O5WFYzczAFSt7nwMzx0G7tChPtGtA+S1ezwK2eTc jWzLDvS541HRMhwDjUhzF5R6JOC9e8CojLbV7dnzf2kGCfQWYtuGT3/WTA+n1NZjg69d I3dLxaTjIT7VsN6CRXzXXjrSzBEvwnRe+ZnJAgbqqGExzYC58jZh+fP5HpSxuDdiGpnS X70PZOFjd/BstCQLaRCziCsh5EwsWRk8Q0qqsO9eCtdHxb7WbcQ7bueIkruFL5vnmDmC DuJ0CrZ7lLqhdI/QFXHjp04+ZEibmzxn+2BD/WCjlovyMqze9rP82in5FrNwE+79Zwwn pkmA== X-Received: by 10.14.113.137 with SMTP id a9mr10589980eeh.3.1377849887763; Fri, 30 Aug 2013 01:04:47 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id b45sm52507266eef.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 01:04:47 -0700 (PDT) Message-ID: <52205220.20804@gmail.com> Date: Fri, 30 Aug 2013 10:04:48 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ccamp@ietf.org" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 08:04:51 -0000 "No, I'm not aware of any IPR that applies to this draft" Best regards, Huub van Helvoort. From Malcolm.BETTS@zte.com.cn Fri Aug 30 07:49:00 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE0311E8111 for ; Fri, 30 Aug 2013 07:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.553 X-Spam-Level: X-Spam-Status: No, score=-101.553 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU6KXK7+OU8R for ; Fri, 30 Aug 2013 07:48:55 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A3DF321F9E44 for ; Fri, 30 Aug 2013 07:48:50 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 730A61322DAC for ; Fri, 30 Aug 2013 22:48:30 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 9017D730C30; Fri, 30 Aug 2013 22:48:29 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r7UEmU8C001708; Fri, 30 Aug 2013 22:48:30 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: References: To: "BRUNGARD, DEBORAH A" MIME-Version: 1.0 X-KeepSent: 6046F44E:29AD2F1A-85257BD7:0051246A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Fri, 30 Aug 2013 10:48:05 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-08-30 22:48:08, Serialize complete at 2013-08-30 22:48:08 Content-Type: multipart/alternative; boundary="=_alternative 0051578785257BD7_=" X-MAIL: mse02.zte.com.cn r7UEmU8C001708 Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 14:49:00 -0000 This is a multipart message in MIME format. --=_alternative 0051578785257BD7_= Content-Type: text/plain; charset="US-ASCII" "No, I'm not aware of any IPR that applies to this draft" Regards, Malcolm --=_alternative 0051578785257BD7_= Content-Type: text/html; charset="US-ASCII" "No, I'm not aware of any IPR that applies to this draft"

Regards,

Malcolm --=_alternative 0051578785257BD7_=-- From blu@infinera.com Fri Aug 30 08:43:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D278E21E80D6 for ; Fri, 30 Aug 2013 08:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55u9N3J44+RZ for ; Fri, 30 Aug 2013 08:43:53 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2C52A21F9FF2 for ; Fri, 30 Aug 2013 08:43:46 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Fri, 30 Aug 2013 08:43:45 -0700 From: Biao Lu To: "BRUNGARD, DEBORAH A" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-Index: Ac6VK7+mWUvlMi3uQtWQFQbgJh00TQQa+jIA Date: Fri, 30 Aug 2013 15:43:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_B9CBD6F2293C14458AFDD5B5286F32340C4CF2B6SVEXDBPROD2infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 15:43:57 -0000 --_000_B9CBD6F2293C14458AFDD5B5286F32340C4CF2B6SVEXDBPROD2infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft Thanks, Biao From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Friday, August 09, 2013 11:11 AM To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_B9CBD6F2293C14458AFDD5B5286F32340C4CF2B6SVEXDBPROD2infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I'm not = aware of any IPR that applies to this draft

 <= /o:p>

Thanks,=

Biao<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Friday, August 09, 2013 11:11 AM
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fw= k

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG docum= ent adoption:

 

Are you aware of any IPR that applies t= o draft identified above?

 

  Please state either:<= /span>

 

  "No, I'm not aware of any I= PR that applies to this draft"

  or

  "Yes, I'm aware of IPR that= applies to this draft"

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details)?

 

   If yes to the above, pleas= e state either:

 

  "Yes, the IPR has been disc= losed in compliance with IETF IPR rules"

  or

  "No, the IPR has not been d= isclosed"

 

  If you answer no, please provide= any additional details you think

  appropriate.

 

If you are listed as a document author = or contributor please answer the

above by responding to this email regar= dless of whether or not you are

aware of any relevant IPR.  This d= ocument will not advance to the next

stage until a response has been receive= d from each author and listed

contributor.  NOTE: THIS APPLIES T= O ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list b= ut are not listed as an author or

contributor, we remind you of your obli= gations under the IETF IPR rules

which encourages you to notify the IETF= if you are aware of IPR of

others on an IETF contribution, or to r= efrain from participating in any

contribution or discussion related to y= our undisclosed IPR.  For more

information, please see the RFCs listed= above and

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the hea= ders of this message in your

response.

 

 

--_000_B9CBD6F2293C14458AFDD5B5286F32340C4CF2B6SVEXDBPROD2infi_-- From rrao@infinera.com Fri Aug 30 09:48:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483F221F9F5B for ; Fri, 30 Aug 2013 09:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGWkUvFnEwzu for ; Fri, 30 Aug 2013 09:48:04 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1901721F9EA2 for ; Fri, 30 Aug 2013 09:48:03 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Fri, 30 Aug 2013 09:48:02 -0700 From: Rajan Rao To: "BRUNGARD, DEBORAH A" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-Index: Ac6VK7+mWUvlMi3uQtWQFQbgJh00TQQdNGSQ Date: Fri, 30 Aug 2013 16:48:01 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D3FBD98C4@SV-EXDB-PROD2.infinera.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_650AA355E323C34D9D4AAEED952E053D3FBD98C4SVEXDBPROD2infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:48:08 -0000 --_000_650AA355E323C34D9D4AAEED952E053D3FBD98C4SVEXDBPROD2infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "No, I'm not aware of any IPR that applies to this draft" Regards Rajan From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Friday, August 09, 2013 11:11 AM To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_650AA355E323C34D9D4AAEED952E053D3FBD98C4SVEXDBPROD2infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

  "No, I'm not aware of any IPR that a= pplies to this draft"

 <= /p>

Regards=

Rajan

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Friday, August 09, 2013 11:11 AM
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fw= k

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG docum= ent adoption:

 

Are you aware of any IPR that applies t= o draft identified above?

 

  Please state either:<= /span>

 

  "No, I'm not aware of any I= PR that applies to this draft"

  or

  "Yes, I'm aware of IPR that= applies to this draft"

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details)?

 

   If yes to the above, pleas= e state either:

 

  "Yes, the IPR has been disc= losed in compliance with IETF IPR rules"

  or

  "No, the IPR has not been d= isclosed"

 

  If you answer no, please provide= any additional details you think

  appropriate.

 

If you are listed as a document author = or contributor please answer the

above by responding to this email regar= dless of whether or not you are

aware of any relevant IPR.  This d= ocument will not advance to the next

stage until a response has been receive= d from each author and listed

contributor.  NOTE: THIS APPLIES T= O ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list b= ut are not listed as an author or

contributor, we remind you of your obli= gations under the IETF IPR rules

which encourages you to notify the IETF= if you are aware of IPR of

others on an IETF contribution, or to r= efrain from participating in any

contribution or discussion related to y= our undisclosed IPR.  For more

information, please see the RFCs listed= above and

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the hea= ders of this message in your

response.

 

 

--_000_650AA355E323C34D9D4AAEED952E053D3FBD98C4SVEXDBPROD2infi_-- From leeyoung@huawei.com Fri Aug 30 09:58:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DE621F9C06 for ; Fri, 30 Aug 2013 09:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNH8u7YN0Zyo for ; Fri, 30 Aug 2013 09:58:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AA2F921F9B08 for ; Fri, 30 Aug 2013 09:57:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWT16441; Fri, 30 Aug 2013 16:57:44 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 30 Aug 2013 17:57:23 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 30 Aug 2013 17:57:14 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.204]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Fri, 30 Aug 2013 09:57:08 -0700 From: Leeyoung To: "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-Index: Ac6VK7+mWUvlMi3uQtWQFQbgJh00TQP8ijMAAActOYA= Date: Fri, 30 Aug 2013 16:57:06 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17291B42A8@dfweml511-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.108] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E17291B42A8dfweml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:58:12 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E17291B42A8dfweml511mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "No, I'm not aware of any IPR that applies to this draft" Young From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: Saturday, August 10, 2013 2:11 AM To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_7AEB3D6833318045B4AE71C2C87E8E17291B42A8dfweml511mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

"No, I'm not aware of any IPR that= applies to this draft"

 <= /p>

Young

From: BRUNGARD= , DEBORAH A [mailto:db3546@att.com]
Sent: Saturday, August 10, 2013 2:11 AM
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG docum= ent adoption:

 

Are you aware of any IPR that applies t= o draft identified above?

 

  Please state either:<= /span>

 

  "No, I'm not aware of any I= PR that applies to this draft"

  or

  "Yes, I'm aware of IPR that= applies to this draft"

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details)?

 

   If yes to the above, pleas= e state either:

 

  "Yes, the IPR has been disc= losed in compliance with IETF IPR rules"

  or

  "No, the IPR has not been d= isclosed"

 

  If you answer no, please provide= any additional details you think

  appropriate.

 

If you are listed as a document author = or contributor please answer the

above by responding to this email regar= dless of whether or not you are

aware of any relevant IPR.  This d= ocument will not advance to the next

stage until a response has been receive= d from each author and listed

contributor.  NOTE: THIS APPLIES T= O ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list b= ut are not listed as an author or

contributor, we remind you of your obli= gations under the IETF IPR rules

which encourages you to notify the IETF= if you are aware of IPR of

others on an IETF contribution, or to r= efrain from participating in any

contribution or discussion related to y= our undisclosed IPR.  For more

information, please see the RFCs listed= above and

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the hea= ders of this message in your

response.

 

 

--_000_7AEB3D6833318045B4AE71C2C87E8E17291B42A8dfweml511mbschi_-- From msosa@infinera.com Fri Aug 30 13:57:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766E721F9D15 for ; Fri, 30 Aug 2013 13:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chvr8AZM8vnC for ; Fri, 30 Aug 2013 13:56:50 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 22E8721F9D1E for ; Fri, 30 Aug 2013 13:56:50 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Fri, 30 Aug 2013 13:56:47 -0700 From: Marco Sosa To: "BRUNGARD, DEBORAH A" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Thread-Topic: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-Index: AQHOpaC5BMaQGssMWkii/yeN07v1c5muO1hg Date: Fri, 30 Aug 2013 20:56:47 +0000 Message-ID: <589607FC5DA65940AE5E96188CFA01B30B849C02@SV-EXDB-PROD2.infinera.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_589607FC5DA65940AE5E96188CFA01B30B849C02SVEXDBPROD2infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 20:57:10 -0000 --_000_589607FC5DA65940AE5E96188CFA01B30B849C02SVEXDBPROD2infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft. Marco From: Biao Lu [mailto:blu@infinera.com] Sent: Friday, August 30, 2013 8:44 AM To: BRUNGARD, DEBORAH A; draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk No, I'm not aware of any IPR that applies to this draft Thanks, Biao From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Friday, August 09, 2013 11:11 AM To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. --_000_589607FC5DA65940AE5E96188CFA01B30B849C02SVEXDBPROD2infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I'm not = aware of any IPR that applies to this draft.

 <= /o:p>

Marco

 <= /p>

 <= /p>

From: Biao Lu = [mailto:blu@infinera.com]
Sent: Friday, August 30, 2013 8:44 AM
To: BRUNGARD, DEBORAH A; draft-ogrcetal-ccamp-flexi-grid-fwk@tools.i= etf.org
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-gri= d-fwk

 

No, I'm not = aware of any IPR that applies to this draft

 <= /o:p>

Thanks,=

Biao<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Friday, August 09, 2013 11:11 AM
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fw= k

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG docum= ent adoption:

 

Are you aware of any IPR that applies t= o draft identified above?

 

  Please state either:<= /span>

 

  "No, I'm not aware of any I= PR that applies to this draft"

  or

  "Yes, I'm aware of IPR that= applies to this draft"

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details)?

 

   If yes to the above, pleas= e state either:

 

  "Yes, the IPR has been disc= losed in compliance with IETF IPR rules"

  or

  "No, the IPR has not been d= isclosed"

 

  If you answer no, please provide= any additional details you think

  appropriate.

 

If you are listed as a document author = or contributor please answer the

above by responding to this email regar= dless of whether or not you are

aware of any relevant IPR.  This d= ocument will not advance to the next

stage until a response has been receive= d from each author and listed

contributor.  NOTE: THIS APPLIES T= O ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list b= ut are not listed as an author or

contributor, we remind you of your obli= gations under the IETF IPR rules

which encourages you to notify the IETF= if you are aware of IPR of

others on an IETF contribution, or to r= efrain from participating in any

contribution or discussion related to y= our undisclosed IPR.  For more

information, please see the RFCs listed= above and

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the hea= ders of this message in your

response.

 

 

--_000_589607FC5DA65940AE5E96188CFA01B30B849C02SVEXDBPROD2infi_-- From zhang.xian@huawei.com Fri Aug 30 17:40:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FFE21F9E83 for ; Fri, 30 Aug 2013 17:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=-0.992, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuqeCr4iYiCj for ; Fri, 30 Aug 2013 17:40:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 72A1321F9E4F for ; Fri, 30 Aug 2013 17:40:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUX28469; Sat, 31 Aug 2013 00:40:09 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 31 Aug 2013 01:40:04 +0100 Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 31 Aug 2013 01:40:05 +0100 Received: from SZXEML510-MBS.china.huawei.com ([169.254.4.117]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.01.0323.007; Sat, 31 Aug 2013 08:40:00 +0800 From: "Zhangxian (Xian)" To: "BRUNGARD, DEBORAH A" , "draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Thread-Index: Ac6VK7+mWUvlMi3uQtWQFQbgJh00TQQNrK8w Date: Sat, 31 Aug 2013 00:39:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B189F3D1Dszxeml510mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 00:40:22 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B189F3D1Dszxeml510mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N Cg0KUmVnYXJkcywNClhpYW4NCg0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCUlVOR0FSRCwgREVCT1JBSCBB DQpTZW50OiAyMDEzxOo41MIxMMjVIDI6MTENClRvOiBkcmFmdC1vZ3JjZXRhbC1jY2FtcC1mbGV4 aS1ncmlkLWZ3a0B0b29scy5pZXRmLm9yZw0KQ2M6IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiBb Q0NBTVBdIFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtb2dyY2V0YWwtY2NhbXAtZmxleGktZ3JpZC1m d2sNCg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCAoQ0NBTVApDQoNCkFzIHBhcnQgb2YgdGhlIHBy ZXBhcmF0aW9uIGZvciBXRyBkb2N1bWVudCBhZG9wdGlvbjoNCg0KQXJlIHlvdSBhd2FyZSBvZiBh bnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPw0KDQogIFBsZWFz ZSBzdGF0ZSBlaXRoZXI6DQoNCiAgIk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBh cHBsaWVzIHRvIHRoaXMgZHJhZnQiDQogIG9yDQogICJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhh dCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNj bG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwg NDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KICAgSWYgeWVzIHRvIHRo ZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVu IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQogIG9yDQogICJO bywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQogIElmIHlvdSBhbnN3ZXIgbm8s IHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rDQogIGFwcHJv cHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250 cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVt YWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZQ0KYXdhcmUgb2YgYW55IHJl bGV2YW50IElQUi4gIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dA0K c3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9y IGFuZCBsaXN0ZWQNCmNvbnRyaWJ1dG9yLiAgTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZ T1UgTElTVEVEIElOIFRISVMNCk1FU1NBR0UnUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0 aGUgQ0NBTVAgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9y DQpjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRo ZSBJRVRGIElQUiBydWxlcw0Kd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRG IGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBSIG9mDQpvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRp b24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueQ0KY29udHJpYnV0aW9u IG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gIEZvciBtb3Jl DQppbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQpodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQ cm9wZXJ0eS4NCg0KVGhhbmsgeW91LA0KQ0NBTVAgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBpbmNs dWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXINCnJl c3BvbnNlLg0KDQoNCg== --_000_C636AF2FA540124E9B9ACB5A6BECCE6B189F3D1Dszxeml510mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

No, I'm not aware of any= IPR that applies to this draft.

 =

Regards,
Xian

 = ;

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org= ] On Behalf Of BRUNGARD, DEBORAH A
Sent: 2013=C4=EA8=D4=C210=C8= =D5 2:11
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fw= k

 

Authors, Contributors, (= CCAMP)

 =

As part of the preparati= on for WG document adoption:

 =

Are you aware of any IPR= that applies to draft identified above?

 =

  Please state eith= er:

 =

  "No, I'm not= aware of any IPR that applies to this draft"

  or

  "Yes, I'm aw= are of IPR that applies to this draft"

 =

If so, has this IPR been= disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 36= 69 and 5378 for more details)?

 =

   If yes to t= he above, please state either:

 =

  "Yes, the IP= R has been disclosed in compliance with IETF IPR rules"

  or

  "No, the IPR= has not been disclosed"

 =

  If you answer no,= please provide any additional details you think

  appropriate.=

 =

If you are listed as a d= ocument author or contributor please answer the

above by responding to t= his email regardless of whether or not you are

aware of any relevant IP= R.  This document will not advance to the next

stage until a response h= as been received from each author and listed

contributor.  NOTE:= THIS APPLIES TO ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.=

 =

If you are on the CCAMP = WG email list but are not listed as an author or

contributor, we remind y= ou of your obligations under the IETF IPR rules

which encourages you to = notify the IETF if you are aware of IPR of

others on an IETF contri= bution, or to refrain from participating in any

contribution or discussi= on related to your undisclosed IPR.  For more

information, please see = the RFCs listed above and

 =

Thank you,

CCAMP WG Chairs

 =

PS Please include all li= sted in the headers of this message in your

response.

 =

 =

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B189F3D1Dszxeml510mbschi_-- From gyzhang@sina.com Sat Aug 31 02:30:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D863521F9B4B for ; Sat, 31 Aug 2013 02:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBzzVqDnklCi for ; Sat, 31 Aug 2013 02:30:55 -0700 (PDT) Received: from smtp2911-209.mail.sina.com.cn (mail2-155.sinamail.sina.com.cn [60.28.2.155]) by ietfa.amsl.com (Postfix) with SMTP id 49B2D21F99DC for ; Sat, 31 Aug 2013 02:30:53 -0700 (PDT) Received: from unknown( HELO X220)([114.248.237.131]) by sina.com with ESMTP 31 Aug 2013 17:30:49 +0800 (CST) X-Sender: gyzhang@sina.com X-Auth-ID: gyzhang@sina.com X-SMAIL-MID: 8877915253489 Date: Sat, 31 Aug 2013 17:30:46 +0800 From: "gyzhang" To: "BRUNGARD, DEBORAH A (ATTLABS)" , "draft-ogrcetal-ccamp-flexi-grid-fwk" Message-ID: <201308311730458413881@sina.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon135044421627_=====" Cc: ccamp Subject: Re: [CCAMP] Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 09:31:00 -0000 This is a multi-part message in MIME format. --=====003_Dragon135044421627_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit No, I'm not aware of any IPR that applies to this draft. best, Guoying Zhang From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: Saturday, August 10, 2013 2:11 AM To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk Authors, Contributors, (CCAMP) As part of the preparation for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. 2013-08-31 Guoying Zhang --=====003_Dragon135044421627_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
No, I'm not aware of any IPR that applies to this draft.
 
best,
Guoying Zhang
 
 

From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]
Sent: Saturday, August 10, 2013 2:11 AM
To: draft-ogrcetal-ccamp-flexi-grid-fwk@tools.ietf.org
Cc: ccamp@ietf.org
Subject: Regarding IPR on draft-ogrcetal-ccamp-flexi-grid-fwk

 

Authors, Contributors, (CCAMP)

 

As part of the preparation for WG document adoption:

 

Are you aware of any IPR that applies to draft identified above?

 

  Please state either:

 

  "No, I'm not aware of any IPR that applies to this draft"

  or

  "Yes, I'm aware of IPR that applies to this draft"

 

If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details)?

 

   If yes to the above, please state either:

 

  "Yes, the IPR has been disclosed in compliance with IETF IPR rules"

  or

  "No, the IPR has not been disclosed"

 

  If you answer no, please provide any additional details you think

  appropriate.

 

If you are listed as a document author or contributor please answer the

above by responding to this email regardless of whether or not you are

aware of any relevant IPR.  This document will not advance to the next

stage until a response has been received from each author and listed

contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS

MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list but are not listed as an author or

contributor, we remind you of your obligations under the IETF IPR rules

which encourages you to notify the IETF if you are aware of IPR of

others on an IETF contribution, or to refrain from participating in any

contribution or discussion related to your undisclosed IPR.  For more

information, please see the RFCs listed above and

 

Thank you,

CCAMP WG Chairs

 

PS Please include all listed in the headers of this message in your

response.

 

 

 
2013-08-31
Guoying Zhang
 --=====003_Dragon135044421627_=====--