From daniele.ceccarelli@ericsson.com Tue Oct 1 00:40:42 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3D321F9AC1; Tue, 1 Oct 2013 00:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=0.586, 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 PRDxNCjOud96; Tue, 1 Oct 2013 00:40:36 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AAC3421F9AE7; Tue, 1 Oct 2013 00:40:32 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-e8-524a7c6f2e6d Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 77.23.16099.F6C7A425; Tue, 1 Oct 2013 09:40:31 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Tue, 1 Oct 2013 09:40:31 +0200 From: Daniele Ceccarelli To: Lou Berger , "BELOTTI, SERGIO (SERGIO)" Thread-Topic: I: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt Thread-Index: AQHOvij4F556Cc2zvUSVNC4MiT7tv5nfcKKA Date: Tue, 1 Oct 2013 07:40:30 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4815B8F5@ESESSMB301.ericsson.se> References: <5249EF71.6000906@labn.net> In-Reply-To: <5249EF71.6000906@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.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+JvrW5+jVeQwduLyhZP5txgsVg2Zz+T xcdTb5gsOprfslg8nzOTxWLBmqfsFss2/2Z3YPdofbaX1WPJkp9MHuemfGf0+LCpmc3jy+XP bAGsUVw2Kak5mWWpRfp2CVwZbfNOsBTs6GSs2PZpD2MD45dWxi5GTg4JAROJjy/nMEPYYhIX 7q1n62Lk4hASOMwosfxeBxOEs5hRYu3TQ0BVHBxsAlYSTw75gJgiAskS7VczQUqYBeYySczb NYEdZJCwQKLEjjcrwYaKCCRJXP3VxARhG0lM+3AIrIZFQEVi/uXPYDW8At4SL899BasREqiS eHyxE8zmFNCQ6JuyA+xQRgFZiQm7F4HZzALiEreezGeCOFpAYsme81APiEq8fPyPFcJWlLg6 fTkTyJ3MApoS63fpQ7QqSkzpfsgOsVZQ4uTMJywTGMVmIZk6C6FjFpKOWUg6FjCyrGJkz03M zEkvN9zECIy5g1t+6+5gPHVO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4 pRoYNbRi9GSW3f6We/dYmYUp12bNWbsmxSwMXDVpzoPIxB/rUiXmezKeCnboe9+9oduAW7pO fWOv3xkVf1PpAz6b3IvlHq9e+ztpvpCV7fR2n7gHiQf/He2UvGBjt/v9owsxXo5nFE8ez4vo bnrXp82wOl3gIptrrXyzYs2MixsuTXqafNnDo/ivEktxRqKhFnNRcSIAzAag4IcCAAA= X-Mailman-Approved-At: Tue, 01 Oct 2013 01:21:13 -0700 Cc: "rtg-dir@ietf.org" , CCAMP WG , "Joel M. Halpern" , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] I: R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 07:40:42 -0000 SGkgTG91LA0KDQpObyBubyBubywgbm8gT1NQRiBkaXNjdXNzaW9uIHJlb3BlbmluZy4gVGhlIE9T UEYgZHJhZnRzIGNsZWFybHkgc3RhdGVzIHRoYXQgb25seSBzdXBwb3J0ZWQgcHJpb3JpdGllcyBt dXN0IGJlIGFkdmVydGlzZWQsIHdoYXQgZG9lcyBub3Qgc2F5IGlzIHdoeSAoaS5lLiBmb3Igb3B0 aW1pemF0aW9uKS4gDQpXaXRoIHNlY3Rpb24gOCBhbmQgc2VjdGlvbiAxMCBtb2RpZmllZCBhcyBi ZWxvdywgdGhlcmUgaXMgbm8gbmVlZCB0byBtb2RpZnkgT1NQRiBhcyB0aGUgIndoeSIgaXMgc3Rh dGVkIGluIHRoZSBnYXAtYW5hbHlzaXMgZHJhZnQuDQoNClRyeWluZyB0byBzdW1tYXJpemUuDQpT ZWN0aW9uIDggYXMgeW91IHByb3Bvc2VkOg0KPiA4LiBNYXhpbXVtIExTUCBCYW5kd2lkdGgNCj4g TWF4aW11bSBMU1AgYmFuZHdpZHRoIGlzIGN1cnJlbnRseSBhZHZlcnRpc2VkIHBlciBwcmlvcml0 eSBpbg0KPiB0aGUgY29tbW9uIHBhcnQgb2YgdGhlIElTQ0QuICBTZWN0aW9uIDUgcmV2aWV3cyBz b21lIG9mIHRoZQ0KPiBpbXBsaWNhdGlvbnMgb2YgYWR2ZXJ0aXNpbmcgT1ROIG5ldHdvcmsgaW5m b3JtYXRpb24gdXNpbmcgSVNDRHMsDQo+IGFuZCBpZGVudGlmaWVzIHRoZSBuZWVkIGZvciBhIG1v cmUgb3B0aW1pemVkIHNvbHV0aW9uLg0KPiBXaGlsZSBzdHJpY3RseSBub3QgcmVxdWlyZWQsIHN1 Y2ggYW4gb3B0aW1pemF0aW9uIGVmZm9ydCBzaG91bGQNCj4gYWxzbyBjb25zaWRlciB0aGUgb3B0 aW1pemF0aW9uIG9mIHRoZSBwZXIgcHJpb3JpdHkgbWF4aW11bSBMU1ANCj4gYmFuZHdpZHRoIGFk dmVydGlzZW1lbnQgb2YgYm90aCBmaXhlZCBhbmQgdmFyaWFibGUgT0RVIHR5cGVzLg0KDQpTZWN0 aW9uIDEwIChhcyBwZXIgeW91ciBsYXN0IHByb3Bvc2FsKQ0KPiJbUkZDNDIwMl0gZGVmaW5lcyA4 IHByaW9yaXRpZXMgZm9yIHJlc291cmNlIGF2YWlsYWJpbGl0eQ0KPiBhbmQgdXNhZ2UuIEFzIGRl ZmluZWQsIGVhY2ggaXMgYWR2ZXJ0aXNlZCBpbmRlcGVuZGVudCBvZiB0aGUgbnVtYmVyDQo+IG9m IHByaW9yaXRpZXMgc3VwcG9ydGVkIGJ5IGEgbmV0d29yaywgYW5kIGV2ZW4gdW5zdXBwb3J0ZWQN Cj4gcHJpb3JpdGllcyBhcmUgaW5jbHVkZWQuLiBBcyBpcyB0aGUgY2FzZSBpbiBTZWN0aW9uIDgs IGFkZHJlc3NpbmcgYW55DQo+IGluZWZmaWNpZW5jeSB3aXRoIHN1Y2ggYWR2ZXJ0aXNlbWVudHMg aXMgbm90IHJlcXVpcmVkIHRvIHN1cHBvcnQgT1RODQo+IG5ldHdvcmtzLiAgQnV0IGFueSBzdWNo IGluZWZmaWNpZW5jeSBzaG91bGQgYWxzbyBiZSBjb25zaWRlcmVkIGFzIHBhcnQNCj4gb2YgdGhl IG9wdGltaXphdGlvbiBlZmZvcnQgaWRlbnRpZmllZCBpbiBTZWN0aW9uIDUuIg0KDQpTb3VuZHMg cmVhc29uYWJsZT8NCkJSDQpBdXRob3JzDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+IFNlbnQ6IGx1 bmVkw6wgMzAgc2V0dGVtYnJlIDIwMTMgMjM6MzkNCj4gVG86IEJFTE9UVEksIFNFUkdJTyAoU0VS R0lPKQ0KPiBDYzogSm9lbCBNLiBIYWxwZXJuOyBydGctZGlyQGlldGYub3JnOyBDQ0FNUCBXRzsg ZHJhZnQtaWV0Zi1jY2FtcC1vdG4tZzcwOS0NCj4gaW5mby1tb2RlbC5hbGxAdG9vbHMuaWV0Zi5v cmc7IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEk6IFtSVEctRElSXSBS OiBbQ0NBTVBdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtY2NhbXAtb3RuLQ0KPiBnNzA5LWlu Zm8tbW9kZWwtMTEudHh0DQo+IA0KPiBTZXJnaW8sDQo+IAlTZWUgYmVsb3cuDQo+IA0KPiBPbiA5 LzMwLzIwMTMgMTE6MTUgQU0sIEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKSB3cm90ZToNCj4gPiBM b3UsDQo+ID4gb3VyIGFuc3dlciBpbiBsaW5lIG1hcmtlZCAiYXV0aG9ycyINCj4gPg0KPiA+IFRo YW5rcw0KPiA+DQo+ID4gQXV0aG9ycw0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g LS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBEYW5pZWxlLA0KPiA+DQo+ID4gT24gMDkvMzAvMjAxMyAw OTo1OSBBTSwgRGFuaWVsZSBDZWNjYXJlbGxpIHdyb3RlOg0KPiA+PiBMb3UsIEpvZWwsDQo+ID4+ DQo+ID4+IFRoZSB0ZXh0IHByb3Bvc2VkIHNvdW5kcyBnb29kIGJ1dCBpdCBvbmx5IHN0YXRlcyB0 aGUgcHJvYmxlbSB3aXRob3V0DQo+IGFueSBoaW50IG9uIHRoZSBzb2x1dGlvbnMgKGkuZS4gc2F5 cyB0aGVyZSBpcyBhbiBpbmVmZmljaWVuY3kgYnV0IGRvZXNu4oCZdCBzYXkNCj4gdGhhdCBhZHZl cnRpc2luZyBvbmx5IHN1cHBvcnRlZCBwcmlvcml0aWVzIGlzIGEgd2F5IHRvIGFkZHJlc3Mgc3Vj aA0KPiBpbmVmZmljaWVuY3kpLg0KPiA+PiBUaGVyZSBhcmUgdHdvIG9wdGlvbnM6DQo+ID4NCj4g PiBXZWxsLCB0aGVyZSdzIGFsc28gdGhlIG9wdGlvbiBvZiBkcm9wcGluZyB0aGUgc2VjdGlvbnMu DQo+ID4NCj4gPiBBdXRob3JzPiBhcyBhbHJlYWR5IHNhaWQgVGhlIGJhc2ljIHNjb3BlIG9mIHRo ZSBkcmFmdCBpcyB0byB1bmRlcmxpbmUNCj4gPiBnYXBzLCBhbmQgZXZlbiBpZiB3aGF0IGRlc2Ny aWJlZCBpbiBDaC44IGFuZCAxMCwgZG8gbm90IHByZXZlbnQNCj4gPiByb3V0aW5nIHRvIHdvcmss IGl0IGlzIHN1Z2dlc3RlZCBoZXJlIGFuIHJlcXVpcmVtZW50IGZvciBvcHRpbWl6YXRpb24NCj4g PiBiYXNlZCBvbiBPVE4gcmVxdWlyZW1lbnRzIChlLmcuIG5vIG5lZWQgdG8gYWR2ZXJ0aXNlIGZp eGVkIE9EVQ0KPiA+IGNvbnRhaW5lciBNYXggTFNQIEJXIHNpbmNlIGltcGxpY2l0IGluIHRoZSBz aWduYWwgdHlwZS4pLiBTbywgaW4gb3VyDQo+ID4gb3Bpbmlvbiwgbm8gZHJvcHBpbmcuDQo+ID4N Cj4gPg0KPiA+PiAxLiBJbXByb3ZlIHRoZSB0ZXh0ICh0aGUgTkVXIG9uZSkgc2F5aW5nIGUuZy4g b25seSB0aGUgYWR2ZXJ0aXNlbWVudA0KPiA+PiBvZiBiYW5kd2lkdGggZm9yIHN1cHBvcnRlZCBw cmlvcml0aWVzIGlzIG5lZWRlZA0KPiA+DQo+ID4gSSBhbHdheXMgZmluZCBpdCBlYXNpZXIgdG8g bWFrZSBhIGRlY2lzaW9uIHdoZW4gdGhlIHRyYWRlb2ZmcyBhcmUgY29uY3JldGUuDQo+IENhbiB5 b3UgKGF1dGhvcnMpIHByb3Bvc2UgcmV2aXNlZCB0ZXh0Pw0KPiA+DQo+ID4gQXV0aG9ycz4gIltS RkM0MjAyXSBkZWZpbmVzIDggcHJpb3JpdGllcyBmb3IgcmVzb3VyY2UgYXZhaWxhYmlsaXR5DQo+ ID4gYW5kIHVzYWdlLiBBcyBkZWZpbmVkLCBlYWNoIGlzIGFkdmVydGlzZWQgaW5kZXBlbmRlbnQg b2YgdGhlIG51bWJlciBvZg0KPiA+IHByaW9yaXRpZXMgc3VwcG9ydGVkIGJ5IGEgbmV0d29yayB2 cy4gdG8gYWR2ZXJ0aXNlIG9ubHkgdGhlDQo+ID4gaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUg cmVhbGx5IHN1cHBvcnRlZCBwcmlvcml0aWVzIGFzIHBvc3NpYmxlDQo+ID4gb3B0aW1pemF0aW9u IGltcHJvdmVtZW50LiBBcyBpcyB0aGUgY2FzZSBpbiBTZWN0aW9uIDgsIGFkZHJlc3NpbmcgYW55 DQo+ID4gaW5lZmZpY2llbmN5IHdpdGggc3VjaCBhZHZlcnRpc2VtZW50cyBpcyBub3QgcmVxdWly ZWQgdG8gc3VwcG9ydCBPVE4NCj4gPiBuZXR3b3Jrcy4gIEJ1dCBhbnkgc3VjaCBpbmVmZmljaWVu Y3kgc2hvdWxkIGFsc28gYmUgY29uc2lkZXJlZCBhcyBwYXJ0DQo+ID4gb2YgdGhlIG9wdGltaXph dGlvbiBlZmZvcnQgaWRlbnRpZmllZCBpbiBTZWN0aW9uIDUuIg0KPiA+DQo+IA0KPiBIb3cgYWJv dXQ6DQo+IE9MRA0KPiAgIEFzIGRlZmluZWQsIGVhY2ggaXMgYWR2ZXJ0aXNlZCBpbmRlcGVuZGVu dCBvZiB0aGUgbnVtYmVyDQo+ICAgb2YgcHJpb3JpdGllcyBzdXBwb3J0ZWQgYnkgYSBuZXR3b3Jr IHZzLiB0byBhZHZlcnRpc2Ugb25seSB0aGUNCj4gICBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRo ZSByZWFsbHkgc3VwcG9ydGVkIHByaW9yaXRpZXMgYXMgcG9zc2libGUNCj4gICBvcHRpbWl6YXRp b24gaW1wcm92ZW1lbnQuDQo+IE5FVw0KPiAgIEFzIGRlZmluZWQsIGVhY2ggaXMgYWR2ZXJ0aXNl ZCBpbmRlcGVuZGVudCBvZiB0aGUgbnVtYmVyDQo+ICAgb2YgcHJpb3JpdGllcyBzdXBwb3J0ZWQg YnkgYSBuZXR3b3JrLCBhbmQgZXZlbiB1bnN1cHBvcnRlZA0KPiAgIHByaW9yaXRpZXMgYXJlIGlu Y2x1ZGVkLg0KPiANCj4gDQo+ID4+IDIuIEFkb3B0IHRoZSBORVcgdGV4dCBhcyBpdCBpcyBhbmQg bW92ZSB0aGUgcmVtYWluaW5nIHBhcnQgb2YgdGhlIHRleHQgdG8NCj4gdGhlIE9TUEYgZHJhZnQg KHdoZXJlIHdlIHNheSBlLmcuIHRoYXQgb25seSBiYW5kd2lkdGggZm9yIHN1cHBvcnRlcg0KPiBw cmlvcml0aWVzIG5lZWQgdG8gYmUgYWR2ZXJ0aXNlZCBidXQgZG9uJ3Qgc2F5IHdoeSkuDQo+ID4+ DQo+ID4gRG9lc24ndCB0aGUgT1NQRiBkcmFmdCBhbHJlYWR5IGFscmVhZHkgZG8gd2hhdCB5b3Ug c2F5LCBpLmUuLCBhZHZlcnRpc2Ugb25seQ0KPiB1c2VkIHByaW9yaXRpZXMuIFdoYXQgc3BlY2lm aWMgdGV4dCBhcmUgeW91IHByb3Bvc2luZyB0byBhZGQ/DQo+ID4+DQo+ID4gQXV0aG9ycz4gTm8s IGl0IGRvZXNuJ3QuDQo+IA0KPiBTbyB0aGUgT1NQRiBkcmFmdCBjdXJyZW50bHkgc2F5cyB0aGF0 IGFsbCBwcmlvcml0aWVzIGFyZSBhZHZlcnRpc2VkPw0KPiBSZWFsbHk/Pz8/ICBJZiBzbyBhZGRp bmcgdGhpcyBuZXcgdGV4dCBkb2VzIGxpdHRsZSB0byBjaGFuZ2UgdGhpcy4gIEFyZSB5b3UgcmVh bGx5DQo+IGFkdm9jYXRpbmcgcmVvcGVuaW5nIGRpc2N1c3Npb24gb24gdGhlIE9TUEYgZHJhZnQg aW4gYWRkaXRpb24gdG8gdGhpcyBvbmU/DQo+IA0KPiBMb3UNCj4gDQo+ID4gLi4uIFRleHQgcHJv cG9zZWQgaXMgdGhlIG9sZCBvbmUgdGhhdCB0b3RhbGx5IGFkZHJlc3MgZXhwbGFuYXRpb24gaW4g b3VyIHZpZXcNCj4gOiIgW1JGQzQyMDJdIGRlZmluZXMgOCBwcmlvcml0aWVzIGZvciByZXNvdXJj ZSBhdmFpbGFiaWxpdHkgYW5kIHVzYWdlLiBBbGwgb2YNCj4gdGhlbSBoYXZlIHRvIGJlIGFkdmVy dGlzZWQgaW5kZXBlbmRlbnRseSBvbiB0aGUgbnVtYmVyIG9mIHByaW9yaXRpZXMNCj4gc3VwcG9y dGVkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbi5Db25zaWRlcmluZyB0aGF0IHRoZSBhZHZlcnRpc2Vt ZW50IG9mIGFsbA0KPiB0aGUgZGlmZmVyZW50IHN1cHBvcnRlZCBzaWduYWwgdHlwZXMgd2lsbCBv cmlnaW5hdGUgbGFyZ2UgTFNBcywgaXQgaXMgYWR2aXNlZCB0bw0KPiBhZHZlcnRpc2Ugb25seSB0 aGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgcmVhbGx5IHN1cHBvcnRlZCBwcmlvcml0aWVz Lg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IExvdQ0KPiA+DQo+ID4+IFJlIGFsbCB0aGUgb3RoZXIg Y29tbWVudHMvc3VnZ2VzdGlvbiB3ZSdyZSBvayBhbmQgd2lsbCBmaXggdGhlbSBhcw0KPiBzdWdn ZXN0ZWQuDQo+ID4+DQo+ID4+IEJSDQo+ID4+IEF1dGhvcnMNCj4gPj4NCj4gPj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdl ckBsYWJuLm5ldF0NCj4gPj4+IFNlbnQ6IHZlbmVyZMOsIDI3IHNldHRlbWJyZSAyMDEzIDIxOjU1 DQo+ID4+PiBUbzogSm9lbCBNLiBIYWxwZXJuDQo+ID4+PiBDYzogcnRnLWRpckBpZXRmLm9yZzsg Q0NBTVAgV0c7IGRyYWZ0LWlldGYtY2NhbXAtb3RuLWc3MDktaW5mby0NCj4gPj4+IG1vZGVsLmFs bEB0b29scy5pZXRmLm9yZzsgQkVMT1RUSSwgU0VSR0lPIFwoU0VSR0lPXCk7DQo+ID4+PiBydGct YWRzQHRvb2xzLmlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBSZTogW1JURy1ESVJdIFI6IFtDQ0FN UF0gUnRnRGlyIHJldmlldzoNCj4gPj4+IGRyYWZ0LWlldGYtY2NhbXAtb3RuLWc3MDktIGluZm8t bW9kZWwtMTEudHh0DQo+ID4+Pg0KPiA+Pj4gR3JlYXQuIFNvIHlvdSBhbmQgSSBhcmUgaW4gYWdy ZWVtZW50LiBXZSdsbCBzZWUgd2hhdCB0aGUgYXV0aG9ycw0KPiA+Pj4gaGF2ZSB0byBzYXkuLi4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4gT24gMzoyNnBtLCBTZXB0ZW1iZXIgMjcsIDIwMTMsIEpvZWwg TS4gSGFscGVybiB3cm90ZToNCj4gPj4+PiBUaGUgcHJvcG9zZWQgYWx0ZXJuYXRpdmUgdGV4dCB3 b3VsZCBzdWZmaWNlLCBhbHRob3VnaCBwZXJzb25hbGx5IEkNCj4gPj4+PiB3b3VsZCBqdXN0IHJl bW92ZSB0aGUgdHdvIHNlY3Rpb25zLg0KPiA+Pj4+DQo+ID4+Pj4gWW91cnMsDQo+ID4+Pj4gSm9l bA0KPiA+Pj4+DQo+ID4+Pj4gT24gOS8yNy8xMyAzOjAwIFBNLCBMb3UgQmVyZ2VyIHdyb3RlOg0K PiA+Pj4+PiBKb2VsLA0KPiA+Pj4+PiBEb2VzIHRoZSBwcm9wb3NlZCBhbHRuZXJhdGUgdGV4dCBh ZGRyZXNzIHlvdXIgY29tbWVudCAoYXNzdW1pbmcNCj4gPj4+Pj4gdGhlIGF1dGhvcidzIHdhbnQg dG8ga2VlcCB0aGUgc2VjdGlvbnMpPyAgSWYgbm90LCBjYW4geW91IHN1Z2dlc3QNCj4gY2hhbmdl cz8NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhhbmtzLA0KPiA+Pj4+PiBMb3UNCj4gPj4+Pj4NCj4gPj4+ Pj4gT24gMDkvMjcvMjAxMyAwMjozMCBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiA+Pj4+ Pj4gTG91LCB0aGFua3MgZm9yIHN0ZXBwaW5nIGluLg0KPiA+Pj4+Pj4gV2l0aCB5b3VyIGV4cGxh bmF0aW9uIEkgY2FuIGxpdmUgd2l0aCB0aGUgTFNQIHRleHQgYXMgaXQgaXMuDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gSSBsb29rIGZvcndhcmQgdG8gZnVydGhlciBjb252ZXJzYXRpb24gb24gdGhlIG90 aGVyIHBvaW50Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFlvdXJzLA0KPiA+Pj4+Pj4gSm9lbA0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+IE9uIDkvMjcvMTMgMTozNyBQTSwgTG91IEJlcmdlciB3cm90ZToNCj4g Pj4+Pj4+PiBKb2VsL0F1dGhvcnMsDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBJIHRob3VnaHQgSSBt aWdodCBqdW1wIGluIG9uIHR3byBwb2ludHM6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+ Pj4+IE9uIDkvMjYvMjAxMyA0OjUwIEFNLCBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykgd3JvdGU6 DQo+ID4+Pj4+Pj4+IEhlbGxvIEpvZWwsDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IHRoYW5rcyBm b3IgeW91ciBjb21tZW50cy4NCj4gPj4+Pj4+Pj4gQmVsb3cgaW4gbGluZSBvdXIgcmVwbHksIG1h cmtlZCAiYXV0aG9ycyIuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAuLi4NCj4g Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBHaXZlbiB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgYWJvdXQgbWFw cGluZyB0byBHLjcwOSwgaXQgaXMNCj4gPj4+Pj4+Pj4gdW5jbGVhciB3aGF0IGlzIGludGVuZGVk IGJ5IHRoZSB1c2FnZSBvZiAiTFNQIi4gIE15IGd1ZXNzIGlzDQo+ID4+Pj4+Pj4+IHRoYXQgaXQg aXMgaW50ZW5kZWQgdG8gbWVhbiBMYWJlbCBTd2l0Y2ggUGF0aHMgc2V0IHVwIGJ5IEdNUExTDQo+ ID4+Pj4+Pj4+IHRvIGNhcnJ5IE9UVS9VRFUgZWxlbWVudHMuDQo+ID4+Pj4+Pj4+IEl0IHNob3Vs ZCBiZSBzdGF0ZWQgZXhwbGljaXRseS4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gQXV0aG9ycz4g V2UgY2FuIHNwZWNpZnkgdGhpcyBhcyB5b3Ugc3VnZ2VzdCBldmVuIGlmIHdlDQo+ID4+Pj4+Pj4+ IEF1dGhvcnM+IGNvbnNpZGVyZWQgbm90DQo+ID4+Pj4+Pj4+IG5lY2Vzc2FyeSB0byBzcGVjaWZ5 IHRoZSB1c2FnZSBvZiBMU1AgaW4gcmVsYXRpb24gdG8gZGF0YSBwbGFuZQ0KPiA+Pj4+Pj4+PiBz cGVjaWZpYy4gRW5jb2RpbmcgdHlwZSBzaG91bGQgY29wZSB3aXRoIHRoaXMgaXNzdWUuDQo+ID4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBKb2VsLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g SSBzdXNwZWN0IHRoYXQgdGhlIHVzYWdlIG9mIExTUCBpbiB0aGUgYWJzZW5jZSBvZiB0aGUgTVBM UyBkYXRhDQo+ID4+Pj4+Pj4gcGxhbmUgaXMgd2hhdCdzIGNhdXNpbmcgY29uZnVzaW9uIGhlcmUu ICBJcyB0aGlzIGNvcnJlY3Q/DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBJZiBzbywgSSB0aGluayBH TVBMUyByZWZlcmVuY2luZyBjb250cm9sbGVkIGRhdGEgcGF0aHMNCj4gPj4+Pj4+PiAoY2lyY3Vp dHMpIGJ5IHRoZSBjb21tb24gbmFtZSBvZiBMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApIGlzDQo+ ID4+Pj4+Pj4gc3VmZmljaWVudGx5IGVzdGFibGlzaGVkIHRoYXQgdGhpcyBkb2N1bWVudCBkb2Vz bid0IG5lZWQgdG8NCj4gPj4+Pj4+PiByZXZpc2l0IGl0LiAgSW4gYW55IGNhc2UsIHRoZSBkb2N1 bWVudCBhbHJlYWR5IHByb3ZpZGVzIGNvbnRleHQ6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBHTVBM UyByb3V0aW5nIGFuZCBzaWduYWxpbmcsIGFzIGRlZmluZWQgYnkgW1JGQzQyMDNdLCBbUkZDNTMw N10sDQo+ID4+Pj4+Pj4gW1JGQzM0NzNdIGFuZCBbUkZDNDMyOF0sIHByb3ZpZGVzIHRoZSBtZWNo YW5pc21zIGZvciBiYXNpYw0KPiBHTVBMUw0KPiA+Pj4+Pj4+IGNvbnRyb2wgb2YgT1ROIG5ldHdv cmtzIGJhc2VkIG9uIHRoZSAyMDAxIHJldmlzaW9uIG9mIHRoZSBHLjcwOQ0KPiA+Pj4+Pj4+IHNw ZWNpZmljYXRpb24uDQo+ID4+Pj4+Pj4gYW5kDQo+ID4+Pj4+Pj4gQmFja2dyb3VuZCBpbmZvcm1h dGlvbiBhbmQgYSBmcmFtZXdvcmsgZm9yIHRoZSBHTVBMUyBwcm90b2NvbA0KPiA+Pj4+Pj4+IGV4 dGVuc2lvbnMgbmVlZCB0byBzdXBwb3J0IFtHLjcwOS0yMDEyXSBpcyBwcm92aWRlZCBpbiBbT1RO LUZXS10uDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBbT1ROLUZXS10gaGFzIHRoZSBvZnRlbiByZXBl YXRlZCBjb25jZXB0Og0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gR01QTFMgZXh0ZW5kcyBNdWx0aS1Q cm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIHRvDQo+IGVuY29tcGFzcw0KPiA+Pj4+Pj4+ IHRpbWUgZGl2aXNpb24gbXVsdGlwbGV4aW5nIChURE0pIG5ldHdvcmtzIChlLmcuLCBTeW5jaHJv bm91cw0KPiA+Pj4+Pj4+IE9wdGljYWwgTkVUd29yayAoU09ORVQpLyBTeW5jaHJvbm91cyBEaWdp dGFsIEhpZXJhcmNoeSAoU0RIKSwNCj4gPj4+Pj4+PiBQbGVzaW9jaHJvbm91cyBEaWdpdGFsIEhp ZXJhcmNoeSAoUERIKSwgYW5kIEcuNzA5IHN1Yi1sYW1iZGEpLA0KPiA+Pj4+Pj4+IGxhbWJkYSBz d2l0Y2hpbmcgb3B0aWNhbCBuZXR3b3JrcywgYW5kIHNwYXRpYWwgc3dpdGNoaW5nIChlLmcuLA0K PiA+Pj4+Pj4+IGluY29taW5nIHBvcnQgb3IgZmliZXIgdG8gb3V0Z29pbmcgcG9ydCBvciBmaWJl cikuICBUaGUgR01QTFMNCj4gPj4+Pj4+PiBhcmNoaXRlY3R1cmUgaXMgcHJvdmlkZWQgaW4gW1JG QzM5NDVdLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSWYgdGhpcyBkb2Vzbid0IGNvdmVyIHRoZSBj b21tZW50LCBjYW4geW91IGVsYWJvcmF0ZSBvbiB3aGF0IHlvdQ0KPiA+Pj4+Pj4+IHdhbnQgZXhw bGljaXRseSBzdGF0ZWQ/DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gLi4uDQo+ID4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+IFNlY3Rpb24gOCBvbiBNYXhpbXVtIExTUCBCYW5kd2RpdGggc2VlbXMgdG8gYmUg b2JqZWN0aW5nIHRvDQo+IHRvbw0KPiA+Pj4+Pj4+PiBtdWNoIGluZm9ybWF0aW9uIGxlYWRpbmcg dG8gYSAid2FzdGUgb2YgYml0cyIuICBXaGlsZSBwb3NzaWJseQ0KPiA+Pj4+Pj4+PiBvZiBpbnRl cmVzdCB0byB0aGUgV0csIHRoYXQgZG9lcyBub3Qgc2VlbSB0byBmaXQgYSBnYXANCj4gPj4+IGFu YWx5c2lzLg0KPiA+Pj4+Pj4+PiBTaW1pbGFybHksIHNlY3Rpb24gMTAgb24gUHJpb3JpdHkgU3Vw cG9ydCByZWFkcyBhcw0KPiA+Pj4+Pj4+PiBpbXBsZW1lbnRhdGlvbiBhZHZpY2UgcmF0aGVyIHRo YW4gYSBnYXAgbmVlZGluZyBwcm90b2NvbA0KPiBjaGFuZ2VzLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+PiBBdXRob3JzPiBUaGUgYmFzaWMgc2NvcGUgb2YgdGhlIGRyYWZ0IGlzIHRvIHVuZGVybGlu ZSBnYXBzLCBhbmQNCj4gPj4+Pj4+Pj4gQXV0aG9ycz4gZXZlbg0KPiA+Pj4+Pj4+PiBpZiB3aGF0 IGRlc2NyaWJlZCBpbiBDaC44IGFuZCAxMCwgZG8gbm90IHByZXZlbnQgcm91dGluZyB0bw0KPiA+ Pj4+Pj4+PiB3b3JrICwgaXQgaXMgc3VnZ2VzdGVkIGhlcmUgYW4gcmVxdWlyZW1lbnQgZm9yIG9w dGltaXphdGlvbg0KPiA+Pj4+Pj4+PiBiYXNlZCBvbiBPVE4gcmVxdWlyZW1lbnRzIChlLmcuIG5v IG5lZWQgdG8gYWR2ZXJ0aXNlIGZpeGVkIE9EVQ0KPiA+Pj4+Pj4+PiBjb250YWluZXIgTWF4IExT UCBCVyBzaW5jZSBpbXBsaWNpdCBpbiB0aGUgc2lnbmFsIHR5cGUuKQ0KPiA+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+DQo+ID4+Pj4+Pj4gQXV0aG9ycywNCj4gPj4+Pj4+PiBJIGNvbXBsZXRlbHkgYWdyZWUg d2l0aCBKb2VsIG9uIHRoaXMgcG9pbnQsIGZ1cnRoZXJtb3JlIHNlY3Rpb25zDQo+ID4+Pj4+Pj4g MTAgYW5kDQo+ID4+Pj4+Pj4gOCBvdmVybGFwLiAgT25lIGFwcHJvYWNoIHRvIGFkZHJlc3MgaGlz IHBvaW50IHdvdWxkIGJlIHRvIHNpbXBseQ0KPiA+Pj4+Pj4+IGRyb3AgYm90aCBzZWN0aW9ucy4g IEFuIGFsdGVybmF0aXZlIGlzIHRyeSB0byByZXBocmFzZSB0aGVtIHRvDQo+ID4+Pj4+Pj4gYWRk cmVzcyBKb2VsJ3MgcG9pbnRzLiAgSSd2ZSB0YWtlbiBhIHBhc3MgYXQgdGhlIGxhdHRlciBiZWxv dywNCj4gPj4+Pj4+PiBidXQgd29uJ3Qgb2JqZWN0IGlmIHRoZSBhdXRob3JzIHByZWZlciB0aGUg Zm9ybWVyLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSGVyZSdzIGEgc3VnZ2VzdGVkIHdvcmRpbmcg Y2hhbmdlIGlmIHlvdSBjaG9vc2UgdG8ga2VlcCB0aGUNCj4gPj4+IHNlY3Rpb25zOg0KPiA+Pj4+ Pj4+IE9MRDoNCj4gPj4+Pj4+PiA4LiBNYXhpbXVtIExTUCBCYW5kd2lkdGgNCj4gPj4+Pj4+Pg0K PiA+Pj4+Pj4+IE1heGltdW0gTFNQIGJhbmR3aWR0aCBpcyBjdXJyZW50bHkgYWR2ZXJ0aXNlZCBp biB0aGUgY29tbW9uDQo+IHBhcnQNCj4gPj4+Pj4+PiBvZiB0aGUgSVNDRCBhbmQgYWR2ZXJ0aXNl ZCBwZXIgcHJpb3JpdHksIHdoaWxlIGluIE9UTiBuZXR3b3Jrcw0KPiA+Pj4+Pj4+IGl0IGlzIG9u bHkgcmVxdWlyZWQgZm9yIE9EVWZsZXggYWR2ZXJ0aXNpbmcuICBUaGlzIGxlYWRzIHRvIGENCj4g Pj4+Pj4+PiBzaWduaWZpY2FudCB3YXN0ZSBvZiBiaXRzIGluc2lkZSBlYWNoIExTQS4NCj4gPj4+ Pj4+PiBhbmQNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IE5FVw0KPiA+Pj4+Pj4+IDguIE1heGltdW0g TFNQIEJhbmR3aWR0aA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gTWF4aW11bSBMU1AgYmFuZHdpZHRo IGlzIGN1cnJlbnRseSBhZHZlcnRpc2VkIHBlciBwcmlvcml0eSBpbg0KPiA+Pj4+Pj4+IHRoZSBj b21tb24gcGFydCBvZiB0aGUgSVNDRC4gIFNlY3Rpb24gNSByZXZpZXdzIHNvbWUgb2YgdGhlDQo+ ID4+Pj4+Pj4gaW1wbGljYXRpb25zIG9mIGFkdmVydGlzaW5nIE9UTiBuZXR3b3JrIGluZm9ybWF0 aW9uIHVzaW5nIElTQ0RzLA0KPiA+Pj4+Pj4+IGFuZCBpZGVudGlmaWVzIHRoZSBuZWVkIGZvciBh IG1vcmUgb3B0aW1pemVkIHNvbHV0aW9uLg0KPiA+Pj4+Pj4+IFdoaWxlIHN0cmljdGx5IG5vdCBy ZXF1aXJlZCwgc3VjaCBhbiBvcHRpbWl6YXRpb24gZWZmb3J0IHNob3VsZA0KPiA+Pj4+Pj4+IGFs c28gY29uc2lkZXIgdGhlIG9wdGltaXphdGlvbiBvZiB0aGUgcGVyIHByaW9yaXR5IG1heGltdW0g TFNQDQo+ID4+Pj4+Pj4gYmFuZHdpZHRoIGFkdmVydGlzZW1lbnQgb2YgYm90aCBmaXhlZCBhbmQg dmFyaWFibGUgT0RVIHR5cGVzLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT0xEDQo+ID4+Pj4+Pj4g MTAuIFByaW9yaXR5IFN1cHBvcnQNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFtSRkM0MjAyXSBkZWZp bmVzIDggcHJpb3JpdGllcyBmb3IgcmVzb3VyY2UgYXZhaWxhYmlsaXR5IGFuZCB1c2FnZS4NCj4g Pj4+Pj4+PiBBbGwgb2YgdGhlbSBoYXZlIHRvIGJlIGFkdmVydGlzZWQgaW5kZXBlbmRlbnRseSBv biB0aGUgbnVtYmVyIG9mDQo+ID4+Pj4+Pj4gcHJpb3JpdGllcyBzdXBwb3J0ZWQgYnkgdGhlIGlt cGxlbWVudGF0aW9uLiAgQ29uc2lkZXJpbmcgdGhhdA0KPiA+Pj4+Pj4+IHRoZSBhZHZlcnRpc2Vt ZW50IG9mIGFsbCB0aGUgZGlmZmVyZW50IHN1cHBvcnRlZCBzaWduYWwgdHlwZXMNCj4gPj4+Pj4+ PiB3aWxsIG9yaWdpbmF0ZSBsYXJnZSBMU0FzLCBpdCBpcyBhZHZpc2VkIHRvIGFkdmVydGlzZSBv bmx5IHRoZQ0KPiA+Pj4+Pj4+IGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhlIHJlYWxseSBzdXBw b3J0ZWQgcHJpb3JpdGllcy4NCj4gPj4+Pj4+PiBORVcNCj4gPj4+Pj4+PiAxMC4gUHJpb3JpdHkg U3VwcG9ydA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gW1JGQzQyMDJdIGRlZmluZXMgOCBwcmlvcml0 aWVzIGZvciByZXNvdXJjZSBhdmFpbGFiaWxpdHkgYW5kIHVzYWdlLg0KPiA+Pj4+Pj4+IEFzIGRl ZmluZWQsIGVhY2ggaXMgYWR2ZXJ0aXNlZCBpbmRlcGVuZGVudCBvZiB0aGUgbnVtYmVyIG9mDQo+ ID4+Pj4+Pj4gcHJpb3JpdGllcyBzdXBwb3J0ZWQgYnkgYSBuZXR3b3JrLiAgQXMgaXMgdGhlIGNh c2UgaW4gU2VjdGlvbiA4LA0KPiA+Pj4+Pj4+IGFkZHJlc3NpbmcgYW55IGluZWZmaWNpZW5jeSB3 aXRoIHN1Y2ggYWR2ZXJ0aXNlbWVudHMgaXMgbm90DQo+ID4+Pj4+Pj4gcmVxdWlyZWQgdG8gc3Vw cG9ydCBPVE4gbmV0d29ya3MuICBCdXQgYW55IHN1Y2ggaW5lZmZpY2llbmN5DQo+ID4+Pj4+Pj4g c2hvdWxkIGFsc28gYmUgY29uc2lkZXJlZCBhcyBwYXJ0IG9mIHRoZSBvcHRpbWl6YXRpb24gZWZm b3J0DQo+ID4+Pj4+Pj4gaWRlbnRpZmllZCBpbiBTZWN0aW9uIDUuDQo+ID4+Pj4+Pj4NCj4gPj4+ Pj4+PiBBbHNvIHBsZWFzZSByZXBsYWNlICJCdyIgd2l0aCAiQmFuZHdpZHRoIiBpbiB0aGUgZG9j dW1lbnQuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBMb3UNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4NCj4g Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+DQo= From lberger@labn.net Tue Oct 1 05:26:59 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E6011E80FF for ; Tue, 1 Oct 2013 05:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.917 X-Spam-Level: X-Spam-Status: No, score=-101.917 tagged_above=-999 required=5 tests=[AWL=0.348, 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 nbtvtGMxR0Hl for ; Tue, 1 Oct 2013 05:26:54 -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 297D911E810F for ; Tue, 1 Oct 2013 05:26:46 -0700 (PDT) Received: (qmail 15887 invoked by uid 0); 1 Oct 2013 12:26:23 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.mail.unifiedlayer.com with SMTP; 1 Oct 2013 12:26:23 -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=rObsru/baLun7zPRVp8kg/saUlTLoLAxQCKJFauT5RI=; b=QB1E3MG7ufxZLDbHgTrrhYMVnjtbmHTZiV3STgR+lKFHGg6RCQIYS33AT6oZFH2XpOnJdlAi5xtYjrBrGXtZ5guaPJT6EdhJWvpLZ8Y9fJJakSdLF3zfybG93b33eFXv; Received: from box313.bluehost.com ([69.89.31.113]:36759 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VQz1z-0001hl-GK; Tue, 01 Oct 2013 06:26:23 -0600 Message-ID: <524ABF6E.2080801@labn.net> Date: Tue, 01 Oct 2013 08:26:22 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Daniele Ceccarelli , "BELOTTI, SERGIO (SERGIO)" References: <5249EF71.6000906@labn.net> <4A1562797D64E44993C5CBF38CF1BE4815B8F5@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4815B8F5@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 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: "rtg-dir@ietf.org" , CCAMP WG , "Joel M. Halpern" , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] I: R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 12:26:59 -0000 Daniele, > Sounds reasonable? While I still like option 3, I can live with the revised text. Joel, Is the revised text acceptable? Lou On 10/01/2013 03:40 AM, Daniele Ceccarelli wrote: > Hi Lou, > > No no no, no OSPF discussion reopening. The OSPF drafts clearly states that only supported priorities must be advertised, what does not say is why (i.e. for optimization). > With section 8 and section 10 modified as below, there is no need to modify OSPF as the "why" is stated in the gap-analysis draft. > > Trying to summarize. > Section 8 as you proposed: >> 8. Maximum LSP Bandwidth >> Maximum LSP bandwidth is currently advertised per priority in >> the common part of the ISCD. Section 5 reviews some of the >> implications of advertising OTN network information using ISCDs, >> and identifies the need for a more optimized solution. >> While strictly not required, such an optimization effort should >> also consider the optimization of the per priority maximum LSP >> bandwidth advertisement of both fixed and variable ODU types. > > Section 10 (as per your last proposal) >> "[RFC4202] defines 8 priorities for resource availability >> and usage. As defined, each is advertised independent of the number >> of priorities supported by a network, and even unsupported >> priorities are included.. As is the case in Section 8, addressing any >> inefficiency with such advertisements is not required to support OTN >> networks. But any such inefficiency should also be considered as part >> of the optimization effort identified in Section 5." > > Sounds reasonable? > BR > Authors > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: lunedì 30 settembre 2013 23:39 >> To: BELOTTI, SERGIO (SERGIO) >> Cc: Joel M. Halpern; rtg-dir@ietf.org; CCAMP WG; draft-ietf-ccamp-otn-g709- >> info-model.all@tools.ietf.org; rtg-ads@tools.ietf.org >> Subject: Re: I: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn- >> g709-info-model-11.txt >> >> Sergio, >> See below. >> >> On 9/30/2013 11:15 AM, BELOTTI, SERGIO (SERGIO) wrote: >>> Lou, >>> our answer in line marked "authors" >>> >>> Thanks >>> >>> Authors >>> >>> >>> ---------------------------------------------------------------------- >>> ----------------- >>> Daniele, >>> >>> On 09/30/2013 09:59 AM, Daniele Ceccarelli wrote: >>>> Lou, Joel, >>>> >>>> The text proposed sounds good but it only states the problem without >> any hint on the solutions (i.e. says there is an inefficiency but doesn’t say >> that advertising only supported priorities is a way to address such >> inefficiency). >>>> There are two options: >>> >>> Well, there's also the option of dropping the sections. >>> >>> Authors> as already said The basic scope of the draft is to underline >>> gaps, and even if what described in Ch.8 and 10, do not prevent >>> routing to work, it is suggested here an requirement for optimization >>> based on OTN requirements (e.g. no need to advertise fixed ODU >>> container Max LSP BW since implicit in the signal type.). So, in our >>> opinion, no dropping. >>> >>> >>>> 1. Improve the text (the NEW one) saying e.g. only the advertisement >>>> of bandwidth for supported priorities is needed >>> >>> I always find it easier to make a decision when the tradeoffs are concrete. >> Can you (authors) propose revised text? >>> >>> Authors> "[RFC4202] defines 8 priorities for resource availability >>> and usage. As defined, each is advertised independent of the number of >>> priorities supported by a network vs. to advertise only the >>> information related to the really supported priorities as possible >>> optimization improvement. As is the case in Section 8, addressing any >>> inefficiency with such advertisements is not required to support OTN >>> networks. But any such inefficiency should also be considered as part >>> of the optimization effort identified in Section 5." >>> >> >> How about: >> OLD >> As defined, each is advertised independent of the number >> of priorities supported by a network vs. to advertise only the >> information related to the really supported priorities as possible >> optimization improvement. >> NEW >> As defined, each is advertised independent of the number >> of priorities supported by a network, and even unsupported >> priorities are included. >> >> >>>> 2. Adopt the NEW text as it is and move the remaining part of the text to >> the OSPF draft (where we say e.g. that only bandwidth for supporter >> priorities need to be advertised but don't say why). >>>> >>> Doesn't the OSPF draft already already do what you say, i.e., advertise only >> used priorities. What specific text are you proposing to add? >>>> >>> Authors> No, it doesn't. >> >> So the OSPF draft currently says that all priorities are advertised? >> Really???? If so adding this new text does little to change this. Are you really >> advocating reopening discussion on the OSPF draft in addition to this one? >> >> Lou >> >>> ... Text proposed is the old one that totally address explanation in our view >> :" [RFC4202] defines 8 priorities for resource availability and usage. All of >> them have to be advertised independently on the number of priorities >> supported by the implementation.Considering that the advertisement of all >> the different supported signal types will originate large LSAs, it is advised to >> advertise only the information related to the really supported priorities. >>> >>> Thanks, >>> Lou >>> >>>> Re all the other comments/suggestion we're ok and will fix them as >> suggested. >>>> >>>> BR >>>> Authors >>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: venerdì 27 settembre 2013 21:55 >>>>> To: Joel M. Halpern >>>>> Cc: rtg-dir@ietf.org; CCAMP WG; draft-ietf-ccamp-otn-g709-info- >>>>> model.all@tools.ietf.org; BELOTTI, SERGIO \(SERGIO\); >>>>> rtg-ads@tools.ietf.org >>>>> Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: >>>>> draft-ietf-ccamp-otn-g709- info-model-11.txt >>>>> >>>>> Great. So you and I are in agreement. We'll see what the authors >>>>> have to say... >>>>> >>>>> >>>>> On 3:26pm, September 27, 2013, Joel M. Halpern wrote: >>>>>> The proposed alternative text would suffice, although personally I >>>>>> would just remove the two sections. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 9/27/13 3:00 PM, Lou Berger wrote: >>>>>>> Joel, >>>>>>> Does the proposed altnerate text address your comment (assuming >>>>>>> the author's want to keep the sections)? If not, can you suggest >> changes? >>>>>>> >>>>>>> Thanks, >>>>>>> Lou >>>>>>> >>>>>>> On 09/27/2013 02:30 PM, Joel M. Halpern wrote: >>>>>>>> Lou, thanks for stepping in. >>>>>>>> With your explanation I can live with the LSP text as it is. >>>>>>>> >>>>>>>> I look forward to further conversation on the other point. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 9/27/13 1:37 PM, Lou Berger wrote: >>>>>>>>> Joel/Authors, >>>>>>>>> >>>>>>>>> I thought I might jump in on two points: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote: >>>>>>>>>> Hello Joel, >>>>>>>>>> >>>>>>>>>> thanks for your comments. >>>>>>>>>> Below in line our reply, marked "authors". >>>>>>>>>> >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>>> Given that this document is about mapping to G.709, it is >>>>>>>>>> unclear what is intended by the usage of "LSP". My guess is >>>>>>>>>> that it is intended to mean Label Switch Paths set up by GMPLS >>>>>>>>>> to carry OTU/UDU elements. >>>>>>>>>> It should be stated explicitly. >>>>>>>>>> >>>>>>>>>> Authors> We can specify this as you suggest even if we >>>>>>>>>> Authors> considered not >>>>>>>>>> necessary to specify the usage of LSP in relation to data plane >>>>>>>>>> specific. Encoding type should cope with this issue. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Joel, >>>>>>>>> >>>>>>>>> I suspect that the usage of LSP in the absence of the MPLS data >>>>>>>>> plane is what's causing confusion here. Is this correct? >>>>>>>>> >>>>>>>>> If so, I think GMPLS referencing controlled data paths >>>>>>>>> (circuits) by the common name of Label Switched Path (LSP) is >>>>>>>>> sufficiently established that this document doesn't need to >>>>>>>>> revisit it. In any case, the document already provides context: >>>>>>>>> >>>>>>>>> GMPLS routing and signaling, as defined by [RFC4203], [RFC5307], >>>>>>>>> [RFC3473] and [RFC4328], provides the mechanisms for basic >> GMPLS >>>>>>>>> control of OTN networks based on the 2001 revision of the G.709 >>>>>>>>> specification. >>>>>>>>> and >>>>>>>>> Background information and a framework for the GMPLS protocol >>>>>>>>> extensions need to support [G.709-2012] is provided in [OTN-FWK]. >>>>>>>>> >>>>>>>>> [OTN-FWK] has the often repeated concept: >>>>>>>>> >>>>>>>>> GMPLS extends Multi-Protocol Label Switching (MPLS) to >> encompass >>>>>>>>> time division multiplexing (TDM) networks (e.g., Synchronous >>>>>>>>> Optical NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), >>>>>>>>> Plesiochronous Digital Hierarchy (PDH), and G.709 sub-lambda), >>>>>>>>> lambda switching optical networks, and spatial switching (e.g., >>>>>>>>> incoming port or fiber to outgoing port or fiber). The GMPLS >>>>>>>>> architecture is provided in [RFC3945], >>>>>>>>> >>>>>>>>> If this doesn't cover the comment, can you elaborate on what you >>>>>>>>> want explicitly stated? >>>>>>>>> >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> Section 8 on Maximum LSP Bandwdith seems to be objecting to >> too >>>>>>>>>> much information leading to a "waste of bits". While possibly >>>>>>>>>> of interest to the WG, that does not seem to fit a gap >>>>> analysis. >>>>>>>>>> Similarly, section 10 on Priority Support reads as >>>>>>>>>> implementation advice rather than a gap needing protocol >> changes. >>>>>>>>>> >>>>>>>>>> Authors> The basic scope of the draft is to underline gaps, and >>>>>>>>>> Authors> even >>>>>>>>>> if what described in Ch.8 and 10, do not prevent routing to >>>>>>>>>> work , it is suggested here an requirement for optimization >>>>>>>>>> based on OTN requirements (e.g. no need to advertise fixed ODU >>>>>>>>>> container Max LSP BW since implicit in the signal type.) >>>>>>>>>> >>>>>>>>> >>>>>>>>> Authors, >>>>>>>>> I completely agree with Joel on this point, furthermore sections >>>>>>>>> 10 and >>>>>>>>> 8 overlap. One approach to address his point would be to simply >>>>>>>>> drop both sections. An alternative is try to rephrase them to >>>>>>>>> address Joel's points. I've taken a pass at the latter below, >>>>>>>>> but won't object if the authors prefer the former. >>>>>>>>> >>>>>>>>> Here's a suggested wording change if you choose to keep the >>>>> sections: >>>>>>>>> OLD: >>>>>>>>> 8. Maximum LSP Bandwidth >>>>>>>>> >>>>>>>>> Maximum LSP bandwidth is currently advertised in the common >> part >>>>>>>>> of the ISCD and advertised per priority, while in OTN networks >>>>>>>>> it is only required for ODUflex advertising. This leads to a >>>>>>>>> significant waste of bits inside each LSA. >>>>>>>>> and >>>>>>>>> >>>>>>>>> NEW >>>>>>>>> 8. Maximum LSP Bandwidth >>>>>>>>> >>>>>>>>> Maximum LSP bandwidth is currently advertised per priority in >>>>>>>>> the common part of the ISCD. Section 5 reviews some of the >>>>>>>>> implications of advertising OTN network information using ISCDs, >>>>>>>>> and identifies the need for a more optimized solution. >>>>>>>>> While strictly not required, such an optimization effort should >>>>>>>>> also consider the optimization of the per priority maximum LSP >>>>>>>>> bandwidth advertisement of both fixed and variable ODU types. >>>>>>>>> >>>>>>>>> OLD >>>>>>>>> 10. Priority Support >>>>>>>>> >>>>>>>>> [RFC4202] defines 8 priorities for resource availability and usage. >>>>>>>>> All of them have to be advertised independently on the number of >>>>>>>>> priorities supported by the implementation. Considering that >>>>>>>>> the advertisement of all the different supported signal types >>>>>>>>> will originate large LSAs, it is advised to advertise only the >>>>>>>>> information related to the really supported priorities. >>>>>>>>> NEW >>>>>>>>> 10. Priority Support >>>>>>>>> >>>>>>>>> [RFC4202] defines 8 priorities for resource availability and usage. >>>>>>>>> As defined, each is advertised independent of the number of >>>>>>>>> priorities supported by a network. As is the case in Section 8, >>>>>>>>> addressing any inefficiency with such advertisements is not >>>>>>>>> required to support OTN networks. But any such inefficiency >>>>>>>>> should also be considered as part of the optimization effort >>>>>>>>> identified in Section 5. >>>>>>>>> >>>>>>>>> Also please replace "Bw" with "Bandwidth" in the document. >>>>>>>>> >>>>>>>>> Lou >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>> From jmh@joelhalpern.com Wed Oct 2 11:38:41 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7CC21F9633; Wed, 2 Oct 2013 11:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 m6zXYWhGuc66; Wed, 2 Oct 2013 11:38:29 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDF921F893E; Wed, 2 Oct 2013 11:32:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 850CE1C9F25; Wed, 2 Oct 2013 11:32:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-99.clppva.east.verizon.net [70.106.135.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D81C21C9E48; Wed, 2 Oct 2013 11:32:35 -0700 (PDT) Message-ID: <524C66C8.5010401@joelhalpern.com> Date: Wed, 02 Oct 2013 14:32:40 -0400 From: "Joel M. Halpern" 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: Lou Berger References: <5249EF71.6000906@labn.net> <4A1562797D64E44993C5CBF38CF1BE4815B8F5@ESESSMB301.ericsson.se> <524ABF6E.2080801@labn.net> In-Reply-To: <524ABF6E.2080801@labn.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtg-dir@ietf.org" , CCAMP WG , "rtg-ads@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , Daniele Ceccarelli , "BELOTTI, SERGIO \(SERGIO\)" Subject: Re: [RTG-DIR] I: R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 18:38:41 -0000 While I tend to think of optimizations and gaps as very different things, I can live with the text changes. Yours, Joel On 10/1/13 8:26 AM, Lou Berger wrote: > Daniele, > >> Sounds reasonable? > > While I still like option 3, I can live with the revised text. > > Joel, > > Is the revised text acceptable? > > Lou > > On 10/01/2013 03:40 AM, Daniele Ceccarelli wrote: >> Hi Lou, >> >> No no no, no OSPF discussion reopening. The OSPF drafts clearly states that only supported priorities must be advertised, what does not say is why (i.e. for optimization). >> With section 8 and section 10 modified as below, there is no need to modify OSPF as the "why" is stated in the gap-analysis draft. >> >> Trying to summarize. >> Section 8 as you proposed: >>> 8. Maximum LSP Bandwidth >>> Maximum LSP bandwidth is currently advertised per priority in >>> the common part of the ISCD. Section 5 reviews some of the >>> implications of advertising OTN network information using ISCDs, >>> and identifies the need for a more optimized solution. >>> While strictly not required, such an optimization effort should >>> also consider the optimization of the per priority maximum LSP >>> bandwidth advertisement of both fixed and variable ODU types. >> >> Section 10 (as per your last proposal) >>> "[RFC4202] defines 8 priorities for resource availability >>> and usage. As defined, each is advertised independent of the number >>> of priorities supported by a network, and even unsupported >>> priorities are included.. As is the case in Section 8, addressing any >>> inefficiency with such advertisements is not required to support OTN >>> networks. But any such inefficiency should also be considered as part >>> of the optimization effort identified in Section 5." >> >> Sounds reasonable? >> BR >> Authors >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: lunedì 30 settembre 2013 23:39 >>> To: BELOTTI, SERGIO (SERGIO) >>> Cc: Joel M. Halpern; rtg-dir@ietf.org; CCAMP WG; draft-ietf-ccamp-otn-g709- >>> info-model.all@tools.ietf.org; rtg-ads@tools.ietf.org >>> Subject: Re: I: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn- >>> g709-info-model-11.txt >>> >>> Sergio, >>> See below. >>> >>> On 9/30/2013 11:15 AM, BELOTTI, SERGIO (SERGIO) wrote: >>>> Lou, >>>> our answer in line marked "authors" >>>> >>>> Thanks >>>> >>>> Authors >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> ----------------- >>>> Daniele, >>>> >>>> On 09/30/2013 09:59 AM, Daniele Ceccarelli wrote: >>>>> Lou, Joel, >>>>> >>>>> The text proposed sounds good but it only states the problem without >>> any hint on the solutions (i.e. says there is an inefficiency but doesn’t say >>> that advertising only supported priorities is a way to address such >>> inefficiency). >>>>> There are two options: >>>> >>>> Well, there's also the option of dropping the sections. >>>> >>>> Authors> as already said The basic scope of the draft is to underline >>>> gaps, and even if what described in Ch.8 and 10, do not prevent >>>> routing to work, it is suggested here an requirement for optimization >>>> based on OTN requirements (e.g. no need to advertise fixed ODU >>>> container Max LSP BW since implicit in the signal type.). So, in our >>>> opinion, no dropping. >>>> >>>> >>>>> 1. Improve the text (the NEW one) saying e.g. only the advertisement >>>>> of bandwidth for supported priorities is needed >>>> >>>> I always find it easier to make a decision when the tradeoffs are concrete. >>> Can you (authors) propose revised text? >>>> >>>> Authors> "[RFC4202] defines 8 priorities for resource availability >>>> and usage. As defined, each is advertised independent of the number of >>>> priorities supported by a network vs. to advertise only the >>>> information related to the really supported priorities as possible >>>> optimization improvement. As is the case in Section 8, addressing any >>>> inefficiency with such advertisements is not required to support OTN >>>> networks. But any such inefficiency should also be considered as part >>>> of the optimization effort identified in Section 5." >>>> >>> >>> How about: >>> OLD >>> As defined, each is advertised independent of the number >>> of priorities supported by a network vs. to advertise only the >>> information related to the really supported priorities as possible >>> optimization improvement. >>> NEW >>> As defined, each is advertised independent of the number >>> of priorities supported by a network, and even unsupported >>> priorities are included. >>> >>> >>>>> 2. Adopt the NEW text as it is and move the remaining part of the text to >>> the OSPF draft (where we say e.g. that only bandwidth for supporter >>> priorities need to be advertised but don't say why). >>>>> >>>> Doesn't the OSPF draft already already do what you say, i.e., advertise only >>> used priorities. What specific text are you proposing to add? >>>>> >>>> Authors> No, it doesn't. >>> >>> So the OSPF draft currently says that all priorities are advertised? >>> Really???? If so adding this new text does little to change this. Are you really >>> advocating reopening discussion on the OSPF draft in addition to this one? >>> >>> Lou >>> >>>> ... Text proposed is the old one that totally address explanation in our view >>> :" [RFC4202] defines 8 priorities for resource availability and usage. All of >>> them have to be advertised independently on the number of priorities >>> supported by the implementation.Considering that the advertisement of all >>> the different supported signal types will originate large LSAs, it is advised to >>> advertise only the information related to the really supported priorities. >>>> >>>> Thanks, >>>> Lou >>>> >>>>> Re all the other comments/suggestion we're ok and will fix them as >>> suggested. >>>>> >>>>> BR >>>>> Authors >>>>> >>>>>> -----Original Message----- >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>> Sent: venerdì 27 settembre 2013 21:55 >>>>>> To: Joel M. Halpern >>>>>> Cc: rtg-dir@ietf.org; CCAMP WG; draft-ietf-ccamp-otn-g709-info- >>>>>> model.all@tools.ietf.org; BELOTTI, SERGIO \(SERGIO\); >>>>>> rtg-ads@tools.ietf.org >>>>>> Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: >>>>>> draft-ietf-ccamp-otn-g709- info-model-11.txt >>>>>> >>>>>> Great. So you and I are in agreement. We'll see what the authors >>>>>> have to say... >>>>>> >>>>>> >>>>>> On 3:26pm, September 27, 2013, Joel M. Halpern wrote: >>>>>>> The proposed alternative text would suffice, although personally I >>>>>>> would just remove the two sections. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 9/27/13 3:00 PM, Lou Berger wrote: >>>>>>>> Joel, >>>>>>>> Does the proposed altnerate text address your comment (assuming >>>>>>>> the author's want to keep the sections)? If not, can you suggest >>> changes? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lou >>>>>>>> >>>>>>>> On 09/27/2013 02:30 PM, Joel M. Halpern wrote: >>>>>>>>> Lou, thanks for stepping in. >>>>>>>>> With your explanation I can live with the LSP text as it is. >>>>>>>>> >>>>>>>>> I look forward to further conversation on the other point. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 9/27/13 1:37 PM, Lou Berger wrote: >>>>>>>>>> Joel/Authors, >>>>>>>>>> >>>>>>>>>> I thought I might jump in on two points: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote: >>>>>>>>>>> Hello Joel, >>>>>>>>>>> >>>>>>>>>>> thanks for your comments. >>>>>>>>>>> Below in line our reply, marked "authors". >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>>> Given that this document is about mapping to G.709, it is >>>>>>>>>>> unclear what is intended by the usage of "LSP". My guess is >>>>>>>>>>> that it is intended to mean Label Switch Paths set up by GMPLS >>>>>>>>>>> to carry OTU/UDU elements. >>>>>>>>>>> It should be stated explicitly. >>>>>>>>>>> >>>>>>>>>>> Authors> We can specify this as you suggest even if we >>>>>>>>>>> Authors> considered not >>>>>>>>>>> necessary to specify the usage of LSP in relation to data plane >>>>>>>>>>> specific. Encoding type should cope with this issue. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Joel, >>>>>>>>>> >>>>>>>>>> I suspect that the usage of LSP in the absence of the MPLS data >>>>>>>>>> plane is what's causing confusion here. Is this correct? >>>>>>>>>> >>>>>>>>>> If so, I think GMPLS referencing controlled data paths >>>>>>>>>> (circuits) by the common name of Label Switched Path (LSP) is >>>>>>>>>> sufficiently established that this document doesn't need to >>>>>>>>>> revisit it. In any case, the document already provides context: >>>>>>>>>> >>>>>>>>>> GMPLS routing and signaling, as defined by [RFC4203], [RFC5307], >>>>>>>>>> [RFC3473] and [RFC4328], provides the mechanisms for basic >>> GMPLS >>>>>>>>>> control of OTN networks based on the 2001 revision of the G.709 >>>>>>>>>> specification. >>>>>>>>>> and >>>>>>>>>> Background information and a framework for the GMPLS protocol >>>>>>>>>> extensions need to support [G.709-2012] is provided in [OTN-FWK]. >>>>>>>>>> >>>>>>>>>> [OTN-FWK] has the often repeated concept: >>>>>>>>>> >>>>>>>>>> GMPLS extends Multi-Protocol Label Switching (MPLS) to >>> encompass >>>>>>>>>> time division multiplexing (TDM) networks (e.g., Synchronous >>>>>>>>>> Optical NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), >>>>>>>>>> Plesiochronous Digital Hierarchy (PDH), and G.709 sub-lambda), >>>>>>>>>> lambda switching optical networks, and spatial switching (e.g., >>>>>>>>>> incoming port or fiber to outgoing port or fiber). The GMPLS >>>>>>>>>> architecture is provided in [RFC3945], >>>>>>>>>> >>>>>>>>>> If this doesn't cover the comment, can you elaborate on what you >>>>>>>>>> want explicitly stated? >>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> Section 8 on Maximum LSP Bandwdith seems to be objecting to >>> too >>>>>>>>>>> much information leading to a "waste of bits". While possibly >>>>>>>>>>> of interest to the WG, that does not seem to fit a gap >>>>>> analysis. >>>>>>>>>>> Similarly, section 10 on Priority Support reads as >>>>>>>>>>> implementation advice rather than a gap needing protocol >>> changes. >>>>>>>>>>> >>>>>>>>>>> Authors> The basic scope of the draft is to underline gaps, and >>>>>>>>>>> Authors> even >>>>>>>>>>> if what described in Ch.8 and 10, do not prevent routing to >>>>>>>>>>> work , it is suggested here an requirement for optimization >>>>>>>>>>> based on OTN requirements (e.g. no need to advertise fixed ODU >>>>>>>>>>> container Max LSP BW since implicit in the signal type.) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Authors, >>>>>>>>>> I completely agree with Joel on this point, furthermore sections >>>>>>>>>> 10 and >>>>>>>>>> 8 overlap. One approach to address his point would be to simply >>>>>>>>>> drop both sections. An alternative is try to rephrase them to >>>>>>>>>> address Joel's points. I've taken a pass at the latter below, >>>>>>>>>> but won't object if the authors prefer the former. >>>>>>>>>> >>>>>>>>>> Here's a suggested wording change if you choose to keep the >>>>>> sections: >>>>>>>>>> OLD: >>>>>>>>>> 8. Maximum LSP Bandwidth >>>>>>>>>> >>>>>>>>>> Maximum LSP bandwidth is currently advertised in the common >>> part >>>>>>>>>> of the ISCD and advertised per priority, while in OTN networks >>>>>>>>>> it is only required for ODUflex advertising. This leads to a >>>>>>>>>> significant waste of bits inside each LSA. >>>>>>>>>> and >>>>>>>>>> >>>>>>>>>> NEW >>>>>>>>>> 8. Maximum LSP Bandwidth >>>>>>>>>> >>>>>>>>>> Maximum LSP bandwidth is currently advertised per priority in >>>>>>>>>> the common part of the ISCD. Section 5 reviews some of the >>>>>>>>>> implications of advertising OTN network information using ISCDs, >>>>>>>>>> and identifies the need for a more optimized solution. >>>>>>>>>> While strictly not required, such an optimization effort should >>>>>>>>>> also consider the optimization of the per priority maximum LSP >>>>>>>>>> bandwidth advertisement of both fixed and variable ODU types. >>>>>>>>>> >>>>>>>>>> OLD >>>>>>>>>> 10. Priority Support >>>>>>>>>> >>>>>>>>>> [RFC4202] defines 8 priorities for resource availability and usage. >>>>>>>>>> All of them have to be advertised independently on the number of >>>>>>>>>> priorities supported by the implementation. Considering that >>>>>>>>>> the advertisement of all the different supported signal types >>>>>>>>>> will originate large LSAs, it is advised to advertise only the >>>>>>>>>> information related to the really supported priorities. >>>>>>>>>> NEW >>>>>>>>>> 10. Priority Support >>>>>>>>>> >>>>>>>>>> [RFC4202] defines 8 priorities for resource availability and usage. >>>>>>>>>> As defined, each is advertised independent of the number of >>>>>>>>>> priorities supported by a network. As is the case in Section 8, >>>>>>>>>> addressing any inefficiency with such advertisements is not >>>>>>>>>> required to support OTN networks. But any such inefficiency >>>>>>>>>> should also be considered as part of the optimization effort >>>>>>>>>> identified in Section 5. >>>>>>>>>> >>>>>>>>>> Also please replace "Bw" with "Bandwidth" in the document. >>>>>>>>>> >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>> > From matthew.bocci@alcatel-lucent.com Thu Oct 3 06:48:24 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5531711E80AD; Thu, 3 Oct 2013 06:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Egfnq494IXZw; Thu, 3 Oct 2013 06:48:01 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id AFF7221E805D; Thu, 3 Oct 2013 06:44:49 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r93Diifm007487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Oct 2013 08:44:45 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r93DihUT011842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Oct 2013 15:44:43 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.189]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 3 Oct 2013 15:44:43 +0200 From: "Bocci, Matthew (Matthew)" To: Yakov Rekhter Thread-Topic: RtgDir review: draft-ietf-l2vpn-vpls-mcast-14.txt Thread-Index: AQHOvXESP3mxn74FpEGDXCcZiCiZlpni8cQA Date: Thu, 3 Oct 2013 13:44:42 +0000 Message-ID: In-Reply-To: <201309300007.r8U07ML16896@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <39E86674AD3B93488991830AF122AF19@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-l2vpn-vpls-mcast@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-mcast-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 13:48:24 -0000 Yakov Thanks for your responses. Please see below. On 30/09/2013 01:07, "Yakov Rekhter" wrote: >Matthew, > >> Hello, >>=20 >> 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, and >> sometimes on special request. 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 >>=20 >> Since IETF LC has ended for this draft, I am primarily providing >>comments t=3D >> o >> aid the ADs, and I hope the authors will also take them into >>consideration =3D >> to improve >> the readability of the draft. > >Thanks for your review and comments. > >> Document: draft-ietf-l2vpn-vpls-mcast-14.txt >> Reviewer: Matthew Bocci >> Review Date: 26 September 2013 >> IETF LC End Date: date-if-known >> Intended Status: Proposed Standard >>=20 >> Summary: >>=20 >> I have some minor concerns about this document that I think should >> be resolved before publication. >>=20 >> Comments: >>=20 >> The draft appears to be complete and accurate form a technical >>perspective.=3D >> However, >> the style of the draft and the density of the text make it quite >>difficult =3D >> to >> read at times. It took several passes of some sections of the document, >>and=3D >> returning >> to earlier sections, to properly follow the text. I believe this is >>because=3D >> the basic >> multicast architecture could be better-explained earlier in the draft. >>=20 >> Major Issues: >>=20 >> No major issues found. >>=20 >> Minor Issues: >>=20 >> 1) The draft contains both introductory architectural / framework >> descriptions, and more detailed specifications of the protocols required >> to efficiently support multicast in VPLS. However, the introductory >>sections >> (e.g. the overview in section 5) are presented in the form of extremely >> dense text, and while >> they seem to be trying to explain architectural concepts, they do not >>use=20 >> a single diagram to help the reader visualise the solutions in the >>draft.=20 >> In fact, the first >> figures illustrating the protocol hierarchies and relationships do not >> appear until the >> label stacks are described in Section 13 on page 43. >>=20 >> I think inserting some figures in section 5 to illustrate the >>different=20 >> multicast schemes, and also moving the data forwarding section earlier >>in=20 >> the document, would greatly help the reader. > >Wrt "inserting some figures in section 5", I would be glad to do this, >provided you elaborate a bit on what specific figures you would like >to insert. I think that it would help to add a figure to each of the bullets in section 5.1 (inclusive trees and selective trees) illustrating the architecture of each (a couple of reference models would be helpful). >=20 > >Wrt moving the data forwarding section earlier in the document, >the placement of the data forwarding section follows the structure >of rfc6513. OK, but at least it would help if you added an illustration to the two bullets I have referenced above, which shows the label stacks in each of the cases.=20 > >> 2) Cross-references in the text use the title of the referenced >>section, bu=3D >> t do not >> include a section number. Personally, I found that this made the draft >>much=3D >> more difficult >> to navigate than it should be. It would help to add section numbers to >>each=3D >> instance of >> a cross reference. > >This will be fixed as part of the RFC Editor process. OK thanks > >> Nits: >>=20 >> Abstract, 2nd paragraph, 1st sentence: >> s/solution/solutions > >Fixed. Thanks > >> Section 3: This section would be clearer of it was in tabular form, >> in a similar manner to other RFCs. > >I would prefer to keep it in the present form, as there are plenty >of other RFCs that have similar form. OK I guess it is a personal preference. > =20 >> You could also add short (one sentence) definitions of 'Inclusive >>Trees', '=3D >> Selective Trees', and 'Aggregation'. > >Will do. Thanks > >> Sec 4. Introduction: 3rd para: >> s/when large/when a large > >Fixed. > >> Sec 4. Introduction: 5th para: >> s/RSVP-PE/RSVP-TE > >Fixed. > >> Sec 5.2. BGP-Based VPLS Membership Auto-Discovery: 1st para: >> s/that have membership these/that have membership of these > >Fixed. > >> Sec 5.4 Advertising P-Multicast..., 2nd para: >> Grammar: The decision to bind a set of VPLS instances or customer >>multicast=3D >> group is >> local to the ingress PE matter, / The decision to bind a set of VPLS >>instan=3D >> ces or >> customer multicast groups is a local matter for the ingress PE , > >Fixed. > >> Sec 5.4 Advertising P-Multicast..., 3rd para: >> s/be included. / be included > >Fixed. > >> Section 5.5 Aggregation: >>=20 >> The following algorithm is hard to parse: >> + ((Average number of VPLS instances on a PE / Aggregation Factor) >> * number of PEs) / (Average number of P-Multicast trees that >> transit a given P router) >>=20 >> I think this could be restated in a more readable manner. Just as an >>exampl=3D >> e: >> AveVPLS NPE >> ------- X -------- >> Aggr AvePTree >>=20 >> Where: AveVPLS is the average number of VPLS instances on a PE >> Aggr is the aggregation factor >> NPE is the number of PEs >> AvePTree is the average number of P-multicast that transit a >>giv=3D >en P-router >>=20 > >Will fix. Thanks > >> Section 6: Inter-AS Inclusive P-Multicast..., 5th Paragraph >> This paragraph mentions FEC128 and FEC 129. It would be better to call >>thes=3D >> e by their >> formal names used in RFC4447 i.e. The PWid FEC and the Generalized PWid >>FEC > >Will fix. Thanks Matthew > >Yakov. > From yakov@juniper.net Thu Oct 3 08:01:27 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DBF21F90FD; Thu, 3 Oct 2013 08:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 XQnQjDJBFa74; Thu, 3 Oct 2013 08:01:14 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0CE21F9926; Thu, 3 Oct 2013 07:50:34 -0700 (PDT) Received: from mail55-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.22; Thu, 3 Oct 2013 14:50:33 +0000 Received: from mail55-va3 (localhost [127.0.0.1]) by mail55-va3-R.bigfish.com (Postfix) with ESMTP id DF67D42029A; Thu, 3 Oct 2013 14:50:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI1432I1418Idbf2izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de097h186068h1d68deh8275dhz2fh2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail55-va3: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail55-va3 (localhost.localdomain [127.0.0.1]) by mail55-va3 (MessageSwitch) id 1380811725454892_11367; Thu, 3 Oct 2013 14:48:45 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.254]) by mail55-va3.bigfish.com (Postfix) with ESMTP id 669A04E005B; Thu, 3 Oct 2013 14:48:45 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.50) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 3 Oct 2013 14:48:44 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 3 Oct 2013 07:48:43 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r93EWwL60083; Thu, 3 Oct 2013 07:33:02 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201310031433.r93EWwL60083@magenta.juniper.net> To: "Bocci, Matthew (Matthew)" In-Reply-To: References: X-MH-In-Reply-To: "Bocci, Matthew (Matthew)" message dated "Thu, 03 Oct 2013 13:44:42 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <594.1380810778.1@juniper.net> Date: Thu, 3 Oct 2013 07:32:58 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Thu, 03 Oct 2013 08:05:32 -0700 Cc: "l2vpn@ietf.org" , Yakov Rekhter , "draft-ietf-l2vpn-vpls-mcast@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-mcast-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 15:01:28 -0000 Matthew, > Yakov > > Thanks for your responses. Please see below. > > On 30/09/2013 01:07, "Yakov Rekhter" wrote: > > >Matthew, > > > >> 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, and > >> sometimes on special request. 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 > >> > >> Since IETF LC has ended for this draft, I am primarily providing > >>comments t= > >> o > >> aid the ADs, and I hope the authors will also take them into > >>consideration = > >> to improve > >> the readability of the draft. > > > >Thanks for your review and comments. > > > >> Document: draft-ietf-l2vpn-vpls-mcast-14.txt > >> Reviewer: Matthew Bocci > >> Review Date: 26 September 2013 > >> IETF LC End Date: date-if-known > >> Intended Status: Proposed Standard > >> > >> Summary: > >> > >> I have some minor concerns about this document that I think should > >> be resolved before publication. > >> > >> Comments: > >> > >> The draft appears to be complete and accurate form a technical > >>perspective.= > >> However, > >> the style of the draft and the density of the text make it quite > >>difficult = > >> to > >> read at times. It took several passes of some sections of the document, > >>and= > >> returning > >> to earlier sections, to properly follow the text. I believe this is > >>because= > >> the basic > >> multicast architecture could be better-explained earlier in the draft. > >> > >> Major Issues: > >> > >> No major issues found. > >> > >> Minor Issues: > >> > >> 1) The draft contains both introductory architectural / framework > >> descriptions, and more detailed specifications of the protocols required > >> to efficiently support multicast in VPLS. However, the introductory > >>sections > >> (e.g. the overview in section 5) are presented in the form of extremely > >> dense text, and while > >> they seem to be trying to explain architectural concepts, they do not > >>use > >> a single diagram to help the reader visualise the solutions in the > >>draft. > >> In fact, the first > >> figures illustrating the protocol hierarchies and relationships do not > >> appear until the > >> label stacks are described in Section 13 on page 43. > >> > >> I think inserting some figures in section 5 to illustrate the > >>different > >> multicast schemes, and also moving the data forwarding section earlier > >>in > >> the document, would greatly help the reader. > > > >Wrt "inserting some figures in section 5", I would be glad to do this, > >provided you elaborate a bit on what specific figures you would like > >to insert. > > I think that it would help to add a figure to each of the bullets in > section 5.1 (inclusive trees and selective trees) illustrating the > architecture of each (a couple of reference models would be helpful). I am not sure I agree. In fact, the concepts of inclusive and selective trees have been "borrowed" from rfc6513/rfc6514, and neither of these RFCs have any figures that illustrate inclusive/selective trees. > > > > > > >Wrt moving the data forwarding section earlier in the document, > >the placement of the data forwarding section follows the structure > >of rfc6513. > > OK, but at least it would help if you added an illustration to the two > bullets I have referenced above, which shows the label stacks in each of > the cases. > The label stack is exactly the same for both inclusive and selective trees. Section 13 shows the label stacks for inclusive trees (both non-aggregate and aggregate), and since the label stack is the same for both inclusive and selective trees, the figures the label stack shown in these figures equally applies to both inclusive and selective trees. Would the following new text in 13.1 address your concern ? While this section shows the label stack for inclusive trees, since the label stack is exactly the same for both inclusive and selective trees, the label stack shown in this section is equally applicable to selective trees. Yakov. From adrian@olddog.co.uk Mon Oct 7 10:38:50 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3929311E810A; Mon, 7 Oct 2013 10:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 xfAqrZSg-vL3; Mon, 7 Oct 2013 10:38:44 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1B35021F9FAE; Mon, 7 Oct 2013 10:38:43 -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 r97HceWj030078; Mon, 7 Oct 2013 18:38:40 +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 r97HcdK5030069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Oct 2013 18:38:39 +0100 From: "Adrian Farrel" To: , , Date: Mon, 7 Oct 2013 18:38:39 +0100 Message-ID: <02f501cec384$0f818950$2e849bf0$@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: Ac7DhAuSLs1v28q5R/GMhN3NuGdUfQ== Content-Language: en-gb Cc: stbryant@cisco.com Subject: [RTG-DIR] Routing ADs Open Office : Vancouver X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 17:38:50 -0000 Hi, In a break with tradition, we will hold office hours at lunch on Thursday. Venue will be the IESG break-out room (to be announced). Sorry in advance that you may have to watch the ADs eat! Adrian and Stewart. From jdrake@juniper.net Tue Oct 8 14:58:44 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E8821F9E73; Tue, 8 Oct 2013 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 R2jqqZ-OsoDG; Tue, 8 Oct 2013 14:58:37 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9B58B21F9FC7; Tue, 8 Oct 2013 14:58:26 -0700 (PDT) Received: from mail111-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Oct 2013 21:58:24 +0000 Received: from mail111-co9 (localhost [127.0.0.1]) by mail111-co9-R.bigfish.com (Postfix) with ESMTP id 8F32EA400EE; Tue, 8 Oct 2013 21:58:24 +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: VPS-22(zz9371I542I1432Ief7Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h8275bh8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail111-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=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(377454003)(51704005)(189002)(199002)(38314003)(31966008)(69226001)(51856001)(50986001)(47736001)(80022001)(47976001)(81686001)(83072001)(59766001)(19580395003)(19580405001)(65816001)(49866001)(83322001)(81816001)(74502001)(79102001)(80976001)(77982001)(74662001)(63696002)(46102001)(47446002)(54316002)(66066001)(81542001)(74316001)(33646001)(81342001)(76482001)(53806001)(74876001)(54356001)(56776001)(76576001)(74706001)(4396001)(74366001)(85306002)(76796001)(77096001)(56816003)(76786001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail111-co9 (localhost.localdomain [127.0.0.1]) by mail111-co9 (MessageSwitch) id 1381269502349779_32379; Tue, 8 Oct 2013 21:58:22 +0000 (UTC) Received: from CO9EHSMHS017.bigfish.com (unknown [10.236.132.247]) by mail111-co9.bigfish.com (Postfix) with ESMTP id 4E79F10004B; Tue, 8 Oct 2013 21:58:22 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS017.bigfish.com (10.236.130.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Oct 2013 21:58:22 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 8 Oct 2013 21:58:20 +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.775.9; Tue, 8 Oct 2013 21:58:17 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.115]) with mapi id 15.00.0775.005; Tue, 8 Oct 2013 21:58:17 +0000 From: John E Drake To: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" , "rtgarea-chairs@tools.ietf.org" , "rtg-dir@ietf.org" Thread-Topic: [RTG-DIR] Routing ADs Open Office : Vancouver Thread-Index: Ac7DhAuSLs1v28q5R/GMhN3NuGdUfQA7V77g Date: Tue, 8 Oct 2013 21:58:16 +0000 Message-ID: <380fad1f1e6e473baf3964f741ce5c0c@BY2PR05MB142.namprd05.prod.outlook.com> References: <02f501cec384$0f818950$2e849bf0$@olddog.co.uk> In-Reply-To: <02f501cec384$0f818950$2e849bf0$@olddog.co.uk> 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: 0993689CD1 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: "stbryant@cisco.com" Subject: Re: [RTG-DIR] Routing ADs Open Office : Vancouver X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 21:58:44 -0000 Adrian, Will you be providing lunch and/or beer? Yours Irrespectively, John > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behal= f > Of Adrian Farrel > Sent: Monday, October 07, 2013 10:39 AM > To: routing-discussion@ietf.org; rtgarea-chairs@tools.ietf.org; rtg- > dir@ietf.org > Cc: stbryant@cisco.com > Subject: [RTG-DIR] Routing ADs Open Office : Vancouver >=20 > Hi, >=20 > In a break with tradition, we will hold office hours at lunch on Thursday= . >=20 > Venue will be the IESG break-out room (to be announced). >=20 > Sorry in advance that you may have to watch the ADs eat! >=20 > Adrian and Stewart. >=20 >=20 From loa@pi.nu Tue Oct 8 18:37:34 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B412821F9FF6; Tue, 8 Oct 2013 18:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 PANnnKvOdVoG; Tue, 8 Oct 2013 18:37:28 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E130D11E8104; Tue, 8 Oct 2013 18:37:27 -0700 (PDT) Received: from [192.168.1.6] (unknown [112.208.84.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8584618014F6; Wed, 9 Oct 2013 03:37:24 +0200 (CEST) Message-ID: <5254B351.1010204@pi.nu> Date: Wed, 09 Oct 2013 09:37:21 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John E Drake References: <02f501cec384$0f818950$2e849bf0$@olddog.co.uk> <380fad1f1e6e473baf3964f741ce5c0c@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <380fad1f1e6e473baf3964f741ce5c0c@BY2PR05MB142.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "adrian@olddog.co.uk" , "stbryant@cisco.com" , "rtg-dir@ietf.org" , "routing-discussion@ietf.org" , "rtgarea-chairs@tools.ietf.org" Subject: Re: [RTG-DIR] Routing ADs Open Office : Vancouver X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 01:37:35 -0000 if Adrian pay, I can get a good selection of pale ale and/or IPA. Vancover is a fairly OK beer city :) /Lo9a On 2013-10-09 05:58, John E Drake wrote: > Adrian, > > Will you be providing lunch and/or beer? > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf >> Of Adrian Farrel >> Sent: Monday, October 07, 2013 10:39 AM >> To: routing-discussion@ietf.org; rtgarea-chairs@tools.ietf.org; rtg- >> dir@ietf.org >> Cc: stbryant@cisco.com >> Subject: [RTG-DIR] Routing ADs Open Office : Vancouver >> >> Hi, >> >> In a break with tradition, we will hold office hours at lunch on Thursday. >> >> Venue will be the IESG break-out room (to be announced). >> >> Sorry in advance that you may have to watch the ADs eat! >> >> Adrian and Stewart. >> >> > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From acee.lindem@ericsson.com Tue Oct 8 18:41:42 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EFE21F9DED; Tue, 8 Oct 2013 18:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 ZbNRbyyWNnor; Tue, 8 Oct 2013 18:41:36 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4225911E8100; Tue, 8 Oct 2013 18:41:22 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-85-5254b4414dce Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 05.0E.09414.144B4525; Wed, 9 Oct 2013 03:41:22 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Tue, 8 Oct 2013 21:41:21 -0400 From: Acee Lindem To: "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Thread-Topic: RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Thread-Index: AQHOxJCn0+iFqto7ekGiQXMkyXw9jQ== Date: Wed, 9 Oct 2013 01:41:20 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470307FE6D@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470307FE6Deusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXSPt67TlpAgg5Z9PBZP5txgsfjb8JrF 4vmcmSwWC9Y8ZXdg8Viy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4Mva1mhRMnspSsfL+TMYG xplnmbsYOTkkBEwkfkxaCWWLSVy4t54NxBYSOMoosfyMeBcjF5C9jFHi9I5DLCAJNgEdieeP /oE1iAjkSvQtOcYEYjMLlElM2dkLViMs0MYoMf+NO0iziEA3o8Tmy3uhGvQkfjw8B2azCKhI zDrUAGbzCvhKLLh8E2wzI9AV30+tgRoqLnHryXwmiOsEJJbsOQ91qajEy8f/WCFsZYklT/az QNTnS3xdcRNqpqDEyZlPWCYwCs9CMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfAYqtda YtvW7YzIahYwcqxi5CgtTi3LTTcy2MQIjKpjEmy6Oxj3vLQ8xCjNwaIkzvvlrXOQkEB6Yklq dmpqQWpRfFFpTmrxIUYmDk6pBsYUsYjLT+rSmzl3/trJ/vjqs8Uq3B2cf6f6ZATFvT1zpNQ9 MXhO2f/XN92fLdRcdlFnit9JnshjEVyvF8dvXz0hev3Z28dKX0qEtudz73Q9IKF2k+nWkdJj LP2XHf825cudC2wPqXSddSaqytp04+XInWuLRX1W76tp8Xsm+VxDfy7rrmUu6fpKLMUZiYZa zEXFiQDzgzETeAIAAA== Cc: "rtg-dir@ietf.org" , CCAMP , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 01:41:42 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470307FE6Deusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please seehttp= ://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ccamp-ospf-g709v3-09.txt Reviewer: Acee Lindem Review Date: October 15th, 2013 IETF LC End Date: October 16, 2013 Intended Status: Proposed Standard Summary: The document is missing some key sections and requires some clarif= ication prior to publication. Comments: Major Issues: The document lacks several critical pieces of information. 1. There is no discussion of OSPF scaling or flooding freq= uency. Even if it not expected that G709 GMPLS signaling will not present any problems, this n= eeds to be stated and justified. Refer to section 8 in RFC 6827 for an example of such a discus= sion. 2. The document includes lots of normative text indicating= precisely how sub-TLVs MUST be formatted. However, there is no indication of what th= e action to be taken if the TLVs do not follow the strict conventions. 3. The document jumps down into details of G.709 technolog= y without adequate explanation (particularly in the examples). Either t= hese details need to be removed or a statement of prerequisite knowledge is required. Minor Issues: The document had a large number of editorial errors. 1. The bit numbering on all the figures was off by 1 colum= n. If you look at RFC 4203, this will be obvious. 2. The table on page 7 is incomprehensible with the given = columns and headings. Spaces rather than commas in numbers are annoying. 3. The distinction between TLVs and sub-TLVs is not consis= tent throughout the document. Again, refer to RFC 6827 for an example of consistent= referral. 4. Figures 8 and 9 have the T and S fields offset from the= bit numbering. Also, it took some time to realize that T1 meant a value of 1. 5. Figures 11-15 are very inconsistent in that these are e= xamples yet the values for T, S, and sometime TSG are not specified. Rather, the example i= ncludes the letters. 6. Security section - RFC 2154 is an experimental RFC that= has heretofore never been commercially implemented or deployed. It is time to q= uit referencing it in draft "Security Considerations". Nits: 1. The proper punctuation is "i.e., " and "e.g. ,". Also,= sentences should not start with either. See http://www.rfc-editor.org/rfc-style-guide/rfc-sty= le 2. Page 7, "Switching Capability-Specific Information (SCS= I)? 3. Suggest formatting the document so that the figures are= on separate pages rather than split across pages. 4. Replace all occurrences of "non " with "non-" and do no= t end lines with "non ". 5. I thought the examples included many run-on sentences t= hat were hard to parse and lacked needed punctuation. I tried to edit but I'm not even = sure if I retained the same meaning. You can get a flavor for what I mean by the diffs below. Thanks, Acee 132,133c132,133 < Routing information for Optical Channel Layer (OCh) (i.e. wavelength) < is out of the scope of this document. Please refer to [RFC6163] and --- > Routing information for Optical Channel Layer (OCh) (i.e., wavelength) > is beyond the scope of this document. Please refer to [RFC6163] and 157c157 < As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so --- > As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended 159c159 < related to each different ODUj and ODUk/OTUk (Optical Transport Unit) --- > of each different ODUj and ODUk/OTUk (Optical Transport Unit) 176c176 < In the following we will use ODUj to indicate a service type that is --- > In the following, we will use ODUj to indicate a service type that is 179c179 < the OTUk. Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and --- > the OTUk. Moreover, ODUj(S) and ODUk(S) are used to indicate ODUj and 184c184 < multiplexing levels. In the following the term "multiplexing tree" --- > multiplexing levels. In the following, the term "multiplexing tree" 191c191 < If for example a multiplexing hierarchy like the following one is --- > For example, If a multiplexing hierarchy like the following one is 251c251 < one hop case multiple hop TE-links advertise ODU switching capacity. --- > one hop case, multiple hop TE-links advertise ODU switching capacity. 296,297c296,297 < Both for fixed and flexible ODUs the same switching type and encoding < values MUST be used. When Switching Capability and Encoding fields --- > The same switching type and encoding values must be used for both fixe= d > and flexible ODUs. When Switching Capability and Encoding fields 303,304c303,304 < The MAX LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <= =3D < MAX LSP Bandwidth <=3D ODUk/OTUk and intermediate values are those on --- > The MAX LSP Bandwidth field is used according to [RFC4203]: i.e., 0 <= =3D > MAX LSP Bandwidth <=3D ODUk/OTUk, and intermediate values are those on 306,307c306,307 < E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP < Bandwidth for some priorities, ODU3 for others, ODU2 for some others --- > For example, in the OTU4 link it could be possible to have ODU4 as MAX= LSP > Bandwidth for some priorities, ODU3 for others, ODU2 for some others, 397,398c397,398 < Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non < resizable. Each MUST always be advertised in separate Type 2 TLVs as --- > Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) > non-resizable. Each MUST always be advertised in separate Type 2 TLVs= as 400c400 < both GFP-F resizable and non resizable (i.e. 21 and 22) are --- > both GFP-F resizable and non-resizable (i.e. 21 and 22) are 535c535 < (i.e. a non OTN client). --- > (i.e., a non-OTN client). 540c540 < - Priority (8 bits): a bitmap used to indicate which priorities --- > - Priority (8 bits): A bitmap used to indicate which priorities 542,543c542,543 < leftmost bit representing priority level 0 (i.e. the highest) and < the rightmost bit representing priority level 7 (i.e. the lowest). --- > leftmost bit representing priority level 0 (i.e., the highest) and > the rightmost bit representing priority level 7 (i.e., the lowest). 666c666 < Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD @T0 --- > Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD at T0 676,678c676,678 < At time T1 an ODU3 at priority 2 is set-up, so for priority 0 the MAX < LSP Bandwidth is still equal to the ODU4 bandwidth, while for < priorities from 2 to 7 (excluding the non supported ones) the MAX LSP --- > At time T1, an ODU3 at priority 2 is set-up, so for priority 0 the > MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for > priorities from 2 to 7 (excluding the non-supported ones) the MAX LSP 680c680 < next supported ODUj in the hierarchy is ODU3.The advertisement is --- > next supported ODUj in the hierarchy is ODU3. The advertisement is 710c710 < Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD @T1 --- > Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD at T1 712,714c712,714 < At time T2 an ODU2 at priority 4 is set-up. The first ODU3 is no < longer available since T1 as it was kept by the ODU3 LSP, while the < second is no more available and just 3 ODU2 are left in it. ODU2 is --- > At time T2, an ODU2 at priority 4 is set-up. The first ODU3 is no > longer available since T1, as it was kept by the ODU3 LSP, while the > second is no more available and just 3 ODU2s are left in it. ODU2 is 758c758 < Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD @T2 --- > Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD at T2 762c762 < In this example an interface with Tributary Slot Type 1.25Gbps and --- > In this example, an interface with Tributary Slot Type 1.25Gbps and 766c766 < switched or terminated, the ODU2 can only be terminated and the ODU1 --- > switched or terminated, the ODU2 can only be terminated, and the ODU1 768c768 < advertised to support ODU0 the value of is "ignored" (TS --- > advertised to support ODU0, the value of is "ignored" (TS 770c770 < interface a single ISCD is used and its format is as follows: --- > interface, a single ISCD is used and its format is as follows: 819c819 < In this example two interfaces with homogeneous hierarchies but --- > In this example, two interfaces with homogeneous hierarchies but 822,824c822,824 < one a G.709-2012 interface with fallback procedure disabled (TS < granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy and < priorities 0 and 3. T and S bits values are not relevant to this --- > one supports G.709-2012 interface with fallback procedure disabled > (TS granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy > and priorities 0 and 3. T and S bits values are not relevant to this 826,827c826,827 < interfaces two different ISCDs are used and the format of their SCSIs < is as follows: --- > interfaces, two different ISCDs are used and the format of their > SCSIs is as follows: 903,908c903,908 < with different exported TS granularity MUST be considered as non < homogenous hierarchies is the case in which an H-LPS and the client < LSP are terminated on the same egress node. What can happen is that < a loose Explicit Route Object (ERO) is used at the hop where the < signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate < hop of the LSP). --- > with different exported TS granularity MUST be considered as > non-homogenous hierarchies. This is the case in which an H-LPS and > the client LSP are terminated on the same egress node. What can > happen is that a loose Explicit Route Object (ERO) is used at the > hop where the signaled LSP is nested into the Hierarchical-LSP (H-LSP) > (penultimate hop of the LSP). 912,915c912,915 < if2. In case the H-LSP on if1 exports a TS=3D1.25Gbps and if2 a < TS=3D2.5Gbps and the service LSP being signaled needs a 1.25Gbps < tributary slot, only the H-LSP on if1 can be used to reach node E. < For further details please see section 4.1 of the [OTN-INFO]. --- > if2. In this case, the H-LSP on if1 exports a TS=3D1.25Gbps, if2 a > TS=3D2.5Gbps, the service LSP being signaled needs a 1.25Gbps > tributary slot, and only the H-LSP on if1 can be used to reach node E. > For further details, please see section 4.1 of the [OTN-INFO]. 939,943c939,943 < In this example the advertisement of an ODUflex->ODU3 hierarchy is < shown. In case of ODUflex advertisement the MAX LSP Bandwidth needs < to be advertised and in some cases also information about the < Unreserved bandwidth could be useful. The amount of Unreserved < bandwidth does not give a clear indication of how many ODUflex LSP --- > In this example, the advertisement of an ODUflex->ODU3 hierarchy is > shown. In the case of ODUflex advertisement, the MAX LSP Bandwidth > needs to be advertised and, in some cases, information about the > Unreserved bandwidth could also be useful. The amount of Unreserved > bandwidth does not give a clear indication of how many ODUflex LSPs 959,962c959,962 < Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved < Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex < LSPs of 10 GBps each, have to be restored, for sure only one can be < restored along Link B and it is probable (but not sure) that two of --- > Bandwidth equal to 10 Gbps each. In the case where 50Gbps of Unreserv= ed > Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUflex > LSPs of 10 GBps each have to be restored, for sure only one can be > restored along Link B and it is probable, but not certain, that two of 966c966 < In the case of ODUflex advertisement the Type 2 Bandwidth TLV is --- > In the case of ODUflex advertisement, the Type 2 Bandwidth TLV is 1073c1073 < simplicity we assume that also in this case only priorities 0 and 3 --- > simplicity, we also assume that only priorities 0 and 3 1294c1294 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1388c1388 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1506c1506 < All implementations of this document MAY support also advertisement --- > All implementations of this document MAY also support advertisement 1518c1518 < based on policy and is out of scope of the document. This enables --- > based on policy and beyond the scope of this document. This enables 1537c1537 < [RFC5920] . --- > [RFC5920]. --_000_94A203EA12AECE4BA92D42DBFFE0AE470307FE6Deusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <55F1924DCDD1054DACF74A228BF68BB7@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hello,
 
I have been selected= as the Routing Directorate reviewer for this draft. The Routing Directorat= e seeks to review all routing or routing-related drafts as they pass throug= h IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing Direc= torate, please seehttp://www.ietf.org/iesg/directorate/routing.html
 
Although these comme= nts are primarily for the use of the Routing ADs, it would be helpful if yo= u 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-ospf-g709v3-09.txt
Reviewer: Acee Linde= m
Review Date: October= 15th, 2013
IETF LC End Date: Oc= tober 16, 2013
Intended Status: Pro= posed Standard 
 
Summary: The documen= t is missing some key sections and requires some clarification prior to pub= lication. 
 
Comments:
 
Major Issues: The do= cument lacks several critical pieces of information.   

     =            1. There is no discussion of OSPF= scaling or flooding frequency. Even if it not expected that G709 
     =                 GMPLS signaling wi= ll not present any problems, this needs to be stated and justified. Re= fer to
     =                 section 8 in RFC 6= 827 for an example of such a discussion. 
     =            2. The document includes lots of&= nbsp;normative text indicating precisely how sub-TLVs MUST be 
     =                 formatted. Ho= wever, there is no indication of what the action to be taken if the TLVs do=
     =                 not follow the str= ict conventions. 
     =            3. The document jumps down into d= etails of G.709 technology without adequate 
     =                  explanation = (particularly in the examples). Either these details need to be remove= d or a 
     =                 statement of prere= quisite knowledge is required. 
 
Minor Issues: The do= cument had a large number of editorial errors.

     =            1. The bit numbering on all the f= igures was off by 1 column. If you look at RFC 4203, 
     =                 this will be obvio= us. 
     =            2. The table on page 7 is incompr= ehensible with the given columns and headings. Spaces 
     =                 rather than commas= in numbers are annoying. 
     =            3. The distinction between TLVs a= nd sub-TLVs is not consistent throughout the document. 
     =                 Again, refer to RF= C 6827 for an example of consistent referral.
     =            4. Figures 8 and 9 have the T and= S fields offset from the bit numbering. Also, it took 
     =                 some time to reali= ze that T1 meant a value of 1. 
     =            5. Figures 11-15 are very inconsi= stent in that these are examples yet the values for T, S, and
     =                 sometime TSG are n= ot specified. Rather, the example includes the letters.  
     =            6. Security section - RFC 2154 is= an experimental RFC that has heretofore never been 
     =                 commercially imple= mented or deployed. It is time to quit referencing it in draft 
     =                 "Security Con= siderations". 
    <= /div>
  Nits:
     =            1. The proper punctuation is &quo= t;i.e., " and "e.g. ,".  Also, sentences should not sta= rt with either. 
     =                 See http://www.rfc-edi= tor.org/rfc-style-guide/rfc-style
     =            2. Page 7, "Switching Capabi= lity-Specific Information (SCSI)? 
     =            3. Suggest formatting the documen= t so that the figures are on separate pages rather than 
     =                 split across pages= . 
     =            4. Replace all occurrences of &qu= ot;non " with "non-" and do not end lines with "non &qu= ot;. 
     =            5. I thought the examples include= d many run-on sentences that were hard to parse and lacked
     =                 needed punctuation= . I tried to edit but I'm not even sure if I retained the same meaning. You=  
     =                 can get a flavor f= or what I mean by the diffs below. 

Thanks,
Acee 
132,133c132,133
<    Routing informati= on for Optical Channel Layer (OCh) (i.e. wavelength)
<    is out of the sco= pe of this document.  Please refer to [RFC6163] and
---
>    Routing informati= on for Optical Channel Layer (OCh) (i.e., wavelength)
>    is beyond the sco= pe of this document.  Please refer to [RFC6163] and
157c157
<    As discussed in [= OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so
---
>    As discussed in [= OTN-FWK] and [OTN-INFO], OSPF-TE must be extended
159c159
<    related to each d= ifferent ODUj and ODUk/OTUk (Optical Transport Unit)
---
>    of each different= ODUj and ODUk/OTUk (Optical Transport Unit)
176c176
<    In the following = we will use ODUj to indicate a service type that is
---
>    In the following,= we will use ODUj to indicate a service type that is
179c179
<    the OTUk.  M= oreover ODUj(S) and ODUk(S) are used to indicate ODUj and
---
>    the OTUk.  M= oreover, ODUj(S) and ODUk(S) are used to indicate ODUj and
184c184
<    multiplexing leve= ls.  In the following the term "multiplexing tree"
---
>    multiplexing leve= ls.  In the following, the term "multiplexing tree"
191c191
<    If for example a = multiplexing hierarchy like the following one is
---
>    For example, If a= multiplexing hierarchy like the following one is
251c251
<    one hop case mult= iple hop TE-links advertise ODU switching capacity.
---
>    one hop case, mul= tiple hop TE-links advertise ODU switching capacity.
296,297c296,297
<    Both for fixed an= d flexible ODUs the same switching type and encoding
<    values MUST be us= ed.  When Switching Capability and Encoding fields
---
>    The same switchin= g type and encoding values must be used for both fixed
>    and flexible ODUs= .  When Switching Capability and Encoding fields
303,304c303,304
<    The MAX LSP Bandw= idth field is used according to [RFC4203]: i.e. 0 <=3D
<    MAX LSP Bandwidth= <=3D ODUk/OTUk and intermediate values are those on
---
>    The MAX LSP Bandw= idth field is used according to [RFC4203]: i.e., 0 <=3D
>    MAX LSP Bandwidth= <=3D ODUk/OTUk, and intermediate values are those on
306,307c306,307
<    E.g. in the OTU4 = link it could be possible to have ODU4 as MAX LSP
<    Bandwidth for som= e priorities, ODU3 for others, ODU2 for some others
---
>    For example, in t= he OTU4 link it could be possible to have ODU4 as MAX LSP
>    Bandwidth for som= e priorities, ODU3 for others, ODU2 for some others, 
397,398c397,398
<    Procedure-Frame m= apped (GFP-F) resizable and 22 - ODUflex (GFP-F) non
<    resizable.  = Each MUST always be advertised in separate Type 2 TLVs as
---
>    Procedure-Frame m= apped (GFP-F) resizable and 22 - ODUflex (GFP-F) 
>    non-resizable. &n= bsp;Each MUST always be advertised in separate Type 2 TLVs as=
400c400
<    both GFP-F resiza= ble and non resizable (i.e. 21 and 22) are
---
>    both GFP-F resiza= ble and non-resizable (i.e. 21 and 22) are
535c535
<       (i.e. a n= on OTN client).
---
>       (i.e., a = non-OTN client).
540c540
<       - Priorit= y (8 bits): a bitmap used to indicate which priorities
---
>       - Priorit= y (8 bits): A bitmap used to indicate which priorities
542,543c542,543
<       leftmost = bit representing priority level 0 (i.e. the highest) and
<       the right= most bit representing priority level 7 (i.e. the lowest).
---
>       leftmost = bit representing priority level 0 (i.e., the highest) and
>       the right= most bit representing priority level 7 (i.e., the lowest).
666c666
<       Figure 5:= Example 1 - MAX LSP Bandwidth fields in the ISCD @T0
---
>       Figure 5:= Example 1 - MAX LSP Bandwidth fields in the ISCD at T0
676,678c676,678
<    At time T1 an ODU= 3 at priority 2 is set-up, so for priority 0 the MAX
<    LSP Bandwidth is = still equal to the ODU4 bandwidth, while for
<    priorities from 2= to 7 (excluding the non supported ones) the MAX LSP
---
>    At time T1, an OD= U3 at priority 2 is set-up, so for priority 0 the
>    MAX LSP Bandwidth= is still equal to the ODU4 bandwidth, while for
>    priorities from 2= to 7 (excluding the non-supported ones) the MAX LSP
680c680
<    next supported OD= Uj in the hierarchy is ODU3.The advertisement is
---
>    next supported OD= Uj in the hierarchy is ODU3. The advertisement is
710c710
<       Figure 6:= Example 1 - MAX LSP Bandwidth fields in the ISCD @T1
---
>       Figure 6:= Example 1 - MAX LSP Bandwidth fields in the ISCD at T1
712,714c712,714
<    At time T2 an ODU= 2 at priority 4 is set-up.  The first ODU3 is no
<    longer available = since T1 as it was kept by the ODU3 LSP, while the
<    second is no more= available and just 3 ODU2 are left in it.  ODU2 is
---
>    At time T2, an OD= U2 at priority 4 is set-up.  The first ODU3 is no
>    longer available = since T1, as it was kept by the ODU3 LSP, while the
>    second is no more= available and just 3 ODU2s are left in it.  ODU2 is
758c758
<       Figure 7:= Example 1 - MAX LSP Bandwidth fields in the ISCD @T2
---
>       Figure 7:= Example 1 - MAX LSP Bandwidth fields in the ISCD at T2
762c762
<    In this example a= n interface with Tributary Slot Type 1.25Gbps and
---
>    In this example, = an interface with Tributary Slot Type 1.25Gbps and
766c766
<    switched or termi= nated, the ODU2 can only be terminated and the ODU1
---
>    switched or termi= nated, the ODU2 can only be terminated, and the ODU1
768c768
<    advertised to sup= port ODU0 the value of is "ignored" (TS
---
>    advertised to sup= port ODU0, the value of is "ignored" (TS
770c770
<    interface a singl= e ISCD is used and its format is as follows:
---
>    interface, a sing= le ISCD is used and its format is as follows:
819c819
<    In this example t= wo interfaces with homogeneous hierarchies but
---
>    In this example, = two interfaces with homogeneous hierarchies but
822,824c822,824
<    one a G.709-2012 = interface with fallback procedure disabled (TS
<    granularity=3D3).=  Both of them support ODU1->ODU2->ODU3 hierarchy and
<    priorities 0 and = 3.  T and S bits values are not relevant to this
---
>    one supports G.70= 9-2012 interface with fallback procedure disabled
>    (TS granularity= =3D3).  Both of them support ODU1->ODU2->ODU3 hierarchy
>    and priorities 0 = and 3.  T and S bits values are not relevant to this
826,827c826,827
<    interfaces two di= fferent ISCDs are used and the format of their SCSIs
<    is as follows:
---
>    interfaces, two d= ifferent ISCDs are used and the format of their 
>    SCSIs is as follo= ws:
903,908c903,908
<    with different ex= ported TS granularity MUST be considered as non
<    homogenous hierar= chies is the case in which an H-LPS and the client
<    LSP are terminate= d on the same egress node.  What can happen is that
<    a loose Explicit = Route Object (ERO) is used at the hop where the
<    signaled LSP is n= ested into the Hierarchical-LSP (H-LSP) (penultimate
<    hop of the LSP).<= /span>
---
>    with different ex= ported TS granularity MUST be considered as 
>    non-homogenous hi= erarchies. This is the case in which an H-LPS and 
>    the client LSP ar= e terminated on the same egress node.  What can 
>    happen is that a = loose Explicit Route Object (ERO) is used at the 
>    hop where the sig= naled LSP is nested into the Hierarchical-LSP (H-LSP)
>    (penultimate hop = of the LSP).
912,915c912,915
<    if2.  In cas= e the H-LSP on if1 exports a TS=3D1.25Gbps and if2 a
<    TS=3D2.5Gbps and = the service LSP being signaled needs a 1.25Gbps
<    tributary slot, o= nly the H-LSP on if1 can be used to reach node E.
<    For further detai= ls please see section 4.1 of the [OTN-INFO].
---
>    if2.  In thi= s case, the H-LSP on if1 exports a TS=3D1.25Gbps, if2 a
>    TS=3D2.5Gbps, the= service LSP being signaled needs a 1.25Gbps
>    tributary slot, a= nd only the H-LSP on if1 can be used to reach node E.
>    For further detai= ls, please see section 4.1 of the [OTN-INFO].
939,943c939,943
<    In this example t= he advertisement of an ODUflex->ODU3 hierarchy is
<    shown.  In c= ase of ODUflex advertisement the MAX LSP Bandwidth needs
<    to be advertised = and in some cases also information about the
<    Unreserved bandwi= dth could be useful.  The amount of Unreserved
<    bandwidth does no= t give a clear indication of how many ODUflex LSP
---
>    In this example, = the advertisement of an ODUflex->ODU3 hierarchy is
>    shown.  In t= he case of ODUflex advertisement, the MAX LSP Bandwidth
>    needs to be adver= tised and, in some cases, information about the
>    Unreserved bandwi= dth could also be useful.  The amount of Unreserved
>    bandwidth does no= t give a clear indication of how many ODUflex LSPs
959,962c959,962
<    Bandwidth equal t= o 10 Gbps each.  In case 50Gbps of Unreserved
<    Bandwidth are ava= ilable on Link A, 10Gbps on Link B and 3 ODUflex
<    LSPs of 10 GBps e= ach, have to be restored, for sure only one can be
<    restored along Li= nk B and it is probable (but not sure) that two of
---
>    Bandwidth equal t= o 10 Gbps each.  In the case where 50Gbps of Unreserved<= /div>
>    Bandwidth are ava= ilable on Link A, 10Gbps on Link B, and 3 ODUflex
>    LSPs of 10 GBps e= ach have to be restored, for sure only one can be
>    restored along Li= nk B and it is probable, but not certain, that two of
966c966
<    In the case of OD= Uflex advertisement the Type 2 Bandwidth TLV is
---
>    In the case of OD= Uflex advertisement, the Type 2 Bandwidth TLV is
1073c1073
<    simplicity we ass= ume that also in this case only priorities 0 and 3
---
>    simplicity, we al= so assume that only priorities 0 and 3
1294c1294
<    In this example 2= OTU4 component links with the same supported TS
---
>    In this example, = 2 OTU4 component links with the same supported TS
1388c1388
<    In this example 2= OTU4 component links with the same supported TS
---
>    In this example, = 2 OTU4 component links with the same supported TS
1506c1506
<    All implementatio= ns of this document MAY support also advertisement
---
>    All implementatio= ns of this document MAY also support advertisement
1518c1518
<    based on policy a= nd is out of scope of the document.  This enables
---
>    based on policy a= nd beyond the scope of this document.  This enables
1537c1537
<    [RFC5920] .
---
>    [RFC5920].=


     =           
     =           
 
--_000_94A203EA12AECE4BA92D42DBFFE0AE470307FE6Deusaamb101erics_-- From matthew.bocci@alcatel-lucent.com Fri Oct 11 08:22:03 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280E411E81C5; Fri, 11 Oct 2013 08:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 zNClxX6ggXOy; Fri, 11 Oct 2013 08:21:57 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A84C121E8082; Fri, 11 Oct 2013 08:21:57 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9BFLsuZ009437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Oct 2013 10:21:55 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r9BFLr6E009130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 17:21:53 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.189]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 11 Oct 2013 17:21:53 +0200 From: "Bocci, Matthew (Matthew)" To: Yakov Rekhter Thread-Topic: RtgDir review: draft-ietf-l2vpn-vpls-mcast-14.txt Thread-Index: AQHOvXESP3mxn74FpEGDXCcZiCiZlpni8cQAgAAjUomADIk4gA== Date: Fri, 11 Oct 2013 15:21:53 +0000 Message-ID: In-Reply-To: <201310031433.r93EWwL60083@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <8697C3C738E4B64C9632EFBC16818C2A@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-l2vpn-vpls-mcast@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-mcast-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:22:03 -0000 Yakov On 03/10/2013 15:32, "Yakov Rekhter" wrote: >Matthew, > >> Yakov >>=20 >> Thanks for your responses. Please see below. >>=20 >> On 30/09/2013 01:07, "Yakov Rekhter" wrote: >>=20 >> >Matthew, >> > >> >> Hello, >> >>=20 >> >> 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, and >> >> sometimes on special request. 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 >> >>=20 >> >> Since IETF LC has ended for this draft, I am primarily providing >> >>comments t=3D >> >> o >> >> aid the ADs, and I hope the authors will also take them into >> >>consideration =3D >> >> to improve >> >> the readability of the draft. >> > >> >Thanks for your review and comments. >> > >> >> Document: draft-ietf-l2vpn-vpls-mcast-14.txt >> >> Reviewer: Matthew Bocci >> >> Review Date: 26 September 2013 >> >> IETF LC End Date: date-if-known >> >> Intended Status: Proposed Standard >> >>=20 >> >> Summary: >> >>=20 >> >> I have some minor concerns about this document that I think should >> >> be resolved before publication. >> >>=20 >> >> Comments: >> >>=20 >> >> The draft appears to be complete and accurate form a technical >> >>perspective.=3D >> >> However, >> >> the style of the draft and the density of the text make it quite >> >>difficult =3D >> >> to >> >> read at times. It took several passes of some sections of the >>document, >> >>and=3D >> >> returning >> >> to earlier sections, to properly follow the text. I believe this is >> >>because=3D >> >> the basic >> >> multicast architecture could be better-explained earlier in the >>draft. >> >>=20 >> >> Major Issues: >> >>=20 >> >> No major issues found. >> >>=20 >> >> Minor Issues: >> >>=20 >> >> 1) The draft contains both introductory architectural / framework >> >> descriptions, and more detailed specifications of the protocols >>required >> >> to efficiently support multicast in VPLS. However, the introductory >> >>sections >> >> (e.g. the overview in section 5) are presented in the form of >>extremely >> >> dense text, and while >> >> they seem to be trying to explain architectural concepts, they do not >> >>use=20 >> >> a single diagram to help the reader visualise the solutions in the >> >>draft.=20 >> >> In fact, the first >> >> figures illustrating the protocol hierarchies and relationships do >>not >> >> appear until the >> >> label stacks are described in Section 13 on page 43. >> >>=20 >> >> I think inserting some figures in section 5 to illustrate the >> >>different=20 >> >> multicast schemes, and also moving the data forwarding section >>earlier >> >>in=20 >> >> the document, would greatly help the reader. >> > >> >Wrt "inserting some figures in section 5", I would be glad to do this, >> >provided you elaborate a bit on what specific figures you would like >> >to insert. >>=20 >> I think that it would help to add a figure to each of the bullets in >> section 5.1 (inclusive trees and selective trees) illustrating the >> architecture of each (a couple of reference models would be helpful). > >I am not sure I agree. In fact, the concepts of inclusive and selective >trees have been "borrowed" from rfc6513/rfc6514, and neither of these >RFCs have any figures that illustrate inclusive/selective trees. I would certainly find it easier to read, to explain how those concepts apply in VPLS scenarios, even if the original RFCs do not use diagrams. At very least, if you have borrowed the terms, then a reference here to those RFCs would be helpful. > >>=20 >> >=20 >> > >> >Wrt moving the data forwarding section earlier in the document, >> >the placement of the data forwarding section follows the structure >> >of rfc6513. >>=20 >> OK, but at least it would help if you added an illustration to the two >> bullets I have referenced above, which shows the label stacks in each of >> the cases.=20 >>=20 > > >The label stack is exactly the same for both inclusive and selective >trees. Section 13 shows the label stacks for inclusive trees >(both non-aggregate and aggregate), and since the label stack >is the same for both inclusive and selective trees, the figures >the label stack shown in these figures equally applies to >both inclusive and selective trees. > >Would the following new text in 13.1 address your concern ? > > > While this section shows the label stack for inclusive trees, > since the label stack is exactly the same for both inclusive and > selective trees, the label stack shown in this section is equally > applicable to selective trees. OK Matthew > >Yakov. > From manav.bhatia@alcatel-lucent.com Sun Oct 13 08:55:51 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9779011E814C; Sun, 13 Oct 2013 08:55: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=[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 so7loscuVCFJ; Sun, 13 Oct 2013 08:55:45 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 152C111E8118; Sun, 13 Oct 2013 08:55:43 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9DFtgfb020190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Oct 2013 10:55:42 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r9DFteKF015472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Oct 2013 11:55:40 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 13 Oct 2013 11:55:40 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Sun, 13 Oct 2013 23:55:37 +0800 From: "Bhatia, Manav (Manav)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSA== Date: Sun, 13 Oct 2013 15:55:37 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 15:55:51 -0000 Hello, =20 I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please seehttp= ://www.ietf.org/iesg/directorate/routing.html =20 Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. =20 Document: draft-ietf-mpls-tp-rosetta-stone-12.txt Reviewer: Manav Bhatia Review Date: October 13th, 2013 IETF LC End Date: October 16, 2013 Intended Status: Informational =20 Summary: This document is basically ready for publication, but has nits th= at should be considered prior to publication. Comments: This document is built on top of terms already defined in differe= nt RFCs and ITU-T documents. The terms and definitions have already been re= viewed so there is a trifle little that needs to be done there. Overall, th= e document looks good and ready for publication. Some of my comments can be= =20 =20 Nits: o) Please expand PW in either the Abstract or Sec 3.5 o) When explaining Control Plane (3.6) should we mention that it is possibl= e to operate an MPLS-TP network without using a Control Plane? o) In 3.7, it would be useful to mention that an important property of co-r= outed bidirectional path is that the forward and backward directions share = fate. Similarly, in 3.1, we should mention that the forward and backward di= rections don't share fate. o) 3.12 in the current text doesn't look very helpful. Can it be rephrased = it to something like, "The equipment management function (EMF) provides the= means through which an element management system (EMS) and other managing = entities manage the network element function (NEF)." o) 3.13 talks about Fault cause without explaining what a fault cause is. I= t took me some time to understand what was meant by "fault cause". Can the = authors of the draft rephrase 3.13 in their own language to explain what th= ey mean by a Failure. The current definition in the draft has been picked u= p as-is from ITU-T G.806 o) 3.14 talks about "inability of a function to perform a required action".= Since this RFC-to-be is in the IETF domain, can this be rephrased to use a= term like router/switch instead of a more esoteric "function". This is a g= eneral comment and applies to most of the definitions that have been copied= from the ITU-T documents. o) The last paragraph of 3.17 says the following: "OAM packets are subject to the same forwarding treatment as the data traff= ic, but they are distinct from the data traffic." In what sense are the OAM packets distinct from the data traffic?=20 o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been expande= d in the document. o) Sec 3.19 uses TCM without expanding it first. o) In Sec 3.23, s/Tandem Connections/Tandem Connection o) In 3.28.3, can the following text be added: An LSP segment comprises one or more continuous hops on the path of the LSP= . [RFC5654] defines two terms. A "segment" is a single hop along the path= of an LSP, while a "concatenated segment" is more than one hop along the p= ath of an LSP. o) In 3.31, Isn't Operations Support Systems (OSS) a more common term than = Operations Systems (OS)? Cheers, Manav= From Alexander.Vainshtein@ecitele.com Sun Oct 13 09:15:52 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6E721F9D74 for ; Sun, 13 Oct 2013 09:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 ofp9-Zpkji-P for ; Sun, 13 Oct 2013 09:15:48 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id A665F21F9CF3 for ; Sun, 13 Oct 2013 09:15:45 -0700 (PDT) X-AuditID: 93eaf2e7-b7fa36d000007b89-cb-525ac72e3faa Received: from ILPTWPVEXCA01.ecitele.com ( [172.31.244.224]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 58.AF.31625.E27CA525; Sun, 13 Oct 2013 18:15:43 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Sun, 13 Oct 2013 19:15:42 +0300 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5 Date: Sun, 13 Oct 2013 16:15:41 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTfUgTYRjv3d3mOb04l7ZXCboulb5mW/axqEnQ14pKsSizQs/tdTvcbmu3 LPuwRURkRYX0h9P8QCsxwcqMsA/U0tAEg5C+RVOzDMFSCc2i2y5NiN6/fu/9Pp7nXp6HwFRf FREEx7uRi2dtjEKJ5/Z/G9YsfpqcqD1TEaSvH2/H9QUdHXJ9cWVvwBrMeOrjQ7mxrGxUZhx+ MaRIwJI9YDXL8w4360a0GQkmA5Pg4jJZUxZDc2YDo2Nop401ITvi3QaGdToRb2bilPQ/Z7Uo 43ga8SaHmeMtBmbT9niNXr9spUbHxEXP1cWuUu6wcgKNNHaWs9F2JAisBdHil9Q7mLW7o0Dh bJl/qKvug8wD2ubkgEACUkth+aMrMgnPhM87qhQ5QEmoqHoAz9wdC5AujQB6vGV+lYIywNs3 3it8OFTEfdW1uE+EUYMADno65T5iBrUWPntdByTROuhtbZVJeAm8+nbcj3EqCjZf6vHrSSoB jlxs8oeqqL1wtKbVjwOpfbBptMuvB2J731sq/Rij1PBNT9GftilY9qANk3AY/Nz9Sy7h2bC6 plsu6RfB4vvfFBJeCK+VfMGkuiGwOa8Hl/ThsL78FX4RqL1TSnin2L1T7N4p9mKAV4AwzuZ0 p9ktWl0MMnFuZEMxJof9NpDmpe8eGCuKbAAUAZhgsq5td6JKzmYKWfYGEE7ImDCy4nFyomp6 msOcZWUFa4rrgA0JDQASGBNK4pzIkWY26zByOSao9eILXsIigkwOcTJ5d0qsVvv/C6Mmr3t2 xasoiziDGQg5kWsiZxZBMJCMahJLhLiQBR1K52zuv7SMCPS1ESy2ofVpSMHJ2gXOIvEtYE6E mhxuFAnKR1gP8JPeiU3pB2rxp2eQGp89WNyjSXe/GCwTg0cHknzB4n5MUhEeoIzrzA48fezJ zqrsy9Fba7t/bA/mhvaXfu0N2GuB/QexkPYjaTXHz670dK4qNI73nEvftvztcstN7YpEfVLV 2ED1O0da9vnIHaUx7Y76krzQ2jU586b9zDjx8sladKtQ3XYsaMPJjJGoTOvj/Aum9Eq0JXVn xUZbUuHR/M1RufTQpz0MLlhZ3QLMJbC/AXLccHUEBAAA Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 16:15:52 -0000 Manav and all, Regarding one of the nits you've identified: "it would be useful to mention that an important property of co-routed bidir= ectional path is that the forward and backward directions share fate." IMHO and FWIW this is not correct. To the best of my understanding the two d= irections of an MPLS-TP co-routed bi-directional path share lifespan (i.e.,t= hey are set up and torn down in a single management or control plane operati= on). But they do not share fate, as can be seen from the following examples: 1. A unidirectiona fiber cut in one of the links used by a co-routed bi-dire= ctional trail will result in traffic failur in the affected direction but no= t necessarily in the reverse one 2. Consider the case when one of entries the ILM in one of the transit LSRs= is corruped. This will result in incorrect failure of a single label, but t= he rest of the labels would be handled correctly. Since co-routed bi-directi= onal trails do not require using the same label in both directions of a trai= l, the fate sharing would be broken. (Actually, in such a way it could be easily broken even if the same label is= used on each segment of the LSP in both directions...) My 2c, Sasha ________________________________________ From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on behalf of Bhati= a, Manav (Manav) [manav.bhatia@alcatel-lucent.com] Sent: Sunday, October 13, 2013 5:55 PM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; m= pls@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt 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 a= s they pass through IETF last call and IESG review, and sometimes on special= request. The purpose of the review is to provide assistance to the Routing= ADs. For more information about the Routing Directorate, please seehttp://w= ww.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wou= ld 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-mpls-tp-rosetta-stone-12.txt Reviewer: Manav Bhatia Review Date: October 13th, 2013 IETF LC End Date: October 16, 2013 Intended Status: Informational Summary: This document is basically ready for publication, but has nits tha= t should be considered prior to publication. Comments: This document is built on top of terms already defined in differen= t RFCs and ITU-T documents. The terms and definitions have already been revi= ewed so there is a trifle little that needs to be done there. Overall, the d= ocument looks good and ready for publication. Some of my comments can be Nits: o) Please expand PW in either the Abstract or Sec 3.5 o) When explaining Control Plane (3.6) should we mention that it is possible= to operate an MPLS-TP network without using a Control Plane? o) In 3.7, it would be useful to mention that an important property of co-ro= uted bidirectional path is that the forward and backward directions share fa= te. Similarly, in 3.1, we should mention that the forward and backward direc= tions don't share fate. o) 3.12 in the current text doesn't look very helpful. Can it be rephrased i= t to something like, "The equipment management function (EMF) provides the m= eans through which an element management system (EMS) and other managing ent= ities manage the network element function (NEF)." o) 3.13 talks about Fault cause without explaining what a fault cause is. It= took me some time to understand what was meant by "fault cause". Can the au= thors of the draft rephrase 3.13 in their own language to explain what they= mean by a Failure. The current definition in the draft has been picked up a= s-is from ITU-T G.806 o) 3.14 talks about "inability of a function to perform a required action".= Since this RFC-to-be is in the IETF domain, can this be rephrased to use a= term like router/switch instead of a more esoteric "function". This is a ge= neral comment and applies to most of the definitions that have been copied f= rom the ITU-T documents. o) The last paragraph of 3.17 says the following: "OAM packets are subject to the same forwarding treatment as the data traffi= c, but they are distinct from the data traffic." In what sense are the OAM packets distinct from the data traffic? o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been expanded= in the document. o) Sec 3.19 uses TCM without expanding it first. o) In Sec 3.23, s/Tandem Connections/Tandem Connection o) In 3.28.3, can the following text be added: An LSP segment comprises one or more continuous hops on the path of the LSP.= [RFC5654] defines two terms. A "segment" is a single hop along the path o= f an LSP, while a "concatenated segment" is more than one hop along the path= of an LSP. o) In 3.31, Isn't Operations Support Systems (OSS) a more common term than O= perations Systems (OS)? Cheers, Manav This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From manav.bhatia@alcatel-lucent.com Sun Oct 13 19:22:00 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F9A11E81D6; Sun, 13 Oct 2013 19:22:00 -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 b0KbBuu5LaKg; Sun, 13 Oct 2013 19:21:54 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9E711E81D0; Sun, 13 Oct 2013 19:21:53 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9E2LmfR026742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Oct 2013 21:21:48 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r9E2LiFs001405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Oct 2013 22:21:45 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 13 Oct 2013 22:21:44 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Mon, 14 Oct 2013 10:21:41 +0800 From: "Bhatia, Manav (Manav)" To: Alexander Vainshtein Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiA= Date: Mon, 14 Oct 2013 02:21:40 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 02:22:00 -0000 Hi Sasha, RFC 5960 that describes the MPLS-TP data plane says the following: A point-to-point co-routed bidirectional LSP is a point-to-point associated bidirectional LSP with the additional constraint that its two unidirectional component LSPs in each direction follow the same path (in terms of both nodes and links). An important property of co-routed bidirectional LSPs is that their unidirectional component LSPs share fate. Am I missing something? Cheers, Manav =20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 > Sent: Sunday, October 13, 2013 9:46 PM > To: Bhatia, Manav (Manav) > Cc: rtg-dir@ietf.org;=20 > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org;=20 > mpls@ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > Manav and all, > Regarding one of the nits you've identified: > "it would be useful to mention that an important property of=20 > co-routed bidirectional path is that the forward and backward=20 > directions share fate." >=20 > IMHO and FWIW this is not correct. To the best of my=20 > understanding the two directions of an MPLS-TP co-routed=20 > bi-directional path share lifespan (i.e.,they are set up and=20 > torn down in a single management or control plane operation). > But they do not share fate, as can be seen from the following=20 > examples: >=20 > 1. A unidirectiona fiber cut in one of the links used by a=20 > co-routed bi-directional trail will result in traffic failur=20 > in the affected direction but not necessarily in the reverse one >=20 > 2. Consider the case when one of entries the ILM in one of=20 > the transit LSRs is corruped. This will result in incorrect=20 > failure of a single label, but the rest of the labels would=20 > be handled correctly. Since co-routed bi-directional trails=20 > do not require using the same label in both directions of a=20 > trail, the fate sharing would be broken.=20 > (Actually, in such a way it could be easily broken even if=20 > the same label is used on each segment of the LSP in both=20 > directions...) >=20 > My 2c, > Sasha >=20 >=20 >=20 > ________________________________________ > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on=20 > behalf of Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > Sent: Sunday, October 13, 2013 5:55 PM > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org;=20 > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > Subject: [RTG-DIR] RtgDir review:=20 > draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for=20 > this draft. The Routing Directorate seeks to review all=20 > routing or routing-related drafts as they pass through IETF=20 > last call and IESG review, and sometimes on special request.=20 > The purpose of the review is to provide assistance to the=20 > Routing ADs. For more information about the Routing=20 > Directorate, please=20 > seehttp://www.ietf.org/iesg/directorate/routing.html >=20 > Although these comments are primarily for the use of the=20 > Routing ADs, it would be helpful if you could consider them=20 > along with any other IETF Last Call comments that you=20 > receive, and strive to resolve them through discussion or by=20 > updating the draft. >=20 > Document: draft-ietf-mpls-tp-rosetta-stone-12.txt > Reviewer: Manav Bhatia > Review Date: October 13th, 2013 > IETF LC End Date: October 16, 2013 > Intended Status: Informational >=20 > Summary: This document is basically ready for publication,=20 > but has nits that should be considered prior to publication. >=20 > Comments: This document is built on top of terms already=20 > defined in different RFCs and ITU-T documents. The terms and=20 > definitions have already been reviewed so there is a trifle=20 > little that needs to be done there. Overall, the document=20 > looks good and ready for publication. Some of my comments can be >=20 > Nits: >=20 > o) Please expand PW in either the Abstract or Sec 3.5 >=20 > o) When explaining Control Plane (3.6) should we mention that=20 > it is possible to operate an MPLS-TP network without using a=20 > Control Plane? >=20 > o) In 3.7, it would be useful to mention that an important=20 > property of co-routed bidirectional path is that the forward=20 > and backward directions share fate. Similarly, in 3.1, we=20 > should mention that the forward and backward directions don't=20 > share fate. >=20 > o) 3.12 in the current text doesn't look very helpful. Can it=20 > be rephrased it to something like, "The equipment management=20 > function (EMF) provides the means through which an element=20 > management system (EMS) and other managing entities manage=20 > the network element function (NEF)." >=20 > o) 3.13 talks about Fault cause without explaining what a=20 > fault cause is. It took me some time to understand what was=20 > meant by "fault cause". Can the authors of the draft rephrase=20 > 3.13 in their own language to explain what they mean by a=20 > Failure. The current definition in the draft has been picked=20 > up as-is from ITU-T G.806 >=20 > o) 3.14 talks about "inability of a function to perform a=20 > required action". Since this RFC-to-be is in the IETF domain,=20 > can this be rephrased to use a term like router/switch=20 > instead of a more esoteric "function". This is a general=20 > comment and applies to most of the definitions that have been=20 > copied from the ITU-T documents. >=20 > o) The last paragraph of 3.17 says the following: >=20 > "OAM packets are subject to the same forwarding treatment as=20 > the data traffic, but they are distinct from the data traffic." >=20 > In what sense are the OAM packets distinct from the data traffic? >=20 > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have=20 > not been expanded in the document. >=20 > o) Sec 3.19 uses TCM without expanding it first. >=20 > o) In Sec 3.23, s/Tandem Connections/Tandem Connection >=20 > o) In 3.28.3, can the following text be added: >=20 > An LSP segment comprises one or more continuous hops on the=20 > path of the LSP. [RFC5654] defines two terms. A "segment"=20 > is a single hop along the path of an LSP, while a=20 > "concatenated segment" is more than one hop along the path of an LSP. >=20 > o) In 3.31, Isn't Operations Support Systems (OSS) a more=20 > common term than Operations Systems (OS)? >=20 > Cheers, Manav >=20 > This e-mail message is intended for the recipient only and=20 > contains information which is CONFIDENTIAL and which may be=20 > proprietary to ECI Telecom. If you have received this=20 > transmission in error, please inform us by e-mail, phone or=20 > fax, and then delete the original and all copies thereof. >=20 > = From Alexander.Vainshtein@ecitele.com Sun Oct 13 21:07:04 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815E621E80DE for ; Sun, 13 Oct 2013 21:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 4t5qFG4Hpqgm for ; Sun, 13 Oct 2013 21:06:57 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5E77A21E80C5 for ; Sun, 13 Oct 2013 21:06:49 -0700 (PDT) X-AuditID: 93eaf2e7-b7f596d000004d89-63-525b6dd3a0e6 Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 10.A1.19849.3DD6B525; Mon, 14 Oct 2013 06:06:43 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 07:06:43 +0300 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BQ== Date: Mon, 14 Oct 2013 04:06:42 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGJsWRmVeSWpSXmKPExsUy+dWnL7qXc6ODDP7etrE4+Ocqi8WCNU/Z HZg8liz5yeTx5fJntgCmqAZGm8S8vPySxJJUhZTU4mRbpYCizLLE5EolhcwUWyVDJYWCnMTk 1NzUvBJbpcSCgtS8FCU7LgUMYANUlpmnkJqXnJ+SmZduq+QZ7K9rYWFqqWuoZKembGhszRWS kVmskKqbm5iZo5CbWlycmJ6qABRJ2MKccWT3Y5aCq/YVf/ssGhg3GXcxcnJICJhIzN62hRnC FpO4cG89WxcjF4eQwEFGiQMPbkA5Rxkldm9Yyg5SxSZgK7Fp9V02EFsEyH6+eRcLSBGzwAdG iQ8ND1hBEsICzhKnbx5ghChykZh15gxTFyMHkO0kcWJbHUiYRUBVou3XMrDNvAIBEm+mTWeF WPaFUeJOx0kmkASnQKzE1GczwWYyAp33/dQasDizgLjErSfzmSDOFpBYsuc81AuiEi8f/2OF sOUlLn54AFWvI7Fg9yc2CFtbYtnC11CLBSVOznzCAlEvKXFwxQ2WCYzis5CsmIWkfRaS9llI 2hcwsqxiFM3MKShJyk03MNRLTc4sSc1J1UvOz93ECEkkz3cw/pqvcohRgINRiYc3wyU6SIg1 say4MvcQoyQHk5Io7+0coBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3t0g5bwpiZVVqUX5MClX YBBOZJbiTs4HJse8knhjAwPcHCVx3uUN4f5CAunAJJidmlqQWgQzR4aDQ0mC1wCYhIUEi1LT UyvSMnNKENJMHJwgZ/AAnfEP5ETe4oLE3OLMdIj8KUZFKXFeI5BmAZBERmkeXC8se7xiFAd6 WpiXCaSKB5h54LpfAQ1mAhr8820EyGBg9oBLSTUwJr+Lrp1VG7OeJV980saLbBWxhr/2Mz5T 46z8q/RVR0vEVPycLbd9huHzyNTsYyEenut02c98f7HwOvtr3t2Ldy7v3xtT1Hkge6Zc2UH5 5TY/9/d4sK712tgXeNas4MC1iKa//nNytqzJWpz08Jdv8t8/Dgc8OYOu2byqV7FcpSc24/qU okpJJZbijERDLeai4kQAHSQ0zPkDAAA= Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 04:07:04 -0000 Manav, Lots of thanks for a prompt response. I must admit that I've mssed the text in 5960 to which you refer. The original definition, to the best of my understanding, is in Section 1.2.= 2. of RFC 5654 and says something else: Co-routed Bidirectional path: A path where the forward and backward directions follow the same route (links and nodes) across the network. Both directions are setup, monitored and protected as a single entity. A transport network path is typically co-routed. To me this means that if one of the directions of the co-routed bi-direction= al path fails to convey traffic, the monitoring mechanisms will report the entire bi-directional path as fail= ed. To the best of my recollection when I=3DD to become RFC 5960 has been discus= sed I've asked the authors of RFC 5960 whether the pairing between two direc= tions of a co-routed bi-directional MPLS-TP LSP in a transit LSR is limited= to OAM processing, and they (or one of them) have confirmed that this is in= deed so. I wonder whether this can be interpreted as "fate-sharing". Regards, Sasha ________________________________________ From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] Sent: Monday, October 14, 2013 4:21 AM To: Alexander Vainshtein Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; m= pls@ietf.org; rtg-ads@tools.ietf.org Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Hi Sasha, RFC 5960 that describes the MPLS-TP data plane says the following: A point-to-point co-routed bidirectional LSP is a point-to-point associated bidirectional LSP with the additional constraint that its two unidirectional component LSPs in each direction follow the same path (in terms of both nodes and links). An important property of co-routed bidirectional LSPs is that their unidirectional component LSPs share fate. Am I missing something? Cheers, Manav > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Sunday, October 13, 2013 9:46 PM > To: Bhatia, Manav (Manav) > Cc: rtg-dir@ietf.org; > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > mpls@ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > Manav and all, > Regarding one of the nits you've identified: > "it would be useful to mention that an important property of > co-routed bidirectional path is that the forward and backward > directions share fate." > > IMHO and FWIW this is not correct. To the best of my > understanding the two directions of an MPLS-TP co-routed > bi-directional path share lifespan (i.e.,they are set up and > torn down in a single management or control plane operation). > But they do not share fate, as can be seen from the following > examples: > > 1. A unidirectiona fiber cut in one of the links used by a > co-routed bi-directional trail will result in traffic failur > in the affected direction but not necessarily in the reverse one > > 2. Consider the case when one of entries the ILM in one of > the transit LSRs is corruped. This will result in incorrect > failure of a single label, but the rest of the labels would > be handled correctly. Since co-routed bi-directional trails > do not require using the same label in both directions of a > trail, the fate sharing would be broken. > (Actually, in such a way it could be easily broken even if > the same label is used on each segment of the LSP in both > directions...) > > My 2c, > Sasha > > > > ________________________________________ > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on > behalf of Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > Sent: Sunday, October 13, 2013 5:55 PM > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > Subject: [RTG-DIR] RtgDir review: > draft-ietf-mpls-tp-rosetta-stone-12.txt > > 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, and sometimes on special request. > The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing > Directorate, please > seehttp://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-mpls-tp-rosetta-stone-12.txt > Reviewer: Manav Bhatia > Review Date: October 13th, 2013 > IETF LC End Date: October 16, 2013 > Intended Status: Informational > > Summary: This document is basically ready for publication, > but has nits that should be considered prior to publication. > > Comments: This document is built on top of terms already > defined in different RFCs and ITU-T documents. The terms and > definitions have already been reviewed so there is a trifle > little that needs to be done there. Overall, the document > looks good and ready for publication. Some of my comments can be > > Nits: > > o) Please expand PW in either the Abstract or Sec 3.5 > > o) When explaining Control Plane (3.6) should we mention that > it is possible to operate an MPLS-TP network without using a > Control Plane? > > o) In 3.7, it would be useful to mention that an important > property of co-routed bidirectional path is that the forward > and backward directions share fate. Similarly, in 3.1, we > should mention that the forward and backward directions don't > share fate. > > o) 3.12 in the current text doesn't look very helpful. Can it > be rephrased it to something like, "The equipment management > function (EMF) provides the means through which an element > management system (EMS) and other managing entities manage > the network element function (NEF)." > > o) 3.13 talks about Fault cause without explaining what a > fault cause is. It took me some time to understand what was > meant by "fault cause". Can the authors of the draft rephrase > 3.13 in their own language to explain what they mean by a > Failure. The current definition in the draft has been picked > up as-is from ITU-T G.806 > > o) 3.14 talks about "inability of a function to perform a > required action". Since this RFC-to-be is in the IETF domain, > can this be rephrased to use a term like router/switch > instead of a more esoteric "function". This is a general > comment and applies to most of the definitions that have been > copied from the ITU-T documents. > > o) The last paragraph of 3.17 says the following: > > "OAM packets are subject to the same forwarding treatment as > the data traffic, but they are distinct from the data traffic." > > In what sense are the OAM packets distinct from the data traffic? > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have > not been expanded in the document. > > o) Sec 3.19 uses TCM without expanding it first. > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > o) In 3.28.3, can the following text be added: > > An LSP segment comprises one or more continuous hops on the > path of the LSP. [RFC5654] defines two terms. A "segment" > is a single hop along the path of an LSP, while a > "concatenated segment" is more than one hop along the path of an LSP. > > o) In 3.31, Isn't Operations Support Systems (OSS) a more > common term than Operations Systems (OS)? > > Cheers, Manav > > This e-mail message is intended for the recipient only and > contains information which is CONFIDENTIAL and which may be > proprietary to ECI Telecom. If you have received this > transmission in error, please inform us by e-mail, phone or > fax, and then delete the original and all copies thereof. > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From manav.bhatia@alcatel-lucent.com Sun Oct 13 22:26:23 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125EE21E80B8; Sun, 13 Oct 2013 22:26:23 -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 wFE4HhQpL7RX; Sun, 13 Oct 2013 22:26:17 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1038D21E80AB; Sun, 13 Oct 2013 22:26:16 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9E5Q9H7002230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Oct 2013 00:26:10 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r9E5Q8H8024702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 01:26:08 -0400 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Oct 2013 01:26:07 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 13:26:05 +0800 From: "Bhatia, Manav (Manav)" To: Alexander Vainshtein Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BYAAE12w Date: Mon, 14 Oct 2013 05:26:05 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 05:26:23 -0000 Sasha, I think the confusion is over what we mean by "fate sharing". To me, if the forward path is torn down for some reason, and that results i= n the backward path being torn down as well, then they inextricably "share = the fate". If the path of the forward LSP changes because of an IGP trigger, then the = backward LSP changes too in case of co-routed bidirectional LSPs. However, = this isn't true in case of Associated bidirectional LSPs. Similarly, an IGP= change (or a network event -- link/node flap, link/node down) will always = result in both directions changing their path in case of co-routed bidirect= ional LSPs. This doesn't happen in case of Associated bidirectional LSPs. I= ts this difference that I wanted the authors to highlight as part of my rev= iew comment.=20 If you think "fate sharing" is not the most appropriate term then you can s= uggest something else as long as you believe its something that ought to be= mentioned. Cheers, Manav=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 > Sent: Monday, October 14, 2013 9:37 AM > To: Bhatia, Manav (Manav) > Cc: rtg-dir@ietf.org;=20 > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org;=20 > mpls@ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 >=20 > Manav, > Lots of thanks for a prompt response. >=20 > I must admit that I've mssed the text in 5960 to which you refer. >=20 > The original definition, to the best of my understanding, is=20 > in Section 1.2.2. of RFC 5654 and says something else: >=20 >=20 > Co-routed Bidirectional path: A path where the forward and backward > directions follow the same route (links and nodes) across the > network. Both directions are setup, monitored and protected as a > single entity. A transport network path is typically co-routed. >=20 > To me this means that if one of the directions of the=20 > co-routed bi-directional path fails to convey traffic, the=20 > monitoring mechanisms will report the entire bi-directional=20 > path as failed. >=20 > To the best of my recollection when I=3DD to become RFC 5960=20 > has been discussed I've asked the authors of RFC 5960 whether=20 > the pairing between two directions of a co-routed=20 > bi-directional MPLS-TP LSP in a transit LSR is limited to OAM=20 > processing, and they (or one of them) have confirmed that=20 > this is indeed so.=20 >=20 > I wonder whether this can be interpreted as "fate-sharing". >=20 > Regards, > Sasha >=20 > ________________________________________ > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > Sent: Monday, October 14, 2013 4:21 AM > To: Alexander Vainshtein > Cc: rtg-dir@ietf.org;=20 > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org;=20 > mpls@ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > Hi Sasha, >=20 > RFC 5960 that describes the MPLS-TP data plane says the following: >=20 > A point-to-point co-routed bidirectional LSP is a=20 > point-to-point associated bidirectional LSP with the=20 > additional constraint that its two unidirectional component=20 > LSPs in each direction follow the same path (in terms of both=20 > nodes and links). An important property of co-routed=20 > bidirectional LSPs is that their unidirectional component=20 > LSPs share fate. >=20 > Am I missing something? >=20 > Cheers, Manav >=20 >=20 > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Sunday, October 13, 2013 9:46 PM > > To: Bhatia, Manav (Manav) > > Cc: rtg-dir@ietf.org; > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > mpls@ietf.org; rtg-ads@tools.ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Manav and all, > > Regarding one of the nits you've identified: > > "it would be useful to mention that an important property=20 > of co-routed=20 > > bidirectional path is that the forward and backward=20 > directions share=20 > > fate." > > > > IMHO and FWIW this is not correct. To the best of my=20 > understanding the=20 > > two directions of an MPLS-TP co-routed bi-directional path share=20 > > lifespan (i.e.,they are set up and torn down in a single=20 > management or=20 > > control plane operation). > > But they do not share fate, as can be seen from the following > > examples: > > > > 1. A unidirectiona fiber cut in one of the links used by a=20 > co-routed=20 > > bi-directional trail will result in traffic failur in the affected=20 > > direction but not necessarily in the reverse one > > > > 2. Consider the case when one of entries the ILM in one of=20 > the transit=20 > > LSRs is corruped. This will result in incorrect failure of a single=20 > > label, but the rest of the labels would be handled correctly. Since=20 > > co-routed bi-directional trails do not require using the=20 > same label in=20 > > both directions of a trail, the fate sharing would be broken. > > (Actually, in such a way it could be easily broken even if the same=20 > > label is used on each segment of the LSP in both > > directions...) > > > > My 2c, > > Sasha > > > > > > > > ________________________________________ > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org]=20 > on behalf of=20 > > Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > Sent: Sunday, October 13, 2013 5:55 PM > > To: rtg-ads@tools.ietf.org > > Cc: rtg-dir@ietf.org; > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > > Subject: [RTG-DIR] RtgDir review: > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this=20 > > draft. The Routing Directorate seeks to review all routing or=20 > > routing-related drafts as they pass through IETF last call and IESG=20 > > review, and sometimes on special request. > > The purpose of the review is to provide assistance to the=20 > Routing ADs.=20 > > For more information about the Routing Directorate, please=20 > > seehttp://www.ietf.org/iesg/directorate/routing.html > > > > Although these comments are primarily for the use of the=20 > Routing ADs,=20 > > it would be helpful if you could consider them along with any other=20 > > IETF Last Call comments that you receive, and strive to=20 > resolve them=20 > > through discussion or by updating the draft. > > > > Document: draft-ietf-mpls-tp-rosetta-stone-12.txt > > Reviewer: Manav Bhatia > > Review Date: October 13th, 2013 > > IETF LC End Date: October 16, 2013 > > Intended Status: Informational > > > > Summary: This document is basically ready for publication, but has=20 > > nits that should be considered prior to publication. > > > > Comments: This document is built on top of terms already defined in=20 > > different RFCs and ITU-T documents. The terms and definitions have=20 > > already been reviewed so there is a trifle little that needs to be=20 > > done there. Overall, the document looks good and ready for=20 > > publication. Some of my comments can be > > > > Nits: > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > o) When explaining Control Plane (3.6) should we mention that it is=20 > > possible to operate an MPLS-TP network without using a=20 > Control Plane? > > > > o) In 3.7, it would be useful to mention that an important=20 > property of=20 > > co-routed bidirectional path is that the forward and backward=20 > > directions share fate. Similarly, in 3.1, we should mention=20 > that the=20 > > forward and backward directions don't share fate. > > > > o) 3.12 in the current text doesn't look very helpful. Can it be=20 > > rephrased it to something like, "The equipment management function=20 > > (EMF) provides the means through which an element management system=20 > > (EMS) and other managing entities manage the network=20 > element function=20 > > (NEF)." > > > > o) 3.13 talks about Fault cause without explaining what a=20 > fault cause=20 > > is. It took me some time to understand what was meant by "fault=20 > > cause". Can the authors of the draft rephrase > > 3.13 in their own language to explain what they mean by a=20 > Failure. The=20 > > current definition in the draft has been picked up as-is from ITU-T=20 > > G.806 > > > > o) 3.14 talks about "inability of a function to perform a required=20 > > action". Since this RFC-to-be is in the IETF domain, can this be=20 > > rephrased to use a term like router/switch instead of a=20 > more esoteric=20 > > "function". This is a general comment and applies to most of the=20 > > definitions that have been copied from the ITU-T documents. > > > > o) The last paragraph of 3.17 says the following: > > > > "OAM packets are subject to the same forwarding treatment=20 > as the data=20 > > traffic, but they are distinct from the data traffic." > > > > In what sense are the OAM packets distinct from the data traffic? > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been=20 > > expanded in the document. > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > o) In 3.28.3, can the following text be added: > > > > An LSP segment comprises one or more continuous hops on the path of=20 > > the LSP. [RFC5654] defines two terms. A "segment" > > is a single hop along the path of an LSP, while a "concatenated=20 > > segment" is more than one hop along the path of an LSP. > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more=20 > common term=20 > > than Operations Systems (OS)? > > > > Cheers, Manav > > > > This e-mail message is intended for the recipient only and contains=20 > > information which is CONFIDENTIAL and which may be=20 > proprietary to ECI=20 > > Telecom. If you have received this transmission in error, please=20 > > inform us by e-mail, phone or fax, and then delete the original and=20 > > all copies thereof. > > > > >=20 > This e-mail message is intended for the recipient only and=20 > contains information which is CONFIDENTIAL and which may be=20 > proprietary to ECI Telecom. If you have received this=20 > transmission in error, please inform us by e-mail, phone or=20 > fax, and then delete the original and all copies thereof. >=20 > = From Alexander.Vainshtein@ecitele.com Sun Oct 13 23:21:49 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF7411E8114; Sun, 13 Oct 2013 23:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 VC9jRiXvP6xl; Sun, 13 Oct 2013 23:21:45 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1F11711E810E; Sun, 13 Oct 2013 23:21:43 -0700 (PDT) X-AuditID: 93eaf2e7-b7f596d000004d89-d1-525b8d754b28 Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 8E.E4.19849.57D8B525; Mon, 14 Oct 2013 08:21:42 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 09:21:41 +0300 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BYAAE12wgAAQYTQ= Date: Mon, 14 Oct 2013 06:21:41 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTe0hTURjn7G7rurx1NW3HFXQ7Pf6oZo4MFroKMrAokwq0Uuq6nbZb2924 d4kriAlBFCVF7/UysPcgSMVeUK6isndSlGH0sEYra2lR633ubpoQ3b9+5/we33cu30dT6Z16 Ey2IfiyJvBvpDdotsa6P5sqNi+bm/IiarG0Hj+qs0T27tNba8Mt+U6nCurqEpvBja7e+WLMw CPJ5UfT6eT/mHFi221CxJFTy9gDiBIcNWRDnc/N27MGi34Z4nw+LDjTZwP3z5ROZIHJYtHsd gui0oRnz5pit1omTzBY0efQIy4Q8w3yXIHPY7OEFN+fBssw7MUduljRQrs5ETOerr6h68D1K BcHDovUghYZsLnxyvkav4sHwzpMTBBvodLYZwJqbx7Tq4TKAVzoTQFHpWRs8ebw96cggOFp/ Jimi2DiA8eBTnUIMYqfB648uAFVUAEM3bmhUXATbX72nFKxlR8E3h58lNQxbDOPV3X+qbaDg u41tSSKFLYc1rc1JDEh/n1vCySCKNcK2jv0atW8W1p27Tak4E75+8VOn4mHwbvzpH/04WHu2 S6/isfDQgTeUWjgNXtvVoVX1WbD5yEPtJmAM9SkR6mMP9bGH+thrgfYYyBTcPn+Fx5ljycZ2 wY/dONvu9ZwE6qxET4Gv+0dGAEsDlMq4ChbNTdfxlXLAEwFZtAZlMvXrydWACq8j4OJl12Jp hRvLEQBpCmUw91cTjnHwgZVY8vZQ08kv3EyZ+tu9ZCpF/+IJOTn/PyAjczhYMieddZIhXI6x D0s9OUNpGkHm+QZSIk3CTly1VHD7/9IaOkVpI5W08UHRMLKP98iCU+VbwHCTkXmvEKxCuFaI vd6eLYkBI3n0IKZLUaWSHep1x0iwhgQnOkuVYLIgvZQpCDLbU6YMOJf/pel0oOREuMC8OUtX tftX662ykh93Dm0/Urikf9kVKbbsG4pk5IndyxNDZs/6lJb7mFt3dXykxbYj+/ul1wO/rc01 LHOsineVv6q2Hb1YPLqhEc1smkoltjZKpftKreHL5W8XlDVsrS5bXbOpaOeOwjV78zq2fa4H 98J5SCu7eMsYSpL53/ytMSwABAAA Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 06:21:50 -0000 Manav, Lots of thanks for a prompt response. I fully agree that the confusion is over what "fate-sharing" means. E.g., OAM for an MPLS-TP LSP and user traffic that is carried by such an LSP= are fate-sharing by design: * Your interpretation (as I understand from your example) mainly deals with= the control/management plane aspects of an LSP. From this point of view the= forward and backward directions of a co-routed bi-directional LSP are indee= d fate-sharing. E.g., the definition in 5654 implies (from my point of view)= that the corresdponding data plane configuration is set up/torn down atomic= ally. However, if I extend/tweak your example a bit, I could say that unidirection= al MP2M LSPs set up by LDP within a given AS are fate-sharing with IP traff= ic paths set up by the IGP running in this AS - but somehow I do not feel th= at such a usage of the term "fate-sharing" would be appropriate. (If it were= . there would be no need for LSP Ping...) * My interpretation includes also the data plane aspects of an LSP. E.g., u= ser traffic in an MPLS-TP LSP (of any type) and its OAM packets are fate-sha= ring by design, because exactly the same part of the label stack is looked f= or forwarding decisions (please note that both identification of OAM packets= using GAL/GACH and prohibition of ECMP are part of this design). But two di= rections of a co-routed bi-direction LSP are not fate-sharing in this sense= IMHO - unless such an LSP is (a) monitored using some OAM mechanism and (b)= user traffic is blocked on both directions of an LSP if the monitoring mech= anism reports that one direction has failed. However, it is usually possibl= e to say which direction has really failed in the case of a uni-directional= failure: e.g., the local diagnostic of the BFD session - if used for monito= ring - would report time-out expiration at one endpoint and "peer declared s= ession down" at the other endpoint. ________________________________________ From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] Sent: Monday, October 14, 2013 7:26 AM To: Alexander Vainshtein Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; m= pls@ietf.org; rtg-ads@tools.ietf.org Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Sasha, I think the confusion is over what we mean by "fate sharing". To me, if the forward path is torn down for some reason, and that results in= the backward path being torn down as well, then they inextricably "share th= e fate". If the path of the forward LSP changes because of an IGP trigger, then the b= ackward LSP changes too in case of co-routed bidirectional LSPs. However, th= is isn't true in case of Associated bidirectional LSPs. Similarly, an IGP ch= ange (or a network event -- link/node flap, link/node down) will always resu= lt in both directions changing their path in case of co-routed bidirectional= LSPs. This doesn't happen in case of Associated bidirectional LSPs. Its thi= s difference that I wanted the authors to highlight as part of my review com= ment. If you think "fate sharing" is not the most appropriate term then you can su= ggest something else as long as you believe its something that ought to be m= entioned. Cheers, Manav > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, October 14, 2013 9:37 AM > To: Bhatia, Manav (Manav) > Cc: rtg-dir@ietf.org; > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > mpls@ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > Manav, > Lots of thanks for a prompt response. > > I must admit that I've mssed the text in 5960 to which you refer. > > The original definition, to the best of my understanding, is > in Section 1.2.2. of RFC 5654 and says something else: > > > Co-routed Bidirectional path: A path where the forward and backward > directions follow the same route (links and nodes) across the > network. Both directions are setup, monitored and protected as a > single entity. A transport network path is typically co-routed. > > To me this means that if one of the directions of the > co-routed bi-directional path fails to convey traffic, the > monitoring mechanisms will report the entire bi-directional > path as failed. > > To the best of my recollection when I=3DD to become RFC 5960 > has been discussed I've asked the authors of RFC 5960 whether > the pairing between two directions of a co-routed > bi-directional MPLS-TP LSP in a transit LSR is limited to OAM > processing, and they (or one of them) have confirmed that > this is indeed so. > > I wonder whether this can be interpreted as "fate-sharing". > > Regards, > Sasha > > ________________________________________ > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > Sent: Monday, October 14, 2013 4:21 AM > To: Alexander Vainshtein > Cc: rtg-dir@ietf.org; > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > mpls@ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > Hi Sasha, > > RFC 5960 that describes the MPLS-TP data plane says the following: > > A point-to-point co-routed bidirectional LSP is a > point-to-point associated bidirectional LSP with the > additional constraint that its two unidirectional component > LSPs in each direction follow the same path (in terms of both > nodes and links). An important property of co-routed > bidirectional LSPs is that their unidirectional component > LSPs share fate. > > Am I missing something? > > Cheers, Manav > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Sunday, October 13, 2013 9:46 PM > > To: Bhatia, Manav (Manav) > > Cc: rtg-dir@ietf.org; > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > mpls@ietf.org; rtg-ads@tools.ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Manav and all, > > Regarding one of the nits you've identified: > > "it would be useful to mention that an important property > of co-routed > > bidirectional path is that the forward and backward > directions share > > fate." > > > > IMHO and FWIW this is not correct. To the best of my > understanding the > > two directions of an MPLS-TP co-routed bi-directional path share > > lifespan (i.e.,they are set up and torn down in a single > management or > > control plane operation). > > But they do not share fate, as can be seen from the following > > examples: > > > > 1. A unidirectiona fiber cut in one of the links used by a > co-routed > > bi-directional trail will result in traffic failur in the affected > > direction but not necessarily in the reverse one > > > > 2. Consider the case when one of entries the ILM in one of > the transit > > LSRs is corruped. This will result in incorrect failure of a single > > label, but the rest of the labels would be handled correctly. Since > > co-routed bi-directional trails do not require using the > same label in > > both directions of a trail, the fate sharing would be broken. > > (Actually, in such a way it could be easily broken even if the same > > label is used on each segment of the LSP in both > > directions...) > > > > My 2c, > > Sasha > > > > > > > > ________________________________________ > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] > on behalf of > > Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > Sent: Sunday, October 13, 2013 5:55 PM > > To: rtg-ads@tools.ietf.org > > Cc: rtg-dir@ietf.org; > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > > Subject: [RTG-DIR] RtgDir review: > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > 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, and sometimes on special request. > > The purpose of the review is to provide assistance to the > Routing ADs. > > For more information about the Routing Directorate, please > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > Reviewer: Manav Bhatia > > Review Date: October 13th, 2013 > > IETF LC End Date: October 16, 2013 > > Intended Status: Informational > > > > Summary: This document is basically ready for publication, but has > > nits that should be considered prior to publication. > > > > Comments: This document is built on top of terms already defined in > > different RFCs and ITU-T documents. The terms and definitions have > > already been reviewed so there is a trifle little that needs to be > > done there. Overall, the document looks good and ready for > > publication. Some of my comments can be > > > > Nits: > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > o) When explaining Control Plane (3.6) should we mention that it is > > possible to operate an MPLS-TP network without using a > Control Plane? > > > > o) In 3.7, it would be useful to mention that an important > property of > > co-routed bidirectional path is that the forward and backward > > directions share fate. Similarly, in 3.1, we should mention > that the > > forward and backward directions don't share fate. > > > > o) 3.12 in the current text doesn't look very helpful. Can it be > > rephrased it to something like, "The equipment management function > > (EMF) provides the means through which an element management system > > (EMS) and other managing entities manage the network > element function > > (NEF)." > > > > o) 3.13 talks about Fault cause without explaining what a > fault cause > > is. It took me some time to understand what was meant by "fault > > cause". Can the authors of the draft rephrase > > 3.13 in their own language to explain what they mean by a > Failure. The > > current definition in the draft has been picked up as-is from ITU-T > > G.806 > > > > o) 3.14 talks about "inability of a function to perform a required > > action". Since this RFC-to-be is in the IETF domain, can this be > > rephrased to use a term like router/switch instead of a > more esoteric > > "function". This is a general comment and applies to most of the > > definitions that have been copied from the ITU-T documents. > > > > o) The last paragraph of 3.17 says the following: > > > > "OAM packets are subject to the same forwarding treatment > as the data > > traffic, but they are distinct from the data traffic." > > > > In what sense are the OAM packets distinct from the data traffic? > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been > > expanded in the document. > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > o) In 3.28.3, can the following text be added: > > > > An LSP segment comprises one or more continuous hops on the path of > > the LSP. [RFC5654] defines two terms. A "segment" > > is a single hop along the path of an LSP, while a "concatenated > > segment" is more than one hop along the path of an LSP. > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more > common term > > than Operations Systems (OS)? > > > > Cheers, Manav > > > > This e-mail message is intended for the recipient only and contains > > information which is CONFIDENTIAL and which may be > proprietary to ECI > > Telecom. If you have received this transmission in error, please > > inform us by e-mail, phone or fax, and then delete the original and > > all copies thereof. > > > > > > This e-mail message is intended for the recipient only and > contains information which is CONFIDENTIAL and which may be > proprietary to ECI Telecom. If you have received this > transmission in error, please inform us by e-mail, phone or > fax, and then delete the original and all copies thereof. > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Mon Oct 14 01:08:27 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D2511E8180; Mon, 14 Oct 2013 01:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 lihA10H7OxYN; Mon, 14 Oct 2013 01:08:16 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id C14FA11E817A; Mon, 14 Oct 2013 01:08:12 -0700 (PDT) X-AuditID: 93eaf2e7-b7f596d000004d89-33-525ba669d2aa Received: from ILPTWPVEXCA01.ecitele.com ( [172.31.244.224]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id B4.E8.19849.966AB525; Mon, 14 Oct 2013 10:08:09 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 11:08:09 +0300 From: Alexander Vainshtein To: Gregory Mirsky Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BYAAE12wgAAS/oCAAB9uEA== Date: Mon, 14 Oct 2013 08:08:09 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B6F8E0D@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B6F8E0D@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTS0wTURTNm5mWoXbIUME+GkPKiCZ+Cq2gqdKi8RN1oSIaNSLBoX22E9tp 0yloWeFGI24ghChdCCoCKkaDLowahcYfWITET6ACLiwRQUOCGIOAOtMRJDHO6rx3zj3nvsm9 JK75otSRHO9HPp51MUoVUT0yPmHgGgvyjZ/7M83t028Ic+TKVYW5vmUobiO+vaFhEts+8eqr Mg87VA4sLM97/Kwf6e1IsFmZPB9XytoCjJ6zWxkTo/e6WBtyI95vZVivF/F2Jlel/+eziDKO 1yPe5rFzvMPK7Ni722A2r1lnMDG5y5aYsnJU+5ycoEcGN8u59G4kCKwD6cWbI3dw5+v71YT3 ZfGJoep+ZTn4trMCxJOQzoYdNx/GyXgR7Bm8qawAKlJDtwPYM30mTj48AXBo8DEuqZS0FbZe H1BKOIk2wneNTbgkwukbGGx+/kghEQvpzfBFXxuQRVtgMBzGZLwfXpxqjWkIeim8VROORVN0 Hpx5ev5P9Bsc/nrWERPF07tgb92pmAiI/X3vbIkZ4bQWRqJ1mNw3DRsedOMyToafPvxUyDgV RqOdhKxfBevvjytlvBI2XhzF5eBE2FEbJWR9Cmxv7iUqgTY4LyI4rzw4rzw4r7weENdAMufy +ovdDqMpA9k4P3KhDJvH3QrkWfl4F/yoSw8BmgSMmnJuKcjXKNhSIeAOgRQSY5IpxRXxKqHY Yw84WcFZ5CtxISEEIIkzSVTiBZGj7GygDPk8s9RW8RdW4boFNo84lby/KMto/P+B0VJN5Qd2 a2iHOITHEPIi36zPYpJkIKWR4hN9yIFOHOVc/r80RsZLbajFNkYbpDYEL+sWOIfMd4I0nZY6 e1kkaIlwlvBztbNbMgK04qMXUulShFrcobnqEdEYE40nvxyUjMUFmaN05eBc1462plOHa1r6 +eNTV4ffr0XkJaPhcerwtuzxgYJjw4EKYkPOnmXYtTJhZSgtY0Hk4dvRrkg0M5TQlDkztv/Z 6u4bliOllqf37s1khSOb1p9WXagKT6aOqUFOi64tKcWiLYus6L/dTT9KOz3VV1vg+3Bm+cnK YOFS9Zr3HfmFYwwhOFnTCtwnsL8Byn4vqwAEAAA= Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 08:08:30 -0000 Greg, Lots of thanks for an important comment. Regarding your example: my personal interpretation of 5654 is like following= : - Co-routed bidirectional LSPs MAY be protected using bi-directional protect= ion schemes but MUST NOT be protected using unidirectional ones - Associated bidirectional LSPs MAY be protected using both unidirectional a= nd bi-directional protection schemes Does this match your understanding? Regards, Sasha > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, October 14, 2013 9:23 AM > To: Bhatia, Manav (Manav); Alexander Vainshtein > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; draft-ietf-mpls-tp-rosetta- > stone.all@tools.ietf.org; mpls@ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > Hi Manav, > I do feel that "fate sharing" already has certain interpretation in the in= dustry. > Difference in, for example, protection between co-routed and associated bi= - > directional LSPs doesn't seem not to be described by "fate sharing". I thi= nk of it > as in co-routed case LSP protected as a single entity while in associated= case > each direction of LSP is protected independently of the other. > > Regards, > Greg > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Bhatia, Manav (Manav) > Sent: Sunday, October 13, 2013 10:26 PM > To: Alexander Vainshtein > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; draft-ietf-mpls-tp-rosetta- > stone.all@tools.ietf.org; mpls@ietf.org > Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > Sasha, > > I think the confusion is over what we mean by "fate sharing". > > To me, if the forward path is torn down for some reason, and that results= in the > backward path being torn down as well, then they inextricably "share the f= ate". > > If the path of the forward LSP changes because of an IGP trigger, then the > backward LSP changes too in case of co-routed bidirectional LSPs. However,= this > isn't true in case of Associated bidirectional LSPs. Similarly, an IGP cha= nge (or a > network event -- link/node flap, link/node down) will always result in bot= h > directions changing their path in case of co-routed bidirectional LSPs. Th= is > doesn't happen in case of Associated bidirectional LSPs. Its this differen= ce that > I wanted the authors to highlight as part of my review comment. > > If you think "fate sharing" is not the most appropriate term then you can > suggest something else as long as you believe its something that ought to= be > mentioned. > > Cheers, Manav > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Monday, October 14, 2013 9:37 AM > > To: Bhatia, Manav (Manav) > > Cc: rtg-dir@ietf.org; > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > mpls@ietf.org; rtg-ads@tools.ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Manav, > > Lots of thanks for a prompt response. > > > > I must admit that I've mssed the text in 5960 to which you refer. > > > > The original definition, to the best of my understanding, is > > in Section 1.2.2. of RFC 5654 and says something else: > > > > > > Co-routed Bidirectional path: A path where the forward and backward > > directions follow the same route (links and nodes) across the > > network. Both directions are setup, monitored and protected as a > > single entity. A transport network path is typically co-routed. > > > > To me this means that if one of the directions of the > > co-routed bi-directional path fails to convey traffic, the > > monitoring mechanisms will report the entire bi-directional > > path as failed. > > > > To the best of my recollection when I=3DD to become RFC 5960 > > has been discussed I've asked the authors of RFC 5960 whether > > the pairing between two directions of a co-routed > > bi-directional MPLS-TP LSP in a transit LSR is limited to OAM > > processing, and they (or one of them) have confirmed that > > this is indeed so. > > > > I wonder whether this can be interpreted as "fate-sharing". > > > > Regards, > > Sasha > > > > ________________________________________ > > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > Sent: Monday, October 14, 2013 4:21 AM > > To: Alexander Vainshtein > > Cc: rtg-dir@ietf.org; > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > mpls@ietf.org; rtg-ads@tools.ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Hi Sasha, > > > > RFC 5960 that describes the MPLS-TP data plane says the following: > > > > A point-to-point co-routed bidirectional LSP is a > > point-to-point associated bidirectional LSP with the > > additional constraint that its two unidirectional component > > LSPs in each direction follow the same path (in terms of both > > nodes and links). An important property of co-routed > > bidirectional LSPs is that their unidirectional component > > LSPs share fate. > > > > Am I missing something? > > > > Cheers, Manav > > > > > > > -----Original Message----- > > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > > Sent: Sunday, October 13, 2013 9:46 PM > > > To: Bhatia, Manav (Manav) > > > Cc: rtg-dir@ietf.org; > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Manav and all, > > > Regarding one of the nits you've identified: > > > "it would be useful to mention that an important property > > of co-routed > > > bidirectional path is that the forward and backward > > directions share > > > fate." > > > > > > IMHO and FWIW this is not correct. To the best of my > > understanding the > > > two directions of an MPLS-TP co-routed bi-directional path share > > > lifespan (i.e.,they are set up and torn down in a single > > management or > > > control plane operation). > > > But they do not share fate, as can be seen from the following > > > examples: > > > > > > 1. A unidirectiona fiber cut in one of the links used by a > > co-routed > > > bi-directional trail will result in traffic failur in the affected > > > direction but not necessarily in the reverse one > > > > > > 2. Consider the case when one of entries the ILM in one of > > the transit > > > LSRs is corruped. This will result in incorrect failure of a single > > > label, but the rest of the labels would be handled correctly. Since > > > co-routed bi-directional trails do not require using the > > same label in > > > both directions of a trail, the fate sharing would be broken. > > > (Actually, in such a way it could be easily broken even if the same > > > label is used on each segment of the LSP in both > > > directions...) > > > > > > My 2c, > > > Sasha > > > > > > > > > > > > ________________________________________ > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] > > on behalf of > > > Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > Sent: Sunday, October 13, 2013 5:55 PM > > > To: rtg-ads@tools.ietf.org > > > Cc: rtg-dir@ietf.org; > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > > > Subject: [RTG-DIR] RtgDir review: > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > 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, and sometimes on special request. > > > The purpose of the review is to provide assistance to the > > Routing ADs. > > > For more information about the Routing Directorate, please > > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > > Reviewer: Manav Bhatia > > > Review Date: October 13th, 2013 > > > IETF LC End Date: October 16, 2013 > > > Intended Status: Informational > > > > > > Summary: This document is basically ready for publication, but has > > > nits that should be considered prior to publication. > > > > > > Comments: This document is built on top of terms already defined in > > > different RFCs and ITU-T documents. The terms and definitions have > > > already been reviewed so there is a trifle little that needs to be > > > done there. Overall, the document looks good and ready for > > > publication. Some of my comments can be > > > > > > Nits: > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > o) When explaining Control Plane (3.6) should we mention that it is > > > possible to operate an MPLS-TP network without using a > > Control Plane? > > > > > > o) In 3.7, it would be useful to mention that an important > > property of > > > co-routed bidirectional path is that the forward and backward > > > directions share fate. Similarly, in 3.1, we should mention > > that the > > > forward and backward directions don't share fate. > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be > > > rephrased it to something like, "The equipment management function > > > (EMF) provides the means through which an element management system > > > (EMS) and other managing entities manage the network > > element function > > > (NEF)." > > > > > > o) 3.13 talks about Fault cause without explaining what a > > fault cause > > > is. It took me some time to understand what was meant by "fault > > > cause". Can the authors of the draft rephrase > > > 3.13 in their own language to explain what they mean by a > > Failure. The > > > current definition in the draft has been picked up as-is from ITU-T > > > G.806 > > > > > > o) 3.14 talks about "inability of a function to perform a required > > > action". Since this RFC-to-be is in the IETF domain, can this be > > > rephrased to use a term like router/switch instead of a > > more esoteric > > > "function". This is a general comment and applies to most of the > > > definitions that have been copied from the ITU-T documents. > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > "OAM packets are subject to the same forwarding treatment > > as the data > > > traffic, but they are distinct from the data traffic." > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been > > > expanded in the document. > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > o) In 3.28.3, can the following text be added: > > > > > > An LSP segment comprises one or more continuous hops on the path of > > > the LSP. [RFC5654] defines two terms. A "segment" > > > is a single hop along the path of an LSP, while a "concatenated > > > segment" is more than one hop along the path of an LSP. > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more > > common term > > > than Operations Systems (OS)? > > > > > > Cheers, Manav > > > > > > This e-mail message is intended for the recipient only and contains > > > information which is CONFIDENTIAL and which may be > > proprietary to ECI > > > Telecom. If you have received this transmission in error, please > > > inform us by e-mail, phone or fax, and then delete the original and > > > all copies thereof. > > > > > > > > > > This e-mail message is intended for the recipient only and > > contains information which is CONFIDENTIAL and which may be > > proprietary to ECI Telecom. If you have received this > > transmission in error, please inform us by e-mail, phone or > > fax, and then delete the original and all copies thereof. > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From jdrake@juniper.net Mon Oct 14 06:42:27 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B0621F9CAF; Mon, 14 Oct 2013 06:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.747 X-Spam-Level: X-Spam-Status: No, score=-3.747 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, 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 4t3jY3mkX8S6; Mon, 14 Oct 2013 06:42:21 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id F0A3121E816B; Mon, 14 Oct 2013 06:42:20 -0700 (PDT) Received: from mail41-co9-R.bigfish.com (10.236.132.244) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 13:42:15 +0000 Received: from mail41-co9 (localhost [127.0.0.1]) by mail41-co9-R.bigfish.com (Postfix) with ESMTP id 4F6A3780152; Mon, 14 Oct 2013 13:42:15 +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: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail41-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=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(189002)(199002)(13464003)(54316002)(56776001)(85306002)(81686001)(76482001)(65816001)(66066001)(80022001)(74366001)(79102001)(77982001)(63696002)(59766001)(81816001)(74876001)(74706001)(83072001)(69226001)(47736001)(49866001)(50986001)(47976001)(53806001)(51856001)(46102001)(4396001)(83322001)(74502001)(19580405001)(74662001)(54356001)(80976001)(19580395003)(47446002)(31966008)(81542001)(74316001)(76796001)(76786001)(76576001)(81342001)(77096001)(33646001)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail41-co9 (localhost.localdomain [127.0.0.1]) by mail41-co9 (MessageSwitch) id 1381758133764023_19985; Mon, 14 Oct 2013 13:42:13 +0000 (UTC) Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.238]) by mail41-co9.bigfish.com (Postfix) with ESMTP id AD88444007D; Mon, 14 Oct 2013 13:42:13 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 13:42:11 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 14 Oct 2013 13:42:10 +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.775.9; Mon, 14 Oct 2013 13:42:08 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.188]) with mapi id 15.00.0775.005; Mon, 14 Oct 2013 13:42:07 +0000 From: John E Drake To: Alexander Vainshtein , "Bhatia, Manav (Manav)" Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gAFpNkA= Date: Mon, 14 Oct 2013 13:42:07 +0000 Message-ID: <5ca0484c5ca745bbabd93bb799afaca8@BY2PR05MB142.namprd05.prod.outlook.com> References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.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.232.2] x-forefront-prvs: 0999136621 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$ecitele.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%ECITELE.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 13:42:27 -0000 Sasha, I think your comments apply equally to bidirectional LSPs. Yours Irrespectively, John > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behal= f Of > Alexander Vainshtein > Sent: Sunday, October 13, 2013 9:16 AM > To: Bhatia, Manav (Manav) > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; draft-ietf-mpls-tp-rosetta- > stone.all@tools.ietf.org; mpls@ietf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12= .txt >=20 > Manav and all, > Regarding one of the nits you've identified: > "it would be useful to mention that an important property of co-routed > bidirectional path is that the forward and backward directions share fate= ." >=20 > IMHO and FWIW this is not correct. To the best of my understanding the tw= o > directions of an MPLS-TP co-routed bi-directional path share lifespan (i.= e.,they > are set up and torn down in a single management or control plane operatio= n). > But they do not share fate, as can be seen from the following examples: >=20 > 1. A unidirectiona fiber cut in one of the links used by a co-routed bi-d= irectional > trail will result in traffic failur in the affected direction but not nec= essarily in the > reverse one >=20 > 2. Consider the case when one of entries the ILM in one of the transit LS= Rs is > corruped. This will result in incorrect failure of a single label, but th= e rest of the > labels would be handled correctly. Since co-routed bi-directional trails = do not > require using the same label in both directions of a trail, the fate shar= ing would > be broken. > (Actually, in such a way it could be easily broken even if the same label= is used > on each segment of the LSP in both directions...) >=20 > My 2c, > Sasha >=20 >=20 >=20 > ________________________________________ > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on behalf of Bh= atia, > Manav (Manav) [manav.bhatia@alcatel-lucent.com] > Sent: Sunday, October 13, 2013 5:55 PM > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org= ; > mpls@ietf.org > Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > Hello, >=20 > 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, and sometimes on specia= l > request. The purpose of the review is to provide assistance to the Routin= g > ADs. For more information about the Routing Directorate, please > seehttp://www.ietf.org/iesg/directorate/routing.html >=20 > 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 Las= t Call > comments that you receive, and strive to resolve them through discussion = or > by updating the draft. >=20 > Document: draft-ietf-mpls-tp-rosetta-stone-12.txt > Reviewer: Manav Bhatia > Review Date: October 13th, 2013 > IETF LC End Date: October 16, 2013 > Intended Status: Informational >=20 > Summary: This document is basically ready for publication, but has nits = that > should be considered prior to publication. >=20 > Comments: This document is built on top of terms already defined in diffe= rent > RFCs and ITU-T documents. The terms and definitions have already been > reviewed so there is a trifle little that needs to be done there. Overall= , the > document looks good and ready for publication. Some of my comments can be >=20 > Nits: >=20 > o) Please expand PW in either the Abstract or Sec 3.5 >=20 > o) When explaining Control Plane (3.6) should we mention that it is possi= ble to > operate an MPLS-TP network without using a Control Plane? >=20 > o) In 3.7, it would be useful to mention that an important property of co= -routed > bidirectional path is that the forward and backward directions share fate= . > Similarly, in 3.1, we should mention that the forward and backward direct= ions > don't share fate. >=20 > o) 3.12 in the current text doesn't look very helpful. Can it be rephrase= d it to > something like, "The equipment management function (EMF) provides the > means through which an element management system (EMS) and other > managing entities manage the network element function (NEF)." >=20 > o) 3.13 talks about Fault cause without explaining what a fault cause is.= It took > me some time to understand what was meant by "fault cause". Can the > authors of the draft rephrase 3.13 in their own language to explain what = they > mean by a Failure. The current definition in the draft has been picked up= as-is > from ITU-T G.806 >=20 > o) 3.14 talks about "inability of a function to perform a required action= ". Since > this RFC-to-be is in the IETF domain, can this be rephrased to use a term= like > router/switch instead of a more esoteric "function". This is a general co= mment > and applies to most of the definitions that have been copied from the ITU= -T > documents. >=20 > o) The last paragraph of 3.17 says the following: >=20 > "OAM packets are subject to the same forwarding treatment as the data > traffic, but they are distinct from the data traffic." >=20 > In what sense are the OAM packets distinct from the data traffic? >=20 > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been expan= ded > in the document. >=20 > o) Sec 3.19 uses TCM without expanding it first. >=20 > o) In Sec 3.23, s/Tandem Connections/Tandem Connection >=20 > o) In 3.28.3, can the following text be added: >=20 > An LSP segment comprises one or more continuous hops on the path of the > LSP. [RFC5654] defines two terms. A "segment" is a single hop along the= path > of an LSP, while a "concatenated segment" is more than one hop along the > path of an LSP. >=20 > o) In 3.31, Isn't Operations Support Systems (OSS) a more common term tha= n > Operations Systems (OS)? >=20 > Cheers, Manav >=20 > This e-mail message is intended for the recipient only and contains infor= mation > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this transmission in error, please inform us by e-mail, pho= ne or > fax, and then delete the original and all copies thereof. >=20 >=20 From Alexander.Vainshtein@ecitele.com Mon Oct 14 07:34:11 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC52D11E8144; Mon, 14 Oct 2013 07:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 sp9adFrU2s1o; Mon, 14 Oct 2013 07:34:07 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96C11E8184; Mon, 14 Oct 2013 07:34:06 -0700 (PDT) X-AuditID: 93eaf2e7-b7f586d00000770a-e9-525c00dcc6ca Received: from ILPTWPVEXCA01.ecitele.com ( [172.31.244.224]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 0E.A2.30474.CD00C525; Mon, 14 Oct 2013 16:34:04 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 17:34:04 +0300 From: Alexander Vainshtein To: John E Drake Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gAFpNkCAAA4F4A== Date: Mon, 14 Oct 2013 14:34:04 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5ca0484c5ca745bbabd93bb799afaca8@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <5ca0484c5ca745bbabd93bb799afaca8@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTfUgTYRjvvbut8+Pimh97Wx+s6wMqPzbMWNkkysLwj6SiosQ6b6/b5XYb u1NcQfhHZqhFIZItyxXOyopK7AOyWlaUJlhElIJCtYqUPlhFGfRxt0sTovvr9z6/j/d5j+ch cd2w1kDygoS8AutktLFE3VDkc+rAhIK1pt4n8ZbGwUGNpT94WmMJnH01cRmeW/n6uia3uXkE y8c2V4ClrCC4JVZCRhsSOSuT7+XLWM7HGHmblTEzRo+T5ZALCZKVYT0eJNiY7FjjP99SWcYL RiRwbhsv2K3M6nVrUi2WzMWpZiZ77ixzRlbsegcvGlGqi+WdRhcSRdaOjHJlWzvuqGy8R3ge Lym/0TWCV4BjadUghoT0QniiO4SpOBk+HDyvrQaxpI6+BWBr1XONergLYM37ExpFpaWtsO3M gFbBifQcOBx5G3Xg9DkMnrp/MypKoFfAB30hoIpyoL+nB1Pxctj44zKhYEI2hwOtE6sBSVJ0 PgzeLVPKOvoDgEeq0hUcQ2+Ab151ReVA7u5r99loDE7rYX+46U/XNGzu6MVVnATfvvypUfEM GA53E6o+BQauRbQqXgBbjg9H9RQ9GXYdDhOqfgq8deoZcQDo/eOu8I+z+8fZ/ePsAUC0giTe 6ZGKXHaTOQ1xvIScKI1zu9qAOilvroLvTbM7AU0CJp5y5GxZq9OwZaLP1QmmkBiTRA39kkuT itw2n4MVHVu9pU4kdgJI4kwi5Xonc5SN9e1AXvcotVL+gQdxQxznlmdSkLZmmEz/PzB66mTF xjU62i6PYAlCHuQdzZlGkgykOpXrJ3uRHZUX807pL42RMUob8XIbVxUNJXpYl8jbVb4bzDTo qcsKQSuEo1QY847uyBDQy49OoEKKKl7eoDH3kByMycEj7zYpwfJ6jFGGCnC7Blu1aP2nfU13 lhhYLthS8KU+52P6peKplW31IX3Vht01kdMnG+p+4BqpRQz8uoLtzGvfg7ht4Fyh2Lp7f2nc sfb+4K7t6c01ujqaKgi5s9qSC0u7+hoe+VKq5iVkVh96kdVRe2Hv95SBp5UXk7+lHzUFI7V5 00t6joNI0+I8hhAdrHk+7hXZ35s/8Tj+AwAA Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:34:11 -0000 John, Not sure I fully understood your message. My comments have been about applicability of the term "fate-sharing" to the= two directions of a co-routed bi-directional LSP. It is of course true that each direction of an associated bi-directional LSP= can fail independently of the other one, but, presumably, nobody has expect= ed anything else in this case. Regards, Sasha > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Monday, October 14, 2013 4:42 PM > To: Alexander Vainshtein; Bhatia, Manav (Manav) > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; draft-ietf-mpls-tp-rosetta- > stone.all@tools.ietf.org; mpls@ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > Sasha, > > I think your comments apply equally to bidirectional LSPs. > > Yours Irrespectively, > > John > > > -----Original Message----- > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Beha= lf > Of > > Alexander Vainshtein > > Sent: Sunday, October 13, 2013 9:16 AM > > To: Bhatia, Manav (Manav) > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; draft-ietf-mpls-tp-rosetta= - > > stone.all@tools.ietf.org; mpls@ietf.org > > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-1= 2.txt > > > > Manav and all, > > Regarding one of the nits you've identified: > > "it would be useful to mention that an important property of co-routed > > bidirectional path is that the forward and backward directions share fat= e." > > > > IMHO and FWIW this is not correct. To the best of my understanding the t= wo > > directions of an MPLS-TP co-routed bi-directional path share lifespan (i= .e.,they > > are set up and torn down in a single management or control plane operati= on). > > But they do not share fate, as can be seen from the following examples: > > > > 1. A unidirectiona fiber cut in one of the links used by a co-routed bi- > directional > > trail will result in traffic failur in the affected direction but not ne= cessarily in > the > > reverse one > > > > 2. Consider the case when one of entries the ILM in one of the transit L= SRs is > > corruped. This will result in incorrect failure of a single label, but t= he rest of > the > > labels would be handled correctly. Since co-routed bi-directional trails= do not > > require using the same label in both directions of a trail, the fate sha= ring > would > > be broken. > > (Actually, in such a way it could be easily broken even if the same labe= l is > used > > on each segment of the LSP in both directions...) > > > > My 2c, > > Sasha > > > > > > > > ________________________________________ > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on behalf of B= hatia, > > Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > Sent: Sunday, October 13, 2013 5:55 PM > > To: rtg-ads@tools.ietf.org > > Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.or= g; > > mpls@ietf.org > > Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.tx= t > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this draft.= The > > Routing Directorate seeks to review all routing or routing-related draft= s as > > they pass through IETF last call and IESG review, and sometimes on speci= al > > request. The purpose of the review is to provide assistance to the Routi= ng > > ADs. For more information about the Routing Directorate, please > > seehttp://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 La= st > Call > > comments that you receive, and strive to resolve them through discussion= or > > by updating the draft. > > > > Document: draft-ietf-mpls-tp-rosetta-stone-12.txt > > Reviewer: Manav Bhatia > > Review Date: October 13th, 2013 > > IETF LC End Date: October 16, 2013 > > Intended Status: Informational > > > > Summary: This document is basically ready for publication, but has nits= that > > should be considered prior to publication. > > > > Comments: This document is built on top of terms already defined in diff= erent > > RFCs and ITU-T documents. The terms and definitions have already been > > reviewed so there is a trifle little that needs to be done there. Overal= l, the > > document looks good and ready for publication. Some of my comments can b= e > > > > Nits: > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > o) When explaining Control Plane (3.6) should we mention that it is poss= ible > to > > operate an MPLS-TP network without using a Control Plane? > > > > o) In 3.7, it would be useful to mention that an important property of c= o- > routed > > bidirectional path is that the forward and backward directions share fat= e. > > Similarly, in 3.1, we should mention that the forward and backward direc= tions > > don't share fate. > > > > o) 3.12 in the current text doesn't look very helpful. Can it be rephras= ed it to > > something like, "The equipment management function (EMF) provides the > > means through which an element management system (EMS) and other > > managing entities manage the network element function (NEF)." > > > > o) 3.13 talks about Fault cause without explaining what a fault cause is= . It > took > > me some time to understand what was meant by "fault cause". Can the > > authors of the draft rephrase 3.13 in their own language to explain what= they > > mean by a Failure. The current definition in the draft has been picked u= p as-is > > from ITU-T G.806 > > > > o) 3.14 talks about "inability of a function to perform a required actio= n". Since > > this RFC-to-be is in the IETF domain, can this be rephrased to use a ter= m like > > router/switch instead of a more esoteric "function". This is a general > comment > > and applies to most of the definitions that have been copied from the IT= U-T > > documents. > > > > o) The last paragraph of 3.17 says the following: > > > > "OAM packets are subject to the same forwarding treatment as the data > > traffic, but they are distinct from the data traffic." > > > > In what sense are the OAM packets distinct from the data traffic? > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been expa= nded > > in the document. > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > o) In 3.28.3, can the following text be added: > > > > An LSP segment comprises one or more continuous hops on the path of the > > LSP. [RFC5654] defines two terms. A "segment" is a single hop along th= e > path > > of an LSP, while a "concatenated segment" is more than one hop along the > > path of an LSP. > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more common term th= an > > Operations Systems (OS)? > > > > Cheers, Manav > > > > This e-mail message is intended for the recipient only and contains > information > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u > > have received this transmission in error, please inform us by e-mail, ph= one or > > fax, and then delete the original and all copies thereof. > > > > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From jdrake@juniper.net Mon Oct 14 07:48:57 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C147A11E81A5; Mon, 14 Oct 2013 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=-1.761, BAYES_00=-2.599, 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 9f42VwRpoZgb; Mon, 14 Oct 2013 07:48:51 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1728211E8199; Mon, 14 Oct 2013 07:48:45 -0700 (PDT) Received: from mail14-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 14:48:38 +0000 Received: from mail14-ch1 (localhost [127.0.0.1]) by mail14-ch1-R.bigfish.com (Postfix) with ESMTP id 69E383E0100; Mon, 14 Oct 2013 14:48: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: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail14-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:(199002)(189002)(51704005)(377454003)(13464003)(74706001)(63696002)(54356001)(59766001)(33646001)(51856001)(77982001)(76482001)(76576001)(85306002)(77096001)(56816003)(53806001)(76786001)(69226001)(76796001)(83072001)(4396001)(47976001)(50986001)(19580395003)(54316002)(66066001)(80022001)(47736001)(46102001)(65816001)(49866001)(74366001)(79102001)(80976001)(74876001)(56776001)(74316001)(47446002)(31966008)(81542001)(81686001)(74502001)(19580405001)(83322001)(81342001)(74662001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail14-ch1 (localhost.localdomain [127.0.0.1]) by mail14-ch1 (MessageSwitch) id 1381762116974675_12204; Mon, 14 Oct 2013 14:48:36 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail14-ch1.bigfish.com (Postfix) with ESMTP id E98E7180110; Mon, 14 Oct 2013 14:48:36 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 14:48:36 +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.371.2; Mon, 14 Oct 2013 14:48:35 +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.775.9; Mon, 14 Oct 2013 14:48:33 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.188]) with mapi id 15.00.0775.005; Mon, 14 Oct 2013 14:48:33 +0000 From: John E Drake To: "Bhatia, Manav (Manav)" , Alexander Vainshtein Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BYAAE12wgACiAUA= Date: Mon, 14 Oct 2013 14:48:32 +0000 Message-ID: <26d4df40f74644c896ab376f8b6725fd@BY2PR05MB142.namprd05.prod.outlook.com> References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0999136621 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$ecitele.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%ECITELE.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:48:57 -0000 Manav, Snipped, comment inline. Yours Irrespectively, John > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behal= f Of > Bhatia, Manav (Manav) > Sent: Sunday, October 13, 2013 10:26 PM > To: Alexander Vainshtein > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; draft-ietf-mpls-tp-rosetta- > stone.all@tools.ietf.org; mpls@ietf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12= .txt >=20 > Sasha, >=20 > I think the confusion is over what we mean by "fate sharing". >=20 > To me, if the forward path is torn down for some reason, and that results= in > the backward path being torn down as well, then they inextricably "share = the > fate". >=20 > If the path of the forward LSP changes because of an IGP trigger, then th= e > backward LSP changes too in case of co-routed bidirectional LSPs. However= , > this isn't true in case of Associated bidirectional LSPs. Similarly, an I= GP change > (or a network event -- link/node flap, link/node down) will always result= in both > directions changing their path in case of co-routed bidirectional LSPs. T= his > doesn't happen in case of Associated bidirectional LSPs. [JD] You attributing to the endpoints of a pair of Associated LSPs a behav= ior which I think is actually at their discretion.=20 > Its this difference that > I wanted the authors to highlight as part of my review comment. >=20 > If you think "fate sharing" is not the most appropriate term then you can > suggest something else as long as you believe its something that ought to= be > mentioned. >=20 > Cheers, Manav >=20 From jdrake@juniper.net Mon Oct 14 07:55:37 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5C921E80DB; Mon, 14 Oct 2013 07:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.618 X-Spam-Level: X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, 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 Mjzyp5EHRj2K; Mon, 14 Oct 2013 07:55:29 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1304321E80DA; Mon, 14 Oct 2013 07:55:23 -0700 (PDT) Received: from mail69-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 14:55:22 +0000 Received: from mail69-tx2 (localhost [127.0.0.1]) by mail69-tx2-R.bigfish.com (Postfix) with ESMTP id 4CC871201C4; Mon, 14 Oct 2013 14:55:22 +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: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) 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=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(377454003)(189002)(199002)(51704005)(19580405001)(81342001)(83322001)(74662001)(47446002)(74316001)(31966008)(81542001)(81686001)(74502001)(81816001)(85306002)(76576001)(69226001)(83072001)(76796001)(53806001)(56816003)(77096001)(76786001)(63696002)(54356001)(74706001)(76482001)(77982001)(51856001)(59766001)(33646001)(74876001)(80976001)(15975445006)(79102001)(56776001)(19580395003)(47976001)(50986001)(66066001)(54316002)(4396001)(74366001)(47736001)(80022001)(65816001)(46102001)(49866001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail69-tx2 (localhost.localdomain [127.0.0.1]) by mail69-tx2 (MessageSwitch) id 138176251898139_15982; Mon, 14 Oct 2013 14:55:18 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.239]) by mail69-tx2.bigfish.com (Postfix) with ESMTP id A6C4D3E0040; Mon, 14 Oct 2013 14:55:17 +0000 (UTC) Received: from BL2PRD0510HT004.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; Mon, 14 Oct 2013 14:55:08 +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.371.2; Mon, 14 Oct 2013 14:55:07 +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.775.9; Mon, 14 Oct 2013 14:55:05 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.188]) with mapi id 15.00.0775.005; Mon, 14 Oct 2013 14:55:05 +0000 From: John E Drake To: Alexander Vainshtein , Gregory Mirsky Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BYAAE12wgAAS/oCAAB9uEIAAcVUA Date: Mon, 14 Oct 2013 14:55:05 +0000 Message-ID: <2bf422c8e5674cbdba8faa198d57e0fa@BY2PR05MB142.namprd05.prod.outlook.com> References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B6F8E0D@eusaamb103.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.232.2] x-forefront-prvs: 0999136621 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$ecitele.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%ECITELE.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:55:37 -0000 Yours Irrespectively, John > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behal= f Of > Alexander Vainshtein > Sent: Monday, October 14, 2013 1:08 AM > To: Gregory Mirsky > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-mp= ls- > tp-rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12= .txt >=20 > Greg, > Lots of thanks for an important comment. >=20 > Regarding your example: my personal interpretation of 5654 is like follow= ing: > - Co-routed bidirectional LSPs MAY be protected using bi-directional prot= ection > schemes but MUST NOT be protected using unidirectional ones [JD] I don't think that is true for a pair of co-routed associated unidire= ctional LSPs.=20 > - Associated bidirectional LSPs MAY be protected using both unidirectiona= l and > bi-directional protection schemes [JD] Conversely, if a pair of associated unidirectional LSPs are diversely= routed, it may be difficult to apply bidirectional protection to them. =20 >=20 > Does this match your understanding? >=20 > Regards, > Sasha >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Monday, October 14, 2013 9:23 AM > > To: Bhatia, Manav (Manav); Alexander Vainshtein > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Hi Manav, > > I do feel that "fate sharing" already has certain interpretation in the > industry. > > Difference in, for example, protection between co-routed and > > associated bi- directional LSPs doesn't seem not to be described by > > "fate sharing". I think of it as in co-routed case LSP protected as a > > single entity while in associated case each direction of LSP is protect= ed > independently of the other. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Bhatia, Manav (Manav) > > Sent: Sunday, October 13, 2013 10:26 PM > > To: Alexander Vainshtein > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > Subject: Re: [mpls] RtgDir review: > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Sasha, > > > > I think the confusion is over what we mean by "fate sharing". > > > > To me, if the forward path is torn down for some reason, and that > > results in the backward path being torn down as well, then they inextri= cably > "share the fate". > > > > If the path of the forward LSP changes because of an IGP trigger, then > > the backward LSP changes too in case of co-routed bidirectional LSPs. > > However, this isn't true in case of Associated bidirectional LSPs. > > Similarly, an IGP change (or a network event -- link/node flap, > > link/node down) will always result in both directions changing their > > path in case of co-routed bidirectional LSPs. This doesn't happen in > > case of Associated bidirectional LSPs. Its this difference that I wante= d the > authors to highlight as part of my review comment. > > > > If you think "fate sharing" is not the most appropriate term then you > > can suggest something else as long as you believe its something that > > ought to be mentioned. > > > > Cheers, Manav > > > > > -----Original Message----- > > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > > Sent: Monday, October 14, 2013 9:37 AM > > > To: Bhatia, Manav (Manav) > > > Cc: rtg-dir@ietf.org; > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > Manav, > > > Lots of thanks for a prompt response. > > > > > > I must admit that I've mssed the text in 5960 to which you refer. > > > > > > The original definition, to the best of my understanding, is in > > > Section 1.2.2. of RFC 5654 and says something else: > > > > > > > > > Co-routed Bidirectional path: A path where the forward and backwar= d > > > directions follow the same route (links and nodes) across the > > > network. Both directions are setup, monitored and protected as a > > > single entity. A transport network path is typically co-routed. > > > > > > To me this means that if one of the directions of the co-routed > > > bi-directional path fails to convey traffic, the monitoring > > > mechanisms will report the entire bi-directional path as failed. > > > > > > To the best of my recollection when I=3DD to become RFC 5960 has been > > > discussed I've asked the authors of RFC 5960 whether the pairing > > > between two directions of a co-routed bi-directional MPLS-TP LSP in > > > a transit LSR is limited to OAM processing, and they (or one of > > > them) have confirmed that this is indeed so. > > > > > > I wonder whether this can be interpreted as "fate-sharing". > > > > > > Regards, > > > Sasha > > > > > > ________________________________________ > > > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > Sent: Monday, October 14, 2013 4:21 AM > > > To: Alexander Vainshtein > > > Cc: rtg-dir@ietf.org; > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Hi Sasha, > > > > > > RFC 5960 that describes the MPLS-TP data plane says the following: > > > > > > A point-to-point co-routed bidirectional LSP is a point-to-point > > > associated bidirectional LSP with the additional constraint that its > > > two unidirectional component LSPs in each direction follow the same > > > path (in terms of both nodes and links). An important property of > > > co-routed bidirectional LSPs is that their unidirectional component > > > LSPs share fate. > > > > > > Am I missing something? > > > > > > Cheers, Manav > > > > > > > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Sunday, October 13, 2013 9:46 PM > > > > To: Bhatia, Manav (Manav) > > > > Cc: rtg-dir@ietf.org; > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > Subject: RE: RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Manav and all, > > > > Regarding one of the nits you've identified: > > > > "it would be useful to mention that an important property > > > of co-routed > > > > bidirectional path is that the forward and backward > > > directions share > > > > fate." > > > > > > > > IMHO and FWIW this is not correct. To the best of my > > > understanding the > > > > two directions of an MPLS-TP co-routed bi-directional path share > > > > lifespan (i.e.,they are set up and torn down in a single > > > management or > > > > control plane operation). > > > > But they do not share fate, as can be seen from the following > > > > examples: > > > > > > > > 1. A unidirectiona fiber cut in one of the links used by a > > > co-routed > > > > bi-directional trail will result in traffic failur in the affected > > > > direction but not necessarily in the reverse one > > > > > > > > 2. Consider the case when one of entries the ILM in one of > > > the transit > > > > LSRs is corruped. This will result in incorrect failure of a > > > > single label, but the rest of the labels would be handled > > > > correctly. Since co-routed bi-directional trails do not require > > > > using the > > > same label in > > > > both directions of a trail, the fate sharing would be broken. > > > > (Actually, in such a way it could be easily broken even if the > > > > same label is used on each segment of the LSP in both > > > > directions...) > > > > > > > > My 2c, > > > > Sasha > > > > > > > > > > > > > > > > ________________________________________ > > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] > > > on behalf of > > > > Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > > Sent: Sunday, October 13, 2013 5:55 PM > > > > To: rtg-ads@tools.ietf.org > > > > Cc: rtg-dir@ietf.org; > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > > > > Subject: [RTG-DIR] RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > 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, and sometimes on special request. > > > > The purpose of the review is to provide assistance to the > > > Routing ADs. > > > > For more information about the Routing Directorate, please > > > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > > > Reviewer: Manav Bhatia > > > > Review Date: October 13th, 2013 > > > > IETF LC End Date: October 16, 2013 Intended Status: Informational > > > > > > > > Summary: This document is basically ready for publication, but > > > > has nits that should be considered prior to publication. > > > > > > > > Comments: This document is built on top of terms already defined > > > > in different RFCs and ITU-T documents. The terms and definitions > > > > have already been reviewed so there is a trifle little that needs > > > > to be done there. Overall, the document looks good and ready for > > > > publication. Some of my comments can be > > > > > > > > Nits: > > > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > > > o) When explaining Control Plane (3.6) should we mention that it > > > > is possible to operate an MPLS-TP network without using a > > > Control Plane? > > > > > > > > o) In 3.7, it would be useful to mention that an important > > > property of > > > > co-routed bidirectional path is that the forward and backward > > > > directions share fate. Similarly, in 3.1, we should mention > > > that the > > > > forward and backward directions don't share fate. > > > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be > > > > rephrased it to something like, "The equipment management function > > > > (EMF) provides the means through which an element management > > > > system > > > > (EMS) and other managing entities manage the network > > > element function > > > > (NEF)." > > > > > > > > o) 3.13 talks about Fault cause without explaining what a > > > fault cause > > > > is. It took me some time to understand what was meant by "fault > > > > cause". Can the authors of the draft rephrase > > > > 3.13 in their own language to explain what they mean by a > > > Failure. The > > > > current definition in the draft has been picked up as-is from > > > > ITU-T > > > > G.806 > > > > > > > > o) 3.14 talks about "inability of a function to perform a required > > > > action". Since this RFC-to-be is in the IETF domain, can this be > > > > rephrased to use a term like router/switch instead of a > > > more esoteric > > > > "function". This is a general comment and applies to most of the > > > > definitions that have been copied from the ITU-T documents. > > > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > > > "OAM packets are subject to the same forwarding treatment > > > as the data > > > > traffic, but they are distinct from the data traffic." > > > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not > > > > been expanded in the document. > > > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > > > o) In 3.28.3, can the following text be added: > > > > > > > > An LSP segment comprises one or more continuous hops on the path > > > > of the LSP. [RFC5654] defines two terms. A "segment" > > > > is a single hop along the path of an LSP, while a "concatenated > > > > segment" is more than one hop along the path of an LSP. > > > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more > > > common term > > > > than Operations Systems (OS)? > > > > > > > > Cheers, Manav > > > > > > > > This e-mail message is intended for the recipient only and > > > > contains information which is CONFIDENTIAL and which may be > > > proprietary to ECI > > > > Telecom. If you have received this transmission in error, please > > > > inform us by e-mail, phone or fax, and then delete the original > > > > and all copies thereof. > > > > > > > > > > > > > > This e-mail message is intended for the recipient only and contains > > > information which is CONFIDENTIAL and which may be proprietary to > > > ECI Telecom. If you have received this transmission in error, please > > > inform us by e-mail, phone or fax, and then delete the original and > > > all copies thereof. > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > This e-mail message is intended for the recipient only and contains infor= mation > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this transmission in error, please inform us by e-mail, pho= ne or > fax, and then delete the original and all copies thereof. >=20 >=20 From Alexander.Vainshtein@ecitele.com Mon Oct 14 07:58:24 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D8321E80C7 for ; Mon, 14 Oct 2013 07:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 2RbvdisFJ7d0 for ; Mon, 14 Oct 2013 07:58:20 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE7E21E80C9 for ; Mon, 14 Oct 2013 07:58:19 -0700 (PDT) X-AuditID: 93eaf2e7-b7f586d00000770a-24-525c06848a6d Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 85.33.30474.4860C525; Mon, 14 Oct 2013 16:58:12 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 17:58:11 +0300 From: Alexander Vainshtein To: John E Drake , Gregory Mirsky Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BYAAE12wgAAS/oCAAB9uEIAAcVUAgAABwGA= Date: Mon, 14 Oct 2013 14:58:11 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B6F8E0D@eusaamb103.ericsson.se> <2bf422c8e5674cbdba8faa198d57e0fa@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <2bf422c8e5674cbdba8faa198d57e0fa@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTW0zTUBjHPWu3FaRYB7gj3mpBouLMFrzMy9QIJtMHnXhXjJTtuDWu3bIO ZPiyqPGCxmgUI4tRVLygGCNqVDRGCDyIJBgUFcPQhCmKtwgYhBi1pQFJjH369fz/3+WcfB+B 6X5oEglO8COfwLoZTTR+tKOz27Bbk5VpbO5LMbdHCoH5ZDjd3H6yGDeXlL/VLsKtfd+bNNbS 0l6V9cXOJq21+2mXxoZvDIL5rCB4/Kwf0Q4k2i2MzcflsfYAQ3MOC2NiaK+btSMeCX4Lw3q9 SHAwC6Lpf775ko0TaCTYPQ5OcFqYpatWGMzmmXMMJmZBSpIpbV70ahcn0sjAs5yb5pEosk5E SyfZNzFXT2uj2ruzIL+tslEbBK2bC0EUAakZsKusTKvwKPik9ZpGZh1VBeC+nzmFIFriWgAr ij72CxrKAiuuhCUmiHhqDexuWSwfY9RVFWwPCzLHUenwcfNDIHM8lQFD9fUqhXNgc81dTGac mgSLGo70pyQpG6zqeKJWar3HYVflO1wWoqi1sPHWof7mgNRcT125Simmh68ip1VK0xQsvd+A KZwAP7T9Uis8HkYidbjinwZL7nVqFE6FF858xJTCI+Gj4giu+EfDqksv8cNAHxpSIjQkPDQk PDQkvATgl0EC5/b6c3in0TQd2Tk/cqPpdg9fAZSxab8D+k4nVwOKAEwM6crYlKlTs3ligK8G owkVk0BewbIydbE5HkfAxYquLb5cNxKrASQwJp7kP0t20sEGCpDPMyAtkZ7wCJY43O6RBlTw b0kzGv//w+jJi8F1K3SUU5rAbQh5kW8gz1iCYCD5Ri2VH+lDTpS/lXP7/8oqIkpuI0Zqo1H2 kKKX5UXOqeh1YGKinnwmC5QsuHKFwdiBhekAeunSceQr2RUjrdNgdIeUWCUl7v28Xk4sbceg lBgEZRh26vyJyUm/+IZdD3qK37QcGLEHW0k8r0ta/Z0N3Nlxi5ky4eGsMctWGbUJscm1M3K7 0vbOLiLvrYvNt6UN770d97z16DdDeHfMhU+uwwU3rme3bEBfyjpt4481Lczb33b73Nezc7cH x5XQYevv1+fX07Z5qSk1yyuHNRzvcxwU0uMYXHSxpqmYT2T/AEIj53ALBAAA Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:58:24 -0000 John, RFC 5654 states that both directions of a co-routed bi-directional LSP are p= rotected as a whole. Hence I do not see how they may participate in a unidirectional protection s= cheme. Regards, Sasha > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Monday, October 14, 2013 5:55 PM > To: Alexander Vainshtein; Gregory Mirsky > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-mpl= s-tp- > rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Yours Irrespectively, > > John > > > -----Original Message----- > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Beha= lf > Of > > Alexander Vainshtein > > Sent: Monday, October 14, 2013 1:08 AM > > To: Gregory Mirsky > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-m= pls- > > tp-rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org > > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-1= 2.txt > > > > Greg, > > Lots of thanks for an important comment. > > > > Regarding your example: my personal interpretation of 5654 is like follo= wing: > > - Co-routed bidirectional LSPs MAY be protected using bi-directional > protection > > schemes but MUST NOT be protected using unidirectional ones > > [JD] I don't think that is true for a pair of co-routed associated unidir= ectional > LSPs. > > > - Associated bidirectional LSPs MAY be protected using both unidirection= al > and > > bi-directional protection schemes > > [JD] Conversely, if a pair of associated unidirectional LSPs are diversel= y routed, > it > may be difficult to apply bidirectional protection to them. > > > > > Does this match your understanding? > > > > Regards, > > Sasha > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Monday, October 14, 2013 9:23 AM > > > To: Bhatia, Manav (Manav); Alexander Vainshtein > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Hi Manav, > > > I do feel that "fate sharing" already has certain interpretation in th= e > > industry. > > > Difference in, for example, protection between co-routed and > > > associated bi- directional LSPs doesn't seem not to be described by > > > "fate sharing". I think of it as in co-routed case LSP protected as a > > > single entity while in associated case each direction of LSP is protec= ted > > independently of the other. > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > > Of Bhatia, Manav (Manav) > > > Sent: Sunday, October 13, 2013 10:26 PM > > > To: Alexander Vainshtein > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > > Subject: Re: [mpls] RtgDir review: > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Sasha, > > > > > > I think the confusion is over what we mean by "fate sharing". > > > > > > To me, if the forward path is torn down for some reason, and that > > > results in the backward path being torn down as well, then they inextr= icably > > "share the fate". > > > > > > If the path of the forward LSP changes because of an IGP trigger, then > > > the backward LSP changes too in case of co-routed bidirectional LSPs. > > > However, this isn't true in case of Associated bidirectional LSPs. > > > Similarly, an IGP change (or a network event -- link/node flap, > > > link/node down) will always result in both directions changing their > > > path in case of co-routed bidirectional LSPs. This doesn't happen in > > > case of Associated bidirectional LSPs. Its this difference that I want= ed the > > authors to highlight as part of my review comment. > > > > > > If you think "fate sharing" is not the most appropriate term then you > > > can suggest something else as long as you believe its something that > > > ought to be mentioned. > > > > > > Cheers, Manav > > > > > > > -----Original Message----- > > > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Monday, October 14, 2013 9:37 AM > > > > To: Bhatia, Manav (Manav) > > > > Cc: rtg-dir@ietf.org; > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > > > Manav, > > > > Lots of thanks for a prompt response. > > > > > > > > I must admit that I've mssed the text in 5960 to which you refer. > > > > > > > > The original definition, to the best of my understanding, is in > > > > Section 1.2.2. of RFC 5654 and says something else: > > > > > > > > > > > > Co-routed Bidirectional path: A path where the forward and backwa= rd > > > > directions follow the same route (links and nodes) across the > > > > network. Both directions are setup, monitored and protected as a > > > > single entity. A transport network path is typically co-routed. > > > > > > > > To me this means that if one of the directions of the co-routed > > > > bi-directional path fails to convey traffic, the monitoring > > > > mechanisms will report the entire bi-directional path as failed. > > > > > > > > To the best of my recollection when I=3DD to become RFC 5960 has bee= n > > > > discussed I've asked the authors of RFC 5960 whether the pairing > > > > between two directions of a co-routed bi-directional MPLS-TP LSP in > > > > a transit LSR is limited to OAM processing, and they (or one of > > > > them) have confirmed that this is indeed so. > > > > > > > > I wonder whether this can be interpreted as "fate-sharing". > > > > > > > > Regards, > > > > Sasha > > > > > > > > ________________________________________ > > > > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > > Sent: Monday, October 14, 2013 4:21 AM > > > > To: Alexander Vainshtein > > > > Cc: rtg-dir@ietf.org; > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Hi Sasha, > > > > > > > > RFC 5960 that describes the MPLS-TP data plane says the following: > > > > > > > > A point-to-point co-routed bidirectional LSP is a point-to-point > > > > associated bidirectional LSP with the additional constraint that its > > > > two unidirectional component LSPs in each direction follow the same > > > > path (in terms of both nodes and links). An important property of > > > > co-routed bidirectional LSPs is that their unidirectional component > > > > LSPs share fate. > > > > > > > > Am I missing something? > > > > > > > > Cheers, Manav > > > > > > > > > > > > > -----Original Message----- > > > > > From: Alexander Vainshtein > > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > Sent: Sunday, October 13, 2013 9:46 PM > > > > > To: Bhatia, Manav (Manav) > > > > > Cc: rtg-dir@ietf.org; > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > > Subject: RE: RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > Manav and all, > > > > > Regarding one of the nits you've identified: > > > > > "it would be useful to mention that an important property > > > > of co-routed > > > > > bidirectional path is that the forward and backward > > > > directions share > > > > > fate." > > > > > > > > > > IMHO and FWIW this is not correct. To the best of my > > > > understanding the > > > > > two directions of an MPLS-TP co-routed bi-directional path share > > > > > lifespan (i.e.,they are set up and torn down in a single > > > > management or > > > > > control plane operation). > > > > > But they do not share fate, as can be seen from the following > > > > > examples: > > > > > > > > > > 1. A unidirectiona fiber cut in one of the links used by a > > > > co-routed > > > > > bi-directional trail will result in traffic failur in the affected > > > > > direction but not necessarily in the reverse one > > > > > > > > > > 2. Consider the case when one of entries the ILM in one of > > > > the transit > > > > > LSRs is corruped. This will result in incorrect failure of a > > > > > single label, but the rest of the labels would be handled > > > > > correctly. Since co-routed bi-directional trails do not require > > > > > using the > > > > same label in > > > > > both directions of a trail, the fate sharing would be broken. > > > > > (Actually, in such a way it could be easily broken even if the > > > > > same label is used on each segment of the LSP in both > > > > > directions...) > > > > > > > > > > My 2c, > > > > > Sasha > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] > > > > on behalf of > > > > > Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > > > Sent: Sunday, October 13, 2013 5:55 PM > > > > > To: rtg-ads@tools.ietf.org > > > > > Cc: rtg-dir@ietf.org; > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > > > > > Subject: [RTG-DIR] RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > 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, and sometimes on special request. > > > > > The purpose of the review is to provide assistance to the > > > > Routing ADs. > > > > > For more information about the Routing Directorate, please > > > > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > > > > Reviewer: Manav Bhatia > > > > > Review Date: October 13th, 2013 > > > > > IETF LC End Date: October 16, 2013 Intended Status: Informational > > > > > > > > > > Summary: This document is basically ready for publication, but > > > > > has nits that should be considered prior to publication. > > > > > > > > > > Comments: This document is built on top of terms already defined > > > > > in different RFCs and ITU-T documents. The terms and definitions > > > > > have already been reviewed so there is a trifle little that needs > > > > > to be done there. Overall, the document looks good and ready for > > > > > publication. Some of my comments can be > > > > > > > > > > Nits: > > > > > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > > > > > o) When explaining Control Plane (3.6) should we mention that it > > > > > is possible to operate an MPLS-TP network without using a > > > > Control Plane? > > > > > > > > > > o) In 3.7, it would be useful to mention that an important > > > > property of > > > > > co-routed bidirectional path is that the forward and backward > > > > > directions share fate. Similarly, in 3.1, we should mention > > > > that the > > > > > forward and backward directions don't share fate. > > > > > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be > > > > > rephrased it to something like, "The equipment management function > > > > > (EMF) provides the means through which an element management > > > > > system > > > > > (EMS) and other managing entities manage the network > > > > element function > > > > > (NEF)." > > > > > > > > > > o) 3.13 talks about Fault cause without explaining what a > > > > fault cause > > > > > is. It took me some time to understand what was meant by "fault > > > > > cause". Can the authors of the draft rephrase > > > > > 3.13 in their own language to explain what they mean by a > > > > Failure. The > > > > > current definition in the draft has been picked up as-is from > > > > > ITU-T > > > > > G.806 > > > > > > > > > > o) 3.14 talks about "inability of a function to perform a required > > > > > action". Since this RFC-to-be is in the IETF domain, can this be > > > > > rephrased to use a term like router/switch instead of a > > > > more esoteric > > > > > "function". This is a general comment and applies to most of the > > > > > definitions that have been copied from the ITU-T documents. > > > > > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > > > > > "OAM packets are subject to the same forwarding treatment > > > > as the data > > > > > traffic, but they are distinct from the data traffic." > > > > > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not > > > > > been expanded in the document. > > > > > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > > > > > o) In 3.28.3, can the following text be added: > > > > > > > > > > An LSP segment comprises one or more continuous hops on the path > > > > > of the LSP. [RFC5654] defines two terms. A "segment" > > > > > is a single hop along the path of an LSP, while a "concatenated > > > > > segment" is more than one hop along the path of an LSP. > > > > > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more > > > > common term > > > > > than Operations Systems (OS)? > > > > > > > > > > Cheers, Manav > > > > > > > > > > This e-mail message is intended for the recipient only and > > > > > contains information which is CONFIDENTIAL and which may be > > > > proprietary to ECI > > > > > Telecom. If you have received this transmission in error, please > > > > > inform us by e-mail, phone or fax, and then delete the original > > > > > and all copies thereof. > > > > > > > > > > > > > > > > > > This e-mail message is intended for the recipient only and contains > > > > information which is CONFIDENTIAL and which may be proprietary to > > > > ECI Telecom. If you have received this transmission in error, please > > > > inform us by e-mail, phone or fax, and then delete the original and > > > > all copies thereof. > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > This e-mail message is intended for the recipient only and contains > information > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u > > have received this transmission in error, please inform us by e-mail, ph= one or > > fax, and then delete the original and all copies thereof. > > > > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From jdrake@juniper.net Mon Oct 14 08:09:57 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64A721E8093; Mon, 14 Oct 2013 08:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=-2.142, BAYES_00=-2.599, 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 5yTF+qoH5zTn; Mon, 14 Oct 2013 08:09:52 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 36CCB21F9A97; Mon, 14 Oct 2013 08:09:48 -0700 (PDT) Received: from mail114-db9-R.bigfish.com (10.174.16.241) by DB9EHSOBE011.bigfish.com (10.174.14.74) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 15:09:47 +0000 Received: from mail114-db9 (localhost [127.0.0.1]) by mail114-db9-R.bigfish.com (Postfix) with ESMTP id 1BF7E3A0070; Mon, 14 Oct 2013 15:09:47 +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: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail114-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=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(189002)(199002)(13464003)(54316002)(56776001)(85306002)(81686001)(76482001)(65816001)(66066001)(80022001)(74366001)(79102001)(77982001)(63696002)(59766001)(81816001)(74876001)(74706001)(83072001)(69226001)(47736001)(49866001)(50986001)(47976001)(53806001)(51856001)(46102001)(4396001)(83322001)(74502001)(19580405001)(74662001)(54356001)(80976001)(19580395003)(47446002)(31966008)(81542001)(74316001)(76796001)(76786001)(76576001)(81342001)(77096001)(33646001)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail114-db9 (localhost.localdomain [127.0.0.1]) by mail114-db9 (MessageSwitch) id 1381763385919332_14478; Mon, 14 Oct 2013 15:09:45 +0000 (UTC) Received: from DB9EHSMHS011.bigfish.com (unknown [10.174.16.251]) by mail114-db9.bigfish.com (Postfix) with ESMTP id D1826140074; Mon, 14 Oct 2013 15:09:45 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS011.bigfish.com (10.174.14.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 15:09:45 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 14 Oct 2013 15:09:42 +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.775.9; Mon, 14 Oct 2013 15:09:40 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.188]) with mapi id 15.00.0775.005; Mon, 14 Oct 2013 15:09:40 +0000 From: John E Drake To: Alexander Vainshtein Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gAFpNkCAAA4F4IAACoJw Date: Mon, 14 Oct 2013 15:09:39 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5ca0484c5ca745bbabd93bb799afaca8@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.232.2] x-forefront-prvs: 0999136621 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$ecitele.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%ECITELE.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 15:09:57 -0000 Sasha, My point was simply that in the data plane there isn't any difference betwe= en the two. Yours Irrespectively, John > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behal= f Of > Alexander Vainshtein > Sent: Monday, October 14, 2013 7:34 AM > To: John E Drake > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-mp= ls- > tp-rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12= .txt >=20 > John, > Not sure I fully understood your message. >=20 > My comments have been about applicability of the term "fate-sharing" to t= he > two directions of a co-routed bi-directional LSP. > It is of course true that each direction of an associated bi-directional = LSP can > fail independently of the other one, but, presumably, nobody has expected > anything else in this case. >=20 > Regards, > Sasha >=20 >=20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Monday, October 14, 2013 4:42 PM > > To: Alexander Vainshtein; Bhatia, Manav (Manav) > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Sasha, > > > > I think your comments apply equally to bidirectional LSPs. > > > > Yours Irrespectively, > > > > John > > > > > -----Original Message----- > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > > > Behalf > > Of > > > Alexander Vainshtein > > > Sent: Sunday, October 13, 2013 9:16 AM > > > To: Bhatia, Manav (Manav) > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > > Subject: Re: [RTG-DIR] RtgDir review: > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Manav and all, > > > Regarding one of the nits you've identified: > > > "it would be useful to mention that an important property of > > > co-routed bidirectional path is that the forward and backward directi= ons > share fate." > > > > > > IMHO and FWIW this is not correct. To the best of my understanding > > > the two directions of an MPLS-TP co-routed bi-directional path share > > > lifespan (i.e.,they are set up and torn down in a single management o= r > control plane operation). > > > But they do not share fate, as can be seen from the following example= s: > > > > > > 1. A unidirectiona fiber cut in one of the links used by a co-routed > > > bi- > > directional > > > trail will result in traffic failur in the affected direction but > > > not necessarily in > > the > > > reverse one > > > > > > 2. Consider the case when one of entries the ILM in one of the > > > transit LSRs is corruped. This will result in incorrect failure of a > > > single label, but the rest of > > the > > > labels would be handled correctly. Since co-routed bi-directional > > > trails do not require using the same label in both directions of a > > > trail, the fate sharing > > would > > > be broken. > > > (Actually, in such a way it could be easily broken even if the same > > > label is > > used > > > on each segment of the LSP in both directions...) > > > > > > My 2c, > > > Sasha > > > > > > > > > > > > ________________________________________ > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on behalf > > > of Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > Sent: Sunday, October 13, 2013 5:55 PM > > > To: rtg-ads@tools.ietf.org > > > Cc: rtg-dir@ietf.org; > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > mpls@ietf.org > > > Subject: [RTG-DIR] RtgDir review: > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > 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, and sometimes on special request. The purpose of the review > > > is to provide assistance to the Routing ADs. For more information > > > about the Routing Directorate, please > > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > > Reviewer: Manav Bhatia > > > Review Date: October 13th, 2013 > > > IETF LC End Date: October 16, 2013 > > > Intended Status: Informational > > > > > > Summary: This document is basically ready for publication, but has > > > nits that should be considered prior to publication. > > > > > > Comments: This document is built on top of terms already defined in > > > different RFCs and ITU-T documents. The terms and definitions have > > > already been reviewed so there is a trifle little that needs to be > > > done there. Overall, the document looks good and ready for > > > publication. Some of my comments can be > > > > > > Nits: > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > o) When explaining Control Plane (3.6) should we mention that it is > > > possible > > to > > > operate an MPLS-TP network without using a Control Plane? > > > > > > o) In 3.7, it would be useful to mention that an important property > > > of co- > > routed > > > bidirectional path is that the forward and backward directions share = fate. > > > Similarly, in 3.1, we should mention that the forward and backward > > > directions don't share fate. > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be > > > rephrased it to something like, "The equipment management function > > > (EMF) provides the means through which an element management system > > > (EMS) and other managing entities manage the network element function > (NEF)." > > > > > > o) 3.13 talks about Fault cause without explaining what a fault > > > cause is. It > > took > > > me some time to understand what was meant by "fault cause". Can the > > > authors of the draft rephrase 3.13 in their own language to explain > > > what they mean by a Failure. The current definition in the draft has > > > been picked up as-is from ITU-T G.806 > > > > > > o) 3.14 talks about "inability of a function to perform a required > > > action". Since this RFC-to-be is in the IETF domain, can this be > > > rephrased to use a term like router/switch instead of a more > > > esoteric "function". This is a general > > comment > > > and applies to most of the definitions that have been copied from > > > the ITU-T documents. > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > "OAM packets are subject to the same forwarding treatment as the > > > data traffic, but they are distinct from the data traffic." > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been > > > expanded in the document. > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > o) In 3.28.3, can the following text be added: > > > > > > An LSP segment comprises one or more continuous hops on the path of > > > the LSP. [RFC5654] defines two terms. A "segment" is a single hop > > > along the > > path > > > of an LSP, while a "concatenated segment" is more than one hop along > > > the path of an LSP. > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more common > > > term than Operations Systems (OS)? > > > > > > Cheers, Manav > > > > > > This e-mail message is intended for the recipient only and contains > > information > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. > > > If you have received this transmission in error, please inform us by > > > e-mail, phone or fax, and then delete the original and all copies the= reof. > > > > > > > > >=20 >=20 >=20 > This e-mail message is intended for the recipient only and contains infor= mation > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this transmission in error, please inform us by e-mail, pho= ne or > fax, and then delete the original and all copies thereof. >=20 >=20 From lberger@labn.net Mon Oct 14 08:17:45 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB1D21E816E for ; Mon, 14 Oct 2013 08:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.986 X-Spam-Level: X-Spam-Status: No, score=-101.986 tagged_above=-999 required=5 tests=[AWL=0.279, 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 vlW7IqfFfa41 for ; Mon, 14 Oct 2013 08:17:40 -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 AA96121E817D for ; Mon, 14 Oct 2013 08:17:33 -0700 (PDT) Received: (qmail 25958 invoked by uid 0); 14 Oct 2013 15:17:11 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.mail.unifiedlayer.com with SMTP; 14 Oct 2013 15:17:11 -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=JgTYC6oFC4V1lDQRD56wZTdxvR9rUGLfKTRuaHr9SAU=; b=Ry3JhHG6yHSU9/ngTMJohjakqIUvHW6hJQ5LB7DLGyrugYrV5fdK1n5KObVb2j1UChn8uwdHeTiPj9mpzfxOQLQGgvi8BLUC830NDH2nRl6pA9M8MJBGNx/vnKUYgc1j; Received: from box313.bluehost.com ([69.89.31.113]:39129 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VVjtP-0005iM-7p; Mon, 14 Oct 2013 09:17:11 -0600 Message-ID: <525C0AF4.6020004@labn.net> Date: Mon, 14 Oct 2013 11:17:08 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Alexander Vainshtein , John E Drake References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5ca0484c5ca745bbabd93bb799afaca8@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: 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: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 15:17:45 -0000 They also share control plane / "connection" fate. Lou On 10/14/2013 10:34 AM, Alexander Vainshtein wrote: > John, > Not sure I fully understood your message. > > My comments have been about applicability of the term "fate-sharing" to the two directions of a co-routed bi-directional LSP. > It is of course true that each direction of an associated bi-directional LSP can fail independently of the other one, but, presumably, nobody has expected anything else in this case. > > Regards, > Sasha > > >> -----Original Message----- >> From: John E Drake [mailto:jdrake@juniper.net] >> Sent: Monday, October 14, 2013 4:42 PM >> To: Alexander Vainshtein; Bhatia, Manav (Manav) >> Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; draft-ietf-mpls-tp-rosetta- >> stone.all@tools.ietf.org; mpls@ietf.org >> Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >> >> Sasha, >> >> I think your comments apply equally to bidirectional LSPs. >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf >> Of >>> Alexander Vainshtein >>> Sent: Sunday, October 13, 2013 9:16 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; draft-ietf-mpls-tp-rosetta- >>> stone.all@tools.ietf.org; mpls@ietf.org >>> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >>> >>> Manav and all, >>> Regarding one of the nits you've identified: >>> "it would be useful to mention that an important property of co-routed >>> bidirectional path is that the forward and backward directions share fate." >>> >>> IMHO and FWIW this is not correct. To the best of my understanding the two >>> directions of an MPLS-TP co-routed bi-directional path share lifespan (i.e.,they >>> are set up and torn down in a single management or control plane operation). >>> But they do not share fate, as can be seen from the following examples: >>> >>> 1. A unidirectiona fiber cut in one of the links used by a co-routed bi- >> directional >>> trail will result in traffic failur in the affected direction but not necessarily in >> the >>> reverse one >>> >>> 2. Consider the case when one of entries the ILM in one of the transit LSRs is >>> corruped. This will result in incorrect failure of a single label, but the rest of >> the >>> labels would be handled correctly. Since co-routed bi-directional trails do not >>> require using the same label in both directions of a trail, the fate sharing >> would >>> be broken. >>> (Actually, in such a way it could be easily broken even if the same label is >> used >>> on each segment of the LSP in both directions...) >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on behalf of Bhatia, >>> Manav (Manav) [manav.bhatia@alcatel-lucent.com] >>> Sent: Sunday, October 13, 2013 5:55 PM >>> To: rtg-ads@tools.ietf.org >>> Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; >>> mpls@ietf.org >>> Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >>> >>> 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, and sometimes on special >>> request. The purpose of the review is to provide assistance to the Routing >>> ADs. For more information about the Routing Directorate, please >>> seehttp://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-mpls-tp-rosetta-stone-12.txt >>> Reviewer: Manav Bhatia >>> Review Date: October 13th, 2013 >>> IETF LC End Date: October 16, 2013 >>> Intended Status: Informational >>> >>> Summary: This document is basically ready for publication, but has nits that >>> should be considered prior to publication. >>> >>> Comments: This document is built on top of terms already defined in different >>> RFCs and ITU-T documents. The terms and definitions have already been >>> reviewed so there is a trifle little that needs to be done there. Overall, the >>> document looks good and ready for publication. Some of my comments can be >>> >>> Nits: >>> >>> o) Please expand PW in either the Abstract or Sec 3.5 >>> >>> o) When explaining Control Plane (3.6) should we mention that it is possible >> to >>> operate an MPLS-TP network without using a Control Plane? >>> >>> o) In 3.7, it would be useful to mention that an important property of co- >> routed >>> bidirectional path is that the forward and backward directions share fate. >>> Similarly, in 3.1, we should mention that the forward and backward directions >>> don't share fate. >>> >>> o) 3.12 in the current text doesn't look very helpful. Can it be rephrased it to >>> something like, "The equipment management function (EMF) provides the >>> means through which an element management system (EMS) and other >>> managing entities manage the network element function (NEF)." >>> >>> o) 3.13 talks about Fault cause without explaining what a fault cause is. It >> took >>> me some time to understand what was meant by "fault cause". Can the >>> authors of the draft rephrase 3.13 in their own language to explain what they >>> mean by a Failure. The current definition in the draft has been picked up as-is >>> from ITU-T G.806 >>> >>> o) 3.14 talks about "inability of a function to perform a required action". Since >>> this RFC-to-be is in the IETF domain, can this be rephrased to use a term like >>> router/switch instead of a more esoteric "function". This is a general >> comment >>> and applies to most of the definitions that have been copied from the ITU-T >>> documents. >>> >>> o) The last paragraph of 3.17 says the following: >>> >>> "OAM packets are subject to the same forwarding treatment as the data >>> traffic, but they are distinct from the data traffic." >>> >>> In what sense are the OAM packets distinct from the data traffic? >>> >>> o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been expanded >>> in the document. >>> >>> o) Sec 3.19 uses TCM without expanding it first. >>> >>> o) In Sec 3.23, s/Tandem Connections/Tandem Connection >>> >>> o) In 3.28.3, can the following text be added: >>> >>> An LSP segment comprises one or more continuous hops on the path of the >>> LSP. [RFC5654] defines two terms. A "segment" is a single hop along the >> path >>> of an LSP, while a "concatenated segment" is more than one hop along the >>> path of an LSP. >>> >>> o) In 3.31, Isn't Operations Support Systems (OSS) a more common term than >>> Operations Systems (OS)? >>> >>> Cheers, Manav >>> >>> This e-mail message is intended for the recipient only and contains >> information >>> which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you >>> have received this transmission in error, please inform us by e-mail, phone or >>> fax, and then delete the original and all copies thereof. >>> >>> >> > > > > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > > > > From jdrake@juniper.net Mon Oct 14 08:23:07 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9CD11E8144; Mon, 14 Oct 2013 08:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=-1.523, BAYES_00=-2.599, 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 xEgJSDtNCd4D; Mon, 14 Oct 2013 08:23:01 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 25E6C21E8064; Mon, 14 Oct 2013 08:22:56 -0700 (PDT) Received: from mail24-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 15:22:55 +0000 Received: from mail24-va3 (localhost [127.0.0.1]) by mail24-va3-R.bigfish.com (Postfix) with ESMTP id 24EAF20007E; Mon, 14 Oct 2013 15:22:55 +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: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail24-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:(13464003)(377454003)(189002)(199002)(51704005)(19580405001)(81342001)(83322001)(74662001)(47446002)(74316001)(31966008)(81542001)(81686001)(74502001)(81816001)(85306002)(76576001)(69226001)(83072001)(76796001)(53806001)(56816003)(77096001)(76786001)(63696002)(54356001)(74706001)(76482001)(77982001)(51856001)(59766001)(33646001)(74876001)(80976001)(15975445006)(79102001)(56776001)(19580395003)(47976001)(50986001)(66066001)(54316002)(4396001)(74366001)(47736001)(80022001)(65816001)(46102001)(49866001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail24-va3 (localhost.localdomain [127.0.0.1]) by mail24-va3 (MessageSwitch) id 1381764171105572_3426; Mon, 14 Oct 2013 15:22:51 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.246]) by mail24-va3.bigfish.com (Postfix) with ESMTP id 115BE2A0063; Mon, 14 Oct 2013 15:22:51 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 15:22:50 +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.371.2; Mon, 14 Oct 2013 15:22:49 +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.775.9; Mon, 14 Oct 2013 15:22:47 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.188]) with mapi id 15.00.0775.005; Mon, 14 Oct 2013 15:22:47 +0000 From: John E Drake To: Alexander Vainshtein , Gregory Mirsky Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BYAAE12wgAAS/oCAAB9uEIAAcVUAgAABwGCAAAPvUA== Date: Mon, 14 Oct 2013 15:22:46 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B6F8E0D@eusaamb103.ericsson.se> <2bf422c8e5674cbdba8faa198d57e0fa@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.232.2] x-forefront-prvs: 0999136621 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$ecitele.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%ECITELE.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 15:23:07 -0000 Sasha, >From RFC 5654: "Associated bidirectional path: A path that supports traffic flow in both d= irections but that is constructed from a pair of unidirectional paths (one for each direction) that are associated with one another at t= he path's ingress/egress points. The forward and backward directions are setup, monitored, and protected independently. As a cons= equence, they may or may not follow the same route (links and nodes) across the network." Please pay special attention to the last two sentences.=20 Yours Irrespectively, John > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, October 14, 2013 7:58 AM > To: John E Drake; Gregory Mirsky > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-mp= ls- > tp-rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > John, > RFC 5654 states that both directions of a co-routed bi-directional LSP ar= e > protected as a whole. > Hence I do not see how they may participate in a unidirectional protectio= n > scheme. >=20 > Regards, > Sasha >=20 >=20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Monday, October 14, 2013 5:55 PM > > To: Alexander Vainshtein; Gregory Mirsky > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; > > draft-ietf-mpls-tp- rosetta-stone.all@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Yours Irrespectively, > > > > John > > > > > -----Original Message----- > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > > > Behalf > > Of > > > Alexander Vainshtein > > > Sent: Monday, October 14, 2013 1:08 AM > > > To: Gregory Mirsky > > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; > > > draft-ietf-mpls- tp-rosetta-stone.all@tools.ietf.org; > > > rtg-ads@tools.ietf.org > > > Subject: Re: [RTG-DIR] RtgDir review: > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Greg, > > > Lots of thanks for an important comment. > > > > > > Regarding your example: my personal interpretation of 5654 is like > following: > > > - Co-routed bidirectional LSPs MAY be protected using bi-directional > > protection > > > schemes but MUST NOT be protected using unidirectional ones > > > > [JD] I don't think that is true for a pair of co-routed associated > > unidirectional LSPs. > > > > > - Associated bidirectional LSPs MAY be protected using both > > > unidirectional > > and > > > bi-directional protection schemes > > > > [JD] Conversely, if a pair of associated unidirectional LSPs are > > diversely routed, it may be difficult to apply bidirectional > > protection to them. > > > > > > > > Does this match your understanding? > > > > > > Regards, > > > Sasha > > > > > > > -----Original Message----- > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > Sent: Monday, October 14, 2013 9:23 AM > > > > To: Bhatia, Manav (Manav); Alexander Vainshtein > > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; > > > > mpls@ietf.org > > > > Subject: RE: RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Hi Manav, > > > > I do feel that "fate sharing" already has certain interpretation > > > > in the > > > industry. > > > > Difference in, for example, protection between co-routed and > > > > associated bi- directional LSPs doesn't seem not to be described > > > > by "fate sharing". I think of it as in co-routed case LSP > > > > protected as a single entity while in associated case each > > > > direction of LSP is protected > > > independently of the other. > > > > > > > > Regards, > > > > Greg > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > > Behalf Of Bhatia, Manav (Manav) > > > > Sent: Sunday, October 13, 2013 10:26 PM > > > > To: Alexander Vainshtein > > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; > > > > mpls@ietf.org > > > > Subject: Re: [mpls] RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Sasha, > > > > > > > > I think the confusion is over what we mean by "fate sharing". > > > > > > > > To me, if the forward path is torn down for some reason, and that > > > > results in the backward path being torn down as well, then they > > > > inextricably > > > "share the fate". > > > > > > > > If the path of the forward LSP changes because of an IGP trigger, > > > > then the backward LSP changes too in case of co-routed bidirectiona= l > LSPs. > > > > However, this isn't true in case of Associated bidirectional LSPs. > > > > Similarly, an IGP change (or a network event -- link/node flap, > > > > link/node down) will always result in both directions changing > > > > their path in case of co-routed bidirectional LSPs. This doesn't > > > > happen in case of Associated bidirectional LSPs. Its this > > > > difference that I wanted the > > > authors to highlight as part of my review comment. > > > > > > > > If you think "fate sharing" is not the most appropriate term then > > > > you can suggest something else as long as you believe its > > > > something that ought to be mentioned. > > > > > > > > Cheers, Manav > > > > > > > > > -----Original Message----- > > > > > From: Alexander Vainshtein > > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > Sent: Monday, October 14, 2013 9:37 AM > > > > > To: Bhatia, Manav (Manav) > > > > > Cc: rtg-dir@ietf.org; > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > > Subject: RE: RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > > > > > > Manav, > > > > > Lots of thanks for a prompt response. > > > > > > > > > > I must admit that I've mssed the text in 5960 to which you refer. > > > > > > > > > > The original definition, to the best of my understanding, is in > > > > > Section 1.2.2. of RFC 5654 and says something else: > > > > > > > > > > > > > > > Co-routed Bidirectional path: A path where the forward and bac= kward > > > > > directions follow the same route (links and nodes) across the > > > > > network. Both directions are setup, monitored and protected a= s a > > > > > single entity. A transport network path is typically co-route= d. > > > > > > > > > > To me this means that if one of the directions of the co-routed > > > > > bi-directional path fails to convey traffic, the monitoring > > > > > mechanisms will report the entire bi-directional path as failed. > > > > > > > > > > To the best of my recollection when I=3DD to become RFC 5960 has > > > > > been discussed I've asked the authors of RFC 5960 whether the > > > > > pairing between two directions of a co-routed bi-directional > > > > > MPLS-TP LSP in a transit LSR is limited to OAM processing, and > > > > > they (or one of > > > > > them) have confirmed that this is indeed so. > > > > > > > > > > I wonder whether this can be interpreted as "fate-sharing". > > > > > > > > > > Regards, > > > > > Sasha > > > > > > > > > > ________________________________________ > > > > > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > > > Sent: Monday, October 14, 2013 4:21 AM > > > > > To: Alexander Vainshtein > > > > > Cc: rtg-dir@ietf.org; > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > > Subject: RE: RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > Hi Sasha, > > > > > > > > > > RFC 5960 that describes the MPLS-TP data plane says the following= : > > > > > > > > > > A point-to-point co-routed bidirectional LSP is a point-to-point > > > > > associated bidirectional LSP with the additional constraint that > > > > > its two unidirectional component LSPs in each direction follow > > > > > the same path (in terms of both nodes and links). An important > > > > > property of co-routed bidirectional LSPs is that their > > > > > unidirectional component LSPs share fate. > > > > > > > > > > Am I missing something? > > > > > > > > > > Cheers, Manav > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Alexander Vainshtein > > > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > > Sent: Sunday, October 13, 2013 9:46 PM > > > > > > To: Bhatia, Manav (Manav) > > > > > > Cc: rtg-dir@ietf.org; > > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > > > Subject: RE: RtgDir review: > > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > > > Manav and all, > > > > > > Regarding one of the nits you've identified: > > > > > > "it would be useful to mention that an important property > > > > > of co-routed > > > > > > bidirectional path is that the forward and backward > > > > > directions share > > > > > > fate." > > > > > > > > > > > > IMHO and FWIW this is not correct. To the best of my > > > > > understanding the > > > > > > two directions of an MPLS-TP co-routed bi-directional path > > > > > > share lifespan (i.e.,they are set up and torn down in a single > > > > > management or > > > > > > control plane operation). > > > > > > But they do not share fate, as can be seen from the following > > > > > > examples: > > > > > > > > > > > > 1. A unidirectiona fiber cut in one of the links used by a > > > > > co-routed > > > > > > bi-directional trail will result in traffic failur in the > > > > > > affected direction but not necessarily in the reverse one > > > > > > > > > > > > 2. Consider the case when one of entries the ILM in one of > > > > > the transit > > > > > > LSRs is corruped. This will result in incorrect failure of a > > > > > > single label, but the rest of the labels would be handled > > > > > > correctly. Since co-routed bi-directional trails do not > > > > > > require using the > > > > > same label in > > > > > > both directions of a trail, the fate sharing would be broken. > > > > > > (Actually, in such a way it could be easily broken even if the > > > > > > same label is used on each segment of the LSP in both > > > > > > directions...) > > > > > > > > > > > > My 2c, > > > > > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] > > > > > on behalf of > > > > > > Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > > > > Sent: Sunday, October 13, 2013 5:55 PM > > > > > > To: rtg-ads@tools.ietf.org > > > > > > Cc: rtg-dir@ietf.org; > > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > > > mpls@ietf.org > > > > > > Subject: [RTG-DIR] RtgDir review: > > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > > > 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, and sometimes on special request. > > > > > > The purpose of the review is to provide assistance to the > > > > > Routing ADs. > > > > > > For more information about the Routing Directorate, please > > > > > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > > > > > Reviewer: Manav Bhatia > > > > > > Review Date: October 13th, 2013 IETF LC End Date: October 16, > > > > > > 2013 Intended Status: Informational > > > > > > > > > > > > Summary: This document is basically ready for publication, > > > > > > but has nits that should be considered prior to publication. > > > > > > > > > > > > Comments: This document is built on top of terms already > > > > > > defined in different RFCs and ITU-T documents. The terms and > > > > > > definitions have already been reviewed so there is a trifle > > > > > > little that needs to be done there. Overall, the document > > > > > > looks good and ready for publication. Some of my comments can > > > > > > be > > > > > > > > > > > > Nits: > > > > > > > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > > > > > > > o) When explaining Control Plane (3.6) should we mention that > > > > > > it is possible to operate an MPLS-TP network without using a > > > > > Control Plane? > > > > > > > > > > > > o) In 3.7, it would be useful to mention that an important > > > > > property of > > > > > > co-routed bidirectional path is that the forward and backward > > > > > > directions share fate. Similarly, in 3.1, we should mention > > > > > that the > > > > > > forward and backward directions don't share fate. > > > > > > > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it > > > > > > be rephrased it to something like, "The equipment management > > > > > > function > > > > > > (EMF) provides the means through which an element management > > > > > > system > > > > > > (EMS) and other managing entities manage the network > > > > > element function > > > > > > (NEF)." > > > > > > > > > > > > o) 3.13 talks about Fault cause without explaining what a > > > > > fault cause > > > > > > is. It took me some time to understand what was meant by > > > > > > "fault cause". Can the authors of the draft rephrase > > > > > > 3.13 in their own language to explain what they mean by a > > > > > Failure. The > > > > > > current definition in the draft has been picked up as-is from > > > > > > ITU-T > > > > > > G.806 > > > > > > > > > > > > o) 3.14 talks about "inability of a function to perform a > > > > > > required action". Since this RFC-to-be is in the IETF domain, > > > > > > can this be rephrased to use a term like router/switch instead > > > > > > of a > > > > > more esoteric > > > > > > "function". This is a general comment and applies to most of > > > > > > the definitions that have been copied from the ITU-T documents. > > > > > > > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > > > > > > > "OAM packets are subject to the same forwarding treatment > > > > > as the data > > > > > > traffic, but they are distinct from the data traffic." > > > > > > > > > > > > In what sense are the OAM packets distinct from the data traffi= c? > > > > > > > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not > > > > > > been expanded in the document. > > > > > > > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > > > > > > > o) In 3.28.3, can the following text be added: > > > > > > > > > > > > An LSP segment comprises one or more continuous hops on the > > > > > > path of the LSP. [RFC5654] defines two terms. A "segment" > > > > > > is a single hop along the path of an LSP, while a > > > > > > "concatenated segment" is more than one hop along the path of a= n > LSP. > > > > > > > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more > > > > > common term > > > > > > than Operations Systems (OS)? > > > > > > > > > > > > Cheers, Manav > > > > > > > > > > > > This e-mail message is intended for the recipient only and > > > > > > contains information which is CONFIDENTIAL and which may be > > > > > proprietary to ECI > > > > > > Telecom. If you have received this transmission in error, > > > > > > please inform us by e-mail, phone or fax, and then delete the > > > > > > original and all copies thereof. > > > > > > > > > > > > > > > > > > > > > > This e-mail message is intended for the recipient only and > > > > > contains information which is CONFIDENTIAL and which may be > > > > > proprietary to ECI Telecom. If you have received this > > > > > transmission in error, please inform us by e-mail, phone or fax, > > > > > and then delete the original and all copies thereof. > > > > > > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > This e-mail message is intended for the recipient only and contains > > information > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. > > > If you have received this transmission in error, please inform us by > > > e-mail, phone or fax, and then delete the original and all copies the= reof. > > > > > > > > >=20 >=20 >=20 > This e-mail message is intended for the recipient only and contains infor= mation > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this transmission in error, please inform us by e-mail, pho= ne or > fax, and then delete the original and all copies thereof. >=20 >=20 From Alexander.Vainshtein@ecitele.com Mon Oct 14 08:27:16 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB67611E8189; Mon, 14 Oct 2013 08:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 UkG5YRArQtxe; Mon, 14 Oct 2013 08:27:12 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id C0A3811E8144; Mon, 14 Oct 2013 08:27:11 -0700 (PDT) X-AuditID: 93eaf2e7-b7f586d00000770a-93-525c0d4dc2ff Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 46.D3.30474.D4D0C525; Mon, 14 Oct 2013 17:27:09 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 18:27:09 +0300 From: Alexander Vainshtein To: John E Drake Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gAFpNkCAAA4F4IAACoJwgAAEJPA= Date: Mon, 14 Oct 2013 15:27:08 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5ca0484c5ca745bbabd93bb799afaca8@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: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURjlzozbaE5Mq7Y3e7BND02z3B6w0a5EGr0ozcKk97h72x3amZ12 Jsn+JEUPzMAyqLYoo620NqpFMXqQGkaZUdCDEiwoy1SsfERv646TJkT317lzzvnON5fvo0lj myGWFiQV+STewxkiqOLWzu6kxczqzOSegM3acLoszNp87AhlLQm+GTSbnB8IfCXmdz/qMmQQ K/OBjZckr8qryOxEisPOZfiEXN6Rx5kFp52zcGbZwzuQiCTVzvGyjCQnlxJh/ufYsEyQzEhy eJ2C5LJzC5alJ1mtM2YmWbiUCWMt02ZFLHcLihklibzgMYtIUXgXMuMv68tJ97sXBaR8J31L 7b4qQz44Zy8A4TRkp8OKhsOEjofBhy8uGgpABG1kqwEsvHorTL/UAth8rYvUVAbWDkPnGw0a jmbHw7bOll5MshcI2NwoaTiKTYX3nlcBXZMG/fX1hI6XwLa3Hb2Ywt6nl0IY0zTDZsCX90fp WdtJ+P5LRW9WOJsFd1ffoTQMcHef64KEnmWCDU0n/nTNwsD1B6SOY2DL654wHY+GTU11lK6f BEuudf7pMxGeOdnWq2fYofDukSZK1w+H1aXPqCJg8g+I8A+w+wfY/QPsJYA6B2IEj6zmiK5k y2TkEFTkQZMdXjEE9ElpvgK+nRhXA1gacJGMO21VpjGMz1XyxBownCa4GCYjfHWmcUiO15nn 5hX3Ot9mD1JqAKRJLpoR27GccfJ5W5HP20fNxS+4n4wd7PDimZTUddOSk/9/4UzM2fwV6UbW hUdwI0Iy8vXVGUnTHGRuD8bxQ33IhbZsEDzqX5qgw7U2InEbHZqGUWReVASXzteBMbEmhojE BKsR7s1Sv7dvR1qBCf90FPNFs0fiDep3t+LCBC78tT1bK4zXo5+KzQfBuKl7Nt34VDglGCN7 QtmHonLY+D02elPljsfZLcENa3u6in4k/EwwnOyeUz9ykTyr/fX3D7kpHVMTE+1Vvy7Xztuh BtbEiY33doZOBVP37loaX17acrPy4Ijd37Y9mfiquKz4cUXWhZQDC48XH4pOH/+ucobNzR0m j55tf1ZdlPo09SNHKW7ekkD6FP4337IPev4DAAA= Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 15:27:17 -0000 John, Lots of thanks for a prompt response. I fully agree with you that there is no difference in the data plane between= two directions a co-routed bi-directional LSP and two directions of an asso= ciated bi-directional LSP. The difference is mainly in management/control pl= ane, in the OAM etc. This is exactly why I find the term "fate-sharing" inappropriate when it is= applied to forward and backward directions of a co-routed bi-directional LS= P because to me fate-staring refers to first of all to the data plane behavi= or. Regards, Sasha > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Monday, October 14, 2013 6:10 PM > To: Alexander Vainshtein > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-mpl= s-tp- > rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > Sasha, > > My point was simply that in the data plane there isn't any difference betw= een > the two. > > Yours Irrespectively, > > John > > > -----Original Message----- > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Beha= lf > Of > > Alexander Vainshtein > > Sent: Monday, October 14, 2013 7:34 AM > > To: John E Drake > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-m= pls- > > tp-rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org > > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-1= 2.txt > > > > John, > > Not sure I fully understood your message. > > > > My comments have been about applicability of the term "fate-sharing" to= the > > two directions of a co-routed bi-directional LSP. > > It is of course true that each direction of an associated bi-directional= LSP can > > fail independently of the other one, but, presumably, nobody has expecte= d > > anything else in this case. > > > > Regards, > > Sasha > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Monday, October 14, 2013 4:42 PM > > > To: Alexander Vainshtein; Bhatia, Manav (Manav) > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Sasha, > > > > > > I think your comments apply equally to bidirectional LSPs. > > > > > > Yours Irrespectively, > > > > > > John > > > > > > > -----Original Message----- > > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > > > > Behalf > > > Of > > > > Alexander Vainshtein > > > > Sent: Sunday, October 13, 2013 9:16 AM > > > > To: Bhatia, Manav (Manav) > > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > > > Subject: Re: [RTG-DIR] RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Manav and all, > > > > Regarding one of the nits you've identified: > > > > "it would be useful to mention that an important property of > > > > co-routed bidirectional path is that the forward and backward direct= ions > > share fate." > > > > > > > > IMHO and FWIW this is not correct. To the best of my understanding > > > > the two directions of an MPLS-TP co-routed bi-directional path share > > > > lifespan (i.e.,they are set up and torn down in a single management= or > > control plane operation). > > > > But they do not share fate, as can be seen from the following exampl= es: > > > > > > > > 1. A unidirectiona fiber cut in one of the links used by a co-routed > > > > bi- > > > directional > > > > trail will result in traffic failur in the affected direction but > > > > not necessarily in > > > the > > > > reverse one > > > > > > > > 2. Consider the case when one of entries the ILM in one of the > > > > transit LSRs is corruped. This will result in incorrect failure of a > > > > single label, but the rest of > > > the > > > > labels would be handled correctly. Since co-routed bi-directional > > > > trails do not require using the same label in both directions of a > > > > trail, the fate sharing > > > would > > > > be broken. > > > > (Actually, in such a way it could be easily broken even if the same > > > > label is > > > used > > > > on each segment of the LSP in both directions...) > > > > > > > > My 2c, > > > > Sasha > > > > > > > > > > > > > > > > ________________________________________ > > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on behalf > > > > of Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > > Sent: Sunday, October 13, 2013 5:55 PM > > > > To: rtg-ads@tools.ietf.org > > > > Cc: rtg-dir@ietf.org; > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > mpls@ietf.org > > > > Subject: [RTG-DIR] RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > 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, and sometimes on special request. The purpose of the review > > > > is to provide assistance to the Routing ADs. For more information > > > > about the Routing Directorate, please > > > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > > > Reviewer: Manav Bhatia > > > > Review Date: October 13th, 2013 > > > > IETF LC End Date: October 16, 2013 > > > > Intended Status: Informational > > > > > > > > Summary: This document is basically ready for publication, but has > > > > nits that should be considered prior to publication. > > > > > > > > Comments: This document is built on top of terms already defined in > > > > different RFCs and ITU-T documents. The terms and definitions have > > > > already been reviewed so there is a trifle little that needs to be > > > > done there. Overall, the document looks good and ready for > > > > publication. Some of my comments can be > > > > > > > > Nits: > > > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > > > o) When explaining Control Plane (3.6) should we mention that it is > > > > possible > > > to > > > > operate an MPLS-TP network without using a Control Plane? > > > > > > > > o) In 3.7, it would be useful to mention that an important property > > > > of co- > > > routed > > > > bidirectional path is that the forward and backward directions share= fate. > > > > Similarly, in 3.1, we should mention that the forward and backward > > > > directions don't share fate. > > > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be > > > > rephrased it to something like, "The equipment management function > > > > (EMF) provides the means through which an element management system > > > > (EMS) and other managing entities manage the network element functio= n > > (NEF)." > > > > > > > > o) 3.13 talks about Fault cause without explaining what a fault > > > > cause is. It > > > took > > > > me some time to understand what was meant by "fault cause". Can the > > > > authors of the draft rephrase 3.13 in their own language to explain > > > > what they mean by a Failure. The current definition in the draft has > > > > been picked up as-is from ITU-T G.806 > > > > > > > > o) 3.14 talks about "inability of a function to perform a required > > > > action". Since this RFC-to-be is in the IETF domain, can this be > > > > rephrased to use a term like router/switch instead of a more > > > > esoteric "function". This is a general > > > comment > > > > and applies to most of the definitions that have been copied from > > > > the ITU-T documents. > > > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > > > "OAM packets are subject to the same forwarding treatment as the > > > > data traffic, but they are distinct from the data traffic." > > > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been > > > > expanded in the document. > > > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > > > o) In 3.28.3, can the following text be added: > > > > > > > > An LSP segment comprises one or more continuous hops on the path of > > > > the LSP. [RFC5654] defines two terms. A "segment" is a single hop > > > > along the > > > path > > > > of an LSP, while a "concatenated segment" is more than one hop along > > > > the path of an LSP. > > > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more common > > > > term than Operations Systems (OS)? > > > > > > > > Cheers, Manav > > > > > > > > This e-mail message is intended for the recipient only and contains > > > information > > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. > > > > If you have received this transmission in error, please inform us by > > > > e-mail, phone or fax, and then delete the original and all copies th= ereof. > > > > > > > > > > > > > > > > > > > This e-mail message is intended for the recipient only and contains > information > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u > > have received this transmission in error, please inform us by e-mail, ph= one or > > fax, and then delete the original and all copies thereof. > > > > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From jdrake@juniper.net Mon Oct 14 08:38:00 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D0411E819F; Mon, 14 Oct 2013 08:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=-1.443, BAYES_00=-2.599, 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 qBaJTejv-zZT; Mon, 14 Oct 2013 08:37:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id A3C0E11E818E; Mon, 14 Oct 2013 08:37:55 -0700 (PDT) Received: from mail122-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 15:37:55 +0000 Received: from mail122-ch1 (localhost [127.0.0.1]) by mail122-ch1-R.bigfish.com (Postfix) with ESMTP id 1CCAB140074; Mon, 14 Oct 2013 15:37:55 +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: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail122-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)(51704005)(377454003)(13464003)(74706001)(63696002)(54356001)(59766001)(33646001)(51856001)(77982001)(76482001)(76576001)(85306002)(77096001)(56816003)(53806001)(76786001)(69226001)(76796001)(83072001)(4396001)(47976001)(50986001)(19580395003)(54316002)(66066001)(80022001)(47736001)(46102001)(65816001)(49866001)(74366001)(79102001)(80976001)(74876001)(56776001)(74316001)(47446002)(31966008)(81542001)(81686001)(74502001)(19580405001)(83322001)(81342001)(74662001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail122-ch1 (localhost.localdomain [127.0.0.1]) by mail122-ch1 (MessageSwitch) id 1381765073455888_6594; Mon, 14 Oct 2013 15:37:53 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail122-ch1.bigfish.com (Postfix) with ESMTP id 5FF944E0071; Mon, 14 Oct 2013 15:37:53 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 15:37:52 +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.371.2; Mon, 14 Oct 2013 15:37:47 +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.775.9; Mon, 14 Oct 2013 15:37:44 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.188]) with mapi id 15.00.0775.005; Mon, 14 Oct 2013 15:37:44 +0000 From: John E Drake To: Alexander Vainshtein Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gAFpNkCAAA4F4IAACoJwgAAEJPCAAAOHMA== Date: Mon, 14 Oct 2013 15:37:43 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5ca0484c5ca745bbabd93bb799afaca8@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.232.2] x-forefront-prvs: 0999136621 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$ecitele.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%ECITELE.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 15:38:01 -0000 Sasha, I think the use of the term 'fate sharing' here is an example of 'mission c= reep'. Yours Irrespectively, John > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, October 14, 2013 8:27 AM > To: John E Drake > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-mp= ls- > tp-rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > John, > Lots of thanks for a prompt response. >=20 > I fully agree with you that there is no difference in the data plane betw= een two > directions a co-routed bi-directional LSP and two directions of an associ= ated bi- > directional LSP. The difference is mainly in management/control plane, in= the > OAM etc. >=20 > This is exactly why I find the term "fate-sharing" inappropriate when it = is > applied to forward and backward directions of a co-routed bi-directional = LSP > because to me fate-staring refers to first of all to the data plane behav= ior. >=20 > Regards, > Sasha >=20 >=20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Monday, October 14, 2013 6:10 PM > > To: Alexander Vainshtein > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; > > draft-ietf-mpls-tp- rosetta-stone.all@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Sasha, > > > > My point was simply that in the data plane there isn't any difference > > between the two. > > > > Yours Irrespectively, > > > > John > > > > > -----Original Message----- > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > > > Behalf > > Of > > > Alexander Vainshtein > > > Sent: Monday, October 14, 2013 7:34 AM > > > To: John E Drake > > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; > > > draft-ietf-mpls- tp-rosetta-stone.all@tools.ietf.org; > > > rtg-ads@tools.ietf.org > > > Subject: Re: [RTG-DIR] RtgDir review: > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > John, > > > Not sure I fully understood your message. > > > > > > My comments have been about applicability of the term "fate-sharing" > > > to the two directions of a co-routed bi-directional LSP. > > > It is of course true that each direction of an associated > > > bi-directional LSP can fail independently of the other one, but, > > > presumably, nobody has expected anything else in this case. > > > > > > Regards, > > > Sasha > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Monday, October 14, 2013 4:42 PM > > > > To: Alexander Vainshtein; Bhatia, Manav (Manav) > > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; > > > > mpls@ietf.org > > > > Subject: RE: RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Sasha, > > > > > > > > I think your comments apply equally to bidirectional LSPs. > > > > > > > > Yours Irrespectively, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] > > > > > On Behalf > > > > Of > > > > > Alexander Vainshtein > > > > > Sent: Sunday, October 13, 2013 9:16 AM > > > > > To: Bhatia, Manav (Manav) > > > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; > > > > > mpls@ietf.org > > > > > Subject: Re: [RTG-DIR] RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > Manav and all, > > > > > Regarding one of the nits you've identified: > > > > > "it would be useful to mention that an important property of > > > > > co-routed bidirectional path is that the forward and backward > > > > > directions > > > share fate." > > > > > > > > > > IMHO and FWIW this is not correct. To the best of my > > > > > understanding the two directions of an MPLS-TP co-routed > > > > > bi-directional path share lifespan (i.e.,they are set up and > > > > > torn down in a single management or > > > control plane operation). > > > > > But they do not share fate, as can be seen from the following exa= mples: > > > > > > > > > > 1. A unidirectiona fiber cut in one of the links used by a > > > > > co-routed > > > > > bi- > > > > directional > > > > > trail will result in traffic failur in the affected direction > > > > > but not necessarily in > > > > the > > > > > reverse one > > > > > > > > > > 2. Consider the case when one of entries the ILM in one of the > > > > > transit LSRs is corruped. This will result in incorrect failure > > > > > of a single label, but the rest of > > > > the > > > > > labels would be handled correctly. Since co-routed > > > > > bi-directional trails do not require using the same label in > > > > > both directions of a trail, the fate sharing > > > > would > > > > > be broken. > > > > > (Actually, in such a way it could be easily broken even if the > > > > > same label is > > > > used > > > > > on each segment of the LSP in both directions...) > > > > > > > > > > My 2c, > > > > > Sasha > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on > > > > > behalf of Bhatia, Manav (Manav) > > > > > [manav.bhatia@alcatel-lucent.com] > > > > > Sent: Sunday, October 13, 2013 5:55 PM > > > > > To: rtg-ads@tools.ietf.org > > > > > Cc: rtg-dir@ietf.org; > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > > mpls@ietf.org > > > > > Subject: [RTG-DIR] RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > 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, and sometimes on special request. The purpose > > > > > of the review is to provide assistance to the Routing ADs. For > > > > > more information about the Routing Directorate, please > > > > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > > > > Reviewer: Manav Bhatia > > > > > Review Date: October 13th, 2013 > > > > > IETF LC End Date: October 16, 2013 Intended Status: > > > > > Informational > > > > > > > > > > Summary: This document is basically ready for publication, but > > > > > has nits that should be considered prior to publication. > > > > > > > > > > Comments: This document is built on top of terms already defined > > > > > in different RFCs and ITU-T documents. The terms and definitions > > > > > have already been reviewed so there is a trifle little that > > > > > needs to be done there. Overall, the document looks good and > > > > > ready for publication. Some of my comments can be > > > > > > > > > > Nits: > > > > > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > > > > > o) When explaining Control Plane (3.6) should we mention that it > > > > > is possible > > > > to > > > > > operate an MPLS-TP network without using a Control Plane? > > > > > > > > > > o) In 3.7, it would be useful to mention that an important > > > > > property of co- > > > > routed > > > > > bidirectional path is that the forward and backward directions sh= are > fate. > > > > > Similarly, in 3.1, we should mention that the forward and > > > > > backward directions don't share fate. > > > > > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be > > > > > rephrased it to something like, "The equipment management > > > > > function > > > > > (EMF) provides the means through which an element management > > > > > system > > > > > (EMS) and other managing entities manage the network element > > > > > function > > > (NEF)." > > > > > > > > > > o) 3.13 talks about Fault cause without explaining what a fault > > > > > cause is. It > > > > took > > > > > me some time to understand what was meant by "fault cause". Can > > > > > the authors of the draft rephrase 3.13 in their own language to > > > > > explain what they mean by a Failure. The current definition in > > > > > the draft has been picked up as-is from ITU-T G.806 > > > > > > > > > > o) 3.14 talks about "inability of a function to perform a > > > > > required action". Since this RFC-to-be is in the IETF domain, > > > > > can this be rephrased to use a term like router/switch instead > > > > > of a more esoteric "function". This is a general > > > > comment > > > > > and applies to most of the definitions that have been copied > > > > > from the ITU-T documents. > > > > > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > > > > > "OAM packets are subject to the same forwarding treatment as the > > > > > data traffic, but they are distinct from the data traffic." > > > > > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not > > > > > been expanded in the document. > > > > > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > > > > > o) In 3.28.3, can the following text be added: > > > > > > > > > > An LSP segment comprises one or more continuous hops on the path > > > > > of the LSP. [RFC5654] defines two terms. A "segment" is a > > > > > single hop along the > > > > path > > > > > of an LSP, while a "concatenated segment" is more than one hop > > > > > along the path of an LSP. > > > > > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more common > > > > > term than Operations Systems (OS)? > > > > > > > > > > Cheers, Manav > > > > > > > > > > This e-mail message is intended for the recipient only and > > > > > contains > > > > information > > > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom= . > > > > > If you have received this transmission in error, please inform > > > > > us by e-mail, phone or fax, and then delete the original and all = copies > thereof. > > > > > > > > > > > > > > > > > > > > > > > > > > This e-mail message is intended for the recipient only and contains > > information > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. > > > If you have received this transmission in error, please inform us by > > > e-mail, phone or fax, and then delete the original and all copies the= reof. > > > > > > > > >=20 >=20 >=20 > This e-mail message is intended for the recipient only and contains infor= mation > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this transmission in error, please inform us by e-mail, pho= ne or > fax, and then delete the original and all copies thereof. >=20 >=20 From jdrake@juniper.net Mon Oct 14 09:13:49 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE61A11E8184; Mon, 14 Oct 2013 09:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=-1.871, BAYES_00=-2.599, 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 9v-QN-FlWINj; Mon, 14 Oct 2013 09:13:44 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id B6A8411E8160; Mon, 14 Oct 2013 09:13:42 -0700 (PDT) Received: from mail169-db8-R.bigfish.com (10.174.8.238) by DB8EHSOBE031.bigfish.com (10.174.4.94) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 16:13:41 +0000 Received: from mail169-db8 (localhost [127.0.0.1]) by mail169-db8-R.bigfish.com (Postfix) with ESMTP id 58D87D200EF; Mon, 14 Oct 2013 16:13:41 +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: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail169-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=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(189002)(199002)(13464003)(54316002)(56776001)(85306002)(81686001)(76482001)(65816001)(66066001)(80022001)(74366001)(79102001)(77982001)(63696002)(59766001)(15975445006)(81816001)(74876001)(74706001)(83072001)(69226001)(47736001)(49866001)(50986001)(47976001)(53806001)(51856001)(46102001)(4396001)(83322001)(74502001)(19580405001)(74662001)(54356001)(80976001)(19580395003)(47446002)(31966008)(81542001)(74316001)(76796001)(76786001)(76576001)(81342001)(77096001)(33646001)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail169-db8 (localhost.localdomain [127.0.0.1]) by mail169-db8 (MessageSwitch) id 1381767219359060_26493; Mon, 14 Oct 2013 16:13:39 +0000 (UTC) Received: from DB8EHSMHS008.bigfish.com (unknown [10.174.8.230]) by mail169-db8.bigfish.com (Postfix) with ESMTP id 5070B9001B5; Mon, 14 Oct 2013 16:13:39 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS008.bigfish.com (10.174.4.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 16:13:38 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 14 Oct 2013 16:13:35 +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.775.9; Mon, 14 Oct 2013 16:13:33 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.188]) with mapi id 15.00.0775.005; Mon, 14 Oct 2013 16:13:33 +0000 From: John E Drake To: Gregory Mirsky , Alexander Vainshtein Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gAFpNkCAAA4F4IAACoJwgAAEJPCAAAh7oIAABUhw Date: Mon, 14 Oct 2013 16:13:32 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5ca0484c5ca745bbabd93bb799afaca8@BY2PR05MB142.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B6F8FD9@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B6F8FD9@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0999136621 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$ecitele.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%ECITELE.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 16:13:49 -0000 Greg, I don't recall mentioning OAM.=20 Yours Irrespectively, John > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, October 14, 2013 9:01 AM > To: Alexander Vainshtein; John E Drake > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; Bhatia, Manav (Manav); draf= t- > ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > Hi Sasha, John, et. al, > isn't there bit of contradiction when first stating that co-routed bidire= ctional > and associated bidirectional LSPs are indistinguishable in data plane to = note > that there are difference in their OAM? OAM, in large part, is in data pl= ane and > how co-routed and associated bidirectional LSP being references in OAM is > different in the data plane, not only in control and/or management planes= . >=20 > Regards, > Greg >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Monday, October 14, 2013 8:27 AM > To: John E Drake > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; Bhatia, Manav (Manav); draf= t- > ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.tx= t >=20 > John, > Lots of thanks for a prompt response. >=20 > I fully agree with you that there is no difference in the data plane betw= een two > directions a co-routed bi-directional LSP and two directions of an associ= ated bi- > directional LSP. The difference is mainly in management/control plane, in= the > OAM etc. >=20 > This is exactly why I find the term "fate-sharing" inappropriate when it = is > applied to forward and backward directions of a co-routed bi-directional = LSP > because to me fate-staring refers to first of all to the data plane behav= ior. >=20 > Regards, > Sasha >=20 >=20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Monday, October 14, 2013 6:10 PM > > To: Alexander Vainshtein > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; > > draft-ietf-mpls-tp- rosetta-stone.all@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Sasha, > > > > My point was simply that in the data plane there isn't any difference > > between the two. > > > > Yours Irrespectively, > > > > John > > > > > -----Original Message----- > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > > > Behalf > > Of > > > Alexander Vainshtein > > > Sent: Monday, October 14, 2013 7:34 AM > > > To: John E Drake > > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; > > > draft-ietf-mpls- tp-rosetta-stone.all@tools.ietf.org; > > > rtg-ads@tools.ietf.org > > > Subject: Re: [RTG-DIR] RtgDir review: > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > John, > > > Not sure I fully understood your message. > > > > > > My comments have been about applicability of the term "fate-sharing" > > > to the two directions of a co-routed bi-directional LSP. > > > It is of course true that each direction of an associated > > > bi-directional LSP can fail independently of the other one, but, > > > presumably, nobody has expected anything else in this case. > > > > > > Regards, > > > Sasha > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Monday, October 14, 2013 4:42 PM > > > > To: Alexander Vainshtein; Bhatia, Manav (Manav) > > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; > > > > mpls@ietf.org > > > > Subject: RE: RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Sasha, > > > > > > > > I think your comments apply equally to bidirectional LSPs. > > > > > > > > Yours Irrespectively, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] > > > > > On Behalf > > > > Of > > > > > Alexander Vainshtein > > > > > Sent: Sunday, October 13, 2013 9:16 AM > > > > > To: Bhatia, Manav (Manav) > > > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; > > > > > mpls@ietf.org > > > > > Subject: Re: [RTG-DIR] RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > Manav and all, > > > > > Regarding one of the nits you've identified: > > > > > "it would be useful to mention that an important property of > > > > > co-routed bidirectional path is that the forward and backward > > > > > directions > > > share fate." > > > > > > > > > > IMHO and FWIW this is not correct. To the best of my > > > > > understanding the two directions of an MPLS-TP co-routed > > > > > bi-directional path share lifespan (i.e.,they are set up and > > > > > torn down in a single management or > > > control plane operation). > > > > > But they do not share fate, as can be seen from the following exa= mples: > > > > > > > > > > 1. A unidirectiona fiber cut in one of the links used by a > > > > > co-routed > > > > > bi- > > > > directional > > > > > trail will result in traffic failur in the affected direction > > > > > but not necessarily in > > > > the > > > > > reverse one > > > > > > > > > > 2. Consider the case when one of entries the ILM in one of the > > > > > transit LSRs is corruped. This will result in incorrect failure > > > > > of a single label, but the rest of > > > > the > > > > > labels would be handled correctly. Since co-routed > > > > > bi-directional trails do not require using the same label in > > > > > both directions of a trail, the fate sharing > > > > would > > > > > be broken. > > > > > (Actually, in such a way it could be easily broken even if the > > > > > same label is > > > > used > > > > > on each segment of the LSP in both directions...) > > > > > > > > > > My 2c, > > > > > Sasha > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on > > > > > behalf of Bhatia, Manav (Manav) > > > > > [manav.bhatia@alcatel-lucent.com] > > > > > Sent: Sunday, October 13, 2013 5:55 PM > > > > > To: rtg-ads@tools.ietf.org > > > > > Cc: rtg-dir@ietf.org; > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > > mpls@ietf.org > > > > > Subject: [RTG-DIR] RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > 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, and sometimes on special request. The purpose > > > > > of the review is to provide assistance to the Routing ADs. For > > > > > more information about the Routing Directorate, please > > > > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > > > > Reviewer: Manav Bhatia > > > > > Review Date: October 13th, 2013 > > > > > IETF LC End Date: October 16, 2013 Intended Status: > > > > > Informational > > > > > > > > > > Summary: This document is basically ready for publication, but > > > > > has nits that should be considered prior to publication. > > > > > > > > > > Comments: This document is built on top of terms already defined > > > > > in different RFCs and ITU-T documents. The terms and definitions > > > > > have already been reviewed so there is a trifle little that > > > > > needs to be done there. Overall, the document looks good and > > > > > ready for publication. Some of my comments can be > > > > > > > > > > Nits: > > > > > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > > > > > o) When explaining Control Plane (3.6) should we mention that it > > > > > is possible > > > > to > > > > > operate an MPLS-TP network without using a Control Plane? > > > > > > > > > > o) In 3.7, it would be useful to mention that an important > > > > > property of co- > > > > routed > > > > > bidirectional path is that the forward and backward directions sh= are > fate. > > > > > Similarly, in 3.1, we should mention that the forward and > > > > > backward directions don't share fate. > > > > > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be > > > > > rephrased it to something like, "The equipment management > > > > > function > > > > > (EMF) provides the means through which an element management > > > > > system > > > > > (EMS) and other managing entities manage the network element > > > > > function > > > (NEF)." > > > > > > > > > > o) 3.13 talks about Fault cause without explaining what a fault > > > > > cause is. It > > > > took > > > > > me some time to understand what was meant by "fault cause". Can > > > > > the authors of the draft rephrase 3.13 in their own language to > > > > > explain what they mean by a Failure. The current definition in > > > > > the draft has been picked up as-is from ITU-T G.806 > > > > > > > > > > o) 3.14 talks about "inability of a function to perform a > > > > > required action". Since this RFC-to-be is in the IETF domain, > > > > > can this be rephrased to use a term like router/switch instead > > > > > of a more esoteric "function". This is a general > > > > comment > > > > > and applies to most of the definitions that have been copied > > > > > from the ITU-T documents. > > > > > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > > > > > "OAM packets are subject to the same forwarding treatment as the > > > > > data traffic, but they are distinct from the data traffic." > > > > > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not > > > > > been expanded in the document. > > > > > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > > > > > o) In 3.28.3, can the following text be added: > > > > > > > > > > An LSP segment comprises one or more continuous hops on the path > > > > > of the LSP. [RFC5654] defines two terms. A "segment" is a > > > > > single hop along the > > > > path > > > > > of an LSP, while a "concatenated segment" is more than one hop > > > > > along the path of an LSP. > > > > > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more common > > > > > term than Operations Systems (OS)? > > > > > > > > > > Cheers, Manav > > > > > > > > > > This e-mail message is intended for the recipient only and > > > > > contains > > > > information > > > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom= . > > > > > If you have received this transmission in error, please inform > > > > > us by e-mail, phone or fax, and then delete the original and all = copies > thereof. > > > > > > > > > > > > > > > > > > > > > > > > > > This e-mail message is intended for the recipient only and contains > > information > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. > > > If you have received this transmission in error, please inform us by > > > e-mail, phone or fax, and then delete the original and all copies the= reof. > > > > > > > > >=20 >=20 >=20 > This e-mail message is intended for the recipient only and contains infor= mation > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this transmission in error, please inform us by e-mail, pho= ne or > fax, and then delete the original and all copies thereof. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From Alexander.Vainshtein@ecitele.com Mon Oct 14 09:40:43 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA36821F9F0E for ; Mon, 14 Oct 2013 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 2U0+CQ+BrWKn for ; Mon, 14 Oct 2013 09:40:39 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEFC21E80D0 for ; Mon, 14 Oct 2013 09:40:37 -0700 (PDT) X-AuditID: 93eaf2e7-b7f586d00000770a-b3-525c1e84cdff Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id D9.15.30474.48E1C525; Mon, 14 Oct 2013 18:40:36 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 19:40:36 +0300 From: Alexander Vainshtein To: Gregory Mirsky Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gAFpNkCAAA4F4IAACoJwgAAEJPCAAAh7oIAABxZQ Date: Mon, 14 Oct 2013 16:40:35 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5ca0484c5ca745bbabd93bb799afaca8@BY2PR05MB142.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B6F8FD9@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B6F8FD9@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTWUwTURTldYYy1I4ZCtgnLqkDEpUlrUtSoyUaNGJMZDMuiMFh+mgnttOm M4pgTHD7UUlUYoSKUpMGCBKJIGIEREGjAi4RiQhuKG4YP0SioR/otCNIYpyv895Z7n2TewlM 800ZRXC8iFw8Y6OVKrxkeGQ04fDc7Ay95/JCY/nLZOPH8jLc6Kl9H7IKS/F6xxQpzw72hqSM 9nxXpmFZRWAlw/MOkRGRzowE1kSnubg9DFtA6ziziTbQOqeNYZEd8aKJZpxOxJvpJJXun2+l JON4HeJZh5njLSZ6fWZqgtG4bHmCgU6KjTYsWaHaZOUEHUqwM5xNZ0eCwFiQTrrZeQWzvj3X pnQ2Off6GnpBEXi6+SgIJSC1FB4vbQiR8Qz4+FWd8ihQERrqFoCDt/sw+XAHwPH7lwIqJWWC 9RdfKv04gtLDgcqqgAijnijgkbOtwX4inEqGXc9vAlm0Brq7uxUyzoKnjhwIBOHUfNj+4FNA Q1JpsKtp8E/pYhzeG5XNodRG6OupCZiB1N/PztoAxigt7B+qUMh9U9Db8giTcST8/G48WMZz 4dBQJy7r46GneUQp4zhYeeELJhcOg/fLhnBZPxPequ7DTwCte0oJ9xS7e4rdPcXuAXgNiORs TjHXbtEbEhHLiciGElmHvR7I8/LxGvBVxLQDigC0mkynsjM0wcweocDeDmYSCjqSjJslXU3P dZgLrIxgzXHttiGhHUACoyNI+9ftGRrSzBQUIpdjglor/cKTWNQ01iFNJi/mLNHr/3+gtWRV 0ZZUDWWRhnAXQk7kmsiZTRA0JM/PkcqHuZAF7c3jbOJfWkGE+ttQS22k+zWk4GTsAmeR+U4w L0pLHvMTlJ+w7uYnvRObMgy00qPDyVK/Si3t0aR7WApWSMFjX7f6g6UFmaSiikBJk2/s03kC xRzg77SB5sT9G2ZkB1WuGxgLXpzP9eeDH2zhmrrokSTPwzfmt9YedQwcH9ymHYlr3t91Y0Gt Iz/8TXljMZkJkrz3DhbeKH3xM+bQ67veH21dffHfqjvOhVSI8bH8r9MteTtaTT545mpHoptd /UHdOFAxbd/O6yVBNC5YGcMizCUwvwF56Q8MBAQAAA== Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , John E Drake , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 16:40:44 -0000 Greg, Lots of thanks for a prompt response. I do not think that there is any contradiction between the two statements in= question: 1. From the data plane point of view, when an OAM packet is trapped by a tra= nsit LSR due to TTL expiration (there is no other way to do that), it is ide= ntified as such based on the GAL/GACH in its label stack and passed to the "= OAM engine" which is NOT part of the data plane. 2. The difference between co-routed and associated bidirectional LSPs only c= omes into play if/when the "OAM engine", as part of its handling of the spec= ific trapped packet, decides to send a response back to the its originator: (a) In the case of an associated bi-directional LSP it may be unable to do s= o in MPLS-TP (in IP/MPLS the response could be sent as an unlabeled packet) - In the case of a co-routed bi-directional LSP it can always send a respons= e to the head-end LER because it understands the pairing between the forward= and backward directions of this LSP (and it is the only entity that underst= ands that). This pairing effectively means that the outgoing label for the b= ackward direction of the co-routed bi-directional LSP can be found by the OA= M engine if it knows the incoming label (and its context) of the trapped OAM= packet - If (as in the case of segment OAM) the response should be trapped by an up= stream transit LSR and not by the head-end, it needs, the OAM engine, in add= ition to forming an appropriate label stack, must set the TTL to the right v= alue - this is what http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-ttl-= tlv-05 is about. Hopefully these notes clarify my understanding of the situation. IMHO and FW= IW they comply with the general claim of shared data plane between IP/MPLS a= nd MPLS-TP. Regards, Sasha > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, October 14, 2013 7:01 PM > To: Alexander Vainshtein; John E Drake > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; Bhatia, Manav (Manav); draft= -ietf- > mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > Hi Sasha, John, et. al, > isn't there bit of contradiction when first stating that co-routed bidirec= tional > and associated bidirectional LSPs are indistinguishable in data plane to n= ote > that there are difference in their OAM? OAM, in large part, is in data pla= ne and > how co-routed and associated bidirectional LSP being references in OAM is > different in the data plane, not only in control and/or management planes. > > Regards, > Greg > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Monday, October 14, 2013 8:27 AM > To: John E Drake > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; Bhatia, Manav (Manav); draft= -ietf- > mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > John, > Lots of thanks for a prompt response. > > I fully agree with you that there is no difference in the data plane betwe= en two > directions a co-routed bi-directional LSP and two directions of an associa= ted bi- > directional LSP. The difference is mainly in management/control plane, in= the > OAM etc. > > This is exactly why I find the term "fate-sharing" inappropriate when it i= s > applied to forward and backward directions of a co-routed bi-directional L= SP > because to me fate-staring refers to first of all to the data plane behavi= or. > > Regards, > Sasha > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Monday, October 14, 2013 6:10 PM > > To: Alexander Vainshtein > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; > > draft-ietf-mpls-tp- rosetta-stone.all@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Sasha, > > > > My point was simply that in the data plane there isn't any difference > > between the two. > > > > Yours Irrespectively, > > > > John > > > > > -----Original Message----- > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > > > Behalf > > Of > > > Alexander Vainshtein > > > Sent: Monday, October 14, 2013 7:34 AM > > > To: John E Drake > > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; > > > draft-ietf-mpls- tp-rosetta-stone.all@tools.ietf.org; > > > rtg-ads@tools.ietf.org > > > Subject: Re: [RTG-DIR] RtgDir review: > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > John, > > > Not sure I fully understood your message. > > > > > > My comments have been about applicability of the term "fate-sharing" > > > to the two directions of a co-routed bi-directional LSP. > > > It is of course true that each direction of an associated > > > bi-directional LSP can fail independently of the other one, but, > > > presumably, nobody has expected anything else in this case. > > > > > > Regards, > > > Sasha > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Monday, October 14, 2013 4:42 PM > > > > To: Alexander Vainshtein; Bhatia, Manav (Manav) > > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; > > > > mpls@ietf.org > > > > Subject: RE: RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Sasha, > > > > > > > > I think your comments apply equally to bidirectional LSPs. > > > > > > > > Yours Irrespectively, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] > > > > > On Behalf > > > > Of > > > > > Alexander Vainshtein > > > > > Sent: Sunday, October 13, 2013 9:16 AM > > > > > To: Bhatia, Manav (Manav) > > > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; > > > > > mpls@ietf.org > > > > > Subject: Re: [RTG-DIR] RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > Manav and all, > > > > > Regarding one of the nits you've identified: > > > > > "it would be useful to mention that an important property of > > > > > co-routed bidirectional path is that the forward and backward > > > > > directions > > > share fate." > > > > > > > > > > IMHO and FWIW this is not correct. To the best of my > > > > > understanding the two directions of an MPLS-TP co-routed > > > > > bi-directional path share lifespan (i.e.,they are set up and > > > > > torn down in a single management or > > > control plane operation). > > > > > But they do not share fate, as can be seen from the following exam= ples: > > > > > > > > > > 1. A unidirectiona fiber cut in one of the links used by a > > > > > co-routed > > > > > bi- > > > > directional > > > > > trail will result in traffic failur in the affected direction > > > > > but not necessarily in > > > > the > > > > > reverse one > > > > > > > > > > 2. Consider the case when one of entries the ILM in one of the > > > > > transit LSRs is corruped. This will result in incorrect failure > > > > > of a single label, but the rest of > > > > the > > > > > labels would be handled correctly. Since co-routed > > > > > bi-directional trails do not require using the same label in > > > > > both directions of a trail, the fate sharing > > > > would > > > > > be broken. > > > > > (Actually, in such a way it could be easily broken even if the > > > > > same label is > > > > used > > > > > on each segment of the LSP in both directions...) > > > > > > > > > > My 2c, > > > > > Sasha > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on > > > > > behalf of Bhatia, Manav (Manav) > > > > > [manav.bhatia@alcatel-lucent.com] > > > > > Sent: Sunday, October 13, 2013 5:55 PM > > > > > To: rtg-ads@tools.ietf.org > > > > > Cc: rtg-dir@ietf.org; > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > > mpls@ietf.org > > > > > Subject: [RTG-DIR] RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > 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, and sometimes on special request. The purpose > > > > > of the review is to provide assistance to the Routing ADs. For > > > > > more information about the Routing Directorate, please > > > > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > > > > Reviewer: Manav Bhatia > > > > > Review Date: October 13th, 2013 > > > > > IETF LC End Date: October 16, 2013 Intended Status: > > > > > Informational > > > > > > > > > > Summary: This document is basically ready for publication, but > > > > > has nits that should be considered prior to publication. > > > > > > > > > > Comments: This document is built on top of terms already defined > > > > > in different RFCs and ITU-T documents. The terms and definitions > > > > > have already been reviewed so there is a trifle little that > > > > > needs to be done there. Overall, the document looks good and > > > > > ready for publication. Some of my comments can be > > > > > > > > > > Nits: > > > > > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > > > > > o) When explaining Control Plane (3.6) should we mention that it > > > > > is possible > > > > to > > > > > operate an MPLS-TP network without using a Control Plane? > > > > > > > > > > o) In 3.7, it would be useful to mention that an important > > > > > property of co- > > > > routed > > > > > bidirectional path is that the forward and backward directions sha= re > fate. > > > > > Similarly, in 3.1, we should mention that the forward and > > > > > backward directions don't share fate. > > > > > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be > > > > > rephrased it to something like, "The equipment management > > > > > function > > > > > (EMF) provides the means through which an element management > > > > > system > > > > > (EMS) and other managing entities manage the network element > > > > > function > > > (NEF)." > > > > > > > > > > o) 3.13 talks about Fault cause without explaining what a fault > > > > > cause is. It > > > > took > > > > > me some time to understand what was meant by "fault cause". Can > > > > > the authors of the draft rephrase 3.13 in their own language to > > > > > explain what they mean by a Failure. The current definition in > > > > > the draft has been picked up as-is from ITU-T G.806 > > > > > > > > > > o) 3.14 talks about "inability of a function to perform a > > > > > required action". Since this RFC-to-be is in the IETF domain, > > > > > can this be rephrased to use a term like router/switch instead > > > > > of a more esoteric "function". This is a general > > > > comment > > > > > and applies to most of the definitions that have been copied > > > > > from the ITU-T documents. > > > > > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > > > > > "OAM packets are subject to the same forwarding treatment as the > > > > > data traffic, but they are distinct from the data traffic." > > > > > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not > > > > > been expanded in the document. > > > > > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > > > > > o) In 3.28.3, can the following text be added: > > > > > > > > > > An LSP segment comprises one or more continuous hops on the path > > > > > of the LSP. [RFC5654] defines two terms. A "segment" is a > > > > > single hop along the > > > > path > > > > > of an LSP, while a "concatenated segment" is more than one hop > > > > > along the path of an LSP. > > > > > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more common > > > > > term than Operations Systems (OS)? > > > > > > > > > > Cheers, Manav > > > > > > > > > > This e-mail message is intended for the recipient only and > > > > > contains > > > > information > > > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. > > > > > If you have received this transmission in error, please inform > > > > > us by e-mail, phone or fax, and then delete the original and all c= opies > thereof. > > > > > > > > > > > > > > > > > > > > > > > > > > This e-mail message is intended for the recipient only and contains > > information > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. > > > If you have received this transmission in error, please inform us by > > > e-mail, phone or fax, and then delete the original and all copies ther= eof. > > > > > > > > > > > > This e-mail message is intended for the recipient only and contains inform= ation > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this transmission in error, please inform us by e-mail, phon= e or > fax, and then delete the original and all copies thereof. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From jdrake@juniper.net Mon Oct 14 10:08:45 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5537F21E818D; Mon, 14 Oct 2013 10:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-1.782, BAYES_00=-2.599, 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 9p2c1zrjQ3K7; Mon, 14 Oct 2013 10:08:40 -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 5532921E809F; Mon, 14 Oct 2013 10:08:38 -0700 (PDT) Received: from mail1-db8-R.bigfish.com (10.174.8.249) by DB8EHSOBE032.bigfish.com (10.174.4.95) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 17:08:37 +0000 Received: from mail1-db8 (localhost [127.0.0.1]) by mail1-db8-R.bigfish.com (Postfix) with ESMTP id 62539B00165; Mon, 14 Oct 2013 17:08:37 +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: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail1-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:(199002)(189002)(51704005)(377454003)(13464003)(74706001)(63696002)(54356001)(59766001)(33646001)(51856001)(77982001)(76482001)(76576001)(85306002)(77096001)(56816003)(53806001)(76786001)(69226001)(76796001)(83072001)(4396001)(47976001)(50986001)(19580395003)(54316002)(66066001)(80022001)(47736001)(46102001)(65816001)(49866001)(74366001)(15975445006)(79102001)(80976001)(74876001)(56776001)(74316001)(47446002)(31966008)(81542001)(81686001)(74502001)(19580405001)(83322001)(81342001)(74662001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail1-db8 (localhost.localdomain [127.0.0.1]) by mail1-db8 (MessageSwitch) id 1381770514603273_7264; Mon, 14 Oct 2013 17:08:34 +0000 (UTC) Received: from DB8EHSMHS032.bigfish.com (unknown [10.174.8.236]) by mail1-db8.bigfish.com (Postfix) with ESMTP id 8DEA91640047; Mon, 14 Oct 2013 17:08:34 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS032.bigfish.com (10.174.4.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 17:08:34 +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.371.2; Mon, 14 Oct 2013 17:08:32 +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.775.9; Mon, 14 Oct 2013 17:08:30 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.188]) with mapi id 15.00.0775.005; Mon, 14 Oct 2013 17:08:30 +0000 From: John E Drake To: Gregory Mirsky , Alexander Vainshtein Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BYAAE12wgAAS/oCAAB9uEIAAcVUAgAAhKkCAAARRYA== Date: Mon, 14 Oct 2013 17:08:29 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B6F8E0D@eusaamb103.ericsson.se> <2bf422c8e5674cbdba8faa198d57e0fa@BY2PR05MB142.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B6F9071@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B6F9071@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0999136621 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$ecitele.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%ECITELE.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 17:08:45 -0000 Greg, I think the text I quoted from RFC 5654 is remarkably clear. Eric is certa= inly entitled to his opinion but it doesn't seem to be aligned with RFC 565= 4. Yours Irrespectively, John > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, October 14, 2013 10:02 AM > To: John E Drake; Alexander Vainshtein > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-mp= ls- > tp-rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > Hi John, > I was thinking that two unidirectional LSPs that happen to be co-routed c= an > form an associated bi-directional LSP. I believe that Eric Gray explained= that > that was not interpretation and intention of RFC 5960 to see co-routed bi= - > directional p2p LSP not as single unified object but as two federated obj= ects. I > recall that intention was to have case of accidental co-routedness in > associated p2p LSP. In other words, associated bi-directional was not mea= nt to > happen to be co-routed. Well, that is my recollection of talking with Eri= c and > hope it's accurate one. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Monday, October 14, 2013 7:55 AM > To: Alexander Vainshtein; Gregory Mirsky > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-mp= ls- > tp-rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 >=20 >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > > Behalf Of Alexander Vainshtein > > Sent: Monday, October 14, 2013 1:08 AM > > To: Gregory Mirsky > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; > > draft-ietf-mpls- tp-rosetta-stone.all@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: Re: [RTG-DIR] RtgDir review: > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Greg, > > Lots of thanks for an important comment. > > > > Regarding your example: my personal interpretation of 5654 is like foll= owing: > > - Co-routed bidirectional LSPs MAY be protected using bi-directional > > protection schemes but MUST NOT be protected using unidirectional ones >=20 > [JD] I don't think that is true for a pair of co-routed associated unidi= rectional > LSPs. >=20 > > - Associated bidirectional LSPs MAY be protected using both > > unidirectional and bi-directional protection schemes >=20 > [JD] Conversely, if a pair of associated unidirectional LSPs are diverse= ly routed, > it > may be difficult to apply bidirectional protection to them. >=20 > > > > Does this match your understanding? > > > > Regards, > > Sasha > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Monday, October 14, 2013 9:23 AM > > > To: Bhatia, Manav (Manav); Alexander Vainshtein > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Hi Manav, > > > I do feel that "fate sharing" already has certain interpretation in > > > the > > industry. > > > Difference in, for example, protection between co-routed and > > > associated bi- directional LSPs doesn't seem not to be described by > > > "fate sharing". I think of it as in co-routed case LSP protected as > > > a single entity while in associated case each direction of LSP is > > > protected > > independently of the other. > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > > Of Bhatia, Manav (Manav) > > > Sent: Sunday, October 13, 2013 10:26 PM > > > To: Alexander Vainshtein > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > > Subject: Re: [mpls] RtgDir review: > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Sasha, > > > > > > I think the confusion is over what we mean by "fate sharing". > > > > > > To me, if the forward path is torn down for some reason, and that > > > results in the backward path being torn down as well, then they > > > inextricably > > "share the fate". > > > > > > If the path of the forward LSP changes because of an IGP trigger, > > > then the backward LSP changes too in case of co-routed bidirectional = LSPs. > > > However, this isn't true in case of Associated bidirectional LSPs. > > > Similarly, an IGP change (or a network event -- link/node flap, > > > link/node down) will always result in both directions changing their > > > path in case of co-routed bidirectional LSPs. This doesn't happen in > > > case of Associated bidirectional LSPs. Its this difference that I > > > wanted the > > authors to highlight as part of my review comment. > > > > > > If you think "fate sharing" is not the most appropriate term then > > > you can suggest something else as long as you believe its something > > > that ought to be mentioned. > > > > > > Cheers, Manav > > > > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Monday, October 14, 2013 9:37 AM > > > > To: Bhatia, Manav (Manav) > > > > Cc: rtg-dir@ietf.org; > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > Subject: RE: RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > > > Manav, > > > > Lots of thanks for a prompt response. > > > > > > > > I must admit that I've mssed the text in 5960 to which you refer. > > > > > > > > The original definition, to the best of my understanding, is in > > > > Section 1.2.2. of RFC 5654 and says something else: > > > > > > > > > > > > Co-routed Bidirectional path: A path where the forward and backw= ard > > > > directions follow the same route (links and nodes) across the > > > > network. Both directions are setup, monitored and protected as = a > > > > single entity. A transport network path is typically co-routed. > > > > > > > > To me this means that if one of the directions of the co-routed > > > > bi-directional path fails to convey traffic, the monitoring > > > > mechanisms will report the entire bi-directional path as failed. > > > > > > > > To the best of my recollection when I=3DD to become RFC 5960 has > > > > been discussed I've asked the authors of RFC 5960 whether the > > > > pairing between two directions of a co-routed bi-directional > > > > MPLS-TP LSP in a transit LSR is limited to OAM processing, and > > > > they (or one of > > > > them) have confirmed that this is indeed so. > > > > > > > > I wonder whether this can be interpreted as "fate-sharing". > > > > > > > > Regards, > > > > Sasha > > > > > > > > ________________________________________ > > > > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > > Sent: Monday, October 14, 2013 4:21 AM > > > > To: Alexander Vainshtein > > > > Cc: rtg-dir@ietf.org; > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > Subject: RE: RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Hi Sasha, > > > > > > > > RFC 5960 that describes the MPLS-TP data plane says the following: > > > > > > > > A point-to-point co-routed bidirectional LSP is a point-to-point > > > > associated bidirectional LSP with the additional constraint that > > > > its two unidirectional component LSPs in each direction follow the > > > > same path (in terms of both nodes and links). An important > > > > property of co-routed bidirectional LSPs is that their > > > > unidirectional component LSPs share fate. > > > > > > > > Am I missing something? > > > > > > > > Cheers, Manav > > > > > > > > > > > > > -----Original Message----- > > > > > From: Alexander Vainshtein > > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > Sent: Sunday, October 13, 2013 9:46 PM > > > > > To: Bhatia, Manav (Manav) > > > > > Cc: rtg-dir@ietf.org; > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > > Subject: RE: RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > Manav and all, > > > > > Regarding one of the nits you've identified: > > > > > "it would be useful to mention that an important property > > > > of co-routed > > > > > bidirectional path is that the forward and backward > > > > directions share > > > > > fate." > > > > > > > > > > IMHO and FWIW this is not correct. To the best of my > > > > understanding the > > > > > two directions of an MPLS-TP co-routed bi-directional path share > > > > > lifespan (i.e.,they are set up and torn down in a single > > > > management or > > > > > control plane operation). > > > > > But they do not share fate, as can be seen from the following > > > > > examples: > > > > > > > > > > 1. A unidirectiona fiber cut in one of the links used by a > > > > co-routed > > > > > bi-directional trail will result in traffic failur in the > > > > > affected direction but not necessarily in the reverse one > > > > > > > > > > 2. Consider the case when one of entries the ILM in one of > > > > the transit > > > > > LSRs is corruped. This will result in incorrect failure of a > > > > > single label, but the rest of the labels would be handled > > > > > correctly. Since co-routed bi-directional trails do not require > > > > > using the > > > > same label in > > > > > both directions of a trail, the fate sharing would be broken. > > > > > (Actually, in such a way it could be easily broken even if the > > > > > same label is used on each segment of the LSP in both > > > > > directions...) > > > > > > > > > > My 2c, > > > > > Sasha > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] > > > > on behalf of > > > > > Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > > > Sent: Sunday, October 13, 2013 5:55 PM > > > > > To: rtg-ads@tools.ietf.org > > > > > Cc: rtg-dir@ietf.org; > > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > > mpls@ietf.org > > > > > Subject: [RTG-DIR] RtgDir review: > > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > > 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, and sometimes on special request. > > > > > The purpose of the review is to provide assistance to the > > > > Routing ADs. > > > > > For more information about the Routing Directorate, please > > > > > seehttp://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-mpls-tp-rosetta-stone-12.txt > > > > > Reviewer: Manav Bhatia > > > > > Review Date: October 13th, 2013 > > > > > IETF LC End Date: October 16, 2013 Intended Status: > > > > > Informational > > > > > > > > > > Summary: This document is basically ready for publication, but > > > > > has nits that should be considered prior to publication. > > > > > > > > > > Comments: This document is built on top of terms already defined > > > > > in different RFCs and ITU-T documents. The terms and definitions > > > > > have already been reviewed so there is a trifle little that > > > > > needs to be done there. Overall, the document looks good and > > > > > ready for publication. Some of my comments can be > > > > > > > > > > Nits: > > > > > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > > > > > o) When explaining Control Plane (3.6) should we mention that it > > > > > is possible to operate an MPLS-TP network without using a > > > > Control Plane? > > > > > > > > > > o) In 3.7, it would be useful to mention that an important > > > > property of > > > > > co-routed bidirectional path is that the forward and backward > > > > > directions share fate. Similarly, in 3.1, we should mention > > > > that the > > > > > forward and backward directions don't share fate. > > > > > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be > > > > > rephrased it to something like, "The equipment management > > > > > function > > > > > (EMF) provides the means through which an element management > > > > > system > > > > > (EMS) and other managing entities manage the network > > > > element function > > > > > (NEF)." > > > > > > > > > > o) 3.13 talks about Fault cause without explaining what a > > > > fault cause > > > > > is. It took me some time to understand what was meant by "fault > > > > > cause". Can the authors of the draft rephrase > > > > > 3.13 in their own language to explain what they mean by a > > > > Failure. The > > > > > current definition in the draft has been picked up as-is from > > > > > ITU-T > > > > > G.806 > > > > > > > > > > o) 3.14 talks about "inability of a function to perform a > > > > > required action". Since this RFC-to-be is in the IETF domain, > > > > > can this be rephrased to use a term like router/switch instead > > > > > of a > > > > more esoteric > > > > > "function". This is a general comment and applies to most of the > > > > > definitions that have been copied from the ITU-T documents. > > > > > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > > > > > "OAM packets are subject to the same forwarding treatment > > > > as the data > > > > > traffic, but they are distinct from the data traffic." > > > > > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not > > > > > been expanded in the document. > > > > > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > > > > > o) In 3.28.3, can the following text be added: > > > > > > > > > > An LSP segment comprises one or more continuous hops on the path > > > > > of the LSP. [RFC5654] defines two terms. A "segment" > > > > > is a single hop along the path of an LSP, while a "concatenated > > > > > segment" is more than one hop along the path of an LSP. > > > > > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more > > > > common term > > > > > than Operations Systems (OS)? > > > > > > > > > > Cheers, Manav > > > > > > > > > > This e-mail message is intended for the recipient only and > > > > > contains information which is CONFIDENTIAL and which may be > > > > proprietary to ECI > > > > > Telecom. If you have received this transmission in error, please > > > > > inform us by e-mail, phone or fax, and then delete the original > > > > > and all copies thereof. > > > > > > > > > > > > > > > > > > This e-mail message is intended for the recipient only and > > > > contains information which is CONFIDENTIAL and which may be > > > > proprietary to ECI Telecom. If you have received this transmission > > > > in error, please inform us by e-mail, phone or fax, and then > > > > delete the original and all copies thereof. > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > This e-mail message is intended for the recipient only and contains > > information which is CONFIDENTIAL and which may be proprietary to ECI > > Telecom. If you have received this transmission in error, please > > inform us by e-mail, phone or fax, and then delete the original and all= copies > thereof. > > > > >=20 >=20 >=20 From gregory.mirsky@ericsson.com Sun Oct 13 23:22:49 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630D921E80C0; Sun, 13 Oct 2013 23:22:49 -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 GeQCwNmSsxK1; Sun, 13 Oct 2013 23:22:43 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 059E211E810E; Sun, 13 Oct 2013 23:22:38 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-a0-525b8dad684b Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 37.78.03458.EAD8B525; Mon, 14 Oct 2013 08:22:38 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 02:22:37 -0400 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" , "Alexander Vainshtein" Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BYAAE12wgAAS/oA= Date: Mon, 14 Oct 2013 06:22:36 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6F8E0D@eusaamb103.ericsson.se> References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPoO663uggg9n7xCymbv3AbHHwz1UW izn37rFa3Fq6ktXi+ZyZLBYL1jxld2DzaH22l9Vj07/jjB5Llvxk8vhy+TNbAEsUl01Kak5m WWqRvl0CV8bJTe3MBfOjKl58+8newPjMo4uRg0NCwETi9HntLkZOIFNM4sK99WxdjFwcQgJH GSXuda9hhXCWM0qsvviZCaSKTcBI4sXGHnYQW0SgSmJS90qwImaBT4wSO4+/ZwNJCAs4S5y+ eYARoshFYtaZM0wQtp/EzZZVYM0sAqoS/7bMYgG5glfAV6JxRgHEsonMEvsXHQer4RSIlei7 fBBsDiPQed9PrQGbwywgLnHryXwmiLMFJJbsOc8MYYtKvHz8jxXCVpb4PucRC0S9jsSC3Z/Y IGxtiWULX4PV8woISpyc+YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsYOUqLU8ty040MNzECY+yY BJvjDsYFnywPMUpzsCiJ83556xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdHfKEFO09lx 1kHOIuYylU/OO/v03I69+G913FL944V5d/q7vNe9bOt9lR8Ux7Gx3zj7wvmUrLtLuov4quY9 Srsi+6xWe8KTb58n93yf/ly4yT5oJb9LnOrE9u9WUuZvlF7FnPIRCHrVz7/a3v+cnN7bG0JB SsFxfit0bsxtYxKSVat7ZSSXrsRSnJFoqMVcVJwIANFknQB/AgAA X-Mailman-Approved-At: Mon, 14 Oct 2013 10:12:20 -0700 Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 06:22:49 -0000 Hi Manav, I do feel that "fate sharing" already has certain interpretation in the ind= ustry. Difference in, for example, protection between co-routed and associa= ted bi-directional LSPs doesn't seem not to be described by "fate sharing".= I think of it as in co-routed case LSP protected as a single entity while = in associated case each direction of LSP is protected independently of the = other. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Sunday, October 13, 2013 10:26 PM To: Alexander Vainshtein Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; draft-ietf-mpls-tp-rosetta-st= one.all@tools.ietf.org; mpls@ietf.org Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Sasha, I think the confusion is over what we mean by "fate sharing". To me, if the forward path is torn down for some reason, and that results i= n the backward path being torn down as well, then they inextricably "share = the fate". If the path of the forward LSP changes because of an IGP trigger, then the = backward LSP changes too in case of co-routed bidirectional LSPs. However, = this isn't true in case of Associated bidirectional LSPs. Similarly, an IGP= change (or a network event -- link/node flap, link/node down) will always = result in both directions changing their path in case of co-routed bidirect= ional LSPs. This doesn't happen in case of Associated bidirectional LSPs. I= ts this difference that I wanted the authors to highlight as part of my rev= iew comment.=20 If you think "fate sharing" is not the most appropriate term then you can s= uggest something else as long as you believe its something that ought to be= mentioned. Cheers, Manav=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 > Sent: Monday, October 14, 2013 9:37 AM > To: Bhatia, Manav (Manav) > Cc: rtg-dir@ietf.org;=20 > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org;=20 > mpls@ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 >=20 > Manav, > Lots of thanks for a prompt response. >=20 > I must admit that I've mssed the text in 5960 to which you refer. >=20 > The original definition, to the best of my understanding, is=20 > in Section 1.2.2. of RFC 5654 and says something else: >=20 >=20 > Co-routed Bidirectional path: A path where the forward and backward > directions follow the same route (links and nodes) across the > network. Both directions are setup, monitored and protected as a > single entity. A transport network path is typically co-routed. >=20 > To me this means that if one of the directions of the=20 > co-routed bi-directional path fails to convey traffic, the=20 > monitoring mechanisms will report the entire bi-directional=20 > path as failed. >=20 > To the best of my recollection when I=3DD to become RFC 5960=20 > has been discussed I've asked the authors of RFC 5960 whether=20 > the pairing between two directions of a co-routed=20 > bi-directional MPLS-TP LSP in a transit LSR is limited to OAM=20 > processing, and they (or one of them) have confirmed that=20 > this is indeed so.=20 >=20 > I wonder whether this can be interpreted as "fate-sharing". >=20 > Regards, > Sasha >=20 > ________________________________________ > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > Sent: Monday, October 14, 2013 4:21 AM > To: Alexander Vainshtein > Cc: rtg-dir@ietf.org;=20 > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org;=20 > mpls@ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > Hi Sasha, >=20 > RFC 5960 that describes the MPLS-TP data plane says the following: >=20 > A point-to-point co-routed bidirectional LSP is a=20 > point-to-point associated bidirectional LSP with the=20 > additional constraint that its two unidirectional component=20 > LSPs in each direction follow the same path (in terms of both=20 > nodes and links). An important property of co-routed=20 > bidirectional LSPs is that their unidirectional component=20 > LSPs share fate. >=20 > Am I missing something? >=20 > Cheers, Manav >=20 >=20 > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Sunday, October 13, 2013 9:46 PM > > To: Bhatia, Manav (Manav) > > Cc: rtg-dir@ietf.org; > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > mpls@ietf.org; rtg-ads@tools.ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Manav and all, > > Regarding one of the nits you've identified: > > "it would be useful to mention that an important property=20 > of co-routed=20 > > bidirectional path is that the forward and backward=20 > directions share=20 > > fate." > > > > IMHO and FWIW this is not correct. To the best of my=20 > understanding the=20 > > two directions of an MPLS-TP co-routed bi-directional path share=20 > > lifespan (i.e.,they are set up and torn down in a single=20 > management or=20 > > control plane operation). > > But they do not share fate, as can be seen from the following > > examples: > > > > 1. A unidirectiona fiber cut in one of the links used by a=20 > co-routed=20 > > bi-directional trail will result in traffic failur in the affected=20 > > direction but not necessarily in the reverse one > > > > 2. Consider the case when one of entries the ILM in one of=20 > the transit=20 > > LSRs is corruped. This will result in incorrect failure of a single=20 > > label, but the rest of the labels would be handled correctly. Since=20 > > co-routed bi-directional trails do not require using the=20 > same label in=20 > > both directions of a trail, the fate sharing would be broken. > > (Actually, in such a way it could be easily broken even if the same=20 > > label is used on each segment of the LSP in both > > directions...) > > > > My 2c, > > Sasha > > > > > > > > ________________________________________ > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org]=20 > on behalf of=20 > > Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > Sent: Sunday, October 13, 2013 5:55 PM > > To: rtg-ads@tools.ietf.org > > Cc: rtg-dir@ietf.org; > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org > > Subject: [RTG-DIR] RtgDir review: > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this=20 > > draft. The Routing Directorate seeks to review all routing or=20 > > routing-related drafts as they pass through IETF last call and IESG=20 > > review, and sometimes on special request. > > The purpose of the review is to provide assistance to the=20 > Routing ADs.=20 > > For more information about the Routing Directorate, please=20 > > seehttp://www.ietf.org/iesg/directorate/routing.html > > > > Although these comments are primarily for the use of the=20 > Routing ADs,=20 > > it would be helpful if you could consider them along with any other=20 > > IETF Last Call comments that you receive, and strive to=20 > resolve them=20 > > through discussion or by updating the draft. > > > > Document: draft-ietf-mpls-tp-rosetta-stone-12.txt > > Reviewer: Manav Bhatia > > Review Date: October 13th, 2013 > > IETF LC End Date: October 16, 2013 > > Intended Status: Informational > > > > Summary: This document is basically ready for publication, but has=20 > > nits that should be considered prior to publication. > > > > Comments: This document is built on top of terms already defined in=20 > > different RFCs and ITU-T documents. The terms and definitions have=20 > > already been reviewed so there is a trifle little that needs to be=20 > > done there. Overall, the document looks good and ready for=20 > > publication. Some of my comments can be > > > > Nits: > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > o) When explaining Control Plane (3.6) should we mention that it is=20 > > possible to operate an MPLS-TP network without using a=20 > Control Plane? > > > > o) In 3.7, it would be useful to mention that an important=20 > property of=20 > > co-routed bidirectional path is that the forward and backward=20 > > directions share fate. Similarly, in 3.1, we should mention=20 > that the=20 > > forward and backward directions don't share fate. > > > > o) 3.12 in the current text doesn't look very helpful. Can it be=20 > > rephrased it to something like, "The equipment management function=20 > > (EMF) provides the means through which an element management system=20 > > (EMS) and other managing entities manage the network=20 > element function=20 > > (NEF)." > > > > o) 3.13 talks about Fault cause without explaining what a=20 > fault cause=20 > > is. It took me some time to understand what was meant by "fault=20 > > cause". Can the authors of the draft rephrase > > 3.13 in their own language to explain what they mean by a=20 > Failure. The=20 > > current definition in the draft has been picked up as-is from ITU-T=20 > > G.806 > > > > o) 3.14 talks about "inability of a function to perform a required=20 > > action". Since this RFC-to-be is in the IETF domain, can this be=20 > > rephrased to use a term like router/switch instead of a=20 > more esoteric=20 > > "function". This is a general comment and applies to most of the=20 > > definitions that have been copied from the ITU-T documents. > > > > o) The last paragraph of 3.17 says the following: > > > > "OAM packets are subject to the same forwarding treatment=20 > as the data=20 > > traffic, but they are distinct from the data traffic." > > > > In what sense are the OAM packets distinct from the data traffic? > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been=20 > > expanded in the document. > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > o) In 3.28.3, can the following text be added: > > > > An LSP segment comprises one or more continuous hops on the path of=20 > > the LSP. [RFC5654] defines two terms. A "segment" > > is a single hop along the path of an LSP, while a "concatenated=20 > > segment" is more than one hop along the path of an LSP. > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more=20 > common term=20 > > than Operations Systems (OS)? > > > > Cheers, Manav > > > > This e-mail message is intended for the recipient only and contains=20 > > information which is CONFIDENTIAL and which may be=20 > proprietary to ECI=20 > > Telecom. If you have received this transmission in error, please=20 > > inform us by e-mail, phone or fax, and then delete the original and=20 > > all copies thereof. > > > > >=20 > This e-mail message is intended for the recipient only and=20 > contains information which is CONFIDENTIAL and which may be=20 > proprietary to ECI Telecom. If you have received this=20 > transmission in error, please inform us by e-mail, phone or=20 > fax, and then delete the original and all copies thereof. >=20 >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Mon Oct 14 09:01:11 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6884311E8136; Mon, 14 Oct 2013 09:01:10 -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 YTXJDCecKp3p; Mon, 14 Oct 2013 09:01:03 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7B53821F8F3C; Mon, 14 Oct 2013 09:00:44 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-0e-525c15293c15 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 51.28.09414.9251C525; Mon, 14 Oct 2013 18:00:42 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 12:00:40 -0400 From: Gregory Mirsky To: Alexander Vainshtein , John E Drake Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gAFpNkCAAA4F4IAACoJwgAAEJPCAAAh7oA== Date: Mon, 14 Oct 2013 16:00:39 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6F8FD9@eusaamb103.ericsson.se> References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5ca0484c5ca745bbabd93bb799afaca8@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: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXRPgq6WaEyQwbpXQhZTt35gtjj45yqL xZy7zhZz7t1jtbi1dCWrxfM5M1ksFqx5yu7A7tH6bC+rx6Z/xxk9liz5yeRxvekqu8eXy5/Z AlijuGxSUnMyy1KL9O0SuDJubA4uuB5dcepQJ3MD4zn3LkZODgkBE4kJt88xQdhiEhfurWfr YuTiEBI4yihxed03dghnOaPEhSOtjCBVbAJGEi829rCD2CICCRKH1kwDK2IWWM8ksfjZdFaQ hLCAs8TpmwcYIYpcJGadOcMEYYdJPJmziLmLkYODRUBVYuN3Q5Awr4CvxP/3/YwQy04yS2z6 8RWsnlMgUGL53VVsIDYj0HnfT60BizMLiEvcejIf6mwBiSV7zjND2KISLx//Y4WwlSW+z3nE AlGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYwcpcWpZbnp RgabGIFRd0yCTXcH456XlocYpTlYlMR5v7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA uPZWyEyXy7WrSu/2XQri7bGPmjfh9S3tPI5bonwbrm3TN5n7+dMlb7977skvdkq1fb2kkVQW d1xmu4iow5aLCadMSu3EPkoK33jS7pXM+MGo/sPXhohNJfHblO4uXlJvGrXofebCY1F7IvO+ 3JvFGq1z02LZYqOzq8+HvUrwmvvnxC3bTSZzPZVYijMSDbWYi4oTASPJtVCIAgAA X-Mailman-Approved-At: Mon, 14 Oct 2013 10:12:23 -0700 Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 16:01:11 -0000 Hi Sasha, John, et. al, isn't there bit of contradiction when first stating that co-routed bidirect= ional and associated bidirectional LSPs are indistinguishable in data plane= to note that there are difference in their OAM? OAM, in large part, is in = data plane and how co-routed and associated bidirectional LSP being referen= ces in OAM is different in the data plane, not only in control and/or manag= ement planes. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Monday, October 14, 2013 8:27 AM To: John E Drake Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; Bhatia, Manav (Manav); draft-= ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt John, Lots of thanks for a prompt response. I fully agree with you that there is no difference in the data plane betwee= n two directions a co-routed bi-directional LSP and two directions of an as= sociated bi-directional LSP. The difference is mainly in management/control= plane, in the OAM etc.=20 This is exactly why I find the term "fate-sharing" inappropriate when it is= applied to forward and backward directions of a co-routed bi-directional L= SP because to me fate-staring refers to first of all to the data plane beha= vior. Regards, Sasha > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Monday, October 14, 2013 6:10 PM > To: Alexander Vainshtein > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org;=20 > draft-ietf-mpls-tp- rosetta-stone.all@tools.ietf.org;=20 > rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > Sasha, >=20 > My point was simply that in the data plane there isn't any difference=20 > between the two. >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On=20 > > Behalf > Of > > Alexander Vainshtein > > Sent: Monday, October 14, 2013 7:34 AM > > To: John E Drake > > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org;=20 > > draft-ietf-mpls- tp-rosetta-stone.all@tools.ietf.org;=20 > > rtg-ads@tools.ietf.org > > Subject: Re: [RTG-DIR] RtgDir review:=20 > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > John, > > Not sure I fully understood your message. > > > > My comments have been about applicability of the term "fate-sharing"=20 > > to the two directions of a co-routed bi-directional LSP. > > It is of course true that each direction of an associated=20 > > bi-directional LSP can fail independently of the other one, but,=20 > > presumably, nobody has expected anything else in this case. > > > > Regards, > > Sasha > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Monday, October 14, 2013 4:42 PM > > > To: Alexander Vainshtein; Bhatia, Manav (Manav) > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org;=20 > > > mpls@ietf.org > > > Subject: RE: RtgDir review:=20 > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Sasha, > > > > > > I think your comments apply equally to bidirectional LSPs. > > > > > > Yours Irrespectively, > > > > > > John > > > > > > > -----Original Message----- > > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org]=20 > > > > On Behalf > > > Of > > > > Alexander Vainshtein > > > > Sent: Sunday, October 13, 2013 9:16 AM > > > > To: Bhatia, Manav (Manav) > > > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org;=20 > > > > mpls@ietf.org > > > > Subject: Re: [RTG-DIR] RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Manav and all, > > > > Regarding one of the nits you've identified: > > > > "it would be useful to mention that an important property of=20 > > > > co-routed bidirectional path is that the forward and backward=20 > > > > directions > > share fate." > > > > > > > > IMHO and FWIW this is not correct. To the best of my=20 > > > > understanding the two directions of an MPLS-TP co-routed=20 > > > > bi-directional path share lifespan (i.e.,they are set up and=20 > > > > torn down in a single management or > > control plane operation). > > > > But they do not share fate, as can be seen from the following examp= les: > > > > > > > > 1. A unidirectiona fiber cut in one of the links used by a=20 > > > > co-routed > > > > bi- > > > directional > > > > trail will result in traffic failur in the affected direction=20 > > > > but not necessarily in > > > the > > > > reverse one > > > > > > > > 2. Consider the case when one of entries the ILM in one of the=20 > > > > transit LSRs is corruped. This will result in incorrect failure=20 > > > > of a single label, but the rest of > > > the > > > > labels would be handled correctly. Since co-routed=20 > > > > bi-directional trails do not require using the same label in=20 > > > > both directions of a trail, the fate sharing > > > would > > > > be broken. > > > > (Actually, in such a way it could be easily broken even if the=20 > > > > same label is > > > used > > > > on each segment of the LSP in both directions...) > > > > > > > > My 2c, > > > > Sasha > > > > > > > > > > > > > > > > ________________________________________ > > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on=20 > > > > behalf of Bhatia, Manav (Manav)=20 > > > > [manav.bhatia@alcatel-lucent.com] > > > > Sent: Sunday, October 13, 2013 5:55 PM > > > > To: rtg-ads@tools.ietf.org > > > > Cc: rtg-dir@ietf.org; > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > mpls@ietf.org > > > > Subject: [RTG-DIR] RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Hello, > > > > > > > > I have been selected as the Routing Directorate reviewer for=20 > > > > this draft. The Routing Directorate seeks to review all routing=20 > > > > or routing-related drafts as they pass through IETF last call=20 > > > > and IESG review, and sometimes on special request. The purpose=20 > > > > of the review is to provide assistance to the Routing ADs. For=20 > > > > more information about the Routing Directorate, please=20 > > > > seehttp://www.ietf.org/iesg/directorate/routing.html > > > > > > > > Although these comments are primarily for the use of the Routing=20 > > > > ADs, it would be helpful if you could consider them along with=20 > > > > any other IETF Last > > > Call > > > > comments that you receive, and strive to resolve them through=20 > > > > discussion or by updating the draft. > > > > > > > > Document: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Reviewer: Manav Bhatia > > > > Review Date: October 13th, 2013 > > > > IETF LC End Date: October 16, 2013 Intended Status:=20 > > > > Informational > > > > > > > > Summary: This document is basically ready for publication, but=20 > > > > has nits that should be considered prior to publication. > > > > > > > > Comments: This document is built on top of terms already defined=20 > > > > in different RFCs and ITU-T documents. The terms and definitions=20 > > > > have already been reviewed so there is a trifle little that=20 > > > > needs to be done there. Overall, the document looks good and=20 > > > > ready for publication. Some of my comments can be > > > > > > > > Nits: > > > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > > > o) When explaining Control Plane (3.6) should we mention that it=20 > > > > is possible > > > to > > > > operate an MPLS-TP network without using a Control Plane? > > > > > > > > o) In 3.7, it would be useful to mention that an important=20 > > > > property of co- > > > routed > > > > bidirectional path is that the forward and backward directions shar= e fate. > > > > Similarly, in 3.1, we should mention that the forward and=20 > > > > backward directions don't share fate. > > > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be=20 > > > > rephrased it to something like, "The equipment management=20 > > > > function > > > > (EMF) provides the means through which an element management=20 > > > > system > > > > (EMS) and other managing entities manage the network element=20 > > > > function > > (NEF)." > > > > > > > > o) 3.13 talks about Fault cause without explaining what a fault=20 > > > > cause is. It > > > took > > > > me some time to understand what was meant by "fault cause". Can=20 > > > > the authors of the draft rephrase 3.13 in their own language to=20 > > > > explain what they mean by a Failure. The current definition in=20 > > > > the draft has been picked up as-is from ITU-T G.806 > > > > > > > > o) 3.14 talks about "inability of a function to perform a=20 > > > > required action". Since this RFC-to-be is in the IETF domain,=20 > > > > can this be rephrased to use a term like router/switch instead=20 > > > > of a more esoteric "function". This is a general > > > comment > > > > and applies to most of the definitions that have been copied=20 > > > > from the ITU-T documents. > > > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > > > "OAM packets are subject to the same forwarding treatment as the=20 > > > > data traffic, but they are distinct from the data traffic." > > > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not=20 > > > > been expanded in the document. > > > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > > > o) In 3.28.3, can the following text be added: > > > > > > > > An LSP segment comprises one or more continuous hops on the path=20 > > > > of the LSP. [RFC5654] defines two terms. A "segment" is a=20 > > > > single hop along the > > > path > > > > of an LSP, while a "concatenated segment" is more than one hop=20 > > > > along the path of an LSP. > > > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more common=20 > > > > term than Operations Systems (OS)? > > > > > > > > Cheers, Manav > > > > > > > > This e-mail message is intended for the recipient only and=20 > > > > contains > > > information > > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. > > > > If you have received this transmission in error, please inform=20 > > > > us by e-mail, phone or fax, and then delete the original and all co= pies thereof. > > > > > > > > > > > > > > > > > > > This e-mail message is intended for the recipient only and contains > information > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom.=20 > > If you have received this transmission in error, please inform us by=20 > > e-mail, phone or fax, and then delete the original and all copies there= of. > > > > >=20 This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Mon Oct 14 10:02:08 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90A621E8171; Mon, 14 Oct 2013 10:02:08 -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 qJnGxtuU1pY7; Mon, 14 Oct 2013 10:02:03 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B24D321E80E1; Mon, 14 Oct 2013 10:01:59 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-5c-525c2386f450 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 8E.7B.09414.6832C525; Mon, 14 Oct 2013 19:01:59 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 13:01:58 -0400 From: Gregory Mirsky To: John E Drake , Alexander Vainshtein Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BYAAE12wgAAS/oCAAB9uEIAAcVUAgAAhKkA= Date: Mon, 14 Oct 2013 17:01:58 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6F9071@eusaamb103.ericsson.se> References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> , <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4DE827@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B6F8E0D@eusaamb103.ericsson.se> <2bf422c8e5674cbdba8faa198d57e0fa@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <2bf422c8e5674cbdba8faa198d57e0fa@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXRPuG67ckyQwf6lXBZTt35gtjj45yqL xZy7zhZz7t1jtbi1dCWrxfM5M1ksFqx5yu7A7tH6bC+rx6Z/xxk9liz5yeRxvekqu8eXy5/Z AlijuGxSUnMyy1KL9O0SuDLWrDvAXHCrsmJlzyLmBsbD8V2MnBwSAiYSV+78ZIOwxSQu3FsP ZgsJHGWUmHVQrIuRC8hezihxtf8UWIJNwEjixcYedhBbRCBB4vKUA2A2s8BaJonnd/NAbGEB Z4nTNw8wQtS4SMw6c4YJwk6SWPfuHjOIzSKgKvH+UwdYnFfAV6Ln8i5WiGUvWCQ+73rGApLg FAiTuLS1D2wBI9B130+tYYJYJi5x68l8JoirBSSW7DnPDGGLSrx8/I8VwlaW+D7nEQtEvY7E gt2f2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywkLQsYWVYxcpQWp5blphsZbGIE Rt0xCTbdHYx7XloeYpTmYFES5/3y1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6Oa29fZ ol78f8Wa2aYVBmhsZqk44qDjFGP2Uf/ygug9N9PZHfjPFkkemmg1Zc7BSPWW3UcZtXRV5txm v7Wr0jvbbf9PSxPL5rpAo/QZHkqLXtfPFp9jtMkk3rijbaum8GNP/flNDfPqjngy/ttcsjPI nvFpLc/nY7t8+qafObUwJ6WMbWJzrRJLcUaioRZzUXEiAFssFKOIAgAA X-Mailman-Approved-At: Mon, 14 Oct 2013 10:12:23 -0700 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 17:02:08 -0000 Hi John, I was thinking that two unidirectional LSPs that happen to be co-routed can= form an associated bi-directional LSP. I believe that Eric Gray explained = that that was not interpretation and intention of RFC 5960 to see co-routed= bi-directional p2p LSP not as single unified object but as two federated o= bjects. I recall that intention was to have case of accidental co-routednes= s in associated p2p LSP. In other words, associated bi-directional was not = meant to happen to be co-routed. Well, that is my recollection of talking w= ith Eric and hope it's accurate one. Regards, Greg -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Monday, October 14, 2013 7:55 AM To: Alexander Vainshtein; Gregory Mirsky Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org; draft-ietf-mpls= -tp-rosetta-stone.all@tools.ietf.org; rtg-ads@tools.ietf.org Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Yours Irrespectively, John > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On=20 > Behalf Of Alexander Vainshtein > Sent: Monday, October 14, 2013 1:08 AM > To: Gregory Mirsky > Cc: rtg-dir@ietf.org; Bhatia, Manav (Manav); mpls@ietf.org;=20 > draft-ietf-mpls- tp-rosetta-stone.all@tools.ietf.org;=20 > rtg-ads@tools.ietf.org > Subject: Re: [RTG-DIR] RtgDir review:=20 > draft-ietf-mpls-tp-rosetta-stone-12.txt >=20 > Greg, > Lots of thanks for an important comment. >=20 > Regarding your example: my personal interpretation of 5654 is like follow= ing: > - Co-routed bidirectional LSPs MAY be protected using bi-directional=20 > protection schemes but MUST NOT be protected using unidirectional ones [JD] I don't think that is true for a pair of co-routed associated unidire= ctional LSPs.=20 > - Associated bidirectional LSPs MAY be protected using both=20 > unidirectional and bi-directional protection schemes [JD] Conversely, if a pair of associated unidirectional LSPs are diversely= routed, it may be difficult to apply bidirectional protection to them. =20 >=20 > Does this match your understanding? >=20 > Regards, > Sasha >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Monday, October 14, 2013 9:23 AM > > To: Bhatia, Manav (Manav); Alexander Vainshtein > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Hi Manav, > > I do feel that "fate sharing" already has certain interpretation in=20 > > the > industry. > > Difference in, for example, protection between co-routed and=20 > > associated bi- directional LSPs doesn't seem not to be described by=20 > > "fate sharing". I think of it as in co-routed case LSP protected as=20 > > a single entity while in associated case each direction of LSP is=20 > > protected > independently of the other. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > > Of Bhatia, Manav (Manav) > > Sent: Sunday, October 13, 2013 10:26 PM > > To: Alexander Vainshtein > > Cc: rtg-dir@ietf.org; rtg-ads@tools.ietf.org; > > draft-ietf-mpls-tp-rosetta- stone.all@tools.ietf.org; mpls@ietf.org > > Subject: Re: [mpls] RtgDir review: > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Sasha, > > > > I think the confusion is over what we mean by "fate sharing". > > > > To me, if the forward path is torn down for some reason, and that=20 > > results in the backward path being torn down as well, then they=20 > > inextricably > "share the fate". > > > > If the path of the forward LSP changes because of an IGP trigger,=20 > > then the backward LSP changes too in case of co-routed bidirectional LS= Ps. > > However, this isn't true in case of Associated bidirectional LSPs. > > Similarly, an IGP change (or a network event -- link/node flap,=20 > > link/node down) will always result in both directions changing their=20 > > path in case of co-routed bidirectional LSPs. This doesn't happen in=20 > > case of Associated bidirectional LSPs. Its this difference that I=20 > > wanted the > authors to highlight as part of my review comment. > > > > If you think "fate sharing" is not the most appropriate term then=20 > > you can suggest something else as long as you believe its something=20 > > that ought to be mentioned. > > > > Cheers, Manav > > > > > -----Original Message----- > > > From: Alexander Vainshtein=20 > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > Sent: Monday, October 14, 2013 9:37 AM > > > To: Bhatia, Manav (Manav) > > > Cc: rtg-dir@ietf.org; > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > Subject: RE: RtgDir review:=20 > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > > Manav, > > > Lots of thanks for a prompt response. > > > > > > I must admit that I've mssed the text in 5960 to which you refer. > > > > > > The original definition, to the best of my understanding, is in=20 > > > Section 1.2.2. of RFC 5654 and says something else: > > > > > > > > > Co-routed Bidirectional path: A path where the forward and backwar= d > > > directions follow the same route (links and nodes) across the > > > network. Both directions are setup, monitored and protected as a > > > single entity. A transport network path is typically co-routed. > > > > > > To me this means that if one of the directions of the co-routed=20 > > > bi-directional path fails to convey traffic, the monitoring=20 > > > mechanisms will report the entire bi-directional path as failed. > > > > > > To the best of my recollection when I=3DD to become RFC 5960 has=20 > > > been discussed I've asked the authors of RFC 5960 whether the=20 > > > pairing between two directions of a co-routed bi-directional=20 > > > MPLS-TP LSP in a transit LSR is limited to OAM processing, and=20 > > > they (or one of > > > them) have confirmed that this is indeed so. > > > > > > I wonder whether this can be interpreted as "fate-sharing". > > > > > > Regards, > > > Sasha > > > > > > ________________________________________ > > > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > Sent: Monday, October 14, 2013 4:21 AM > > > To: Alexander Vainshtein > > > Cc: rtg-dir@ietf.org; > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > Subject: RE: RtgDir review:=20 > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > Hi Sasha, > > > > > > RFC 5960 that describes the MPLS-TP data plane says the following: > > > > > > A point-to-point co-routed bidirectional LSP is a point-to-point=20 > > > associated bidirectional LSP with the additional constraint that=20 > > > its two unidirectional component LSPs in each direction follow the=20 > > > same path (in terms of both nodes and links). An important=20 > > > property of co-routed bidirectional LSPs is that their=20 > > > unidirectional component LSPs share fate. > > > > > > Am I missing something? > > > > > > Cheers, Manav > > > > > > > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Sunday, October 13, 2013 9:46 PM > > > > To: Bhatia, Manav (Manav) > > > > Cc: rtg-dir@ietf.org; > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; > > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > > Subject: RE: RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Manav and all, > > > > Regarding one of the nits you've identified: > > > > "it would be useful to mention that an important property > > > of co-routed > > > > bidirectional path is that the forward and backward > > > directions share > > > > fate." > > > > > > > > IMHO and FWIW this is not correct. To the best of my > > > understanding the > > > > two directions of an MPLS-TP co-routed bi-directional path share=20 > > > > lifespan (i.e.,they are set up and torn down in a single > > > management or > > > > control plane operation). > > > > But they do not share fate, as can be seen from the following > > > > examples: > > > > > > > > 1. A unidirectiona fiber cut in one of the links used by a > > > co-routed > > > > bi-directional trail will result in traffic failur in the=20 > > > > affected direction but not necessarily in the reverse one > > > > > > > > 2. Consider the case when one of entries the ILM in one of > > > the transit > > > > LSRs is corruped. This will result in incorrect failure of a=20 > > > > single label, but the rest of the labels would be handled=20 > > > > correctly. Since co-routed bi-directional trails do not require=20 > > > > using the > > > same label in > > > > both directions of a trail, the fate sharing would be broken. > > > > (Actually, in such a way it could be easily broken even if the=20 > > > > same label is used on each segment of the LSP in both > > > > directions...) > > > > > > > > My 2c, > > > > Sasha > > > > > > > > > > > > > > > > ________________________________________ > > > > From: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] > > > on behalf of > > > > Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > > > > Sent: Sunday, October 13, 2013 5:55 PM > > > > To: rtg-ads@tools.ietf.org > > > > Cc: rtg-dir@ietf.org; > > > > draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org;=20 > > > > mpls@ietf.org > > > > Subject: [RTG-DIR] RtgDir review: > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > > > > > Hello, > > > > > > > > I have been selected as the Routing Directorate reviewer for=20 > > > > this draft. The Routing Directorate seeks to review all routing=20 > > > > or routing-related drafts as they pass through IETF last call=20 > > > > and IESG review, and sometimes on special request. > > > > The purpose of the review is to provide assistance to the > > > Routing ADs. > > > > For more information about the Routing Directorate, please=20 > > > > seehttp://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=20 > > > > other IETF Last Call comments that you receive, and strive to > > > resolve them > > > > through discussion or by updating the draft. > > > > > > > > Document: draft-ietf-mpls-tp-rosetta-stone-12.txt > > > > Reviewer: Manav Bhatia > > > > Review Date: October 13th, 2013 > > > > IETF LC End Date: October 16, 2013 Intended Status:=20 > > > > Informational > > > > > > > > Summary: This document is basically ready for publication, but=20 > > > > has nits that should be considered prior to publication. > > > > > > > > Comments: This document is built on top of terms already defined=20 > > > > in different RFCs and ITU-T documents. The terms and definitions=20 > > > > have already been reviewed so there is a trifle little that=20 > > > > needs to be done there. Overall, the document looks good and=20 > > > > ready for publication. Some of my comments can be > > > > > > > > Nits: > > > > > > > > o) Please expand PW in either the Abstract or Sec 3.5 > > > > > > > > o) When explaining Control Plane (3.6) should we mention that it=20 > > > > is possible to operate an MPLS-TP network without using a > > > Control Plane? > > > > > > > > o) In 3.7, it would be useful to mention that an important > > > property of > > > > co-routed bidirectional path is that the forward and backward=20 > > > > directions share fate. Similarly, in 3.1, we should mention > > > that the > > > > forward and backward directions don't share fate. > > > > > > > > o) 3.12 in the current text doesn't look very helpful. Can it be=20 > > > > rephrased it to something like, "The equipment management=20 > > > > function > > > > (EMF) provides the means through which an element management=20 > > > > system > > > > (EMS) and other managing entities manage the network > > > element function > > > > (NEF)." > > > > > > > > o) 3.13 talks about Fault cause without explaining what a > > > fault cause > > > > is. It took me some time to understand what was meant by "fault=20 > > > > cause". Can the authors of the draft rephrase > > > > 3.13 in their own language to explain what they mean by a > > > Failure. The > > > > current definition in the draft has been picked up as-is from=20 > > > > ITU-T > > > > G.806 > > > > > > > > o) 3.14 talks about "inability of a function to perform a=20 > > > > required action". Since this RFC-to-be is in the IETF domain,=20 > > > > can this be rephrased to use a term like router/switch instead=20 > > > > of a > > > more esoteric > > > > "function". This is a general comment and applies to most of the=20 > > > > definitions that have been copied from the ITU-T documents. > > > > > > > > o) The last paragraph of 3.17 says the following: > > > > > > > > "OAM packets are subject to the same forwarding treatment > > > as the data > > > > traffic, but they are distinct from the data traffic." > > > > > > > > In what sense are the OAM packets distinct from the data traffic? > > > > > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not=20 > > > > been expanded in the document. > > > > > > > > o) Sec 3.19 uses TCM without expanding it first. > > > > > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection > > > > > > > > o) In 3.28.3, can the following text be added: > > > > > > > > An LSP segment comprises one or more continuous hops on the path=20 > > > > of the LSP. [RFC5654] defines two terms. A "segment" > > > > is a single hop along the path of an LSP, while a "concatenated=20 > > > > segment" is more than one hop along the path of an LSP. > > > > > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more > > > common term > > > > than Operations Systems (OS)? > > > > > > > > Cheers, Manav > > > > > > > > This e-mail message is intended for the recipient only and=20 > > > > contains information which is CONFIDENTIAL and which may be > > > proprietary to ECI > > > > Telecom. If you have received this transmission in error, please=20 > > > > inform us by e-mail, phone or fax, and then delete the original=20 > > > > and all copies thereof. > > > > > > > > > > > > > > This e-mail message is intended for the recipient only and=20 > > > contains information which is CONFIDENTIAL and which may be=20 > > > proprietary to ECI Telecom. If you have received this transmission=20 > > > in error, please inform us by e-mail, phone or fax, and then=20 > > > delete the original and all copies thereof. > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > This e-mail message is intended for the recipient only and contains=20 > information which is CONFIDENTIAL and which may be proprietary to ECI=20 > Telecom. If you have received this transmission in error, please=20 > inform us by e-mail, phone or fax, and then delete the original and all c= opies thereof. >=20 >=20 From daniele.ceccarelli@ericsson.com Tue Oct 15 01:21:48 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FF021E809A; Tue, 15 Oct 2013 01:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=1.782, BAYES_00=-2.599, GB_I_LETTER=-2, 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 PzjF6mYl3rDQ; Tue, 15 Oct 2013 01:21:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0E011E8176; Tue, 15 Oct 2013 01:21:24 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-c4-525cfb03cd10 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 77.0D.03802.30BFC525; Tue, 15 Oct 2013 10:21:23 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 10:21:23 +0200 From: Daniele Ceccarelli To: Acee Lindem , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Thread-Topic: RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Thread-Index: AQHOxJCn0+iFqto7ekGiQXMkyXw9jZn0UizA Date: Tue, 15 Oct 2013 08:21:22 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48163DDB@ESESSMB301.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE470307FE6D@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470307FE6D@eusaamb101.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48163DDBESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvrS7z75ggg9Y7hhZP5txgsfjb8JrF 4vmcmSwWC9Y8ZXdg8Viy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4MlqXrmMtWLWKrWLxObMG xrnnWLsYOTkkBEwktm6+yQhhi0lcuLeerYuRi0NI4DCjxO22uSwQzhJGiafP+5m7GDk42ASs JJ4c8gGJiwhMZ5TYOfs0O0g3s0CZxJSdvWANwgJdQA1Xj7NBVHUzSmy+vBesW0TASOLzUmEQ k0VAVWJVUxmIySvgLTF5nh7IGCEBX4kZR+cygoQ5BfwkHtysBwkzCshKTNi9iBFik7jErSfz mSBuFpBYsuc8M4QtKvHy8T9WkFYJAUWJ5f1yEOX5Ei8XLmUDsXkFBCVOznzCMoFRdBaSSbOQ lM1CUgYR15O4MXUKG4StLbFs4WtmCFtXYsa/QyzI4gsY2VcxsucmZuaklxttYgRG2cEtv1V3 MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjAn9awvCN/59N/dC 2gfbxfe/HVa5f+vBqnwNH4ETOUslnA3MNZ6e1zvs5fK40ctlmn57+q7j/DUt5/q8UtIKuIUY DSdrGAXr7p2mI7qP5YXfPQOFZM1lst1fdbn2hvRartGu9dp910foeYVd3D93/47TT79u6Ui/ My//Sq9bpbaywlUfppw4JZbijERDLeai4kQAZlCrLIACAAA= Cc: "rtg-dir@ietf.org" , CCAMP , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:21:54 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48163DDBESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Acee, Thanks for the careful review and please find comments/replies in line. BR Daniele (&co-authors) From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: mercoled=EC 9 ottobre 2013 03:41 To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org Cc: rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.or= g Subject: RtgDir Review: "Traffic Engineering Extensions to OSPF for General= ized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please seehttp= ://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ccamp-ospf-g709v3-09.txt Reviewer: Acee Lindem Review Date: October 15th, 2013 IETF LC End Date: October 16, 2013 Intended Status: Proposed Standard Summary: The document is missing some key sections and requires some clarif= ication prior to publication. Comments: Major Issues: The document lacks several critical pieces of information. 1. There is no discussion of OSPF scaling or flooding freq= uency. Even if it not expected that G709 GMPLS signaling will not present any problems, this n= eeds to be stated and justified. Refer to section 8 in RFC 6827 for an example of such a discus= sion. [[Authors]] How about adding a section saying: OSPFv2 scalability considerations and requirements are in line with section= 8 of [RFC6827]. In addition please note that OTN extensions in this docume= nt have been designed taking into consideration optimization criteria ident= ified in [OTN-INFO] 2. The document includes lots of normative text indicating= precisely how sub-TLVs MUST be formatted. However, there is no indication of what th= e action to be taken if the TLVs do not follow the strict conventions. [[Authors]] Good comment. Looking at previous OSPF and OSPF-TE drafts we di= dn't find any text on handling of bad TLV formatting. Any suggestion on how= to deal with that is more than welcome. 3. The document jumps down into details of G.709 technolog= y without adequate explanation (particularly in the examples). Either t= hese details need to be removed or a statement of prerequisite knowledge is required. [[Authors]] The reader is supposed to have read [OTN-FWK] and [OTN-INFO]. W= e can add a sentence at the end of the abstract or intro. Minor Issues: The document had a large number of editorial errors. 1. The bit numbering on all the figures was off by 1 colum= n. If you look at RFC 4203, this will be obvious. [[Author]] Correct. Fixed. 2. The table on page 7 is incomprehensible with the given = columns and headings. Spaces rather than commas in numbers are annoying. [[Author]] Spaces substituted with commas. As per comment above having read= [OTN-FWK] and [OTN-INFO] is a prerequisite. 3. The distinction between TLVs and sub-TLVs is not consis= tent throughout the document. Again, refer to RFC 6827 for an example of consistent= referral. [[Authors]] Good catch. We're defining only sub-tlvs. Fixed. 4. Figures 8 and 9 have the T and S fields offset from the= bit numbering. Also, it took some time to realize that T1 meant a value of 1. [[Authors]] T and S were left intentionally to make the reading easier but = maybe it's not the case. Only 0 and 1 are there now. 5. Figures 11-15 are very inconsistent in that these are examples yet the v= alues for T, S, and sometime TSG are not specified. Rather, the example in= cludes the letters. [[Authors]] The focus of those examples is not T,S and TSG but e.g. ODUflex= advertisement, single stage muxing etc. For each example there is a discla= imer saying: "T, S and TS granularity fields are not relevant to this examp= le". 6. Security section - RFC 2154 is an experimental RFC that= has heretofore never been commercially implemented or deployed. It is time to q= uit referencing it in draft "Security Considerations". [[Authors]] How about the following? OLD [RFC3630] suggests mechanisms such = as [RFC2154] to protect the transmission of this information... NEW [RFC3630] suggests mechanisms to pr= otect the transmission of this information... Nits: 1. The proper punctuation is "i.e., " and "e.g. ,". [[Authors]] OK Also, sentences should not start with either. See http://www.rfc-editor.org/rfc-style-guide/rfc-sty= le 2. Page 7, "Switching Capability-Specific Information (SCSI)? [[Authors]] OK 3. Suggest formatting the document so that the figures are= on separate pages rather than split across pages. [[Authors]] I don't know how to do that with the .xml file. Maybe this is a= comment we can leave for the RFC editor? 3. Replace all occurrences of "non " with "non-" and do not end lines= with "non ". [[Authors]] OK 4. I thought the examples included many run-on sentences t= hat were hard to parse and lacked needed punctuation. I tried to edit but I'm not even = sure if I retained the same meaning. You can get a flavor for what I mean by the diffs below. [[Authors]] OK to all. All modifications you suggest have been implemented. Thanks, Acee 132,133c132,133 < Routing information for Optical Channel Layer (OCh) (i.e. wavelength) < is out of the scope of this document. Please refer to [RFC6163] and --- > Routing information for Optical Channel Layer (OCh) (i.e., wavelength) > is beyond the scope of this document. Please refer to [RFC6163] and 157c157 < As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so --- > As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended 159c159 < related to each different ODUj and ODUk/OTUk (Optical Transport Unit) --- > of each different ODUj and ODUk/OTUk (Optical Transport Unit) 176c176 < In the following we will use ODUj to indicate a service type that is --- > In the following, we will use ODUj to indicate a service type that is 179c179 < the OTUk. Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and --- > the OTUk. Moreover, ODUj(S) and ODUk(S) are used to indicate ODUj and 184c184 < multiplexing levels. In the following the term "multiplexing tree" --- > multiplexing levels. In the following, the term "multiplexing tree" 191c191 < If for example a multiplexing hierarchy like the following one is --- > For example, If a multiplexing hierarchy like the following one is 251c251 < one hop case multiple hop TE-links advertise ODU switching capacity. --- > one hop case, multiple hop TE-links advertise ODU switching capacity. 296,297c296,297 < Both for fixed and flexible ODUs the same switching type and encoding < values MUST be used. When Switching Capability and Encoding fields --- > The same switching type and encoding values must be used for both fixe= d > and flexible ODUs. When Switching Capability and Encoding fields 303,304c303,304 < The MAX LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <= =3D < MAX LSP Bandwidth <=3D ODUk/OTUk and intermediate values are those on --- > The MAX LSP Bandwidth field is used according to [RFC4203]: i.e., 0 <= =3D > MAX LSP Bandwidth <=3D ODUk/OTUk, and intermediate values are those on 306,307c306,307 < E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP < Bandwidth for some priorities, ODU3 for others, ODU2 for some others --- > For example, in the OTU4 link it could be possible to have ODU4 as MAX= LSP > Bandwidth for some priorities, ODU3 for others, ODU2 for some others, 397,398c397,398 < Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non < resizable. Each MUST always be advertised in separate Type 2 TLVs as --- > Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) > non-resizable. Each MUST always be advertised in separate Type 2 TLVs= as 400c400 < both GFP-F resizable and non resizable (i.e. 21 and 22) are --- > both GFP-F resizable and non-resizable (i.e. 21 and 22) are 535c535 < (i.e. a non OTN client). --- > (i.e., a non-OTN client). 540c540 < - Priority (8 bits): a bitmap used to indicate which priorities --- > - Priority (8 bits): A bitmap used to indicate which priorities 542,543c542,543 < leftmost bit representing priority level 0 (i.e. the highest) and < the rightmost bit representing priority level 7 (i.e. the lowest). --- > leftmost bit representing priority level 0 (i.e., the highest) and > the rightmost bit representing priority level 7 (i.e., the lowest). 666c666 < Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD @T0 --- > Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD at T0 676,678c676,678 < At time T1 an ODU3 at priority 2 is set-up, so for priority 0 the MAX < LSP Bandwidth is still equal to the ODU4 bandwidth, while for < priorities from 2 to 7 (excluding the non supported ones) the MAX LSP --- > At time T1, an ODU3 at priority 2 is set-up, so for priority 0 the > MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for > priorities from 2 to 7 (excluding the non-supported ones) the MAX LSP 680c680 < next supported ODUj in the hierarchy is ODU3.The advertisement is --- > next supported ODUj in the hierarchy is ODU3. The advertisement is 710c710 < Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD @T1 --- > Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD at T1 712,714c712,714 < At time T2 an ODU2 at priority 4 is set-up. The first ODU3 is no < longer available since T1 as it was kept by the ODU3 LSP, while the < second is no more available and just 3 ODU2 are left in it. ODU2 is --- > At time T2, an ODU2 at priority 4 is set-up. The first ODU3 is no > longer available since T1, as it was kept by the ODU3 LSP, while the > second is no more available and just 3 ODU2s are left in it. ODU2 is 758c758 < Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD @T2 --- > Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD at T2 762c762 < In this example an interface with Tributary Slot Type 1.25Gbps and --- > In this example, an interface with Tributary Slot Type 1.25Gbps and 766c766 < switched or terminated, the ODU2 can only be terminated and the ODU1 --- > switched or terminated, the ODU2 can only be terminated, and the ODU1 768c768 < advertised to support ODU0 the value of is "ignored" (TS --- > advertised to support ODU0, the value of is "ignored" (TS 770c770 < interface a single ISCD is used and its format is as follows: --- > interface, a single ISCD is used and its format is as follows: 819c819 < In this example two interfaces with homogeneous hierarchies but --- > In this example, two interfaces with homogeneous hierarchies but 822,824c822,824 < one a G.709-2012 interface with fallback procedure disabled (TS < granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy and < priorities 0 and 3. T and S bits values are not relevant to this --- > one supports G.709-2012 interface with fallback procedure disabled > (TS granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy > and priorities 0 and 3. T and S bits values are not relevant to this 826,827c826,827 < interfaces two different ISCDs are used and the format of their SCSIs < is as follows: --- > interfaces, two different ISCDs are used and the format of their > SCSIs is as follows: 903,908c903,908 < with different exported TS granularity MUST be considered as non < homogenous hierarchies is the case in which an H-LPS and the client < LSP are terminated on the same egress node. What can happen is that < a loose Explicit Route Object (ERO) is used at the hop where the < signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate < hop of the LSP). --- > with different exported TS granularity MUST be considered as > non-homogenous hierarchies. This is the case in which an H-LPS and > the client LSP are terminated on the same egress node. What can > happen is that a loose Explicit Route Object (ERO) is used at the > hop where the signaled LSP is nested into the Hierarchical-LSP (H-LSP) > (penultimate hop of the LSP). 912,915c912,915 < if2. In case the H-LSP on if1 exports a TS=3D1.25Gbps and if2 a < TS=3D2.5Gbps and the service LSP being signaled needs a 1.25Gbps < tributary slot, only the H-LSP on if1 can be used to reach node E. < For further details please see section 4.1 of the [OTN-INFO]. --- > if2. In this case, the H-LSP on if1 exports a TS=3D1.25Gbps, if2 a > TS=3D2.5Gbps, the service LSP being signaled needs a 1.25Gbps > tributary slot, and only the H-LSP on if1 can be used to reach node E. > For further details, please see section 4.1 of the [OTN-INFO]. 939,943c939,943 < In this example the advertisement of an ODUflex->ODU3 hierarchy is < shown. In case of ODUflex advertisement the MAX LSP Bandwidth needs < to be advertised and in some cases also information about the < Unreserved bandwidth could be useful. The amount of Unreserved < bandwidth does not give a clear indication of how many ODUflex LSP --- > In this example, the advertisement of an ODUflex->ODU3 hierarchy is > shown. In the case of ODUflex advertisement, the MAX LSP Bandwidth > needs to be advertised and, in some cases, information about the > Unreserved bandwidth could also be useful. The amount of Unreserved > bandwidth does not give a clear indication of how many ODUflex LSPs 959,962c959,962 < Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved < Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex < LSPs of 10 GBps each, have to be restored, for sure only one can be < restored along Link B and it is probable (but not sure) that two of --- > Bandwidth equal to 10 Gbps each. In the case where 50Gbps of Unreserv= ed > Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUflex > LSPs of 10 GBps each have to be restored, for sure only one can be > restored along Link B and it is probable, but not certain, that two of 966c966 < In the case of ODUflex advertisement the Type 2 Bandwidth TLV is --- > In the case of ODUflex advertisement, the Type 2 Bandwidth TLV is 1073c1073 < simplicity we assume that also in this case only priorities 0 and 3 --- > simplicity, we also assume that only priorities 0 and 3 1294c1294 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1388c1388 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1506c1506 < All implementations of this document MAY support also advertisement --- > All implementations of this document MAY also support advertisement 1518c1518 < based on policy and is out of scope of the document. This enables --- > based on policy and beyond the scope of this document. This enables 1537c1537 < [RFC5920] . --- > [RFC5920]. --_000_4A1562797D64E44993C5CBF38CF1BE48163DDBESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Acee,

 <= /p>

Thanks for the careful re= view and please find comments/replies in line.

 <= /p>

BR
Daniele (&co-authors)

 <= /p>

From: Acee Lin= dem [mailto:acee.lindem@ericsso= n.com]
Sent: mercoled=EC 9 ottobre 2013 03:41
To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org
Cc: rtg-dir@ietf.org; CCAMP;= rtg-ads@tools.ietf.org
Subject: RtgDir Review: "Traffic Engineering Extensions to OSPF= for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks"<= o:p>

 

Hello,

 

I have been selected as the Routing Dir= ectorate reviewer for this draft. The Routing Directorate seeks to review a= ll routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purp= ose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please seehttp://www.ietf.or= g/iesg/directorate/routing.html

 

Although these comments are primarily f= or the use of the Routing ADs, it would be helpful if you could consider th= em 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-ospf-g709v3-09.txt

Reviewer: Acee Lindem=

Review Date: October 15th, 2013

IETF LC End Date: October 16, 2013=

Intended Status: Proposed Standard = ;

 

Summary: The document is missing some k= ey sections and requires some clarification prior to publication. 

 

Comments:

 

Major Issues: The document lacks severa= l critical pieces of information.   

 

          &nbs= p;      1. There is no discussion of OSPF scaling or floodin= g frequency. Even if it not expected that G709 

          &nbs= p;           GMPLS signaling will not present= any problems, this needs to be stated and justified. Refer to

          &nbs= p;           section 8 in RFC 6827 for an example = of such a discussion. 

[[Authors]] How abo= ut adding a section saying:

= OSPFv2 scalability considerations and require= ments are in line with section 8 of [RFC6827]. In addition please note that OTN extensions in this document have been designed taking= into consideration optimization criteria identified in [OTN-INFO]

          &nbs= p;      2. The document includes lots of normative text= indicating precisely how sub-TLVs MUST be 

          &nbs= p;           formatted. However, there is no = indication of what the action to be taken if the TLVs do<= /p>

          &nbs= p;           not follow the strict conventions.&nb= sp;

[[Authors]] Good co= mment. Looking at previous OSPF and OSPF-TE drafts we didn’t find any= text on handling of bad TLV formatting. Any suggestion on how to deal with that is more than welcome.

          &nbs= p;      3. The document jumps down into details of G.709 tec= hnology without adequate 

          &nbs= p;            explanation (particularly in th= e examples). Either these details need to be removed or a 

          &nbs= p;           statement of prerequisite knowledge i= s required. 

[[Authors]] The rea= der is supposed to have read [OTN-FWK] and [OTN-INFO]. We can add a sentenc= e at the end of the abstract or intro.

 <= /p>

Minor Issues: The document had a large = number of editorial errors.

 

          &nbs= p;      1. The bit numbering on all the figures was off by 1= column. If you look at RFC 4203, 

          &nbs= p;           this will be obvious. 

[[Author]] Correct.= Fixed.

          &nbs= p;      2. The table on page 7 is incomprehensible with the = given columns and headings. Spaces 

          &nbs= p;           rather than commas in numbers are ann= oying. 

[[Author]] Spaces s= ubstituted with commas. As per comment above having read [OTN-FWK] and [OTN= -INFO] is a prerequisite.

          &nbs= p;      3. The distinction between TLVs and sub-TLVs is not = consistent throughout the document. 

          &nbs= p;           Again, refer to RFC 6827 for an examp= le of consistent referral.

[[Authors]] Good ca= tch. We’re defining only sub-tlvs. Fixed.

          &nbs= p;      4. Figures 8 and 9 have the T and S fields offset fr= om the bit numbering. Also, it took 

          &nbs= p;           some time to realize that T1 meant a = value of 1. 

[[Authors]] T and S= were left intentionally to make the reading easier but maybe it’s no= t the case. Only 0 and 1 are there now.

5. Figures 11-15 are very inconsistent in that these are examples y= et the values for T, S, and  sometime TSG are not specified. Rather, the example includes the letters.  

[[=
Authors]] The focus of those examples is not T,S and TSG but e.g. ODUflex a=
dvertisement, single stage muxing etc. For each example there is a disclaim=
er saying: “T, S and TS granularity fields are not relevant to this example”.

 

          &nbs= p;      6. Security section - RFC 2154 is an experimental RF= C that has heretofore never been 

          &nbs= p;           commercially implemented or deployed.=  It is time to quit referencing it in draft 

          &nbs= p;           "Security Considerations".&= nbsp;

[[Authors]] How abo= ut the following?

OLD

    [RFC3630] suggests mechanisms such as [RFC2154] to protect

   the transmissio= n of this information…

NEW

    [RFC3630] suggests mechanisms to protect

   the transmissio= n of this information…

 

  Nits:

1.    &nb= sp;  The proper punctuation is "= ;i.e., " and "e.g. ,".  

[[Authors]] OK

Al= so, sentences should not start with either. 

          &nbs= p;           See http://www.rfc-edit= or.org/rfc-style-guide/rfc-style<= /p>

2.    &nb= sp;  Page 7, "Switching Capabil= ity-Specific Information (SCSI)? 

[[Authors]] OK

          &nbs= p;      3. Suggest formatting the document so that the figur= es are on separate pages rather than 

          &nbs= p;           split across pages. <= /span>

[[Authors]] I don’t know how to do that with the .xml file.= Maybe this is a comment we can leave for the RFC editor?

3.    &nb= sp;  Replace all occurrences of &quo= t;non " with "non-" and do not end lines with "non &quo= t;. 

[[Authors]] OK

          &nbs= p;      4. I thought the examples included many run-on sente= nces that were hard to parse and lacked

          &nbs= p;           needed punctuation. I tried to edit b= ut I'm not even sure if I retained the same meaning. You 

          &nbs= p;           can get a flavor for what I mean by t= he diffs below. 

[[Authors]] OK to all. All modifications you suggest have= been implemented.

 

 

Thanks,

Acee 

132,13= 3c132,133

< &= nbsp;  Routing information for Optical Channel Layer (OCh) (i.e. wavel= ength)

< &= nbsp;  is out of the scope of this document.  Please refer to [RF= C6163] and

---

> &= nbsp;  Routing information for Optical Channel Layer (OCh) (i.e., wave= length)

> &= nbsp;  is beyond the scope of this document.  Please refer to [RF= C6163] and

 

157c15= 7

< &= nbsp;  As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be exten= ded so

---

> &= nbsp;  As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be exten= ded

 

159c15= 9

< &= nbsp;  related to each different ODUj and ODUk/OTUk (Optical Transport= Unit)

---

> &= nbsp;  of each different ODUj and ODUk/OTUk (Optical Transport Unit)

176c17= 6

< &= nbsp;  In the following we will use ODUj to indicate a service type th= at is

---

> &= nbsp;  In the following, we will use ODUj to indicate a service type t= hat is

179c17= 9

< &= nbsp;  the OTUk.  Moreover ODUj(S) and ODUk(S) are used to indica= te ODUj and

---

> &= nbsp;  the OTUk.  Moreover, ODUj(S) and ODUk(S) are used to indic= ate ODUj and

184c18= 4

< &= nbsp;  multiplexing levels.  In the following the term "mult= iplexing tree"

---

> &= nbsp;  multiplexing levels.  In the following, the term "mul= tiplexing tree"

191c19= 1

< &= nbsp;  If for example a multiplexing hierarchy like the following one = is

---

> &= nbsp;  For example, If a multiplexing hierarchy like the following one= is

251c25= 1

< &= nbsp;  one hop case multiple hop TE-links advertise ODU switching capa= city.

---

> &= nbsp;  one hop case, multiple hop TE-links advertise ODU switching cap= acity.

296,29= 7c296,297

< &= nbsp;  Both for fixed and flexible ODUs the same switching type and en= coding

< &= nbsp;  values MUST be used.  When Switching Capability and Encodi= ng fields

---

> &= nbsp;  The same switching type and encoding values must be used for bo= th fixed

> &= nbsp;  and flexible ODUs.  When Switching Capability and Encoding= fields

303,30= 4c303,304

< &= nbsp;  The MAX LSP Bandwidth field is used according to [RFC4203]: i.e= . 0 <=3D

< &= nbsp;  MAX LSP Bandwidth <=3D ODUk/OTUk and intermediate values are= those on

---

> &= nbsp;  The MAX LSP Bandwidth field is used according to [RFC4203]: i.e= ., 0 <=3D

> &= nbsp;  MAX LSP Bandwidth <=3D ODUk/OTUk, and intermediate values ar= e those on

306,30= 7c306,307

< &= nbsp;  E.g. in the OTU4 link it could be possible to have ODU4 as MAX = LSP

< &= nbsp;  Bandwidth for some priorities, ODU3 for others, ODU2 for some o= thers

---

> &= nbsp;  For example, in the OTU4 link it could be possible to have ODU4= as MAX LSP

> &= nbsp;  Bandwidth for some priorities, ODU3 for others, ODU2 for some o= thers, 

397,39= 8c397,398

< &= nbsp;  Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-= F) non

< &= nbsp;  resizable.  Each MUST always be advertised in separate Typ= e 2 TLVs as

---

> &= nbsp;  Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-= F) 

> &= nbsp;  non-resizable.  Each MUST always be advertised in separate= Type 2 TLVs as

400c40= 0

< &= nbsp;  both GFP-F resizable and non resizable (i.e. 21 and 22) are

---

> &= nbsp;  both GFP-F resizable and non-resizable (i.e. 21 and 22) are

535c535

<       (i.e. a non OTN client).

---

>       (i.e., a non-OTN client).

540c54= 0

< &= nbsp;     - Priority (8 bits): a bitmap used to indicate which pr= iorities

---

> &= nbsp;     - Priority (8 bits): A bitmap used to indicate which pr= iorities

542,54= 3c542,543

< &= nbsp;     leftmost bit representing priority level 0 (i.e. the hi= ghest) and

< &= nbsp;     the rightmost bit representing priority level 7 (i.e. t= he lowest).

---

> &= nbsp;     leftmost bit representing priority level 0 (i.e., the h= ighest) and

> &= nbsp;     the rightmost bit representing priority level 7 (i.e., = the lowest).

666c66= 6

< &= nbsp;     Figure 5: Example 1 - MAX LSP Bandwidth fields in the I= SCD @T0

---

> &= nbsp;     Figure 5: Example 1 - MAX LSP Bandwidth fields in the I= SCD at T0

676,67= 8c676,678

< &= nbsp;  At time T1 an ODU3 at priority 2 is set-up, so for priority 0 t= he MAX

< &= nbsp;  LSP Bandwidth is still equal to the ODU4 bandwidth, while for

< &= nbsp;  priorities from 2 to 7 (excluding the non supported ones) the M= AX LSP

---

> &= nbsp;  At time T1, an ODU3 at priority 2 is set-up, so for priority 0 = the

> &= nbsp;  MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while f= or

> &= nbsp;  priorities from 2 to 7 (excluding the non-supported ones) the M= AX LSP

680c68= 0

< &= nbsp;  next supported ODUj in the hierarchy is ODU3.The advertisement = is

---

> &= nbsp;  next supported ODUj in the hierarchy is ODU3. The advertisement= is

710c71= 0

< &= nbsp;     Figure 6: Example 1 - MAX LSP Bandwidth fields in the I= SCD @T1

---

> &= nbsp;     Figure 6: Example 1 - MAX LSP Bandwidth fields in the I= SCD at T1

712,71= 4c712,714

< &= nbsp;  At time T2 an ODU2 at priority 4 is set-up.  The first ODU= 3 is no

< &= nbsp;  longer available since T1 as it was kept by the ODU3 LSP, while= the

< &= nbsp;  second is no more available and just 3 ODU2 are left in it. &nb= sp;ODU2 is

---

> &= nbsp;  At time T2, an ODU2 at priority 4 is set-up.  The first OD= U3 is no

> &= nbsp;  longer available since T1, as it was kept by the ODU3 LSP, whil= e the

> &= nbsp;  second is no more available and just 3 ODU2s are left in it. &n= bsp;ODU2 is

758c75= 8

< &= nbsp;     Figure 7: Example 1 - MAX LSP Bandwidth fields in the I= SCD @T2

---

> &= nbsp;     Figure 7: Example 1 - MAX LSP Bandwidth fields in the I= SCD at T2

762c76= 2

< &= nbsp;  In this example an interface with Tributary Slot Type 1.25Gbps = and

---

> &= nbsp;  In this example, an interface with Tributary Slot Type 1.25Gbps= and

766c76= 6

< &= nbsp;  switched or terminated, the ODU2 can only be terminated and the= ODU1

---

> &= nbsp;  switched or terminated, the ODU2 can only be terminated, and th= e ODU1

768c76= 8

< &= nbsp;  advertised to support ODU0 the value of is "ignored" = (TS

---

> &= nbsp;  advertised to support ODU0, the value of is "ignored"= (TS

770c77= 0

< &= nbsp;  interface a single ISCD is used and its format is as follows:

---

> &= nbsp;  interface, a single ISCD is used and its format is as follows:<= /span>

819c81= 9

< &= nbsp;  In this example two interfaces with homogeneous hierarchies but=

---

> &= nbsp;  In this example, two interfaces with homogeneous hierarchies bu= t

822,82= 4c822,824

< &= nbsp;  one a G.709-2012 interface with fallback procedure disabled (TS=

< &= nbsp;  granularity=3D3).  Both of them support ODU1->ODU2->= ODU3 hierarchy and

< &= nbsp;  priorities 0 and 3.  T and S bits values are not relevant = to this

---

> &= nbsp;  one supports G.709-2012 interface with fallback procedure disab= led

> &= nbsp;  (TS granularity=3D3).  Both of them support ODU1->ODU2-= >ODU3 hierarchy

> &= nbsp;  and priorities 0 and 3.  T and S bits values are not relev= ant to this

826,82= 7c826,827

< &= nbsp;  interfaces two different ISCDs are used and the format of their= SCSIs

< &= nbsp;  is as follows:

---

> &= nbsp;  interfaces, two different ISCDs are used and the format of thei= r 

> &= nbsp;  SCSIs is as follows:

903,90= 8c903,908

< &= nbsp;  with different exported TS granularity MUST be considered as no= n

< &= nbsp;  homogenous hierarchies is the case in which an H-LPS and the cl= ient

< &= nbsp;  LSP are terminated on the same egress node.  What can happ= en is that

< &= nbsp;  a loose Explicit Route Object (ERO) is used at the hop where th= e

< &= nbsp;  signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penul= timate

< &= nbsp;  hop of the LSP).

---

> &= nbsp;  with different exported TS granularity MUST be considered as&nb= sp;

> &= nbsp;  non-homogenous hierarchies. This is the case in which an H-LPS = and 

> &= nbsp;  the client LSP are terminated on the same egress node.  Wh= at can 

> &= nbsp;  happen is that a loose Explicit Route Object (ERO) is used at t= he 

> &= nbsp;  hop where the signaled LSP is nested into the Hierarchical-LSP = (H-LSP)

> &= nbsp;  (penultimate hop of the LSP).

912,91= 5c912,915

< &= nbsp;  if2.  In case the H-LSP on if1 exports a TS=3D1.25Gbps and= if2 a

< &= nbsp;  TS=3D2.5Gbps and the service LSP being signaled needs a 1.25Gbp= s

< &= nbsp;  tributary slot, only the H-LSP on if1 can be used to reach node= E.

< &= nbsp;  For further details please see section 4.1 of the [OTN-INFO].

---

> &= nbsp;  if2.  In this case, the H-LSP on if1 exports a TS=3D1.25Gb= ps, if2 a

> &= nbsp;  TS=3D2.5Gbps, the service LSP being signaled needs a 1.25Gbps

> &= nbsp;  tributary slot, and only the H-LSP on if1 can be used to reach = node E.

> &= nbsp;  For further details, please see section 4.1 of the [OTN-INFO].<= /span>

939,94= 3c939,943

< &= nbsp;  In this example the advertisement of an ODUflex->ODU3 hierar= chy is

< &= nbsp;  shown.  In case of ODUflex advertisement the MAX LSP Bandw= idth needs

< &= nbsp;  to be advertised and in some cases also information about the

< &= nbsp;  Unreserved bandwidth could be useful.  The amount of Unres= erved

< &= nbsp;  bandwidth does not give a clear indication of how many ODUflex = LSP

---

> &= nbsp;  In this example, the advertisement of an ODUflex->ODU3 hiera= rchy is

> &= nbsp;  shown.  In the case of ODUflex advertisement, the MAX LSP = Bandwidth

> &= nbsp;  needs to be advertised and, in some cases, information about th= e

> &= nbsp;  Unreserved bandwidth could also be useful.  The amount of = Unreserved

> &= nbsp;  bandwidth does not give a clear indication of how many ODUflex = LSPs

959,96= 2c959,962

< &= nbsp;  Bandwidth equal to 10 Gbps each.  In case 50Gbps of Unrese= rved

< &= nbsp;  Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUfl= ex

< &= nbsp;  LSPs of 10 GBps each, have to be restored, for sure only one ca= n be

< &= nbsp;  restored along Link B and it is probable (but not sure) that tw= o of

---

> &= nbsp;  Bandwidth equal to 10 Gbps each.  In the case where 50Gbps= of Unreserved

> &= nbsp;  Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUf= lex

> &= nbsp;  LSPs of 10 GBps each have to be restored, for sure only one can= be

> &= nbsp;  restored along Link B and it is probable, but not certain, that= two of

966c96= 6

< &= nbsp;  In the case of ODUflex advertisement the Type 2 Bandwidth TLV i= s

---

> &= nbsp;  In the case of ODUflex advertisement, the Type 2 Bandwidth TLV = is

1073c1= 073

< &= nbsp;  simplicity we assume that also in this case only priorities 0 a= nd 3

---

> &= nbsp;  simplicity, we also assume that only priorities 0 and 3<= /span>

1294c1= 294

< &= nbsp;  In this example 2 OTU4 component links with the same supported = TS

---

> &= nbsp;  In this example, 2 OTU4 component links with the same supported= TS

1388c1= 388

< &= nbsp;  In this example 2 OTU4 component links with the same supported = TS

---

> &= nbsp;  In this example, 2 OTU4 component links with the same supported= TS

1506c1= 506

< &= nbsp;  All implementations of this document MAY support also advertise= ment

---

> &= nbsp;  All implementations of this document MAY also support advertise= ment

1518c1= 518

< &= nbsp;  based on policy and is out of scope of the document.  This= enables

---

> &= nbsp;  based on policy and beyond the scope of this document.  Th= is enables

1537c1= 537

< &= nbsp;  [RFC5920] .

---

> &= nbsp;  [RFC5920].

 

 

          &nbs= p;     

          &nbs= p;     

 

--_000_4A1562797D64E44993C5CBF38CF1BE48163DDBESESSMB301ericsso_-- From acee.lindem@ericsson.com Wed Oct 16 13:19:58 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CBD11E82D2; Wed, 16 Oct 2013 13:19:58 -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=[AWL=0.900, BAYES_00=-2.599, GB_I_LETTER=-2, 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 MgE4x-u-5LKz; Wed, 16 Oct 2013 13:19:52 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA5111E81F0; Wed, 16 Oct 2013 13:19:47 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-3d-525ef4e11f20 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 0D.D4.09414.1E4FE525; Wed, 16 Oct 2013 22:19:46 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 16:19:42 -0400 From: Acee Lindem To: Daniele Ceccarelli Thread-Topic: RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Thread-Index: AQHOxJCn0+iFqto7ekGiQXMkyXw9jZn0UizAgAPB1YA= Date: Wed, 16 Oct 2013 20:19:41 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470308D349@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE470307FE6D@eusaamb101.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48163DDB@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48163DDB@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470308D349eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPgu6jL3FBBiueqVg8mXODxeJvw2sW i+dzZrJYLFjzlN2BxWPJkp9MHl8uf2YLYIrisklJzcksSy3St0vgyvjW18hW0LeKs2LpXp4G xjPNHF2MnBwSAiYS7VMa2CBsMYkL99aD2UICRxklTi7wg7CXM0qc66kGsdkEdCSeP/rHDGKL CFhIdB17zNrFyMXBLPCYUeLThueMIAlhgS5GiUV72UESIgLdjBKbL++F6rCS+H95BzuIzSKg KjGp/yyYzSvgK9F/ahYTSIOQQD+jxJMFE4EmcXBwCvhIrFxkCFLDCHTd91NrmEBsZgFxiVtP 5jNBXC0gsWTPeWYIW1Ti5eN/rBC2ssSSJ/tZIOrzJbacameC2CUocXLmE5YJjKKzkIyahaRs FpIyiLiBxPtz85khbG2JZQtfQ9n6Ehu/nGWEsK0lXv45zoKsZgEjxypGjtLi1LLcdCODTYzA KDwmwaa7g3HPS8tDjNIcLErivF/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYPRmEvss s2Kv2r3AYts1r646sP0729a4pbnA8OxmqcJfd416+y8JnEzZp6NX+ZXV+5K62Ov3K6VEuX89 ebRvj46eQbar+8qJlfoL3MS9im8GLo/KiW9Oky2IiD/N79/WMtcwy682+eaxPzMbnVYcKzL6 Ye2ue6mjpWxf8N4I6/AZJ8UmsXX2K7EUZyQaajEXFScCAB0NMTaQAgAA Cc: "rtg-dir@ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 20:19:58 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470308D349eusaamb101erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Daniele, See inline. On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrote: Hi Acee, Thanks for the careful review and please find comments/replies in line. BR Daniele (&co-authors) From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: mercoled=EC 9 ottobre 2013 03:41 To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org Cc: rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.or= g Subject: RtgDir Review: "Traffic Engineering Extensions to OSPF for General= ized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please seehttp= ://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ccamp-ospf-g709v3-09.txt Reviewer: Acee Lindem Review Date: October 15th, 2013 IETF LC End Date: October 16, 2013 Intended Status: Proposed Standard Summary: The document is missing some key sections and requires some clarif= ication prior to publication. Comments: Major Issues: The document lacks several critical pieces of information. 1. There is no discussion of OSPF scaling or flooding freq= uency. Even if it not expected that G709 GMPLS signaling will not present any problems, this n= eeds to be stated and justified. Refer to section 8 in RFC 6827 for an example of such a discus= sion. [[Authors]] How about adding a section saying: OSPFv2 scalability considerations and requirements are in line with section= 8 of [RFC6827]. In addition please note that OTN extensions in this docume= nt have been designed taking into consideration optimization criteria ident= ified in [OTN-INFO] It isn't obvious to me that these two extensions are comparable. I think a = separate section pertaining to the OTN extensions would make more sense. 2. The document includes lots of normative text indicating= precisely how sub-TLVs MUST be formatted. However, there is no indication of what th= e action to be taken if the TLVs do not follow the strict conventions. [[Authors]] Good comment. Looking at previous OSPF and OSPF-TE drafts we di= dn=92t find any text on handling of bad TLV formatting. Any suggestion on h= ow to deal with that is more than welcome. In the past, I've stated that the problem should be logged and the LSA, TLV= , or Sub-TLV MUST NOT be used for TE/GMPLS path computation. It all depends= on what makes sense for the encoding violation and at what level it should= be resolved. One generic solution would be to NOT use any LSAs with encodi= ng violations for GMPLS path computation. 3. The document jumps down into details of G.709 technolog= y without adequate explanation (particularly in the examples). Either t= hese details need to be removed or a statement of prerequisite knowledge is required. [[Authors]] The reader is supposed to have read [OTN-FWK] and [OTN-INFO]. W= e can add a sentence at the end of the abstract or intro. This is the minimum. Minor Issues: The document had a large number of editorial errors. 1. The bit numbering on all the figures was off by 1 colum= n. If you look at RFC 4203, this will be obvious. [[Author]] Correct. Fixed. 2. The table on page 7 is incomprehensible with the given = columns and headings. Spaces rather than commas in numbers are annoying. [[Author]] Spaces substituted with commas. As per comment above having read= [OTN-FWK] and [OTN-INFO] is a prerequisite. Does it add anything to this document if one needs to look at OTN-FWK and O= TN-INFO anyway? It is much less relevant than, say, a discussion of adverti= sement and scaling ;^) For example, what does 239/238 mean? Is this 239 or 238 separate tributary = slots - why is it variable? What does GFP-F mean - it is not defined here. 3. The distinction between TLVs and sub-TLVs is not consis= tent throughout the document. Again, refer to RFC 6827 for an example of consistent= referral. [[Authors]] Good catch. We=92re defining only sub-tlvs. Fixed. 4. Figures 8 and 9 have the T and S fields offset from the= bit numbering. Also, it took some time to realize that T1 meant a value of 1. [[Authors]] T and S were left intentionally to make the reading easier but = maybe it=92s not the case. Only 0 and 1 are there now. 5. Figures 11-15 are very inconsistent in that these are examples yet the v= alues for T, S, and sometime TSG are not specified. Rather, the example in= cludes the letters. [[Authors]] The focus of those examples is not T,S and TSG but e.g. ODUflex= advertisement, single stage muxing etc. For each example there is a discla= imer saying: =93T, S and TS granularity fields are not relevant to this exa= mple=94. Then wouldn't X's be more relevant than missing discrete values and field l= abels in the same figure? 6. Security section - RFC 2154 is an experimental RFC that= has heretofore never been commercially implemented or deployed. It is time to q= uit referencing it in draft "Security Considerations". [[Authors]] How about the following? OLD [RFC3630] suggests mechanisms such = as [RFC2154] to protect the transmission of this information=85 NEW [RFC3630] suggests mechanisms to pr= otect the transmission of this information=85 It would be great with me. There are plenty of reviewers who will nit pick = the security section... Nits: 1. The proper punctuation is "i.e., " and "e.g. ,". [[Authors]] OK Also, sentences should not start with either. See http://www.rfc-editor.org/rfc-style-guide/rfc-sty= le 2. Page 7, "Switching Capability-Specific Information (SCSI)? [[Authors]] OK 3. Suggest formatting the document so that the figures are= on separate pages rather than split across pages. [[Authors]] I don=92t know how to do that with the .xml file. Maybe this is= a comment we can leave for the RFC editor? Ok. I have been able to do this with 3. Replace all occurrences of "non " with "non-" and do not end lines= with "non ". [[Authors]] OK 4. I thought the examples included many run-on sentences t= hat were hard to parse and lacked needed punctuation. I tried to edit but I'm not even = sure if I retained the same meaning. You can get a flavor for what I mean by the diffs below. [[Authors]] OK to all. All modifications you suggest have been implemented. Thanks - I'll look for the update. Thanks, Acee Thanks, Acee 132,133c132,133 < Routing information for Optical Channel Layer (OCh) (i.e. wavelength) < is out of the scope of this document. Please refer to [RFC6163] and --- > Routing information for Optical Channel Layer (OCh) (i.e., wavelength) > is beyond the scope of this document. Please refer to [RFC6163] and 157c157 < As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so --- > As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended 159c159 < related to each different ODUj and ODUk/OTUk (Optical Transport Unit) --- > of each different ODUj and ODUk/OTUk (Optical Transport Unit) 176c176 < In the following we will use ODUj to indicate a service type that is --- > In the following, we will use ODUj to indicate a service type that is 179c179 < the OTUk. Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and --- > the OTUk. Moreover, ODUj(S) and ODUk(S) are used to indicate ODUj and 184c184 < multiplexing levels. In the following the term "multiplexing tree" --- > multiplexing levels. In the following, the term "multiplexing tree" 191c191 < If for example a multiplexing hierarchy like the following one is --- > For example, If a multiplexing hierarchy like the following one is 251c251 < one hop case multiple hop TE-links advertise ODU switching capacity. --- > one hop case, multiple hop TE-links advertise ODU switching capacity. 296,297c296,297 < Both for fixed and flexible ODUs the same switching type and encoding < values MUST be used. When Switching Capability and Encoding fields --- > The same switching type and encoding values must be used for both fixe= d > and flexible ODUs. When Switching Capability and Encoding fields 303,304c303,304 < The MAX LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <= =3D < MAX LSP Bandwidth <=3D ODUk/OTUk and intermediate values are those on --- > The MAX LSP Bandwidth field is used according to [RFC4203]: i.e., 0 <= =3D > MAX LSP Bandwidth <=3D ODUk/OTUk, and intermediate values are those on 306,307c306,307 < E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP < Bandwidth for some priorities, ODU3 for others, ODU2 for some others --- > For example, in the OTU4 link it could be possible to have ODU4 as MAX= LSP > Bandwidth for some priorities, ODU3 for others, ODU2 for some others, 397,398c397,398 < Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non < resizable. Each MUST always be advertised in separate Type 2 TLVs as --- > Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) > non-resizable. Each MUST always be advertised in separate Type 2 TLVs= as 400c400 < both GFP-F resizable and non resizable (i.e. 21 and 22) are --- > both GFP-F resizable and non-resizable (i.e. 21 and 22) are 535c535 < (i.e. a non OTN client). --- > (i.e., a non-OTN client). 540c540 < - Priority (8 bits): a bitmap used to indicate which priorities --- > - Priority (8 bits): A bitmap used to indicate which priorities 542,543c542,543 < leftmost bit representing priority level 0 (i.e. the highest) and < the rightmost bit representing priority level 7 (i.e. the lowest). --- > leftmost bit representing priority level 0 (i.e., the highest) and > the rightmost bit representing priority level 7 (i.e., the lowest). 666c666 < Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD @T0 --- > Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD at T0 676,678c676,678 < At time T1 an ODU3 at priority 2 is set-up, so for priority 0 the MAX < LSP Bandwidth is still equal to the ODU4 bandwidth, while for < priorities from 2 to 7 (excluding the non supported ones) the MAX LSP --- > At time T1, an ODU3 at priority 2 is set-up, so for priority 0 the > MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for > priorities from 2 to 7 (excluding the non-supported ones) the MAX LSP 680c680 < next supported ODUj in the hierarchy is ODU3.The advertisement is --- > next supported ODUj in the hierarchy is ODU3. The advertisement is 710c710 < Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD @T1 --- > Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD at T1 712,714c712,714 < At time T2 an ODU2 at priority 4 is set-up. The first ODU3 is no < longer available since T1 as it was kept by the ODU3 LSP, while the < second is no more available and just 3 ODU2 are left in it. ODU2 is --- > At time T2, an ODU2 at priority 4 is set-up. The first ODU3 is no > longer available since T1, as it was kept by the ODU3 LSP, while the > second is no more available and just 3 ODU2s are left in it. ODU2 is 758c758 < Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD @T2 --- > Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD at T2 762c762 < In this example an interface with Tributary Slot Type 1.25Gbps and --- > In this example, an interface with Tributary Slot Type 1.25Gbps and 766c766 < switched or terminated, the ODU2 can only be terminated and the ODU1 --- > switched or terminated, the ODU2 can only be terminated, and the ODU1 768c768 < advertised to support ODU0 the value of is "ignored" (TS --- > advertised to support ODU0, the value of is "ignored" (TS 770c770 < interface a single ISCD is used and its format is as follows: --- > interface, a single ISCD is used and its format is as follows: 819c819 < In this example two interfaces with homogeneous hierarchies but --- > In this example, two interfaces with homogeneous hierarchies but 822,824c822,824 < one a G.709-2012 interface with fallback procedure disabled (TS < granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy and < priorities 0 and 3. T and S bits values are not relevant to this --- > one supports G.709-2012 interface with fallback procedure disabled > (TS granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy > and priorities 0 and 3. T and S bits values are not relevant to this 826,827c826,827 < interfaces two different ISCDs are used and the format of their SCSIs < is as follows: --- > interfaces, two different ISCDs are used and the format of their > SCSIs is as follows: 903,908c903,908 < with different exported TS granularity MUST be considered as non < homogenous hierarchies is the case in which an H-LPS and the client < LSP are terminated on the same egress node. What can happen is that < a loose Explicit Route Object (ERO) is used at the hop where the < signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate < hop of the LSP). --- > with different exported TS granularity MUST be considered as > non-homogenous hierarchies. This is the case in which an H-LPS and > the client LSP are terminated on the same egress node. What can > happen is that a loose Explicit Route Object (ERO) is used at the > hop where the signaled LSP is nested into the Hierarchical-LSP (H-LSP) > (penultimate hop of the LSP). 912,915c912,915 < if2. In case the H-LSP on if1 exports a TS=3D1.25Gbps and if2 a < TS=3D2.5Gbps and the service LSP being signaled needs a 1.25Gbps < tributary slot, only the H-LSP on if1 can be used to reach node E. < For further details please see section 4.1 of the [OTN-INFO]. --- > if2. In this case, the H-LSP on if1 exports a TS=3D1.25Gbps, if2 a > TS=3D2.5Gbps, the service LSP being signaled needs a 1.25Gbps > tributary slot, and only the H-LSP on if1 can be used to reach node E. > For further details, please see section 4.1 of the [OTN-INFO]. 939,943c939,943 < In this example the advertisement of an ODUflex->ODU3 hierarchy is < shown. In case of ODUflex advertisement the MAX LSP Bandwidth needs < to be advertised and in some cases also information about the < Unreserved bandwidth could be useful. The amount of Unreserved < bandwidth does not give a clear indication of how many ODUflex LSP --- > In this example, the advertisement of an ODUflex->ODU3 hierarchy is > shown. In the case of ODUflex advertisement, the MAX LSP Bandwidth > needs to be advertised and, in some cases, information about the > Unreserved bandwidth could also be useful. The amount of Unreserved > bandwidth does not give a clear indication of how many ODUflex LSPs 959,962c959,962 < Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved < Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex < LSPs of 10 GBps each, have to be restored, for sure only one can be < restored along Link B and it is probable (but not sure) that two of --- > Bandwidth equal to 10 Gbps each. In the case where 50Gbps of Unreserv= ed > Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUflex > LSPs of 10 GBps each have to be restored, for sure only one can be > restored along Link B and it is probable, but not certain, that two of 966c966 < In the case of ODUflex advertisement the Type 2 Bandwidth TLV is --- > In the case of ODUflex advertisement, the Type 2 Bandwidth TLV is 1073c1073 < simplicity we assume that also in this case only priorities 0 and 3 --- > simplicity, we also assume that only priorities 0 and 3 1294c1294 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1388c1388 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1506c1506 < All implementations of this document MAY support also advertisement --- > All implementations of this document MAY also support advertisement 1518c1518 < based on policy and is out of scope of the document. This enables --- > based on policy and beyond the scope of this document. This enables 1537c1537 < [RFC5920] . --- > [RFC5920]. --_000_94A203EA12AECE4BA92D42DBFFE0AE470308D349eusaamb101erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8ED1E30101426541B59BFFD62E607888@ericsson.com> Content-Transfer-Encoding: quoted-printable Hi Daniele,
See inline. 

On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrote:

Hi Acee,
 
Thanks for the careful review and please find comments/re= plies in line.
 
BR
Daniele (&co-authors)
 
From:=  Acee Lindem [mailto:acee.lindem@ericsson.com] 
Sent: mercoled=EC = 9 ottobre 2013 03:41
To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ie= tf.org
Cc: r= tg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.org
Subject: RtgDir Re= view: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GM= PLS) Control of Evolving G.709 OTN Networks"
 
Hello= ,
 = ;
I hav= e been selected as the Routing Directorate reviewer for this draft. The Rou= ting Directorate seeks to review all routing or routing-related drafts as t= hey pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review i= s to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please seehtt= p://www.ietf.org/iesg/directorate/routing.html
 = ;
Altho= ugh these comments are primarily for the use of the Routing ADs, it would b= e helpful if you could consider them along with any other IETF Last Call co= mments that you receive, and strive to resolve them through discussion or by updating the draft.
 = ;
Docum= ent: draft-ietf-ccamp-ospf-g70= 9v3-09.txt
Revie= wer: Acee Lindem
Revie= w Date: October 15th, 2013
IETF = LC End Date: October 16, 2013
Inten= ded Status: Proposed Standard 
 = ;
Summa= ry: The document is missing some key sections and requires some clarificati= on prior to publication. 
 = ;
Comme= nts:
 = ;
Major= Issues: The document lacks several critical pieces of information.  &= nbsp;
=  
 = ;                1. There is no dis= cussion of OSPF scaling or flooding frequency. Even if it not expected that= G709 
 = ;                     GMP= LS signaling will not present any problems, this needs to be stated an= d justified. Refer to
 = ;                     sec= tion 8 in RFC 6827 for an example of such a discussion. 
[[Authors]] How about adding a section saying:=
OSPFv2 scalability considerations and requirements = are in line with section 8 of [RFC6827]. In addition please note that OTN e= xtensions in this document have been designed taking into consideration optimization criteria identified in [OT= N-INFO]

It isn't obvious to me that these two extensions are comparable. I thi= nk a separate section pertaining to the OTN extensions would make more sens= e. 


 = ;                2. The document in= cludes lots of normative text indicating precisely how sub-TLVs M= UST be 
 = ;                     for= matted. However, there is no indication of what the action to be taken= if the TLVs do
 = ;                     not= follow the strict conventions. 
[[Authors]] Good comment. Looking at previous OSPF = and OSPF-TE drafts we didn=92t find any text on handling of bad TLV formatt= ing. Any suggestion on how to deal with that is more than welcome.

In the past, I've stated that the problem should be logged and the LSA= , TLV, or Sub-TLV MUST NOT be used for TE/GMPLS path computation. It all de= pends on what makes sense for the encoding violation and at what level it s= hould be resolved. One generic solution would be to NOT use any LSAs with encoding violations for GMPLS path compu= tation. 


 = ;                3. The document ju= mps down into details of G.709 technology without adequate =
 = ;                     &nb= sp;explanation (particularly in the examples). Either these details ne= ed to be removed or a 
 = ;                     sta= tement of prerequisite knowledge is required. 
[[Authors]] The reader is supposed to have read [OT= N-FWK] and [OTN-INFO]. We can add a sentence at the end of the abstract or = intro.

This is the minimum. 

 
Minor= Issues: The document had a large number of editorial errors.
=  
 = ;                1. The bit numberi= ng on all the figures was off by 1 column. If you look at RFC 4203, 
 = ;                     thi= s will be obvious. 
[[Author]] Correct. Fixed.
 = ;                2. The table on pa= ge 7 is incomprehensible with the given columns and headings. Spaces <= o:p>
 = ;                     rat= her than commas in numbers are annoying. 


=
[[Author]] Spaces substituted with commas. As per c= omment above having read [OTN-FWK] and [OTN-INFO] is a prerequisite.=

Does it add anything to this document if one needs to look at OTN-FWK = and OTN-INFO anyway? It is much less relevant than, say, a discussion of ad= vertisement and scaling ;^) 

For example, what does 239/238 mean? Is this 239 or 238 separate tribu= tary slots - why is it variable? What does GFP-F mean - it is not defined h= ere. 


 = ;                3. The distinction= between TLVs and sub-TLVs is not consistent throughout the document. =
 = ;                     Aga= in, refer to RFC 6827 for an example of consistent referral.
[[Authors]] Good catch. We=92re defining only sub-t= lvs. Fixed.
 = ;                4. Figures 8 and 9= have the T and S fields offset from the bit numbering. Also, it took =
 = ;                     som= e time to realize that T1 meant a value of 1. 
[[Authors]] T and S were left intentionally to make= the reading easier but maybe it=92s not the case. Only 0 and 1 are there n= ow.
5. Fi= gures 11-15 are very inconsistent in that these are examples yet the values= for T, S, and  sometime TSG are not specified. Rather, the example in= cludes the letters.  
[[Authors]] The focus of those exa=
mples is not T,S and TSG but e.g. ODUflex advertisement, single stage muxin=
g etc. For each example there is a disclaimer saying: =93T, S and TS granularity fields=
 are not relevant to this example=94.=

Then wouldn't X's be more relevant than missing discrete values and fi= eld labels in the same figure? 

=  
 = ;                6. Security sectio= n - RFC 2154 is an experimental RFC that has heretofore never been 
 = ;                     com= mercially implemented or deployed. It is time to quit referencing it i= n draft 
 = ;                     &qu= ot;Security Considerations". 
[[Authors]] How about the following?
OLD
    [RFC3630] suggests mechanisms such =
as [RFC2154] to protect
   the= transmission of this information=85
NEW
    [RFC3630] suggests mechanisms to pr=
otect
   the= transmission of this information=85

It would be great with me. There are plenty of reviewers who will nit = pick the security section... 


=  
 = ; Nits:
1. The proper punctuation is "i.e., " and "e.g. ,".  
[[Authors]] OK
Also,= sentences should not start with either. 
 = ;                     See=  http://www.rfc-editor.org/= rfc-style-guide/rfc-style
2. Page 7, "Switching Capability-Specific Information (SCSI)? 
[[Authors]] OK
 = ;                3. Suggest formatt= ing the document so that the figures are on separate pages rather than = ;
 = ;                     spl= it across pages. 
[[Authors]] I don=92t know how to do that with the = .xml file. Maybe this is a comment we can leave for the RFC editor?<= /i>

Ok. I have been able to do this with 

<vspace blankLines=3D"100" />


=
3. Replace all occurrences of "non " with "non-" and do not end l= ines with "non ". 
[[Authors]] OK
 = ;                4. I thought the e= xamples included many run-on sentences that were hard to parse and lacked
 = ;                     nee= ded punctuation. I tried to edit but I'm not even sure if I retained the sa= me meaning. You 
 = ;                     can= get a flavor for what I mean by the diffs below. 
[[Authors]] OK to all. All modifications you sugges= t have been implemented.

Thanks - I'll look for the update. 

Thanks,
Acee 


=
=  
=  
Thank= s,
Acee&= nbsp;
132,133c132,133
<    Routing information for Optic= al Channel Layer (OCh) (i.e. wavelength)
<    is out of the scope of this d= ocument.  Please refer to [RFC6163] and
---
>    Routing information for Optic= al Channel Layer (OCh) (i.e., wavelength)
>    is beyond the scope of this d= ocument.  Please refer to [RFC6163] and
 
157c157
<    As discussed in [OTN-FWK] and= [OTN-INFO], OSPF-TE must be extended so
---
>    As discussed in [OTN-FWK] and= [OTN-INFO], OSPF-TE must be extended
 
159c159
<    related to each different ODU= j and ODUk/OTUk (Optical Transport Unit)
---
>    of each different ODUj and OD= Uk/OTUk (Optical Transport Unit)
176c176
<    In the following we will use = ODUj to indicate a service type that is
---
>    In the following, we will use= ODUj to indicate a service type that is
179c179
<    the OTUk.  Moreover ODUj= (S) and ODUk(S) are used to indicate ODUj and
---
>    the OTUk.  Moreover, ODU= j(S) and ODUk(S) are used to indicate ODUj and
184c184
<    multiplexing levels.  In= the following the term "multiplexing tree"
---
>    multiplexing levels.  In= the following, the term "multiplexing tree"
191c191
<    If for example a multiplexing= hierarchy like the following one is
---
>    For example, If a multiplexin= g hierarchy like the following one is
251c251
<    one hop case multiple hop TE-= links advertise ODU switching capacity.
---
>    one hop case, multiple hop TE= -links advertise ODU switching capacity.
296,297c296,297
<    Both for fixed and flexible O= DUs the same switching type and encoding
<    values MUST be used.  Wh= en Switching Capability and Encoding fields
---
>    The same switching type and e= ncoding values must be used for both fixed
>    and flexible ODUs.  When= Switching Capability and Encoding fields
303,304c303,304
<    The MAX LSP Bandwidth field i= s used according to [RFC4203]: i.e. 0 <=3D
<    MAX LSP Bandwidth <=3D ODU= k/OTUk and intermediate values are those on
---
>    The MAX LSP Bandwidth field i= s used according to [RFC4203]: i.e., 0 <=3D
>    MAX LSP Bandwidth <=3D ODU= k/OTUk, and intermediate values are those on
306,307c306,307
<    E.g. in the OTU4 link it coul= d be possible to have ODU4 as MAX LSP
<    Bandwidth for some priorities= , ODU3 for others, ODU2 for some others
---
>    For example, in the OTU4 link= it could be possible to have ODU4 as MAX LSP
>    Bandwidth for some priorities= , ODU3 for others, ODU2 for some others, 
397,398c397,398
<    Procedure-Frame mapped (GFP-F= ) resizable and 22 - ODUflex (GFP-F) non
<    resizable.  Each MUST al= ways be advertised in separate Type 2 TLVs as
---
>    Procedure-Frame mapped (GFP-F= ) resizable and 22 - ODUflex (GFP-F) 
>    non-resizable.  Each MUS= T always be advertised in separate Type 2 TLVs as<= /div>
400c400
<    both GFP-F resizable and non = resizable (i.e. 21 and 22) are
---
>    both GFP-F resizable and non-= resizable (i.e. 21 and 22) are
535c535
<       (i.e. a n= on OTN client).
---=
>       (i.e., a = non-OTN client).
540c540
<       - Priority (8 bits): = a bitmap used to indicate which priorities
---
>       - Priority (8 bits): = A bitmap used to indicate which priorities
542,543c542,543
<       leftmost bit represen= ting priority level 0 (i.e. the highest) and
<       the rightmost bit rep= resenting priority level 7 (i.e. the lowest).
---
>       leftmost bit represen= ting priority level 0 (i.e., the highest) and
>       the rightmost bit rep= resenting priority level 7 (i.e., the lowest).
666c666
<       Figure 5: Example 1 -= MAX LSP Bandwidth fields in the ISCD @T0
---
>       Figure 5: Example 1 -= MAX LSP Bandwidth fields in the ISCD at T0
676,678c676,678
<    At time T1 an ODU3 at priorit= y 2 is set-up, so for priority 0 the MAX
<    LSP Bandwidth is still equal = to the ODU4 bandwidth, while for
<    priorities from 2 to 7 (exclu= ding the non supported ones) the MAX LSP
---
>    At time T1, an ODU3 at priori= ty 2 is set-up, so for priority 0 the
>    MAX LSP Bandwidth is still eq= ual to the ODU4 bandwidth, while for
>    priorities from 2 to 7 (exclu= ding the non-supported ones) the MAX LSP
680c680
<    next supported ODUj in the hi= erarchy is ODU3.The advertisement is
---
>    next supported ODUj in the hi= erarchy is ODU3. The advertisement is
710c710
<       Figure 6: Example 1 -= MAX LSP Bandwidth fields in the ISCD @T1
---
>       Figure 6: Example 1 -= MAX LSP Bandwidth fields in the ISCD at T1
712,714c712,714
<    At time T2 an ODU2 at priorit= y 4 is set-up.  The first ODU3 is no
<    longer available since T1 as = it was kept by the ODU3 LSP, while the
<    second is no more available a= nd just 3 ODU2 are left in it.  ODU2 is
---
>    At time T2, an ODU2 at priori= ty 4 is set-up.  The first ODU3 is no
>    longer available since T1, as= it was kept by the ODU3 LSP, while the
>    second is no more available a= nd just 3 ODU2s are left in it.  ODU2 is
758c758
<       Figure 7: Example 1 -= MAX LSP Bandwidth fields in the ISCD @T2
---
>       Figure 7: Example 1 -= MAX LSP Bandwidth fields in the ISCD at T2
762c762
<    In this example an interface = with Tributary Slot Type 1.25Gbps and
---
>    In this example, an interface= with Tributary Slot Type 1.25Gbps and
766c766
<    switched or terminated, the O= DU2 can only be terminated and the ODU1
---
>    switched or terminated, the O= DU2 can only be terminated, and the ODU1
768c768
<    advertised to support ODU0 th= e value of is "ignored" (TS
---
>    advertised to support ODU0, t= he value of is "ignored" (TS
770c770
<    interface a single ISCD is us= ed and its format is as follows:
---
>    interface, a single ISCD is u= sed and its format is as follows:
819c819
<    In this example two interface= s with homogeneous hierarchies but
---
>    In this example, two interfac= es with homogeneous hierarchies but
822,824c822,824
<    one a G.709-2012 interface wi= th fallback procedure disabled (TS
<    granularity=3D3).  Both = of them support ODU1->ODU2->ODU3 hierarchy and
<    priorities 0 and 3.  T a= nd S bits values are not relevant to this
---
>    one supports G.709-2012 inter= face with fallback procedure disabled
>    (TS granularity=3D3).  B= oth of them support ODU1->ODU2->ODU3 hierarchy
>    and priorities 0 and 3.  = ;T and S bits values are not relevant to this
826,827c826,827
<    interfaces two different ISCD= s are used and the format of their SCSIs
<    is as follows:<= o:p>
---
>    interfaces, two different ISC= Ds are used and the format of their 
>    SCSIs is as follows:
903,908c903,908
<    with different exported TS gr= anularity MUST be considered as non
<    homogenous hierarchies is the= case in which an H-LPS and the client
<    LSP are terminated on the sam= e egress node.  What can happen is that
<    a loose Explicit Route Object= (ERO) is used at the hop where the
<    signaled LSP is nested into t= he Hierarchical-LSP (H-LSP) (penultimate
<    hop of the LSP).
---
>    with different exported TS gr= anularity MUST be considered as 
>    non-homogenous hierarchies. T= his is the case in which an H-LPS and 
>    the client LSP are terminated= on the same egress node.  What can 
>    happen is that a loose Explic= it Route Object (ERO) is used at the 
>    hop where the signaled LSP is= nested into the Hierarchical-LSP (H-LSP)
>    (penultimate hop of the LSP).=
912,915c912,915
<    if2.  In case the H-LSP = on if1 exports a TS=3D1.25Gbps and if2 a
<    TS=3D2.5Gbps and the service = LSP being signaled needs a 1.25Gbps
<    tributary slot, only the H-LS= P on if1 can be used to reach node E.
<    For further details please se= e section 4.1 of the [OTN-INFO].
---
>    if2.  In this case, the = H-LSP on if1 exports a TS=3D1.25Gbps, if2 a
>    TS=3D2.5Gbps, the service LSP= being signaled needs a 1.25Gbps
>    tributary slot, and only the = H-LSP on if1 can be used to reach node E.
>    For further details, please s= ee section 4.1 of the [OTN-INFO].
939,943c939,943
<    In this example the advertise= ment of an ODUflex->ODU3 hierarchy is
<    shown.  In case of ODUfl= ex advertisement the MAX LSP Bandwidth needs
<    to be advertised and in some = cases also information about the
<    Unreserved bandwidth could be= useful.  The amount of Unreserved
<    bandwidth does not give a cle= ar indication of how many ODUflex LSP
---
>    In this example, the advertis= ement of an ODUflex->ODU3 hierarchy is
>    shown.  In the case of O= DUflex advertisement, the MAX LSP Bandwidth
>    needs to be advertised and, i= n some cases, information about the
>    Unreserved bandwidth could al= so be useful.  The amount of Unreserved
>    bandwidth does not give a cle= ar indication of how many ODUflex LSPs
959,962c959,962
<    Bandwidth equal to 10 Gbps ea= ch.  In case 50Gbps of Unreserved
<    Bandwidth are available on Li= nk A, 10Gbps on Link B and 3 ODUflex
<    LSPs of 10 GBps each, have to= be restored, for sure only one can be
<    restored along Link B and it = is probable (but not sure) that two of
---
>    Bandwidth equal to 10 Gbps ea= ch.  In the case where 50Gbps of Unreserved
>    Bandwidth are available on Li= nk A, 10Gbps on Link B, and 3 ODUflex
>    LSPs of 10 GBps each have to = be restored, for sure only one can be
>    restored along Link B and it = is probable, but not certain, that two of
966c966
<    In the case of ODUflex advert= isement the Type 2 Bandwidth TLV is
---
>    In the case of ODUflex advert= isement, the Type 2 Bandwidth TLV is
1073c1073
<    simplicity we assume that als= o in this case only priorities 0 and 3
---
>    simplicity, we also assume th= at only priorities 0 and 3
1294c1294
<    In this example 2 OTU4 compon= ent links with the same supported TS
---
>    In this example, 2 OTU4 compo= nent links with the same supported TS
1388c1388
<    In this example 2 OTU4 compon= ent links with the same supported TS
---
>    In this example, 2 OTU4 compo= nent links with the same supported TS
1506c1506
<    All implementations of this d= ocument MAY support also advertisement
---
>    All implementations of this d= ocument MAY also support advertisement
1518c1518
<    based on policy and is out of= scope of the document.  This enables
---
>    based on policy and beyond th= e scope of this document.  This enables
1537c1537
<    [RFC5920] .
---
>    [RFC5920].=
=  
=  
 = ;               <= /div>
 = ;               <= /div>
 = ;

--_000_94A203EA12AECE4BA92D42DBFFE0AE470308D349eusaamb101erics_-- From huubatwork@gmail.com Thu Oct 17 05:53:19 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5C221F9A72; Thu, 17 Oct 2013 05:53:19 -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 gOibnrwjwQOh; Thu, 17 Oct 2013 05:53:17 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7A44E21F9A70; Thu, 17 Oct 2013 05:53:16 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c13so1031686eek.19 for ; Thu, 17 Oct 2013 05:53:15 -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=a8QJ6crRqx9nxCbpBHBf2Iev95sk5TASzNKks09rs14=; b=ViA5Pi3vPy4OMOSyFJpow4MiML8SY+/PofgS44kWKJg6PiCEsmD/lXO0Gq2oiDQ3Km wbs7OYgD0acEe0aYYkpJ/zvfPobcQi4PRiIr6uraCIfIRQDPplMYqHDRrpKYGUKOZhtE 2YEIc32oHkAyFztAPjPWy8ASkigTqNtQnVfedASM2ouavyn4ck8m57q2imjET+NU0VEp NfynopXgt3FoLWNcuIo5Cy9qQWrGrvbQ0FeMudbgwTA3w2ClbOmg4293fGXjdzbNDfqz AbtBI/o7S1CsaK1A8oGuePW8UOCwKy3WhF6pZSPFCk7OOHx+RhZHlKddVD5EzFDWthO2 vRxQ== X-Received: by 10.15.110.75 with SMTP id cg51mr5504640eeb.42.1382014395174; Thu, 17 Oct 2013 05:53:15 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id z12sm192562655eev.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 05:53:14 -0700 (PDT) Message-ID: <525FDDBA.1010306@gmail.com> Date: Thu, 17 Oct 2013 14:53:14 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" , "rtg-ads@tools.ietf.org" References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 17 Oct 2013 05:56:32 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 12:53:19 -0000 Hello Manav, You wrote: > I have been selected as the Routing Directorate reviewer for this draft. Thank you for your review. I will address all your comments in the next spin of the draft. I only want to bring some clarification to your proposal: > o) In 3.7, it would be useful to mention that an important > property of co-routed bidirectional path is that the forward > and backward directions share fate. > Similarly, in 3.1, we should mention that the forward and > backward directions don't share fate. Fate-sharing is NOT a requirement for co-routed bi-directional paths. It is only a secondary effect. E.g. in a cable only one of the fibers can fail/break, same for internal ports in routers, as well as forwarding. The main requirements for co-routed bidirectional paths are: == follow exactly the same path i.e. physical sections, and nodes in both directions == the MEPS at the end-points can communicate directly via the RI (remote interface) NOT via the management plane == during a protection switch both directions are switched (at the same time) from working entity to protection entity. == both are managed as a single entity The only fate-sharing requirement in ITU-T is for OAM packets and data packets transported between the same endpoints See the first paragraph in clauses 6.4 and 7.1 of G.8113.1 and G.8113.2. To resolve your point I can add text to 3.7 that both directions are managed and operated as a single entity; and in 3.1 that they need not be a single management and operational entity. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From daniele.ceccarelli@ericsson.com Mon Oct 21 07:30:23 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31B311E8592; Mon, 21 Oct 2013 07:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.976 X-Spam-Level: X-Spam-Status: No, score=-4.976 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, GB_I_LETTER=-2, 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 cIsSvHspQ+hc; Mon, 21 Oct 2013 07:30:10 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D271E11E860A; Mon, 21 Oct 2013 07:29:26 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-a2-52653a4519ba Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 0B.F9.25272.54A35625; Mon, 21 Oct 2013 16:29:25 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.27]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 16:29:25 +0200 From: Daniele Ceccarelli To: Acee Lindem Thread-Topic: RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Thread-Index: AQHOxJCn0+iFqto7ekGiQXMkyXw9jZn0UizAgAPB1YCAByQB8A== Date: Mon, 21 Oct 2013 14:29:24 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48174EC3@ESESSMB301.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE470307FE6D@eusaamb101.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48163DDB@ESESSMB301.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470308D349@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470308D349@eusaamb101.ericsson.se> 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: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48174EC3ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvja6rVWqQwdmdehZP5txgsfjb8JrF 4vmcmSwWC9Y8ZXdg8Viy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4Mj43tLIWTDrCXjHh03fm Bsb5Z9m6GDk5JARMJI6sucYMYYtJXLi3HijOxSEkcJRRYn3/cVYIZzGjxKq5exi7GDk42ASs JJ4c8gFpEBHQkuh8+50dpIZZ4DGjxKcNzxlBHGGBLkaJp1ePg40SEehmlNh8eS8zSLeIgJPE xYuVIN0sAqoSe46vADuDV8BbontvMyuILSRwmVFizRJrEJtTwE9ic2cfI4jNKCArMWH3IjCb WUBc4taT+UwQZwtILNlzHuoFUYmXj/+xQtiKEjvPtjND1OdL7Ly1lwVil6DEyZlPWCYwis5C MmoWkrJZSMog4noSN6ZOYYOwtSWWLXzNDGHrSsz4d4gFWXwBI/sqRo7i1OKk3HQjg02MwIg7 uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGR/Zn1tLd3 39Us6PRjurk1f2V518+Dx2NLZ21M9/KuKX0+NW9HrMhKzxNuMzrCjhTbvtSZZii1YGPDXsU5 V/6vmp/QuiBk19+7jV7X3RT3fU1ctClfM2Od2/xJazZcd2OSqdAQMpUy5Lp2+0vPXHbdZXsX hi+X/KP3wUVX72O+7xeXWV3ruMWOK7EUZyQaajEXFScCAFiesVOGAgAA Cc: "rtg-dir@ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:30:24 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48174EC3ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Acee, Since today it is the deadline for draft submission we uploaded a version w= ith the changes agreed up to now and the ones proposed in line below. Furth= er modifications, if needed, will be deferred to a new version on Monday No= v 4th. Thanks once again for your review Daniele + Co-authors. From: Acee Lindem Sent: mercoled=EC 16 ottobre 2013 22:20 To: Daniele Ceccarelli Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; rtg-dir@ietf.org; CC= AMP; rtg-ads@tools.ietf.org Subject: Re: RtgDir Review: "Traffic Engineering Extensions to OSPF for Gen= eralized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hi Daniele, See inline. On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrote: Hi Acee, Thanks for the careful review and please find comments/replies in line. BR Daniele (&co-authors) From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: mercoled=EC 9 ottobre 2013 03:41 To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org Cc: rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.or= g Subject: RtgDir Review: "Traffic Engineering Extensions to OSPF for General= ized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please seehttp= ://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ccamp-ospf-g709v3-09.txt Reviewer: Acee Lindem Review Date: October 15th, 2013 IETF LC End Date: October 16, 2013 Intended Status: Proposed Standard Summary: The document is missing some key sections and requires some clarif= ication prior to publication. Comments: Major Issues: The document lacks several critical pieces of information. 1. There is no discussion of OSPF scaling or flooding freq= uency. Even if it not expected that G709 GMPLS signaling will not present any problems, this n= eeds to be stated and justified. Refer to section 8 in RFC 6827 for an example of such a discus= sion. [[Authors]] How about adding a section saying: OSPFv2 scalability considerations and requirements are in line with section= 8 of [RFC6827]. In addition please note that OTN extensions in this docume= nt have been designed taking into consideration optimization criteria ident= ified in [OTN-INFO] It isn't obvious to me that these two extensions are comparable. I think a = separate section pertaining to the OTN extensions would make more sense. [[DC]] The following section has been added: This document does not introduce OSPF scalability issues with respect to existing GMPLS encoding and does not require any modification to flooding frequency. Moreover the design of the encoding has been carried out taking into account bandwidth optimization, and in particular: - Only unreserved and MAX LSP Bandwidth related to supported priorities is advertised - With respect of fixed containers, only the number of available containers is advertised instead of available bandwidth so to use only 16 bits per container instead of 32 (as per former GMPLS encoding In order to further reduce the amount of data advertised it is RECOMMENDED to bundle component links with homogeneous hierarchies as described in [RFC4201] and illustrated in Section 5.6. 2. The document includes lots of normative text indicating= precisely how sub-TLVs MUST be formatted. However, there is no indication of what th= e action to be taken if the TLVs do not follow the strict conventions. [[Authors]] Good comment. Looking at previous OSPF and OSPF-TE drafts we di= dn't find any text on handling of bad TLV formatting. Any suggestion on how= to deal with that is more than welcome. In the past, I've stated that the problem should be logged and the LSA, TLV= , or Sub-TLV MUST NOT be used for TE/GMPLS path computation. It all depends= on what makes sense for the encoding violation and at what level it should= be resolved. One generic solution would be to NOT use any LSAs with encodi= ng violations for GMPLS path computation. [[DC]] This piece of text has been added at the end of section 4: In case a recived LSA is not formatted accordingly to the requir= ements indicated in this document, the problem SHOULD be logged and the wrongly form= atted LSA, TLV or Sub-TLV MUST NOT be used for the path computation until a newer version correc= tly formatted is received. 3. The document jumps down into details of G.709 technolog= y without adequate explanation (particularly in the examples). Either t= hese details need to be removed or a statement of prerequisite knowledge is required. [[Authors]] The reader is supposed to have read [OTN-FWK] and [OTN-INFO]. W= e can add a sentence at the end of the abstract or intro. This is the minimum. Minor Issues: The document had a large number of editorial errors. 1. The bit numbering on all the figures was off by 1 colum= n. If you look at RFC 4203, this will be obvious. [[Author]] Correct. Fixed. 2. The table on page 7 is incomprehensible with the given = columns and headings. Spaces rather than commas in numbers are annoying. [[Author]] Spaces substituted with commas. As per comment above having read= [OTN-FWK] and [OTN-INFO] is a prerequisite. Does it add anything to this document if one needs to look at OTN-FWK and O= TN-INFO anyway? It is much less relevant than, say, a discussion of adverti= sement and scaling ;^) For example, what does 239/238 mean? Is this 239 or 238 separate tributary = slots - why is it variable? What does GFP-F mean - it is not defined here. [[DC]] Table 7 is needed to fill the common header of the ISCD. E.g. when i= ndicating ODU4, the related max lsp bandwidth in the common header of the I= SCD needs to be filled with 0x504331E3. The first and third columns of the table are needed for that, while the sec= ond one explains how the value is Byte/sec is retrieved (i.e. the nominal b= it rate of each ODU). The "239/238" does not mean 239 OR 238 but means 239 = divided by 238. The meaning of GFP-F is explained in the fwk document (defined in G.7041) a= nd stands for Generic Framing Procedure. In addition to the various ODUs th= ere are three more ODU types that need to be advertised, namely: i) ODUflex= for CBR client signals, ii) ODUflex for GFP-F mapped client signal and iii= ) ODU flex resizable. 3. The distinction between TLVs and sub-TLVs is not consis= tent throughout the document. Again, refer to RFC 6827 for an example of consistent= referral. [[Authors]] Good catch. We're defining only sub-tlvs. Fixed. 4. Figures 8 and 9 have the T and S fields offset from the= bit numbering. Also, it took some time to realize that T1 meant a value of 1. [[Authors]] T and S were left intentionally to make the reading easier but = maybe it's not the case. Only 0 and 1 are there now. 5. Figures 11-15 are very inconsistent in that these are examples yet the v= alues for T, S, and sometime TSG are not specified. Rather, the example in= cludes the letters. [[Authors]] The focus of those examples is not T,S and TSG but e.g. ODUflex= advertisement, single stage muxing etc. For each example there is a discla= imer saying: "T, S and TS granularity fields are not relevant to this examp= le". Then wouldn't X's be more relevant than missing discrete values and field l= abels in the same figure? [[DC]] OK. X's used. 6. Security section - RFC 2154 is an experimental RFC that= has heretofore never been commercially implemented or deployed. It is time to q= uit referencing it in draft "Security Considerations". [[Authors]] How about the following? OLD [RFC3630] suggests mechanisms such = as [RFC2154] to protect the transmission of this information... NEW [RFC3630] suggests mechanisms to pr= otect the transmission of this information... It would be great with me. There are plenty of reviewers who will nit pick = the security section... Nits: 1. The proper punctuation is "i.e., " and "e.g. ,". [[Authors]] OK Also, sentences should not start with either. See http://www.rfc-editor.org/rfc-style-guide/rfc-sty= le 2. Page 7, "Switching Capability-Specific Information (SCSI)? [[Authors]] OK 3. Suggest formatting the document so that the figures are= on separate pages rather than split across pages. [[Authors]] I don't know how to do that with the .xml file. Maybe this is a= comment we can leave for the RFC editor? Ok. I have been able to do this with [[DC]] It works fine with all figures except fig 14. It's longer than a pag= e. 3. Replace all occurrences of "non " with "non-" and do not end lines= with "non ". [[Authors]] OK 4. I thought the examples included many run-on sentences t= hat were hard to parse and lacked needed punctuation. I tried to edit but I'm not even = sure if I retained the same meaning. You can get a flavor for what I mean by the diffs below. [[Authors]] OK to all. All modifications you suggest have been implemented. Thanks - I'll look for the update. Thanks, Acee Thanks, Acee 132,133c132,133 < Routing information for Optical Channel Layer (OCh) (i.e. wavelength) < is out of the scope of this document. Please refer to [RFC6163] and --- > Routing information for Optical Channel Layer (OCh) (i.e., wavelength) > is beyond the scope of this document. Please refer to [RFC6163] and 157c157 < As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so --- > As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended 159c159 < related to each different ODUj and ODUk/OTUk (Optical Transport Unit) --- > of each different ODUj and ODUk/OTUk (Optical Transport Unit) 176c176 < In the following we will use ODUj to indicate a service type that is --- > In the following, we will use ODUj to indicate a service type that is 179c179 < the OTUk. Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and --- > the OTUk. Moreover, ODUj(S) and ODUk(S) are used to indicate ODUj and 184c184 < multiplexing levels. In the following the term "multiplexing tree" --- > multiplexing levels. In the following, the term "multiplexing tree" 191c191 < If for example a multiplexing hierarchy like the following one is --- > For example, If a multiplexing hierarchy like the following one is 251c251 < one hop case multiple hop TE-links advertise ODU switching capacity. --- > one hop case, multiple hop TE-links advertise ODU switching capacity. 296,297c296,297 < Both for fixed and flexible ODUs the same switching type and encoding < values MUST be used. When Switching Capability and Encoding fields --- > The same switching type and encoding values must be used for both fixe= d > and flexible ODUs. When Switching Capability and Encoding fields 303,304c303,304 < The MAX LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <= =3D < MAX LSP Bandwidth <=3D ODUk/OTUk and intermediate values are those on --- > The MAX LSP Bandwidth field is used according to [RFC4203]: i.e., 0 <= =3D > MAX LSP Bandwidth <=3D ODUk/OTUk, and intermediate values are those on 306,307c306,307 < E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP < Bandwidth for some priorities, ODU3 for others, ODU2 for some others --- > For example, in the OTU4 link it could be possible to have ODU4 as MAX= LSP > Bandwidth for some priorities, ODU3 for others, ODU2 for some others, 397,398c397,398 < Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non < resizable. Each MUST always be advertised in separate Type 2 TLVs as --- > Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) > non-resizable. Each MUST always be advertised in separate Type 2 TLVs= as 400c400 < both GFP-F resizable and non resizable (i.e. 21 and 22) are --- > both GFP-F resizable and non-resizable (i.e. 21 and 22) are 535c535 < (i.e. a non OTN client). --- > (i.e., a non-OTN client). 540c540 < - Priority (8 bits): a bitmap used to indicate which priorities --- > - Priority (8 bits): A bitmap used to indicate which priorities 542,543c542,543 < leftmost bit representing priority level 0 (i.e. the highest) and < the rightmost bit representing priority level 7 (i.e. the lowest). --- > leftmost bit representing priority level 0 (i.e., the highest) and > the rightmost bit representing priority level 7 (i.e., the lowest). 666c666 < Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD @T0 --- > Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD at T0 676,678c676,678 < At time T1 an ODU3 at priority 2 is set-up, so for priority 0 the MAX < LSP Bandwidth is still equal to the ODU4 bandwidth, while for < priorities from 2 to 7 (excluding the non supported ones) the MAX LSP --- > At time T1, an ODU3 at priority 2 is set-up, so for priority 0 the > MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for > priorities from 2 to 7 (excluding the non-supported ones) the MAX LSP 680c680 < next supported ODUj in the hierarchy is ODU3.The advertisement is --- > next supported ODUj in the hierarchy is ODU3. The advertisement is 710c710 < Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD @T1 --- > Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD at T1 712,714c712,714 < At time T2 an ODU2 at priority 4 is set-up. The first ODU3 is no < longer available since T1 as it was kept by the ODU3 LSP, while the < second is no more available and just 3 ODU2 are left in it. ODU2 is --- > At time T2, an ODU2 at priority 4 is set-up. The first ODU3 is no > longer available since T1, as it was kept by the ODU3 LSP, while the > second is no more available and just 3 ODU2s are left in it. ODU2 is 758c758 < Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD @T2 --- > Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD at T2 762c762 < In this example an interface with Tributary Slot Type 1.25Gbps and --- > In this example, an interface with Tributary Slot Type 1.25Gbps and 766c766 < switched or terminated, the ODU2 can only be terminated and the ODU1 --- > switched or terminated, the ODU2 can only be terminated, and the ODU1 768c768 < advertised to support ODU0 the value of is "ignored" (TS --- > advertised to support ODU0, the value of is "ignored" (TS 770c770 < interface a single ISCD is used and its format is as follows: --- > interface, a single ISCD is used and its format is as follows: 819c819 < In this example two interfaces with homogeneous hierarchies but --- > In this example, two interfaces with homogeneous hierarchies but 822,824c822,824 < one a G.709-2012 interface with fallback procedure disabled (TS < granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy and < priorities 0 and 3. T and S bits values are not relevant to this --- > one supports G.709-2012 interface with fallback procedure disabled > (TS granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy > and priorities 0 and 3. T and S bits values are not relevant to this 826,827c826,827 < interfaces two different ISCDs are used and the format of their SCSIs < is as follows: --- > interfaces, two different ISCDs are used and the format of their > SCSIs is as follows: 903,908c903,908 < with different exported TS granularity MUST be considered as non < homogenous hierarchies is the case in which an H-LPS and the client < LSP are terminated on the same egress node. What can happen is that < a loose Explicit Route Object (ERO) is used at the hop where the < signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate < hop of the LSP). --- > with different exported TS granularity MUST be considered as > non-homogenous hierarchies. This is the case in which an H-LPS and > the client LSP are terminated on the same egress node. What can > happen is that a loose Explicit Route Object (ERO) is used at the > hop where the signaled LSP is nested into the Hierarchical-LSP (H-LSP) > (penultimate hop of the LSP). 912,915c912,915 < if2. In case the H-LSP on if1 exports a TS=3D1.25Gbps and if2 a < TS=3D2.5Gbps and the service LSP being signaled needs a 1.25Gbps < tributary slot, only the H-LSP on if1 can be used to reach node E. < For further details please see section 4.1 of the [OTN-INFO]. --- > if2. In this case, the H-LSP on if1 exports a TS=3D1.25Gbps, if2 a > TS=3D2.5Gbps, the service LSP being signaled needs a 1.25Gbps > tributary slot, and only the H-LSP on if1 can be used to reach node E. > For further details, please see section 4.1 of the [OTN-INFO]. 939,943c939,943 < In this example the advertisement of an ODUflex->ODU3 hierarchy is < shown. In case of ODUflex advertisement the MAX LSP Bandwidth needs < to be advertised and in some cases also information about the < Unreserved bandwidth could be useful. The amount of Unreserved < bandwidth does not give a clear indication of how many ODUflex LSP --- > In this example, the advertisement of an ODUflex->ODU3 hierarchy is > shown. In the case of ODUflex advertisement, the MAX LSP Bandwidth > needs to be advertised and, in some cases, information about the > Unreserved bandwidth could also be useful. The amount of Unreserved > bandwidth does not give a clear indication of how many ODUflex LSPs 959,962c959,962 < Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved < Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex < LSPs of 10 GBps each, have to be restored, for sure only one can be < restored along Link B and it is probable (but not sure) that two of --- > Bandwidth equal to 10 Gbps each. In the case where 50Gbps of Unreserv= ed > Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUflex > LSPs of 10 GBps each have to be restored, for sure only one can be > restored along Link B and it is probable, but not certain, that two of 966c966 < In the case of ODUflex advertisement the Type 2 Bandwidth TLV is --- > In the case of ODUflex advertisement, the Type 2 Bandwidth TLV is 1073c1073 < simplicity we assume that also in this case only priorities 0 and 3 --- > simplicity, we also assume that only priorities 0 and 3 1294c1294 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1388c1388 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1506c1506 < All implementations of this document MAY support also advertisement --- > All implementations of this document MAY also support advertisement 1518c1518 < based on policy and is out of scope of the document. This enables --- > based on policy and beyond the scope of this document. This enables 1537c1537 < [RFC5920] . --- > [RFC5920]. --_000_4A1562797D64E44993C5CBF38CF1BE48174EC3ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Acee,

 <= /p>

Since today it is the dea= dline for draft submission we uploaded a version with the changes agreed up= to now and the ones proposed in line below. Further modifications, if needed, will be deferred to a new version on Monday Nov 4th.=

 <= /p>

Thanks once again for you= r review

 <= /p>

Daniele + Co-authors.=

 <= /p>

From: Acee Lin= dem
Sent: mercoled=EC 16 ottobre 2013 22:20
To: Daniele Ceccarelli
Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; rtg-dir@ietf.= org; CCAMP; rtg-ads@tools.ietf.org
Subject: Re: RtgDir Review: "Traffic Engineering Extensions to = OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks&qu= ot;

 

Hi Daniele,

See inline. 

 

On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrot= e:



Hi Acee,

 <= /p>

Thanks for the careful re= view and please find comments/replies in line.

 <= /p>

BR
Daniele (&co-authors)

 <= /p>

From: Acee Lindem [mailto:acee.lindem@eri= csson.com] 
Sent: mercoled=EC = 9 ottobre 2013 03:41
To: draft-ietf-ccamp-gmp= ls-ospf-g709v3@tools.ietf.org
Cc: rtg-dir@ietf.org; CCAMP; rtg-ads= @tools.ietf.org
Subject: RtgDir Re= view: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GM= PLS) Control of Evolving G.709 OTN Networks"

 

Hello,

 

I have been selected as the Routing Dir= ectorate reviewer for this draft. The Routing Directorate seeks to review a= ll routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purp= ose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please seehttp://www.ietf.or= g/iesg/directorate/routing.html

 

Although these comments are primarily f= or the use of the Routing ADs, it would be helpful if you could consider th= em 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-ospf-g709v3-09.txt

Reviewer: Acee Lindem=

Review Date: October 15th, 2013<= o:p>

IETF LC End Date: October 16, 2013

Intended Status: Proposed Standard = ;

 

Summary: The document is missing some k= ey sections and requires some clarification prior to publication. 

 

Comments:

 

Major Issues: The document lacks severa= l critical pieces of information.   

 

          &nbs= p;      1. There is no discussion of OSPF scaling or floodin= g frequency. Even if it not expected that G709 

          &nbs= p;           GMPLS signaling will not present= any problems, this needs to be stated and justified. Refer to<= /o:p>

          &nbs= p;           section 8 in RFC 6827 for an example = of such a discussion. 

[[Authors]] How abo= ut adding a section saying:

OSPFv2 scalability considerations and requirements are in line w= ith section 8 of [RFC6827]. In addition please note that OTN extensions in this document have been designed taking into consideration o= ptimization criteria identified in [OTN-INFO]

 

It isn't obvious to me that these two extensions are= comparable. I think a separate section pertaining to the OTN extensions wo= uld make more sense. 

 

[[DC]] The followin= g section has been added:

 

This document does not introduce OSPF sca= lability issues with respect
   to existing GMPLS encoding and does not require any modificati= on to
   flooding frequency.  Moreover the design of the encoding = has been
   carried out taking into account bandwidth optimization, and in=
   particular:

      - Only unr= eserved and MAX LSP Bandwidth related to supported
      priorities is advertised

      - With respect of fixed containers, only the= number of available
      containers is advertised instead of availabl= e bandwidth so to use
      only 16 bits per container instead of 32 (as= per former GMPLS
      encoding

   In order to further reduce the amount of data advertised it is=
   RECOMMENDED to bundle component links with homogeneous hierarc= hies as
   described in [RFC4201] and illustrated in Section 5.6.<= o:p>

 <= /p>



          &nbs= p;      2. The document includes lots of normative text= indicating precisely how sub-TLVs MUST be 

          &nbs= p;           formatted. However, there is no = indication of what the action to be taken if the TLVs do<= /p>

          &nbs= p;           not follow the strict conventions.&nb= sp;

[[Authors]] Good co= mment. Looking at previous OSPF and OSPF-TE drafts we didn’t find any= text on handling of bad TLV formatting. Any suggestion on how to deal with that is more than welcome.

 

In the past, I've stated that the problem should be = logged and the LSA, TLV, or Sub-TLV MUST NOT be used for TE/GMPLS path comp= utation. It all depends on what makes sense for the encoding violation and = at what level it should be resolved. One generic solution would be to NOT use any LSAs with encoding violations= for GMPLS path computation. 

 

 

[[DC]] This piece o= f text has been added at the end of section 4:

 

           In c= ase a recived LSA is not formatted accordingly to the requirements indicate= d in

           this= document, the problem SHOULD be logged and the wrongly formatted LSA, TLV = or Sub-TLV MUST NOT

   &= nbsp;          be used for the= path computation until a newer version correctly formatted is received.



          &nbs= p;      3. The document jumps down into details of G.709 tec= hnology without adequate 

          &nbs= p;            explanation (particularly in th= e examples). Either these details need to be removed or a =

          &nbs= p;           statement of prerequisite knowledge i= s required. 

[[Authors]] The rea= der is supposed to have read [OTN-FWK] and [OTN-INFO]. We can add a sentenc= e at the end of the abstract or intro.

 

This is the minimum. 



 <= /p>

Minor Issues: The document had a large = number of editorial errors.

 

          &nbs= p;      1. The bit numbering on all the figures was off by 1= column. If you look at RFC 4203, 

          &nbs= p;           this will be obvious. 

[[Author]] Correct.= Fixed.

          &nbs= p;      2. The table on page 7 is incomprehensible with the = given columns and headings. Spaces 

          &nbs= p;           rather than commas in numbers are ann= oying. 

 

 

[[Author]] Spaces s= ubstituted with commas. As per comment above having read [OTN-FWK] and [OTN= -INFO] is a prerequisite.

 

Does it add anything to this document if one needs t= o look at OTN-FWK and OTN-INFO anyway? It is much less relevant than, say, = a discussion of advertisement and scaling ;^) 

 

For example, what does 239/238 mean? Is this 239 or = 238 separate tributary slots - why is it variable? What does GFP-F mean - i= t is not defined here. 

 

[[=
DC]] Table 7 is needed to fill the common header of the ISCD. E.g. when ind=
icating ODU4, the related max lsp bandwidth in the common header of the ISC=
D needs to be filled with  0x504331E3.
The firs=
t and third columns of the table are needed for that, while the second one =
explains how the value is Byte/sec is retrieved (i.e. the nominal bit rate =
of each ODU). The “239/238” does not mean 239 OR 238 but means =
239 divided by 238.
The mean=
ing of GFP-F is explained in the fwk document (defined in G.7041) and stand=
s for Generic Framing Procedure. In addition to the various ODUs there are =
three more ODU types that need to be advertised, namely: i) ODUflex for CBR=
 client signals, ii) ODUflex for GFP-F mapped client signal and iii) ODU fl=
ex resizable.

          &nbs= p;      3. The distinction between TLVs and sub-TLVs is not = consistent throughout the document. 

          &nbs= p;           Again, refer to RFC 6827 for an examp= le of consistent referral.

[[Authors]] Good ca= tch. We’re defining only sub-tlvs. Fixed.

          &nbs= p;      4. Figures 8 and 9 have the T and S fields offset fr= om the bit numbering. Also, it took 

          &nbs= p;           some time to realize that T1 meant a = value of 1. 

[[Authors]] T and S= were left intentionally to make the reading easier but maybe it’s no= t the case. Only 0 and 1 are there now.

5. Figures = 11-15 are very inconsistent in that these are examples yet the values for T= , S, and  sometime TSG are not specified. Rather, the example includes the letters.  

[[=
Authors]] The focus of those examples is not T,S and TSG but e.g. ODUflex a=
dvertisement, single stage muxing etc. For each example there is a disclaim=
er saying: “T, S and TS granularity fields are not relevant to this example”.

 

Then wouldn't X's be more relevant than missing disc= rete values and field labels in the same figure? 

 

[[DC]] OK. X’= s used.



 

          &nbs= p;      6. Security section - RFC 2154 is an experimental RF= C that has heretofore never been 

          &nbs= p;           commercially implemented or deployed.=  It is time to quit referencing it in draft 

          &nbs= p;           "Security Considerations".&= nbsp;

[[Authors]] How abo= ut the following?

OLD<= o:p>

    [RFC3630] suggests mechanisms such as [RFC2154] to protect

   the transmissio= n of this information…

NEW<= o:p>

    [RFC3630] suggests mechanisms to protect

   the transmissio= n of this information…

 

It would be great with me. There are plenty of revie= wers who will nit pick the security section... 

 



 

  Nits:

1.=        The proper punctuation is "i.e., " and "e.g. ,".  

[[Authors]] OK

Also, sentences should not start with e= ither. 

          &nbs= p;           See http://www.rfc-edit= or.org/rfc-style-guide/rfc-style

2.=        Page 7, "Switching Capability-Specific Information (SCSI)? 

[[Authors]] OK

          &nbs= p;      3. Suggest formatting the document so that the figur= es are on separate pages rather than 

          &nbs= p;           split across pages. =

[[Authors]] I don&#= 8217;t know how to do that with the .xml file. Maybe this is a comment we c= an leave for the RFC editor?

 

Ok. I have been able to do this with 

 

<vspace blankLines=3D"100" />

 

 

[[DC]] It works fin= e with all figures except fig 14. It’s longer than a page.=



3.=        Replace all occurrences of "non " with "non-" and do not end l= ines with "non ". 

[[Authors]] OK

          &nbs= p;      4. I thought the examples included many run-on sente= nces that were hard to parse and lacked

          &nbs= p;           needed punctuation. I tried to edit b= ut I'm not even sure if I retained the same meaning. You <= /o:p>

          &nbs= p;           can get a flavor for what I mean by t= he diffs below. 

[[Authors]] OK to a= ll. All modifications you suggest have been implemented.

 

Thanks - I'll look for the update. <= /p>

 

Thanks,

Acee 

 



 

 

Thanks,

Acee 

132,13= 3c132,133

< &= nbsp;  Routing information for Optical Channel Layer (OCh) (i.e. wavel= ength)

< &= nbsp;  is out of the scope of this document.  Please refer to [RF= C6163] and

---

> &= nbsp;  Routing information for Optical Channel Layer (OCh) (i.e., wave= length)

> &= nbsp;  is beyond the scope of this document.  Please refer to [RF= C6163] and

 

157c15= 7

< &= nbsp;  As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be exten= ded so

---

> &= nbsp;  As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be exten= ded

 

159c15= 9

< &= nbsp;  related to each different ODUj and ODUk/OTUk (Optical Transport= Unit)

---

> &= nbsp;  of each different ODUj and ODUk/OTUk (Optical Transport Unit)

176c17= 6

< &= nbsp;  In the following we will use ODUj to indicate a service type th= at is

---

> &= nbsp;  In the following, we will use ODUj to indicate a service type t= hat is

179c17= 9

< &= nbsp;  the OTUk.  Moreover ODUj(S) and ODUk(S) are used to indica= te ODUj and

---

> &= nbsp;  the OTUk.  Moreover, ODUj(S) and ODUk(S) are used to indic= ate ODUj and

184c18= 4

< &= nbsp;  multiplexing levels.  In the following the term "mult= iplexing tree"

---

> &= nbsp;  multiplexing levels.  In the following, the term "mul= tiplexing tree"

191c19= 1

< &= nbsp;  If for example a multiplexing hierarchy like the following one = is

---

> &= nbsp;  For example, If a multiplexing hierarchy like the following one= is

251c25= 1

< &= nbsp;  one hop case multiple hop TE-links advertise ODU switching capa= city.

---

> &= nbsp;  one hop case, multiple hop TE-links advertise ODU switching cap= acity.

296,29= 7c296,297

< &= nbsp;  Both for fixed and flexible ODUs the same switching type and en= coding

< &= nbsp;  values MUST be used.  When Switching Capability and Encodi= ng fields

---

> &= nbsp;  The same switching type and encoding values must be used for bo= th fixed

> &= nbsp;  and flexible ODUs.  When Switching Capability and Encoding= fields

303,30= 4c303,304

< &= nbsp;  The MAX LSP Bandwidth field is used according to [RFC4203]: i.e= . 0 <=3D

< &= nbsp;  MAX LSP Bandwidth <=3D ODUk/OTUk and intermediate values are= those on

---

> &= nbsp;  The MAX LSP Bandwidth field is used according to [RFC4203]: i.e= ., 0 <=3D

> &= nbsp;  MAX LSP Bandwidth <=3D ODUk/OTUk, and intermediate values ar= e those on

306,30= 7c306,307

< &= nbsp;  E.g. in the OTU4 link it could be possible to have ODU4 as MAX = LSP

< &= nbsp;  Bandwidth for some priorities, ODU3 for others, ODU2 for some o= thers

---

> &= nbsp;  For example, in the OTU4 link it could be possible to have ODU4= as MAX LSP

> &= nbsp;  Bandwidth for some priorities, ODU3 for others, ODU2 for some o= thers, 

397,39= 8c397,398

< &= nbsp;  Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-= F) non

< &= nbsp;  resizable.  Each MUST always be advertised in separate Typ= e 2 TLVs as

---

> &= nbsp;  Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-= F) 

> &= nbsp;  non-resizable.  Each MUST always be advertised in separate= Type 2 TLVs as

400c40= 0

< &= nbsp;  both GFP-F resizable and non resizable (i.e. 21 and 22) are

---

> &= nbsp;  both GFP-F resizable and non-resizable (i.e. 21 and 22) are

535c535

<       (i.e. a non OTN client).=

---

>       (i.e., a non-OTN client).

540c54= 0

< &= nbsp;     - Priority (8 bits): a bitmap used to indicate which pr= iorities

---

> &= nbsp;     - Priority (8 bits): A bitmap used to indicate which pr= iorities

542,54= 3c542,543

< &= nbsp;     leftmost bit representing priority level 0 (i.e. the hi= ghest) and

< &= nbsp;     the rightmost bit representing priority level 7 (i.e. t= he lowest).

---

> &= nbsp;     leftmost bit representing priority level 0 (i.e., the h= ighest) and

> &= nbsp;     the rightmost bit representing priority level 7 (i.e., = the lowest).

666c66= 6

< &= nbsp;     Figure 5: Example 1 - MAX LSP Bandwidth fields in the I= SCD @T0

---

> &= nbsp;     Figure 5: Example 1 - MAX LSP Bandwidth fields in the I= SCD at T0

676,67= 8c676,678

< &= nbsp;  At time T1 an ODU3 at priority 2 is set-up, so for priority 0 t= he MAX

< &= nbsp;  LSP Bandwidth is still equal to the ODU4 bandwidth, while for

< &= nbsp;  priorities from 2 to 7 (excluding the non supported ones) the M= AX LSP

---

> &= nbsp;  At time T1, an ODU3 at priority 2 is set-up, so for priority 0 = the

> &= nbsp;  MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while f= or

> &= nbsp;  priorities from 2 to 7 (excluding the non-supported ones) the M= AX LSP

680c68= 0

< &= nbsp;  next supported ODUj in the hierarchy is ODU3.The advertisement = is

---

> &= nbsp;  next supported ODUj in the hierarchy is ODU3. The advertisement= is

710c71= 0

< &= nbsp;     Figure 6: Example 1 - MAX LSP Bandwidth fields in the I= SCD @T1

---

> &= nbsp;     Figure 6: Example 1 - MAX LSP Bandwidth fields in the I= SCD at T1

712,71= 4c712,714

< &= nbsp;  At time T2 an ODU2 at priority 4 is set-up.  The first ODU= 3 is no

< &= nbsp;  longer available since T1 as it was kept by the ODU3 LSP, while= the

< &= nbsp;  second is no more available and just 3 ODU2 are left in it. &nb= sp;ODU2 is

---

> &= nbsp;  At time T2, an ODU2 at priority 4 is set-up.  The first OD= U3 is no

> &= nbsp;  longer available since T1, as it was kept by the ODU3 LSP, whil= e the

> &= nbsp;  second is no more available and just 3 ODU2s are left in it. &n= bsp;ODU2 is

758c75= 8

< &= nbsp;     Figure 7: Example 1 - MAX LSP Bandwidth fields in the I= SCD @T2

---

> &= nbsp;     Figure 7: Example 1 - MAX LSP Bandwidth fields in the I= SCD at T2

762c76= 2

< &= nbsp;  In this example an interface with Tributary Slot Type 1.25Gbps = and

---

> &= nbsp;  In this example, an interface with Tributary Slot Type 1.25Gbps= and

766c76= 6

< &= nbsp;  switched or terminated, the ODU2 can only be terminated and the= ODU1

---

> &= nbsp;  switched or terminated, the ODU2 can only be terminated, and th= e ODU1

768c76= 8

< &= nbsp;  advertised to support ODU0 the value of is "ignored" = (TS

---

> &= nbsp;  advertised to support ODU0, the value of is "ignored"= (TS

770c77= 0

< &= nbsp;  interface a single ISCD is used and its format is as follows:

---

> &= nbsp;  interface, a single ISCD is used and its format is as follows:<= /span>

819c81= 9

< &= nbsp;  In this example two interfaces with homogeneous hierarchies but=

---

> &= nbsp;  In this example, two interfaces with homogeneous hierarchies bu= t

822,82= 4c822,824

< &= nbsp;  one a G.709-2012 interface with fallback procedure disabled (TS=

< &= nbsp;  granularity=3D3).  Both of them support ODU1->ODU2->= ODU3 hierarchy and

< &= nbsp;  priorities 0 and 3.  T and S bits values are not relevant = to this

---

> &= nbsp;  one supports G.709-2012 interface with fallback procedure disab= led

> &= nbsp;  (TS granularity=3D3).  Both of them support ODU1->ODU2-= >ODU3 hierarchy

> &= nbsp;  and priorities 0 and 3.  T and S bits values are not relev= ant to this

826,82= 7c826,827

< &= nbsp;  interfaces two different ISCDs are used and the format of their= SCSIs

< &= nbsp;  is as follows:

---

> &= nbsp;  interfaces, two different ISCDs are used and the format of thei= r 

> &= nbsp;  SCSIs is as follows:

903,90= 8c903,908

< &= nbsp;  with different exported TS granularity MUST be considered as no= n

< &= nbsp;  homogenous hierarchies is the case in which an H-LPS and the cl= ient

< &= nbsp;  LSP are terminated on the same egress node.  What can happ= en is that

< &= nbsp;  a loose Explicit Route Object (ERO) is used at the hop where th= e

< &= nbsp;  signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penul= timate

< &= nbsp;  hop of the LSP).

---

> &= nbsp;  with different exported TS granularity MUST be considered as&nb= sp;

> &= nbsp;  non-homogenous hierarchies. This is the case in which an H-LPS = and 

> &= nbsp;  the client LSP are terminated on the same egress node.  Wh= at can 

> &= nbsp;  happen is that a loose Explicit Route Object (ERO) is used at t= he 

> &= nbsp;  hop where the signaled LSP is nested into the Hierarchical-LSP = (H-LSP)

> &= nbsp;  (penultimate hop of the LSP).

912,91= 5c912,915

< &= nbsp;  if2.  In case the H-LSP on if1 exports a TS=3D1.25Gbps and= if2 a

< &= nbsp;  TS=3D2.5Gbps and the service LSP being signaled needs a 1.25Gbp= s

< &= nbsp;  tributary slot, only the H-LSP on if1 can be used to reach node= E.

< &= nbsp;  For further details please see section 4.1 of the [OTN-INFO].

---

> &= nbsp;  if2.  In this case, the H-LSP on if1 exports a TS=3D1.25Gb= ps, if2 a

> &= nbsp;  TS=3D2.5Gbps, the service LSP being signaled needs a 1.25Gbps

> &= nbsp;  tributary slot, and only the H-LSP on if1 can be used to reach = node E.

> &= nbsp;  For further details, please see section 4.1 of the [OTN-INFO].<= /span>

939,94= 3c939,943

< &= nbsp;  In this example the advertisement of an ODUflex->ODU3 hierar= chy is

< &= nbsp;  shown.  In case of ODUflex advertisement the MAX LSP Bandw= idth needs

< &= nbsp;  to be advertised and in some cases also information about the

< &= nbsp;  Unreserved bandwidth could be useful.  The amount of Unres= erved

< &= nbsp;  bandwidth does not give a clear indication of how many ODUflex = LSP

---

> &= nbsp;  In this example, the advertisement of an ODUflex->ODU3 hiera= rchy is

> &= nbsp;  shown.  In the case of ODUflex advertisement, the MAX LSP = Bandwidth

> &= nbsp;  needs to be advertised and, in some cases, information about th= e

> &= nbsp;  Unreserved bandwidth could also be useful.  The amount of = Unreserved

> &= nbsp;  bandwidth does not give a clear indication of how many ODUflex = LSPs

959,96= 2c959,962

< &= nbsp;  Bandwidth equal to 10 Gbps each.  In case 50Gbps of Unrese= rved

< &= nbsp;  Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUfl= ex

< &= nbsp;  LSPs of 10 GBps each, have to be restored, for sure only one ca= n be

< &= nbsp;  restored along Link B and it is probable (but not sure) that tw= o of

---

> &= nbsp;  Bandwidth equal to 10 Gbps each.  In the case where 50Gbps= of Unreserved

> &= nbsp;  Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUf= lex

> &= nbsp;  LSPs of 10 GBps each have to be restored, for sure only one can= be

> &= nbsp;  restored along Link B and it is probable, but not certain, that= two of

966c96= 6

< &= nbsp;  In the case of ODUflex advertisement the Type 2 Bandwidth TLV i= s

---

> &= nbsp;  In the case of ODUflex advertisement, the Type 2 Bandwidth TLV = is

1073c1= 073

< &= nbsp;  simplicity we assume that also in this case only priorities 0 a= nd 3

---

> &= nbsp;  simplicity, we also assume that only priorities 0 and 3<= /span>

1294c1= 294

< &= nbsp;  In this example 2 OTU4 component links with the same supported = TS

---

> &= nbsp;  In this example, 2 OTU4 component links with the same supported= TS

1388c1= 388

< &= nbsp;  In this example 2 OTU4 component links with the same supported = TS

---

> &= nbsp;  In this example, 2 OTU4 component links with the same supported= TS

1506c1= 506

< &= nbsp;  All implementations of this document MAY support also advertise= ment

---

> &= nbsp;  All implementations of this document MAY also support advertise= ment

1518c1= 518

< &= nbsp;  based on policy and is out of scope of the document.  This= enables

---

> &= nbsp;  based on policy and beyond the scope of this document.  Th= is enables

1537c1= 537

< &= nbsp;  [RFC5920] .

---

> &= nbsp;  [RFC5920].

 

 

          &nbs= p;     

          &nbs= p;     

 

 

--_000_4A1562797D64E44993C5CBF38CF1BE48174EC3ESESSMB301ericsso_-- From manav.bhatia@alcatel-lucent.com Mon Oct 21 08:20:26 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945EC11E83F2; Mon, 21 Oct 2013 08:20: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=[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 9DPC4h6COwjv; Mon, 21 Oct 2013 08:20:19 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8204F11E81B5; Mon, 21 Oct 2013 08:20:18 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9LFKFXC022033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Oct 2013 10:20:16 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r9LFKEBc030679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 11:20:15 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 21 Oct 2013 11:20:15 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Mon, 21 Oct 2013 23:20:12 +0800 From: "Bhatia, Manav (Manav)" To: "huubatwork@gmail.com" , "rtg-ads@tools.ietf.org" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJn4XogAgAb4cPA= Date: Mon, 21 Oct 2013 15:20:11 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4E6CED@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> <525FDDBA.1010306@gmail.com> In-Reply-To: <525FDDBA.1010306@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 15:20:26 -0000 SSBzYXcgdGhlIHJldmlzZWQgSUQgYW5kIHRoZSBjaGFuZ2VzIGxvb2sgZ29vZC4NCg0KQ2hlZXJz LCBNYW5hdg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSHV1YiB2YW4gSGVs dm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgT2N0 b2JlciAxNywgMjAxMyA2OjIzIFBNDQpUbzogQmhhdGlhLCBNYW5hdiAoTWFuYXYpOyBydGctYWRz QHRvb2xzLmlldGYub3JnDQpDYzogcnRnLWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXRw LXJvc2V0dGEtc3RvbmUuYWxsQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbXBscy10cC1yb3NldHRhLXN0 b25lLTEyLnR4dA0KDQpIZWxsbyBNYW5hdiwNCg0KWW91IHdyb3RlOg0KDQo+IEkgaGF2ZSBiZWVu IHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRy YWZ0Lg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3Lg0KDQpJIHdpbGwgYWRkcmVzcyBhbGwg eW91ciBjb21tZW50cyBpbiB0aGUgbmV4dCBzcGluIG9mIHRoZSBkcmFmdC4NCg0KSSBvbmx5IHdh bnQgdG8gYnJpbmcgc29tZSBjbGFyaWZpY2F0aW9uIHRvIHlvdXIgcHJvcG9zYWw6DQoNCj4gbykg SW4gMy43LCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gbWVudGlvbiB0aGF0IGFuIGltcG9ydGFudA0K ID4gcHJvcGVydHkgb2YgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgcGF0aCBpcyB0aGF0IHRoZSBm b3J3YXJkICA+IGFuZCBiYWNrd2FyZCBkaXJlY3Rpb25zIHNoYXJlIGZhdGUuDQogPiBTaW1pbGFy bHksIGluIDMuMSwgd2Ugc2hvdWxkIG1lbnRpb24gdGhhdCB0aGUgZm9yd2FyZCBhbmQgID4gYmFj a3dhcmQgZGlyZWN0aW9ucyBkb24ndCBzaGFyZSBmYXRlLg0KDQoNCkZhdGUtc2hhcmluZyBpcyBO T1QgYSByZXF1aXJlbWVudCBmb3IgY28tcm91dGVkIGJpLWRpcmVjdGlvbmFsIHBhdGhzLiAgSXQg aXMgb25seSBhIHNlY29uZGFyeSBlZmZlY3QuDQpFLmcuIGluIGEgY2FibGUgb25seSBvbmUgb2Yg dGhlIGZpYmVycyBjYW4gZmFpbC9icmVhaywgc2FtZSBmb3IgaW50ZXJuYWwgcG9ydHMgaW4gcm91 dGVycywgYXMgd2VsbCBhcyBmb3J3YXJkaW5nLg0KDQpUaGUgbWFpbiByZXF1aXJlbWVudHMgZm9y IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZToNCj09IGZvbGxvdyBleGFjdGx5IHRo ZSBzYW1lIHBhdGggaS5lLiBwaHlzaWNhbCBzZWN0aW9ucywgYW5kDQogICAgbm9kZXMgaW4gYm90 aCBkaXJlY3Rpb25zDQo9PSB0aGUgTUVQUyBhdCB0aGUgZW5kLXBvaW50cyBjYW4gY29tbXVuaWNh dGUgZGlyZWN0bHkgdmlhDQogICAgdGhlIFJJIChyZW1vdGUgaW50ZXJmYWNlKSBOT1QgdmlhIHRo ZSBtYW5hZ2VtZW50IHBsYW5lID09IGR1cmluZyBhIHByb3RlY3Rpb24gc3dpdGNoIGJvdGggZGly ZWN0aW9ucyBhcmUgc3dpdGNoZWQNCiAgICAoYXQgdGhlIHNhbWUgdGltZSkgZnJvbSB3b3JraW5n IGVudGl0eSB0byBwcm90ZWN0aW9uIGVudGl0eS4NCj09IGJvdGggYXJlIG1hbmFnZWQgYXMgYSBz aW5nbGUgZW50aXR5DQoNClRoZSBvbmx5IGZhdGUtc2hhcmluZyByZXF1aXJlbWVudCBpbiBJVFUt VCBpcyBmb3IgT0FNIHBhY2tldHMgYW5kIGRhdGEgcGFja2V0cyB0cmFuc3BvcnRlZCBiZXR3ZWVu IHRoZSBzYW1lIGVuZHBvaW50cyBTZWUgdGhlIGZpcnN0IHBhcmFncmFwaCBpbiBjbGF1c2VzIDYu NCBhbmQgNy4xIG9mIEcuODExMy4xIGFuZCBHLjgxMTMuMi4NCg0KVG8gcmVzb2x2ZSB5b3VyIHBv aW50IEkgY2FuIGFkZCB0ZXh0IHRvIDMuNyB0aGF0IGJvdGggZGlyZWN0aW9ucyBhcmUgbWFuYWdl ZCBhbmQgb3BlcmF0ZWQgYXMgYSBzaW5nbGUgZW50aXR5OyBhbmQgaW4gMy4xIHRoYXQgdGhleSBu ZWVkIG5vdCBiZSBhIHNpbmdsZSBtYW5hZ2VtZW50IGFuZCBvcGVyYXRpb25hbCBlbnRpdHkuDQoN Cg0KLS0NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQogICAgICAgICAgICAgICDor7forrDkvY/vvIzkvaDmmK/ni6zkuIDm l6DkuoznmoTvvIzlsLHlg4/lhbbku5bmr4/kuIDkuKrkurrkuIDmoLcNCg== From adrian@olddog.co.uk Fri Oct 25 06:18:39 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B1F11E83FD; Fri, 25 Oct 2013 06:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_05=-1.11] 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 B0UAh0xxZx7p; Fri, 25 Oct 2013 06:18:33 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBDE11E8402; Fri, 25 Oct 2013 06:18:26 -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 r9PDIMIR012599; Fri, 25 Oct 2013 14:18:22 +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 r9PDIJtc012527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Oct 2013 14:18:19 +0100 From: "Adrian Farrel" To: , , Date: Fri, 25 Oct 2013 14:18:15 +0100 Message-ID: <156e01ced184$ab51dc00$01f59400$@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: Ac7RhKJzdtqNMoEyR3G9ujyo+LidTw== Content-Language: en-gb Cc: stbryant@cisco.com Subject: [RTG-DIR] Reminder : Routing ADs Open Office : Vancouver X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 13:18:39 -0000 Hi, The room will be called Lord Byron. > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 07 October 2013 18:39 > To: routing-discussion@ietf.org; rtgarea-chairs@tools.ietf.org; rtg-dir@ietf.org > Cc: stbryant@cisco.com > Subject: [RTG-DIR] Routing ADs Open Office : Vancouver > > Hi, > > In a break with tradition, we will hold office hours at lunch on Thursday. > > Venue will be the IESG break-out room (to be announced). > > Sorry in advance that you may have to watch the ADs eat! > > Adrian and Stewart. From adrian@olddog.co.uk Fri Oct 25 06:25:32 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E1011E8192; Fri, 25 Oct 2013 06:25:32 -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 CRjpGECUje43; Fri, 25 Oct 2013 06:25:21 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 27F1C11E83F3; Fri, 25 Oct 2013 06:25:17 -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 r9PDPGtT030907; Fri, 25 Oct 2013 14:25:16 +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 r9PDPFrg030899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Oct 2013 14:25:16 +0100 From: "Adrian Farrel" To: , , Date: Fri, 25 Oct 2013 14:25:11 +0100 Message-ID: <157601ced185$a27400d0$e75c0270$@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: Ac7RhUuL8WHLv4HBRj+zcJHzodCY3Q== Content-Language: en-gb Subject: [RTG-DIR] Topics for Routing Area meeting X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 13:25:32 -0000 Hi, Does anyone have a topic they want to cover in this meeting? Let us know. Adrian and Stewart. From abdussalambaryun@gmail.com Sat Oct 26 01:40:24 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B8C11E80F9; Sat, 26 Oct 2013 01:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 mWvPln4UTytx; Sat, 26 Oct 2013 01:40:23 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EAD1E21E8064; Sat, 26 Oct 2013 01:40:21 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so5461024pbc.17 for ; Sat, 26 Oct 2013 01:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zcMJe+tXmxZt5fU95PZNFA4rsA3WEN/r62QsByXS1go=; b=X9fslwgI7BrdVwuOqd7j+VIPAu5+2rSJBEKxjLYCQQ1rsuRwjF5SQ4Y4tyiaK5oX/K je20rZRdNBQj1G0Yps58lnNxZ9Or1yETs26jfEInc85zYq9RerZFrc5B5wkEWOgNnm6D l3NW1co8NeUOsZNdqgw/jaF5IvSbtWpGb6KhOeTmeDu2NtTg6tgDcuCzdAe+6VJ8QNKh 59jm9+3NQDqPCHYbWsQ8tm+ae4mGCzN13N2R7SUxfwrscwKiuSd1OkvJVfy5ku9xdFed SawT1+fk2ZymdLVro9UgSEd267iqpPWpmf5du4Z4N2nwLJJBK35aofGdZagN1zMngeMO EhnA== MIME-Version: 1.0 X-Received: by 10.66.227.39 with SMTP id rx7mr15195970pac.44.1382776821579; Sat, 26 Oct 2013 01:40:21 -0700 (PDT) Received: by 10.69.8.5 with HTTP; Sat, 26 Oct 2013 01:40:21 -0700 (PDT) In-Reply-To: <157601ced185$a27400d0$e75c0270$@olddog.co.uk> References: <157601ced185$a27400d0$e75c0270$@olddog.co.uk> Date: Sat, 26 Oct 2013 09:40:21 +0100 Message-ID: From: Abdussalam Baryun To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=047d7b111f3f4106b604e9a0d146 X-Mailman-Approved-At: Sat, 26 Oct 2013 09:23:09 -0700 Cc: "rtg-dir@ietf.org" , "routing-discussion@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Topics for Routing Area meeting X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 08:40:24 -0000 --047d7b111f3f4106b604e9a0d146 Content-Type: text/plain; charset=ISO-8859-1 If you mean anyone including remote participants, I have an issue not sure about within routing area, which is the cross WG issues do we leave it to ADs to advise or do WGs Chairs should take over this task and discuss cross issues, or participants/editor should consider this while developing I-Ds and presentations. Some people in IETF are concerned to compare our standards with other SDOs while developing I-Ds within IETF, I think we need more cross-WG considerations within developing standards and WG-charters. AB On Friday, October 25, 2013, Adrian Farrel wrote: > Hi, > > Does anyone have a topic they want to cover in this meeting? > > Let us know. > > Adrian and Stewart. > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > --047d7b111f3f4106b604e9a0d146 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you mean anyone including remote participants, I have an issue not sure = about within routing area,=A0which is the cross WG issues do we leave it to= ADs to advise=A0or do WGs Chairs should take over this task and discuss cr= oss issues, or participants/editor should consider this while developing I-= Ds and presentations.

Some people in IETF are concerned=A0to compare our standards= with other SDOs while developing I-Ds=A0within IETF, I think=A0we need mor= e cross-WG considerations within developing standards and WG-charters.
<= div>
AB

On Friday, October 25, 2013, Adrian Farrel wrote:=
Hi,

Does anyone have a topic they want to cover in this meeting?

Let us know.

Adrian and Stewart.

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion
--047d7b111f3f4106b604e9a0d146-- From adrian@olddog.co.uk Sat Oct 26 09:31:53 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABD511E81A1; Sat, 26 Oct 2013 09:31:53 -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.025, 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 n1Vcv6c-zCLQ; Sat, 26 Oct 2013 09:31:48 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E621F9F2D; Sat, 26 Oct 2013 09:31:47 -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 r9QGVgJT004082; Sat, 26 Oct 2013 17:31:42 +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 r9QGVf80004067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 26 Oct 2013 17:31:41 +0100 From: "Adrian Farrel" To: "'Abdussalam Baryun'" References: <157601ced185$a27400d0$e75c0270$@olddog.co.uk> In-Reply-To: Date: Sat, 26 Oct 2013 17:31:37 +0100 Message-ID: <170e01ced268$d82d6b10$88884130$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_170F_01CED271.39F44410" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKqBJqdcWpUwCTETd+Fr63vlHEN+wGBigLrmES6TMA= Content-Language: en-gb Cc: rtg-dir@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Topics for Routing Area meeting X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 16:31:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_170F_01CED271.39F44410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, It is good of you to be interested. In the Area meeting I think we are looking for topics of technical substance that span the Routing Area. For example, in London we are promised a talk from the Management AD on the importance of considering management concerns when documenting routing protocols. In a sense, that is exactly the sort of cross-area issue you are talking about. But I think the specific topic you are raising (i.e., what cross-area review and discussion is need and how should we cause it to happen) could be handled more profitably by an email discussion on the routing-discussion@ietf.org list if it is specific to either RTG review of documents produced in other areas, or other-area review of documents produced in RTG. Obviously, the widest version of this topic (any-to-any cross-area review) belongs on the main IETF list. Adrian From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 26 October 2013 09:40 To: adrian@olddog.co.uk Cc: routing-discussion@ietf.org; rtg-chairs@ietf.org; rtg-dir@ietf.org Subject: Re: Topics for Routing Area meeting If you mean anyone including remote participants, I have an issue not sure about within routing area, which is the cross WG issues do we leave it to ADs to advise or do WGs Chairs should take over this task and discuss cross issues, or participants/editor should consider this while developing I-Ds and presentations. Some people in IETF are concerned to compare our standards with other SDOs while developing I-Ds within IETF, I think we need more cross-WG considerations within developing standards and WG-charters. AB On Friday, October 25, 2013, Adrian Farrel wrote: Hi, Does anyone have a topic they want to cover in this meeting? Let us know. Adrian and Stewart. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion ------=_NextPart_000_170F_01CED271.39F44410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It is good of you to be = interested.

 

In the Area meeting I think we = are looking for topics of technical substance that span the Routing = Area. For example, in London we are promised a talk from the Management = AD on the importance of considering management concerns when documenting = routing protocols.

 

In a sense, that is exactly = the sort of cross-area issue you are talking about. But I think the = specific topic you are raising (i.e., what cross-area review and = discussion is need and how should we cause it to happen) could be = handled more profitably by an email discussion on the = routing-discussion@ietf.org list if it is specific to either RTG review = of documents produced in other areas, or other-area review of documents = produced in RTG. Obviously, the widest version of this topic (any-to-any = cross-area review) belongs on the main IETF = list.

 

Adrian

 

From: Abdussalam Baryun = [mailto:abdussalambaryun@gmail.com]
Sent: 26 October 2013 = 09:40
To: adrian@olddog.co.uk
Cc: = routing-discussion@ietf.org; rtg-chairs@ietf.org; = rtg-dir@ietf.org
Subject: Re: Topics for Routing Area = meeting

 

If you mean = anyone including remote participants, I have an issue not sure about = within routing area, which is the cross WG issues do we leave it to = ADs to advise or do WGs Chairs should take over this task and = discuss cross issues, or participants/editor should consider this while = developing I-Ds and presentations.

 

Some people in IETF are concerned to compare our = standards with other SDOs while developing I-Ds within IETF, I = think we need more cross-WG considerations within developing = standards and WG-charters.

 

AB

On Friday, October 25, 2013, Adrian Farrel = wrote:

Hi,

Does anyone have a = topic they want to cover in this meeting?

Let us = know.

Adrian and = Stewart.

_______________________________________________
routin= g-discussion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussio= n

------=_NextPart_000_170F_01CED271.39F44410-- From acee.lindem@ericsson.com Mon Oct 28 09:01:40 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF1211E8260; Mon, 28 Oct 2013 09:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, GB_I_LETTER=-2, 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 sF-hWq7SZFSx; Mon, 28 Oct 2013 09:01:30 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECAF11E8160; Mon, 28 Oct 2013 09:00:51 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-0b-526e8a314de6 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4D.DB.03458.13A8E625; Mon, 28 Oct 2013 17:00:49 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Mon, 28 Oct 2013 12:00:38 -0400 From: Acee Lindem To: Daniele Ceccarelli Thread-Topic: RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Thread-Index: AQHOxJCn0+iFqto7ekGiQXMkyXw9jZn0UizAgAPB1YCAByQB8IALb5KA Date: Mon, 28 Oct 2013 16:00:37 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030AE876@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE470307FE6D@eusaamb101.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48163DDB@ESESSMB301.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470308D349@eusaamb101.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48174EC3@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48174EC3@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47030AE876eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXRPlK5hV16QwZSFmhZP5txgsfjb8JrF 4vmcmSwWC9Y8ZXdg8Viy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4Mu69WcdasPMNV8XPRcfZ Ghh3LuDsYuTkkBAwkVg/5TA7hC0mceHeejYQW0jgCKNE+4+gLkYuIHs5o8TbqdPBEmwCOhLP H/1jBrFFBCwkuo49ZgUpYhZ4zCjxacNzRpCEsEAXo8SivewgCRGBbkaJzZf3QnW4ScxYvpgJ xGYRUJW40j0RaCoHB6+Ar8TXV04Q26YySUw6vxpsG6eAj8T6OZ9YQGxGoPO+n1oD1sssIC5x 68l8JoizBSSW7DnPDGGLSrx8/I8VwlaWWPJkPwtEfb7E9YdTwGxeAUGJkzOfsExgFJ2FZNQs JGWzkJRBxA0k3p+bzwxha0ssW/gaytaX2PjlLCOEbS2xYEI/K7KaBYwcqxg5SotTy3LTjQw3 MQIj8ZgEm+MOxgWfLA8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0Sf9 4OMnS/RfFy/ev0f2puM6vbRbvVXzf8xQfKXC9Iqn//2+BWXSHqvX6HVpHn0+pXhzt5oez2rP ZWJqT3O8pyw+OGESm7GvSuWWi9qv7qv6dYZN7Vl7O3d9yKSSRylBx/YfcCr9anM44Mr0+P9/ GTctPz4t2cCwqkxjv29/TuGziHC1BSVzhZVYijMSDbWYi4oTAQ/C3gSSAgAA Cc: "rtg-dir@ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:01:40 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030AE876eusaamb101erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Daniele, I looked at the update and it is greatly improved. I'd still recommend the = following issues be addressed. 1. In section 4, you state the malformed LSA, TLV, or Sub-TLV is igno= red. Since this specification describes sub-TLVs, does that imply that only= the sub-TLVs are ignored when malformed? This is how I'd interpret it. 2. In examples where you used "X" to denote that the field is not appl= icable, you should state that. Or at least state it somewhere. Also some edits on the new text: 130c130,131 < provided in [OTN-INFO]. --- > provided in [OTN-INFO]. The reader is assumed to be familiar with > both of these documents. 136,138d136 < The reader is supposed to be familiar with OTN framework [OTN-FWK] < and GMPLS evaluation against OTN [OTN-INFO]. < 320c318 < is shown in the table below (please note that there are 1000 bits in --- > are shown in the table below (please note that there are 1000 bits in 369,373c367,370 < In case a recived LSA is not formatted accordingly to the < requirements indicated in this document, the problem SHOULD be logged < and the wrongly formatted LSA, TLV or Sub-TLV MUST NOT be used for < the path computation until a newer version correctly formatted is < received. --- > When a received LSA is not formatted accordingly to the precise > specifications in this document, the problem SHOULD be logged > and the wrongly formatted LSA, TLV, or Sub-TLV MUST NOT be used for > path computation. 1561c1558 < flooding frequency. Moreover the design of the encoding has been --- > flooding frequency. Moreover, the design of the encoding has been 1573c1570 < priorities is advertised --- > priorities are advertised. 1575,1578c1572,1575 < - With respect of fixed containers, only the number of available < containers is advertised instead of available bandwidth so to use < only 16 bits per container instead of 32 (as per former GMPLS < encoding --- > - With respect to fixed containers, only the number of available > containers is advertised instead of available bandwidth so that > only 16 bits per container are used instead of 32 (as per the > former GMPLS encoding). 1580c1577 < In order to further reduce the amount of data advertised it is --- > In order to further reduce the amount of data advertised, it is Thanks, Acee P.S. I still think it would be better not to reference RFC 2154 in the "Sec= urity Considerations". RFC 6837 has a much better example for OSPF TE than = RFC 3630. On Oct 21, 2013, at 10:29 AM, Daniele Ceccarelli wrote: Hi Acee, Since today it is the deadline for draft submission we uploaded a version w= ith the changes agreed up to now and the ones proposed in line below. Furth= er modifications, if needed, will be deferred to a new version on Monday No= v 4th. Thanks once again for your review Daniele + Co-authors. From: Acee Lindem Sent: mercoled=EC 16 ottobre 2013 22:20 To: Daniele Ceccarelli Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.org Subject: Re: RtgDir Review: "Traffic Engineering Extensions to OSPF for Gen= eralized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hi Daniele, See inline. On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrote: Hi Acee, Thanks for the careful review and please find comments/replies in line. BR Daniele (&co-authors) From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: mercoled=EC 9 ottobre 2013 03:41 To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org Cc: rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.or= g Subject: RtgDir Review: "Traffic Engineering Extensions to OSPF for General= ized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please seehttp= ://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ccamp-ospf-g709v3-09.txt Reviewer: Acee Lindem Review Date: October 15th, 2013 IETF LC End Date: October 16, 2013 Intended Status: Proposed Standard Summary: The document is missing some key sections and requires some clarif= ication prior to publication. Comments: Major Issues: The document lacks several critical pieces of information. 1. There is no discussion of OSPF scaling or flooding freq= uency. Even if it not expected that G709 GMPLS signaling will not present any problems, this n= eeds to be stated and justified. Refer to section 8 in RFC 6827 for an example of such a discus= sion. [[Authors]] How about adding a section saying: OSPFv2 scalability considerations and requirements are in line with section= 8 of [RFC6827]. In addition please note that OTN extensions in this docume= nt have been designed taking into consideration optimization criteria ident= ified in [OTN-INFO] It isn't obvious to me that these two extensions are comparable. I think a = separate section pertaining to the OTN extensions would make more sense. [[DC]] The following section has been added: This document does not introduce OSPF scalability issues with respect to existing GMPLS encoding and does not require any modification to flooding frequency. Moreover the design of the encoding has been carried out taking into account bandwidth optimization, and in particular: - Only unreserved and MAX LSP Bandwidth related to supported priorities is advertised - With respect of fixed containers, only the number of available containers is advertised instead of available bandwidth so to use only 16 bits per container instead of 32 (as per former GMPLS encoding In order to further reduce the amount of data advertised it is RECOMMENDED to bundle component links with homogeneous hierarchies as described in [RFC4201] and illustrated in Section 5.6. 2. The document includes lots of normative text indicating= precisely how sub-TLVs MUST be formatted. However, there is no indication of what th= e action to be taken if the TLVs do not follow the strict conventions. [[Authors]] Good comment. Looking at previous OSPF and OSPF-TE drafts we di= dn=92t find any text on handling of bad TLV formatting. Any suggestion on h= ow to deal with that is more than welcome. In the past, I've stated that the problem should be logged and the LSA, TLV= , or Sub-TLV MUST NOT be used for TE/GMPLS path computation. It all depends= on what makes sense for the encoding violation and at what level it should= be resolved. One generic solution would be to NOT use any LSAs with encodi= ng violations for GMPLS path computation. [[DC]] This piece of text has been added at the end of section 4: In case a recived LSA is not formatted accordingly to the requir= ements indicated in this document, the problem SHOULD be logged and the wrongly form= atted LSA, TLV or Sub-TLV MUST NOT be used for the path computation until a newer version correc= tly formatted is received. 3. The document jumps down into details of G.709 technolog= y without adequate explanation (particularly in the examples). Either t= hese details need to be removed or a statement of prerequisite knowledge is required. [[Authors]] The reader is supposed to have read [OTN-FWK] and [OTN-INFO]. W= e can add a sentence at the end of the abstract or intro. This is the minimum. Minor Issues: The document had a large number of editorial errors. 1. The bit numbering on all the figures was off by 1 colum= n. If you look at RFC 4203, this will be obvious. [[Author]] Correct. Fixed. 2. The table on page 7 is incomprehensible with the given = columns and headings. Spaces rather than commas in numbers are annoying. [[Author]] Spaces substituted with commas. As per comment above having read= [OTN-FWK] and [OTN-INFO] is a prerequisite. Does it add anything to this document if one needs to look at OTN-FWK and O= TN-INFO anyway? It is much less relevant than, say, a discussion of adverti= sement and scaling ;^) For example, what does 239/238 mean? Is this 239 or 238 separate tributary = slots - why is it variable? What does GFP-F mean - it is not defined here. [[DC]] Table 7 is needed to fill the common header of the ISCD. E.g. when i= ndicating ODU4, the related max lsp bandwidth in the common header of the I= SCD needs to be filled with 0x504331E3. The first and third columns of the table are needed for that, while the sec= ond one explains how the value is Byte/sec is retrieved (i.e. the nominal b= it rate of each ODU). The =93239/238=94 does not mean 239 OR 238 but means = 239 divided by 238. The meaning of GFP-F is explained in the fwk document (defined in G.7041) a= nd stands for Generic Framing Procedure. In addition to the various ODUs th= ere are three more ODU types that need to be advertised, namely: i) ODUflex= for CBR client signals, ii) ODUflex for GFP-F mapped client signal and iii= ) ODU flex resizable. 3. The distinction between TLVs and sub-TLVs is not consis= tent throughout the document. Again, refer to RFC 6827 for an example of consistent= referral. [[Authors]] Good catch. We=92re defining only sub-tlvs. Fixed. 4. Figures 8 and 9 have the T and S fields offset from the= bit numbering. Also, it took some time to realize that T1 meant a value of 1. [[Authors]] T and S were left intentionally to make the reading easier but = maybe it=92s not the case. Only 0 and 1 are there now. 5. Figures 11-15 are very inconsistent in that these are examples yet the v= alues for T, S, and sometime TSG are not specified. Rather, the example in= cludes the letters. [[Authors]] The focus of those examples is not T,S and TSG but e.g. ODUflex= advertisement, single stage muxing etc. For each example there is a discla= imer saying: =93T, S and TS granularity fields are not relevant to this exa= mple=94. Then wouldn't X's be more relevant than missing discrete values and field l= abels in the same figure? [[DC]] OK. X=92s used. 6. Security section - RFC 2154 is an experimental RFC that= has heretofore never been commercially implemented or deployed. It is time to q= uit referencing it in draft "Security Considerations". [[Authors]] How about the following? OLD [RFC3630] suggests mechanisms such = as [RFC2154] to protect the transmission of this information=85 NEW [RFC3630] suggests mechanisms to pr= otect the transmission of this information=85 It would be great with me. There are plenty of reviewers who will nit pick = the security section... Nits: 1. The proper punctuation is "i.e., " and "e.g. ,". [[Authors]] OK Also, sentences should not start with either. See http://www.rfc-editor.org/rfc-style-guide/rfc-sty= le 2. Page 7, "Switching Capability-Specific Information (SCSI)? [[Authors]] OK 3. Suggest formatting the document so that the figures are= on separate pages rather than split across pages. [[Authors]] I don=92t know how to do that with the .xml file. Maybe this is= a comment we can leave for the RFC editor? Ok. I have been able to do this with [[DC]] It works fine with all figures except fig 14. It=92s longer than a p= age. 3. Replace all occurrences of "non " with "non-" and do not end lines= with "non ". [[Authors]] OK 4. I thought the examples included many run-on sentences t= hat were hard to parse and lacked needed punctuation. I tried to edit but I'm not even = sure if I retained the same meaning. You can get a flavor for what I mean by the diffs below. [[Authors]] OK to all. All modifications you suggest have been implemented. Thanks - I'll look for the update. Thanks, Acee Thanks, Acee 132,133c132,133 < Routing information for Optical Channel Layer (OCh) (i.e. wavelength) < is out of the scope of this document. Please refer to [RFC6163] and --- > Routing information for Optical Channel Layer (OCh) (i.e., wavelength) > is beyond the scope of this document. Please refer to [RFC6163] and 157c157 < As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so --- > As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended 159c159 < related to each different ODUj and ODUk/OTUk (Optical Transport Unit) --- > of each different ODUj and ODUk/OTUk (Optical Transport Unit) 176c176 < In the following we will use ODUj to indicate a service type that is --- > In the following, we will use ODUj to indicate a service type that is 179c179 < the OTUk. Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and --- > the OTUk. Moreover, ODUj(S) and ODUk(S) are used to indicate ODUj and 184c184 < multiplexing levels. In the following the term "multiplexing tree" --- > multiplexing levels. In the following, the term "multiplexing tree" 191c191 < If for example a multiplexing hierarchy like the following one is --- > For example, If a multiplexing hierarchy like the following one is 251c251 < one hop case multiple hop TE-links advertise ODU switching capacity. --- > one hop case, multiple hop TE-links advertise ODU switching capacity. 296,297c296,297 < Both for fixed and flexible ODUs the same switching type and encoding < values MUST be used. When Switching Capability and Encoding fields --- > The same switching type and encoding values must be used for both fixe= d > and flexible ODUs. When Switching Capability and Encoding fields 303,304c303,304 < The MAX LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <= =3D < MAX LSP Bandwidth <=3D ODUk/OTUk and intermediate values are those on --- > The MAX LSP Bandwidth field is used according to [RFC4203]: i.e., 0 <= =3D > MAX LSP Bandwidth <=3D ODUk/OTUk, and intermediate values are those on 306,307c306,307 < E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP < Bandwidth for some priorities, ODU3 for others, ODU2 for some others --- > For example, in the OTU4 link it could be possible to have ODU4 as MAX= LSP > Bandwidth for some priorities, ODU3 for others, ODU2 for some others, 397,398c397,398 < Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non < resizable. Each MUST always be advertised in separate Type 2 TLVs as --- > Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) > non-resizable. Each MUST always be advertised in separate Type 2 TLVs= as 400c400 < both GFP-F resizable and non resizable (i.e. 21 and 22) are --- > both GFP-F resizable and non-resizable (i.e. 21 and 22) are 535c535 < (i.e. a non OTN client). --- > (i.e., a non-OTN client). 540c540 < - Priority (8 bits): a bitmap used to indicate which priorities --- > - Priority (8 bits): A bitmap used to indicate which priorities 542,543c542,543 < leftmost bit representing priority level 0 (i.e. the highest) and < the rightmost bit representing priority level 7 (i.e. the lowest). --- > leftmost bit representing priority level 0 (i.e., the highest) and > the rightmost bit representing priority level 7 (i.e., the lowest). 666c666 < Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD @T0 --- > Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD at T0 676,678c676,678 < At time T1 an ODU3 at priority 2 is set-up, so for priority 0 the MAX < LSP Bandwidth is still equal to the ODU4 bandwidth, while for < priorities from 2 to 7 (excluding the non supported ones) the MAX LSP --- > At time T1, an ODU3 at priority 2 is set-up, so for priority 0 the > MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for > priorities from 2 to 7 (excluding the non-supported ones) the MAX LSP 680c680 < next supported ODUj in the hierarchy is ODU3.The advertisement is --- > next supported ODUj in the hierarchy is ODU3. The advertisement is 710c710 < Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD @T1 --- > Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD at T1 712,714c712,714 < At time T2 an ODU2 at priority 4 is set-up. The first ODU3 is no < longer available since T1 as it was kept by the ODU3 LSP, while the < second is no more available and just 3 ODU2 are left in it. ODU2 is --- > At time T2, an ODU2 at priority 4 is set-up. The first ODU3 is no > longer available since T1, as it was kept by the ODU3 LSP, while the > second is no more available and just 3 ODU2s are left in it. ODU2 is 758c758 < Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD @T2 --- > Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD at T2 762c762 < In this example an interface with Tributary Slot Type 1.25Gbps and --- > In this example, an interface with Tributary Slot Type 1.25Gbps and 766c766 < switched or terminated, the ODU2 can only be terminated and the ODU1 --- > switched or terminated, the ODU2 can only be terminated, and the ODU1 768c768 < advertised to support ODU0 the value of is "ignored" (TS --- > advertised to support ODU0, the value of is "ignored" (TS 770c770 < interface a single ISCD is used and its format is as follows: --- > interface, a single ISCD is used and its format is as follows: 819c819 < In this example two interfaces with homogeneous hierarchies but --- > In this example, two interfaces with homogeneous hierarchies but 822,824c822,824 < one a G.709-2012 interface with fallback procedure disabled (TS < granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy and < priorities 0 and 3. T and S bits values are not relevant to this --- > one supports G.709-2012 interface with fallback procedure disabled > (TS granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy > and priorities 0 and 3. T and S bits values are not relevant to this 826,827c826,827 < interfaces two different ISCDs are used and the format of their SCSIs < is as follows: --- > interfaces, two different ISCDs are used and the format of their > SCSIs is as follows: 903,908c903,908 < with different exported TS granularity MUST be considered as non < homogenous hierarchies is the case in which an H-LPS and the client < LSP are terminated on the same egress node. What can happen is that < a loose Explicit Route Object (ERO) is used at the hop where the < signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate < hop of the LSP). --- > with different exported TS granularity MUST be considered as > non-homogenous hierarchies. This is the case in which an H-LPS and > the client LSP are terminated on the same egress node. What can > happen is that a loose Explicit Route Object (ERO) is used at the > hop where the signaled LSP is nested into the Hierarchical-LSP (H-LSP) > (penultimate hop of the LSP). 912,915c912,915 < if2. In case the H-LSP on if1 exports a TS=3D1.25Gbps and if2 a < TS=3D2.5Gbps and the service LSP being signaled needs a 1.25Gbps < tributary slot, only the H-LSP on if1 can be used to reach node E. < For further details please see section 4.1 of the [OTN-INFO]. --- > if2. In this case, the H-LSP on if1 exports a TS=3D1.25Gbps, if2 a > TS=3D2.5Gbps, the service LSP being signaled needs a 1.25Gbps > tributary slot, and only the H-LSP on if1 can be used to reach node E. > For further details, please see section 4.1 of the [OTN-INFO]. 939,943c939,943 < In this example the advertisement of an ODUflex->ODU3 hierarchy is < shown. In case of ODUflex advertisement the MAX LSP Bandwidth needs < to be advertised and in some cases also information about the < Unreserved bandwidth could be useful. The amount of Unreserved < bandwidth does not give a clear indication of how many ODUflex LSP --- > In this example, the advertisement of an ODUflex->ODU3 hierarchy is > shown. In the case of ODUflex advertisement, the MAX LSP Bandwidth > needs to be advertised and, in some cases, information about the > Unreserved bandwidth could also be useful. The amount of Unreserved > bandwidth does not give a clear indication of how many ODUflex LSPs 959,962c959,962 < Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved < Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex < LSPs of 10 GBps each, have to be restored, for sure only one can be < restored along Link B and it is probable (but not sure) that two of --- > Bandwidth equal to 10 Gbps each. In the case where 50Gbps of Unreserv= ed > Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUflex > LSPs of 10 GBps each have to be restored, for sure only one can be > restored along Link B and it is probable, but not certain, that two of 966c966 < In the case of ODUflex advertisement the Type 2 Bandwidth TLV is --- > In the case of ODUflex advertisement, the Type 2 Bandwidth TLV is 1073c1073 < simplicity we assume that also in this case only priorities 0 and 3 --- > simplicity, we also assume that only priorities 0 and 3 1294c1294 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1388c1388 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1506c1506 < All implementations of this document MAY support also advertisement --- > All implementations of this document MAY also support advertisement 1518c1518 < based on policy and is out of scope of the document. This enables --- > based on policy and beyond the scope of this document. This enables 1537c1537 < [RFC5920] . --- > [RFC5920]. --_000_94A203EA12AECE4BA92D42DBFFE0AE47030AE876eusaamb101erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Daniele, 
I looked at the update and it is greatly improved. I'd still recommend= the following issues be addressed. 

     1. In section 4, you state the malformed LSA, TLV,= or Sub-TLV  is ignored. Since this specification describes sub-TLVs, = does that imply that only the sub-TLVs are ignored when malformed? This is = how I'd interpret it. 
     2. In examples where you used "X" to den= ote that the field is not applicable, you should state that. Or at least st= ate it somewhere. 

Also some edits on the new text:


130c130,131
<    provided in [OTN-INFO].
---
>    provided in [OTN-INFO].  The reader is assumed = to be familiar with
>    both of these documents. 
136,138d136
<    The reader is supposed to be familiar with OTN frame= work [OTN-FWK]
<    and GMPLS evaluation against OTN [OTN-INFO].
< 
320c318
<    is shown in the table below (please note that there = are 1000 bits in
---
>    are shown in the table below (please note that there= are 1000 bits in
369,373c367,370
<    In case a recived LSA is not formatted accordingly t= o the
<    requirements indicated in this document, the problem= SHOULD be logged
<    and the wrongly formatted LSA, TLV or Sub-TLV MUST N= OT be used for
<    the path computation until a newer version correctly= formatted is
<    received.
---
>    When a received LSA is not formatted accordingly to = the precise 
>    specifications in this document, the problem SHOULD = be logged
>    and the wrongly formatted LSA, TLV, or Sub-TLV MUST = NOT be used for
>    path computation.
1561c1558
<    flooding frequency.  Moreover the design of the= encoding has been
---
>    flooding frequency.  Moreover, the design of th= e encoding has been
1573c1570
<       priorities is advertised
---
>       priorities are advertised.
1575,1578c1572,1575
<       - With respect of fixed containers, only the= number of available
<       containers is advertised instead of availabl= e bandwidth so to use
<       only 16 bits per container instead of 32 (as= per former GMPLS
<       encoding
---
>       - With respect to fixed containers, only the= number of available
>       containers is advertised instead of availabl= e bandwidth so that
>       only 16 bits per container are used instead = of 32 (as per the
>       former GMPLS encoding).
1580c1577
<    In order to further reduce the amount of data advert= ised it is
---
>    In order to further reduce the amount of data advert= ised, it is


Thanks,
Acee
P.S. I still think it would be better not to reference RFC 2154 in the= "Security Considerations". RFC 6837 has a much better example fo= r OSPF TE than RFC 3630.

On Oct 21, 2013, at 10:29 AM, Daniele Ceccarelli wrote:

Hi Acee,
 
Since today it is the deadline for draft submission we up= loaded a version with the changes agreed up to now and the ones proposed in= line below. Further modifications, if needed, will be deferred to a new version on Monday Nov 4th.=
 
Thanks once again for your review
 
Daniele + Co-authors.
 
 
Hi Daniele,
See inline. 
 
On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrote:


Hi Acee,
 
Thanks for the careful review and please find comments/re= plies in line.
 
BR
Daniele (&co-authors)
 
 
Hello= ,
 = ;
I hav= e been selected as the Routing Directorate reviewer for this draft. The Rou= ting Directorate seeks to review all routing or routing-related drafts as t= hey pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review i= s to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please seehtt= p://www.ietf.org/iesg/directorate/routing.html
 = ;
Altho= ugh these comments are primarily for the use of the Routing ADs, it would b= e helpful if you could consider them along with any other IETF Last Call co= mments that you receive, and strive to resolve them through discussion or by updating the draft.
 = ;
Docum= ent: draft-ietf-ccamp-ospf-g70= 9v3-09.txt
Revie= wer: Acee Lindem
Revie= w Date: October 15th, 2013
IETF = LC End Date: October 16, 2013
Inten= ded Status: Proposed Standard 
 = ;
Summa= ry: The document is missing some key sections and requires some clarificati= on prior to publication. 
 = ;
Comme= nts:
 = ;
Major= Issues: The document lacks several critical pieces of information.  &= nbsp;
 = ;
 = ;                1. There is no dis= cussion of OSPF scaling or flooding frequency. Even if it not expected that= G709 
 = ;                     GMP= LS signaling will not present any problems, this needs to be stated an= d justified. Refer to
 = ;                     sec= tion 8 in RFC 6827 for an example of such a discussion. 
[[Authors]] How about adding a section saying:
OSPFv2 scalability considerations and requirements = are in line with section 8 of [RFC6827]. In addition please note that OTN e= xtensions in this document have been designed taking into consideration optimization criteria identified in [OT= N-INFO]
 
It isn't obvious to me that these two extensions are comparable. I think a = separate section pertaining to the OTN extensions would make more sense.&nb= sp;
 
[[DC]] The following section has been added:
 

This document does not introdu= ce OSPF scalability issues with respect
   to existing GMPLS encoding and does not require any modificati= on to
   flooding frequency.  Moreover the design of the encoding = has been
   carried out taking into account bandwidth optimization, and in=
   particular:

     = - Only unreserved and MAX LSP Bandwidth related to supported
      priorities is advertised

      - With respect of fixed containers, only the= number of available
      containers is advertised instead of availabl= e bandwidth so to use
      only 16 bits per container instead of 32 (as= per former GMPLS
      encoding

   In order to further reduce the amount of data advertised it is=
   RECOMMENDED to bundle component links with homogeneous hierarc= hies as
   described in [RFC4201] and illustrated in Section 5.6.<= o:p>

 


 = ;                2. The document in= cludes lots of normative text indicating precisely how sub-TLVs M= UST be 
 = ;                     for= matted. However, there is no indication of what the action to be taken= if the TLVs do
 = ;                     not= follow the strict conventions. 
[[Authors]] Good comment. Looking at previous OSPF = and OSPF-TE drafts we didn=92t find any text on handling of bad TLV formatt= ing. Any suggestion on how to deal with that is more than welcome.
 
In the past, I've stated that the problem should be logged and the LSA, TLV= , or Sub-TLV MUST NOT be used for TE/GMPLS path computation. It all depends= on what makes sense for the encoding violation and at what level it should= be resolved. One generic solution would be to NOT use any LSAs with encoding violations for GMPLS path compu= tation. 
 
 
[[DC]] This piece of text has been added at the end= of section 4:
 
        &nb= sp;  In case a recived LSA is not formatted accordingly to the require= ments indicated in
        &nb= sp;  this document, the problem SHOULD be logged and the wrongly forma= tted LSA, TLV or Sub-TLV MUST NOT
        &nb= sp;     be used for the path computation until a newer = version correctly formatted is received.


 = ;                3. The document ju= mps down into details of G.709 technology without adequate 
 = ;                     &nb= sp;explanation (particularly in the examples). Either these details ne= ed to be removed or a 
 = ;                     sta= tement of prerequisite knowledge is required. 
[[Authors]] The reader is supposed to have read [OT= N-FWK] and [OTN-INFO]. We can add a sentence at the end of the abstract or = intro.
 
This is the minimum. 


 
Minor= Issues: The document had a large number of editorial errors.
 = ;
 = ;                1. The bit numberi= ng on all the figures was off by 1 column. If you look at RFC 4203, 
 = ;                     thi= s will be obvious. 
[[Author]] Correct. Fixed.
 = ;                2. The table on pa= ge 7 is incomprehensible with the given columns and headings. Spaces <= /span>
 = ;                     rat= her than commas in numbers are annoying. 
 
 
[[Author]] Spaces substituted with commas. As per c= omment above having read [OTN-FWK] and [OTN-INFO] is a prerequisite.=
 
Does it add anything to this document if one needs to look at OTN-FWK and O= TN-INFO anyway? It is much less relevant than, say, a discussion of adverti= sement and scaling ;^) 
 
For example, what does 239/238 mean? Is this 239 or 238 separate tributary = slots - why is it variable? What does GFP-F mean - it is not defined here.&= nbsp;
 
[[DC]] Table 7 is needed to fill t=
he common header of the ISCD. E.g. when indicating ODU4, the related max ls=
p bandwidth in the common header of the ISCD needs to be filled with  =
0x504331E3.<=
o:p>
The first and third columns of the table=
 are needed for that, while the second one explains how the value is Byte/s=
ec is retrieved (i.e. the nominal bit rate of each ODU). The =93239/238=94 =
does not mean 239 OR 238 but means 239 divided by 238.

The meaning of GFP-F is explained in the=
 fwk document (defined in G.7041) and stands for Generic Framing Procedure.=
 In addition to the various ODUs there are three more ODU types that need t=
o be advertised, namely: i) ODUflex for CBR client signals, ii) ODUflex for=
 GFP-F mapped client signal and iii) ODU flex resizable.
 = ;                3. The distinction= between TLVs and sub-TLVs is not consistent throughout the document. =
 = ;                     Aga= in, refer to RFC 6827 for an example of consistent referral.
[[Authors]] Good catch. We=92re defining only sub-t= lvs. Fixed.
 = ;                4. Figures 8 and 9= have the T and S fields offset from the bit numbering. Also, it took =
 = ;                     som= e time to realize that T1 meant a value of 1. 
[[Authors]] T and S were left intentionally to make= the reading easier but maybe it=92s not the case. Only 0 and 1 are there n= ow.
5. Fi= gures 11-15 are very inconsistent in that these are examples yet the values= for T, S, and  sometime TSG are not specified. Rather, the example in= cludes the letters.  
[[Authors]] The focus of those exa=
mples is not T,S and TSG but e.g. ODUflex advertisement, single stage muxin=
g etc. For each example there is a disclaimer saying: =93T, S and TS granularity fields=
 are not relevant to this example=94.=
 
Then wouldn't X's be more relevant than missing discrete values and field l= abels in the same figure? 
 
[[DC]] OK. X=92s used.


 = ;
 = ;                6. Security sectio= n - RFC 2154 is an experimental RFC that has heretofore never been 
 = ;                     com= mercially implemented or deployed. It is time to quit referencing it i= n draft 
 = ;                     &qu= ot;Security Considerations". 
[[Authors]] How about the following?=
OLD
    [RFC3630] suggests mechanisms such =
as [RFC2154] to protect
   the= transmission of this information=85
NEW
    [RFC3630] suggests mechanisms to pr=
otect
   the= transmission of this information=85
 
It would be great with me. There are plenty of reviewers who will nit pick = the security section... 
 


 = ;
 = ; Nits:
1.       The proper punctuation i= s "i.e., " and "e.g. ,".  
[[Authors]] OK
Also,= sentences should not start with either. 
 = ;                     See=  http://www.rfc-editor.org/= rfc-style-guide/rfc-style
2.       Page 7, "Switching = Capability-Specific Information (SCSI)? 
[[Authors]] OK
 = ;                3. Suggest formatt= ing the document so that the figures are on separate pages rather than = ;
 = ;                     spl= it across pages. 
[[Authors]] I don=92t know how to do that with the = .xml file. Maybe this is a comment we can leave for the RFC editor?<= /i>
 
Ok. I have been able to do this with 
 
<vspace blankLines=3D"100" />
 
 
[[DC]] It works fine with all figures except fig 14= . It=92s longer than a page.


3.       Replace all occurrences of "non " with "non-" and do not end lines with "= non ". 
[[Authors]] OK
 = ;                4. I thought the e= xamples included many run-on sentences that were hard to parse and lacked
 = ;                     nee= ded punctuation. I tried to edit but I'm not even sure if I retained the sa= me meaning. You 
 = ;                     can= get a flavor for what I mean by the diffs below. 
[[Authors]] OK to all. All modifications you sugges= t have been implemented.
 
Thanks - I'll look for the update. 
 
Thanks,
Acee 
 


 = ;
 = ;
Thank= s,
Acee&= nbsp;
132,133c132,133
<    Routing information for Optic= al Channel Layer (OCh) (i.e. wavelength)
<    is out of the scope of this d= ocument.  Please refer to [RFC6163] and
---
>    Routing information for Optic= al Channel Layer (OCh) (i.e., wavelength)
>    is beyond the scope of this d= ocument.  Please refer to [RFC6163] and
 
157c157
<    As discussed in [OTN-FWK] and= [OTN-INFO], OSPF-TE must be extended so
---
>    As discussed in [OTN-FWK] and= [OTN-INFO], OSPF-TE must be extended
 
159c159
<    related to each different ODU= j and ODUk/OTUk (Optical Transport Unit)
---
>    of each different ODUj and OD= Uk/OTUk (Optical Transport Unit)
176c176
<    In the following we will use = ODUj to indicate a service type that is
---
>    In the following, we will use= ODUj to indicate a service type that is
179c179
<    the OTUk.  Moreover ODUj= (S) and ODUk(S) are used to indicate ODUj and
---
>    the OTUk.  Moreover, ODU= j(S) and ODUk(S) are used to indicate ODUj and
184c184
<    multiplexing levels.  In= the following the term "multiplexing tree"
---
>    multiplexing levels.  In= the following, the term "multiplexing tree"
191c191
<    If for example a multiplexing= hierarchy like the following one is
---
>    For example, If a multiplexin= g hierarchy like the following one is
251c251
<    one hop case multiple hop TE-= links advertise ODU switching capacity.
---
>    one hop case, multiple hop TE= -links advertise ODU switching capacity.
296,297c296,297
<    Both for fixed and flexible O= DUs the same switching type and encoding
<    values MUST be used.  Wh= en Switching Capability and Encoding fields
---
>    The same switching type and e= ncoding values must be used for both fixed
>    and flexible ODUs.  When= Switching Capability and Encoding fields
303,304c303,304
<    The MAX LSP Bandwidth field i= s used according to [RFC4203]: i.e. 0 <=3D
<    MAX LSP Bandwidth <=3D ODU= k/OTUk and intermediate values are those on
---
>    The MAX LSP Bandwidth field i= s used according to [RFC4203]: i.e., 0 <=3D
>    MAX LSP Bandwidth <=3D ODU= k/OTUk, and intermediate values are those on
306,307c306,307
<    E.g. in the OTU4 link it coul= d be possible to have ODU4 as MAX LSP
<    Bandwidth for some priorities= , ODU3 for others, ODU2 for some others
---
>    For example, in the OTU4 link= it could be possible to have ODU4 as MAX LSP
>    Bandwidth for some priorities= , ODU3 for others, ODU2 for some others, 
397,398c397,398
<    Procedure-Frame mapped (GFP-F= ) resizable and 22 - ODUflex (GFP-F) non
<    resizable.  Each MUST al= ways be advertised in separate Type 2 TLVs as
---
>    Procedure-Frame mapped (GFP-F= ) resizable and 22 - ODUflex (GFP-F) 
>    non-resizable.  Each MUS= T always be advertised in separate Type 2 TLVs as<= /div>
400c400
<    both GFP-F resizable and non = resizable (i.e. 21 and 22) are
---
>    both GFP-F resizable and non-= resizable (i.e. 21 and 22) are
535c535
<       (i.e. a n= on OTN client).
---
>       (i.e., a = non-OTN client).
540c540
<       - Priority (8 bits): = a bitmap used to indicate which priorities
---
>       - Priority (8 bits): = A bitmap used to indicate which priorities
542,543c542,543
<       leftmost bit represen= ting priority level 0 (i.e. the highest) and
<       the rightmost bit rep= resenting priority level 7 (i.e. the lowest).
---
>       leftmost bit represen= ting priority level 0 (i.e., the highest) and
>       the rightmost bit rep= resenting priority level 7 (i.e., the lowest).
666c666
<       Figure 5: Example 1 -= MAX LSP Bandwidth fields in the ISCD @T0
---
>       Figure 5: Example 1 -= MAX LSP Bandwidth fields in the ISCD at T0
676,678c676,678
<    At time T1 an ODU3 at priorit= y 2 is set-up, so for priority 0 the MAX
<    LSP Bandwidth is still equal = to the ODU4 bandwidth, while for
<    priorities from 2 to 7 (exclu= ding the non supported ones) the MAX LSP
---
>    At time T1, an ODU3 at priori= ty 2 is set-up, so for priority 0 the
>    MAX LSP Bandwidth is still eq= ual to the ODU4 bandwidth, while for
>    priorities from 2 to 7 (exclu= ding the non-supported ones) the MAX LSP
680c680
<    next supported ODUj in the hi= erarchy is ODU3.The advertisement is
---
>    next supported ODUj in the hi= erarchy is ODU3. The advertisement is
710c710
<       Figure 6: Example 1 -= MAX LSP Bandwidth fields in the ISCD @T1
---
>       Figure 6: Example 1 -= MAX LSP Bandwidth fields in the ISCD at T1
712,714c712,714
<    At time T2 an ODU2 at priorit= y 4 is set-up.  The first ODU3 is no
<    longer available since T1 as = it was kept by the ODU3 LSP, while the
<    second is no more available a= nd just 3 ODU2 are left in it.  ODU2 is
---
>    At time T2, an ODU2 at priori= ty 4 is set-up.  The first ODU3 is no
>    longer available since T1, as= it was kept by the ODU3 LSP, while the
>    second is no more available a= nd just 3 ODU2s are left in it.  ODU2 is
758c758
<       Figure 7: Example 1 -= MAX LSP Bandwidth fields in the ISCD @T2
---
>       Figure 7: Example 1 -= MAX LSP Bandwidth fields in the ISCD at T2
762c762
<    In this example an interface = with Tributary Slot Type 1.25Gbps and
---
>    In this example, an interface= with Tributary Slot Type 1.25Gbps and
766c766
<    switched or terminated, the O= DU2 can only be terminated and the ODU1
---
>    switched or terminated, the O= DU2 can only be terminated, and the ODU1
768c768
<    advertised to support ODU0 th= e value of is "ignored" (TS
---
>    advertised to support ODU0, t= he value of is "ignored" (TS
770c770
<    interface a single ISCD is us= ed and its format is as follows:
---
>    interface, a single ISCD is u= sed and its format is as follows:
819c819
<    In this example two interface= s with homogeneous hierarchies but
---
>    In this example, two interfac= es with homogeneous hierarchies but
822,824c822,824
<    one a G.709-2012 interface wi= th fallback procedure disabled (TS
<    granularity=3D3).  Both = of them support ODU1->ODU2->ODU3 hierarchy and
<    priorities 0 and 3.  T a= nd S bits values are not relevant to this
---
>    one supports G.709-2012 inter= face with fallback procedure disabled
>    (TS granularity=3D3).  B= oth of them support ODU1->ODU2->ODU3 hierarchy
>    and priorities 0 and 3.  = ;T and S bits values are not relevant to this
826,827c826,827
<    interfaces two different ISCD= s are used and the format of their SCSIs
<    is as follows:<= o:p>
---
>    interfaces, two different ISC= Ds are used and the format of their 
>    SCSIs is as follows:
903,908c903,908
<    with different exported TS gr= anularity MUST be considered as non
<    homogenous hierarchies is the= case in which an H-LPS and the client
<    LSP are terminated on the sam= e egress node.  What can happen is that
<    a loose Explicit Route Object= (ERO) is used at the hop where the
<    signaled LSP is nested into t= he Hierarchical-LSP (H-LSP) (penultimate
<    hop of the LSP).
---
>    with different exported TS gr= anularity MUST be considered as 
>    non-homogenous hierarchies. T= his is the case in which an H-LPS and 
>    the client LSP are terminated= on the same egress node.  What can 
>    happen is that a loose Explic= it Route Object (ERO) is used at the 
>    hop where the signaled LSP is= nested into the Hierarchical-LSP (H-LSP)
>    (penultimate hop of the LSP).=
912,915c912,915
<    if2.  In case the H-LSP = on if1 exports a TS=3D1.25Gbps and if2 a
<    TS=3D2.5Gbps and the service = LSP being signaled needs a 1.25Gbps
<    tributary slot, only the H-LS= P on if1 can be used to reach node E.
<    For further details please se= e section 4.1 of the [OTN-INFO].
---
>    if2.  In this case, the = H-LSP on if1 exports a TS=3D1.25Gbps, if2 a
>    TS=3D2.5Gbps, the service LSP= being signaled needs a 1.25Gbps
>    tributary slot, and only the = H-LSP on if1 can be used to reach node E.
>    For further details, please s= ee section 4.1 of the [OTN-INFO].
939,943c939,943
<    In this example the advertise= ment of an ODUflex->ODU3 hierarchy is
<    shown.  In case of ODUfl= ex advertisement the MAX LSP Bandwidth needs
<    to be advertised and in some = cases also information about the
<    Unreserved bandwidth could be= useful.  The amount of Unreserved
<    bandwidth does not give a cle= ar indication of how many ODUflex LSP
---
>    In this example, the advertis= ement of an ODUflex->ODU3 hierarchy is
>    shown.  In the case of O= DUflex advertisement, the MAX LSP Bandwidth
>    needs to be advertised and, i= n some cases, information about the
>    Unreserved bandwidth could al= so be useful.  The amount of Unreserved
>    bandwidth does not give a cle= ar indication of how many ODUflex LSPs
959,962c959,962
<    Bandwidth equal to 10 Gbps ea= ch.  In case 50Gbps of Unreserved
<    Bandwidth are available on Li= nk A, 10Gbps on Link B and 3 ODUflex
<    LSPs of 10 GBps each, have to= be restored, for sure only one can be
<    restored along Link B and it = is probable (but not sure) that two of
---
>    Bandwidth equal to 10 Gbps ea= ch.  In the case where 50Gbps of Unreserved
>    Bandwidth are available on Li= nk A, 10Gbps on Link B, and 3 ODUflex
>    LSPs of 10 GBps each have to = be restored, for sure only one can be
>    restored along Link B and it = is probable, but not certain, that two of
966c966
<    In the case of ODUflex advert= isement the Type 2 Bandwidth TLV is
---
>    In the case of ODUflex advert= isement, the Type 2 Bandwidth TLV is
1073c1073
<    simplicity we assume that als= o in this case only priorities 0 and 3
---
>    simplicity, we also assume th= at only priorities 0 and 3
1294c1294
<    In this example 2 OTU4 compon= ent links with the same supported TS
---
>    In this example, 2 OTU4 compo= nent links with the same supported TS
1388c1388
<    In this example 2 OTU4 compon= ent links with the same supported TS
---
>    In this example, 2 OTU4 compo= nent links with the same supported TS
1506c1506
<    All implementations of this d= ocument MAY support also advertisement
---
>    All implementations of this d= ocument MAY also support advertisement
1518c1518
<    based on policy and is out of= scope of the document.  This enables
---
>    based on policy and beyond th= e scope of this document.  This enables
1537c1537
<    [RFC5920] .
---
>    [RFC5920].=
 = ;
 = ;
 = ;               <= /div>
 = ;               <= /div>
 = ;
 

--_000_94A203EA12AECE4BA92D42DBFFE0AE47030AE876eusaamb101erics_-- From daniele.ceccarelli@ericsson.com Tue Oct 29 09:48:43 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B491111E81A8; Tue, 29 Oct 2013 09:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.975 X-Spam-Level: X-Spam-Status: No, score=-4.975 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FRT_LOLITA1=1.865, GB_I_LETTER=-2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=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 8FS9MzTQddAd; Tue, 29 Oct 2013 09:47:36 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC0111E81B9; Tue, 29 Oct 2013 09:35:55 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-cb-526fe3e6db86 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6C.15.16099.6E3EF625; Tue, 29 Oct 2013 17:35:50 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.27]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 17:35:50 +0100 From: Daniele Ceccarelli To: Acee Lindem Thread-Topic: RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Thread-Index: AQHOxJCn0+iFqto7ekGiQXMkyXw9jZn0UizAgAPB1YCAByQB8IALb5KAgAE+r/A= Date: Tue, 29 Oct 2013 16:35:49 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4817FBE0@ESESSMB301.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE470307FE6D@eusaamb101.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48163DDB@ESESSMB301.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470308D349@eusaamb101.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48174EC3@ESESSMB301.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47030AE876@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030AE876@eusaamb101.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/mixed; boundary="_004_4A1562797D64E44993C5CBF38CF1BE4817FBE0ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM+Jvje6zx/lBBte/W1o8mXODxeJvw2sW i+dzZrJYLFjzlN2BxWPJkp9MHl8uf2YLYIrisklJzcksSy3St0vgypjc/p6xYP9x/oor874y NzAemMXXxcjJISFgIvHkxTs2CFtM4sK99UA2F4eQwCFGiQd3fkM5ixklfi05xNzFyMHBJmAl 8eSQD0iDiICWROfb7+wgNcwCjxklPm14zgjiCAt0MUo8vXocrFtEoJtRYvPlvcwQLX4S3eve gu1jEVCV+LaliwXE5hXwlvjctY4FYt1NJomXvW/AEpxADT/Pd4M1MwrISkzYvYgRxGYWEJe4 9WQ+E8ThIhIPL56GekJU4uXjf6wgp0oIKEos75eDKM+U2Ln4PCvELkGJkzOfsExgFJ2FZNIs JGWzkJRBxPMlFvXeZ4Sw9SRuTJ3CBmFrSyxb+JoZwtaVmPHvEAumuJfE1hM32SFsO4kjP18A 7QKF2ElGieVftkINUpSY0v2QfQEjzypG9tzEzJz0csNNjMBYP7jlt+4OxlPnRA4xSnOwKInz fnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUeilgfta1rVr5psZnJrH/9vcrvxH95pA 4SUrWJ+n7MmLUb35U0ayx8JHt5DjKnOf0U4r0y+zpCxbcrdceN1tkWH8Kqv4Qfam9RvN5n1l PJl6w+CAh6E+k3KttUp2duOHjZP8EzMr2oVb9Bdo7Yn9ez1+TgWH2v35KvLpDW9ZK6qrXSu9 nNcrsRRnJBpqMRcVJwIAce0eTMMCAAA= Cc: "rtg-dir@ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:48:43 -0000 --_004_4A1562797D64E44993C5CBF38CF1BE4817FBE0ESESSMB301ericsso_ Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4817FBE0ESESSMB301ericsso_" --_000_4A1562797D64E44993C5CBF38CF1BE4817FBE0ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Acee, Please find the version solving (hopefully) the last issues attached. It wi= ll be updated on Nov 4th. Also, please find my comments in line. Many thanks Daniele From: Acee Lindem Sent: luned=EC 28 ottobre 2013 17:01 To: Daniele Ceccarelli Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; rtg-dir@ietf.org; CC= AMP; rtg-ads@tools.ietf.org Subject: Re: RtgDir Review: "Traffic Engineering Extensions to OSPF for Gen= eralized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hi Daniele, I looked at the update and it is greatly improved. I'd still recommend the = following issues be addressed. 1. In section 4, you state the malformed LSA, TLV, or Sub-TLV is igno= red. Since this specification describes sub-TLVs, does that imply that only= the sub-TLVs are ignored when malformed? This is how I'd interpret it. [[DC]] correct. Fixed as you suggested below in 369,373c367,370, just chang= ed a bit to reflect the fact that only sub-TLVs are defined in this documen= t: When a received LSA includes a sub-TLV not formatted accordingly to the= precise specifications in this document, the problem SHOULD be logged and the wrongly formatted sub-TLV MUST NOT be used for path computation. 2. In examples where you used "X" to denote that the field is not appl= icable, you should state that. Or at least state it somewhere. [[DC]] OK. T, S and TS granularity fields are not relevant to this example (filled wit= h Xs) Also some edits on the new text: 130c130,131 < provided in [OTN-INFO]. --- > provided in [OTN-INFO]. The reader is assumed to be familiar with > both of these documents. 136,138d136 < The reader is supposed to be familiar with OTN framework [OTN-FWK] < and GMPLS evaluation against OTN [OTN-INFO]. < 320c318 < is shown in the table below (please note that there are 1000 bits in --- > are shown in the table below (please note that there are 1000 bits in 369,373c367,370 < In case a recived LSA is not formatted accordingly to the < requirements indicated in this document, the problem SHOULD be logged < and the wrongly formatted LSA, TLV or Sub-TLV MUST NOT be used for < the path computation until a newer version correctly formatted is < received. --- > When a received LSA is not formatted accordingly to the precise > specifications in this document, the problem SHOULD be logged > and the wrongly formatted LSA, TLV, or Sub-TLV MUST NOT be used for > path computation. 1561c1558 < flooding frequency. Moreover the design of the encoding has been --- > flooding frequency. Moreover, the design of the encoding has been 1573c1570 < priorities is advertised --- > priorities are advertised. 1575,1578c1572,1575 < - With respect of fixed containers, only the number of available < containers is advertised instead of available bandwidth so to use < only 16 bits per container instead of 32 (as per former GMPLS < encoding --- > - With respect to fixed containers, only the number of available > containers is advertised instead of available bandwidth so that > only 16 bits per container are used instead of 32 (as per the > former GMPLS encoding). 1580c1577 < In order to further reduce the amount of data advertised it is --- > In order to further reduce the amount of data advertised, it is Thanks, Acee P.S. I still think it would be better not to reference RFC 2154 in the "Sec= urity Considerations". RFC 6837 has a much better example for OSPF TE than = RFC 3630. [[DC]] Reference to RFC2154 removed but I think RFC6837 is not the one you= wanted to point to (A Not-so-novel Endpoint ID (EID) to Routing Locator (R= LOC) Database). On Oct 21, 2013, at 10:29 AM, Daniele Ceccarelli wrote: Hi Acee, Since today it is the deadline for draft submission we uploaded a version w= ith the changes agreed up to now and the ones proposed in line below. Furth= er modifications, if needed, will be deferred to a new version on Monday No= v 4th. Thanks once again for your review Daniele + Co-authors. From: Acee Lindem Sent: mercoled=EC 16 ottobre 2013 22:20 To: Daniele Ceccarelli Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.org Subject: Re: RtgDir Review: "Traffic Engineering Extensions to OSPF for Gen= eralized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hi Daniele, See inline. On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrote: Hi Acee, Thanks for the careful review and please find comments/replies in line. BR Daniele (&co-authors) From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: mercoled=EC 9 ottobre 2013 03:41 To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org Cc: rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.or= g Subject: RtgDir Review: "Traffic Engineering Extensions to OSPF for General= ized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please seehttp= ://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ccamp-ospf-g709v3-09.txt Reviewer: Acee Lindem Review Date: October 15th, 2013 IETF LC End Date: October 16, 2013 Intended Status: Proposed Standard Summary: The document is missing some key sections and requires some clarif= ication prior to publication. Comments: Major Issues: The document lacks several critical pieces of information. 1. There is no discussion of OSPF scaling or flooding freq= uency. Even if it not expected that G709 GMPLS signaling will not present any problems, this n= eeds to be stated and justified. Refer to section 8 in RFC 6827 for an example of such a discus= sion. [[Authors]] How about adding a section saying: OSPFv2 scalability considerations and requirements are in line with section= 8 of [RFC6827]. In addition please note that OTN extensions in this docume= nt have been designed taking into consideration optimization criteria ident= ified in [OTN-INFO] It isn't obvious to me that these two extensions are comparable. I think a = separate section pertaining to the OTN extensions would make more sense. [[DC]] The following section has been added: This document does not introduce OSPF scalability issues with respect to existing GMPLS encoding and does not require any modification to flooding frequency. Moreover the design of the encoding has been carried out taking into account bandwidth optimization, and in particular: - Only unreserved and MAX LSP Bandwidth related to supported priorities is advertised - With respect of fixed containers, only the number of available containers is advertised instead of available bandwidth so to use only 16 bits per container instead of 32 (as per former GMPLS encoding In order to further reduce the amount of data advertised it is RECOMMENDED to bundle component links with homogeneous hierarchies as described in [RFC4201] and illustrated in Section 5.6. 2. The document includes lots of normative text indicating= precisely how sub-TLVs MUST be formatted. However, there is no indication of what th= e action to be taken if the TLVs do not follow the strict conventions. [[Authors]] Good comment. Looking at previous OSPF and OSPF-TE drafts we di= dn't find any text on handling of bad TLV formatting. Any suggestion on how= to deal with that is more than welcome. In the past, I've stated that the problem should be logged and the LSA, TLV= , or Sub-TLV MUST NOT be used for TE/GMPLS path computation. It all depends= on what makes sense for the encoding violation and at what level it should= be resolved. One generic solution would be to NOT use any LSAs with encodi= ng violations for GMPLS path computation. [[DC]] This piece of text has been added at the end of section 4: In case a recived LSA is not formatted accordingly to the requir= ements indicated in this document, the problem SHOULD be logged and the wrongly form= atted LSA, TLV or Sub-TLV MUST NOT be used for the path computation until a newer version correc= tly formatted is received. 3. The document jumps down into details of G.709 technolog= y without adequate explanation (particularly in the examples). Either t= hese details need to be removed or a statement of prerequisite knowledge is required. [[Authors]] The reader is supposed to have read [OTN-FWK] and [OTN-INFO]. W= e can add a sentence at the end of the abstract or intro. This is the minimum. Minor Issues: The document had a large number of editorial errors. 1. The bit numbering on all the figures was off by 1 colum= n. If you look at RFC 4203, this will be obvious. [[Author]] Correct. Fixed. 2. The table on page 7 is incomprehensible with the given = columns and headings. Spaces rather than commas in numbers are annoying. [[Author]] Spaces substituted with commas. As per comment above having read= [OTN-FWK] and [OTN-INFO] is a prerequisite. Does it add anything to this document if one needs to look at OTN-FWK and O= TN-INFO anyway? It is much less relevant than, say, a discussion of adverti= sement and scaling ;^) For example, what does 239/238 mean? Is this 239 or 238 separate tributary = slots - why is it variable? What does GFP-F mean - it is not defined here. [[DC]] Table 7 is needed to fill the common header of the ISCD. E.g. when i= ndicating ODU4, the related max lsp bandwidth in the common header of the I= SCD needs to be filled with 0x504331E3. The first and third columns of the table are needed for that, while the sec= ond one explains how the value is Byte/sec is retrieved (i.e. the nominal b= it rate of each ODU). The "239/238" does not mean 239 OR 238 but means 239 = divided by 238. The meaning of GFP-F is explained in the fwk document (defined in G.7041) a= nd stands for Generic Framing Procedure. In addition to the various ODUs th= ere are three more ODU types that need to be advertised, namely: i) ODUflex= for CBR client signals, ii) ODUflex for GFP-F mapped client signal and iii= ) ODU flex resizable. 3. The distinction between TLVs and sub-TLVs is not consis= tent throughout the document. Again, refer to RFC 6827 for an example of consistent= referral. [[Authors]] Good catch. We're defining only sub-tlvs. Fixed. 4. Figures 8 and 9 have the T and S fields offset from the= bit numbering. Also, it took some time to realize that T1 meant a value of 1. [[Authors]] T and S were left intentionally to make the reading easier but = maybe it's not the case. Only 0 and 1 are there now. 5. Figures 11-15 are very inconsistent in that these are examples yet the v= alues for T, S, and sometime TSG are not specified. Rather, the example in= cludes the letters. [[Authors]] The focus of those examples is not T,S and TSG but e.g. ODUflex= advertisement, single stage muxing etc. For each example there is a discla= imer saying: "T, S and TS granularity fields are not relevant to this examp= le". Then wouldn't X's be more relevant than missing discrete values and field l= abels in the same figure? [[DC]] OK. X's used. 6. Security section - RFC 2154 is an experimental RFC that= has heretofore never been commercially implemented or deployed. It is time to q= uit referencing it in draft "Security Considerations". [[Authors]] How about the following? OLD [RFC3630] suggests mechanisms such = as [RFC2154] to protect the transmission of this information... NEW [RFC3630] suggests mechanisms to pr= otect the transmission of this information... It would be great with me. There are plenty of reviewers who will nit pick = the security section... Nits: 1. The proper punctuation is "i.e., " and "e.g. ,". [[Authors]] OK Also, sentences should not start with either. See http://www.rfc-editor.org/rfc-style-guide/rfc-sty= le 2. Page 7, "Switching Capability-Specific Information (SCSI)? [[Authors]] OK 3. Suggest formatting the document so that the figures are= on separate pages rather than split across pages. [[Authors]] I don't know how to do that with the .xml file. Maybe this is a= comment we can leave for the RFC editor? Ok. I have been able to do this with [[DC]] It works fine with all figures except fig 14. It's longer than a pag= e. 3. Replace all occurrences of "non " with "non-" and do not end lines= with "non ". [[Authors]] OK 4. I thought the examples included many run-on sentences t= hat were hard to parse and lacked needed punctuation. I tried to edit but I'm not even = sure if I retained the same meaning. You can get a flavor for what I mean by the diffs below. [[Authors]] OK to all. All modifications you suggest have been implemented. Thanks - I'll look for the update. Thanks, Acee Thanks, Acee 132,133c132,133 < Routing information for Optical Channel Layer (OCh) (i.e. wavelength) < is out of the scope of this document. Please refer to [RFC6163] and --- > Routing information for Optical Channel Layer (OCh) (i.e., wavelength) > is beyond the scope of this document. Please refer to [RFC6163] and 157c157 < As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so --- > As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended 159c159 < related to each different ODUj and ODUk/OTUk (Optical Transport Unit) --- > of each different ODUj and ODUk/OTUk (Optical Transport Unit) 176c176 < In the following we will use ODUj to indicate a service type that is --- > In the following, we will use ODUj to indicate a service type that is 179c179 < the OTUk. Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and --- > the OTUk. Moreover, ODUj(S) and ODUk(S) are used to indicate ODUj and 184c184 < multiplexing levels. In the following the term "multiplexing tree" --- > multiplexing levels. In the following, the term "multiplexing tree" 191c191 < If for example a multiplexing hierarchy like the following one is --- > For example, If a multiplexing hierarchy like the following one is 251c251 < one hop case multiple hop TE-links advertise ODU switching capacity. --- > one hop case, multiple hop TE-links advertise ODU switching capacity. 296,297c296,297 < Both for fixed and flexible ODUs the same switching type and encoding < values MUST be used. When Switching Capability and Encoding fields --- > The same switching type and encoding values must be used for both fixe= d > and flexible ODUs. When Switching Capability and Encoding fields 303,304c303,304 < The MAX LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <= =3D < MAX LSP Bandwidth <=3D ODUk/OTUk and intermediate values are those on --- > The MAX LSP Bandwidth field is used according to [RFC4203]: i.e., 0 <= =3D > MAX LSP Bandwidth <=3D ODUk/OTUk, and intermediate values are those on 306,307c306,307 < E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP < Bandwidth for some priorities, ODU3 for others, ODU2 for some others --- > For example, in the OTU4 link it could be possible to have ODU4 as MAX= LSP > Bandwidth for some priorities, ODU3 for others, ODU2 for some others, 397,398c397,398 < Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non < resizable. Each MUST always be advertised in separate Type 2 TLVs as --- > Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) > non-resizable. Each MUST always be advertised in separate Type 2 TLVs= as 400c400 < both GFP-F resizable and non resizable (i.e. 21 and 22) are --- > both GFP-F resizable and non-resizable (i.e. 21 and 22) are 535c535 < (i.e. a non OTN client). --- > (i.e., a non-OTN client). 540c540 < - Priority (8 bits): a bitmap used to indicate which priorities --- > - Priority (8 bits): A bitmap used to indicate which priorities 542,543c542,543 < leftmost bit representing priority level 0 (i.e. the highest) and < the rightmost bit representing priority level 7 (i.e. the lowest). --- > leftmost bit representing priority level 0 (i.e., the highest) and > the rightmost bit representing priority level 7 (i.e., the lowest). 666c666 < Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD @T0 --- > Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD at T0 676,678c676,678 < At time T1 an ODU3 at priority 2 is set-up, so for priority 0 the MAX < LSP Bandwidth is still equal to the ODU4 bandwidth, while for < priorities from 2 to 7 (excluding the non supported ones) the MAX LSP --- > At time T1, an ODU3 at priority 2 is set-up, so for priority 0 the > MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for > priorities from 2 to 7 (excluding the non-supported ones) the MAX LSP 680c680 < next supported ODUj in the hierarchy is ODU3.The advertisement is --- > next supported ODUj in the hierarchy is ODU3. The advertisement is 710c710 < Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD @T1 --- > Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD at T1 712,714c712,714 < At time T2 an ODU2 at priority 4 is set-up. The first ODU3 is no < longer available since T1 as it was kept by the ODU3 LSP, while the < second is no more available and just 3 ODU2 are left in it. ODU2 is --- > At time T2, an ODU2 at priority 4 is set-up. The first ODU3 is no > longer available since T1, as it was kept by the ODU3 LSP, while the > second is no more available and just 3 ODU2s are left in it. ODU2 is 758c758 < Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD @T2 --- > Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD at T2 762c762 < In this example an interface with Tributary Slot Type 1.25Gbps and --- > In this example, an interface with Tributary Slot Type 1.25Gbps and 766c766 < switched or terminated, the ODU2 can only be terminated and the ODU1 --- > switched or terminated, the ODU2 can only be terminated, and the ODU1 768c768 < advertised to support ODU0 the value of is "ignored" (TS --- > advertised to support ODU0, the value of is "ignored" (TS 770c770 < interface a single ISCD is used and its format is as follows: --- > interface, a single ISCD is used and its format is as follows: 819c819 < In this example two interfaces with homogeneous hierarchies but --- > In this example, two interfaces with homogeneous hierarchies but 822,824c822,824 < one a G.709-2012 interface with fallback procedure disabled (TS < granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy and < priorities 0 and 3. T and S bits values are not relevant to this --- > one supports G.709-2012 interface with fallback procedure disabled > (TS granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy > and priorities 0 and 3. T and S bits values are not relevant to this 826,827c826,827 < interfaces two different ISCDs are used and the format of their SCSIs < is as follows: --- > interfaces, two different ISCDs are used and the format of their > SCSIs is as follows: 903,908c903,908 < with different exported TS granularity MUST be considered as non < homogenous hierarchies is the case in which an H-LPS and the client < LSP are terminated on the same egress node. What can happen is that < a loose Explicit Route Object (ERO) is used at the hop where the < signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate < hop of the LSP). --- > with different exported TS granularity MUST be considered as > non-homogenous hierarchies. This is the case in which an H-LPS and > the client LSP are terminated on the same egress node. What can > happen is that a loose Explicit Route Object (ERO) is used at the > hop where the signaled LSP is nested into the Hierarchical-LSP (H-LSP) > (penultimate hop of the LSP). 912,915c912,915 < if2. In case the H-LSP on if1 exports a TS=3D1.25Gbps and if2 a < TS=3D2.5Gbps and the service LSP being signaled needs a 1.25Gbps < tributary slot, only the H-LSP on if1 can be used to reach node E. < For further details please see section 4.1 of the [OTN-INFO]. --- > if2. In this case, the H-LSP on if1 exports a TS=3D1.25Gbps, if2 a > TS=3D2.5Gbps, the service LSP being signaled needs a 1.25Gbps > tributary slot, and only the H-LSP on if1 can be used to reach node E. > For further details, please see section 4.1 of the [OTN-INFO]. 939,943c939,943 < In this example the advertisement of an ODUflex->ODU3 hierarchy is < shown. In case of ODUflex advertisement the MAX LSP Bandwidth needs < to be advertised and in some cases also information about the < Unreserved bandwidth could be useful. The amount of Unreserved < bandwidth does not give a clear indication of how many ODUflex LSP --- > In this example, the advertisement of an ODUflex->ODU3 hierarchy is > shown. In the case of ODUflex advertisement, the MAX LSP Bandwidth > needs to be advertised and, in some cases, information about the > Unreserved bandwidth could also be useful. The amount of Unreserved > bandwidth does not give a clear indication of how many ODUflex LSPs 959,962c959,962 < Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved < Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex < LSPs of 10 GBps each, have to be restored, for sure only one can be < restored along Link B and it is probable (but not sure) that two of --- > Bandwidth equal to 10 Gbps each. In the case where 50Gbps of Unreserv= ed > Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUflex > LSPs of 10 GBps each have to be restored, for sure only one can be > restored along Link B and it is probable, but not certain, that two of 966c966 < In the case of ODUflex advertisement the Type 2 Bandwidth TLV is --- > In the case of ODUflex advertisement, the Type 2 Bandwidth TLV is 1073c1073 < simplicity we assume that also in this case only priorities 0 and 3 --- > simplicity, we also assume that only priorities 0 and 3 1294c1294 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1388c1388 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1506c1506 < All implementations of this document MAY support also advertisement --- > All implementations of this document MAY also support advertisement 1518c1518 < based on policy and is out of scope of the document. This enables --- > based on policy and beyond the scope of this document. This enables 1537c1537 < [RFC5920] . --- > [RFC5920]. --_000_4A1562797D64E44993C5CBF38CF1BE4817FBE0ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Acee,

 <= /p>

Please find the version s= olving (hopefully) the last issues attached. It will be updated on Nov 4th.

 <= /p>

Also, please find my comm= ents in line.

 <= /p>

Many thanks

Daniele=

 <= /p>

 <= /p>

From: Acee Lin= dem
Sent: luned=EC 28 ottobre 2013 17:01
To: Daniele Ceccarelli
Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; rtg-dir@ietf.= org; CCAMP; rtg-ads@tools.ietf.org
Subject: Re: RtgDir Review: "Traffic Engineering Extensions to = OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks&qu= ot;

 

Hi Daniele, 

I looked at the update and it is greatly improved. I= 'd still recommend the following issues be addressed. 

 

1.      In section 4, you state the malformed LSA, TLV, or = Sub-TLV  is ignored. Since this specification describes sub-TLVs, does= that imply that only the sub-TLVs are ignored when malformed? This is how = I'd interpret it. 

 

[[DC]] correct. Fix= ed as you suggested below in 369,373c367,370, just changed a bit to reflect= the fact that only sub-TLVs are defined in this document:

 

    When a received LSA includes a sub-TLV not for= matted accordingly to the precise

    specifications in this document, the prob= lem SHOULD be logged

    and the wrongly formatted sub-TLV MUST NOT be = used for

    = path computation.

 

 

2.      In examples where you used "X" to denote = that the field is not applicable, you should state that. Or at least state = it somewhere. 

 

[[DC]] OK.

T, S and TS granularity fields are not relevant to this exa= mple (filled with Xs)

 

Also some edits on the new text:

 

 

130c130,131

<    provided in [OTN-INFO].=

---

>    provided in [OTN-INFO].  The = reader is assumed to be familiar with

>    both of these documents. 

136,138d136

<    The reader is supposed to be famil= iar with OTN framework [OTN-FWK]

<    and GMPLS evaluation against OTN [= OTN-INFO].

< 

320c318

<    is shown in the table below (pleas= e note that there are 1000 bits in

---

>    are shown in the table below (plea= se note that there are 1000 bits in

369,373c367,370

<    In case a recived LSA is not forma= tted accordingly to the

<    requirements indicated in this doc= ument, the problem SHOULD be logged

<    and the wrongly formatted LSA, TLV= or Sub-TLV MUST NOT be used for

<    the path computation until a newer= version correctly formatted is

<    received.

---

>    When a received LSA is not formatt= ed accordingly to the precise 

>    specifications in this document, t= he problem SHOULD be logged

>    and the wrongly formatted LSA, TLV= , or Sub-TLV MUST NOT be used for

>    path computation.

1561c1558

<    flooding frequency.  Moreover= the design of the encoding has been

---

>    flooding frequency.  Moreover= , the design of the encoding has been

1573c1570

<       priorities is advertised

---

>       priorities are advertised.=

1575,1578c1572,1575

<       - With respect of fixed co= ntainers, only the number of available

<       containers is advertised i= nstead of available bandwidth so to use

<       only 16 bits per container= instead of 32 (as per former GMPLS

<       encoding

---

>       - With respect to fixed co= ntainers, only the number of available

>       containers is advertised i= nstead of available bandwidth so that

>       only 16 bits per container= are used instead of 32 (as per the

>       former GMPLS encoding).

1580c1577

<    In order to further reduce the amo= unt of data advertised it is

---

>    In order to further reduce the amo= unt of data advertised, it is

 

 

Thanks,

Acee

P.S. I still think it would be better not to referen= ce RFC 2154 in the "Security Considerations". RFC 6837 has a much= better example for OSPF TE than RFC 3630.

[[DC]] Reference to RF= C2154 removed but I think  RFC6837 is not the one you wanted to point = to (A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database).

 

On Oct 21, 2013, at 10:29 AM, Daniele Ceccarelli wro= te:



Hi Acee,

 <= /p>

Since today it is the dea= dline for draft submission we uploaded a version with the changes agreed up= to now and the ones proposed in line below. Further modifications, if needed, will be deferred to a new version on Monday Nov 4th.=

 <= /p>

Thanks once again for you= r review

 <= /p>

Daniele + Co-authors.=

 <= /p>

From: Acee Lindem 
Sent: mercoled=EC = 16 ottobre 2013 22:20
To: Daniele Ceccar= elli
Cc: draft-ietf-ccamp-gmp= ls-ospf-g709v3@tools.ietf.org;&nb= sp;rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.org
Subject: Re: RtgDi= r Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS= (GMPLS) Control of Evolving G.709 OTN Networks"

 

Hi Daniele,

See inline. 

 

On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrot= e:




Hi Acee,

 <= /p>

Thanks for the careful re= view and please find comments/replies in line.

 <= /p>

BR
Daniele (&co-authors)

 <= /p>

From: Acee Lindem [mailto:acee.lindem@eri= csson.com] 
Sent: mercoled=EC = 9 ottobre 2013 03:41
To: draft-ietf-ccamp-gmp= ls-ospf-g709v3@tools.ietf.org
Cc: rtg-dir@ietf.org; CCAMP; rtg-ads= @tools.ietf.org
Subject: RtgDir Re= view: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GM= PLS) Control of Evolving G.709 OTN Networks"

 

Hello,

 

I have been selected as the Routing Dir= ectorate reviewer for this draft. The Routing Directorate seeks to review a= ll routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purp= ose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please seehttp://www.ietf.or= g/iesg/directorate/routing.html

 

Although these comments are primarily f= or the use of the Routing ADs, it would be helpful if you could consider th= em 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-ospf-g709v3-09.txt

Reviewer: Acee Lindem=

Review Date: October 15th, 2013<= o:p>

IETF LC End Date: October 16, 2013

Intended Status: Proposed Standard = ;

 

Summary: The document is missing some k= ey sections and requires some clarification prior to publication. 

 

Comments:

 

Major Issues: The document lacks severa= l critical pieces of information.   

 

          &nbs= p;      1. There is no discussion of OSPF scaling or floodin= g frequency. Even if it not expected that G709 

          &nbs= p;           GMPLS signaling will not present= any problems, this needs to be stated and justified. Refer to<= /o:p>

          &nbs= p;           section 8 in RFC 6827 for an example = of such a discussion. 

[[Authors]] How abo= ut adding a section saying:

OSPFv2 scalability considerations and requirements are in line w= ith section 8 of [RFC6827]. In addition please note that OTN extensions in this document have been designed taking into consideration o= ptimization criteria identified in [OTN-INFO]

 

It isn't obvious to me that these two extensions are= comparable. I think a separate section pertaining to the OTN extensions wo= uld make more sense. 

 

[[DC]] The followin= g section has been added:

 

This d= ocument does not introduce OSPF scalability issues with respect
   to existing GMPLS encoding and does not require any modificati= on to
   flooding frequency.  Moreover the design of the encoding = has been
   carried out taking into account bandwidth optimization, and in=
   particular:


 =      - Only unreserved and MAX LSP Bandwidth related to= supported
      priorities is advertised

      - With respect of fixed containers, only the= number of available
      containers is advertised instead of availabl= e bandwidth so to use
      only 16 bits per container instead of 32 (as= per former GMPLS
      encoding

   In order to further reduce the amount of data advertised it is=
   RECOMMENDED to bundle component links with homogeneous hierarc= hies as
   described in [RFC4201] and illustrated in Section 5.6.<= span style=3D"font-size:10.5pt;font-family:Consolas">

 <= /p>




          &nbs= p;      2. The document includes lots of normative text= indicating precisely how sub-TLVs MUST be 

          &nbs= p;           formatted. However, there is no = indication of what the action to be taken if the TLVs do<= /p>

          &nbs= p;           not follow the strict conventions.&nb= sp;

[[Authors]] Good co= mment. Looking at previous OSPF and OSPF-TE drafts we didn’t find any= text on handling of bad TLV formatting. Any suggestion on how to deal with that is more than welcome.

 

In the past, I've stated that the problem should be = logged and the LSA, TLV, or Sub-TLV MUST NOT be used for TE/GMPLS path comp= utation. It all depends on what makes sense for the encoding violation and = at what level it should be resolved. One generic solution would be to NOT use any LSAs with encoding violations= for GMPLS path computation. 

 

 

[[DC]] This piece o= f text has been added at the end of section 4:

 

   &= nbsp;       In case a recived LSA is not form= atted accordingly to the requirements indicated in

   &= nbsp;       this document, the problem SHOULD= be logged and the wrongly formatted LSA, TLV or Sub-TLV MUST NOT

   &= nbsp;          be used for the= path computation until a newer version correctly formatted is received.




          &nbs= p;      3. The document jumps down into details of G.709 tec= hnology without adequate 

          &nbs= p;            explanation (particularly in th= e examples). Either these details need to be removed or a =

          &nbs= p;           statement of prerequisite knowledge i= s required. 

[[Authors]] The rea= der is supposed to have read [OTN-FWK] and [OTN-INFO]. We can add a sentenc= e at the end of the abstract or intro.

 

This is the minimum. 




 <= /p>

Minor Issues: The document had a large = number of editorial errors.

 

          &nbs= p;      1. The bit numbering on all the figures was off by 1= column. If you look at RFC 4203, 

          &nbs= p;           this will be obvious. 

[[Author]] Correct.= Fixed.

          &nbs= p;      2. The table on page 7 is incomprehensible with the = given columns and headings. Spaces 

          &nbs= p;           rather than commas in numbers are ann= oying. 

 

 

[[Author]] Spaces s= ubstituted with commas. As per comment above having read [OTN-FWK] and [OTN= -INFO] is a prerequisite.

 

Does it add anything to this document if one needs t= o look at OTN-FWK and OTN-INFO anyway? It is much less relevant than, say, = a discussion of advertisement and scaling ;^) 

 

For example, what does 239/238 mean? Is this 239 or = 238 separate tributary slots - why is it variable? What does GFP-F mean - i= t is not defined here. 

 

[[=
DC]] Table 7 is needed to fill the common header of the ISCD. E.g. when ind=
icating ODU4, the related max lsp bandwidth in the common header of the ISC=
D needs to be filled with  0x504331E3.
The firs=
t and third columns of the table are needed for that, while the second one =
explains how the value is Byte/sec is retrieved (i.e. the nominal bit rate =
of each ODU). The “239/238” does not mean 239 OR 238 but means =
239 divided by 238.
The mean=
ing of GFP-F is explained in the fwk document (defined in G.7041) and stand=
s for Generic Framing Procedure. In addition to the various ODUs there are =
three more ODU types that need to be advertised, namely: i) ODUflex for CBR=
 client signals, ii) ODUflex for GFP-F mapped client signal and iii) ODU fl=
ex resizable.

          &nbs= p;      3. The distinction between TLVs and sub-TLVs is not = consistent throughout the document. 

          &nbs= p;           Again, refer to RFC 6827 for an examp= le of consistent referral.

[[Authors]] Good ca= tch. We’re defining only sub-tlvs. Fixed.

          &nbs= p;      4. Figures 8 and 9 have the T and S fields offset fr= om the bit numbering. Also, it took 

          &nbs= p;           some time to realize that T1 meant a = value of 1. 

[[Authors]] T and S= were left intentionally to make the reading easier but maybe it’s no= t the case. Only 0 and 1 are there now.

5. Figures = 11-15 are very inconsistent in that these are examples yet the values for T= , S, and  sometime TSG are not specified. Rather, the example includes the letters.  

[[=
Authors]] The focus of those examples is not T,S and TSG but e.g. ODUflex a=
dvertisement, single stage muxing etc. For each example there is a disclaim=
er saying: “T, S and TS granularity fields are not relevant to this example”.

 

Then wouldn't X's be more relevant than missing disc= rete values and field labels in the same figure? 

 

[[DC]] OK. X’= s used.




 

          &nbs= p;      6. Security section - RFC 2154 is an experimental RF= C that has heretofore never been 

          &nbs= p;           commercially implemented or deployed.=  It is time to quit referencing it in draft 

          &nbs= p;           "Security Considerations".&= nbsp;

[[Authors]] How abo= ut the following?

OLD<= o:p>

    [RFC3630] suggests mechanisms such as [RFC2154] to protect

   the transmissio= n of this information…

NEW<= o:p>

    [RFC3630] suggests mechanisms to protect

   the transmissio= n of this information…

 

It would be great with me. There are plenty of revie= wers who will nit pick the security section... 

 




 

  Nits:

1.=        The proper punctuation is "i.e., " and "e.g. ,".  

[[Authors]] OK

Also, sentences should not start with e= ither. 

          &nbs= p;           See http://www.rfc-edit= or.org/rfc-style-guide/rfc-style

2.=        Page 7, "Switching Capability-Specific Information (SCSI)? 

[[Authors]] OK

          &nbs= p;      3. Suggest formatting the document so that the figur= es are on separate pages rather than 

          &nbs= p;           split across pages. =

[[Authors]] I don&#= 8217;t know how to do that with the .xml file. Maybe this is a comment we c= an leave for the RFC editor?

 

Ok. I have been able to do this with 

 

<vspace blankLines=3D"100" />

 

 

[[DC]] It works fin= e with all figures except fig 14. It’s longer than a page.=




3.=        Replace all occurrences of "non " with "non-" and do not end l= ines with "non ". 

[[Authors]] OK

          &nbs= p;      4. I thought the examples included many run-on sente= nces that were hard to parse and lacked

          &nbs= p;           needed punctuation. I tried to edit b= ut I'm not even sure if I retained the same meaning. You <= /o:p>

          &nbs= p;           can get a flavor for what I mean by t= he diffs below. 

[[Authors]] OK to a= ll. All modifications you suggest have been implemented.

 

Thanks - I'll look for the update. <= /p>

 

Thanks,

Acee 

 




 

 

Thanks,

Acee 

132,13= 3c132,133

< &= nbsp;  Routing information for Optical Channel Layer (OCh) (i.e. wavel= ength)

< &= nbsp;  is out of the scope of this document.  Please refer to [RF= C6163] and

---

> &= nbsp;  Routing information for Optical Channel Layer (OCh) (i.e., wave= length)

> &= nbsp;  is beyond the scope of this document.  Please refer to [RF= C6163] and

 

157c15= 7

< &= nbsp;  As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be exten= ded so

---

> &= nbsp;  As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be exten= ded

 

159c15= 9

< &= nbsp;  related to each different ODUj and ODUk/OTUk (Optical Transport= Unit)

---

> &= nbsp;  of each different ODUj and ODUk/OTUk (Optical Transport Unit)

176c17= 6

< &= nbsp;  In the following we will use ODUj to indicate a service type th= at is

---

> &= nbsp;  In the following, we will use ODUj to indicate a service type t= hat is

179c17= 9

< &= nbsp;  the OTUk.  Moreover ODUj(S) and ODUk(S) are used to indica= te ODUj and

---

> &= nbsp;  the OTUk.  Moreover, ODUj(S) and ODUk(S) are used to indic= ate ODUj and

184c18= 4

< &= nbsp;  multiplexing levels.  In the following the term "mult= iplexing tree"

---

> &= nbsp;  multiplexing levels.  In the following, the term "mul= tiplexing tree"

191c19= 1

< &= nbsp;  If for example a multiplexing hierarchy like the following one = is

---

> &= nbsp;  For example, If a multiplexing hierarchy like the following one= is

251c25= 1

< &= nbsp;  one hop case multiple hop TE-links advertise ODU switching capa= city.

---

> &= nbsp;  one hop case, multiple hop TE-links advertise ODU switching cap= acity.

296,29= 7c296,297

< &= nbsp;  Both for fixed and flexible ODUs the same switching type and en= coding

< &= nbsp;  values MUST be used.  When Switching Capability and Encodi= ng fields

---

> &= nbsp;  The same switching type and encoding values must be used for bo= th fixed

> &= nbsp;  and flexible ODUs.  When Switching Capability and Encoding= fields

303,30= 4c303,304

< &= nbsp;  The MAX LSP Bandwidth field is used according to [RFC4203]: i.e= . 0 <=3D

< &= nbsp;  MAX LSP Bandwidth <=3D ODUk/OTUk and intermediate values are= those on

---

> &= nbsp;  The MAX LSP Bandwidth field is used according to [RFC4203]: i.e= ., 0 <=3D

> &= nbsp;  MAX LSP Bandwidth <=3D ODUk/OTUk, and intermediate values ar= e those on

306,30= 7c306,307

< &= nbsp;  E.g. in the OTU4 link it could be possible to have ODU4 as MAX = LSP

< &= nbsp;  Bandwidth for some priorities, ODU3 for others, ODU2 for some o= thers

---

> &= nbsp;  For example, in the OTU4 link it could be possible to have ODU4= as MAX LSP

> &= nbsp;  Bandwidth for some priorities, ODU3 for others, ODU2 for some o= thers, 

397,39= 8c397,398

< &= nbsp;  Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-= F) non

< &= nbsp;  resizable.  Each MUST always be advertised in separate Typ= e 2 TLVs as

---

> &= nbsp;  Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-= F) 

> &= nbsp;  non-resizable.  Each MUST always be advertised in separate= Type 2 TLVs as

400c40= 0

< &= nbsp;  both GFP-F resizable and non resizable (i.e. 21 and 22) are

---

> &= nbsp;  both GFP-F resizable and non-resizable (i.e. 21 and 22) are

535c535

<       (i.e. a non OTN client).=

---

>       (i.e., a non-OTN client).

540c54= 0

< &= nbsp;     - Priority (8 bits): a bitmap used to indicate which pr= iorities

---

> &= nbsp;     - Priority (8 bits): A bitmap used to indicate which pr= iorities

542,54= 3c542,543

< &= nbsp;     leftmost bit representing priority level 0 (i.e. the hi= ghest) and

< &= nbsp;     the rightmost bit representing priority level 7 (i.e. t= he lowest).

---

> &= nbsp;     leftmost bit representing priority level 0 (i.e., the h= ighest) and

> &= nbsp;     the rightmost bit representing priority level 7 (i.e., = the lowest).

666c66= 6

< &= nbsp;     Figure 5: Example 1 - MAX LSP Bandwidth fields in the I= SCD @T0

---

> &= nbsp;     Figure 5: Example 1 - MAX LSP Bandwidth fields in the I= SCD at T0

676,67= 8c676,678

< &= nbsp;  At time T1 an ODU3 at priority 2 is set-up, so for priority 0 t= he MAX

< &= nbsp;  LSP Bandwidth is still equal to the ODU4 bandwidth, while for

< &= nbsp;  priorities from 2 to 7 (excluding the non supported ones) the M= AX LSP

---

> &= nbsp;  At time T1, an ODU3 at priority 2 is set-up, so for priority 0 = the

> &= nbsp;  MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while f= or

> &= nbsp;  priorities from 2 to 7 (excluding the non-supported ones) the M= AX LSP

680c68= 0

< &= nbsp;  next supported ODUj in the hierarchy is ODU3.The advertisement = is

---

> &= nbsp;  next supported ODUj in the hierarchy is ODU3. The advertisement= is

710c71= 0

< &= nbsp;     Figure 6: Example 1 - MAX LSP Bandwidth fields in the I= SCD @T1

---

> &= nbsp;     Figure 6: Example 1 - MAX LSP Bandwidth fields in the I= SCD at T1

712,71= 4c712,714

< &= nbsp;  At time T2 an ODU2 at priority 4 is set-up.  The first ODU= 3 is no

< &= nbsp;  longer available since T1 as it was kept by the ODU3 LSP, while= the

< &= nbsp;  second is no more available and just 3 ODU2 are left in it. &nb= sp;ODU2 is

---

> &= nbsp;  At time T2, an ODU2 at priority 4 is set-up.  The first OD= U3 is no

> &= nbsp;  longer available since T1, as it was kept by the ODU3 LSP, whil= e the

> &= nbsp;  second is no more available and just 3 ODU2s are left in it. &n= bsp;ODU2 is

758c75= 8

< &= nbsp;     Figure 7: Example 1 - MAX LSP Bandwidth fields in the I= SCD @T2

---

> &= nbsp;     Figure 7: Example 1 - MAX LSP Bandwidth fields in the I= SCD at T2

762c76= 2

< &= nbsp;  In this example an interface with Tributary Slot Type 1.25Gbps = and

---

> &= nbsp;  In this example, an interface with Tributary Slot Type 1.25Gbps= and

766c76= 6

< &= nbsp;  switched or terminated, the ODU2 can only be terminated and the= ODU1

---

> &= nbsp;  switched or terminated, the ODU2 can only be terminated, and th= e ODU1

768c76= 8

< &= nbsp;  advertised to support ODU0 the value of is "ignored" = (TS

---

> &= nbsp;  advertised to support ODU0, the value of is "ignored"= (TS

770c77= 0

< &= nbsp;  interface a single ISCD is used and its format is as follows:

---

> &= nbsp;  interface, a single ISCD is used and its format is as follows:<= /span>

819c81= 9

< &= nbsp;  In this example two interfaces with homogeneous hierarchies but=

---

> &= nbsp;  In this example, two interfaces with homogeneous hierarchies bu= t

822,82= 4c822,824

< &= nbsp;  one a G.709-2012 interface with fallback procedure disabled (TS=

< &= nbsp;  granularity=3D3).  Both of them support ODU1->ODU2->= ODU3 hierarchy and

< &= nbsp;  priorities 0 and 3.  T and S bits values are not relevant = to this

---

> &= nbsp;  one supports G.709-2012 interface with fallback procedure disab= led

> &= nbsp;  (TS granularity=3D3).  Both of them support ODU1->ODU2-= >ODU3 hierarchy

> &= nbsp;  and priorities 0 and 3.  T and S bits values are not relev= ant to this

826,82= 7c826,827

< &= nbsp;  interfaces two different ISCDs are used and the format of their= SCSIs

< &= nbsp;  is as follows:

---

> &= nbsp;  interfaces, two different ISCDs are used and the format of thei= r 

> &= nbsp;  SCSIs is as follows:

903,90= 8c903,908

< &= nbsp;  with different exported TS granularity MUST be considered as no= n

< &= nbsp;  homogenous hierarchies is the case in which an H-LPS and the cl= ient

< &= nbsp;  LSP are terminated on the same egress node.  What can happ= en is that

< &= nbsp;  a loose Explicit Route Object (ERO) is used at the hop where th= e

< &= nbsp;  signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penul= timate

< &= nbsp;  hop of the LSP).

---

> &= nbsp;  with different exported TS granularity MUST be considered as&nb= sp;

> &= nbsp;  non-homogenous hierarchies. This is the case in which an H-LPS = and 

> &= nbsp;  the client LSP are terminated on the same egress node.  Wh= at can 

> &= nbsp;  happen is that a loose Explicit Route Object (ERO) is used at t= he 

> &= nbsp;  hop where the signaled LSP is nested into the Hierarchical-LSP = (H-LSP)

> &= nbsp;  (penultimate hop of the LSP).

912,91= 5c912,915

< &= nbsp;  if2.  In case the H-LSP on if1 exports a TS=3D1.25Gbps and= if2 a

< &= nbsp;  TS=3D2.5Gbps and the service LSP being signaled needs a 1.25Gbp= s

< &= nbsp;  tributary slot, only the H-LSP on if1 can be used to reach node= E.

< &= nbsp;  For further details please see section 4.1 of the [OTN-INFO].

---

> &= nbsp;  if2.  In this case, the H-LSP on if1 exports a TS=3D1.25Gb= ps, if2 a

> &= nbsp;  TS=3D2.5Gbps, the service LSP being signaled needs a 1.25Gbps

> &= nbsp;  tributary slot, and only the H-LSP on if1 can be used to reach = node E.

> &= nbsp;  For further details, please see section 4.1 of the [OTN-INFO].<= /span>

939,94= 3c939,943

< &= nbsp;  In this example the advertisement of an ODUflex->ODU3 hierar= chy is

< &= nbsp;  shown.  In case of ODUflex advertisement the MAX LSP Bandw= idth needs

< &= nbsp;  to be advertised and in some cases also information about the

< &= nbsp;  Unreserved bandwidth could be useful.  The amount of Unres= erved

< &= nbsp;  bandwidth does not give a clear indication of how many ODUflex = LSP

---

> &= nbsp;  In this example, the advertisement of an ODUflex->ODU3 hiera= rchy is

> &= nbsp;  shown.  In the case of ODUflex advertisement, the MAX LSP = Bandwidth

> &= nbsp;  needs to be advertised and, in some cases, information about th= e

> &= nbsp;  Unreserved bandwidth could also be useful.  The amount of = Unreserved

> &= nbsp;  bandwidth does not give a clear indication of how many ODUflex = LSPs

959,96= 2c959,962

< &= nbsp;  Bandwidth equal to 10 Gbps each.  In case 50Gbps of Unrese= rved

< &= nbsp;  Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUfl= ex

< &= nbsp;  LSPs of 10 GBps each, have to be restored, for sure only one ca= n be

< &= nbsp;  restored along Link B and it is probable (but not sure) that tw= o of

---

> &= nbsp;  Bandwidth equal to 10 Gbps each.  In the case where 50Gbps= of Unreserved

> &= nbsp;  Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUf= lex

> &= nbsp;  LSPs of 10 GBps each have to be restored, for sure only one can= be

> &= nbsp;  restored along Link B and it is probable, but not certain, that= two of

966c96= 6

< &= nbsp;  In the case of ODUflex advertisement the Type 2 Bandwidth TLV i= s

---

> &= nbsp;  In the case of ODUflex advertisement, the Type 2 Bandwidth TLV = is

1073c1= 073

< &= nbsp;  simplicity we assume that also in this case only priorities 0 a= nd 3

---

> &= nbsp;  simplicity, we also assume that only priorities 0 and 3<= /span>

1294c1= 294

< &= nbsp;  In this example 2 OTU4 component links with the same supported = TS

---

> &= nbsp;  In this example, 2 OTU4 component links with the same supported= TS

1388c1= 388

< &= nbsp;  In this example 2 OTU4 component links with the same supported = TS

---

> &= nbsp;  In this example, 2 OTU4 component links with the same supported= TS

1506c1= 506

< &= nbsp;  All implementations of this document MAY support also advertise= ment

---

> &= nbsp;  All implementations of this document MAY also support advertise= ment

1518c1= 518

< &= nbsp;  based on policy and is out of scope of the document.  This= enables

---

> &= nbsp;  based on policy and beyond the scope of this document.  Th= is enables

1537c1= 537

< &= nbsp;  [RFC5920] .

---

> &= nbsp;  [RFC5920].

 

 

          &nbs= p;     

          &nbs= p;     

 

 

 

--_000_4A1562797D64E44993C5CBF38CF1BE4817FBE0ESESSMB301ericsso_-- --_004_4A1562797D64E44993C5CBF38CF1BE4817FBE0ESESSMB301ericsso_ Content-Type: text/plain; name="draft-ietf-ccamp-gmpls-ospf-g709v3-11.txt" Content-Description: draft-ietf-ccamp-gmpls-ospf-g709v3-11.txt Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-ospf-g709v3-11.txt"; size=76146; creation-date="Tue, 29 Oct 2013 16:34:36 GMT"; modification-date="Tue, 29 Oct 2013 16:34:36 GMT" Content-Transfer-Encoding: base64 CgoKQ0NBTVAgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RC4gQ2VjY2FyZWxsaSwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBFcmljc3NvbgpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRi4gWmhhbmcKRXhwaXJl czogTWF5IDgsIDIwMTQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIdWF3ZWkgVGVj aG5vbG9naWVzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUy4gQmVsb3R0aQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQWxjYXRlbC1MdWNlbnQKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4gUmFv CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmZp bmVyYSBDb3Jwb3JhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSi4gRHJha2UKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVyCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm92ZW1iZXIg NCwgMjAxMwoKCiAgVHJhZmZpYyBFbmdpbmVlcmluZyBFeHRlbnNpb25zIHRvIE9TUEYgZm9yIEdl bmVyYWxpemVkIE1QTFMgKEdNUExTKQogICAgICAgICAgICAgICAgIENvbnRyb2wgb2YgRXZvbHZp bmcgRy43MDkgT1ROIE5ldHdvcmtzCiAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1vc3BmLWc3MDl2My0xMQoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IE9wZW4gU2hvcnRlc3QgUGF0aCBGaXJzdCAtIFRyYWZmaWMKICAgRW5naW5lZXJpbmcgKE9TUEYt VEUpIHJvdXRpbmcgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBzdXBwb3J0CiAgIEdlbmVyYWxpemVk IE1QTFMgKEdNUExTKSBjb250cm9sIG9mIE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmtzIChPVE4p CiAgIHNwZWNpZmllZCBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjcwOSBhcyBwdWJsaXNoZWQg aW4gMjAxMi4gIEl0CiAgIGV4dGVuZHMgbWVjaGFuaXNtcyBkZWZpbmVkIGluIFJGQzQyMDMuCgpT dGF0dXMgb2YgdGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBp biBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBC Q1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJ bnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhl ciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMg YXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIE1heSA4LCAyMDE0LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29w eXJpZ2h0IChjKSAyMDEzIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMg dGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAoK CgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE1heSA4LCAyMDE0ICAgICAgICAg ICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgT1NQRi1URSBleHRlbnNpb25z IGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIwMTMKCgogICBQcm92aXNpb25zIFJlbGF0 aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNl LWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRv Y3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0 aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAg IHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBk b2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBh bmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBT aW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9k dWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDMKICAgICAxLjEuICBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAzCiAgIDIuICBPU1BGLVRFIEV4dGVuc2lvbnMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAzLiAgVEUtTGluayBSZXByZXNl bnRhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgNC4g IElTQ0QgZm9ybWF0IGV4dGVuc2lvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA1CiAgICAgNC4xLiAgU3dpdGNoaW5nIENhcGFiaWxpdHkgU3BlY2lmaWMgSW5mb3Jt YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgICAgNC4xLjEuICBTd2l0Y2hpbmcgQ2FwYWJp bGl0eSBTcGVjaWZpYyBJbmZvcm1hdGlvbiBmb3IKICAgICAgICAgICAgICAgZml4ZWQgY29udGFp bmVycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAgICA0LjEu Mi4gIFN3aXRjaGluZyBDYXBhYmlsaXR5IFNwZWNpZmljIEluZm9ybWF0aW9uIGZvcgogICAgICAg ICAgICAgICB2YXJpYWJsZSBjb250YWluZXJzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDgKICAgICAgIDQuMS4zLiAgU3dpdGNoaW5nIENhcGFiaWxpdHkgU3BlY2lmaWMgSW5m b3JtYXRpb24gLSBGaWVsZAogICAgICAgICAgICAgICB2YWx1ZXMgYW5kIGV4cGxhbmF0aW9uIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgNS4gIEV4YW1wbGVzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyCiAgICAgNS4x LiAgTUFYIExTUCBCYW5kd2lkdGggZmllbGRzIGluIHRoZSBJU0NEIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxMgogICAgIDUuMi4gIEV4YW1wbGUgb2YgVCxTIGFuZCBUUyBncmFudWxhcml0eSB1dGls aXphdGlvbiAgLiAuIC4gLiAuIC4gMTQKICAgICAgIDUuMi4xLiAgRXhhbXBsZSBvZiBkaWZmZXJl bnQgVFMgR3JhbnVsYXJpdGllcyAgLiAuIC4gLiAuIC4gLiAuIDE1CiAgICAgNS4zLiAgRXhhbXBs ZSBvZiBPRFVmbGV4IGFkdmVydGlzZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOAog ICAgIDUuNC4gIEV4YW1wbGUgb2Ygc2luZ2xlIHN0YWdlIG11eGluZyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjAKICAgICA1LjUuICBFeGFtcGxlIG9mIG11bHRpIHN0YWdlIG11eGluZyAt IFVuYnVuZGxlZCBsaW5rIC4gLiAuIC4gLiAuIDIyCiAgICAgNS42LiAgRXhhbXBsZSBvZiBtdWx0 aSBzdGFnZSBtdXhpbmcgLSBCdW5kbGVkIGxpbmtzICAuIC4gLiAuIC4gLiAyNAogICAgIDUuNy4g IEV4YW1wbGUgb2YgY29tcG9uZW50IGxpbmtzIHdpdGggbm9uLWhvbW9nZW5lb3VzCiAgICAgICAg ICAgaGllcmFyY2hpZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyNQogICA2LiAgT1NQRnYyIHNjYWxhYmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgKICAgNy4gIENvbXBhdGliaWxpdHkgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI5CiAgIDguICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOQog ICA5LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjkKICAgICA5LjEuICBTd2l0Y2hpbmcgdHlwZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI5CiAgICAgOS4yLiAgTmV3IHN1Yi1UTFZzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMAogICAxMC4gQ29u dHJpYnV0b3JzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMzAKICAgMTEuIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDMzCiAgIDEyLiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMwogICAgIDEyLjEuIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzMKICAg ICAxMi4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDMzCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNAoKCgoKCkNlY2NhcmVsbGksIGV0IGFsLiAgICAg ICAgIEV4cGlyZXMgTWF5IDgsIDIwMTQgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVy bmV0LURyYWZ0ICAgICBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBzdXBwb3J0ICAgICAgTm92 ZW1iZXIgMjAxMwoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIEcuNzA5IE9wdGljYWwgVHJhbnNwb3J0 IE5ldHdvcmsgKE9UTikgW0cuNzA5LTIwMTJdIGluY2x1ZGVzIG5ldyBmaXhlZAogICBhbmQgZmxl eGlibGUgT0RVIChPcHRpY2FsIGNoYW5uZWwgRGF0YSBVbml0KSBjb250YWluZXJzLCB0d28gdHlw ZXMgb2YKICAgVHJpYnV0YXJ5IFNsb3RzIChpLmUuLCAxLjI1R2JwcyBhbmQgMi41R2JwcyksIGFu ZCBzdXBwb3J0cyB2YXJpb3VzCiAgIG11bHRpcGxleGluZyByZWxhdGlvbnNoaXBzIChlLmcuLCBP RFVqIG11bHRpcGxleGVkIGludG8gT0RVayAoajxrKSksCiAgIHR3byBkaWZmZXJlbnQgdHJpYnV0 YXJ5IHNsb3RzIGZvciBPRFVrIChLPTEsIDIsIDMpIGFuZCBPRFVmbGV4CiAgIHNlcnZpY2UgdHlw ZS4gIEluIG9yZGVyIHRvIHByZXNlbnQgdGhpcyBpbmZvcm1hdGlvbiBpbiByb3V0aW5nLCB0aGlz CiAgIGRvY3VtZW50IHByb3ZpZGVzIE9UTiB0ZWNobm9sb2d5IHNwZWNpZmljIGVuY29kaW5nIGZv ciB1c2UgaW4gR01QTFMKICAgT1NQRi1URSBhcyBkZWZpbmVkIGluIFtSRkM0MjAzXS4KCiAgIEZv ciBhIHNob3J0IG92ZXJ2aWV3IG9mIE9UTiBldm9sdXRpb24gYW5kIGltcGxpY2F0aW9ucyBvZiBP VE4KICAgcmVxdWlyZW1lbnRzIG9uIEdNUExTIHJvdXRpbmcgcGxlYXNlIHJlZmVyIHRvIFtPVE4t RldLXS4gIFRoZQogICBpbmZvcm1hdGlvbiBtb2RlbCBhbmQgYW4gZXZhbHVhdGlvbiBhZ2FpbnN0 IHRoZSBjdXJyZW50IHNvbHV0aW9uIGFyZQogICBwcm92aWRlZCBpbiBbT1ROLUlORk9dLiAgVGhl IHJlYWRlciBpcyBzdXBwb3NlZCB0byBiZSBmYW1pbGlhciB3aXRoCiAgIGJvdGggb2YgdGhlc2Ug ZG9jdW1lbnRzLgoKICAgUm91dGluZyBpbmZvcm1hdGlvbiBmb3IgT3B0aWNhbCBDaGFubmVsIExh eWVyIChPQ2gpIChpLmUuLAogICB3YXZlbGVuZ3RoKSBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQuICBQbGVhc2UgcmVmZXIgdG8KICAgW1JGQzYxNjNdIGFuZCBbUkZDNjU2Nl0g Zm9yIGZ1cnRoZXIgaW5mb3JtYXRpb24uCgoxLjEuICBUZXJtaW5vbG9neQoKICAgVGhlIGtleSB3 b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1Qi LAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJP UFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVz Y3JpYmVkIGluIFtSRkMyMTE5XS4KCgoyLiAgT1NQRi1URSBFeHRlbnNpb25zCgogICBJbiB0ZXJt cyBvZiBHTVBMUyBiYXNlZCBPVE4gbmV0d29ya3MsIGVhY2ggT1RVayBjYW4gYmUgdmlld2VkIGFz IGEKICAgY29tcG9uZW50IGxpbmssIGFuZCBlYWNoIGNvbXBvbmVudCBsaW5rIGNhbiBjYXJyeSBv bmUgb3IgbW9yZSB0eXBlcwogICBvZiBPRFVqIChqPGspLgoKICAgRWFjaCBURSBMaW5rIFN0YXRl IEFkdmVydGlzZW1lbnQgKExTQSkgY2FuIGNhcnJ5IGEgdG9wLWxldmVsIGxpbmsKICAgVHlwZSBM ZW5ndGggVmFsdWUgKFRMVikgd2l0aCBzZXZlcmFsIG5lc3RlZCBzdWItVExWcyB0byBkZXNjcmli ZQogICBkaWZmZXJlbnQgYXR0cmlidXRlcyBvZiBhIFRFIGxpbmsuICBUd28gdG9wLWxldmVsIFRM VnMgYXJlIGRlZmluZWQgaW4KICAgW1JGQzM2MzBdLiAoMSkgVGhlIFJvdXRlciBBZGRyZXNzIFRM ViAocmVmZXJyZWQgdG8gYXMgdGhlIE5vZGUgVExWKQogICBhbmQgKDIpIHRoZSBURSBsaW5rIFRM Vi4gIE9uZSBvciBtb3JlIHN1Yi1UTFZzIGNhbiBiZSBuZXN0ZWQgaW50byB0aGUKICAgdHdvIHRv cC1sZXZlbCBUTFZzLiAgVGhlIHN1Yi1UTFYgc2V0IGZvciB0aGUgdHdvIHRvcC1sZXZlbCBUTFZz IGFyZQogICBhbHNvIGRlZmluZWQgaW4gW1JGQzM2MzBdIGFuZCBbUkZDNDIwM10uCgogICBBcyBk aXNjdXNzZWQgaW4gW09UTi1GV0tdIGFuZCBbT1ROLUlORk9dLCBPU1BGLVRFIG11c3QgYmUgZXh0 ZW5kZWQgdG8KICAgYmUgYWJsZSB0byBhZHZlcnRpc2UgdGhlIHRlcm1pbmF0aW9uIGFuZCBzd2l0 Y2hpbmcgY2FwYWJpbGl0aWVzIG9mCiAgIGVhY2ggZGlmZmVyZW50IE9EVWogYW5kIE9EVWsvT1RV ayAoT3B0aWNhbCBUcmFuc3BvcnQgVW5pdCkgYW5kIHRoZQogICBhZHZlcnRpc2VtZW50IG9mIHJl bGF0ZWQgbXVsdGlwbGV4aW5nIGNhcGFiaWxpdGllcy4gIFRoZXNlCiAgIGNhcGFiaWxpdGllcyBh cmUgY2FycmllZCBpbiB0aGUgSW50ZXJmYWNlIFN3aXRjaGluZyBDYXBhYmlsaXR5CiAgIERlc2Ny aXB0b3IgKElTQ0QpIFN3aXRjaGluZyBDYXBhYmlsaXR5LXNwZWNpZmljIGluZm9ybWF0aW9uIGZp ZWxkCgoKCkNlY2NhcmVsbGksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTWF5IDgsIDIwMTQgICAg ICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICBPU1BGLVRFIGV4dGVu c2lvbnMgZm9yIE9UTiBzdXBwb3J0ICAgICAgTm92ZW1iZXIgMjAxMwoKCiAgIHVzaW5nIGZvcm1h dHMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgQXMgZGlzY3Vzc2VkIGluIFtTV0NBUC0KICAg VVBEVF0sIHRoZSB1c2Ugb2YgYSB0ZWNobm9sb2d5IHNwZWNpZmljIFN3aXRjaGluZyBDYXBhYmls aXR5LXNwZWNpZmljCiAgIGluZm9ybWF0aW9uIGZpZWxkIG5lY2Vzc2l0YXRlcyB0aGUgZGVmaW5p dGlvbiBvZiBhIG5ldyBTd2l0Y2hpbmcKICAgQ2FwYWJpbGl0eSB2YWx1ZSBhbmQgYXNzb2NpYXRl ZCBuZXcgU3dpdGNoaW5nIENhcGFiaWxpdHkuCgogICBJbiB0aGUgZm9sbG93aW5nLCB3ZSB3aWxs IHVzZSBPRFVqIHRvIGluZGljYXRlIGEgc2VydmljZSB0eXBlIHRoYXQgaXMKICAgbXVsdGlwbGV4 ZWQgaW50byBhIGhpZ2hlciBvcmRlciBPRFUsIE9EVWsgdG8gaW5kaWNhdGUgYSBoaWdoZXIgb3Jk ZXIKICAgT0RVIGluY2x1ZGluZyBhbiBPRFVqIGFuZCBPRFVrL09UVWsgdG8gaW5kaWNhdGUgdGhl IGxheWVyIG1hcHBlZCBpbnRvCiAgIHRoZSBPVFVrLiAgTW9yZW92ZXIsIE9EVWooUykgYW5kIE9E VWsoUykgYXJlIHVzZWQgdG8gaW5kaWNhdGUgT0RVagogICBhbmQgT0RVayBzdXBwb3J0aW5nIHN3 aXRjaGluZyBjYXBhYmlsaXR5IG9ubHksIGFuZCB0aGUgT0RVai0+T0RVawogICBmb3JtYXQgaXMg dXNlZCB0byBpbmRpY2F0ZSB0aGUgT0RVaiBpbnRvIE9EVWsgbXVsdGlwbGV4aW5nCiAgIGNhcGFi aWxpdHkuCgogICBUaGlzIG5vdGF0aW9uIGNhbiBiZSByZXBlYXRlZCBhcyBuZWVkZWQgZGVwZW5k aW5nIG9uIHRoZSBudW1iZXIgb2YKICAgbXVsdGlwbGV4aW5nIGxldmVscy4gIEluIHRoZSBmb2xs b3dpbmcsIHRoZSB0ZXJtICJtdWx0aXBsZXhpbmcgdHJlZSIKICAgaXMgdXNlZCB0byBpZGVudGlm eSBhIG11bHRpcGxleGluZyBoaWVyYXJjaHkgd2hlcmUgdGhlIHJvb3QgaXMgYWx3YXlzCiAgIGEg c2VydmVyIE9EVWsvT1RVayBhbmQgYW55IG90aGVyIHN1cHBvcnRlZCBtdWx0aXBsZXhlZCBjb250 YWluZXIgaXMKICAgcmVwcmVzZW50ZWQgd2l0aCBpbmNyZWFzaW5nIGdyYW51bGFyaXR5IHVudGls IHJlYWNoaW5nIHRoZSBsZWFmIG9mCiAgIHRoZSB0cmVlLiAgVGhlIHRyZWUgY2FuIGJlIHN0cnVj dHVyZWQgd2l0aCBtb3JlIHRoYW4gb25lIGJyYW5jaCBpZgogICB0aGUgc2VydmVyIE9EVWsvT1RV ayBzdXBwb3J0cyBtb3JlIHRoYW4gb25lIGhpZXJhcmNoeS4KCiAgIEZvciBleGFtcGxlLCBpZiBh IG11bHRpcGxleGluZyBvciBleGFtcGxlIGEgbXVsdGlwbGV4aW5nIGhpZXJhcmNoeQogICBsaWtl IHRoZSBmb2xsb3dpbmcgb25lIGlzIGNvbnNpZGVyZWQ6CgoKCiAgICAgICAgICAgICBPRFUyIE9E VTAgICAgT0RVZmxleCBPRFUwCiAgICAgICAgICAgICAgICBcIC8gICAgICAgICAgICBcIC8KICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgIE9EVTMgICAgICAg ICAgIE9EVTIKICAgICAgICAgICAgICAgICAgXCAgICAgICAgICAgIC8KICAgICAgICAgICAgICAg ICAgIFwgICAgICAgICAgLwogICAgICAgICAgICAgICAgICAgIFwgICAgICAgIC8KICAgICAgICAg ICAgICAgICAgICAgXCAgICAgIC8KICAgICAgICAgICAgICAgICAgICAgICBPRFU0CgoKICAgVGhl IE9EVTQgaXMgdGhlIHJvb3Qgb2YgdGhlIG11eGluZyB0cmVlLCBPRFUzIGFuZCBPRFUyIGFyZSBj b250YWluZXJzCiAgIGRpcmVjdGx5IG11bHRpcGxleGVkIGludG8gdGhlIHNlcnZlciBhbmQgdGhl biBPRFUyLCBPRFUwIGFyZSB0aGUKICAgbGVhdmVzIG9mIHRoZSBPRFUzIGJyYW5jaCwgd2hpbGUg T0RVZmxleCBhbmQgT0RVMCBhcmUgdGhlIGxlYXZlcyBvZgogICB0aGUgT0RVMiBvbmUuICBUaGlz IG1lYW5zIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gaGF2ZSB0aGUgZm9sbG93aW5nCiAgIG11bHRp cGxleGluZyBjYXBhYmlsaXRpZXM6CgoKICAgICAgICAgICBPRFUyLT5PRFUzLT5PRFU0CiAgICAg ICAgICAgT0RVMC0+T0RVMy0+T0RVNAogICAgICAgICAgIE9EVWZsZXgtPk9EVTItPk9EVTQKICAg ICAgICAgICBPRFUwLT5PRFUyLT5PRFU0CgoKCkNlY2NhcmVsbGksIGV0IGFsLiAgICAgICAgIEV4 cGlyZXMgTWF5IDgsIDIwMTQgICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURy YWZ0ICAgICBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBzdXBwb3J0ICAgICAgTm92ZW1iZXIg MjAxMwoKCjMuICBURS1MaW5rIFJlcHJlc2VudGF0aW9uCgogICBHLjcwOSBPRFVrL09UVWsgTGlu a3MgYXJlIHJlcHJlc2VudGVkIGFzIFRFLUxpbmtzIGluIEdNUExTIFRyYWZmaWMKICAgRW5naW5l ZXJpbmcgVG9wb2xvZ3kgZm9yIHN1cHBvcnRpbmcgT0RVaiBsYXllciBzd2l0Y2hpbmcuICBUaGVz ZSBURS0KICAgTGlua3MgY2FuIGJlIG1vZGVsZWQgaW4gbXVsdGlwbGUgd2F5cy4KCiAgIE9UVWsg cGh5c2ljYWwgTGluayhzKSBjYW4gYmUgbW9kZWxlZCBhcyBhIFRFLUxpbmsocykuICBGaWd1cmUg MSBiZWxvdwogICBwcm92aWRlcyBhbiBpbGx1c3RyYXRpb24gb2Ygb25lIGhvcCBPVFVrIFRFLWxp bmtzLgoKCiAgICAgICAgICAgKy0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0rICAgICAg ICAgICAgICAgKy0tLS0tLS0rCiAgICAgICAgICAgfCAgT1ROICB8ICAgICAgICAgICAgICAgfCAg T1ROICB8ICAgICAgICAgICAgICAgfCAgT1ROICB8CiAgICAgICAgICAgfFN3aXRjaCB8PC0gT1RV ayBMaW5rIC0+fFN3aXRjaCB8PC0gT1RVayBMaW5rIC0+fFN3aXRjaCB8CiAgICAgICAgICAgfCAg IEEgICB8ICAgICAgICAgICAgICAgfCAgIEIgICB8ICAgICAgICAgICAgICAgfCAgIEMgICB8CiAg ICAgICAgICAgKy0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0rICAgICAgICAgICAgICAg Ky0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgfDwtLSBURS1MaW5rIC0tPnwgICAgICAgfDwt LSBURS1MaW5rIC0tPnwKCgogICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBPVFVr IFRFLUxpbmtzCgogICBJdCBpcyBwb3NzaWJsZSB0byBjcmVhdGUgVEUtTGlua3MgdGhhdCBzcGFu IG1vcmUgdGhhbiBvbmUgaG9wIGJ5CiAgIGNyZWF0aW5nIEZBcyBiZXR3ZWVuIG5vbi1hZGphY2Vu dCBub2RlcyAoc2VlIEZpZ3VyZSAyKS4gIEFzIGluIHRoZQogICBvbmUgaG9wIGNhc2UsIG11bHRp cGxlIGhvcCBURS1saW5rcyBhZHZlcnRpc2UgT0RVIHN3aXRjaGluZyBjYXBhY2l0eS4KCgogICAg ICAgICAgICstLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tKyAgICAgICAgICAgICAgICst LS0tLS0tKwogICAgICAgICAgIHwgIE9UTiAgfCAgICAgICAgICAgICAgIHwgIE9UTiAgfCAgICAg ICAgICAgICAgIHwgIE9UTiAgfAogICAgICAgICAgIHxTd2l0Y2ggfDwtIE9UVWsgTGluayAtPnxT d2l0Y2ggfDwtIE9UVWsgTGluayAtPnxTd2l0Y2ggfAogICAgICAgICAgIHwgICBBICAgfCAgICAg ICAgICAgICAgIHwgICBCICAgfCAgICAgICAgICAgICAgIHwgICBDICAgfAogICAgICAgICAgICst LS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tKwog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPRFVrIFN3aXRjaGVkCgogICAgICAgICAg ICAgICAgICAgfDwtLS0tLS0tLS0tLS0tIE9EVWsgTGluayAtLS0tLS0tLS0tLS0tPnwKICAgICAg ICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0gVEUtTGluay0tLS0tLS0tLS0tLS0tLT58CgoK ICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBNdWx0aXBsZSBob3AgVEUtTGluawoKCjQu ICBJU0NEIGZvcm1hdCBleHRlbnNpb25zCgogICBUaGUgSVNDRCBkZXNjcmliZXMgdGhlIHN3aXRj aGluZyBjYXBhYmlsaXR5IG9mIGFuIGludGVyZmFjZSBhbmQgaXMKICAgZGVmaW5lZCBpbiBbUkZD NDIwM10uICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgU3dpdGNoaW5nCiAgIENhcGFiaWxp dHkgdmFsdWUgZm9yIE9UTiBbRy43MDktMjAxMl0gYXMgZm9sbG93czoKCgogICBWYWx1ZSAgICAg ICAgICAgICAgICAgICAgICAgVHlwZQoKCgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBp cmVzIE1heSA4LCAyMDE0ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFm dCAgICAgT1NQRi1URSBleHRlbnNpb25zIGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIw MTMKCgogICAtLS0tLSAgICAgICAgICAgICAgICAgICAgICAgLS0tLQogICAxMTAgKFRCQSBieSBJ QU5BKSAgICAgICAgICAgT1ROLVRETSBjYXBhYmxlIChPVE4tVERNKQoKCiAgIFdoZW4gc3VwcG9y dGluZyB0aGUgZXh0ZW5zaW9ucyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQsIGZvciBib3RoCiAg IGZpeGVkIGFuZCBmbGV4aWJsZSBPRFVzLCB0aGUgU3dpdGNoaW5nIENhcGFiaWxpdHkgYW5kIEVu Y29kaW5nIHZhbHVlcwogICBNVVNUIGJlIHVzZWQgYXMgZm9sbG93czoKCgogICAtIFN3aXRjaGlu ZyBDYXBhYmlsaXR5ID0gT1ROLVRETQogICAtIEVuY29kaW5nIFR5cGUgPSBHLjcwOSBPRFVrIChE aWdpdGFsIFBhdGgpIGFzIGRlZmluZWQgaW4gW1JGQzQzMjhdCgoKICAgVGhlIHNhbWUgc3dpdGNo aW5nIHR5cGUgYW5kIGVuY29kaW5nIHZhbHVlcyBtdXN0IGJlIHVzZWQgZm9yIGJvdGgKICAgZml4 ZWQgYW5kIGZsZXhpYmxlIE9EVXMuICBXaGVuIFN3aXRjaGluZyBDYXBhYmlsaXR5IGFuZCBFbmNv ZGluZwogICBmaWVsZHMgYXJlIHNldCB0byB2YWx1ZXMgYXMgc3RhdGVkIGFib3ZlLCB0aGUgSW50 ZXJmYWNlIFN3aXRjaGluZwogICBDYXBhYmlsaXR5IERlc2NyaXB0b3IgTVVTVCBiZSBpbnRlcnBy ZXRlZCBhcyBkZWZpbmVkIGluIFtSRkM0MjAzXS4KCiAgIE1heGltdW0gTFNQIEJhbmR3aWR0aAoK ICAgVGhlIE1BWCBMU1AgQmFuZHdpZHRoIGZpZWxkIGlzIHVzZWQgYWNjb3JkaW5nIHRvIFtSRkM0 MjAzXTogaS5lLiwgMAogICA8PSBNQVggTFNQIEJhbmR3aWR0aCA8PSBPRFVrL09UVWssIGFuZCBp bnRlcm1lZGlhdGUgdmFsdWVzIGFyZSB0aG9zZQogICBvbiB0aGUgYnJhbmNoIG9mIE9UTiBzd2l0 Y2hpbmcgaGllcmFyY2h5IHN1cHBvcnRlZCBieSB0aGUgaW50ZXJmYWNlLgogICBGb3IgZXhhbXBs ZSwgaW4gdGhlIE9UVTQgbGluayBpdCBjb3VsZCBiZSBwb3NzaWJsZSB0byBoYXZlIE9EVTQgYXMK ICAgTUFYIExTUCBCYW5kd2lkdGggZm9yIHNvbWUgcHJpb3JpdGllcywgT0RVMyBmb3Igb3RoZXJz LCBPRFUyIGZvciBzb21lCiAgIG90aGVycywgZXRjLiAgVGhlIGJhbmR3aWR0aCB1bml0IGlzIGlu IGJ5dGVzIHBlciBzZWNvbmQgYW5kIHRoZQogICBlbmNvZGluZyBNVVNUIGJlIGluIEluc3RpdHV0 ZSBvZiBFbGVjdHJpY2FsIGFuZCBFbGVjdHJvbmljIEVuZ2luZWVycwogICAoSUVFRSkgZmxvYXRp bmcgcG9pbnQgZm9ybWF0LiAgVGhlIGRpc2NyZXRlIHZhbHVlcyBmb3IgdmFyaW91cyBPRFVzCiAg IGFyZSBzaG93biBpbiB0aGUgdGFibGUgYmVsb3cgKHBsZWFzZSBub3RlIHRoYXQgdGhlcmUgYXJl IDEwMDAgYml0cyBpbgogICBhIGtiaXQgYWNjb3JkaW5nIHRvIG5vcm1hbCBwcmFjdGljZXMgaW4g dGVsZWNvbW11bmljYXRpb25zKS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKQ2VjY2FyZWxsaSwgZXQg YWwuICAgICAgICAgRXhwaXJlcyBNYXkgOCwgMjAxNCAgICAgICAgICAgICAgICAgIFtQYWdlIDZd CgwKSW50ZXJuZXQtRHJhZnQgICAgIE9TUEYtVEUgZXh0ZW5zaW9ucyBmb3IgT1ROIHN1cHBvcnQg ICAgICBOb3ZlbWJlciAyMDEzCgoKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rCnwgICAgIE9EVSBUeXBlICAgICAg ICB8ICAgIE9EVSBub21pbmFsIGJpdCByYXRlICAgICAgfFZhbHVlIGluIEJ5dGUvU2VjfAp8ICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwoZmxvYXRp bmcgcC4gdmFsKXwKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rCnwgICAgICAgT0RVMCAgICAgICAgICB8ICAgICAg MSwyNDQsMTYwIGtiaXQvcyAgICAgICAgfCAgICAweDREMTQ1MEMwICAgfAp8ICAgICAgIE9EVTEg ICAgICAgICAgfCAyMzkvMjM4IHggMiw0ODgsMzIwIGtiaXQvcyAgIHwgICAgMHg0RDk0RjA0OCAg IHwKfCAgICAgICBPRFUyICAgICAgICAgIHwgMjM5LzIzNyB4IDksOTUzLDI4MCBrYml0L3MgICB8 ICAgIDB4NEU5NTkxMjkgICB8CnwgICAgICAgT0RVMyAgICAgICAgICB8IDIzOS8yMzYgeCAzOSw4 MTMsMTIwIGtiaXQvcyAgfCAgICAweDRGOTYzMzY3ICAgfAp8ICAgICAgIE9EVTQgICAgICAgICAg fCAyMzkvMjI3IHggOTksNTMyLDgwMCBrYml0L3MgIHwgICAgMHg1MDQzMzFFMyAgIHwKfCAgICAg ICBPRFUyZSAgICAgICAgIHwgMjM5LzIzNyB4IDEwLDMxMiw1MDAga2JpdC9zICB8ICAgIDB4NEU5 QUY3MEEgICB8CnwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgfAp8ICBPRFVmbGV4IGZvciBDQlIgICAgfCAgICAyMzkv MjM4IHggY2xpZW50IHNpZ25hbCAgIHwgICAgIE1BWCBMU1AgICAgIHwKfCAgQ2xpZW50IHNpZ25h bHMgICAgIHwgICAgICAgICAgIGJpdCByYXRlICAgICAgICAgICB8ICAgIEJBTkRXSURUSCAgICB8 CnwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgfAp8IE9EVWZsZXggZm9yIEdGUC1GICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgIE1BWCBMU1AgICAgIHwKfE1hcHBlZCBjbGllbnQgc2lnbmFsIHwg ICAgICBDb25maWd1cmVkIGJpdCByYXRlICAgICB8ICAgIEJBTkRXSURUSCAgICB8CnwgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfAp8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgIHwKfE9EVSBmbGV4IHJlc2l6YWJsZSAgIHwgICAgICBDb25m aWd1cmVkIGJpdCByYXRlICAgICB8ICAgICBNQVggTFNQICAgICB8CnwgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBCQU5EV0lEVEggICAgfAor LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLSsKCgogICBBIHNpbmdsZSBJU0NEIE1BWSBiZSB1c2VkIGZvciB0aGUgYWR2 ZXJ0aXNlbWVudCBvZiB1bmJ1bmRsZWQgb3IKICAgYnVuZGxlZCBsaW5rcyBzdXBwb3J0aW5nIGhv bW9nZW5lb3VzIG11bHRpcGxleGluZyBoaWVyYXJjaGllcyBhbmQgdGhlCiAgIHNhbWUgVFMgKFRy aWJ1dGFyeSBTbG90KSBncmFudWxhcml0eS4gIEEgZGlmZmVyZW50IElTQ0QgTVVTVCBiZSB1c2Vk CiAgIGZvciBlYWNoIGRpZmZlcmVudCBtdXhpbmcgaGllcmFyY2h5IChtdXhpbmcgdHJlZSBpbiB0 aGUgZm9sbG93aW5nCiAgIGV4YW1wbGVzKSBhbmQgZGlmZmVyZW50IFRTIGdyYW51bGFyaXR5IHN1 cHBvcnRlZCB3aXRoaW4gdGhlIFRFIExpbmsuCgogICBXaGVuIGEgcmVjZWl2ZWQgTFNBIGluY2x1 ZGVzIGEgc3ViLVRMViBub3QgZm9ybWF0dGVkIGFjY29yZGluZ2x5IHRvCiAgIHRoZSBwcmVjaXNl IHNwZWNpZmljYXRpb25zIGluIHRoaXMgZG9jdW1lbnQsIHRoZSBwcm9ibGVtIFNIT1VMRCBiZQog ICBsb2dnZWQgYW5kIHRoZSB3cm9uZ2x5IGZvcm1hdHRlZCBzdWItVExWIE1VU1QgTk9UIGJlIHVz ZWQgZm9yIHBhdGgKICAgY29tcHV0YXRpb24uCgo0LjEuICBTd2l0Y2hpbmcgQ2FwYWJpbGl0eSBT cGVjaWZpYyBJbmZvcm1hdGlvbgoKICAgVGhlIHRlY2hub2xvZ3kgc3BlY2lmaWMgcGFydCBvZiB0 aGUgT1ROLVRETSBJU0NEIG1heSBpbmNsdWRlIGEKICAgdmFyaWFibGUgbnVtYmVyIG9mIHN1Yi1U TFZzIGNhbGxlZCBCYW5kd2lkdGggc3ViLVRMVnMuICBFYWNoIHN1Yi1UTFYKICAgaXMgZW5jb2Rl ZCB3aXRoIHRoZSBzdWItVExWIGhlYWRlciBhcyBkZWZpbmVkIGluIFtSRkMzNjMwXSBzZWN0aW9u CiAgIDIuMy4yLiAgVGhlIG11eGluZyBoaWVyYXJjaHkgdHJlZSBNVVNUIGJlIGVuY29kZWQgYXMg YW4gb3JkZXIKICAgaW5kZXBlbmRlbnQgbGlzdC4gIFR3byB0eXBlcyBvZiBCYW5kd2lkdGggc3Vi LVRMViBhcmUgZGVmaW5lZCAoVEJBIGJ5CiAgIElBTkEpLiAgTm90ZSB0aGF0IHR5cGUgdmFsdWVz IGFyZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgYW5kIG5vdCBpbgogICBbUkZDMzYzMF0uCgog ICAgICAtIFR5cGUgMSAtIFVucmVzZXJ2ZWQgQmFuZHdpZHRoIGZvciBmaXhlZCBjb250YWluZXJz CgogICAgICAtIFR5cGUgMiAtIFVucmVzZXJ2ZWQvTUFYIExTUCBCYW5kd2lkdGggZm9yIGZsZXhp YmxlIGNvbnRhaW5lcnMKCgoKCkNlY2NhcmVsbGksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTWF5 IDgsIDIwMTQgICAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICBP U1BGLVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBzdXBwb3J0ICAgICAgTm92ZW1iZXIgMjAxMwoKCiAg IFRoZSBTd2l0Y2hpbmcgQ2FwYWJpbGl0eS1TcGVjaWZpYyBJbmZvcm1hdGlvbiAoU0NTSSkgTVVT VCBpbmNsdWRlIG9uZQogICBUeXBlIDEgc3ViLVRMViBmb3IgZWFjaCBmaXhlZCBjb250YWluZXIg YW5kIG9uZSBUeXBlIDIgc3ViLVRMViBmb3IKICAgZWFjaCB2YXJpYWJsZSBjb250YWluZXIuICBF YWNoIGNvbnRhaW5lciB0eXBlIGlzIGlkZW50aWZpZWQgYnkgYQogICBTaWduYWwgVHlwZS4gIFNp Z25hbCBUeXBlIHZhbHVlcyBhcmUgZGVmaW5lZCBpbiBbT1ROLVNJR10uCgogICBXaXRoIHJlc3Bl Y3QgdG8gT0RVZmxleCwgdGhyZWUgZGlmZmVyZW50IHNpZ25hbCB0eXBlcyBhcmUgYWxsb3dlZDog MjAKICAgLSBPRFVmbGV4IENvbnN0YW50IEJpdCBSYXRlIChDQlIpLCAyMSAtIE9EVWZsZXggR2Vu ZXJpYyBGcmFtaW5nCiAgIFByb2NlZHVyZS1GcmFtZSBtYXBwZWQgKEdGUC1GKSByZXNpemFibGUg YW5kIDIyIC0gT0RVZmxleCAoR0ZQLUYpCiAgIG5vbi1yZXNpemFibGUuICBFYWNoIE1VU1QgYWx3 YXlzIGJlIGFkdmVydGlzZWQgaW4gc2VwYXJhdGUgVHlwZSAyCiAgIHN1Yi1UTFZzIGFzIGVhY2gg dXNlcyBkaWZmZXJlbnQgYWRhcHRhdGlvbiBmdW5jdGlvbnMgW0cuODA1XS4gIEluIHRoZQogICBj YXNlIHRoYXQgYm90aCBHRlAtRiByZXNpemFibGUgYW5kIG5vbi1yZXNpemFibGUgKGkuZS4sIDIx IGFuZCAyMikKICAgYXJlIHN1cHBvcnRlZCwgb25seSBTaWduYWwgVHlwZSAyMSBTSEFMTCBiZSBh ZHZlcnRpc2VkIGFzIHRoaXMgdHlwZQogICBhbHNvIGltcGxpZXMgc3VwcG9ydCBmb3IgdHlwZSAy MiBhZGFwdGF0aW9uLgoKNC4xLjEuICBTd2l0Y2hpbmcgQ2FwYWJpbGl0eSBTcGVjaWZpYyBJbmZv cm1hdGlvbiBmb3IgZml4ZWQgY29udGFpbmVycwoKICAgVGhlIGZvcm1hdCBvZiB0aGUgQmFuZHdp ZHRoIHN1Yi1UTFYgZm9yIGZpeGVkIGNvbnRhaW5lcnMgaXMgZGVwaWN0ZWQKICAgaW4gdGhlIGZv bGxvd2luZyBmaWd1cmU6CgoKICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg ICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAg ICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAg ICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICB8ICBTaWduYWwgdHlwZSAgfCBOdW0gb2Ygc3RhZ2VzIHxUfFN8 IFRTRyB8IFJlcyB8ICAgIFByaW9yaXR5ICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgIFN0YWdlIzEg ICAgfCAgICAgIC4uLiAgICAgIHwgICBTdGFnZSNOICAgICB8ICAgIFBhZGRpbmcgICAgfAogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKwogICB8ICBVbnJlc2VydmVkIE9EVWogYXQgUHJpbyAwICAgIHwgICAgICAgICAgICAg Li4uLi4gICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICBVbnJlc2VydmVkIE9EVWogYXQg UHJpbyA3ICAgIHwgICAgIFVucmVzZXJ2ZWQgUGFkZGluZyAgICAgICAgfAogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoK CgogICAgICAgICAgICAgICAgICBGaWd1cmUgMzogQmFuZHdpZHRoIHN1Yi1UTFYgLSBUeXBlIDEg LQoKICAgVGhlIHZhbHVlcyBvZiB0aGUgZmllbGRzIHNob3duIGluIGZpZ3VyZSA0IGFyZSBleHBs YWluZWQgaW4gc2VjdGlvbgogICA0LjEuMy4KCjQuMS4yLiAgU3dpdGNoaW5nIENhcGFiaWxpdHkg U3BlY2lmaWMgSW5mb3JtYXRpb24gZm9yIHZhcmlhYmxlCiAgICAgICAgY29udGFpbmVycwoKICAg VGhlIGZvcm1hdCBvZiB0aGUgQmFuZHdpZHRoIHN1Yi1UTFYgZm9yIHZhcmlhYmxlIGNvbnRhaW5l cnMgaXMKICAgZGVwaWN0ZWQgaW4gdGhlIGZvbGxvd2luZyBmaWd1cmU6CgoKCgoKQ2VjY2FyZWxs aSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBNYXkgOCwgMjAxNCAgICAgICAgICAgICAgICAgIFtQ YWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgIE9TUEYtVEUgZXh0ZW5zaW9ucyBmb3IgT1ROIHN1 cHBvcnQgICAgICBOb3ZlbWJlciAyMDEzCgoKICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAg ICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwogICB8ICAgIFR5cGUgPSAyIChVbnJlcy9NQVgtdmFyKSAgIHwgICAgICAgICAgICAgTGVuZ3Ro ICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICBTaWduYWwgdHlwZSAgfCBOdW0gb2Ygc3Rh Z2VzIHxUfFN8IFRTRyB8IFJlcyB8ICAgIFByaW9yaXR5ICAgfAogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAg IFN0YWdlIzEgICAgfCAgICAgIC4uLiAgICAgIHwgICBTdGFnZSNOICAgICB8ICAgIFBhZGRpbmcg ICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgIFVucmVzZXJ2ZWQgQmFuZHdpZHRo IGF0IHByaW9yaXR5IDAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKwogICB8ICAgICAgICAgICAgICAgIFVucmVzZXJ2ZWQgQmFuZHdpZHRoIGF0IHByaW9y aXR5IDcgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgICBNQVgg TFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAwICAgICAgICAgICAgICAgfAogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgICBNQVggTFNQIEJhbmR3 aWR0aCBhdCBwcmlvcml0eSA3ICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKCiAgICAgICAg ICAgICAgICAgIEZpZ3VyZSA0OiBCYW5kd2lkdGggc3ViLVRMViAtIFR5cGUgMiAtCgogICBUaGUg dmFsdWVzIG9mIHRoZSBmaWVsZHMgc2hvd24gaW4gZmlndXJlIDQgYXJlIGV4cGxhaW5lZCBpbiBz ZWN0aW9uCiAgIDQuMS4zLgoKNC4xLjMuICBTd2l0Y2hpbmcgQ2FwYWJpbGl0eSBTcGVjaWZpYyBJ bmZvcm1hdGlvbiAtIEZpZWxkIHZhbHVlcyBhbmQKICAgICAgICBleHBsYW5hdGlvbgoKICAgVGhl IGZpZWxkcyBpbiB0aGUgQmFuZHdpZHRoIHN1Yi1UTFYgTVVTVCBiZSBmaWxsZWQgYXMgZm9sbG93 czoKCiAgICAgIC0gU2lnbmFsIFR5cGUgKDggYml0cyk6IEluZGljYXRlcyB0aGUgT0RVIHR5cGUg YmVpbmcgYWR2ZXJ0aXNlZC4KICAgICAgVmFsdWVzIGFyZSBkZWZpbmVkIGluIFtPVE4tU0lHXS4K CiAgICAgIC0gTnVtYmVyIG9mIHN0YWdlcyAoOCBiaXRzKTogVGhpcyBmaWVsZCBpbmRpY2F0ZXMg dGhlIG51bWJlciBvZgogICAgICBtdWx0aXBsZXhpbmcgc3RhZ2VzIHVzZWQgdG8gdHJhbnNwb3J0 IHRoZSBpbmRpY2F0ZWQgc2lnbmFsIHR5cGUuCiAgICAgIEl0IE1VU1QgYmUgc2V0IHRvIHRoZSBu dW1iZXIgb2Ygc3RhZ2VzIHJlcHJlc2VudGVkIGluIHRoZSBzdWItVExWLgoKICAgICAgLSBGbGFn cyAoOCBiaXRzKToKCiAgICAgICAgIC0gVCBGbGFnIChiaXQgMTcpOiBJbmRpY2F0ZXMgd2hldGhl ciB0aGUgYWR2ZXJ0aXNlZCBiYW5kd2lkdGgKICAgICAgICAgY2FuIGJlIHRlcm1pbmF0ZWQuICBX aGVuIHRoZSBzaWduYWwgdHlwZSBjYW4gYmUgdGVybWluYXRlZCBUCiAgICAgICAgIE1VU1QgYmUg c2V0LCB3aGlsZSB3aGVuIHRoZSBzaWduYWwgdHlwZSBjYW5ub3QgYmUgdGVybWluYXRlZCBUCiAg ICAgICAgIE1VU1QgYmUgY2xlYXJlZC4KCgoKCgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBF eHBpcmVzIE1heSA4LCAyMDE0ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1E cmFmdCAgICAgT1NQRi1URSBleHRlbnNpb25zIGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVy IDIwMTMKCgogICAgICAgICAtIFMgRmxhZyAoYml0IDE4KTogSW5kaWNhdGVzIHdoZXRoZXIgdGhl IGFkdmVydGlzZWQgYmFuZHdpZHRoCiAgICAgICAgIGNhbiBiZSBzd2l0Y2hlZC4gIFdoZW4gdGhl IHNpZ25hbCB0eXBlIGNhbiBiZSBzd2l0Y2hlZCBTIE1VU1QKICAgICAgICAgYmUgc2V0LCB3aGls ZSB3aGVuIHRoZSBzaWduYWwgdHlwZSBjYW5ub3QgYmUgc3dpdGNoZWQgUyBNVVNUIGJlCiAgICAg ICAgIGNsZWFyZWQuCgogICAgICAgICBUaGUgdmFsdWUgMCBpbiBib3RoIFQgYW5kIFMgYml0cyBN VVNUIE5PVCBiZSB1c2VkLgoKICAgICAgLSBUUyBHcmFudWxhcml0eTogVHJpYnV0YXJ5IFNsb3Qg R3JhbnVsYXJpdHkgKDMgYml0cyk6IFVzZWQgZm9yCiAgICAgIHRoZSBhZHZlcnRpc2VtZW50IG9m IHRoZSBzdXBwb3J0ZWQgVHJpYnV0YXJ5IFNsb3QgZ3JhbnVsYXJpdHkuCiAgICAgIFRoZSBmb2xs b3dpbmcgdmFsdWVzIE1VU1QgYmUgdXNlZDoKCiAgICAgICAgIC0gMCAtIElnbm9yZWQKCiAgICAg ICAgIC0gMSAtIDEuMjVHYnBzLzIuNUdicHMKCiAgICAgICAgIC0gMiAtIDIuNUdicHMgb25seQoK ICAgICAgICAgLSAzIC0gMS4yNUdicHMgb25seQoKICAgICAgICAgLSA0LTcgLSBSZXNlcnZlZAoK ICAgICAgQSB2YWx1ZSBvZiAxIE1VU1QgYmUgdXNlZCBvbiBpbnRlcmZhY2VzIHdoaWNoIGFyZSBj b25maWd1cmVkIHRvCiAgICAgIHN1cHBvcnQgdGhlIGZhbGwgYmFjayBwcm9jZWR1cmVzIGRlZmlu ZWQgaW4gW0cuNzk4LWEyXS4gIEEgdmFsdWUKICAgICAgb2YgMiBNVVNUIGJlIHVzZWQgb24gaW50 ZXJmYWNlcyB0aGF0IG9ubHkgc3VwcG9ydCAyLjVHYnBzIHRpbWUKICAgICAgc2xvdHMsIHN1Y2gg YXMgW1JGQzQzMjhdIGludGVyZmFjZXMuICBBIHZhbHVlIG9mIDMgTVVTVCBiZSB1c2VkIG9uCiAg ICAgIGludGVyZmFjZXMgdGhhdCBhcmUgY29uZmlndXJlZCB0byBvbmx5IHN1cHBvcnQgMS4yNUdi cHMgdGltZQogICAgICBzbG90cy4gIEEgdmFsdWUgb2YgMCBNVVNUIGJlIHVzZWQgZm9yIG5vbi1t dWx0aXBsZXhlZCBzaWduYWwgdHlwZXMKICAgICAgKGkuZS4sIGEgbm9uLU9UTiBjbGllbnQpLgoK ICAgICAgLSBSZXMgKDMgYml0cyk6IHJlc2VydmVkIGJpdHMuICBNVVNUIGJlIHNldCB0byAwIGFu ZCBpZ25vcmVkIG9uCiAgICAgIHJlY2VpcHQuCgogICAgICAtIFByaW9yaXR5ICg4IGJpdHMpOiBB IGJpdG1hcCB1c2VkIHRvIGluZGljYXRlIHdoaWNoIHByaW9yaXRpZXMKICAgICAgYXJlIGJlaW5n IGFkdmVydGlzZWQuICBUaGUgYml0bWFwIGlzIGluIGFzY2VuZGluZyBvcmRlciwgd2l0aCB0aGUK ICAgICAgbGVmdG1vc3QgYml0IHJlcHJlc2VudGluZyBwcmlvcml0eSBsZXZlbCAwIChpLmUuLCB0 aGUgaGlnaGVzdCkgYW5kCiAgICAgIHRoZSByaWdodG1vc3QgYml0IHJlcHJlc2VudGluZyBwcmlv cml0eSBsZXZlbCA3IChpLmUuLCB0aGUKICAgICAgbG93ZXN0KS4gIEEgYml0IE1VU1QgYmUgc2V0 ICgxKSBjb3JyZXNwb25kaW5nIHRvIGVhY2ggcHJpb3JpdHkKICAgICAgcmVwcmVzZW50ZWQgaW4g dGhlIHN1Yi1UTFYsIGFuZCBNVVNUIE5PVCBiZSBzZXQgKDApIHdoZW4gdGhlCiAgICAgIGNvcnJl c3BvbmRpbmcgcHJpb3JpdHkgaXMgbm90IHJlcHJlc2VudGVkLiAgQXQgbGVhc3Qgb25lIHByaW9y aXR5CiAgICAgIGxldmVsIE1VU1QgYmUgYWR2ZXJ0aXNlZCB0aGF0LCB1bmxlc3Mgb3ZlcnJpZGRl biBieSBsb2NhbCBwb2xpY3ksCiAgICAgIFNIQUxMIGJlIGF0IHByaW9yaXR5IGxldmVsIDAuCgog ICAgICAtIFN0YWdlICg4IGJpdHMpOiBFYWNoIFN0YWdlIGZpZWxkIGluZGljYXRlcyBhIHNpZ25h bCB0eXBlIGluIHRoZQogICAgICBtdWx0aXBsZXhpbmcgaGllcmFyY2h5IHVzZWQgdG8gdHJhbnNw b3J0IHRoZSBzaWduYWwgaW5kaWNhdGVkIGluCiAgICAgIHRoZSBTaWduYWwgVHlwZSBmaWVsZC4g IFRoZSBudW1iZXIgb2YgU3RhZ2UgZmllbGRzIGluY2x1ZGVkIGluIGEKICAgICAgc3ViLVRMViBN VVNUIGVxdWFsIHRoZSB2YWx1ZSBvZiB0aGUgTnVtYmVyIG9mIFN0YWdlcyBmaWVsZC4gIFRoZQog ICAgICBTdGFnZSBmaWVsZHMgTVVTVCBiZSBvcmRlcmVkIHRvIG1hdGNoIHRoZSBkYXRhIHBsYW5l IGluIGFzY2VuZGluZwogICAgICBvcmRlciAoZnJvbSB0aGUgbG93ZXN0IG9yZGVyIE9EVSB0byB0 aGUgaGlnaGVzdCBvcmRlciBPRFUpLiAgVGhlCgoKCkNlY2NhcmVsbGksIGV0IGFsLiAgICAgICAg IEV4cGlyZXMgTWF5IDgsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0 LURyYWZ0ICAgICBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBzdXBwb3J0ICAgICAgTm92ZW1i ZXIgMjAxMwoKCiAgICAgIHZhbHVlcyBvZiB0aGUgU3RhZ2UgZmllbGQgYXJlIHRoZSBzYW1lIGFz IHRob3NlIGRlZmluZWQgZm9yIHRoZQogICAgICBTaWduYWwgVHlwZSBmaWVsZC4gIFdoZW4gdGhl IE51bWJlciBvZiBzdGFnZSBmaWVsZCBjYXJyaWVzIGEgMCwKICAgICAgdGhlbiB0aGUgU3RhZ2Ug YW5kIFBhZGRpbmcgZmllbGRzIE1VU1QgYmUgb21pdHRlZC4KCiAgICAgIC0gUGFkZGluZyAodmFy aWFibGUpOiBUaGUgUGFkZGluZyBmaWVsZCBpcyB1c2VkIHRvIGVuc3VyZSB0aGUgMzIKICAgICAg Yml0IGFsaWdubWVudCBvZiBzdGFnZSBmaWVsZHMuICBUaGUgbGVuZ3RoIG9mIHRoZSBQYWRkaW5n IGZpZWxkIGlzCiAgICAgIGFsd2F5cyBhIG11bHRpcGxlIG9mIDggYml0cyAoMSBieXRlKS4gIEl0 cyBsZW5ndGggY2FuIGJlCiAgICAgIGNhbGN1bGF0ZWQsIGluIGJ5dGVzLCBhczogNCAtICggInZh bHVlIG9mIE51bWJlciBvZiBTdGFnZXMgZmllbGQiCiAgICAgICUgNCkuICBUaGUgUGFkZGluZyBm aWVsZCBNVVNUIGJlIHNldCB0byBhIHplcm8gKDApIHZhbHVlIG9uCiAgICAgIHRyYW5zbWlzc2lv biBhbmQgTVVTVCBiZSBpZ25vcmVkIG9uIHJlY2VpcHQuCgogICAgICAtIFVucmVzZXJ2ZWQgT0RV aiAoMTYgYml0cyk6IFRoaXMgZmllbGQgaW5kaWNhdGVzIHRoZSBVbnJlc2VydmVkCiAgICAgIEJh bmR3aWR0aCBhdCBhIHBhcnRpY3VsYXIgcHJpb3JpdHkgbGV2ZWwuICBUaGlzIGZpZWxkIE1VU1Qg YmUgc2V0CiAgICAgIHRvIHRoZSBudW1iZXIgb2YgT0RVcyBhdCB0aGUgaW5kaWNhdGVkIHRoZSBT aWduYWwgVHlwZSBmb3IgYQogICAgICBwYXJ0aWN1bGFyIHByaW9yaXR5IGxldmVsLiAgT25lIGZp ZWxkIE1VU1QgYmUgcHJlc2VudCBmb3IgZWFjaCBiaXQKICAgICAgc2V0IGluIHRoZSBQcmlvcml0 eSBmaWVsZCwgYW5kIGlzIG9yZGVyZWQgdG8gbWF0Y2ggdGhlIFByaW9yaXR5CiAgICAgIGZpZWxk LiAgRmllbGRzIE1VU1QgTk9UIGJlIHByZXNlbnQgZm9yIHByaW9yaXR5IGxldmVscyB0aGF0IGFy ZQogICAgICBub3QgaW5kaWNhdGVkIGluIHRoZSBQcmlvcml0eSBmaWVsZC4KCiAgICAgIC0gVW5y ZXNlcnZlZCBQYWRkaW5nICgxNiBiaXRzKTogVGhlIFBhZGRpbmcgZmllbGQgaXMgdXNlZCB0bwog ICAgICBlbnN1cmUgdGhlIDMyIGJpdCBhbGlnbm1lbnQgb2YgVW5yZXNlcnZlZCBPRFVqIGZpZWxk cy4gIFdoZW4KICAgICAgcHJlc2VudCB0aGUgVW5yZXNlcnZlZCBQYWRkaW5nIGZpZWxkIGlzIDE2 IGJpdHMgKDIgYnl0ZSkgbG9uZy4KICAgICAgV2hlbiB0aGUgbnVtYmVyIG9mIHByaW9yaXRpZXMg aXMgb2RkLCB0aGUgVW5yZXNlcnZlZCBQYWRkaW5nIGZpZWxkCiAgICAgIE1VU1QgYmUgaW5jbHVk ZWQuICBXaGVuIHRoZSBudW1iZXIgb2YgcHJpb3JpdGllcyBpcyBldmVuLCB0aGUKICAgICAgVW5y ZXNlcnZlZCBQYWRkaW5nIE1VU1QgYmUgb21pdHRlZC4KCiAgICAgIC0gVW5yZXNlcnZlZCBCYW5k d2lkdGggKDMyIGJpdHMpOiBUaGlzIGZpZWxkIGluZGljYXRlcyB0aGUKICAgICAgVW5yZXNlcnZl ZCBCYW5kd2lkdGggYXQgYSBwYXJ0aWN1bGFyIHByaW9yaXR5IGxldmVsLiAgVGhpcyBmaWVsZAog ICAgICBNVVNUIGJlIHNldCB0byB0aGUgYmFuZHdpZHRoLCBpbiBCeXRlcy9zZWMgaW4gSUVFRSBm bG9hdGluZyBwb2ludAogICAgICBmb3JtYXQsIGF2YWlsYWJsZSBhdCB0aGUgaW5kaWNhdGVkIFNp Z25hbCBUeXBlIGZvciBhIHBhcnRpY3VsYXIKICAgICAgcHJpb3JpdHkgbGV2ZWwuICBPbmUgZmll bGQgTVVTVCBiZSBwcmVzZW50IGZvciBlYWNoIGJpdCBzZXQgaW4gdGhlCiAgICAgIFByaW9yaXR5 IGZpZWxkLCBhbmQgaXMgb3JkZXJlZCB0byBtYXRjaCB0aGUgUHJpb3JpdHkgZmllbGQuCiAgICAg IEZpZWxkcyBNVVNUIE5PVCBiZSBwcmVzZW50IGZvciBwcmlvcml0eSBsZXZlbHMgdGhhdCBhcmUg bm90CiAgICAgIGluZGljYXRlZCBpbiB0aGUgUHJpb3JpdHkgZmllbGQuCgogICAgICAtIE1heGlt dW0gTFNQIEJhbmR3aWR0aCAoMzIgYml0KTogVGhpcyBmaWVsZCBpbmRpY2F0ZXMgdGhlIG1heGlt dW0KICAgICAgYmFuZHdpZHRoIHRoYXQgY2FuIGJlIGFsbG9jYXRlZCBmb3IgYSBzaW5nbGUgTFNQ IGF0IGEgcGFydGljdWxhcgogICAgICBwcmlvcml0eSBsZXZlbC4gIFRoaXMgZmllbGQgTVVTVCBi ZSBzZXQgdG8gdGhlIG1heGltdW0gYmFuZHdpZHRoLAogICAgICBpbiBCeXRlcy9zZWMgaW4gSUVF RSBmbG9hdGluZyBwb2ludCBmb3JtYXQsIGF2YWlsYWJsZSB0byBhIHNpbmdsZQogICAgICBMU1Ag YXQgdGhlIGluZGljYXRlZCBTaWduYWwgVHlwZSBmb3IgYSBwYXJ0aWN1bGFyIHByaW9yaXR5IGxl dmVsLgogICAgICBPbmUgZmllbGQgTVVTVCBiZSBwcmVzZW50IGZvciBlYWNoIGJpdCBzZXQgaW4g dGhlIFByaW9yaXR5IGZpZWxkLAogICAgICBhbmQgaXMgb3JkZXJlZCB0byBtYXRjaCB0aGUgUHJp b3JpdHkgZmllbGQuICBGaWVsZHMgTVVTVCBOT1QgYmUKICAgICAgcHJlc2VudCBmb3IgcHJpb3Jp dHkgbGV2ZWxzIHRoYXQgYXJlIG5vdCBpbmRpY2F0ZWQgaW4gdGhlIFByaW9yaXR5CiAgICAgIGZp ZWxkLiAgVGhlIGFkdmVydGlzZW1lbnQgb2YgdGhlIE1BWCBMU1AgQmFuZHdpZHRoIE1VU1QgdGFr ZSBpbnRvCiAgICAgIGFjY291bnQgSE8gT1BVayBiaXQgcmF0ZSB0b2xlcmFuY2UgYW5kIGJlIGNh bGN1bGF0ZWQgYWNjb3JkaW5nIHRvCiAgICAgIHRoZSBmb2xsb3dpbmcgZm9ybXVsYToKCgoKCgpD ZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE1heSA4LCAyMDE0ICAgICAgICAgICAg ICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgT1NQRi1URSBleHRlbnNpb25zIGZv ciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIwMTMKCgogICAgICAgICBNYXggTFNQIEJXID0g KCMgYXZhaWxhYmxlIFRTcykgKiAoT0RUVWsudHMgbm9taW5hbCBiaXQgcmF0ZSkgKgogICAgICAg ICAoMS1ITyBPUFVrIGJpdCByYXRlIHRvbGVyYW5jZSkKCgo1LiAgRXhhbXBsZXMKCiAgIFRoZSBl eGFtcGxlcyBpbiB0aGUgZm9sbG93aW5nIHBhZ2VzIGFyZSBub3Qgbm9ybWF0aXZlIGFuZCBhcmUg bm90CiAgIGludGVuZGVkIHRvIGltcGx5IG9yIG1hbmRhdGUgYW55IHNwZWNpZmljIGltcGxlbWVu dGF0aW9uLgoKNS4xLiAgTUFYIExTUCBCYW5kd2lkdGggZmllbGRzIGluIHRoZSBJU0NECgogICBU aGlzIGV4YW1wbGUgc2hvd3MgaG93IHRoZSBNQVggTFNQIEJhbmR3aWR0aCBmaWVsZHMgb2YgdGhl IElTQ0QgYXJlCiAgIGZpbGxlZCBhY2NvcmRpbmdseSB0byB0aGUgZXZvbHZpbmcgb2YgdGhlIFRF LWxpbmsgYmFuZHdpZHRoCiAgIG9jY3VwYW5jeS4gIEluIHRoZSBleGFtcGxlIGFuIE9UVTQgbGlu ayBpcyBjb25zaWRlcmVkLCB3aXRoIHN1cHBvcnRlZAogICBwcmlvcml0aWVzIDAsMiw0LDcgYW5k IG11eGluZyBoaWVyYXJjaHkgT0RVMS0+T0RVMi0+T0RVMy0+T0RVNC4KCiAgIEF0IHRpbWUgVDAs IHdpdGggdGhlIGxpbmsgY29tcGxldGVseSBmcmVlLCB0aGUgYWR2ZXJ0aXNlbWVudCB3b3VsZAog ICBiZToKCgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgU3dDYXA9T1ROX1RE TSB8IEVuY29kaW5nID0gMTIgfCAgICBSZXNlcnZlZCAoYWxsIHplcm9zKSAgICAgICB8CiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgIHwgICAgICAgICAgICAgTUFYIExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgMCA9 IDEwMEdicHMgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgTUFYIExTUCBC YW5kd2lkdGggYXQgcHJpb3JpdHkgMSA9IDAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg IHwgICAgICAgICAgICAgTUFYIExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgMiA9IDEwMEdicHMg ICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgTUFYIExTUCBCYW5kd2lkdGgg YXQgcHJpb3JpdHkgMyA9IDAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAg ICAgICAgTUFYIExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgNCA9IDEwMEdicHMgICAgICAgICB8 CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgTUFYIExTUCBCYW5kd2lkdGggYXQgcHJpb3Jp dHkgNSA9IDAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgTUFY IExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgNiA9IDAgICAgICAgICAgICAgICB8CiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgIHwgICAgICAgICAgICAgTUFYIExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgNyA9IDEw MEdicHMgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgU3dpdGNoaW5nIENh cGFiaWxpdHkgU3BlY2lmaWMgSW5mb3JtYXRpb24gICAgICAgICB8CiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAodmFyaWFibGUgbGVuZ3RoKSAgICAgICAgICAgICAgICAgICAgICB8CiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCgoKICAgICBGaWd1cmUgNTogRXhhbXBsZSAxIC0gTUFYIExTUCBCYW5kd2lkdGggZmll bGRzIGluIHRoZSBJU0NEIGF0IFQwCgoKCgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBp cmVzIE1heSA4LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFm dCAgICAgT1NQRi1URSBleHRlbnNpb25zIGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIw MTMKCgogICBBdCB0aW1lIFQxLCBhbiBPRFUzIGF0IHByaW9yaXR5IDIgaXMgc2V0LXVwLCBzbyBm b3IgcHJpb3JpdHkgMCB0aGUKICAgTUFYIExTUCBCYW5kd2lkdGggaXMgc3RpbGwgZXF1YWwgdG8g dGhlIE9EVTQgYmFuZHdpZHRoLCB3aGlsZSBmb3IKICAgcHJpb3JpdGllcyBmcm9tIDIgdG8gNyAo ZXhjbHVkaW5nIHRoZSBub24tc3VwcG9ydGVkIG9uZXMpIHRoZSBNQVggTFNQCiAgIEJhbmR3aWR0 aCBpcyBlcXVhbCB0byBPRFUzLCBhcyBubyBtb3JlIE9EVTRzIGFyZSBhdmFpbGFibGUgYW5kIHRo ZQogICBuZXh0IHN1cHBvcnRlZCBPRFVqIGluIHRoZSBoaWVyYXJjaHkgaXMgT0RVMy4gIFRoZSBh ZHZlcnRpc2VtZW50IGlzCiAgIHVwZGF0ZWQgYXMgZm9sbG93czoKCgogICAgMCAgICAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgIHwgU3dDYXA9T1ROX1RETSB8IEVuY29kaW5nID0gMTIgfCAgICBS ZXNlcnZlZCAoYWxsIHplcm9zKSAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAg TUFYIExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgMCA9IDEwMEdicHMgICAgICAgICB8CiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgIHwgICAgICAgICAgICAgTUFYIExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgMSA9 IDAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgTUFYIExTUCBC YW5kd2lkdGggYXQgcHJpb3JpdHkgMiA9IDQwR2JwcyAgICAgICAgICB8CiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg IHwgICAgICAgICAgICAgTUFYIExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgMyA9IDAgICAgICAg ICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgTUFYIExTUCBCYW5kd2lkdGgg YXQgcHJpb3JpdHkgNCA9IDQwR2JwcyAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAg ICAgICAgTUFYIExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgNSA9IDAgICAgICAgICAgICAgICB8 CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgTUFYIExTUCBCYW5kd2lkdGggYXQgcHJpb3Jp dHkgNiA9IDAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgTUFY IExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgNyA9IDQwR2JwcyAgICAgICAgICB8CiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgIHwgICAgICAgICAgICAgU3dpdGNoaW5nIENhcGFiaWxpdHkgU3BlY2lmaWMgSW5mb3Jt YXRpb24gICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAodmFyaWFibGUgbGVu Z3RoKSAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgoKICAgICBGaWd1cmUgNjog RXhhbXBsZSAxIC0gTUFYIExTUCBCYW5kd2lkdGggZmllbGRzIGluIHRoZSBJU0NEICBhdCBUMQoK ICAgQXQgdGltZSBUMiwgYW4gT0RVMiBhdCBwcmlvcml0eSA0IGlzIHNldC11cC4gIFRoZSBmaXJz dCBPRFUzIGlzIG5vCiAgIGxvbmdlciBhdmFpbGFibGUgc2luY2UgVDEsIGFzIGl0IHdhcyBrZXB0 IGJ5IHRoZSBPRFUzIExTUCwgd2hpbGUgdGhlCiAgIHNlY29uZCBpcyBubyBtb3JlIGF2YWlsYWJs ZSBhbmQganVzdCAzIE9EVTIgYXJlIGxlZnQgaW4gaXQuICBPRFUyIGlzCiAgIG5vdyB0aGUgTUFY IExTUCBCYW5kd2lkdGggZm9yIHByaW9yaXRpZXMgaGlnaGVyIHRoYW4gNC4gIFRoZQogICBhZHZl cnRpc2VtZW50IGlzIHVwZGF0ZWQgYXMgZm9sbG93czoKCgoKCgoKCgoKCkNlY2NhcmVsbGksIGV0 IGFsLiAgICAgICAgIEV4cGlyZXMgTWF5IDgsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDEz XQoMCkludGVybmV0LURyYWZ0ICAgICBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBzdXBwb3J0 ICAgICAgTm92ZW1iZXIgMjAxMwoKCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAg ICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg fCBTd0NhcD1PVE5fVERNIHwgRW5jb2RpbmcgPSAxMiB8ICAgIFJlc2VydmVkIChhbGwgemVyb3Mp ICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICBNQVggTFNQIEJhbmR3aWR0aCBh dCBwcmlvcml0eSAwID0gMTAwR2JwcyAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAg ICAgICBNQVggTFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAxID0gMCAgICAgICAgICAgICAgIHwK ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICBNQVggTFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0 eSAyID0gNDBHYnBzICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICBNQVgg TFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAzID0gMCAgICAgICAgICAgICAgIHwKICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKICAgfCAgICAgICAgICAgICBNQVggTFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0eSA0ID0gMTBH YnBzICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICBNQVggTFNQIEJhbmR3 aWR0aCBhdCBwcmlvcml0eSA1ID0gMCAgICAgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAg ICAgICAgICAgICBNQVggTFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0eSA2ID0gMCAgICAgICAgICAg ICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICBNQVggTFNQIEJhbmR3aWR0aCBhdCBw cmlvcml0eSA3ID0gMTBHYnBzICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAg ICBTd2l0Y2hpbmcgQ2FwYWJpbGl0eSBTcGVjaWZpYyBJbmZvcm1hdGlvbiAgICAgICAgIHwKICAg fCAgICAgICAgICAgICAgICAgICAgICAgICh2YXJpYWJsZSBsZW5ndGgpICAgICAgICAgICAgICAg ICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKCgogICAgIEZpZ3VyZSA3OiBFeGFtcGxlIDEgLSBNQVggTFNQ IEJhbmR3aWR0aCBmaWVsZHMgaW4gdGhlIElTQ0QgYXQgVDIKCjUuMi4gIEV4YW1wbGUgb2YgVCxT IGFuZCBUUyBncmFudWxhcml0eSB1dGlsaXphdGlvbgoKICAgSW4gdGhpcyBleGFtcGxlLCBhbiBp bnRlcmZhY2Ugd2l0aCBUcmlidXRhcnkgU2xvdCBUeXBlIDEuMjVHYnBzIGFuZAogICBmYWxsYmFj ayBwcm9jZWR1cmUgZW5hYmxlZCBpcyBjb25zaWRlcmVkIChUUyBncmFudWxhcml0eT0xKS4gIEl0 CiAgIHN1cHBvcnRzIHRoZSBzaW1wbGUgT0RVMS0+T0RVMi0+T0RVMyBoaWVyYXJjaHkgYW5kIHBy aW9yaXRpZXMgMCBhbmQKICAgMy4gIFN1cHBvc2UgdGhhdCBpbiB0aGlzIGludGVyZmFjZSB0aGUg T0RVMyBzaWduYWwgdHlwZSBjYW4gYmUgYm90aAogICBzd2l0Y2hlZCBvciB0ZXJtaW5hdGVkLCB0 aGUgT0RVMiBjYW4gb25seSBiZSB0ZXJtaW5hdGVkLCBhbmQgdGhlIE9EVTEKICAgc3dpdGNoZWQg b25seS4gIFBsZWFzZSBub3RlIHRoYXQgc2luY2UgdGhlIE9EVTEgaXMgbm90IGJlaW5nCiAgIGFk dmVydGlzZWQgdG8gc3VwcG9ydCBPRFUwLCB0aGUgdmFsdWUgb2YgaXMgImlnbm9yZWQiIChUUwog ICBncmFudWxhcml0eT0wKS4gIEZvciB0aGUgYWR2ZXJ0aXNlbWVudCBvZiB0aGUgY2FwYWJpbGl0 aWVzIG9mIHN1Y2gKICAgaW50ZXJmYWNlLCBhIHNpbmdsZSBJU0NEIGlzIHVzZWQgYW5kIGl0cyBm b3JtYXQgaXMgYXMgZm9sbG93czoKCgoKCgoKCgoKCgoKQ2VjY2FyZWxsaSwgZXQgYWwuICAgICAg ICAgRXhwaXJlcyBNYXkgOCwgMjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJu ZXQtRHJhZnQgICAgIE9TUEYtVEUgZXh0ZW5zaW9ucyBmb3IgT1ROIHN1cHBvcnQgICAgICBOb3Zl bWJlciAyMDEzCgoKICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAy ICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICBU eXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgIExlbmd0aCA9IDEyICAgICAgICAgfAog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVMSAgfCAgI3N0YWdlcz0gMiAgIHwwfDF8ICAwICB8 MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8IFN0YWdlIzE9T0RVMiAgfCBT dGFnZSMyPU9EVTMgIHwgICAgICAgUGFkZGluZyAoYWxsIHplcm9zKSAgICAgfAogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwogICB8ICAgICBVbnJlcyBPRFUxIGF0IFByaW8gMCAgICAgIHwgICAgIFVucmVzIE9EVTEgYXQg UHJpbyAzICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4 KSAgIHwgICAgICAgICAgIExlbmd0aCA9IDEyICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8U2ln IHR5cGU9T0RVMiAgfCAgI3N0YWdlcz0gMSAgIHwxfDB8ICAxICB8MCAwIDB8MXwwfDB8MXwwfDB8 MHwwfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICB8IFN0YWdlIzE9T0RVMyAgfCAgICAgICAgUGFkZGluZyAoYWxs IHplcm9zKSAgICAgICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICBVbnJlcyBP RFUyIGF0IFByaW8gMCAgICAgIHwgICAgIFVucmVzIE9EVTIgYXQgUHJpbyAzICAgICAgfAogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKwogICB8ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgIExl bmd0aCA9IDggICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVMyAgfCAgI3N0 YWdlcz0gMCAgIHwxfDF8ICAxICB8MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICB8ICAgICBVbnJlcyBPRFUzIGF0IFByaW8gMCAgICAgIHwgICAgIFVucmVzIE9EVTMgYXQgUHJp byAzICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwoKCiAgICAgICAgIEZpZ3VyZSA4OiBFeGFtcGxlIDIgLSBU UyBncmFudWxhcml0eSwgVCBhbmQgUyB1dGlsaXphdGlvbgoKNS4yLjEuICBFeGFtcGxlIG9mIGRp ZmZlcmVudCBUUyBHcmFudWxhcml0aWVzCgogICBJbiB0aGlzIGV4YW1wbGUsIHR3byBpbnRlcmZh Y2VzIHdpdGggaG9tb2dlbmVvdXMgaGllcmFyY2hpZXMgYnV0CiAgIGRpZmZlcmVudCBUcmlidXRh cnkgU2xvdCBUeXBlcyBhcmUgY29uc2lkZXJlZC4gIFRoZSBmaXJzdCBvbmUKICAgc3VwcG9ydHMg YSBbUkZDNDMyOF0gaW50ZXJmYWNlIChUUyBncmFudWxhcml0eT0yKSB3aGlsZSB0aGUgc2Vjb25k CiAgIG9uZSBzdXBwb3J0cyBHLjcwOS0yMDEyIGludGVyZmFjZSB3aXRoIGZhbGxiYWNrIHByb2Nl ZHVyZSBkaXNhYmxlZAogICAoVFMgZ3JhbnVsYXJpdHk9MykuICBCb3RoIG9mIHRoZW0gc3VwcG9y dCBPRFUxLT5PRFUyLT5PRFUzIGhpZXJhcmNoeQogICBhbmQgcHJpb3JpdGllcyAwIGFuZCAzLiAg U3VwcG9zZSB0aGF0IGluIHRoaXMgaW50ZXJmYWNlIHRoZSBPRFUzCiAgIHNpZ25hbCB0eXBlIGNh biBiZSBib3RoIHN3aXRjaGVkIG9yIHRlcm1pbmF0ZWQsIHRoZSBPRFUyIGNhbiBvbmx5IGJlCiAg IHRlcm1pbmF0ZWQsIGFuZCB0aGUgT0RVMSBzd2l0Y2hlZCBvbmx5LiAgRm9yIHRoZSBhZHZlcnRp c2VtZW50IG9mIHRoZQogICBjYXBhYmlsaXRpZXMgb2Ygc3VjaCBpbnRlcmZhY2VzLCB0d28gZGlm ZmVyZW50IElTQ0RzIGFyZSB1c2VkIGFuZCB0aGUKICAgZm9ybWF0IG9mIHRoZWlyIFNDU0lzIGlz IGFzIGZvbGxvd3M6CgoKCgoKCgoKCgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBpcmVz IE1heSA4LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgT1NQRi1URSBleHRlbnNpb25zIGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIwMTMK CgogICBTQ1NJIG9mIElTQ0QgMSAtIFRTIGdyYW51bGFyaXR5PTIKICAgIDAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKwogICB8ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAg ICAgIExlbmd0aCA9IDEyICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVMSAg fCAgI3N0YWdlcz0gMiAgIHwwfDF8ICAwICB8MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwogICB8IFN0YWdlIzE9T0RVMiAgfCBTdGFnZSMyPU9EVTMgIHwgICAgICAgUGFkZGluZyAo YWxsIHplcm9zKSAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICBVbnJlcyBPRFUxIGF0IFByaW8g MCAgICAgIHwgICAgIFVucmVzIE9EVTEgYXQgUHJpbyAzICAgICAgfAogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8 ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgIExlbmd0aCA9IDEyICAg ICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVMiAgfCAgI3N0YWdlcz0gMSAgIHwx fDB8ICAxICB8MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8IFN0YWdlIzE9 T0RVMyAgfCAgICAgICAgUGFkZGluZyAoYWxsIHplcm9zKSAgICAgICAgICAgICAgICAgICAgfAog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICB8ICAgICBVbnJlcyBPRFUyIGF0IFByaW8gMCAgICAgIHwgICAgIFVucmVz IE9EVTIgYXQgUHJpbyAzICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICBUeXBlID0gMSAo VW5yZXMtZml4KSAgIHwgICAgICAgICAgIExlbmd0aCA9IDggICAgICAgICAgfAogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwogICB8U2lnIHR5cGU9T0RVMyAgfCAgI3N0YWdlcz0gMCAgIHwxfDF8ICAyICB8MCAwIDB8MXww fDB8MXwwfDB8MHwwfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICBVbnJlcyBPRFUzIGF0IFByaW8gMCAg ICAgIHwgICAgIFVucmVzIE9EVTMgYXQgUHJpbyAzICAgICAgfAogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKCiAgIEZp Z3VyZSA5OiBFeGFtcGxlIDIuMSAtIERpZmZlcmVudCBUUyBHcmFudWxhcml0aWVzIHV0aWxpemF0 aW9uIC0gSVNDRAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMQoKCgoKCgoK CgoKCgoKCgoKCgoKCgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE1heSA4LCAy MDE0ICAgICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgT1NQRi1U RSBleHRlbnNpb25zIGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIwMTMKCgogICBTQ1NJ IG9mIElTQ0QgMiAtIFRTIGdyYW51bGFyaXR5PTMKICAgIDAgICAgICAgICAgICAgICAgICAgMSAg ICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwogICB8ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgIExlbmd0 aCA9IDEyICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVMSAgfCAgI3N0YWdl cz0gMiAgIHwwfDF8ICAwICB8MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8 IFN0YWdlIzE9T0RVMiAgfCBTdGFnZSMyPU9EVTMgIHwgICAgICAgUGFkZGluZyAoYWxsIHplcm9z KSAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICBVbnJlcyBPRFUxIGF0IFByaW8gMCAgICAgIHwg ICAgIFVucmVzIE9EVTEgYXQgUHJpbyAzICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICBU eXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgIExlbmd0aCA9IDEyICAgICAgICAgfAog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVMiAgfCAgI3N0YWdlcz0gMSAgIHwxfDB8ICAxICB8 MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8IFN0YWdlIzE9T0RVMyAgfCAg ICAgICAgUGFkZGluZyAoYWxsIHplcm9zKSAgICAgICAgICAgICAgICAgICAgfAogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwogICB8ICAgICBVbnJlcyBPRFUyIGF0IFByaW8gMCAgICAgIHwgICAgIFVucmVzIE9EVTIgYXQg UHJpbyAzICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4 KSAgIHwgICAgICAgICAgIExlbmd0aCA9IDggICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8U2ln IHR5cGU9T0RVMyAgfCAgI3N0YWdlcz0gMCAgIHwxfDF8ICAzICB8MCAwIDB8MXwwfDB8MXwwfDB8 MHwwfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICB8ICAgICBVbnJlcyBPRFUzIGF0IFByaW8gMCAgICAgIHwgICAg IFVucmVzIE9EVTMgYXQgUHJpbyAzICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKCiAgICAgRmlndXJlIDEw OiBFeGFtcGxlIDIuMSAtIERpZmZlcmVudCBUUyBHcmFudWxhcml0aWVzIHV0aWxpemF0aW9uIC0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElTQ0QgMgoKICAgQSBwYXJ0aWN1bGFy IGNhc2UgaW4gd2hpY2ggaGllcmFyY2hpZXMgd2l0aCB0aGUgc2FtZSBtdXhpbmcgdHJlZSBidXQK ICAgd2l0aCBkaWZmZXJlbnQgZXhwb3J0ZWQgVFMgZ3JhbnVsYXJpdHkgTVVTVCBiZSBjb25zaWRl cmVkIGFzIG5vbi0KICAgaG9tb2dlbm91cyBoaWVyYXJjaGllcy4gIFRoaXMgaXMgdGhlIGNhc2Ug aW4gd2hpY2ggYW4gSC1MUFMgYW5kIHRoZQogICBjbGllbnQgTFNQIGFyZSB0ZXJtaW5hdGVkIG9u IHRoZSBzYW1lIGVncmVzcyBub2RlLiAgV2hhdCBjYW4gaGFwcGVuCiAgIGlzIHRoYXQgYSBsb29z ZSBFeHBsaWNpdCBSb3V0ZSBPYmplY3QgKEVSTykgaXMgdXNlZCBhdCB0aGUgaG9wIHdoZXJlCiAg IHRoZSBzaWduYWxlZCBMU1AgaXMgbmVzdGVkIGludG8gdGhlIEhpZXJhcmNoaWNhbC1MU1AgKEgt TFNQKQogICAocGVudWx0aW1hdGUgaG9wIG9mIHRoZSBMU1ApLgoKICAgSW4gdGhlIGZvbGxvd2lu ZyBmaWd1cmUsIG5vZGUgQyByZWNlaXZlcyBmcm9tIEEgYSBsb29zZSBFUk8gdG93YXJkcwogICBu b2RlIEUgYW5kIG11c3QgY2hvb3NlIGJldHdlZW4gdGhlIE9EVTIgSC1MU1Agb24gaWYxIG9yIHRo ZSBvbmUgb24KICAgaWYyLiAgSW4gdGhpcyBjYXNlLCB0aGUgSC1MU1Agb24gaWYxIGV4cG9ydHMg YSBUUz0xLjI1R2JwcywgYW5kIGlmMiBhCiAgIFRTPTIuNUdicHMsIHRoZSBzZXJ2aWNlIExTUCBi ZWluZyBzaWduYWxlZCBuZWVkcyBhIDEuMjVHYnBzIHRyaWJ1dGFyeQogICBzbG90LCBvbmx5IHRo ZSBILUxTUCBvbiBpZjEgY2FuIGJlIHVzZWQgdG8gcmVhY2ggbm9kZSBFLiBGb3IgZnVydGhlcgog ICBkZXRhaWxzLCBwbGVhc2Ugc2VlIHNlY3Rpb24gNC4xIG9mIHRoZSBbT1ROLUlORk9dLgoKCgoK CgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE1heSA4LCAyMDE0ICAgICAgICAg ICAgICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFmdCAgICAgT1NQRi1URSBleHRlbnNpb25z IGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIwMTMKCgogICAgICAgICAgICAgICAgICAg ICAgICAgIE9EVTAtTFNQCiAgICAgICAgIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4rCiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT0RVMi1ILUxTUCAgICAgICAgICB8CiAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rCiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICAgICstLSstLSsgICAgICArLS0tLS0rICAgICAgKy0tLS0t KyBpZjEgICAgICstLS0tLSsgICAgICAgICArLS0tLS0rCiAgICAgIHwgICAgIHwgT1RVMyB8ICAg ICB8IE9UVTMgfCAgICAgfC0tLS0tLS0tLXwgICAgIHwtLS0tLS0tLS18ICAgICB8CiAgICAgIHwg IEEgICstLS0tLS0rICBCICArLS0tLS0tKyAgQyAgfCBpZjIgICAgIHwgIEQgIHwgICAgICAgICB8 ICBFICB8CiAgICAgIHwgICAgIHwgICAgICB8ICAgICB8ICAgICAgfCAgICAgfC0tLS0tLS0tLXwg ICAgIHwtLS0tLS0tLS18ICAgICB8CiAgICAgICstLS0tLSsgICAgICArLS0tLS0rICAgICAgKy0t LS0tKyAgICAgICAgICstLS0tLSsgICAgICAgICArLS0tLS0rCgogICAgICAgICAgICAuLi4gU2Vy dmljZSBMU1AKICAgICAgICAgICAgLS0tIEgtTFNQCgoKICAgIEZpZ3VyZSAxMTogRXhhbXBsZSAt IFNlcnZpY2UgTFNQIGFuZCBILUxTUCB0ZXJtaW5hdGluZyBvbiB0aGUgc2FtZQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIG5vZGUKCjUuMy4gIEV4YW1wbGUgb2YgT0RVZmxleCBh ZHZlcnRpc2VtZW50CgogICBJbiB0aGlzIGV4YW1wbGUsIHRoZSBhZHZlcnRpc2VtZW50IG9mIGFu IE9EVWZsZXgtPk9EVTMgaGllcmFyY2h5IGlzCiAgIHNob3duLiAgSW4gY2FzZSBvZiBPRFVmbGV4 IGFkdmVydGlzZW1lbnQsIHRoZSBNQVggTFNQIEJhbmR3aWR0aCBuZWVkcwogICB0byBiZSBhZHZl cnRpc2VkIGFuZCwgaW4gc29tZSBjYXNlcywgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFVucmVzZXJ2 ZWQKICAgYmFuZHdpZHRoIGNvdWxkIGFsc28gYmUgdXNlZnVsLiAgVGhlIGFtb3VudCBvZiBVbnJl c2VydmVkIGJhbmR3aWR0aAogICBkb2VzIG5vdCBnaXZlIGEgY2xlYXIgaW5kaWNhdGlvbiBvZiBo b3cgbWFueSBPRFVmbGV4IExTUCBjYW4gYmUgc2V0CiAgIHVwIGVpdGhlciBhdCB0aGUgTUFYIExT UCBCYW5kd2lkdGggb3IgYXQgZGlmZmVyZW50IHJhdGVzLCBhcyBpdCBnaXZlcwogICBubyBpbmZv cm1hdGlvbiBhYm91dCB0aGUgc3BhdGlhbCBhbGxvY2F0aW9uIG9mIHRoZSBmcmVlIFRTcy4KCiAg IEFuIGluZGljYXRpb24gb2YgdGhlIGFtb3VudCBvZiBVbnJlc2VydmVkIGJhbmR3aWR0aCBjb3Vs ZCBiZSB1c2VmdWwKICAgZHVyaW5nIHRoZSBwYXRoIGNvbXB1dGF0aW9uIHByb2Nlc3MsIGFzIHNo b3duIGluIHRoZSBmb2xsb3dpbmcKICAgZXhhbXBsZS4gIFN1cHBvc2luZyB0aGVyZSBhcmUgdHdv IFRFLWxpbmtzIChBIGFuZCBCKSB3aXRoIE1BWCBMU1AKICAgQmFuZHdpZHRoIGVxdWFsIHRvIDEw IEdicHMgZWFjaC4gIEluIHRoZSBjYXNlIHdoZXJlIDUwR2JwcyBvZgogICBVbnJlc2VydmVkIEJh bmR3aWR0aCBhcmUgYXZhaWxhYmxlIG9uIExpbmsgQSwgMTBHYnBzIG9uIExpbmsgQiwgYW5kIDMK ICAgT0RVZmxleCBMU1BzIG9mIDEwIEdCcHMgZWFjaCBoYXZlIHRvIGJlIHJlc3RvcmVkLCBmb3Ig c3VyZSBvbmx5IG9uZQogICBjYW4gYmUgcmVzdG9yZWQgYWxvbmcgTGluayBCIGFuZCBpdCBpcyBw cm9iYWJsZSwgYnV0IG5vdCBjZXJ0YWluLAogICB0aGF0IHR3byBvZiB0aGVtIGNhbiBiZSByZXN0 b3JlZCBhbG9uZyBMaW5rIEEuIFQsIFMgYW5kIFRTCiAgIGdyYW51bGFyaXR5IGZpZWxkcyBhcmUg bm90IHJlbGV2YW50IHRvIHRoaXMgZXhhbXBsZSAoZmlsbGVkIHdpdGggWHMpLgoKICAgSW4gdGhl IGNhc2Ugb2YgT0RVZmxleCBhZHZlcnRpc2VtZW50LCB0aGUgVHlwZSAyIEJhbmR3aWR0aCBzdWIt VExWIGlzCiAgIHVzZWQuCgoKCgoKCgoKCgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBp cmVzIE1heSA4LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5ldC1EcmFm dCAgICAgT1NQRi1URSBleHRlbnNpb25zIGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIw MTMKCgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAg ICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgVHlwZSA9IDIgKFVu cmVzL01BWC12YXIpICAgfCAgICAgICAgICAgTGVuZ3RoICA9IDcyICAgICAgICB8CiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgIHxTLiB0eXBlPU9EVWZsZXh8ICAjc3RhZ2VzPSAxICAgfFh8WHxYIFggWHwwIDAgMHwg UHJpb3JpdHkoOCkgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgIFN0YWdlIzE9T0RVMyB8ICAgICAgICAg IFBhZGRpbmcgKGFsbCB6ZXJvcykgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwg ICAgICAgICAgICAgICBVbnJlc2VydmVkIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAwICAgICAgICAg ICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICBVbnJlc2VydmVkIEJhbmR3aWR0 aCBhdCBwcmlvcml0eSAxICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAg ICAgICBVbnJlc2VydmVkIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAyICAgICAgICAgICAgICB8CiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICBVbnJlc2VydmVkIEJhbmR3aWR0aCBhdCBwcmlv cml0eSAzICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICBVbnJl c2VydmVkIEJhbmR3aWR0aCBhdCBwcmlvcml0eSA0ICAgICAgICAgICAgICB8CiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r CiAgIHwgICAgICAgICAgICAgICBVbnJlc2VydmVkIEJhbmR3aWR0aCBhdCBwcmlvcml0eSA1ICAg ICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICBVbnJlc2VydmVkIEJh bmR3aWR0aCBhdCBwcmlvcml0eSA2ICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAg ICAgICAgICAgICBVbnJlc2VydmVkIEJhbmR3aWR0aCBhdCBwcmlvcml0eSA3ICAgICAgICAgICAg ICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgIE1BWCBMU1AgIEJhbmR3aWR0aCBh dCBwcmlvcml0eSAwICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAg ICAgIE1BWCBMU1AgIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAxICAgICAgICAgICAgICB8CiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgIHwgICAgICAgICAgICAgICAgIE1BWCBMU1AgIEJhbmR3aWR0aCBhdCBwcmlvcml0 eSAyICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgIE1BWCBM U1AgIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAzICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg IHwgICAgICAgICAgICAgICAgIE1BWCBMU1AgIEJhbmR3aWR0aCBhdCBwcmlvcml0eSA0ICAgICAg ICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgIE1BWCBMU1AgIEJhbmR3 aWR0aCBhdCBwcmlvcml0eSA1ICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAg ICAgICAgICAgIE1BWCBMU1AgIEJhbmR3aWR0aCBhdCBwcmlvcml0eSA2ICAgICAgICAgICAgICB8 CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgIE1BWCBMU1AgIEJhbmR3aWR0aCBhdCBw cmlvcml0eSA3ICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgoKICAgICAgICAgICAgICAgRmln dXJlIDEyOiBFeGFtcGxlIDMgLSBPRFVmbGV4IGFkdmVydGlzZW1lbnQKCgoKCgoKCkNlY2NhcmVs bGksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTWF5IDgsIDIwMTQgICAgICAgICAgICAgICAgIFtQ YWdlIDE5XQoMCkludGVybmV0LURyYWZ0ICAgICBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBz dXBwb3J0ICAgICAgTm92ZW1iZXIgMjAxMwoKCjUuNC4gIEV4YW1wbGUgb2Ygc2luZ2xlIHN0YWdl IG11eGluZwoKICAgU3VwcG9zaW5nIHRoZXJlIGlzIDEgT1RVNCBjb21wb25lbnQgbGluayBzdXBw b3J0aW5nIHNpbmdsZSBzdGFnZQogICBtdXhpbmcgb2YgT0RVMSwgT0RVMiwgT0RVMyBhbmQgT0RV ZmxleCwgdGhlIHN1cHBvcnRlZCBoaWVyYXJjaHkgY2FuCiAgIGJlIHN1bW1hcml6ZWQgaW4gYSB0 cmVlIGFzIGluIHRoZSBmb2xsb3dpbmcgZmlndXJlLiAgRm9yIHNha2Ugb2YKICAgc2ltcGxpY2l0 eSwgd2UgYWxzbyBhc3N1bWUgdGhhdCBvbmx5IHByaW9yaXRpZXMgMCBhbmQgMyBhcmUKICAgc3Vw cG9ydGVkLiAgVCwgUyBhbmQgVFMgZ3JhbnVsYXJpdHkgZmllbGRzIGFyZSBub3QgcmVsZXZhbnQg dG8gdGhpcwogICBleGFtcGxlKGZpbGxlZCB3aXRoIFhzKS4KCgogICAgICAgICAgT0RVMSBPRFUy ICBPRFUzIE9EVWZsZXgKICAgICAgICAgICAgIFwgICBcICAgIC8gICAvCiAgICAgICAgICAgICAg XCAgIFwgIC8gICAvCiAgICAgICAgICAgICAgIFwgICBcLyAgIC8KICAgICAgICAgICAgICAgICAg T0RVNAoKCiAgIGFuZCB0aGUgcmVsYXRlZCBTQ1NJcyBhcyBmb2xsb3dzOgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE1h eSA4LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAyMF0KDApJbnRlcm5ldC1EcmFmdCAgICAg T1NQRi1URSBleHRlbnNpb25zIGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIwMTMKCgog ICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAg ICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgIFR5cGUgPSAxIChVbnJl cy1maXgpICAgfCAgICAgICAgICAgTGVuZ3RoID0gOCAgICAgICAgICB8CiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg IHxTaWcgdHlwZT1PRFU0ICB8ICAjc3RhZ2VzPSAwICAgfFh8WHxYIFggWHwwIDAgMHwxfDB8MHwx fDB8MHwwfDB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICBVbnJlcyBPRFU0IGF0IFByaW8gMCA9MSAgICAg fCAgICBVbnJlcyBPRFU0IGF0IFByaW8gMyA9MSAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAg IFR5cGUgPSAxIChVbnJlcy1maXgpICAgfCAgICAgICAgICAgTGVuZ3RoID0gMTIgICAgICAgICB8 CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgIHxTaWcgdHlwZT1PRFUxICB8ICAjc3RhZ2VzPSAxICAgfFh8WHxYIFgg WHwwIDAgMHwxfDB8MHwxfDB8MHwwfDB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgU3RhZ2UjMT1PRFU0ICB8 ICAgICAgICAgICAgUGFkZGluZyAoYWxsIHplcm9zKSAgICAgICAgICAgICAgICB8CiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgIHwgICBVbnJlcyBPRFUxIGF0IFByaW8gMCA9NDAgICAgfCAgICBVbnJlcyBPRFUxIGF0 IFByaW8gMyA9NDAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgIFR5cGUgPSAxIChVbnJlcy1m aXgpICAgfCAgICAgICAgICAgTGVuZ3RoID0gMTIgICAgICAgICB8CiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxT aWcgdHlwZT1PRFUyICB8ICAjc3RhZ2VzPSAxICAgfFh8WHxYIFggWHwwIDAgMHwxfDB8MHwxfDB8 MHwwfDB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rCiAgIHwgU3RhZ2UjMT1PRFU0ICB8ICAgICAgICAgICAgUGFkZGlu ZyAoYWxsIHplcm9zKSAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICBVbnJlcyBP RFUyIGF0IFByaW8gMCA9MTAgICAgfCAgICBVbnJlcyBPRFUyIGF0IFByaW8gMyA9MTAgICB8CiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgIHwgICAgICAgIFR5cGUgPSAxIChVbnJlcy1maXgpICAgfCAgICAgICAgICAg TGVuZ3RoID0gMTIgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxTaWcgdHlwZT1PRFUzICB8ICAj c3RhZ2VzPSAxICAgfFh8WHxYIFggWHwwIDAgMHwxfDB8MHwxfDB8MHwwfDB8CiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r CiAgIHwgU3RhZ2UjMT1PRFU0ICB8ICAgICAgICAgICAgUGFkZGluZyAoYWxsIHplcm9zKSAgICAg ICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICBVbnJlcyBPRFUzIGF0IFByaW8gMCA9MiAg ICAgfCAgICBVbnJlcyBPRFUzIGF0IFByaW8gMyA9MiAgICB8CiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAg VHlwZSA9IDIgKFVucmVzL01BWC12YXIpICAgfCAgICAgICAgICAgTGVuZ3RoID0gMjQgICAgICAg ICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgIHxTLiB0eXBlPU9EVWZsZXh8ICAjc3RhZ2VzPSAxICAgfFh8WHxY IFggWHwwIDAgMHwxfDB8MHwxfDB8MHwwfDB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgIFN0YWdlIzE9T0RV NCB8ICAgICAgICAgICAgUGFkZGluZyAoYWxsIHplcm9zKSAgICAgICAgICAgICAgICB8CiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgIHwgICAgICAgICAgICBVbnJlc2VydmVkIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAw ID0xMDBHYnBzICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICBVbnJlc2VydmVk IEJhbmR3aWR0aCBhdCBwcmlvcml0eSAzID0xMDBHYnBzICAgICAgICB8CiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg IHwgICAgICAgICAgICAgIE1BWCBMU1AgQmFuZHdpZHRoIGF0IHByaW9yaXR5IDAgPTEwMEdicHMg ICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgIE1BWCBMU1AgQmFuZHdpZHRo IGF0IHByaW9yaXR5IDMgPTEwMEdicHMgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgoKCgpDZWNjYXJl bGxpLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE1heSA4LCAyMDE0ICAgICAgICAgICAgICAgICBb UGFnZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgT1NQRi1URSBleHRlbnNpb25zIGZvciBPVE4g c3VwcG9ydCAgICAgIE5vdmVtYmVyIDIwMTMKCgogICAgICAgICAgICAgICAgRmlndXJlIDEzOiBF eGFtcGxlIDQgLSBTaW5nbGUgc3RhZ2UgbXV4aW5nCgo1LjUuICBFeGFtcGxlIG9mIG11bHRpIHN0 YWdlIG11eGluZyAtIFVuYnVuZGxlZCBsaW5rCgogICBTdXBwb3NpbmcgdGhlcmUgaXMgMSBPVFU0 IGNvbXBvbmVudCBsaW5rIHdpdGggbXV4aW5nIGNhcGFiaWxpdGllcyBhcwogICBzaG93biBpbiB0 aGUgZm9sbG93aW5nIGZpZ3VyZToKCgogICAgICAgICAgT0RVMiBPRFUwICAgIE9EVWZsZXggT0RV MAogICAgICAgICAgICAgXCAvICAgICAgICAgICAgXCAvCiAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgfAogICAgICAgICAgICBPRFUzICAgICAgICAgICBPRFUyCiAgICAgICAgICAgICAgIFwg ICAgICAgICAgICAvCiAgICAgICAgICAgICAgICBcICAgICAgICAgIC8KICAgICAgICAgICAgICAg ICBcICAgICAgICAvCiAgICAgICAgICAgICAgICAgIFwgICAgICAvCiAgICAgICAgICAgICAgICAg ICAgT0RVNAoKCiAgIGFuZCBzdXBwb3J0ZWQgcHJpb3JpdGllcyAwIGFuZCAzLCB0aGUgYWR2ZXJ0 aXNlbWVudCBpcyBjb21wb3NlZCBieQogICB0aGUgZm9sbG93aW5nIEJhbmR3aWR0aCBzdWItVExW cyAoVCBhbmQgUyBmaWVsZHMgYXJlIG5vdCByZWxldmFudCB0bwogICB0aGlzIGV4YW1wbGUgYW5k IGZpbGxlZCB3aXRoIFhzKToKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDZWNjYXJlbGxp LCBldCBhbC4gICAgICAgICBFeHBpcmVzIE1heSA4LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFn ZSAyMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgT1NQRi1URSBleHRlbnNpb25zIGZvciBPVE4gc3Vw cG9ydCAgICAgIE5vdmVtYmVyIDIwMTMKCgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAg ICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r CiAgIHwgICAgICAgIFR5cGUgPSAxIChVbnJlcy1maXgpICAgfCAgICAgICAgICAgTGVuZ3RoID0g OCAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxTaWcgdHlwZT1PRFU0ICB8ICAjc3RhZ2VzPSAw ICAgfFh8WHwgIDEgIHwwIDAgMHwxfDB8MHwxfDB8MHwwfDB8CiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICBV bnJlcyBPRFU0IGF0IFByaW8gMCA9MSAgICAgfCAgICBVbnJlcyBPRFU0IGF0IFByaW8gMyA9MSAg ICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgIFR5cGUgPSAxIChVbnJlcy1maXgpICAgfCAgICAg ICAgICAgTGVuZ3RoID0gMTIgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxTaWcgdHlwZT1PRFUz ICB8ICAjc3RhZ2VzPSAxICAgfFh8WHwgIDEgIHwwIDAgMHwxfDB8MHwxfDB8MHwwfDB8CiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgIHwgIFN0YWdlIzE9T0RVNCB8ICAgICAgICAgUGFkZGluZyAoYWxsIHplcm9zKSAg ICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICBVbnJlcyBPRFUzIGF0IFByaW8g MCA9MiAgICAgfCAgICBVbnJlcyBPRFUzIGF0IFByaW8gMyA9MiAgICB8CiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg IHwgICAgICAgIFR5cGUgPSAxIChVbnJlcy1maXgpICAgfCAgICAgICAgICAgTGVuZ3RoID0gMTIg ICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxTaWcgdHlwZT1PRFUyICB8ICAjc3RhZ2VzPSAxICAg fFh8WHwgIDEgIHwwIDAgMHwxfDB8MHwxfDB8MHwwfDB8CiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgIFN0YWdl IzE9T0RVNCB8ICAgICAgICAgUGFkZGluZyAoYWxsIHplcm9zKSAgICAgICAgICAgICAgICAgICB8 CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgIHwgICBVbnJlcyBPRFUyIGF0IFByaW8gMCA9MTAgICAgfCAgICBVbnJl cyBPRFUyIGF0IFByaW8gMyA9MTAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgIFR5cGUgPSAx IChVbnJlcy1maXgpICAgfCAgICAgICAgICAgTGVuZ3RoID0gMTIgICAgICAgICB8CiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgIHxTaWcgdHlwZT1PRFUyICB8ICAjc3RhZ2VzPSAyICAgfFh8WHwgIDAgIHwwIDAgMHwx fDB8MHwxfDB8MHwwfDB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgU3RhZ2UjMT1PRFUzICB8IFN0YWdlIzI9 T0RVNCAgfCAgICBQYWRkaW5nIChhbGwgemVyb3MpICAgICAgICB8CiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwg ICBVbnJlcyBPRFUyIGF0IFByaW8gMCA9OCAgICAgfCAgICBVbnJlcyBPRFUyIGF0IFByaW8gMyA9 OCAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgIFR5cGUgPSAxIChVbnJlcy1maXgpICAgfCAg ICAgICAgICAgTGVuZ3RoID0gMTIgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxTaWcgdHlwZT1P RFUwICB8ICAjc3RhZ2VzPSAyICAgfFh8WHwgIDAgIHwwIDAgMHwxfDB8MHwxfDB8MHwwfDB8CiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgIHwgU3RhZ2UjMT1PRFUzICB8IFN0YWdlIzI9T0RVNCAgfCAgICBQYWRkaW5n IChhbGwgemVyb3MpICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICBVbnJlcyBPRFUwIGF0IFBy aW8gMCA9NjQgICAgfCAgICBVbnJlcyBPRFUwIGF0IFByaW8gMyA9NjQgICB8CiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r CiAgIHwgICAgICAgIFR5cGUgPSAxIChVbnJlcy1maXgpICAgfCAgICAgICAgICAgTGVuZ3RoID0g MTIgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxTaWcgdHlwZT1PRFUwICB8ICAjc3RhZ2VzPSAy ICAgfFh8WHwgIDAgIHwwIDAgMHwxfDB8MHwxfDB8MHwwfDB8CiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgU3Rh Z2UjMT1PRFUyICB8IFN0YWdlIzI9T0RVNCAgfCAgICBQYWRkaW5nIChhbGwgemVyb3MpICAgICAg ICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgIHwgICBVbnJlcyBPRFUwIGF0IFByaW8gMCA9ODAgICAgfCAgICBV bnJlcyBPRFUwIGF0IFByaW8gMyA9ODAgICB8CgoKCkNlY2NhcmVsbGksIGV0IGFsLiAgICAgICAg IEV4cGlyZXMgTWF5IDgsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDIzXQoMCkludGVybmV0 LURyYWZ0ICAgICBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBzdXBwb3J0ICAgICAgTm92ZW1i ZXIgMjAxMwoKCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgVHlwZSA9IDIgKFVucmVzL01BWC12YXIpICAg fCAgICAgICAgICAgTGVuZ3RoID0gMjQgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxTLnR5cGU9 T0RVZmxleCB8ICAjc3RhZ2VzPSAyICAgfFh8WHwgIDAgIHwwIDAgMHwxfDB8MHwxfDB8MHwwfDB8 CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgIHwgU3RhZ2UjMT1PRFUyICB8IFN0YWdlIzI9T0RVNCAgfCAgICBQYWRk aW5nIChhbGwgemVyb3MpICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICBVbnJl c2VydmVkIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAwID0xMDBHYnBzICAgICAgICB8CiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgIHwgICAgICAgICAgICBVbnJlc2VydmVkIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAzID0x MDBHYnBzICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICBNQVggTFNQIEJhbmR3 aWR0aCBhdCBwcmlvcml0eSAwID0xMEdicHMgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwg ICAgICAgICAgICBNQVggTFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAzID0xMEdicHMgICAgICAg ICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rCgoKCiAgICAgICAgRmlndXJlIDE0OiBFeGFtcGxlIDUgLSBNdWx0 aSBzdGFnZSBtdXhpbmcgLSBVbmJ1bmRsZWQgbGluawoKNS42LiAgRXhhbXBsZSBvZiBtdWx0aSBz dGFnZSBtdXhpbmcgLSBCdW5kbGVkIGxpbmtzCgogICBJbiB0aGlzIGV4YW1wbGUsIDIgT1RVNCBj b21wb25lbnQgbGlua3Mgd2l0aCB0aGUgc2FtZSBzdXBwb3J0ZWQgVFMKICAgZ3JhbnVsYXJpdHkg YW5kIGhvbW9nZW5lb3VzIG11eGluZyBoaWVyYXJjaGllcyBhcmUgY29uc2lkZXJlZC4gIFRoZQog ICBmb2xsb3dpbmcgbXV4aW5nIGNhcGFiaWxpdGllcyB0cmVlcyBhcmUgc3VwcG9ydGVkOgoKCiAg IENvbXBvbmVudCBMaW5rIzEgICAgICBDb21wb25lbnQgTGluayMyCiAgICAgIE9EVTIgT0RVMCAg ICAgICAgICAgICBPRFUyIE9EVTAKICAgICAgICAgXCAvICAgICAgICAgICAgICAgICAgIFwgLwog ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgT0RVMyAgICAgICAgICAg ICAgICAgIE9EVTMKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIE9E VTQgICAgICAgICAgICAgICAgICBPRFU0CgoKICAgQ29uc2lkZXJpbmcgb25seSBzdXBwb3J0ZWQg cHJpb3JpdGllcyAwIGFuZCAzLCB0aGUgYWR2ZXJ0aXNlbWVudCBpcwogICBhcyBmb2xsb3dzIChU LCBTIGFuZCBUUyBncmFudWxhcml0eSBmaWVsZHMgYXJlIG5vdCByZWxldmFudCB0byB0aGlzCiAg IGV4YW1wbGUgYW5kIGZpbGxlZCB3aXRoIFhzKToKCgoKCgoKCgoKCgoKQ2VjY2FyZWxsaSwgZXQg YWwuICAgICAgICAgRXhwaXJlcyBNYXkgOCwgMjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgMjRd CgwKSW50ZXJuZXQtRHJhZnQgICAgIE9TUEYtVEUgZXh0ZW5zaW9ucyBmb3IgT1ROIHN1cHBvcnQg ICAgICBOb3ZlbWJlciAyMDEzCgoKICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8 ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgIExlbmd0aCA9IDggICAg ICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVNCAgfCAgI3N0YWdlcz0gMCAgIHxY fFh8WCBYIFh8MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgVW5yZXMg T0RVNCBhdCBQcmlvIDAgPTIgICAgIHwgICAgVW5yZXMgT0RVNCBhdCBQcmlvIDMgPTIgICAgfAog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICB8ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAg IExlbmd0aCA9IDEyICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVMyAgfCAg I3N0YWdlcz0gMSAgIHxYfFh8WCBYIFh8MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwogICB8ICBTdGFnZSMxPU9EVTQgfCAgICAgICAgICBQYWRkaW5nIChhbGwgemVyb3MpICAgICAg ICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgVW5yZXMgT0RVMyBhdCBQcmlvIDAgPTQg ICAgIHwgICAgVW5yZXMgT0RVMyBhdCBQcmlvIDMgPTQgICAgfAogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAg ICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgIExlbmd0aCA9IDEyICAgICAg ICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVMiAgfCAgI3N0YWdlcz0gMiAgIHxYfFh8 WCBYIFh8MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8IFN0YWdlIzE9T0RV MyAgfCBTdGFnZSMyPU9EVTQgIHwgICAgUGFkZGluZyAoYWxsIHplcm9zKSAgICAgICAgfAogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKwogICB8ICAgVW5yZXMgT0RVMiBhdCBQcmlvIDAgPTE2ICAgIHwgICAgVW5yZXMgT0RV MiBhdCBQcmlvIDMgPTE2ICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICBUeXBlID0gMSAoVW5y ZXMtZml4KSAgIHwgICAgICAgICAgIExlbmd0aCA9IDEyICAgICAgICAgfAogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICB8U2lnIHR5cGU9T0RVMCAgfCAgI3N0YWdlcz0gMiAgIHxYfFh8WCBYIFh8MCAwIDB8MXwwfDB8 MXwwfDB8MHwwfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICB8IFN0YWdlIzE9T0RVMyAgfCBTdGFnZSMyPU9EVTQg IHwgICAgUGFkZGluZyAoYWxsIHplcm9zKSAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgVW5y ZXMgT0RVMCBhdCBQcmlvIDAgPTEyOCAgIHwgICAgVW5yZXMgT0RVMCBhdCBQcmlvIDMgPTEyOCAg fAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKwoKCgogICAgICAgICBGaWd1cmUgMTU6IEV4YW1wbGUgNiAtIE11bHRpIHN0 YWdlIG11eGluZyAtIEJ1bmRsZWQgbGlua3MKCjUuNy4gIEV4YW1wbGUgb2YgY29tcG9uZW50IGxp bmtzIHdpdGggbm9uLWhvbW9nZW5lb3VzIGhpZXJhcmNoaWVzCgogICBJbiB0aGlzIGV4YW1wbGUs IDIgT1RVNCBjb21wb25lbnQgbGlua3Mgd2l0aCB0aGUgc2FtZSBzdXBwb3J0ZWQgVFMKICAgZ3Jh bnVsYXJpdHkgYW5kIG5vbi1ob21vZ2VuZW91cyBtdXhpbmcgaGllcmFyY2hpZXMgYXJlIGNvbnNp ZGVyZWQuCiAgIFRoZSBmb2xsb3dpbmcgbXV4aW5nIGNhcGFiaWxpdGllcyB0cmVlcyBhcmUgc3Vw cG9ydGVkOgoKCgoKCgoKCkNlY2NhcmVsbGksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTWF5IDgs IDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDI1XQoMCkludGVybmV0LURyYWZ0ICAgICBPU1BG LVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBzdXBwb3J0ICAgICAgTm92ZW1iZXIgMjAxMwoKCiAgIENv bXBvbmVudCBMaW5rIzEgICAgICBDb21wb25lbnQgTGluayMyCiAgICAgIE9EVTIgT0RVMCAgICAg ICAgICAgICBPRFUxIE9EVTAKICAgICAgICAgXCAvICAgICAgICAgICAgICAgICAgIFwgLwogICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgT0RVMyAgICAgICAgICAgICAg ICAgIE9EVTIKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIE9EVTQg ICAgICAgICAgICAgICAgICBPRFU0CgoKICAgQ29uc2lkZXJpbmcgb25seSBzdXBwb3J0ZWQgcHJp b3JpdGllcyAwIGFuZCAzLCB0aGUgYWR2ZXJ0aXNlbWVudCB1c2VzCiAgIHR3byBkaWZmZXJlbnQg SVNDRHMsIG9uZSBmb3IgZWFjaCBoaWVyYXJjaHkgKFQsIFMgYW5kIFRTIGdyYW51bGFyaXR5CiAg IGZpZWxkcyBhcmUgbm90IHJlbGV2YW50IHRvIHRoaXMgZXhhbXBsZSBhbmQgZmlsbGVkIHdpdGgg WHMpLiAgSW4gdGhlCiAgIGZvbGxvd2luZyBmaWd1cmUsIHRoZSBTQ1NJIG9mIGVhY2ggSVNDRCBp cyBzaG93bjoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDZWNjYXJlbGxp LCBldCBhbC4gICAgICAgICBFeHBpcmVzIE1heSA4LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFn ZSAyNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgT1NQRi1URSBleHRlbnNpb25zIGZvciBPVE4gc3Vw cG9ydCAgICAgIE5vdmVtYmVyIDIwMTMKCgogICBTQ1NJIG9mIElTQ0QgMSAtIENvbXBvbmVudCBM aW5rIzEKCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAg ICAgICAgICAgICAgICAzCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgVHlwZSA9 IDEgKFVucmVzLWZpeCkgICB8ICAgICAgICAgICBMZW5ndGggPSA4ICAgICAgICAgIHwKICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKICAgfFNpZyB0eXBlPU9EVTQgIHwgICNzdGFnZXM9IDAgICB8WHxYfFggWCBYfDAgMCAw fDF8MHwwfDF8MHwwfDB8MHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgIFVucmVzIE9EVTQgYXQgUHJpbyAw ID0xICAgICB8ICAgIFVucmVzIE9EVTQgYXQgUHJpbyAzID0xICAgIHwKICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg fCAgICAgICAgVHlwZSA9IDEgKFVucmVzLWZpeCkgICB8ICAgICAgICAgICBMZW5ndGggPSAxMiAg ICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgfFNpZyB0eXBlPU9EVTMgIHwgICNzdGFnZXM9IDEgICB8 WHxYfFggWCBYfDAgMCAwfDF8MHwwfDF8MHwwfDB8MHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgU3RhZ2Uj MT1PRFU0IHwgICAgICAgICAgIFBhZGRpbmcgKGFsbCB6ZXJvcykgICAgICAgICAgICAgICAgIHwK ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsKICAgfCAgIFVucmVzIE9EVTMgYXQgUHJpbyAwID0yICAgICB8ICAgIFVucmVz IE9EVTMgYXQgUHJpbyAzID0yICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgVHlwZSA9IDEg KFVucmVzLWZpeCkgICB8ICAgICAgICAgICBMZW5ndGggPSAxMiAgICAgICAgIHwKICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKICAgfFNpZyB0eXBlPU9EVTIgIHwgICNzdGFnZXM9IDIgICB8WHxYfFggWCBYfDAgMCAwfDF8 MHwwfDF8MHwwfDB8MHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCBTdGFnZSMxPU9EVTMgIHwgU3RhZ2UjMj1P RFU0ICB8ICAgIFBhZGRpbmcgKGFsbCB6ZXJvcykgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAg IFVucmVzIE9EVTIgYXQgUHJpbyAwID04ICAgICB8ICAgIFVucmVzIE9EVTIgYXQgUHJpbyAzID04 ICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgVHlwZSA9IDEgKFVucmVzLWZpeCkgICB8ICAg ICAgICAgICBMZW5ndGggPSAxMiAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfFNpZyB0eXBlPU9E VTAgIHwgICNzdGFnZXM9IDIgICB8WHxYfFggWCBYfDAgMCAwfDF8MHwwfDF8MHwwfDB8MHwKICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsKICAgfCBTdGFnZSMxPU9EVTMgIHwgU3RhZ2UjMj1PRFU0ICB8ICAgIFBhZGRpbmcg KGFsbCB6ZXJvcykgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgIFVucmVzIE9EVTAgYXQgUHJp byAwID02NCAgICB8ICAgIFVucmVzIE9EVTAgYXQgUHJpbyAzID02NCAgIHwKICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsK CgogICAgICAgIEZpZ3VyZSAxNjogRXhhbXBsZSA3IC0gTXVsdGkgc3RhZ2UgbXV4aW5nIC0gTm9u LWhvbW9nZW5lb3VzCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGhpZXJhcmNoaWVzIC0gSVND RCAxCgoKCgoKCgoKCgoKCkNlY2NhcmVsbGksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTWF5IDgs IDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDI3XQoMCkludGVybmV0LURyYWZ0ICAgICBPU1BG LVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBzdXBwb3J0ICAgICAgTm92ZW1iZXIgMjAxMwoKCiAgIFND U0kgb2YgSVNDRCAyIC0gQ29tcG9uZW50IExpbmsjMgoKICAgIDAgICAgICAgICAgICAgICAgICAg MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKwogICB8ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgIExl bmd0aCA9IDggICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVNCAgfCAgI3N0 YWdlcz0gMCAgIHxYfFh8WCBYIFh8MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICB8ICAgVW5yZXMgT0RVNCBhdCBQcmlvIDAgPTEgICAgIHwgICAgVW5yZXMgT0RVNCBhdCBQcmlv IDMgPTEgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAg IHwgICAgICAgICAgIExlbmd0aCA9IDEyICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8U2lnIHR5 cGU9T0RVMiAgfCAgI3N0YWdlcz0gMSAgIHxYfFh8WCBYIFh8MCAwIDB8MXwwfDB8MXwwfDB8MHww fAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKwogICB8ICBTdGFnZSMxPU9EVTQgfCAgICAgICAgICAgUGFkZGluZyAoYWxs IHplcm9zKSAgICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgVW5yZXMgT0RVMiBh dCBQcmlvIDAgPTEwICAgIHwgICAgVW5yZXMgT0RVMiBhdCBQcmlvIDMgPTEwICAgfAogICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwogICB8ICAgICAgICBUeXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgIExlbmd0 aCA9IDEyICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVMSAgfCAgI3N0YWdl cz0gMiAgIHxYfFh8WCBYIFh8MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8 IFN0YWdlIzE9T0RVMiAgfCBTdGFnZSMyPU9EVTQgIHwgICAgUGFkZGluZyAoYWxsIHplcm9zKSAg ICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwogICB8ICAgVW5yZXMgT0RVMSBhdCBQcmlvIDAgPTQwICAgIHwg ICAgVW5yZXMgT0RVMSBhdCBQcmlvIDMgPTQwICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICBU eXBlID0gMSAoVW5yZXMtZml4KSAgIHwgICAgICAgICAgIExlbmd0aCA9IDEyICAgICAgICAgfAog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICB8U2lnIHR5cGU9T0RVMCAgfCAgI3N0YWdlcz0gMiAgIHxYfFh8WCBYIFh8 MCAwIDB8MXwwfDB8MXwwfDB8MHwwfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8IFN0YWdlIzE9T0RVMiAgfCBT dGFnZSMyPU9EVTQgIHwgICAgUGFkZGluZyAoYWxsIHplcm9zKSAgICAgICAgfAogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwogICB8ICAgVW5yZXMgT0RVMCBhdCBQcmlvIDAgPTgwICAgIHwgICAgVW5yZXMgT0RVMCBhdCBQ cmlvIDMgPTgwICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKCiAgICAgICAgRmlndXJlIDE3OiBFeGFtcGxlIDcg LSBNdWx0aSBzdGFnZSBtdXhpbmcgLSBOb24taG9tb2dlbmVvdXMKICAgICAgICAgICAgICAgICAg ICAgICAgICAgaGllcmFyY2hpZXMgLSBJU0NEIDIKCgo2LiAgT1NQRnYyIHNjYWxhYmlsaXR5Cgog ICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBPU1BGIHNjYWxhYmlsaXR5IGlzc3Vl cyB3aXRoIHJlc3BlY3QKICAgdG8gZXhpc3RpbmcgR01QTFMgZW5jb2RpbmcgYW5kIGRvZXMgbm90 IHJlcXVpcmUgYW55IG1vZGlmaWNhdGlvbiB0bwogICBmbG9vZGluZyBmcmVxdWVuY3kuICBNb3Jl b3ZlciwgdGhlIGRlc2lnbiBvZiB0aGUgZW5jb2RpbmcgaGFzIGJlZW4KICAgY2FycmllZCBvdXQg dGFraW5nIGludG8gYWNjb3VudCBiYW5kd2lkdGggb3B0aW1pemF0aW9uLCBhbmQgaW4KICAgcGFy dGljdWxhcjoKCgoKQ2VjY2FyZWxsaSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBNYXkgOCwgMjAx NCAgICAgICAgICAgICAgICAgW1BhZ2UgMjhdCgwKSW50ZXJuZXQtRHJhZnQgICAgIE9TUEYtVEUg ZXh0ZW5zaW9ucyBmb3IgT1ROIHN1cHBvcnQgICAgICBOb3ZlbWJlciAyMDEzCgoKICAgICAgLSBP bmx5IHVucmVzZXJ2ZWQgYW5kIE1BWCBMU1AgQmFuZHdpZHRoIHJlbGF0ZWQgdG8gc3VwcG9ydGVk CiAgICAgIHByaW9yaXRpZXMgYXJlIGFkdmVydGlzZWQKCiAgICAgIC0gV2l0aCByZXNwZWN0IG9m IGZpeGVkIGNvbnRhaW5lcnMsIG9ubHkgdGhlIG51bWJlciBvZiBhdmFpbGFibGUKICAgICAgY29u dGFpbmVycyBpcyBhZHZlcnRpc2VkIGluc3RlYWQgb2YgYXZhaWxhYmxlIGJhbmR3aWR0aCBzbyB0 byB1c2UKICAgICAgb25seSAxNiBiaXRzIHBlciBjb250YWluZXIgaW5zdGVhZCBvZiAzMiAoYXMg cGVyIGZvcm1lciBHTVBMUwogICAgICBlbmNvZGluZwoKICAgSW4gb3JkZXIgdG8gZnVydGhlciBy ZWR1Y2UgdGhlIGFtb3VudCBvZiBkYXRhIGFkdmVydGlzZWQgaXQgaXMKICAgUkVDT01NRU5ERUQg dG8gYnVuZGxlIGNvbXBvbmVudCBsaW5rcyB3aXRoIGhvbW9nZW5lb3VzIGhpZXJhcmNoaWVzIGFz CiAgIGRlc2NyaWJlZCBpbiBbUkZDNDIwMV0gYW5kIGlsbHVzdHJhdGVkIGluIFNlY3Rpb24gNS42 LgoKCjcuICBDb21wYXRpYmlsaXR5CgogICBBbGwgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMgZG9j dW1lbnQgTUFZIGFsc28gc3VwcG9ydCBhZHZlcnRpc2VtZW50CiAgIGFzIGRlZmluZWQgaW4gW1JG QzQzMjhdLiAgV2hlbiBub2RlcyBzdXBwb3J0IGJvdGggYWR2ZXJ0aXNlbWVudAogICBtZXRob2Rz LCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IHRoZSBjb25maWd1cmF0aW9uIG9mIHdoaWNo CiAgIGFkdmVydGlzZW1lbnQgbWV0aG9kIGlzIGZvbGxvd2VkLiAgVGhlIGNob2ljZSBvZiB3aGlj aCBpcyB1c2VkIGlzCiAgIGJhc2VkIG9uIHBvbGljeSBhbmQgYmV5b25kIHRoZSBzY29wZSBvZiB0 aGlzIGRvY3VtZW50LiAgVGhpcyBlbmFibGVzCiAgIG5vZGVzIGZvbGxvd2luZyBlYWNoIG1ldGhv ZCB0byBpZGVudGlmeSBzaW1pbGFyIHN1cHBvcnRpbmcgbm9kZXMgYW5kCiAgIGNvbXB1dGUgcGF0 aHMgdXNpbmcgb25seSB0aGUgYXBwcm9wcmlhdGUgbm9kZXMuCgoKOC4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zCgogICBUaGlzIGRvY3VtZW50IGV4dGVuZHMgW1JGQzQyMDNdLiAgQXMgd2l0aFtS RkM0MjAzXSwgaXQgc3BlY2lmaWVzIHRoZQogICBjb250ZW50cyBvZiBPcGFxdWUgTFNBcyBpbiBP U1BGdjIuICBBcyBPcGFxdWUgTFNBcyBhcmUgbm90IHVzZWQgZm9yCiAgIFNQRiBjb21wdXRhdGlv biBvciBub3JtYWwgcm91dGluZywgdGhlIGV4dGVuc2lvbnMgc3BlY2lmaWVkIGhlcmUgaGF2ZQog ICBubyBkaXJlY3QgZWZmZWN0IG9uIElQIHJvdXRpbmcuICBUYW1wZXJpbmcgd2l0aCBHTVBMUyBU RSBMU0FzIG1heQogICBoYXZlIGFuIGVmZmVjdCBvbiB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQg KG9wdGljYWwgYW5kL29yIFNPTkVULVNESCkKICAgbmV0d29yay4gIFtSRkMzNjMwXSBzdWdnZXN0 cyBtZWNoYW5pc21zIHRvIHByb3RlY3QgdGhlIHRyYW5zbWlzc2lvbgogICBvZiB0aGlzIGluZm9y bWF0aW9uLCBhbmQgdGhvc2Ugb3Igb3RoZXIgbWVjaGFuaXNtcyBzaG91bGQgYmUgdXNlZCB0bwog ICBzZWN1cmUgYW5kL29yIGF1dGhlbnRpY2F0ZSB0aGUgaW5mb3JtYXRpb24gY2FycmllZCBpbiB0 aGUgT3BhcXVlCiAgIExTQXMuCgogICBGb3Igc2VjdXJpdHkgdGhyZWF0cywgZGVmZW5zaXZlIHRl Y2huaXF1ZXMsIG1vbml0b3JpbmcvZGV0ZWN0aW9uLwogICByZXBvcnRpbmcgb2Ygc2VjdXJpdHkg YXR0YWNrcyBhbmQgcmVxdWlyZW1lbnRzIHBsZWFzZSByZWZlciB0bwogICBbUkZDNTkyMF0uCgoK OS4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCjkuMS4gIFN3aXRjaGluZyB0eXBlcwoKICAgVXBvbiBh cHByb3ZhbCBvZiB0aGlzIGRvY3VtZW50LCBJQU5BIHdpbGwgbWFrZSB0aGUgYXNzaWdubWVudCBp biB0aGUKICAgIlN3aXRjaGluZyBUeXBlcyIgc2VjdGlvbiBvZiB0aGUgIkdNUExTIFNpZ25hbGlu ZyBQYXJhbWV0ZXJzIgogICByZWdpc3RyeSBsb2NhdGVkIGF0CgoKCkNlY2NhcmVsbGksIGV0IGFs LiAgICAgICAgIEV4cGlyZXMgTWF5IDgsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDI5XQoM CkludGVybmV0LURyYWZ0ICAgICBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBzdXBwb3J0ICAg ICAgTm92ZW1iZXIgMjAxMwoKCiAgIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZ21w bHMtc2lnLXBhcmFtZXRlcnM6CgoKICAgVmFsdWUgICAgICBOYW1lICAgICAgICAgICAgICAgICAg ICAgICAgICBSZWZlcmVuY2UKICAgLS0tLS0tLS0tICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSAgICAtLS0tLS0tLS0tCiAgIDExMCAoKikgICAgIE9UTi1URE0gY2FwYWJsZSAoT1ROLVRETSkg ICAgW1RoaXMuSS1EXQoKICAgKCopIFN1Z2dlc3RlZCB2YWx1ZQoKCiAgIFNhbWUgdHlwZSBvZiBt b2RpZmljYXRpb24gbmVlZHMgdG8gYXBwbGllZCB0byB0aGUgSUFOQS1HTVBMUy1UQy1NSUIKICAg YXQgaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaWFuYWdtcGxzdGMtbWliL2lhbmFn bXBsc3RjLW1pYgoKOS4yLiAgTmV3IHN1Yi1UTFZzCgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMg MiBuZXcgc3ViLVRMVnMgdGhhdCBhcmUgY2FycmllZCBpbiBJbnRlcmZhY2UKICAgU3dpdGNoaW5n IENhcGFiaWxpdHkgRGVzY3JpcHRvcnMgW1JGQzQyMDNdIHdpdGggU2lnbmFsIFR5cGUgT1ROLVRE TS4KICAgRWFjaCBzdWItVExWIGluY2x1ZGVzIGEgMTYtYml0IHR5cGUgaWRlbnRpZmllciAodGhl IFQtZmllbGQpLiAgVGhlCiAgIHNhbWUgVC1maWVsZCB2YWx1ZXMgYXJlIGFwcGxpY2FibGUgdG8g dGhlIG5ldyBzdWItVExWLgoKICAgVXBvbiBhcHByb3ZhbCBvZiB0aGlzIGRvY3VtZW50LCBJQU5B IHdpbGwgY3JlYXRlIGFuZCBtYWludGFpbiBhIG5ldwogICBzdWItcmVnaXN0cnksIHRoZSAiVHlw ZXMgZm9yIHN1Yi1UTFZzIG9mIE9UTi1URE0gU0NTSSAoU3dpdGNoCiAgIENhcGFiaWxpdHktU3Bl Y2lmaWMgSW5mb3JtYXRpb24pIiByZWdpc3RyeSB1bmRlciB0aGUgIk9wZW4gU2hvcnRlc3QKICAg UGF0aCBGaXJzdCAoT1NQRikgVHJhZmZpYyBFbmdpbmVlcmluZyBUTFZzIiByZWdpc3RyeSwgc2Vl IGh0dHA6Ly8KICAgd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29zcGYtdHJhZmZpYy1lbmctdGx2 cy8KICAgb3NwZi10cmFmZmljLWVuZy10bHZzLnhtbCwgd2l0aCB0aGUgc3ViLVRMViB0eXBlcyBh cyBmb2xsb3dzOgoKCiAgICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBuZXcgc3ViLVRMViB0eXBl cyBhcyBmb2xsb3dzOgoKICAgVmFsdWUgICAgICBTdWItVExWICAgICAgICAgICAgICAgICAgICAg ICBSZWZlcmVuY2UKICAgLS0tLS0tLS0tICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAt LS0tLS0tLS0tCiAgIDAgICAgICAgICAgIFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgW1Ro aXMuSS1EXQogICAxICAgICAgICAgICBVbnJlc2VydmVkIEJhbmR3aWR0aCBmb3IgICAgIFtUaGlz LkktRF0KICAgICAgICAgICAgICAgZml4ZWQgY29udGFpbmVycwogICAyICAgICAgICAgICBVbnJl c2VydmVkL01BWCBCYW5kd2lkdGggZm9yIFtUaGlzLkktRF0KICAgICAgICAgICAgICAgZmxleGli bGUgY29udGFpbmVycwogICAzLTY1NTM1ICAgICBVbmFzc2lnbmVkCgogICBUeXBlcyBhcmUgdG8g YmUgYXNzaWduZWQgdmlhIFN0YW5kYXJkcyBBY3Rpb24gYXMgZGVmaW5lZCBpbgogICBbUkZDNTIy Nl0uCgoKMTAuICBDb250cmlidXRvcnMKCiAgICAgIERpZWdvIENhdmlnbGlhLCBFcmljc3NvbgoK CgoKCkNlY2NhcmVsbGksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTWF5IDgsIDIwMTQgICAgICAg ICAgICAgICAgIFtQYWdlIDMwXQoMCkludGVybmV0LURyYWZ0ICAgICBPU1BGLVRFIGV4dGVuc2lv bnMgZm9yIE9UTiBzdXBwb3J0ICAgICAgTm92ZW1iZXIgMjAxMwoKCiAgICAgIFZpYSBFLk1lbGVu LCA3NyAtIEdlbm92YSAtIEl0YWx5CgogICAgICBFbWFpbDogZGllZ28uY2F2aWdsaWFAZXJpY3Nz b24uY29tCgoKCiAgICAgIERhbiBMaSwgSHVhd2VpIFRlY2hub2xvZ2llcwoKICAgICAgQmFudGlh biwgTG9uZ2dhbmcgRGlzdHJpY3QgLSBTaGVuemhlbiA1MTgxMjkgUC5SLkNoaW5hCgogICAgICBF bWFpbDogZGFubGlAaHVhd2VpLmNvbQoKCgogICAgICBQaWV0cm8gVml0dG9yaW8gR3JhbmRpLCBB bGNhdGVsLUx1Y2VudAoKICAgICAgVmlhIFRyZW50bywgMzAgLSBWaW1lcmNhdGUgLSBJdGFseQoK ICAgICAgRW1haWw6IHBpZXRyb192aXR0b3Jpby5ncmFuZGlAYWxjYXRlbC1sdWNlbnQuY29tCgoK CiAgICAgIEtodXplbWEgUGl0aGV3YW4sIEluZmluZXJhIENvcnBvcmF0aW9uCgogICAgICAxNDAg Q2FzcGlhbiBDVC4sIFN1bm55dmFsZSAtIENBIC0gVVNBCgogICAgICBFbWFpbDoga3BpdGhld2Fu QGluZmluZXJhLmNvbQoKCgogICAgICBYaWFvYmluZyBaaSwgSHVhd2VpIFRlY2hub2xvZ2llcwoK ICAgICAgRW1haWw6IHppeGlhb2JpbmdAaHVhd2VpLmNvbQoKCgogICAgICBGcmFuY2VzY28gRm9u ZGVsbGksIEVyaWNzc29uCgogICAgICBFbWFpbDogZnJhbmNlc2NvLmZvbmRlbGxpQGVyaWNzc29u LmNvbQoKCgogICAgICBNYXJjbyBDb3JzaQoKICAgICAgRU1haWw6IGNvcnNpLm1hcmNvQGdtYWls LmNvbQoKCgoKCgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE1heSA4LCAyMDE0 ICAgICAgICAgICAgICAgICBbUGFnZSAzMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgT1NQRi1URSBl eHRlbnNpb25zIGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIwMTMKCgogICAgICBFdmUg VmFybWEsIEFsY2F0ZWwtTHVjZW50CgogICAgICBFTWFpbDogZXZlLnZhcm1hQGFsY2F0ZWwtbHVj ZW50LmNvbQoKCgogICAgICBKb25hdGhhbiBTYWRsZXIsIFRlbGxhYnMKCiAgICAgIEVNYWlsOiBq b25hdGhhbi5zYWRsZXJAdGVsbGFicy5jb20KCgoKICAgICAgTHluZG9uIE9uZywgQ2llbmEKCiAg ICAgIEVNYWlsOiBseW9uZ0BjaWVuYS5jb20KCgoKICAgICAgQXNob2sgS3VuamlkaGFwYXRoYW0K CiAgICAgIGFrdW5qaWRoYXBhdGhhbUBpbmZpbmVyYS5jb20KCgoKICAgICAgU25pZ2RobyBCYXJk YWxhaQoKICAgICAgc2JhcmRhbGFpQGluZmluZXJhLmNvbQoKCgogICAgICBTdGV2ZSBCYWxscwoK ICAgICAgU3RldmUuQmFsbHNAbWV0YXN3aXRjaC5jb20KCgoKICAgICAgSm9uYXRoYW4gSGFyZHdp Y2sKCiAgICAgIEpvbmF0aGFuLkhhcmR3aWNrQG1ldGFzd2l0Y2guY29tCgoKCiAgICAgIFhpaHVh IEZ1CgogICAgICBmdS54aWh1YUB6dGUuY29tLmNuCgoKCgoKCkNlY2NhcmVsbGksIGV0IGFsLiAg ICAgICAgIEV4cGlyZXMgTWF5IDgsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDMyXQoMCklu dGVybmV0LURyYWZ0ICAgICBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIE9UTiBzdXBwb3J0ICAgICAg Tm92ZW1iZXIgMjAxMwoKCiAgICAgIEN5cmlsIE1hcmdhcmlhCgogICAgICBjeXJpbC5tYXJnYXJp YUBuc24uY29tCgogICAgICBNYWxjb2xtIEJldHRzCgogICAgICBNYWxjb2xtLmJldHRzQHp0ZS5j b20uY24KCgoKCjExLiAgQWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIGF1dGhvcnMgd291bGQgbGlr ZSB0byB0aGFuayBGcmVkIEdydW1hbiBhbmQgTG91IEJlcmdlciBmb3IgdGhlCiAgIHByZWNpb3Vz IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4KCgoxMi4gIFJlZmVyZW5jZXMKCjEyLjEuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBm b3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZl bHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoKICAgW1JGQzM2MzBdICBLYXR6LCBE LiwgS29tcGVsbGEsIEsuLCBhbmQgRC4gWWV1bmcsICJUcmFmZmljIEVuZ2luZWVyaW5nCiAgICAg ICAgICAgICAgKFRFKSBFeHRlbnNpb25zIHRvIE9TUEYgVmVyc2lvbiAyIiwgUkZDIDM2MzAsCiAg ICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMuCgogICBbUkZDNDIwMV0gIEtvbXBlbGxhLCBLLiwg UmVraHRlciwgWS4sIGFuZCBMLiBCZXJnZXIsICJMaW5rIEJ1bmRsaW5nCiAgICAgICAgICAgICAg aW4gTVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nIChURSkiLCBSRkMgNDIwMSwgT2N0b2JlciAyMDA1 LgoKICAgW1JGQzQyMDNdICBLb21wZWxsYSwgSy4gYW5kIFkuIFJla2h0ZXIsICJPU1BGIEV4dGVu c2lvbnMgaW4gU3VwcG9ydAogICAgICAgICAgICAgIG9mIEdlbmVyYWxpemVkIE11bHRpLVByb3Rv Y29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpIiwKICAgICAgICAgICAgICBSRkMgNDIwMywgT2N0 b2JlciAyMDA1LgoKICAgW1JGQzQzMjhdICBQYXBhZGltaXRyaW91LCBELiwgIkdlbmVyYWxpemVk IE11bHRpLVByb3RvY29sIExhYmVsCiAgICAgICAgICAgICAgU3dpdGNoaW5nIChHTVBMUykgU2ln bmFsaW5nIEV4dGVuc2lvbnMgZm9yIEcuNzA5IE9wdGljYWwKICAgICAgICAgICAgICBUcmFuc3Bv cnQgTmV0d29ya3MgQ29udHJvbCIsIFJGQyA0MzI4LCBKYW51YXJ5IDIwMDYuCgoxMi4yLiAgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW09UTi1GV0tdICBGLlpoYW5nLCBELkxpLCBILkxpLCBT LkJlbG90dGksIEQuQ2VjY2FyZWxsaSwgIkZyYW1ld29yawogICAgICAgICAgICAgIGZvciBHTVBM UyBhbmQgUENFIENvbnRyb2wgb2YgRy43MDkgT3B0aWNhbCBUcmFuc3BvcnQKICAgICAgICAgICAg ICBuZXR3b3Jrcywgd29yayBpbiBwcm9ncmVzcwogICAgICAgICAgICAgIGRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMTMiLCBKdW5lIDIwMTMuCgogICBbT1ROLUlORk9dCiAg ICAgICAgICAgICAgUy5CZWxvdHRpLCBQLkdyYW5kaSwgRC5DZWNjYXJlbGxpLCBELkNhdmlnbGlh LCBGLlpoYW5nLAoKCgpDZWNjYXJlbGxpLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE1heSA4LCAy MDE0ICAgICAgICAgICAgICAgICBbUGFnZSAzM10KDApJbnRlcm5ldC1EcmFmdCAgICAgT1NQRi1U RSBleHRlbnNpb25zIGZvciBPVE4gc3VwcG9ydCAgICAgIE5vdmVtYmVyIDIwMTMKCgogICAgICAg ICAgICAgIEQuTGksICJJbmZvcm1hdGlvbiBtb2RlbCBmb3IgRy43MDkgT3B0aWNhbCBUcmFuc3Bv cnQKICAgICAgICAgICAgICBOZXR3b3JrcyAoT1ROKSwgd29yayBpbiBwcm9ncmVzcwogICAgICAg ICAgICAgIGRyYWZ0LWlldGYtY2NhbXAtb3RuLWc3MDktaW5mby1tb2RlbC0wOSIsIEp1bmUgMjAx My4KCiAgIFtPVE4tU0lHXSAgRi5aaGFuZywgRy5aaGFuZywgUy5CZWxvdHRpLCBELkNlY2NhcmVs bGksIEsuUGl0aGV3YW4sCiAgICAgICAgICAgICAgIkdlbmVyYWxpemVkIE11bHRpLVByb3RvY29s IExhYmVsIFN3aXRjaGluZyAoR01QTFMpCiAgICAgICAgICAgICAgU2lnbmFsaW5nIEV4dGVuc2lv bnMgZm9yIHRoZSBldm9sdmluZyBHLjcwOSBPcHRpY2FsCiAgICAgICAgICAgICAgVHJhbnNwb3J0 IE5ldHdvcmtzIENvbnRyb2wsIHdvcmsgaW4gcHJvZ3Jlc3MKICAgICAgICAgICAgICBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMTEiLCBKdW5lIDIwMTMuCgogICBbUkZD NTIyNl0gIE5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICJHdWlkZWxpbmVzIGZvciBXcml0 aW5nIGFuCiAgICAgICAgICAgICAgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3Mi LCBCQ1AgMjYsIFJGQyA1MjI2LAogICAgICAgICAgICAgIE1heSAyMDA4LgoKICAgW1JGQzU5MjBd ICBGYW5nLCBMLiwgIlNlY3VyaXR5IEZyYW1ld29yayBmb3IgTVBMUyBhbmQgR01QTFMKICAgICAg ICAgICAgICBOZXR3b3JrcyIsIFJGQyA1OTIwLCBKdWx5IDIwMTAuCgogICBbUkZDNjE2M10gIExl ZSwgWS4sIEJlcm5zdGVpbiwgRy4sIGFuZCBXLiBJbWFqdWt1LCAiRnJhbWV3b3JrIGZvcgogICAg ICAgICAgICAgIEdNUExTIGFuZCBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgKFBDRSkgQ29udHJv bCBvZgogICAgICAgICAgICAgIFdhdmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAo V1NPTnMpIiwgUkZDIDYxNjMsCiAgICAgICAgICAgICAgQXByaWwgMjAxMS4KCiAgIFtSRkM2NTY2 XSAgTGVlLCBZLiwgQmVybnN0ZWluLCBHLiwgTGksIEQuLCBhbmQgRy4gTWFydGluZWxsaSwgIkEK ICAgICAgICAgICAgICBGcmFtZXdvcmsgZm9yIHRoZSBDb250cm9sIG9mIFdhdmVsZW5ndGggU3dp dGNoZWQgT3B0aWNhbAogICAgICAgICAgICAgIE5ldHdvcmtzIChXU09Ocykgd2l0aCBJbXBhaXJt ZW50cyIsIFJGQyA2NTY2LCBNYXJjaCAyMDEyLgoKICAgW1NXQ0FQLVVQRFRdCiAgICAgICAgICAg ICAgRi5aaGFuZywgRC5MaSwgSC5MaSwgUy5CZWxvdHRpLCBELkNlY2NhcmVsbGksICJGcmFtZXdv cmsKICAgICAgICAgICAgICBmb3IgR01QTFMgYW5kIFBDRSBDb250cm9sIG9mIEcuNzA5IE9wdGlj YWwgVHJhbnNwb3J0CiAgICAgICAgICAgICAgbmV0d29ya3MsIHdvcmsgaW4gcHJvZ3Jlc3MKICAg ICAgICAgICAgICBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTEzIiwgSnVu ZSAyMDEzLgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgRGFuaWVsZSBDZWNjYXJlbGxpIChlZGl0 b3IpCiAgIEVyaWNzc29uCiAgIFZpYSBFLk1lbGVuIDc3CiAgIEdlbm92YSAtIEVyemVsbGkKICAg SXRhbHkKCiAgIEVtYWlsOiBkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tCgoKCgoKCgoK CkNlY2NhcmVsbGksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTWF5IDgsIDIwMTQgICAgICAgICAg ICAgICAgIFtQYWdlIDM0XQoMCkludGVybmV0LURyYWZ0ICAgICBPU1BGLVRFIGV4dGVuc2lvbnMg Zm9yIE9UTiBzdXBwb3J0ICAgICAgTm92ZW1iZXIgMjAxMwoKCiAgIEZhdGFpIFpoYW5nCiAgIEh1 YXdlaSBUZWNobm9sb2dpZXMKICAgRjMtNS1CIFImRCBDZW50ZXIsIEh1YXdlaSBCYXNlCiAgIFNo ZW56aGVuIDUxODEyOSBQLlIuQ2hpbmEgIEJhbnRpYW4sIExvbmdnYW5nIERpc3RyaWN0CiAgIFBo b25lOiArODYtNzU1LTI4OTcyOTEyCgogICBFbWFpbDogemhhbmdmYXRhaUBodWF3ZWkuY29tCgoK ICAgU2VyZ2lvIEJlbG90dGkKICAgQWxjYXRlbC1MdWNlbnQKICAgVmlhIFRyZW50bywgMzAKICAg VmltZXJjYXRlCiAgIEl0YWx5CgogICBFbWFpbDogc2VyZ2lvLmJlbG90dGlAYWxjYXRlbC1sdWNl bnQuY29tCgoKICAgUmFqYW4gUmFvCiAgIEluZmluZXJhIENvcnBvcmF0aW9uCiAgIDE0MCwgQ2Fz cGlhbiBDVC4KICAgU3Vubnl2YWxlLCBDQS05NDA4OQogICBVU0EKCiAgIEVtYWlsOiBycmFvQGlu ZmluZXJhLmNvbQoKCiAgIEpvaG4gRSBEcmFrZQogICBKdW5pcGVyCgoKICAgRW1haWw6IGpkcmFr ZUBqdW5pcGVyLm5ldAoKCgoKCgoKCgoKCgoKCgoKCgoKQ2VjY2FyZWxsaSwgZXQgYWwuICAgICAg ICAgRXhwaXJlcyBNYXkgOCwgMjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgMzVdCgwK --_004_4A1562797D64E44993C5CBF38CF1BE4817FBE0ESESSMB301ericsso_-- From heinerhummel@aol.com Sun Oct 27 02:26:23 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755A011E8125 for ; Sun, 27 Oct 2013 02:26: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 OmulU8SVyD0s for ; Sun, 27 Oct 2013 02:26:23 -0700 (PDT) Received: from omr-m04.mx.aol.com (omr-m04.mx.aol.com [64.12.143.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1979211E8262 for ; Sun, 27 Oct 2013 02:26:09 -0700 (PDT) Received: from mtaomg-ma03.r1000.mx.aol.com (mtaomg-ma03.r1000.mx.aol.com [172.29.41.10]) by omr-m04.mx.aol.com (Outbound Mail Relay) with ESMTP id 9F10370000088; Sun, 27 Oct 2013 05:26:08 -0400 (EDT) Received: from core-dqa003a.r1000.mail.aol.com (core-dqa003.r1000.mail.aol.com [172.29.211.201]) by mtaomg-ma03.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 623E0E000082; Sun, 27 Oct 2013 05:26:08 -0400 (EDT) References: <157601ced185$a27400d0$e75c0270$@olddog.co.uk> <170e01ced268$d82d6b10$88884130$@olddog.co.uk> To: adrian@olddog.co.uk, abdussalambaryun@gmail.com In-Reply-To: <170e01ced268$d82d6b10$88884130$@olddog.co.uk> X-MB-Message-Source: WebUI Received: from 178.26.195.50 by webmail-vd008.sysops.aol.com (205.188.20.112) with HTTP (WebMailUI); Sun, 27 Oct 2013 05:26:08 -0400 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D0A10DB3AFAF74_1AA8_7F1D4_webmail-vd008.sysops.aol.com" X-Mailer: Webmail 38121-STANDARD Message-Id: <8D0A10DB39A4302-1AA8-232E7@webmail-vd008.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Sun, 27 Oct 2013 05:26:08 -0400 (EDT) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1382865968; bh=d3Af9gglZKuqd6wa8LPQ/ClPsYNcNDZRkVypxVoxpUI=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=y4Q1xjCjf92DHlH3fC3BDoHRIik3CFq/CPFzRn9i3UT0/8TPEcF1ho1IMcSeCAAsC iIVmfPHMYekCJNG4rbkuudUDhEmLfXso5iU3RlBEb573VFvDwig7XfOrCRI6OXIsr9 SkDu3r4QbETWhg7DuujjDvM/rjittsJ7gzcDoVt4= x-aol-sid: 3039ac1d290a526cdc3076e4 X-Mailman-Approved-At: Wed, 30 Oct 2013 08:10:05 -0700 Cc: rtg-dir@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Topics for Routing Area meeting X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 09:26:23 -0000 This is a multi-part message in MIME format. ----------MB_8D0A10DB3AFAF74_1AA8_7F1D4_webmail-vd008.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Adrian, If you mean anyone including remote participants, I have two topics to name= : 1) State-less multicast 2) A discussion what means anycast user services (given that IPv6 even prov= ides address space for this) from the application's point of view as well a= s from the IP-layer's point of view; or even to develop the necessary routi= ng technology. Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Adrian Farrel An: 'Abdussalam Baryun' Cc: rtg-dir ; routing-discussion ; rtg-chairs Verschickt: Sa, 26 Okt 2013 6:32 pm Betreff: RE: Topics for Routing Area meeting Hi, =20 It is good of you to be interested. =20 In the Area meeting I think we are looking for topics of technical substanc= e that span the Routing Area. For example, in London we are promised a talk= from the Management AD on the importance of considering management concern= s when documenting routing protocols. =20 In a sense, that is exactly the sort of cross-area issue you are talking ab= out. But I think the specific topic you are raising (i.e., what cross-area = review and discussion is need and how should we cause it to happen) could b= e handled more profitably by an email discussion on the routing-discussion@= ietf.org list if it is specific to either RTG review of documents produced = in other areas, or other-area review of documents produced in RTG. Obviousl= y, the widest version of this topic (any-to-any cross-area review) belongs = on the main IETF list. =20 Adrian =20 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]=20 Sent: 26 October 2013 09:40 To: adrian@olddog.co.uk Cc: routing-discussion@ietf.org; rtg-chairs@ietf.org; rtg-dir@ietf.org Subject: Re: Topics for Routing Area meeting =20 If you mean anyone including remote participants, I have an issue not sure = about within routing area, which is the cross WG issues do we leave it to A= Ds to advise or do WGs Chairs should take over this task and discuss cross = issues, or participants/editor should consider this while developing I-Ds a= nd presentations. =20 Some people in IETF are concerned to compare our standards with other SDOs = while developing I-Ds within IETF, I think we need more cross-WG considerat= ions within developing standards and WG-charters. =20 AB On Friday, October 25, 2013, Adrian Farrel wrote: Hi, Does anyone have a topic they want to cover in this meeting? Let us know. Adrian and Stewart. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion =20 ----------MB_8D0A10DB3AFAF74_1AA8_7F1D4_webmail-vd008.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Hi Adrian,
If you mea= n anyone including remote participants, I have two topics to name:
1= ) State-less multicast
2) A discussion what means anycast user servi= ces (given that IPv6 even provides address space for this) from the applica= tion's point of view as well as from the IP-layer's point of view; or even = to develop the necessary routing technology.

Heiner



-----= Urspr=C3=BCngliche Mitteilung-----
Von: Adrian Farrel <adrian@olddog.co.uk>
An: 'Abdussalam Baryun' <abdussalambaryun@gmail.com>
Cc: rtg-dir <rtg-dir@ietf.org>; routing-discussion <routing-discus= sion@ietf.org>; rtg-chairs <rtg-chairs@ietf.org>
Verschickt: Sa, 26 Okt 2013 6:32 pm
Betreff: RE: Topics for Routing Area meeting

Hi,<= /span>
&nbs= p;
It i= s good of you to be interested.
&nbs= p;
In t= he Area meeting I think we are looking for topics of technical substance th= at span the Routing Area. For example, in London we are promised a talk fro= m the Management AD on the importance of considering management concerns wh= en documenting routing protocols.
&nbs= p;
In a= sense, that is exactly the sort of cross-area issue you are talking about.= But I think the specific topic you are raising (i.e., what cross-area revi= ew and discussion is need and how should we cause it to happen) could be ha= ndled more profitably by an email discussion on the routing-discussion@ietf.org list if it is speci= fic to either RTG review of documents produced in other areas, or other-are= a review of documents produced in RTG. Obviously, the widest version of thi= s topic (any-to-any cross-area review) belongs on the main IETF list.
&nbs= p;
Adri= an
&nbs= p;
From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 26 October 2013 09:40
To: adrian@olddog.co.uk Cc: routing-discussio= n@ietf.org; rtg-chairs@ietf.org<= /a>; rtg-dir@ietf.org
Subject: Re: Topics for Routing Area meeting
 
If you mean anyone including remote participants, = I have an issue not sure about within routing area, which is the cross= WG issues do we leave it to ADs to advise or do WGs Chairs should tak= e over this task and discuss cross issues, or participants/editor should co= nsider this while developing I-Ds and presentations.
 
Some people in IETF are concerned to compare = our standards with other SDOs while developing I-Ds within IETF, I thi= nk we need more cross-WG considerations within developing standards an= d WG-charters.
 
AB

On Friday, October 25, 2013, Adrian Farrel wrote:
Hi,

Does anyone have a topic they want to cover in this meeting?

Let us know.

Adrian and Stewart.

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion 
________________________________________=
_______
routing-discussion mailing list
routing-discussion@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/routing-discussion
----------MB_8D0A10DB3AFAF74_1AA8_7F1D4_webmail-vd008.sysops.aol.com-- From hadi@mojatatu.com Thu Oct 31 03:46:53 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998E511E8316 for ; Thu, 31 Oct 2013 03:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 qSRCfp15yL20 for ; Thu, 31 Oct 2013 03:46:19 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA9211E8314 for ; Thu, 31 Oct 2013 03:46:17 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id ks9so1810691vcb.17 for ; Thu, 31 Oct 2013 03:46:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=6jRpQVM96NiX06QIW8HYSPtH2mpp92tjGnDxIMP9j8Y=; b=kzlHt3tpJGKzNynYtoB1guZcmz5z5/k8UjlVKKKAMqvDFV3uPR7lvkXYOjKPh/e/2K PDtIXzG+ykpBymH4IFmxshnVDA9lDiOy5lVApJTUmUg5MN7A//vIF6couvBOZzSPartK Aito4DHvbsgRtqoYEfWRVja6BEmIS8OTuWO/lDmP0XM0E5bMyFyjiTkcozFVTqVQtqYM gfKa+TWC2S+j67J/wvaLMYjZnfSTqw1yqEI+/53yzmttZwbLfn6mv3CIrst+TFNw0cxG H1Ad2jX3c0dKsY7L1Q1B+D0vn0b3XkUTeG3Lym6lv/ft63nL+yk3pSoaV0qMKp1iFnXr 92Dg== X-Gm-Message-State: ALoCoQkPRZYUMVAeDRvVdb4El/JI3iIlEiBU4rdBSK8TkS4L8NF35US3wVPrmwPzp7AA/bguAarc X-Received: by 10.58.168.205 with SMTP id zy13mr1395063veb.19.1383216376665; Thu, 31 Oct 2013 03:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.8.19 with HTTP; Thu, 31 Oct 2013 03:45:56 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 31 Oct 2013 06:45:56 -0400 Message-ID: To: "rtg-ads@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-sin-sdnrg-sdn-approach@tools.ietf.org, "rtg-dir@ietf.org" , "sdn@irtf.org" Subject: [RTG-DIR] RtgDir review: draft-sin-sdnrg-sdn-approach X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 10:46:53 -0000 Salutations, 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-sin-sdnrg-sdn-approach-04 Reviewer: Jamal Hadi Salim Review Date: 31 October 2013 IETF LC End Date: 2013-11-04 Intended Status: Informational o Summary: This document provides a perspective of a service provider on the SDN landscape. The document builds context for a taxanomy on SDN, as seen from a service provider's lens, to do gap analysis which leads to advise with a dose of reality check. o Comments: I think this document is ready for publication. I have a couple of minor comments. o Major Issues: No major issues found. o Minor Issues: 1) It would probably make sense, based on the content and tone, to title section 3 as "Reality Check" (instead of "A few considerations") 2) Please fix my last name in the acks from "Salim" to "Hadi Salim" cheers, jamal