From ogondio@tid.es Tue Oct 1 00:38:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F111121F9A6C for ; Tue, 1 Oct 2013 00:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBF1nMNHtmrB for ; Tue, 1 Oct 2013 00:38:23 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 56FCC21F918F for ; Tue, 1 Oct 2013 00:38:20 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MTZ004FBBVIG4@tid.hi.inet> for ccamp@ietf.org; Tue, 01 Oct 2013 09:38:08 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 2B.30.28420.FDB7A425; Tue, 01 Oct 2013 09:38:07 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MTZ00EVIBVJNA@tid.hi.inet> for ccamp@ietf.org; Tue, 01 Oct 2013 09:38:07 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0123.003; Tue, 01 Oct 2013 09:38:07 +0200 Date: Tue, 01 Oct 2013 07:38:05 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= X-Originating-IP: [10.95.64.115] To: Lou Berger , DEBORAH A BRUNGARD Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_4n1ArYnBUPs81aTHsGwmmQ)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: Request for early IANA Allocation of values for new flag and RRO sub-object in draft-ietf-ccamp-rsvp-te-srlg-collect-03 Thread-index: AQHOvnkqNCPHky1ky0iNDxJLfoE5EQ== user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4e69-b7fe58e000006f04-0a-524a7bdf482e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42Lhivcz1L1f7RVksOijpcWTOTdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0fdtB2NBh3HFurn32RoYL2p3MXJySAiYSOyf/5QRwhaTuHBv PVsXIxeHkMB2RolLW0+wQjg/GSVevZ/HAuFsZJQ4/fMZK0gLi4CqxPMPZ9lAbDYBB4l1i3rB 2oUFmhgl3k7fxgIxV0Hiz7nHYLaIgJvEwqk7wMYyC/QySpx7vxNsOa+AtsSPqffYIWxBiR+T 74E1MAv4SvRtvsQOYYtLzPk1EWwzo4CsxMrzpxlBBokItDNKbHnayQ6xQU+i8+VpsKGiQHbb sTPsEFcISCzZc54ZwhaVePn4H+sERtFZSPbNQrJvFpJ9ELaexI2pU9ggbG2JZQtfM0PYuhIz /h2C6jWTuLr7OCOymgWMHKsYxYqTijLTM0pyEzNz0g2M9DIy9TLzUks2MULiL3MH4/KdKocY BTgYlXh4Deo9g4RYE8uKK3MPMUpwMCuJ8LZVeAUJ8aYkVlalFuXHF5XmpBYfYmTi4JRqYLS7 M8nmqNuSi/Yv/n779M1Tqv7eWfZFG1TcnVTzVN8w3q3WkSk+v3vl+XrDme7y84yDPF8IhHZ2 BXg3qP88/N/Bt3uryB4zfp0DqTdmSbF7qr3d/b7j0J1nz+ZsF/O88rFxQf7KuZLHEla61rMX ptra+MocrldTLmSbY25y5E+OMo8C801LdSWW4oxEQy3mouJEALPXV7SdAgAA Cc: CCAMP , "draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org" Subject: [CCAMP] Request for early IANA Allocation of values for new flag and RRO sub-object in draft-ietf-ccamp-rsvp-te-srlg-collect-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 07:38:28 -0000 --Boundary_(ID_4n1ArYnBUPs81aTHsGwmmQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Dear CCAMP WG chairs, Following the procedure for Early IANA Allocation of Standards Track Code P= oints defined in Section 3.1 of RFC 4020, on behalf of the authors of the W= G draft "RSVP-TE Extensions for Collecting SRLG Information", draft-ietf-cc= amp-rsvp-te-srlg-collect-03, it is requested to CCAMP WG chairs the early a= llocation of the following values: --> Value for a new flag, named "SRLG Collection Flag" in the RSVP Attribu= te Bit Flags space. IANA has created a registry and manages the space of at= tributes bit flags of Attribute Flags TLV, as described in section 11.3 of = [RFC5420], in the "Attributes TLV Space" section of the "Resource Reservati= on Protocol-Traffic Engineering (RSVP-TE) Parameters" registry located in h= ttps://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xhtml= . The document "RSVP-TE Extensions for Collecting SRLG Information",dra= ft-ietf-ccamp-rsvp-te-srlg-collect-03, introduces and defines a new Attribu= te Bit Flag, named "SRLG Collection Flag". It is requested that IANA makes = an early assignment of the value of the "SRLG Collection Flag" from the At= tribute Bit Flags. --> Type for a new RRO sub-object, named "SRLG sub-object " within the ROU= TE_RECORD Object space. IANA has made assignments in the "Class Names, Clas= s Numbers, and Class Types" section of the "RSVP PARAMETERS" registry locat= ed at http://www.iana.org/assignments/rsvp-parameters. It is requested that IANA makes an early assignment of the type of the new = proposed RRO sub object in the document draft-ietf-ccamp-rsvp-te-srlg-colle= ct-03 named "SRLG sub-object" from the ROUTE_RECORD portions of the mention= ed registry. The main reason for the request of the early allocation is to facilitate in= teroperability of early implementations, as other WG documents have also ne= w values in the same registry and clashes have been identified with the sug= gested values in the drafts. We only request the allocation of those parame= ters whose definition we think to be stable. Best Regards, Oscar ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_4n1ArYnBUPs81aTHsGwmmQ) Content-id: <7C75387914DB1049828FA4862C404667@hi.inet> Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Dear CCAMP WG chairs,

Follow= ing the procedure for Early IANA Allocation of Standards Track Code Points = defined in Section 3.1 of RFC 4020, on behalf of the authors of the WG draf= t "RSVP-TE Extensions for Collecting SRLG Information", draft-ietf-ccamp-rsvp-te-srlg-collect-03,&nbs= p;it is requested to CCAMP WG chairs the early allocation  of the foll= owing values:

-->  Value for a new flag, named "SRLG Collection Fl= ag" in the RSVP Attribute Bit Flags space. IANA has created = a registry and manages the space of attributes bit flags of Attribute = Flags TLV, as described in section 11.3 of [RFC5420], in the "Att= ributes TLV Space" section of the "Resource Reservation Protocol-Tr= affic Engineering (RSVP-TE) Parameters" registry located in https= ://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xhtml. &n= bsp;
     The  document "RSVP-TE Extensions f= or Collecting SRLG Information",draft-ietf-ccamp-rsvp-te-srlg-collect-= 03, introduces and defines a new Attribute Bit Flag, named "SRLG = Collection Flag". It is requested that IANA makes an early a= ssignment of the  value of the "SRLG Collection Flag" from the Attribute Bit= Flags. 

-->  Type for a new RRO sub-object, named "SRLG sub-objec= t " within the ROUTE_RECORD Object space. IANA has made= assignments in the "Class Names, Class Numbers, and Class Types&= quot; section of the "RSVP PARAMETERS" registry located at h= ttp://www.iana.org/assignments/rsvp-parameters.  
It is = requested that IANA makes an early assignment of the type of the new p= roposed RRO sub object in the document draft-ietf-ccamp-rsvp-te-srlg-c= ollect-03 named "SRLG sub-object" from the ROUTE_RECORD = ;portions of the mentioned registry.

The ma= in reason for the request of the early allocation is to facilitate interope= rability of early implementations, as other WG documents have also new valu= es in the same registry and clashes have been identified with the suggested values in the drafts. We only requ= est the allocation of those parameters whose definition we think to be stab= le.
Best Regards,

Oscar<= /div>



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_4n1ArYnBUPs81aTHsGwmmQ)-- From daniele.ceccarelli@ericsson.com Tue Oct 1 00:40:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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= Cc: "rtg-dir@ietf.org" , CCAMP WG , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [CCAMP] I: [RTG-DIR] R: RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 internet-drafts@ietf.org Tue Oct 1 01:16:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0912D21F9C6A; Tue, 1 Oct 2013 01:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39snBOjQoI+K; Tue, 1 Oct 2013 01:16:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD73321F9A6C; Tue, 1 Oct 2013 01:16:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131001081644.4916.68131.idtracker@ietfa.amsl.com> Date: Tue, 01 Oct 2013 01:16:44 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 08:16:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Traffic Engineering Extensions to OSPF for Generalized M= PLS (GMPLS) Control of Evolving G.709 OTN Networks Author(s) : Daniele Ceccarelli Fatai Zhang Sergio Belotti Rajan Rao John E Drake Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-09.txt Pages : 34 Date : 2013-10-01 Abstract: This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC4203. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniele.ceccarelli@ericsson.com Tue Oct 1 01:18:49 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA1D21F9C10 for ; Tue, 1 Oct 2013 01:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[AWL=-1.312, 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 iZ7qVibGlTe3 for ; Tue, 1 Oct 2013 01:18:37 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id BA31A21F9C36 for ; Tue, 1 Oct 2013 01:18:23 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-ba-524a854d49d2 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 24.3F.25272.D458A425; Tue, 1 Oct 2013 10:18:22 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Tue, 1 Oct 2013 10:18:18 +0200 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" Thread-Topic: New Version Notification for draft-ietf-ccamp-gmpls-ospf-g709v3-09.txt Thread-Index: AQHOvn6gKcCGB2SjB0aBMQDCmQDGuJnfgErQ Date: Tue, 1 Oct 2013 08:18:18 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4815B951@ESESSMB301.ericsson.se> References: <20131001081658.4916.43173.idtracker@ietfa.amsl.com> In-Reply-To: <20131001081658.4916.43173.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvra5fq1eQQUeTsMWTOTdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMbF7HXPBN+GKnV09bA2MW4S7GDk5JARMJE5Nu80EYYtJXLi3 nq2LkYtDSOAoo8TS/ZOhnMWMEqdWrWfpYuTgYBOwknhyyAekQURAV2LvxuvMILawQKjEqiWf WSDiYRInf65kg7CNJFr/XABbwCKgItF8fyeYzSvgLfH8x01WEFtIwEFiReMTdhCbU8BRYuvB KWBxRgFZiQm7FzGC2MwC4hK3nsyHOlRAYsme88wQtqjEy8f/WCFsRYmr05czgZzJLKApsX6X PkSrosSU7ofsEGsFJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEjyypGjuLU4qTcdCODTYzAoD+4 5bfFDsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZFpfuaa/28Y LzssfSvb3aqmJTDz2PPf6pG3dxSXffj+T6VUxmBehtLvCp15cm3LvqSVy8103Xtc+j/DtDNx v+Zdt7P9q1t7Qu3Av39fC671/PT48XF5hpac8oeS/h3zPG8sOXw7S0fPlKOdyZHHuebxmSW9 p68cCTzO6f/z8W1xAyOu4L0ptQVKLMUZiYZazEXFiQAwZA8rSAIAAA== Subject: [CCAMP] FW: New Version Notification for draft-ietf-ccamp-gmpls-ospf-g709v3-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 08:18:49 -0000 RGVhciBDQ0FNUCwNCg0KQSBuZXcgdmVyc2lvbiBvZiB0aGUgT1NQRiBHNzA5djMgZHJhZnQgaGFz IGp1c3QgYmVlbiB1cGxvYWRlZC4gSXQgdHJpZXMgdG8gYWRkcmVzcyB0aGUgQUQgcmV2aWV3IGNv bW1lbnRzIGFzIHBlcjogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NjYW1w L2N1cnJlbnQvbXNnMTUyMDUuaHRtbA0KDQpCUg0KQXV0aG9ycw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IG1hcnRlZMOsIDEgb3R0b2JyZSAyMDEzIDEwOjE3 DQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBGYXRhaSBaaGFuZzsgSm9obiBEcmFrZTsgUmFqYW4g UmFvOyBKb2huIEUgRHJha2U7IFNlcmdpbyBCZWxvdHRpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtb3NwZi1nNzA5djMtMDkudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtb3NwZi1n NzA5djMtMDkudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhbmllbGUg Q2VjY2FyZWxsaSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1l OgkgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1vc3BmLWc3MDl2Mw0KUmV2aXNpb246CSAwOQ0KVGl0 bGU6CQkgVHJhZmZpYyBFbmdpbmVlcmluZyBFeHRlbnNpb25zIHRvIE9TUEYgZm9yIEdlbmVyYWxp emVkIE1QTFMgKEdNUExTKSBDb250cm9sIG9mIEV2b2x2aW5nIEcuNzA5IE9UTiBOZXR3b3Jrcw0K Q3JlYXRpb24gZGF0ZToJIDIwMTMtMTAtMDENCkdyb3VwOgkJIGNjYW1wDQpOdW1iZXIgb2YgcGFn ZXM6IDM0DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtb3NwZi1nNzA5djMtMDkudHh0DQpTdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1vc3BmLWc3MDl2Mw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLW9zcGYtZzcwOXYzLTA5DQpEaWZmOiAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtb3NwZi1nNzA5djMtMDkNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyBPcGVuIFNob3J0ZXN0IFBhdGggRmlyc3QgLSBUcmFmZmljDQogICBFbmdpbmVlcmluZyAoT1NQ Ri1URSkgcm91dGluZyBwcm90b2NvbCBleHRlbnNpb25zIHRvIHN1cHBvcnQNCiAgIEdlbmVyYWxp emVkIE1QTFMgKEdNUExTKSBjb250cm9sIG9mIE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmtzIChP VE4pDQogICBzcGVjaWZpZWQgaW4gSVRVLVQgUmVjb21tZW5kYXRpb24gRy43MDkgYXMgcHVibGlz aGVkIGluIDIwMTIuICBJdA0KICAgZXh0ZW5kcyBtZWNoYW5pc21zIGRlZmluZWQgaW4gUkZDNDIw My4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From lberger@labn.net Tue Oct 1 05:26:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E2D11E80FF 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.897 X-Spam-Level: X-Spam-Status: No, score=-101.897 tagged_above=-999 required=5 tests=[AWL=0.368, 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 4rTAQ+NSIliC for ; Tue, 1 Oct 2013 05:26:53 -0700 (PDT) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id E2C3F11E80EC 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 , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [CCAMP] I: [RTG-DIR] R: RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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鈥檛 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 iesg-secretary@ietf.org Tue Oct 1 08:41:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BCF21E81EF; Tue, 1 Oct 2013 08:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-YNVezyr4pE; Tue, 1 Oct 2013 08:41:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D92C621E8255; Tue, 1 Oct 2013 08:41:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131001154127.21382.5300.idtracker@ietfa.amsl.com> Date: Tue, 01 Oct 2013 08:41:27 -0700 Cc: ccamp mailing list , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Revised Definition of The GMPLS Switching Capability and Type Fields' to Proposed Standard (draft-ietf-ccamp-swcaps-update-03.txt) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 15:41:51 -0000 The IESG has approved the following document: - 'Revised Definition of The GMPLS Switching Capability and Type Fields' (draft-ietf-ccamp-swcaps-update-03.txt) as Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ccamp-swcaps-update/ Technical Summary GMPLS provides control for multiple switching technologies, and hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate switching technology type. These values are carried in routing in the Switching Capability field, and in signaling in the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates any document that uses the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. Working Group Summary: Nothing of note. Good support by the WG. Document Quality: This document updates the definitions for the Switching Type field to be consistent and deprecates three previously defined switching types. For existing implementations, the primary impact of this document is deprecating the use of PSC-2, 3 and 4. At the time of publication, there are no known deployments (or even implementations) that make use of these values so there is no compatibility issues for current routing and signaling implementations. Personnel: Deborah Brungard (dbrungard@att.com) is the Document Shepherd. Adrian Farrel (Adrian@olddog.co.uk) is the Area Director. RFC Editor Note Abstract OLD This document updates any document that uses the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. NEW This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. END Section 1 OLD In particular this document proposes deprecating the use of the Switching Types as an identifier of hierarchy levels within a switching technology, and limit its use to identification of a per-switching technology SCSI field format. NEW In particular this document deprecates the use of the Switching Types as an identifier of hierarchy levels within a switching technology, and limits its use to identification of a per-switching technology SCSI field format. END Section 1.1 (end) s/ Descriptor .../ Descriptor./ Section 5 OLD IANA needs to deprecate and redefine the related registry NEW IANA needs to deprecate some values and redefine the related registr END From lberger@labn.net Tue Oct 1 09:35:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1E411E81DC for ; Tue, 1 Oct 2013 09:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=0.480, 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 LLHi2jvcQf8C for ; Tue, 1 Oct 2013 09:35:41 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id EF8CD11E8153 for ; Tue, 1 Oct 2013 09:35:13 -0700 (PDT) Received: (qmail 7476 invoked by uid 0); 1 Oct 2013 16:34:51 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by qproxy1.mail.unifiedlayer.com with SMTP; 1 Oct 2013 16:34:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=bpPgYYZh8NIWvRBPpBM4ylv5e38/iISx/InbPwI7gWA=; b=PZnw5ju/igyeO18ASRVx05GTpBEm0pIb0nNzbvwfPhXxB+F6Yf/ewt77EwFdOfxURVgj5zPFjL1kNWS6cwAtv4oiX0O1kqYlyTxbsWOVzgCjXDcXC5s2wPhf5FWYFdtm; Received: from box313.bluehost.com ([69.89.31.113]:38901 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VR2uR-0001kA-7l for ccamp@ietf.org; Tue, 01 Oct 2013 10:34:51 -0600 Message-ID: <524AF9A9.3040006@labn.net> Date: Tue, 01 Oct 2013 12:34:49 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 16:35:46 -0000 All, This mail begins working group last call on the WSON documents. As there are 6 documents in this set, the last call will be three weeks. The documents included in the last call are: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 (Informational, IPR Disclosed) http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 (Standards Track, IPR Disclosed) http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 (Standards Track) http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 (Standards Track, IPR Disclosed) http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 (Standards Track, IPR Disclosed) http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards Track) Also has one open issue that will need to be resolved as part of LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. This working group last call ends on October 22. Comments should be sent to the CCAMP mailing list. Please remember to include the technical basis for any comments. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! Please note that we're still missing some IPR statements. Any forthcoming publication request will be delayed by late IPR statements/disclosures. Thank you, Lou (and Deborah) From db3546@att.com Tue Oct 1 14:24:09 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7287221E80C7 for ; Tue, 1 Oct 2013 14:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuCXS6XW+2EK for ; Tue, 1 Oct 2013 14:23:33 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id CF39921F9CEA for ; Tue, 1 Oct 2013 14:23:07 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 83d3b425.0.1206197.00-192.3401209.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 01 Oct 2013 21:23:11 +0000 (UTC) X-MXL-Hash: 524b3d3f52434153-cd1c68996633310a901e4cff5ee86d757d35ae7d Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r91LN3wG004344 for ; Tue, 1 Oct 2013 17:23:04 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r91LMlFW004096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Oct 2013 17:22:57 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Tue, 1 Oct 2013 21:22:28 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0158.001; Tue, 1 Oct 2013 17:22:28 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Poll on making draft-ogrcetal-ccamp-flexi-grid-fwk-03 a WG document-Closed Thread-Index: Ac6+7FHfndbHMrd+SEWc6M6lj4xFqQ== Date: Tue, 1 Oct 2013 21:22:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C80C0BD27DMISOUT7MSGUSR9O_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=IPW1/HTG c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=aR3f-eevh4QA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=HEFd6S1KF] X-AnalysisOut: [N0A:10 a=48vgC7mUAAAA:8 a=6395D88C4xZvPChkB50A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA] X-AnalysisOut: [:8 a=mPCUdzpf4J5ai1j0lt0A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S] X-AnalysisOut: [4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=Cd30ETv4W8TZzj] X-AnalysisOut: [Oq:21] Subject: Re: [CCAMP] Poll on making draft-ogrcetal-ccamp-flexi-grid-fwk-03 a WG document-Closed X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 21:24:09 -0000 --_000_F64C10EAA68C8044B33656FA214632C80C0BD27DMISOUT7MSGUSR9O_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, This poll is closed. The document has good support to be adopted. Authors, Please resubmit with name change only to draft-ietf-ccamp-flexi-grid-fwk Thank you, Deborah (and Lou) From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Monday, September 16, 2013 3:35 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ogrcetal-ccamp-flexi-grid-fwk-03 a WG= document All, This is to start a two week poll on making draft-ogrcetal-ccamp-flexi-grid-= fwk-03 a ccamp working group document. Please send email to the list indica= ting "yes/support" or "no/do not support". If indicating no, please state y= our technical reservations with the document. The poll ends Monday, September 30th. Thanks, Deborah and Lou --_000_F64C10EAA68C8044B33656FA214632C80C0BD27DMISOUT7MSGUSR9O_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 <= /p>

This poll is closed. The = document has good support to be adopted.

 <= /p>

Authors,

 <= /p>

Please resubmit with name= change only to draft-ietf-ccamp-flexi-grid-fwk

 <= /p>

Thank you,

Deborah (and Lou)

 <= /p>

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Monday, September 16, 2013 3:35 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ogrcetal-ccamp-flexi-grid-fwk-= 03 a WG document

 

All,

 

This is to start a two week poll on mak= ing draft-ogrcetal-ccamp-flexi-grid-fwk-03 a ccamp working group document. = Please send email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your techn= ical reservations with the document.

 

The poll ends Monday, September 30th.

 

Thanks,

Deborah and Lou

 

 

--_000_F64C10EAA68C8044B33656FA214632C80C0BD27DMISOUT7MSGUSR9O_-- From ogondio@tid.es Wed Oct 2 08:10:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39C621F9360 for ; Wed, 2 Oct 2013 08:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKR6rh3S55h1 for ; Wed, 2 Oct 2013 08:10:45 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1825621F9609 for ; Wed, 2 Oct 2013 08:07:34 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MU100AZ8RCKTM@tid.hi.inet> for ccamp@ietf.org; Wed, 02 Oct 2013 17:07:32 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id A4.46.28420.4B63C425; Wed, 02 Oct 2013 17:07:32 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MU100AZ3RCJTM@tid.hi.inet> for ccamp@ietf.org; Wed, 02 Oct 2013 17:07:31 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Wed, 02 Oct 2013 17:07:30 +0200 Date: Wed, 02 Oct 2013 15:07:29 +0000 From: =?Windows-1252?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: X-Originating-IP: [10.95.64.115] To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_jQeyJ+P02lLx2A7HuXehNw)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [CCAMP] Poll on making draft-ogrcetal-ccamp-flexi-grid-fwk-03 a WG document-Closed Thread-index: AQHOv4EcF+e3j/zQfUqw3NZyd7Xo+w== user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4e69-b7fe58e000006f04-98-524c36b4f86e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42Lhivcz1N1i5hNk8PqAoMWTOTdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0fG4kangkm3FnYvXmRoY75h1MXJySAiYSPxe/4QFwhaTuHBv PVsXIxeHkMB2RokTe9tYIZyfjBIPj6xhAqkSEpjJKNF5xR/EZhFQlbiz9i8riM0m4CTR0HOe EcQWFkiU6FmyBCzOKRAj8f39c1aIDQoSf849BtrGwSEi4CsxdTrYSF4BbYnpO26xQNiCEj8m 3wOzmYFKZretZISwxSXm/JoINoZRQFZi5fnTYHERgSSJd8c/sULYehLnHuxlA7FFgey2Y2fY IdYKSCzZc54ZwhaVePn4H+sERtFZSNbNQrJuFpJ1ELaBxPtz85khbG2JZQtfQ9n6Ehu/nAWq 5wCyzSQaZpkiK1nAyLGKUaw4qSgzPaMkNzEzJ93ASC8jUy8zL7VkEyMk5jJ3MC7fqXKIUYCD UYmHd6K2T5AQa2JZcWXuIUYJDmYlEd4DICHelMTKqtSi/Pii0pzU4kOMTBycUg2Mel1TuNpa f/3JbnrIci7jXuZc6Xuym9NONH8V9XRsMb1jduDV7ZcTtj0tUn5zJ6bcrDbaea95as1zz+J6 rdrL5rxGenxugluyqpQVJolaqacnT2Mv3diw6nqNSk8Ki0S6vbfw/EVBtrdm7S5f/lz/WcL1 ue/41vmkPX36cXuhk4HFgxiPlnVKLMUZiYZazEXFiQBF3022lwIAAA== Subject: Re: [CCAMP] Poll on making draft-ogrcetal-ccamp-flexi-grid-fwk-03 a WG document-Closed X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 15:10:57 -0000 --Boundary_(ID_jQeyJ+P02lLx2A7HuXehNw) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Dear Deborah, The document draft-ietf-ccamp-flexi-grid-fwk-00 has been submitted, Best Regards, Oscar All, This poll is closed. The document has good support to be adopted. Authors, Please resubmit with name change only to draft-ietf-ccamp-flexi-grid-fwk Thank you, Deborah (and Lou) From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Monday, September 16, 2013 3:35 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ogrcetal-ccamp-flexi-grid-fwk-03 a WG= document All, This is to start a two week poll on making draft-ogrcetal-ccamp-flexi-grid-= fwk-03 a ccamp working group document. Please send email to the list indica= ting =93yes/support=94 or =93no/do not support=94. If indicating no, please= state your technical reservations with the document. The poll ends Monday, September 30th. Thanks, Deborah and Lou ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_jQeyJ+P02lLx2A7HuXehNw) Content-id: Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable
Dear Deborah,

The do= cument draft-ietf-ccamp-flexi-grid-fwk-00 has been submitted,

Best R= egards,

Oscar<= /div>

All,

 

This poll is closed. The document has good= support to be adopted.

 

Authors,

 

Please resubmit with name change only to d= raft-ietf-ccamp-flexi-grid-fwk

 

Thank you,

Deborah (and Lou)

 

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Monday, September 16, 2013 3:35 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ogrcetal-ccamp-flexi-grid-fwk-= 03 a WG document

 

All,

 

This is to start a two week poll on making draft-ogrcetal-ccamp-= flexi-grid-fwk-03 a ccamp working group document. Please send email to the = list indicating =93yes/support=94 or =93no/do not support=94. If indicating no, please state your technical reservations= with the document.

 

The poll ends Monday, September 30th.

 

Thanks,

Deborah and Lou

 

 



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_jQeyJ+P02lLx2A7HuXehNw)-- From jdrake@juniper.net Wed Oct 2 11:32:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21CF21F9ED1 for ; Wed, 2 Oct 2013 11:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDsnC+qS52sH for ; Wed, 2 Oct 2013 11:31:59 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAB221F88FB for ; Wed, 2 Oct 2013 11:26:41 -0700 (PDT) Received: from mail37-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Oct 2013 18:26:41 +0000 Received: from mail37-ch1 (localhost [127.0.0.1]) by mail37-ch1-R.bigfish.com (Postfix) with ESMTP id 2587E4E0188 for ; Wed, 2 Oct 2013 18:26: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: -8 X-BigFish: VPS-8(zzddf5rzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail37-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(15202345003)(69226001)(31966008)(51856001)(74502001)(47446002)(4396001)(74662001)(46102001)(83072001)(59766001)(47736001)(50986001)(47976001)(81686001)(49866001)(83322001)(19580395003)(65816001)(81816001)(15975445006)(80022001)(77982001)(80976001)(63696002)(79102001)(33646001)(66066001)(81542001)(81342001)(53806001)(74876001)(76482001)(54356001)(56816003)(77096001)(74316001)(74706001)(56776001)(54316002)(76176001)(76576001)(76786001)(76796001)(74366001)(85306001)(568214003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail37-ch1 (localhost.localdomain [127.0.0.1]) by mail37-ch1 (MessageSwitch) id 1380738399743940_5684; Wed, 2 Oct 2013 18:26:39 +0000 (UTC) Received: from CH1EHSMHS009.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail37-ch1.bigfish.com (Postfix) with ESMTP id A785940040 for ; Wed, 2 Oct 2013 18:26:39 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Oct 2013 18:26:39 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.359.1; Wed, 2 Oct 2013 18:26:37 +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; Wed, 2 Oct 2013 18:26:35 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) with mapi id 15.00.0775.005; Wed, 2 Oct 2013 18:26:35 +0000 From: John E Drake To: "CCAMP (ccamp@ietf.org)" Thread-Topic: Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQ== Date: Wed, 2 Oct 2013 18:26:34 +0000 Message-ID: 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: 0987ACA2E2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 18:32:10 -0000 HI, I was reading: http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diver= sity/?include_text=3D1, and I happened to notice the following paragraph: "The means by which the node calculating or expanding the route of the sign= aled LSP discovers the route of the path(s) from which the signaled LSP requires diversity are beyond the scope of this document. " Doesn't this disclaimer effectively render this draft useless? The draft a= lso does not define how the node that initially signaled the LSP finds the = 'node calculating or expanding the route' nor how it delivers the signaled LSP request to th= at node. As an aside, the draft: http://datatracker.ietf.org/doc/draft-ali-ccamp-rs= vp-te-include-route/?include_text=3D1 would be subject to the same criticis= m except that the above quoted paragraph is replaced with: "The above-mentioned use cases require relevant path inclusion requirements= to be communicated to the route expanding nodes. This document addresses these requirements and defines procedures to address them."=20 Even though this is helpful, the draft doesn't actually define these proced= ures. Yours Irrespectively, John From jmh@joelhalpern.com Wed Oct 2 11:38:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" Subject: Re: [CCAMP] I: [RTG-DIR] R: RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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鈥檛 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 iesg-secretary@ietf.org Wed Oct 2 14:46:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA5D21F9F45; Wed, 2 Oct 2013 14:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJxNcn13sC54; Wed, 2 Oct 2013 14:46:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D685221F9F0A; Wed, 2 Oct 2013 14:46:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131002214615.20697.2968.idtracker@ietfa.amsl.com> Date: Wed, 02 Oct 2013 14:46:15 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: (Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 21:46:54 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC4203. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1835/ http://datatracker.ietf.org/ipr/1621/ From db3546@att.com Thu Oct 3 13:04:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A175621F8E2D for ; Thu, 3 Oct 2013 13:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd2gQKv3QSQA for ; Thu, 3 Oct 2013 13:03:51 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id EA3C521F94FA for ; Thu, 3 Oct 2013 12:44:33 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 129cd425.0.2439314.00-338.6853655.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 03 Oct 2013 19:44:35 +0000 (UTC) X-MXL-Hash: 524dc923575bf6b1-6bbf0c2260df6444743bc18747b83ab48ac023bb Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r93JiWd7013841 for ; Thu, 3 Oct 2013 15:44:32 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r93JiP58013775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Oct 2013 15:44:29 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Thu, 3 Oct 2013 19:44:05 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 15:44:05 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-dhody-ccamp-rsvp-te-domain-subobjects-02 a WG document-Closed Thread-Index: Ac7AcOgu8q+15i/KRxazH0k63a4tEw== Date: Thu, 3 Oct 2013 19:44:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C80C0BE023MISOUT7MSGUSR9O_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=IPW1/HTG c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=ATC87pJe6PAA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=26KtgZ-Bw] X-AnalysisOut: [ZIA:10 a=48vgC7mUAAAA:8 a=v8ySuWTr0Uanj0cEI10A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=2TSDkfqdCjIA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAA] X-AnalysisOut: [A:8 a=SSmOFEACAAAA:8 a=4TsRtyZeCIb58NkIJPIA:9 a=gKO2Hq4RSV] X-AnalysisOut: [kA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:1] X-AnalysisOut: [0 a=T_Q2TXcRYHwrue-W:21] Subject: Re: [CCAMP] Poll on making draft-dhody-ccamp-rsvp-te-domain-subobjects-02 a WG document-Closed X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 20:04:03 -0000 --_000_F64C10EAA68C8044B33656FA214632C80C0BE023MISOUT7MSGUSR9O_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, This poll is closed. The document had relative support to be adopted. Authors, Please resubmit with name change only to draft-ietf-ccamp-rsvp-te-domain-su= bobjects. As you improve on the document, please take into consideration Ad= rian's comments on improving the use case description and ensure that you s= tay aligned with the PCE work. Thanks, Deborah (and Lou) From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Thursday, September 12, 2013 11:54 AM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-dhody-ccamp-rsvp-te-domain-subobjects= -02 a WG document ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. All, This is to start a two week poll on making draft-dhody-ccamp-rsvp-te-domain= -subobjects-02 a ccamp working group document. Please send email to the lis= t indicating "yes/support" or "no/do not support". If indicating no, please= state your technical reservations with the document. The poll ends Thursday, Sept. 26th. Thanks, Deborah and Lou --_000_F64C10EAA68C8044B33656FA214632C80C0BE023MISOUT7MSGUSR9O_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 <= /p>

This poll is closed. The = document had relative support to be adopted.

 <= /p>

Authors,

 <= /p>

Please resubmit with name= change only to draft-ietf-ccamp-rsvp-te-domain-subobjects. As you improve = on the document, please take into consideration Adrian’s comments on improving the use case description and ensure that you stay al= igned with the PCE work.

 <= /p>

Thanks,=

Deborah (and Lou)

 <= /p>

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, September 12, 2013 11:54 AM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-dhody-ccamp-rsvp-te-domain-sub= objects-02 a WG document

 

***Security Advisory: This Message Originated Outside of= AT&T ***
Reference http://cso= .att.com/EmailSecurity/IDSP.html for more information.

All,

 

This is to start a two week poll on mak= ing draft-dhody-ccamp-rsvp-te-domain-subobjects-02 a ccamp working group do= cument. Please send email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your te= chnical reservations with the document.

 

The poll ends Thursday, Sept. 26= th.

 

Thanks,

Deborah and Lou

 

--_000_F64C10EAA68C8044B33656FA214632C80C0BE023MISOUT7MSGUSR9O_-- From daniele.ceccarelli@ericsson.com Fri Oct 4 03:31:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0811521F91BF for ; Fri, 4 Oct 2013 03:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13c5z0aDkXAW for ; Fri, 4 Oct 2013 03:30:53 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4B321F9123 for ; Fri, 4 Oct 2013 03:30:44 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-0a-524e98d33eaf Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F9.94.03802.3D89E425; Fri, 4 Oct 2013 12:30:43 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Fri, 4 Oct 2013 12:30:43 +0200 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" Thread-Topic: IETF 88 - CCAMP agenda requests Thread-Index: Ac7A62fizl6s11uwRBqP7yxjH/V66Q== Date: Fri, 4 Oct 2013 10:30:42 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.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.18] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4815CE4DESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvre7lGX5BBifmqlg8mXODxeJyVze7 RUfzWxYHZo+X/XMYPZYs+cnk8WFTM1sAcxSXTUpqTmZZapG+XQJXxq5jUQXvoyrWPm5mbmDs DOxi5OCQEDCRuLnLuIuRE8gUk7hwbz1bFyMXh5DAYUaJ77M2s0I4ixkl1t1/zw7SwCZgJfHk kA9Ig4iArsTejdeZQWqYBTYzStz9PokNJCEsoCGxYc9udpiiI497mSBsPYl1dzaA1bAIqEic fLGPGcTmFfCWuDJzOyuIzSggKzFh9yJGEJtZQFzi1pP5TBDXCUgs2XOeGcIWlXj5+B8rhK0o 8fHVPqj6fIlPC5pZIWYKSpyc+YRlAqPwLCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkD j5mQxRcwsq9iZM9NzMxJLzfaxAiMmoNbfqvuYLxzTuQQozQHi5I474e3zkFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGKcwCSobPHA801dxpKxr1ZaAE9krAotVvse2H76V9z1E8Lvxe3bF 4xsuVl8/NP/HWblbxowJEx71FWzmmc9n4PHgev6DOXKtJpZl5xhtHvL2K4lx7g29aBJY4Hv5 rLngb19h0Scz3LJPXDg7gbXbsu+nKu9qPgex1thNjqnsiY9mTOrj5WM5r8RSnJFoqMVcVJwI AJhPdcRoAgAA Subject: [CCAMP] IETF 88 - CCAMP agenda requests X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 10:31:04 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE4815CE4DESESSMB301ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear CCAMP, IETF 88 meeting is approaching and it's time to start collecting agenda slo= ts requests. Keeping this in mind: Authors of active working group documents should plan on presenting status = (briefly, including recent changes), open issues/discussion topics and plan= ned next steps at the meeting. Alternatively, an update can be provided vi= a e-mail to the list in the *week prior* to the meeting. Agenda Requests: - To submit a request, please fill the survey at the following link: http:/= /www.surveymonkey.com/s/QLK9BB6 - Please fill the survey no later than Sunday, October 20. Presentations: If you are presenting slides please make sure you send them to all *indi= viduals* listed above (Chairs, Secretary and exclude CCAMP) no later than = Sunday, November 3. Reminder about a few important dates: * 2013-10-21 (Monday): Internet Draft submission cut-off (for all draft= s, including -00) by UTC 24:00, upload using IETF ID Submission Tool. * 2013-10-23 (Wednesday): Draft Working Group agendas due by UTC 24:00,= upload using IETF Meeting Materials Management Tool. * 2013-10-28 (Monday): Revised Working Group agendas due by UTC 24:00, = upload using IETF Meeting Materials Management Tool. * 2013-11-03 - 2013-11-08: 88th IETF Meeting in Vancouver, BC, Canada. BR Daniele & CCAMP chairs --_000_4A1562797D64E44993C5CBF38CF1BE4815CE4DESESSMB301ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear CCAMP,

 

IETF 88 meeting is approaching and it’s time t= o start collecting agenda slots requests.

 

Keeping this in mind:

Authors of active working group documents should = plan on presenting status (briefly, including recent changes), open issues/= discussion topics and planned next steps at the meeting.  Alternativel= y, an update can be provided via e-mail to the list in the *week prior* to the meeting.

 

Agenda Requests:

- To submit a request, please fill the sur= vey at the following link: http://www.surveymonkey.c= om/s/QLK9BB6

- Please fill the survey no later than Sunday,= October 20.

 

Presentations:

  If you are presenting slides please make s= ure you send them to  all *individuals* listed above (Chairs, Secretar= y and exclude CCAMP) no later  than Sunday, November 3.

 

Reminder about a few important dates:

BR

Daniele & CCAMP cha= irs

 

--_000_4A1562797D64E44993C5CBF38CF1BE4815CE4DESESSMB301ericsso_-- From internet-drafts@ietf.org Fri Oct 4 07:02:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B1121F9994; Fri, 4 Oct 2013 07:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VmAekyTvExF; Fri, 4 Oct 2013 07:02:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 484C321F9B9F; Fri, 4 Oct 2013 06:55:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131004135532.12797.25752.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2013 06:55:32 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-flexi-grid-fwk-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 14:02:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Framework and Requirements for GMPLS based control of Fl= exi-grid DWDM networks Author(s) : Oscar Gonzalez de Dios Ramon Casellas Fatai Zhang Xihua Fu Daniele Ceccarelli Iftekhar Hussain Filename : draft-ietf-ccamp-flexi-grid-fwk-00.txt Pages : 30 Date : 2013-10-02 Abstract: This document defines a framework and the associated control plane requirements for the GMPLS based control of flexi-grid DWDM networks. To allow efficient allocation of optical spectral bandwidth for high bit-rate systems, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended the recommendations [G.694.1] and [G.872] to include the concept of flexible grid. A new DWDM grid has been developed within the ITU-T Study Group 15 by defining a set of nominal central frequencies, channel spacings and the concept of "frequency slot". In such environment, a data plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-flexi-grid-fwk-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Oct 4 07:03:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB3021F9DCA; Fri, 4 Oct 2013 07:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eemyKUUuUBhI; Fri, 4 Oct 2013 07:03:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6347421F9DD5; Fri, 4 Oct 2013 06:55:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131004135556.12797.15745.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2013 06:55:56 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-domain-subobjects-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 14:03:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Domain Subobjects for Resource ReserVation Protocol - Tr= affic Engineering (RSVP-TE) Author(s) : Dhruv Dhody Udayasree Palle Venugopal Reddy Kondreddy Ramon Casellas Filename : draft-ietf-ccamp-rsvp-te-domain-subobjects-00.txt Pages : 17 Date : 2013-10-04 Abstract: The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) specification [RFC3209] and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE [RFC3473] allow abstract nodes and resources to be explicitly included in a path setup. Further Exclude Routes extensions [RFC4874] allow abstract nodes and resources to be explicitly excluded in a path setup. This document specifies new subobjects to include or exclude domains during path setup where domain is a collection of network elements within a common sphere of address management or path computational responsibility (such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS)). Note that the use of AS as an abstract node representing domain is already defined in [RFC3209] and [RFC4874], albeit with a 2-Byte AS number. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-domain-subobjects There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-domain-subobjects-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhang.xian@huawei.com Mon Oct 7 18:42:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1788121E8115 for ; Mon, 7 Oct 2013 18:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9Z3-WlGgdH0 for ; Mon, 7 Oct 2013 18:42:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCE021E8117 for ; Mon, 7 Oct 2013 18:42:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYR66975; Tue, 08 Oct 2013 01:42:00 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 02:41:36 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 02:41:56 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.167]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.03.0146.000; Tue, 8 Oct 2013 09:41:48 +0800 From: "Zhangxian (Xian)" To: "ccamp@ietf.org" Thread-Topic: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-00.txt Thread-Index: AQHOvMYHLs+trSDnwEKq9jEM2JTyepnqE35w Date: Tue, 8 Oct 2013 01:41:47 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 01:42:07 -0000 RGVhciBhbGwsIA0KDQogICBXZSBoYXZlIHVwbG9hZGVkIGEgbmV3IGRyYWZ0IGFzIGRldGFpbGVk IGJlbG93LiBUaGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0IGlzIHRvIGZhY2lsaXRhdGUgcm91dGUg ZXhjbHVzaW9uIHVzaW5nIHBhdGgga2V5IGJ5IGV4dGVuZGluZyB0aGUgUlNWUCBYUk8gYW5kIEVS TyBvYmplY3RzLiANCg0KICAgQW55IGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4gDQoNCkJlc3Qg UmVnYXJkcywNClhpYW4gKG9uIGJlaGFsZiBvZiBjby1hdXRob3JzKQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IDIwMTPlubQ55pyIMjnml6UgMTE6NDMNClRv OiBaaGFuZ3hpYW4gKFhpYW4pOyBGYXRhaSBaaGFuZzsgT3NjYXIgR29uemFsZXogZGUgRGlvczsg SWdvciBCcnlza2luDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXpoYW5nLWNjYW1wLXJvdXRlLWV4Y2x1c2lvbi1wYXRoa2V5LTAwLnR4dA0KDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC16aGFuZy1jY2FtcC1yb3V0ZS1leGNsdXNpb24tcGF0aGtleS0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhbiBaaGFuZyBhbmQg cG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXpoYW5n LWNjYW1wLXJvdXRlLWV4Y2x1c2lvbi1wYXRoa2V5DQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBF eHRlbnNpb25zIHRvIFJlc291cmNlIFJlU2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5naW5l ZXJpbmcgKFJTVlAtIFRFKSB0byBTdXBwb3J0IFJvdXRlIEV4Y2x1c2lvbiBVc2luZyBQYXRoIEtl eSBTdWJvYmplY3QNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA5LTI5DQpHcm91cDoJCSBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogOQ0KVVJMOiAgICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGFuZy1jY2FtcC1yb3V0ZS1l eGNsdXNpb24tcGF0aGtleS0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1jY2FtcC1yb3V0ZS1leGNsdXNpb24tcGF0aGtl eQ0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFu Zy1jY2FtcC1yb3V0ZS1leGNsdXNpb24tcGF0aGtleS0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhp cyBkb2N1bWVudCBleHRlbmRzIHRoZSBSZXNvdXJjZSBSZVNlclZhdGlvbiBQcm90b2NvbC1UcmFm ZmljDQogICBFbmdpbmVlcmluZyAoUlNWUC1URSkgZVhjbHVkZSBSb3V0ZSBPYmplY3QgKFhSTykg YW5kIEV4cGxpY2l0IFJvdXRlDQogICBPYmplY3QgKEVSTykgdG8gc3VwcG9ydCBzcGVjaWZ5aW5n IHJvdXRlIGV4Y2x1c2lvbiByZXF1aXJlbWVudCB1c2luZw0KICAgUGF0aCBLZXkgU3Vib2JqZWN0 IChQS1MpLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From zhangfatai@huawei.com Tue Oct 8 00:01:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A79921E815D for ; Tue, 8 Oct 2013 00:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wUf704m8rGf for ; Tue, 8 Oct 2013 00:01:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9956221E8155 for ; Tue, 8 Oct 2013 00:01:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYR89175; Tue, 08 Oct 2013 07:01:44 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 08:01:13 +0100 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 08:01:41 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.86]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0146.000; Tue, 8 Oct 2013 15:01:33 +0800 From: Fatai Zhang To: John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQ Date: Tue, 8 Oct 2013 07:01:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 07:01:51 -0000 Hi John, Totally agree with you, I already found these two drafts are much *useless*= .=20 This is why we made a new draft (very simple and useful) and put our feet o= n the ground.=20 http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion-pathk= ey-00.txt Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Thursday, October 03, 2013 2:27 AM To: CCAMP (ccamp@ietf.org) Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE= ) Path Diversity using Exclude Routes HI, I was reading: http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diver= sity/?include_text=3D1, and I happened to notice the following paragraph: "The means by which the node calculating or expanding the route of the sign= aled LSP discovers the route of the path(s) from which the signaled LSP requires diversity are beyond the scope of this document. " Doesn't this disclaimer effectively render this draft useless? The draft a= lso does not define how the node that initially signaled the LSP finds the = 'node calculating or expanding the route' nor how it delivers the signaled LSP request to th= at node. As an aside, the draft: http://datatracker.ietf.org/doc/draft-ali-ccamp-rs= vp-te-include-route/?include_text=3D1 would be subject to the same criticis= m except that the above quoted paragraph is replaced with: "The above-mentioned use cases require relevant path inclusion requirements= to be communicated to the route expanding nodes. This document addresses these requirements and defines procedures to address them."=20 Even though this is helpful, the draft doesn't actually define these proced= ures. Yours Irrespectively, John _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Tue Oct 8 09:32:31 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52F21E826A for ; Tue, 8 Oct 2013 09:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=-1.825, 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 ue1UOTttwtVY for ; Tue, 8 Oct 2013 09:32:26 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C00F621E81C6 for ; Tue, 8 Oct 2013 09:32:25 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-09-52543398d355 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B1.D2.25272.89334525; Tue, 8 Oct 2013 18:32:24 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Tue, 8 Oct 2013 18:32:24 +0200 From: Daniele Ceccarelli To: Fatai Zhang , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABN/2rA= Date: Tue, 8 Oct 2013 16:32:24 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvre4M45Agg12zNC2ezLnBYjHnrrNF X/N5Vgdmj5Yjb1k9liz5yeRxvekqewBzFJdNSmpOZllqkb5dAlfGz5ufmAsuSVa8edXP0sD4 Q6SLkZNDQsBE4t6LV8wQtpjEhXvr2boYuTiEBI4ySry/u4kFwlnMKPFq7wegKg4ONgEriSeH fEAaRATKJTY2fWAEsYUFyiQerb7KBhOf8XsbI4RtJdHX/IkRpJVFQEXiwpcikDCvgLfEiVv7 GCHGL2SUeH3qCBNIDadAmMTal7wgNYwCshITdi8CG8MsIC5x68l8Jog7BSSW7DkPdbOoxMvH /1hBWiUEFCWW98tBlOtJ3Jg6hQ3C1pZYtvA1M8RaQYmTM5+wTGAUnYVk6iwkLbOQtMxC0rKA kWUVI0dxanFSbrqRwSZGYGwc3PLbYgfj5b82hxilOViUxHk/vnUOEhJITyxJzU5NLUgtii8q zUktPsTIxMEp1cCYMvtSynOxibvPMHzWj707mS2latIT+d1r55fMODI79KPi/9vnHP+t3vHI Z2H7kr9nxGeWdwZHhDPn7XoSt0aZs9J99dNyn62z+E+/mjOX+YrF43hlM9Vqphj/8t8zTzOK awUFX9Z3vDJVb6th2/Q/AcqBJbf071ccEu239lTY7vh2YwjTwW5PJZbijERDLeai4kQAFqfa FVsCAAA= Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:32:31 -0000 Thanks John for pointing that out. When I first read the draft I missed tha= t point. I see two differences between the two drafts: 1. utilization of 5ple vs Path key 2. The path diversity draft does not say how to collect the 5ple (which in = some cases could not be available at all), the path key draft covers this a= spect also Re 1 I have a moderate preference for the path key for the security reasons= that lead to the definition of the Path Key years ago and secondly it's si= mpler. Re 2 I don't know how the WG will manage the issue of two competing drafts = (one wg, the other individual) but in any case it's an issue that need to b= e fixed somehow. BR Daniele > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Fatai Zhang > Sent: marted=EC 8 ottobre 2013 09:02 > To: John E Drake; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > (RSVP-TE) Path Diversity using Exclude Routes >=20 > Hi John, >=20 > Totally agree with you, I already found these two drafts are much *useles= s*. >=20 > This is why we made a new draft (very simple and useful) and put our feet= on > the ground. >=20 > http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion- > pathkey-00.txt >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of John E Drake > Sent: Thursday, October 03, 2013 2:27 AM > To: CCAMP (ccamp@ietf.org) > Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP- > TE) Path Diversity using Exclude Routes >=20 > HI, >=20 > I was reading: http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp- > diversity/?include_text=3D1, and I happened to notice the following parag= raph: >=20 > "The means by which the node calculating or expanding the route of the > signaled LSP discovers the route of the path(s) from which the signaled L= SP > requires diversity are beyond the scope of this document. " >=20 > Doesn't this disclaimer effectively render this draft useless? The draft= also > does not define how the node that initially signaled the LSP finds the 'n= ode > calculating or expanding the route' nor how it delivers the signaled LSP > request to that node. >=20 > As an aside, the draft: http://datatracker.ietf.org/doc/draft-ali-ccamp-= rsvp- > te-include-route/?include_text=3D1 would be subject to the same criticism > except that the above quoted paragraph is replaced with: >=20 > "The above-mentioned use cases require relevant path inclusion > requirements to be communicated to the route expanding nodes. This > document addresses these requirements and defines procedures to > address them." >=20 > Even though this is helpful, the draft doesn't actually define these > procedures. >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Tue Oct 8 10:28:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFE221E8271 for ; Tue, 8 Oct 2013 10:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm+clbtwcTbG for ; Tue, 8 Oct 2013 10:28:21 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9AE21E8279 for ; Tue, 8 Oct 2013 10:28:13 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 3a044525.0.4681827.00-284.13144538.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 08 Oct 2013 17:28:13 +0000 (UTC) X-MXL-Hash: 525440ad73a138da-d02886e56ab79e2c00b8e3472bfbedbf34abdbf3 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r98HS3Al008289 for ; Tue, 8 Oct 2013 13:28:03 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r98HRroS008122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Oct 2013 13:27:57 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Tue, 8 Oct 2013 17:27:40 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0158.001; Tue, 8 Oct 2013 13:27:40 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: WG secretary change and thanks to Dan Thread-Index: Ac7ES7BJZDIo1PJ0TYyUwDb88n6rGQ== Date: Tue, 8 Oct 2013 17:27:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.69.101] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C80C0BF6D4MISOUT7MSGUSR9O_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=O52OSmBW c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=NBCWkiIW8uAA:10 a=4aBEPFXm8g4A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=CQ24vLHzB] X-AnalysisOut: [-AA:10 a=tuuemKkPZC-sKLy9TRYA:9 a=CjuIK1q_8ugA:10 a=sOZasn] X-AnalysisOut: [2MD5IA:10 a=FoZXaxiaZmYA:10 a=1AoprO8VHI_rQrMTIZAA:9 a=_W_] X-AnalysisOut: [S_7VecoQA:10 a=frz4AuCg-hUA:10 a=cjh8W46Ov5fGW6Oo:21] Subject: [CCAMP] WG secretary change and thanks to Dan X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:28:28 -0000 --_000_F64C10EAA68C8044B33656FA214632C80C0BF6D4MISOUT7MSGUSR9O_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCAMP, Dan King has decided to resign from his position as our WG's (co-) secretar= y. We want to thank him for all his support over these years (he was our fi= rst secretary) and wish him all the best. He says he will still be able to = attend CCAMP as a participant and we look forward to his continued contribu= tion to the WG. Much thanks Dan! Daniele will continue as our WG secretary. Lou and Deborah --_000_F64C10EAA68C8044B33656FA214632C80C0BF6D4MISOUT7MSGUSR9O_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
CCAMP,
 
Dan King has decided to resign from his position as our WG’s (co= -) secretary. We want to thank him for all his support over these years (he= was our first secretary) and wish him all the best. He says he will still = be able to attend CCAMP as a participant and we look forward to his continued contribution to the WG.
 
Much thanks Dan!
 
Daniele will continue as our WG secretary.
 
Lou and Deborah
 
 --_000_F64C10EAA68C8044B33656FA214632C80C0BF6D4MISOUT7MSGUSR9O_-- From zali@cisco.com Tue Oct 8 10:47:31 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA0811E810C for ; Tue, 8 Oct 2013 10:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDcbCUJWqfC1 for ; Tue, 8 Oct 2013 10:47:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9247E11E81BA for ; Tue, 8 Oct 2013 10:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2729; q=dns/txt; s=iport; t=1381254445; x=1382464045; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=sbPmmmtfHXpcPWsRB+xpqXg9uRTRwryHKcc+s+HCj50=; b=YSlRH3u3OPK/axNQExJ2WKCt4R1Fdy8P4xa7A8F3TuhXvRhuCXNNxFc8 Be1gzOo9sudMbWHtyzTwHme3riFMyQ1H0DuKy3y8EFqvYKubebi948dKC pGCjl5d9EarjtiHrXS6naUfp8/fDMaW9mJot24ahTiy6ROCAKZNwxbnlL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAAlEVFKtJV2Z/2dsb2JhbABZgwc4UsElgSIWdIIlAQEBBAEBAWsXBgEIEQMBAQELGQQuCxQJCAEBBAESCAESh2sMunOPETgGgxmBBAOZMJBRgWaBPoIq X-IronPort-AV: E=Sophos;i="4.90,1057,1371081600"; d="scan'208";a="269596409" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 08 Oct 2013 17:47:25 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r98HlPpe032028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Oct 2013 17:47:25 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 8 Oct 2013 12:47:24 -0500 From: "Zafar Ali (zali)" To: Fatai Zhang , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYA= Date: Tue, 8 Oct 2013 17:47:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.235.242] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1305E8690807D9448CD1E350ACE236F6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:47:31 -0000 Fatai and all-=20 In a stateless PCE, Path Keys are transient and they expire. For this solution to work you need a PCE that can keep Paths associated with a Path Key around (a stateful PCE where states are path computed by the PCE). Thanks Regards =8A Zafar -----Original Message----- From: Fatai Zhang Date: Tuesday, October 8, 2013 3:01 AM To: "jdrake@juniper.net" , "ccamp@ietf.org" Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes >Hi John, > >Totally agree with you, I already found these two drafts are much >*useless*.=20 > >This is why we made a new draft (very simple and useful) and put our feet >on the ground.=20 > >http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion-path >key-00.txt > > > > >Best Regards > >Fatai > > >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >John E Drake >Sent: Thursday, October 03, 2013 2:27 AM >To: CCAMP (ccamp@ietf.org) >Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering >(RSVP-TE) Path Diversity using Exclude Routes > >HI, > >I was reading: =20 >http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?include_te >xt=3D1, and I happened to notice the following paragraph: > >"The means by which the node calculating or expanding the route of the >signaled LSP discovers the route of the path(s) from which the signaled >LSP > requires diversity are beyond the scope of this document. " > >Doesn't this disclaimer effectively render this draft useless? The draft >also does not define how the node that initially signaled the LSP finds >the 'node calculating >or expanding the route' nor how it delivers the signaled LSP request to >that node. > >As an aside, the draft: >http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-te-include-route/?inc >lude_text=3D1 would be subject to the same criticism >except that the above quoted paragraph is replaced with: > >"The above-mentioned use cases require relevant path inclusion >requirements to be communicated to the route expanding nodes. This >document addresses > these requirements and defines procedures to address them." > >Even though this is helpful, the draft doesn't actually define these >procedures. > >Yours Irrespectively, > >John > > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Tue Oct 8 10:53:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6E921E827F for ; Tue, 8 Oct 2013 10:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL6s2RuMBBgF for ; Tue, 8 Oct 2013 10:53:35 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id DE79321E8209 for ; Tue, 8 Oct 2013 10:53:12 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 88644525.0.4794261.00-150.13430862.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 08 Oct 2013 17:53:14 +0000 (UTC) X-MXL-Hash: 5254468a75a823cd-dfa4e643cc66b9274e85c5bf7d09ab07519ed3a1 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r98HrBrL004895 for ; Tue, 8 Oct 2013 13:53:12 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r98Hr7tX004803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Oct 2013 13:53:09 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Tue, 8 Oct 2013 17:52:55 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0158.001; Tue, 8 Oct 2013 13:52:55 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Proposed Liaison to ITU-T's SG15 Q6 and Q12 Thread-Index: Ac7ETzbFEJc8IoigQzOAyKIqlgXD/Q== Date: Tue, 8 Oct 2013 17:52:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.69.101] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C80C0BF745MISOUT7MSGUSR9O_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=IPW1/HTG c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=NBCWkiIW8uAA:10 a=SoUtPnEXjK8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=jajwg5fpG] X-AnalysisOut: [nMA:10 a=48vgC7mUAAAA:8 a=xjnMe2nOWjEPl-yPnPsA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=Lvm-s_rizUiUlXQYkkgA:9 a=_W_S_7VecoQA:10 a=frz4] X-AnalysisOut: [AuCg-hUA:10 a=UdtBxalzAtTM0tMn:21] Subject: [CCAMP] Proposed Liaison to ITU-T's SG15 Q6 and Q12 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:53:41 -0000 --_000_F64C10EAA68C8044B33656FA214632C80C0BF745MISOUT7MSGUSR9O_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCAMP, Here's a proposed liaison to ITU-T on our Flexible Grid work. Let us know if any concerns, Deborah and Lou ------------------- Title: CCAMP work on Flexible Grid DWDM networks The CCAMP Working Group would like to inform you that we have initiated con= trol plane work on supporting Flexible Grid DWDM networks with the followin= g document: http://www.ietf.org/id/draft-ietf-ccamp-flexi-grid-fwk-00.txt Our understanding of the n and m parameters, when used to describe a freque= ncy slot, have to be integer, as per G.694.1. From a signaling perspective= , since we are signaling actual frequency slots on a hop per hop basis, we = would use integer values. It is our understanding that typically a consiste= nt value of n would be used for a path over multiple network elements, thou= gh the Recommendation does not constrain it. The CCAMP WG would like to ask if our understanding is accurate. We would appreciate if you would continue to keep us informed of your progr= ess and development on capabilities for the data plane that may affect the = control plane. Best regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs --_000_F64C10EAA68C8044B33656FA214632C80C0BF745MISOUT7MSGUSR9O_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
CCAMP,
 
Here’s a proposed liaison to ITU-T on our Flexible Grid work.
Let us know if any concerns,
Deborah and Lou
-------------------
Title: CCAMP work on Flexible Grid DWDM networks
 
The CCAMP Working Group would like to inform you that we have initiate= d control plane work on supporting Flexible Grid DWDM networks with the fol= lowing document:
 
Our understanding of the n and m parameters, when used to describe a f= requency slot, have to be integer, as per G.694.1.  From a signaling p= erspective, since we are signaling actual frequency slots on a hop per hop = basis, we would use integer values. It is our understanding that typically a consistent value of n would be used f= or a path over multiple network elements, though the Recommendation does no= t constrain it.
 
The CCAMP WG would like to ask if our understanding is accurate.
 
We would appreciate if you would continue to keep us informed of your = progress and development on capabilities for the data plane that may affect= the control plane.
 
Best regards,
Lou Berger and Deborah Brungard
IETF CCAMP Working Group Co-Chairs
 
 
 
 
 --_000_F64C10EAA68C8044B33656FA214632C80C0BF745MISOUT7MSGUSR9O_-- From jdrake@juniper.net Tue Oct 8 15:21:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E9E21E80B4 for ; Tue, 8 Oct 2013 15:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=-0.875, 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 se83HZcHhc5i for ; Tue, 8 Oct 2013 15:21:00 -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 CA30B21E809A for ; Tue, 8 Oct 2013 15:20:59 -0700 (PDT) Received: from mail2-db8-R.bigfish.com (10.174.8.244) by DB8EHSOBE033.bigfish.com (10.174.4.96) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Oct 2013 22:20:58 +0000 Received: from mail2-db8 (localhost [127.0.0.1]) by mail2-db8-R.bigfish.com (Postfix) with ESMTP id B668C9C0240; Tue, 8 Oct 2013 22:20:58 +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: -19 X-BigFish: VPS-19(zz9371Ic85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail2-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:(189002)(199002)(377454003)(54356001)(74876001)(53806001)(74316001)(81542001)(66066001)(54316002)(81342001)(76482001)(33646001)(76796001)(74366001)(85306002)(76786001)(56816003)(77096001)(74706001)(16236675002)(56776001)(76576001)(4396001)(59766001)(83072001)(15202345003)(51856001)(31966008)(69226001)(47736001)(50986001)(47976001)(81686001)(80022001)(74662001)(79102001)(74502001)(77982001)(80976001)(19300405004)(47446002)(63696002)(46102001)(49866001)(83322001)(81816001)(65816001)(19580405001)(19580395003)(15975445006)(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 mail2-db8 (localhost.localdomain [127.0.0.1]) by mail2-db8 (MessageSwitch) id 1381270857378561_12008; Tue, 8 Oct 2013 22:20:57 +0000 (UTC) Received: from DB8EHSMHS017.bigfish.com (unknown [10.174.8.248]) by mail2-db8.bigfish.com (Postfix) with ESMTP id 4B8E61980048; Tue, 8 Oct 2013 22:20:57 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS017.bigfish.com (10.174.4.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Oct 2013 22:20:57 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 8 Oct 2013 22:20:55 +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 22:20:53 +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 22:20:53 +0000 From: John E Drake To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: WG secretary change and thanks to Dan Thread-Index: Ac7ES7BJZDIo1PJ0TYyUwDb88n6rGQAKL9qQ Date: Tue, 8 Oct 2013 22:20:52 +0000 Message-ID: <20aaaf9f71aa4e3092573dd36c68aab7@BY2PR05MB142.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0993689CD1 Content-Type: multipart/alternative; boundary="_000_20aaaf9f71aa4e3092573dd36c68aab7BY2PR05MB142namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] WG secretary change and thanks to Dan X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 22:21:06 -0000 --_000_20aaaf9f71aa4e3092573dd36c68aab7BY2PR05MB142namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Deborah Isn't also the case that had had to leave the UK rather suddenly and that n= o one knows his current whereabouts? Yours Irrespectively, John From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Tuesday, October 08, 2013 10:28 AM To: ccamp@ietf.org Subject: [CCAMP] WG secretary change and thanks to Dan CCAMP, Dan King has decided to resign from his position as our WG's (co-) secretar= y. We want to thank him for all his support over these years (he was our fi= rst secretary) and wish him all the best. He says he will still be able to = attend CCAMP as a participant and we look forward to his continued contribu= tion to the WG. Much thanks Dan! Daniele will continue as our WG secretary. Lou and Deborah --_000_20aaaf9f71aa4e3092573dd36c68aab7BY2PR05MB142namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Deborah=

 <= /p>

Isn’t also the case= that had had to leave the UK rather suddenly and that no one knows his cur= rent whereabouts?

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: ccamp-= bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Tuesday, October 08, 2013 10:28 AM
To: ccamp@ietf.org
Subject: [CCAMP] WG secretary change and thanks to Dan

 

CCAMP,

 

Dan King has decided to resign from his= position as our WG’s (co-) secretary. We want to thank him for all h= is support over these years (he was our first secretary) and wish him all the best. He says he will still be able to attend CCAMP as a parti= cipant and we look forward to his continued contribution to the WG.

 

Much thanks Dan!

 

Daniele will continue as our WG secreta= ry.

 

Lou and Deborah

 

--_000_20aaaf9f71aa4e3092573dd36c68aab7BY2PR05MB142namprd05pro_-- From jdrake@juniper.net Tue Oct 8 15:27:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167FF11E812D for ; Tue, 8 Oct 2013 15:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxIWjSVZGXgi for ; Tue, 8 Oct 2013 15:27:22 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id C1D8311E811A for ; Tue, 8 Oct 2013 15:26:20 -0700 (PDT) Received: from mail116-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Oct 2013 22:26:19 +0000 Received: from mail116-ch1 (localhost [127.0.0.1]) by mail116-ch1-R.bigfish.com (Postfix) with ESMTP id 0F1324201BB; Tue, 8 Oct 2013 22:26:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail116-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=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(13464003)(189002)(51704005)(37854004)(377454003)(19580395003)(74706001)(74316001)(74366001)(63696002)(80022001)(79102001)(83322001)(19580405001)(65816001)(81342001)(69226001)(77982001)(81542001)(59766001)(50986001)(66066001)(47736001)(47976001)(49866001)(83072001)(85306002)(56776001)(51856001)(53806001)(76482001)(4396001)(54316002)(46102001)(81686001)(76796001)(56816003)(76786001)(77096001)(76576001)(74876001)(33646001)(47446002)(74502001)(80976001)(31966008)(54356001)(81816001)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail116-ch1 (localhost.localdomain [127.0.0.1]) by mail116-ch1 (MessageSwitch) id 1381271177604273_3289; Tue, 8 Oct 2013 22:26:17 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail116-ch1.bigfish.com (Postfix) with ESMTP id 8E5D02A00C2; Tue, 8 Oct 2013 22:26:17 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Oct 2013 22:26:17 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 8 Oct 2013 22:26:16 +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; Tue, 8 Oct 2013 22:26:14 +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 22:26:14 +0000 From: John E Drake To: "Zafar Ali (zali)" , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: AQHOw/RvMrBCr56VuU2xebXAhUabxpnrFPqAgABNoZA= Date: Tue, 8 Oct 2013 22:26:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0993689CD1 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 22:27:28 -0000 Zafar, So, is your assertion that RFC5553 is broken? Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Tuesday, October 08, 2013 10:47 AM > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > (RSVP-TE) Path Diversity using Exclude Routes >=20 > Fatai and all- >=20 > In a stateless PCE, Path Keys are transient and they expire. For this sol= ution > to work you need a PCE that can keep Paths associated with a Path Key > around (a stateful PCE where states are path computed by the PCE). >=20 > Thanks >=20 > Regards =A9 Zafar >=20 >=20 > -----Original Message----- > From: Fatai Zhang > Date: Tuesday, October 8, 2013 3:01 AM > To: "jdrake@juniper.net" , "ccamp@ietf.org" > > Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > (RSVP-TE) Path Diversity using Exclude Routes >=20 > >Hi John, > > > >Totally agree with you, I already found these two drafts are much > >*useless*. > > > >This is why we made a new draft (very simple and useful) and put our > >feet on the ground. > > > >http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion-p > >ath > >key-00.txt > > > > > > > > > >Best Regards > > > >Fatai > > > > > >-----Original Message----- > >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > >Of John E Drake > >Sent: Thursday, October 03, 2013 2:27 AM > >To: CCAMP (ccamp@ietf.org) > >Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > >(RSVP-TE) Path Diversity using Exclude Routes > > > >HI, > > > >I was reading: > >http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?include > >_te xt=3D1, and I happened to notice the following paragraph: > > > >"The means by which the node calculating or expanding the route of the > >signaled LSP discovers the route of the path(s) from which the signaled > >LSP requires diversity are beyond the scope of this document. " > > > >Doesn't this disclaimer effectively render this draft useless? The > >draft also does not define how the node that initially signaled the LSP > >finds the 'node calculating or expanding the route' nor how it > >delivers the signaled LSP request to that node. > > > >As an aside, the draft: > >http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-te-include-route/? > >inc > >lude_text=3D1 would be subject to the same criticism except that the > >above quoted paragraph is replaced with: > > > >"The above-mentioned use cases require relevant path inclusion > >requirements to be communicated to the route expanding nodes. This > >document addresses these requirements and defines procedures to > >address them." > > > >Even though this is helpful, the draft doesn't actually define these > >procedures. > > > >Yours Irrespectively, > > > >John > > > > > >_______________________________________________ > >CCAMP mailing list > >CCAMP@ietf.org > >https://www.ietf.org/mailman/listinfo/ccamp > >_______________________________________________ > >CCAMP mailing list > >CCAMP@ietf.org > >https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 From jdrake@juniper.net Tue Oct 8 15:39:17 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E3C11E8101 for ; Tue, 8 Oct 2013 15:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.666, 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 XWlny-NsQFGd for ; Tue, 8 Oct 2013 15:39:11 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 61BE821F9B8A for ; Tue, 8 Oct 2013 15:39:04 -0700 (PDT) Received: from mail110-db9-R.bigfish.com (10.174.16.231) by DB9EHSOBE018.bigfish.com (10.174.14.81) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Oct 2013 22:39:00 +0000 Received: from mail110-db9 (localhost [127.0.0.1]) by mail110-db9-R.bigfish.com (Postfix) with ESMTP id 2D97A80143; Tue, 8 Oct 2013 22:39:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371Ic89bh542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275dhz2fh2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail110-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)(189002)(199002)(13464003)(377454003)(37854004)(56816003)(76796001)(47976001)(33646001)(51856001)(76576001)(76786001)(77096001)(47736001)(15202345003)(47446002)(74502001)(74366001)(85306002)(79102001)(74706001)(74316001)(53806001)(50986001)(31966008)(63696002)(76482001)(77982001)(49866001)(56776001)(19580405001)(80022001)(83322001)(54356001)(4396001)(81686001)(54316002)(81816001)(66066001)(15975445006)(83072001)(74876001)(46102001)(69226001)(80976001)(81542001)(74662001)(19580395003)(81342001)(59766001)(65816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail110-db9 (localhost.localdomain [127.0.0.1]) by mail110-db9 (MessageSwitch) id 1381271938351282_4235; Tue, 8 Oct 2013 22:38:58 +0000 (UTC) Received: from DB9EHSMHS031.bigfish.com (unknown [10.174.16.233]) by mail110-db9.bigfish.com (Postfix) with ESMTP id 502612E0074; Tue, 8 Oct 2013 22:38:58 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS031.bigfish.com (10.174.14.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Oct 2013 22:38:58 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 8 Oct 2013 22:38:50 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 8 Oct 2013 22:38:48 +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 22:38:47 +0000 From: John E Drake To: Daniele Ceccarelli , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: AQHOw/RvMrBCr56VuU2xebXAhUabxpnrAAYAgABkwRA= Date: Tue, 8 Oct 2013 22:38:47 +0000 Message-ID: <6ac0c1760bf242c1bca67bc20c637359@BY2PR05MB142.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0993689CD1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 22:39:17 -0000 Daniele and Fatai, I have been thinking some more about Zafar's Exclude/Include drafts and I h= ave the following observations. Let's assume that the ingress node has the RSVP-TE explicit route and ident= ifier for a given LSP from which it wishes to have a subsequent LSP be disj= ointly routed (exclude route) or be identically routed (include route). For either full or partial exclude route, where partial exclude route means= a disjoint route across one or more abstract nodes, the ingress node can c= ompute a route that is disjoint from the route of the given LSP. (However,= it is not guaranteed that a disjoint route can be found. The Suurballe al= gorithm computes disjoint routes *in pairs* and will find disjoint routes i= f they exist.) In order to allow the ingress node at the edge of an abstrac= t node to expand the explicit route and provide a disjoint route will requi= re that each such ingress node has complete knowledge of the RSVP-TE explic= it route and identifier of every LSP transiting that abstract node. For full include route the ingress node can simply re-use the explicit rout= e from the selected LSP. For partial include path, where partial include = path means an identical route across one or more abstract nodes, it can sim= ply re-use the [ingress node, abstract node] tuple for the subject abstract= node. Let's now assume that the ingress node has the RSVP-TE identifier for the g= iven LSP but not the explicit route. This is the UNI case, and if the ingr= ess node is single homed then the ingress PE can act on the ingress node's = behalf as described above. If however, the ingress node is multi-homed then this will require that eac= h of the ingress PEs know the complete set of ingress PEs serving the ingre= ss node and each has the RSVP-TE explicit route and identifier for the give= n LSP. This allows each ingress PE to act on the ingress node's behalf as = described above. =20 The net of all this that there needs to be a lot of distributed and coordin= ated state maintained in the server network and that neither Zafar nor any = of his co-authors has proposed a method for accomplishing this. Yours Irrespectively, John > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, October 08, 2013 9:32 AM > To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > (RSVP-TE) Path Diversity using Exclude Routes >=20 > Thanks John for pointing that out. When I first read the draft I missed t= hat > point. >=20 > I see two differences between the two drafts: > 1. utilization of 5ple vs Path key > 2. The path diversity draft does not say how to collect the 5ple (which i= n > some cases could not be available at all), the path key draft covers this= aspect > also >=20 > Re 1 I have a moderate preference for the path key for the security reaso= ns > that lead to the definition of the Path Key years ago and secondly it's s= impler. > Re 2 I don't know how the WG will manage the issue of two competing draft= s > (one wg, the other individual) but in any case it's an issue that need to= be > fixed somehow. >=20 > BR > Daniele >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Fatai Zhang > > Sent: marted=EC 8 ottobre 2013 09:02 > > To: John E Drake; CCAMP (ccamp@ietf.org) > > Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > > (RSVP-TE) Path Diversity using Exclude Routes > > > > Hi John, > > > > Totally agree with you, I already found these two drafts are much > *useless*. > > > > This is why we made a new draft (very simple and useful) and put our > > feet on the ground. > > > > http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion- > > pathkey-00.txt > > > > > > > > > > Best Regards > > > > Fatai > > > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of John E Drake > > Sent: Thursday, October 03, 2013 2:27 AM > > To: CCAMP (ccamp@ietf.org) > > Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > > (RSVP- > > TE) Path Diversity using Exclude Routes > > > > HI, > > > > I was reading: http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp- > > diversity/?include_text=3D1, and I happened to notice the following > paragraph: > > > > "The means by which the node calculating or expanding the route of the > > signaled LSP discovers the route of the path(s) from which the > > signaled LSP requires diversity are beyond the scope of this document. = " > > > > Doesn't this disclaimer effectively render this draft useless? The > > draft also does not define how the node that initially signaled the > > LSP finds the 'node calculating or expanding the route' nor how it > > delivers the signaled LSP request to that node. > > > > As an aside, the draft: > > http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp- > > te-include-route/?include_text=3D1 would be subject to the same > > criticism except that the above quoted paragraph is replaced with: > > > > "The above-mentioned use cases require relevant path inclusion > > requirements to be communicated to the route expanding nodes. This > > document addresses these requirements and defines procedures to > > address them." > > > > Even though this is helpful, the draft doesn't actually define these > > procedures. > > > > Yours Irrespectively, > > > > John > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp >=20 From jdrake@juniper.net Tue Oct 8 15:41:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3415521F9831 for ; Tue, 8 Oct 2013 15:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ3eR8RDZ198 for ; Tue, 8 Oct 2013 15:40:56 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2F75421F9967 for ; Tue, 8 Oct 2013 15:40:54 -0700 (PDT) Received: from mail152-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Oct 2013 22:40:53 +0000 Received: from mail152-co1 (localhost [127.0.0.1]) by mail152-co1-R.bigfish.com (Postfix) with ESMTP id A3D12180082; Tue, 8 Oct 2013 22:40:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail152-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(37854004)(199002)(13464003)(377454003)(189002)(51704005)(74662001)(69226001)(65816001)(74502001)(74316001)(47446002)(31966008)(46102001)(79102001)(76796001)(85306002)(76482001)(15202345003)(53806001)(50986001)(19580395003)(76786001)(74706001)(54356001)(76576001)(15975445006)(80022001)(81816001)(56816003)(47976001)(47736001)(59766001)(83072001)(74876001)(33646001)(56776001)(81686001)(54316002)(74366001)(77096001)(80976001)(81542001)(66066001)(77982001)(4396001)(51856001)(81342001)(19580405001)(63696002)(49866001)(83322001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail152-co1 (localhost.localdomain [127.0.0.1]) by mail152-co1 (MessageSwitch) id 1381272051961321_2790; Tue, 8 Oct 2013 22:40:51 +0000 (UTC) Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.228]) by mail152-co1.bigfish.com (Postfix) with ESMTP id E66E310004D; Tue, 8 Oct 2013 22:40:51 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Oct 2013 22:40:51 +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; Tue, 8 Oct 2013 22:40:29 +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; Tue, 8 Oct 2013 22:40:27 +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 22:40:27 +0000 From: John E Drake To: Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: AQHOw/RvMrBCr56VuU2xebXAhUabxpnrZsRg Date: Tue, 8 Oct 2013 22:40:26 +0000 Message-ID: <5e37de0c93a74f7393262538b623aa79@BY2PR05MB142.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 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% Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 22:41:03 -0000 And a very nice draft it is. Yours Irrespectively, John > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Tuesday, October 08, 2013 12:02 AM > To: John E Drake; CCAMP (ccamp@ietf.org) > Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > (RSVP-TE) Path Diversity using Exclude Routes >=20 > Hi John, >=20 > Totally agree with you, I already found these two drafts are much *useles= s*. >=20 > This is why we made a new draft (very simple and useful) and put our feet= on > the ground. >=20 > http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion- > pathkey-00.txt >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of John E Drake > Sent: Thursday, October 03, 2013 2:27 AM > To: CCAMP (ccamp@ietf.org) > Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP- > TE) Path Diversity using Exclude Routes >=20 > HI, >=20 > I was reading: http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp- > diversity/?include_text=3D1, and I happened to notice the following parag= raph: >=20 > "The means by which the node calculating or expanding the route of the > signaled LSP discovers the route of the path(s) from which the signaled L= SP > requires diversity are beyond the scope of this document. " >=20 > Doesn't this disclaimer effectively render this draft useless? The draft= also > does not define how the node that initially signaled the LSP finds the 'n= ode > calculating or expanding the route' nor how it delivers the signaled LSP > request to that node. >=20 > As an aside, the draft: http://datatracker.ietf.org/doc/draft-ali-ccamp-= rsvp- > te-include-route/?include_text=3D1 would be subject to the same criticism > except that the above quoted paragraph is replaced with: >=20 > "The above-mentioned use cases require relevant path inclusion > requirements to be communicated to the route expanding nodes. This > document addresses these requirements and defines procedures to > address them." >=20 > Even though this is helpful, the draft doesn't actually define these > procedures. >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From zhangfatai@huawei.com Tue Oct 8 18:18:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0847111E80E6 for ; Tue, 8 Oct 2013 18:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RbiVawjI9S4 for ; Tue, 8 Oct 2013 18:18:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2959B21F9FCA for ; Tue, 8 Oct 2013 18:18:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT01222; Wed, 09 Oct 2013 01:18:03 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 02:17:39 +0100 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 02:18:02 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.86]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 09:17:55 +0800 From: Fatai Zhang To: Daniele Ceccarelli , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABN/2rAAErujkA== Date: Wed, 9 Oct 2013 01:17:55 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 01:18:13 -0000 Hi Daniele, I don't think your point 2 is an issue.=20 If the WG realize that a WG document is *useless*, I think the WG document = should stop there and let it die (ie., I don't think a WG document have pre= ference to lead the WG to the wrong direction if this WG document is nothin= g but wrong).=20 Best Regards Fatai -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]=20 Sent: Wednesday, October 09, 2013 12:32 AM To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSV= P-TE) Path Diversity using Exclude Routes Thanks John for pointing that out. When I first read the draft I missed tha= t point. I see two differences between the two drafts: 1. utilization of 5ple vs Path key 2. The path diversity draft does not say how to collect the 5ple (which in = some cases could not be available at all), the path key draft covers this a= spect also Re 1 I have a moderate preference for the path key for the security reasons= that lead to the definition of the Path Key years ago and secondly it's si= mpler. Re 2 I don't know how the WG will manage the issue of two competing drafts = (one wg, the other individual) but in any case it's an issue that need to b= e fixed somehow. BR Daniele > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Fatai Zhang > Sent: marted=EC 8 ottobre 2013 09:02 > To: John E Drake; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > (RSVP-TE) Path Diversity using Exclude Routes >=20 > Hi John, >=20 > Totally agree with you, I already found these two drafts are much *useles= s*. >=20 > This is why we made a new draft (very simple and useful) and put our feet= on > the ground. >=20 > http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion- > pathkey-00.txt >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of John E Drake > Sent: Thursday, October 03, 2013 2:27 AM > To: CCAMP (ccamp@ietf.org) > Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP- > TE) Path Diversity using Exclude Routes >=20 > HI, >=20 > I was reading: http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp- > diversity/?include_text=3D1, and I happened to notice the following parag= raph: >=20 > "The means by which the node calculating or expanding the route of the > signaled LSP discovers the route of the path(s) from which the signaled L= SP > requires diversity are beyond the scope of this document. " >=20 > Doesn't this disclaimer effectively render this draft useless? The draft= also > does not define how the node that initially signaled the LSP finds the 'n= ode > calculating or expanding the route' nor how it delivers the signaled LSP > request to that node. >=20 > As an aside, the draft: http://datatracker.ietf.org/doc/draft-ali-ccamp-= rsvp- > te-include-route/?include_text=3D1 would be subject to the same criticism > except that the above quoted paragraph is replaced with: >=20 > "The above-mentioned use cases require relevant path inclusion > requirements to be communicated to the route expanding nodes. This > document addresses these requirements and defines procedures to > address them." >=20 > Even though this is helpful, the draft doesn't actually define these > procedures. >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From acee.lindem@ericsson.com Tue Oct 8 18:41:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [CCAMP] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 zali@cisco.com Tue Oct 8 22:26:24 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A96F11E813A for ; Tue, 8 Oct 2013 22:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfQ8vqXcJOYK for ; Tue, 8 Oct 2013 22:26:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 36A3521F9FDA for ; Tue, 8 Oct 2013 22:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4065; q=dns/txt; s=iport; t=1381296368; x=1382505968; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=wQ6nyQfnA1Zwi5tnrYj3T/MH2WC0Zo2TK5unAnEZvmk=; b=RDhZn/CQB0tkrBR/MlfWjJAOkXv/0CwplmMLFpl1fL3MYZ6qfkqX2JMI QpHkN0pPxFtBaKmEMeDS57h2LLLw0X7j7dSLaJLGRAScoi5cfW6y+BtR1 FR8nJbzXoe1G3XtFaZ8OJwFcnSxQZ31Gc8svH8UAk3WLONVT91X9zEx9u I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAIHoVFKtJV2b/2dsb2JhbABagwc4UsExgSQWdIIlAQEBBAEBAWsXBgEIEQMBAQELGQQuCxQJCAEBBAESCAESh2sMuTyPEzgGgxmBBAOZMZBRgWaBPoIq X-IronPort-AV: E=Sophos;i="4.90,1060,1371081600"; d="scan'208";a="269835378" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 09 Oct 2013 05:26:07 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r995Q77W024484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 05:26:07 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 00:26:07 -0500 From: "Zafar Ali (zali)" To: John E Drake , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYAAEh8IgAAGSCKA Date: Wed, 9 Oct 2013 05:26:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.233.245] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <4F8D21C16EC45A4E9BAC81413A0D3BA8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 05:26:24 -0000 Hi John:=20 No, RFC 5520/ RFC5533 are fine. The issue is that solution proposed by draft-zhang-ccamp-route-exclusion-pathkey-00.txt forces customers to deploy a stateful PCE where PCE need to remember path it has served for indefinite time.=20 Thanks Regards ... Zafar -----Original Message----- From: "jdrake@juniper.net" Date: Tuesday, October 8, 2013 6:26 PM To: zali , Fatai Zhang , "ccamp@ietf.org" Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes >Zafar, > >So, is your assertion that RFC5553 is broken? > >Yours Irrespectively, > >John > >> -----Original Message----- >> From: Zafar Ali (zali) [mailto:zali@cisco.com] >> Sent: Tuesday, October 08, 2013 10:47 AM >> To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) >> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering >> (RSVP-TE) Path Diversity using Exclude Routes >>=20 >> Fatai and all- >>=20 >> In a stateless PCE, Path Keys are transient and they expire. For this >>solution >> to work you need a PCE that can keep Paths associated with a Path Key >> around (a stateful PCE where states are path computed by the PCE). >>=20 >> Thanks >>=20 >> Regards =A9 Zafar >>=20 >>=20 >> -----Original Message----- >> From: Fatai Zhang >> Date: Tuesday, October 8, 2013 3:01 AM >> To: "jdrake@juniper.net" , "ccamp@ietf.org" >> >> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering >> (RSVP-TE) Path Diversity using Exclude Routes >>=20 >> >Hi John, >> > >> >Totally agree with you, I already found these two drafts are much >> >*useless*. >> > >> >This is why we made a new draft (very simple and useful) and put our >> >feet on the ground. >> > >> >http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion-p >> >ath >> >key-00.txt >> > >> > >> > >> > >> >Best Regards >> > >> >Fatai >> > >> > >> >-----Original Message----- >> >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> Behalf >> >Of John E Drake >> >Sent: Thursday, October 03, 2013 2:27 AM >> >To: CCAMP (ccamp@ietf.org) >> >Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering >> >(RSVP-TE) Path Diversity using Exclude Routes >> > >> >HI, >> > >> >I was reading: >> >http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?include >> >_te xt=3D1, and I happened to notice the following paragraph: >> > >> >"The means by which the node calculating or expanding the route of the >> >signaled LSP discovers the route of the path(s) from which the signaled >> >LSP requires diversity are beyond the scope of this document. " >> > >> >Doesn't this disclaimer effectively render this draft useless? The >> >draft also does not define how the node that initially signaled the LSP >> >finds the 'node calculating or expanding the route' nor how it >> >delivers the signaled LSP request to that node. >> > >> >As an aside, the draft: >> >http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-te-include-route/? >> >inc >> >lude_text=3D1 would be subject to the same criticism except that the >> >above quoted paragraph is replaced with: >> > >> >"The above-mentioned use cases require relevant path inclusion >> >requirements to be communicated to the route expanding nodes. This >> >document addresses these requirements and defines procedures to >> >address them." >> > >> >Even though this is helpful, the draft doesn't actually define these >> >procedures. >> > >> >Yours Irrespectively, >> > >> >John >> > >> > >> >_______________________________________________ >> >CCAMP mailing list >> >CCAMP@ietf.org >> >https://www.ietf.org/mailman/listinfo/ccamp >> >_______________________________________________ >> >CCAMP mailing list >> >CCAMP@ietf.org >> >https://www.ietf.org/mailman/listinfo/ccamp >>=20 >>=20 > > From zali@cisco.com Tue Oct 8 22:37:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3104C21E80E7 for ; Tue, 8 Oct 2013 22:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dUYKU1cxprQ for ; Tue, 8 Oct 2013 22:37:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E033021E80C1 for ; Tue, 8 Oct 2013 22:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4246; q=dns/txt; s=iport; t=1381297043; x=1382506643; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=0qlHhwg6qN+ACeqJtmwG2nRQShTQsZHnQwM7Rn5p/kg=; b=UjIzMc3SrhaYaaKS/OmkFTS8CgJi4jW5Qtfu7xeGaluDDuNDokIniYuW 2wIXdNCvsSodD2O4ANjepXz8j51v19UwKE8Yp5ZZNRh46HMt5B/G0bI9X tr+bK860Ce50UHhuHzrvK17fWBclFFfqSw7rcDNEUoL5B+PsjZUVgGFii Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFANzqVFKtJV2d/2dsb2JhbABagwc4UsExgSQWdIIlAQEBBAEBAWsXBgEIEQECAQEBCxkELgsUAwYIAQEEARIIARKHawy5MY8RAjgGgxmBBAOZMZBRgWaBPoIq X-IronPort-AV: E=Sophos;i="4.90,1060,1371081600"; d="scan'208";a="269830901" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 09 Oct 2013 05:37:22 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r995bMnH011939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 05:37:22 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 00:37:21 -0500 From: "Zafar Ali (zali)" To: Daniele Ceccarelli , Fatai Zhang , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABN/2rAAHhLcgA== Date: Wed, 9 Oct 2013 05:37:21 +0000 Message-ID: In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.233.245] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1CDBCC1BA6847E4683BA3A9CC3947E96@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 05:37:41 -0000 Daniele:=20 The main difference between the drafts is that one is RSVP-TE signaling based solution, while the other forces customers to deploy stateful PCE. Calling a RSVP-TE based signaling solution that is a WG document "useless" to force a "stateful" PCE based solution/ architecture to service providers is very inappropriate. Thanks Regards =8A Zafar -----Original Message----- From: Daniele Ceccarelli Date: Tuesday, October 8, 2013 12:32 PM To: Fatai Zhang , "jdrake@juniper.net" , "ccamp@ietf.org" Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes >Thanks John for pointing that out. When I first read the draft I missed >that point. > >I see two differences between the two drafts: >1. utilization of 5ple vs Path key >2. The path diversity draft does not say how to collect the 5ple (which >in some cases could not be available at all), the path key draft covers >this aspect also > >Re 1 I have a moderate preference for the path key for the security >reasons that lead to the definition of the Path Key years ago and >secondly it's simpler. >Re 2 I don't know how the WG will manage the issue of two competing >drafts (one wg, the other individual) but in any case it's an issue that >need to be fixed somehow. > >BR >Daniele > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Fatai Zhang >> Sent: marted=EC 8 ottobre 2013 09:02 >> To: John E Drake; CCAMP (ccamp@ietf.org) >> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering >> (RSVP-TE) Path Diversity using Exclude Routes >>=20 >> Hi John, >>=20 >> Totally agree with you, I already found these two drafts are much >>*useless*. >>=20 >> This is why we made a new draft (very simple and useful) and put our >>feet on >> the ground. >>=20 >> http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion- >> pathkey-00.txt >>=20 >>=20 >>=20 >>=20 >> Best Regards >>=20 >> Fatai >>=20 >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of John E Drake >> Sent: Thursday, October 03, 2013 2:27 AM >> To: CCAMP (ccamp@ietf.org) >> Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering >>(RSVP- >> TE) Path Diversity using Exclude Routes >>=20 >> HI, >>=20 >> I was reading: http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp- >> diversity/?include_text=3D1, and I happened to notice the following >>paragraph: >>=20 >> "The means by which the node calculating or expanding the route of the >> signaled LSP discovers the route of the path(s) from which the signaled >>LSP >> requires diversity are beyond the scope of this document. " >>=20 >> Doesn't this disclaimer effectively render this draft useless? The >>draft also >> does not define how the node that initially signaled the LSP finds the >>'node >> calculating or expanding the route' nor how it delivers the signaled >>LSP >> request to that node. >>=20 >> As an aside, the draft: >>http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp- >> te-include-route/?include_text=3D1 would be subject to the same criticis= m >> except that the above quoted paragraph is replaced with: >>=20 >> "The above-mentioned use cases require relevant path inclusion >> requirements to be communicated to the route expanding nodes. This >> document addresses these requirements and defines procedures to >> address them." >>=20 >> Even though this is helpful, the draft doesn't actually define these >> procedures. >>=20 >> Yours Irrespectively, >>=20 >> John >>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From zhang.xian@huawei.com Tue Oct 8 23:02:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9B111E812B for ; Tue, 8 Oct 2013 23:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=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 zQqcQbGT-NR0 for ; Tue, 8 Oct 2013 23:02:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D920611E8136 for ; Tue, 8 Oct 2013 23:02:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWP18775; Wed, 09 Oct 2013 06:02:19 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:01:44 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:02:15 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.167]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 14:02:05 +0800 From: "Zhangxian (Xian)" To: "Zafar Ali (zali)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYD//7cKgIAAdVAA//9yNXA= Date: Wed, 9 Oct 2013 06:02:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 06:02:36 -0000 SGksIFphZmFyLCANCiAgICANCiAgICBUaGFuayB5b3UgZm9yIHNoYXJpbmcgdGhlIHRob3VnaHRz LiBCdXQgSSBjYW5ub3QgYWdyZWUgd2l0aCB3aGF0IHlvdSBzYWlkIGJlbG93LiANCg0KICAgIFBh dGgga2V5IHNvbHV0aW9uIGRvZXMgbm90IG5lY2Vzc2FyaWx5IG5lZWQgdGhlIHByZXNlbmNlIG9m IGEgc3RhdGVmdWwgUENFLiBTaW1pbGFybHkgd2l0aCBSRkM1NTUzLCB0aGUgcGF0aCBrZXkgb3du ZXIgbmVlZHMgdG8gcmV0YWluIHRoaXMgaW5mb3JtYXRpb24gc28gdGhhdCBJIGNhbiBpbnRlcnBy ZXQgd2hlbiB1c2VkIGF0IGEgbGF0ZXIgdGltZS4gUmV0YWluaW5nIHN1Y2ggaW5mb3JtYXRpb24g ZG9lcyBub3QgZXF1YWwgdG8gYSBzdGF0ZWZ1bCBQQ0Ugd2hpY2ggbmVlZHMgdG8ga25vdyB0aGUg TFNQIHN0YXRlcyBvZiB0aGUgd2hvbGUgbmV0d29yayBpdCBzZXJ2ZXMuIA0KDQpSZWdhcmRzLA0K WGlhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBaYWZh ciBBbGkgKHphbGkpDQpTZW50OiAyMDEz5bm0MTDmnIg55pelIDEzOjI2DQpUbzogSm9obiBFIERy YWtlOyBGYXRhaSBaaGFuZzsgQ0NBTVAgKGNjYW1wQGlldGYub3JnKQ0KU3ViamVjdDogUmU6IFtD Q0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZyAo UlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCg0KSGkgSm9objog DQoNCk5vLCBSRkMgNTUyMC8gUkZDNTUzMyBhcmUgZmluZS4gVGhlIGlzc3VlIGlzIHRoYXQgc29s dXRpb24gcHJvcG9zZWQgYnkNCmRyYWZ0LXpoYW5nLWNjYW1wLXJvdXRlLWV4Y2x1c2lvbi1wYXRo a2V5LTAwLnR4dCBmb3JjZXMgY3VzdG9tZXJzIHRvDQpkZXBsb3kgYSBzdGF0ZWZ1bCBQQ0Ugd2hl cmUgUENFIG5lZWQgdG8gcmVtZW1iZXIgcGF0aCBpdCBoYXMgc2VydmVkIGZvcg0KaW5kZWZpbml0 ZSB0aW1lLiANCg0KVGhhbmtzDQoNClJlZ2FyZHMgLi4uIFphZmFyDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206ICJqZHJha2VAanVuaXBlci5uZXQiIDxqZHJha2VAanVuaXBl ci5uZXQ+DQpEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDgsIDIwMTMgNjoyNiBQTQ0KVG86IHphbGkg PHphbGlAY2lzY28uY29tPiwgRmF0YWkgWmhhbmcgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbT4sDQoi Y2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbQ0NBTVBdIFJl c291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcNCihSU1ZQLVRF KSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KDQo+WmFmYXIsDQo+DQo+U28s IGlzIHlvdXIgYXNzZXJ0aW9uIHRoYXQgUkZDNTU1MyBpcyBicm9rZW4/DQo+DQo+WW91cnMgSXJy ZXNwZWN0aXZlbHksDQo+DQo+Sm9obg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+IEZyb206IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxpQGNpc2NvLmNvbV0NCj4+IFNl bnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDgsIDIwMTMgMTA6NDcgQU0NCj4+IFRvOiBGYXRhaSBaaGFu ZzsgSm9obiBFIERyYWtlOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+PiBTdWJqZWN0OiBSZTog W0NDQU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5n DQo+PiAoUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4+IA0K Pj4gRmF0YWkgYW5kIGFsbC0NCj4+IA0KPj4gSW4gYSBzdGF0ZWxlc3MgUENFLCBQYXRoIEtleXMg YXJlIHRyYW5zaWVudCBhbmQgdGhleSBleHBpcmUuIEZvciB0aGlzDQo+PnNvbHV0aW9uDQo+PiB0 byB3b3JrIHlvdSBuZWVkIGEgUENFIHRoYXQgY2FuIGtlZXAgUGF0aHMgYXNzb2NpYXRlZCB3aXRo IGEgUGF0aCBLZXkNCj4+IGFyb3VuZCAoYSBzdGF0ZWZ1bCBQQ0Ugd2hlcmUgc3RhdGVzIGFyZSBw YXRoIGNvbXB1dGVkIGJ5IHRoZSBQQ0UpLg0KPj4gDQo+PiBUaGFua3MNCj4+IA0KPj4gUmVnYXJk cyDFoCBaYWZhcg0KPj4gDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBGYXRhaSBaaGFuZyA8emhhbmdmYXRhaUBodWF3ZWkuY29tPg0KPj4gRGF0ZTogVHVlc2Rh eSwgT2N0b2JlciA4LCAyMDEzIDM6MDEgQU0NCj4+IFRvOiAiamRyYWtlQGp1bmlwZXIubmV0IiA8 amRyYWtlQGp1bmlwZXIubmV0PiwgImNjYW1wQGlldGYub3JnIg0KPj4gPGNjYW1wQGlldGYub3Jn Pg0KPj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wt VHJhZmZpYyBFbmdpbmVlcmluZw0KPj4gKFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4 Y2x1ZGUgUm91dGVzDQo+PiANCj4+ID5IaSBKb2huLA0KPj4gPg0KPj4gPlRvdGFsbHkgYWdyZWUg d2l0aCB5b3UsIEkgYWxyZWFkeSBmb3VuZCB0aGVzZSB0d28gZHJhZnRzIGFyZSBtdWNoDQo+PiA+ KnVzZWxlc3MqLg0KPj4gPg0KPj4gPlRoaXMgaXMgd2h5IHdlIG1hZGUgYSBuZXcgZHJhZnQgKHZl cnkgc2ltcGxlIGFuZCB1c2VmdWwpIGFuZCBwdXQgb3VyDQo+PiA+ZmVldCBvbiB0aGUgZ3JvdW5k Lg0KPj4gPg0KPj4gPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpo YW5nLWNjYW1wLXJvdXRlLWV4Y2x1c2lvbi1wDQo+PiA+YXRoDQo+PiA+a2V5LTAwLnR4dA0KPj4g Pg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPkJlc3QgUmVnYXJkcw0KPj4gPg0KPj4gPkZhdGFpDQo+ PiA+DQo+PiA+DQo+PiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID5Gcm9tOiBjY2Ft cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+ IEJlaGFsZg0KPj4gPk9mIEpvaG4gRSBEcmFrZQ0KPj4gPlNlbnQ6IFRodXJzZGF5LCBPY3RvYmVy IDAzLCAyMDEzIDI6MjcgQU0NCj4+ID5UbzogQ0NBTVAgKGNjYW1wQGlldGYub3JnKQ0KPj4gPlN1 YmplY3Q6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdp bmVlcmluZw0KPj4gPihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRl cw0KPj4gPg0KPj4gPkhJLA0KPj4gPg0KPj4gPkkgd2FzIHJlYWRpbmc6DQo+PiA+aHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLWxzcC1kaXZlcnNpdHkvP2lu Y2x1ZGUNCj4+ID5fdGUgeHQ9MSwgYW5kIEkgaGFwcGVuZWQgdG8gbm90aWNlIHRoZSBmb2xsb3dp bmcgcGFyYWdyYXBoOg0KPj4gPg0KPj4gPiJUaGUgbWVhbnMgYnkgd2hpY2ggdGhlIG5vZGUgY2Fs Y3VsYXRpbmcgb3IgZXhwYW5kaW5nIHRoZSByb3V0ZSBvZiB0aGUNCj4+ID5zaWduYWxlZCBMU1Ag ZGlzY292ZXJzIHRoZSByb3V0ZSBvZiB0aGUgcGF0aChzKSBmcm9tIHdoaWNoIHRoZSBzaWduYWxl ZA0KPj4gPkxTUCAgcmVxdWlyZXMgZGl2ZXJzaXR5IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQuICINCj4+ID4NCj4+ID5Eb2Vzbid0IHRoaXMgZGlzY2xhaW1lciBlZmZlY3Rp dmVseSByZW5kZXIgdGhpcyBkcmFmdCB1c2VsZXNzPyAgVGhlDQo+PiA+ZHJhZnQgYWxzbyBkb2Vz IG5vdCBkZWZpbmUgaG93IHRoZSBub2RlIHRoYXQgaW5pdGlhbGx5IHNpZ25hbGVkIHRoZSBMU1AN Cj4+ID5maW5kcyB0aGUgJ25vZGUgY2FsY3VsYXRpbmcgb3IgZXhwYW5kaW5nIHRoZSByb3V0ZScg IG5vciBob3cgaXQNCj4+ID5kZWxpdmVycyB0aGUgc2lnbmFsZWQgTFNQIHJlcXVlc3QgdG8gdGhh dCBub2RlLg0KPj4gPg0KPj4gPkFzIGFuIGFzaWRlLCB0aGUgZHJhZnQ6DQo+PiA+aHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hbGktY2NhbXAtcnN2cC10ZS1pbmNsdWRlLXJv dXRlLz8NCj4+ID5pbmMNCj4+ID5sdWRlX3RleHQ9MSB3b3VsZCBiZSBzdWJqZWN0IHRvIHRoZSBz YW1lIGNyaXRpY2lzbSBleGNlcHQgdGhhdCB0aGUNCj4+ID5hYm92ZSBxdW90ZWQgcGFyYWdyYXBo IGlzIHJlcGxhY2VkIHdpdGg6DQo+PiA+DQo+PiA+IlRoZSBhYm92ZS1tZW50aW9uZWQgdXNlIGNh c2VzIHJlcXVpcmUgcmVsZXZhbnQgcGF0aCBpbmNsdXNpb24NCj4+ID5yZXF1aXJlbWVudHMgdG8g YmUgY29tbXVuaWNhdGVkIHRvIHRoZSByb3V0ZSBleHBhbmRpbmcgbm9kZXMuICBUaGlzDQo+PiA+ ZG9jdW1lbnQgYWRkcmVzc2VzICB0aGVzZSByZXF1aXJlbWVudHMgYW5kIGRlZmluZXMgcHJvY2Vk dXJlcyB0bw0KPj4gPmFkZHJlc3MgdGhlbS4iDQo+PiA+DQo+PiA+RXZlbiB0aG91Z2ggdGhpcyBp cyBoZWxwZnVsLCB0aGUgZHJhZnQgZG9lc24ndCBhY3R1YWxseSBkZWZpbmUgdGhlc2UNCj4+ID5w cm9jZWR1cmVzLg0KPj4gPg0KPj4gPllvdXJzIElycmVzcGVjdGl2ZWx5LA0KPj4gPg0KPj4gPkpv aG4NCj4+ID4NCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gPkNDQU1QIG1haWxpbmcgbGlzdA0KPj4gPkNDQU1QQGlldGYub3JnDQo+ PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4gPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+Q0NBTVAgbWFp bGluZyBsaXN0DQo+PiA+Q0NBTVBAaWV0Zi5vcmcNCj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+PiANCj4+IA0KPg0KPg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FN UEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0K From zali@cisco.com Tue Oct 8 23:06:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BF821F90A7 for ; Tue, 8 Oct 2013 23:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+TiAhxKsgDv for ; Tue, 8 Oct 2013 23:06:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 81C7E21E80DF for ; Tue, 8 Oct 2013 23:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7990; q=dns/txt; s=iport; t=1381298814; x=1382508414; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RN6I5l5UFfZMyyQi75N0Pm2EpbYsorjbGYXgGHW1GU4=; b=U6u0YZrSz2prQVG2UkYL0/hrgrVIx0v99MAJ0kNyK2EOtgyxFObtnKpG jE/y7gPFUTmYzP9ADOHIhpxw9XJiQiU582JeLTTAakaWZvrsFP3Isi7GW 2bfQ5TrpCuhXmicA+3pRJ/SV21RpgZHKZtEszo0eDeR8KWFeGk2A7cl+w o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAGjxVFKtJXG+/2dsb2JhbABagwc4UoMovggXgQ0WdIIlAQEBBAEBASAROgsMBgEGAhEDAQEBAwIGGQQDAgQlCxQBCAgCBAENBQgBEodrDIsIm1ySPoEpjWgCFhsHBoJkNYEEA5kxkFGBZoE+gio X-IronPort-AV: E=Sophos;i="4.90,1061,1371081600"; d="scan'208";a="269829710" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 09 Oct 2013 06:06:44 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9966icD015734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 06:06:44 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 01:06:44 -0500 From: "Zafar Ali (zali)" To: "Zhangxian (Xian)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYAAEh8IgAAGSCKAAAmjooD//745AA== Date: Wed, 9 Oct 2013 06:06:43 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.233.245] Content-Type: text/plain; charset="utf-8" Content-ID: <2480B8C3935CD244A96919946877BFD7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 06:06:59 -0000 SGkgWmhhbmd4aWFuOiANCg0KU3RhdGUgZG9lcyBub3QgYWx3YXlzIG1lYW5zIFJTVlAgVEUgc3Rh dGVzIGluIHRoZSBuZXR3b3JrLiBQQ0UgKHNldmVyKQ0KbmVlZHMgdG8gcmVtZW1iZXIgcGF0aCBp bmZvcm1hdGlvbiAocG9zc2libHkgd2l0aCBvdGhlciBwYXRoIGF0dHJpYnV0ZXMpDQppdCBjb21w dXRlZCBmb3IgaW5kZWZpbml0ZSB0aW1lLiBUaGVzZSBhcmUgc3RhdGVzIHRoYXQgUENFIG5lZWRz IHRvDQpyZW1lbWJlci4gSGVuY2UsIHN0YXRlZnVsIFBDRS4NCg0KVGhhbmtzDQoNClJlZ2FyZHMg 4oCmIFphZmFyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206ICJaaGFuZ3hp YW4gICAoWGlhbikiIDx6aGFuZy54aWFuQGh1YXdlaS5jb20+DQpEYXRlOiBXZWRuZXNkYXksIE9j dG9iZXIgOSwgMjAxMyAyOjAyIEFNDQpUbzogemFsaSA8emFsaUBjaXNjby5jb20+LCAiY2NhbXBA aWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4NCkNjOiAiamRyYWtlQGp1bmlwZXIubmV0IiA8amRy YWtlQGp1bmlwZXIubmV0PiwgRmF0YWkgWmhhbmcNCjx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+DQpT dWJqZWN0OiBSRTogW0NDQU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmlj IEVuZ2luZWVyaW5nDQooUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0 ZXMNCg0KPkhpLCBaYWZhciwgDQo+ICAgIA0KPiAgICBUaGFuayB5b3UgZm9yIHNoYXJpbmcgdGhl IHRob3VnaHRzLiBCdXQgSSBjYW5ub3QgYWdyZWUgd2l0aCB3aGF0IHlvdQ0KPnNhaWQgYmVsb3cu IA0KPg0KPiAgICBQYXRoIGtleSBzb2x1dGlvbiBkb2VzIG5vdCBuZWNlc3NhcmlseSBuZWVkIHRo ZSBwcmVzZW5jZSBvZiBhDQo+c3RhdGVmdWwgUENFLiBTaW1pbGFybHkgd2l0aCBSRkM1NTUzLCB0 aGUgcGF0aCBrZXkgb3duZXIgbmVlZHMgdG8gcmV0YWluDQo+dGhpcyBpbmZvcm1hdGlvbiBzbyB0 aGF0IEkgY2FuIGludGVycHJldCB3aGVuIHVzZWQgYXQgYSBsYXRlciB0aW1lLg0KPlJldGFpbmlu ZyBzdWNoIGluZm9ybWF0aW9uIGRvZXMgbm90IGVxdWFsIHRvIGEgc3RhdGVmdWwgUENFIHdoaWNo IG5lZWRzDQo+dG8ga25vdyB0aGUgTFNQIHN0YXRlcyBvZiB0aGUgd2hvbGUgbmV0d29yayBpdCBz ZXJ2ZXMuDQo+DQo+UmVnYXJkcywNCj5YaWFuDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj5Gcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+WmFmYXIgQWxpICh6YWxpKQ0KPlNlbnQ6IDIwMTPlubQx MOaciDnml6UgMTM6MjYNCj5UbzogSm9obiBFIERyYWtlOyBGYXRhaSBaaGFuZzsgQ0NBTVAgKGNj YW1wQGlldGYub3JnKQ0KPlN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9u IFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcNCj4oUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkg dXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4NCj5IaSBKb2huOiANCj4NCj5ObywgUkZDIDU1MjAvIFJG QzU1MzMgYXJlIGZpbmUuIFRoZSBpc3N1ZSBpcyB0aGF0IHNvbHV0aW9uIHByb3Bvc2VkIGJ5DQo+ ZHJhZnQtemhhbmctY2NhbXAtcm91dGUtZXhjbHVzaW9uLXBhdGhrZXktMDAudHh0IGZvcmNlcyBj dXN0b21lcnMgdG8NCj5kZXBsb3kgYSBzdGF0ZWZ1bCBQQ0Ugd2hlcmUgUENFIG5lZWQgdG8gcmVt ZW1iZXIgcGF0aCBpdCBoYXMgc2VydmVkIGZvcg0KPmluZGVmaW5pdGUgdGltZS4gDQo+DQo+VGhh bmtzDQo+DQo+UmVnYXJkcyAuLi4gWmFmYXINCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPkZyb206ICJqZHJha2VAanVuaXBlci5uZXQiIDxqZHJha2VAanVuaXBlci5uZXQ+DQo+ RGF0ZTogVHVlc2RheSwgT2N0b2JlciA4LCAyMDEzIDY6MjYgUE0NCj5UbzogemFsaSA8emFsaUBj aXNjby5jb20+LCBGYXRhaSBaaGFuZyA8emhhbmdmYXRhaUBodWF3ZWkuY29tPiwNCj4iY2NhbXBA aWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4NCj5TdWJqZWN0OiBSRTogW0NDQU1QXSBSZXNvdXJj ZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+KFJTVlAtVEUpIFBh dGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVzDQo+DQo+PlphZmFyLA0KPj4NCj4+U28s IGlzIHlvdXIgYXNzZXJ0aW9uIHRoYXQgUkZDNTU1MyBpcyBicm9rZW4/DQo+Pg0KPj5Zb3VycyBJ cnJlc3BlY3RpdmVseSwNCj4+DQo+PkpvaG4NCj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+PiBGcm9tOiBaYWZhciBBbGkgKHphbGkpIFttYWlsdG86emFsaUBjaXNjby5jb21d DQo+Pj4gU2VudDogVHVlc2RheSwgT2N0b2JlciAwOCwgMjAxMyAxMDo0NyBBTQ0KPj4+IFRvOiBG YXRhaSBaaGFuZzsgSm9obiBFIERyYWtlOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+Pj4gU3Vi amVjdDogUmU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBF bmdpbmVlcmluZw0KPj4+IChSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJv dXRlcw0KPj4+IA0KPj4+IEZhdGFpIGFuZCBhbGwtDQo+Pj4gDQo+Pj4gSW4gYSBzdGF0ZWxlc3Mg UENFLCBQYXRoIEtleXMgYXJlIHRyYW5zaWVudCBhbmQgdGhleSBleHBpcmUuIEZvciB0aGlzDQo+ Pj5zb2x1dGlvbg0KPj4+IHRvIHdvcmsgeW91IG5lZWQgYSBQQ0UgdGhhdCBjYW4ga2VlcCBQYXRo cyBhc3NvY2lhdGVkIHdpdGggYSBQYXRoIEtleQ0KPj4+IGFyb3VuZCAoYSBzdGF0ZWZ1bCBQQ0Ug d2hlcmUgc3RhdGVzIGFyZSBwYXRoIGNvbXB1dGVkIGJ5IHRoZSBQQ0UpLg0KPj4+IA0KPj4+IFRo YW5rcw0KPj4+IA0KPj4+IFJlZ2FyZHMgxaAgWmFmYXINCj4+PiANCj4+PiANCj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IEZhdGFpIFpoYW5nIDx6aGFuZ2ZhdGFpQGh1 YXdlaS5jb20+DQo+Pj4gRGF0ZTogVHVlc2RheSwgT2N0b2JlciA4LCAyMDEzIDM6MDEgQU0NCj4+ PiBUbzogImpkcmFrZUBqdW5pcGVyLm5ldCIgPGpkcmFrZUBqdW5pcGVyLm5ldD4sICJjY2FtcEBp ZXRmLm9yZyINCj4+PiA8Y2NhbXBAaWV0Zi5vcmc+DQo+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0g UmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZw0KPj4+IChS U1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPj4+IA0KPj4+ID5I aSBKb2huLA0KPj4+ID4NCj4+PiA+VG90YWxseSBhZ3JlZSB3aXRoIHlvdSwgSSBhbHJlYWR5IGZv dW5kIHRoZXNlIHR3byBkcmFmdHMgYXJlIG11Y2gNCj4+PiA+KnVzZWxlc3MqLg0KPj4+ID4NCj4+ PiA+VGhpcyBpcyB3aHkgd2UgbWFkZSBhIG5ldyBkcmFmdCAodmVyeSBzaW1wbGUgYW5kIHVzZWZ1 bCkgYW5kIHB1dCBvdXINCj4+PiA+ZmVldCBvbiB0aGUgZ3JvdW5kLg0KPj4+ID4NCj4+PiANCj4+ Pj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGFuZy1jY2FtcC1y b3V0ZS1leGNsdXNpb24tcA0KPj4+ID5hdGgNCj4+PiA+a2V5LTAwLnR4dA0KPj4+ID4NCj4+PiA+ DQo+Pj4gPg0KPj4+ID4NCj4+PiA+QmVzdCBSZWdhcmRzDQo+Pj4gPg0KPj4+ID5GYXRhaQ0KPj4+ ID4NCj4+PiA+DQo+Pj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gPkZyb206IGNj YW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0K Pj4+IEJlaGFsZg0KPj4+ID5PZiBKb2huIEUgRHJha2UNCj4+PiA+U2VudDogVGh1cnNkYXksIE9j dG9iZXIgMDMsIDIwMTMgMjoyNyBBTQ0KPj4+ID5UbzogQ0NBTVAgKGNjYW1wQGlldGYub3JnKQ0K Pj4+ID5TdWJqZWN0OiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZm aWMgRW5naW5lZXJpbmcNCj4+PiA+KFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1 ZGUgUm91dGVzDQo+Pj4gPg0KPj4+ID5ISSwNCj4+PiA+DQo+Pj4gPkkgd2FzIHJlYWRpbmc6DQo+ Pj4gDQo+Pj4+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1w LWxzcC1kaXZlcnNpdHkvP2luY2x1ZGUNCj4+PiA+X3RlIHh0PTEsIGFuZCBJIGhhcHBlbmVkIHRv IG5vdGljZSB0aGUgZm9sbG93aW5nIHBhcmFncmFwaDoNCj4+PiA+DQo+Pj4gPiJUaGUgbWVhbnMg Ynkgd2hpY2ggdGhlIG5vZGUgY2FsY3VsYXRpbmcgb3IgZXhwYW5kaW5nIHRoZSByb3V0ZSBvZiB0 aGUNCj4+PiA+c2lnbmFsZWQgTFNQIGRpc2NvdmVycyB0aGUgcm91dGUgb2YgdGhlIHBhdGgocykg ZnJvbSB3aGljaCB0aGUNCj4+PnNpZ25hbGVkDQo+Pj4gPkxTUCAgcmVxdWlyZXMgZGl2ZXJzaXR5 IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICINCj4+PiA+DQo+Pj4gPkRv ZXNuJ3QgdGhpcyBkaXNjbGFpbWVyIGVmZmVjdGl2ZWx5IHJlbmRlciB0aGlzIGRyYWZ0IHVzZWxl c3M/ICBUaGUNCj4+PiA+ZHJhZnQgYWxzbyBkb2VzIG5vdCBkZWZpbmUgaG93IHRoZSBub2RlIHRo YXQgaW5pdGlhbGx5IHNpZ25hbGVkIHRoZQ0KPj4+TFNQDQo+Pj4gPmZpbmRzIHRoZSAnbm9kZSBj YWxjdWxhdGluZyBvciBleHBhbmRpbmcgdGhlIHJvdXRlJyAgbm9yIGhvdyBpdA0KPj4+ID5kZWxp dmVycyB0aGUgc2lnbmFsZWQgTFNQIHJlcXVlc3QgdG8gdGhhdCBub2RlLg0KPj4+ID4NCj4+PiA+ QXMgYW4gYXNpZGUsIHRoZSBkcmFmdDoNCj4+PiANCj4+Pj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWFsaS1jY2FtcC1yc3ZwLXRlLWluY2x1ZGUtcm91dGUvPw0KPj4+ID5p bmMNCj4+PiA+bHVkZV90ZXh0PTEgd291bGQgYmUgc3ViamVjdCB0byB0aGUgc2FtZSBjcml0aWNp c20gZXhjZXB0IHRoYXQgdGhlDQo+Pj4gPmFib3ZlIHF1b3RlZCBwYXJhZ3JhcGggaXMgcmVwbGFj ZWQgd2l0aDoNCj4+PiA+DQo+Pj4gPiJUaGUgYWJvdmUtbWVudGlvbmVkIHVzZSBjYXNlcyByZXF1 aXJlIHJlbGV2YW50IHBhdGggaW5jbHVzaW9uDQo+Pj4gPnJlcXVpcmVtZW50cyB0byBiZSBjb21t dW5pY2F0ZWQgdG8gdGhlIHJvdXRlIGV4cGFuZGluZyBub2Rlcy4gIFRoaXMNCj4+PiA+ZG9jdW1l bnQgYWRkcmVzc2VzICB0aGVzZSByZXF1aXJlbWVudHMgYW5kIGRlZmluZXMgcHJvY2VkdXJlcyB0 bw0KPj4+ID5hZGRyZXNzIHRoZW0uIg0KPj4+ID4NCj4+PiA+RXZlbiB0aG91Z2ggdGhpcyBpcyBo ZWxwZnVsLCB0aGUgZHJhZnQgZG9lc24ndCBhY3R1YWxseSBkZWZpbmUgdGhlc2UNCj4+PiA+cHJv Y2VkdXJlcy4NCj4+PiA+DQo+Pj4gPllvdXJzIElycmVzcGVjdGl2ZWx5LA0KPj4+ID4NCj4+PiA+ Sm9obg0KPj4+ID4NCj4+PiA+DQo+Pj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4gPkNDQU1QIG1haWxpbmcgbGlzdA0KPj4+ID5DQ0FNUEBpZXRm Lm9yZw0KPj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ Pj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4g PkNDQU1QIG1haWxpbmcgbGlzdA0KPj4+ID5DQ0FNUEBpZXRmLm9yZw0KPj4+ID5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4gDQo+Pj4gDQo+Pg0KPj4NCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkNDQU1Q IG1haWxpbmcgbGlzdA0KPkNDQU1QQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jY2FtcA0KDQo= From zhang.xian@huawei.com Tue Oct 8 23:09:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABF221E80E6 for ; Tue, 8 Oct 2013 23:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 b02qOw3fOsI6 for ; Tue, 8 Oct 2013 23:09:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9F21E80E7 for ; Tue, 8 Oct 2013 23:09:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT19979; Wed, 09 Oct 2013 06:09:19 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:08:55 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:09:19 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.167]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 14:09:07 +0800 From: "Zhangxian (Xian)" To: "Zafar Ali (zali)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABN/2rAAHhLcgAABOZAg Date: Wed, 9 Oct 2013 06:09:06 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 06:09:28 -0000 SGksIFphZmFyLA0KDQogICBXaGF0IEkgdW5kZXJzdGFuZCBpcyBxdWl0ZSB0aGUgb3Bwb3NpdGUu IEluIHRoZSAiUlNWUC1URSBzaWduYWxpbmcgYmFzZWQgc29sdXRpb24iIHlvdSBtZW50aW9uZWQg YmVsb3csIHdoaWNoIGVudGl0eSB3aWxsIGJlIGFibGUgdG8gdW5kZXJzdGFuZCB0aGUgTFNQIGlk ZW50aWZpZXJzIGFuZCB0cmFuc2xhdGUgaXQgdG8gYSBub2RlL2xpbmsgbGlzdD8gSU1ITywgb25s eSBhIHN0YXRlZnVsIFBDRSBjYW4gZG8gc28uIElzbid0IHRoYXQgdGhlIGNhc2U/DQoNClJlZ2Fy ZHMsDQpYaWFuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBaYWZhciBBbGkgKHphbGkpDQpTZW50OiAyMDEz5bm0MTDmnIg55pelIDEzOjM3DQpUbzogRGFu aWVsZSBDZWNjYXJlbGxpOyBGYXRhaSBaaGFuZzsgSm9obiBFIERyYWtlOyBDQ0FNUCAoY2NhbXBA aWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90 b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nIChSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBF eGNsdWRlIFJvdXRlcw0KDQpEYW5pZWxlOiANCg0KVGhlIG1haW4gZGlmZmVyZW5jZSBiZXR3ZWVu IHRoZSBkcmFmdHMgaXMgdGhhdCBvbmUgaXMgUlNWUC1URSBzaWduYWxpbmcNCmJhc2VkIHNvbHV0 aW9uLCB3aGlsZSB0aGUgb3RoZXIgZm9yY2VzIGN1c3RvbWVycyB0byBkZXBsb3kgc3RhdGVmdWwg UENFLg0KQ2FsbGluZyBhIFJTVlAtVEUgYmFzZWQgc2lnbmFsaW5nIHNvbHV0aW9uIHRoYXQgaXMg YSBXRyBkb2N1bWVudCAidXNlbGVzcyINCnRvIGZvcmNlIGEgInN0YXRlZnVsIiBQQ0UgYmFzZWQg c29sdXRpb24vIGFyY2hpdGVjdHVyZSB0byBzZXJ2aWNlDQpwcm92aWRlcnMgaXMgdmVyeSBpbmFw cHJvcHJpYXRlLg0KDQpUaGFua3MNCg0KUmVnYXJkcyDFoCBaYWZhcg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2Fy ZWxsaUBlcmljc3Nvbi5jb20+DQpEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDgsIDIwMTMgMTI6MzIg UE0NClRvOiBGYXRhaSBaaGFuZyA8emhhbmdmYXRhaUBodWF3ZWkuY29tPiwgImpkcmFrZUBqdW5p cGVyLm5ldCINCjxqZHJha2VAanVuaXBlci5uZXQ+LCAiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3Rv Y29sLVRyYWZmaWMgRW5naW5lZXJpbmcNCihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBF eGNsdWRlIFJvdXRlcw0KDQo+VGhhbmtzIEpvaG4gZm9yIHBvaW50aW5nIHRoYXQgb3V0LiBXaGVu IEkgZmlyc3QgcmVhZCB0aGUgZHJhZnQgSSBtaXNzZWQNCj50aGF0IHBvaW50Lg0KPg0KPkkgc2Vl IHR3byBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSB0d28gZHJhZnRzOg0KPjEuIHV0aWxpemF0aW9u IG9mIDVwbGUgdnMgUGF0aCBrZXkNCj4yLiBUaGUgcGF0aCBkaXZlcnNpdHkgZHJhZnQgZG9lcyBu b3Qgc2F5IGhvdyB0byBjb2xsZWN0IHRoZSA1cGxlICh3aGljaA0KPmluIHNvbWUgY2FzZXMgY291 bGQgbm90IGJlIGF2YWlsYWJsZSBhdCBhbGwpLCB0aGUgcGF0aCBrZXkgZHJhZnQgY292ZXJzDQo+ dGhpcyBhc3BlY3QgYWxzbw0KPg0KPlJlIDEgSSBoYXZlIGEgbW9kZXJhdGUgcHJlZmVyZW5jZSBm b3IgdGhlIHBhdGgga2V5IGZvciB0aGUgc2VjdXJpdHkNCj5yZWFzb25zIHRoYXQgbGVhZCB0byB0 aGUgZGVmaW5pdGlvbiBvZiB0aGUgUGF0aCBLZXkgeWVhcnMgYWdvIGFuZA0KPnNlY29uZGx5IGl0 J3Mgc2ltcGxlci4NCj5SZSAyIEkgZG9uJ3Qga25vdyBob3cgdGhlIFdHIHdpbGwgbWFuYWdlIHRo ZSBpc3N1ZSBvZiB0d28gY29tcGV0aW5nDQo+ZHJhZnRzIChvbmUgd2csIHRoZSBvdGhlciBpbmRp dmlkdWFsKSBidXQgaW4gYW55IGNhc2UgaXQncyBhbiBpc3N1ZSB0aGF0DQo+bmVlZCB0byBiZSBm aXhlZCBzb21laG93Lg0KPg0KPkJSDQo+RGFuaWVsZQ0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+IE9mIEZhdGFpIFpoYW5nDQo+PiBTZW50OiBt YXJ0ZWTDrCA4IG90dG9icmUgMjAxMyAwOTowMg0KPj4gVG86IEpvaG4gRSBEcmFrZTsgQ0NBTVAg KGNjYW1wQGlldGYub3JnKQ0KPj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJW YXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZw0KPj4gKFJTVlAtVEUpIFBhdGggRGl2 ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVzDQo+PiANCj4+IEhpIEpvaG4sDQo+PiANCj4+IFRv dGFsbHkgYWdyZWUgd2l0aCB5b3UsIEkgYWxyZWFkeSBmb3VuZCB0aGVzZSB0d28gZHJhZnRzIGFy ZSBtdWNoDQo+Pip1c2VsZXNzKi4NCj4+IA0KPj4gVGhpcyBpcyB3aHkgd2UgbWFkZSBhIG5ldyBk cmFmdCAodmVyeSBzaW1wbGUgYW5kIHVzZWZ1bCkgYW5kIHB1dCBvdXINCj4+ZmVldCBvbg0KPj4g dGhlIGdyb3VuZC4NCj4+IA0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtemhhbmctY2NhbXAtcm91dGUtZXhjbHVzaW9uLQ0KPj4gcGF0aGtleS0wMC50eHQNCj4+ IA0KPj4gDQo+PiANCj4+IA0KPj4gQmVzdCBSZWdhcmRzDQo+PiANCj4+IEZhdGFpDQo+PiANCj4+ IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGNjYW1wLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+IE9m IEpvaG4gRSBEcmFrZQ0KPj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDMsIDIwMTMgMjoyNyBB TQ0KPj4gVG86IENDQU1QIChjY2FtcEBpZXRmLm9yZykNCj4+IFN1YmplY3Q6IFtDQ0FNUF0gUmVz b3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZw0KPj4oUlNWUC0N Cj4+IFRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPj4gDQo+PiBISSwN Cj4+IA0KPj4gSSB3YXMgcmVhZGluZzogICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtY2NhbXAtbHNwLQ0KPj4gZGl2ZXJzaXR5Lz9pbmNsdWRlX3RleHQ9MSwgYW5k IEkgaGFwcGVuZWQgdG8gbm90aWNlIHRoZSBmb2xsb3dpbmcNCj4+cGFyYWdyYXBoOg0KPj4gDQo+ PiAiVGhlIG1lYW5zIGJ5IHdoaWNoIHRoZSBub2RlIGNhbGN1bGF0aW5nIG9yIGV4cGFuZGluZyB0 aGUgcm91dGUgb2YgdGhlDQo+PiBzaWduYWxlZCBMU1AgZGlzY292ZXJzIHRoZSByb3V0ZSBvZiB0 aGUgcGF0aChzKSBmcm9tIHdoaWNoIHRoZSBzaWduYWxlZA0KPj5MU1ANCj4+IHJlcXVpcmVzIGRp dmVyc2l0eSBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAiDQo+PiANCj4+ IERvZXNuJ3QgdGhpcyBkaXNjbGFpbWVyIGVmZmVjdGl2ZWx5IHJlbmRlciB0aGlzIGRyYWZ0IHVz ZWxlc3M/ICBUaGUNCj4+ZHJhZnQgYWxzbw0KPj4gZG9lcyBub3QgZGVmaW5lIGhvdyB0aGUgbm9k ZSB0aGF0IGluaXRpYWxseSBzaWduYWxlZCB0aGUgTFNQIGZpbmRzIHRoZQ0KPj4nbm9kZQ0KPj4g Y2FsY3VsYXRpbmcgb3IgZXhwYW5kaW5nIHRoZSByb3V0ZScgIG5vciBob3cgaXQgZGVsaXZlcnMg dGhlIHNpZ25hbGVkDQo+PkxTUA0KPj4gcmVxdWVzdCB0byB0aGF0IG5vZGUuDQo+PiANCj4+IEFz IGFuIGFzaWRlLCB0aGUgZHJhZnQ6DQo+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYWxpLWNjYW1wLXJzdnAtDQo+PiB0ZS1pbmNsdWRlLXJvdXRlLz9pbmNsdWRlX3RleHQ9 MSB3b3VsZCBiZSBzdWJqZWN0IHRvIHRoZSBzYW1lIGNyaXRpY2lzbQ0KPj4gZXhjZXB0IHRoYXQg dGhlIGFib3ZlIHF1b3RlZCBwYXJhZ3JhcGggaXMgcmVwbGFjZWQgd2l0aDoNCj4+IA0KPj4gIlRo ZSBhYm92ZS1tZW50aW9uZWQgdXNlIGNhc2VzIHJlcXVpcmUgcmVsZXZhbnQgcGF0aCBpbmNsdXNp b24NCj4+IHJlcXVpcmVtZW50cyB0byBiZSBjb21tdW5pY2F0ZWQgdG8gdGhlIHJvdXRlIGV4cGFu ZGluZyBub2Rlcy4gIFRoaXMNCj4+IGRvY3VtZW50IGFkZHJlc3NlcyAgdGhlc2UgcmVxdWlyZW1l bnRzIGFuZCBkZWZpbmVzIHByb2NlZHVyZXMgdG8NCj4+IGFkZHJlc3MgdGhlbS4iDQo+PiANCj4+ IEV2ZW4gdGhvdWdoIHRoaXMgaXMgaGVscGZ1bCwgdGhlIGRyYWZ0IGRvZXNuJ3QgYWN0dWFsbHkg ZGVmaW5lIHRoZXNlDQo+PiBwcm9jZWR1cmVzLg0KPj4gDQo+PiBZb3VycyBJcnJlc3BlY3RpdmVs eSwNCj4+IA0KPj4gSm9obg0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+IENDQU1QQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gQ0NB TVAgbWFpbGluZyBsaXN0DQo+PiBDQ0FNUEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Q0NBTVAgbWFpbGluZyBsaXN0DQo+Q0NBTVBAaWV0Zi5vcmcN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxp c3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NjYW1wDQo= From zhangfatai@huawei.com Tue Oct 8 23:12:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495DE21E80E3 for ; Tue, 8 Oct 2013 23:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=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 HQVucKTyUPLb for ; Tue, 8 Oct 2013 23:12:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7188421E80FE for ; Tue, 8 Oct 2013 23:12:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT20197; Wed, 09 Oct 2013 06:12:20 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:11:56 +0100 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 07:12:18 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.86]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 14:12:05 +0800 From: Fatai Zhang To: "Zafar Ali (zali)" , "Zhangxian (Xian)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYD//7cKgIAAdVAA//9yNXCAAJkkgP//eVVw Date: Wed, 9 Oct 2013 06:12:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 06:12:40 -0000 SGkgWmFmYXIsDQoNClJlYWxseSBpbnRlcmVzdGluZyBmb3IgeW91ciBhc3NlcnRpb24uIA0KDQpE aWQgeW91IG1lYW4gdGhhdCBSRkMgNTUyMCBpcyBzcGVjaWZpYyBmb3Igc3RhdGVmdWwgUENFPyAN Cg0KSW4gYWRkaXRvbiwgcGxlYXNlIGxvb2sgYXQgIkNvbnRyb2wgb2YgRnVuY3Rpb24gdGhyb3Vn aCBDb25maWd1cmF0aW9uIGFuZCBQb2xpY3kiIG9mIFJGQyA1NTIwIGFuZCBSRkM1NTUzLiANCg0K DQpCZXN0IFJlZ2FyZHMNCg0KRmF0YWkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogWmFmYXIgQWxpICh6YWxpKSBbbWFpbHRvOnphbGlAY2lzY28uY29tXSANClNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAwOSwgMjAxMyAyOjA3IFBNDQpUbzogWmhhbmd4aWFuIChYaWFuKTsg Q0NBTVAgKGNjYW1wQGlldGYub3JnKQ0KQ2M6IEpvaG4gRSBEcmFrZTsgRmF0YWkgWmhhbmcNClN1 YmplY3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMg RW5naW5lZXJpbmcgKFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVz DQoNCkhpIFpoYW5neGlhbjogDQoNClN0YXRlIGRvZXMgbm90IGFsd2F5cyBtZWFucyBSU1ZQIFRF IHN0YXRlcyBpbiB0aGUgbmV0d29yay4gUENFIChzZXZlcikNCm5lZWRzIHRvIHJlbWVtYmVyIHBh dGggaW5mb3JtYXRpb24gKHBvc3NpYmx5IHdpdGggb3RoZXIgcGF0aCBhdHRyaWJ1dGVzKQ0KaXQg Y29tcHV0ZWQgZm9yIGluZGVmaW5pdGUgdGltZS4gVGhlc2UgYXJlIHN0YXRlcyB0aGF0IFBDRSBu ZWVkcyB0bw0KcmVtZW1iZXIuIEhlbmNlLCBzdGF0ZWZ1bCBQQ0UuDQoNClRoYW5rcw0KDQpSZWdh cmRzIOKApiBaYWZhcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiWmhh bmd4aWFuICAgKFhpYW4pIiA8emhhbmcueGlhbkBodWF3ZWkuY29tPg0KRGF0ZTogV2VkbmVzZGF5 LCBPY3RvYmVyIDksIDIwMTMgMjowMiBBTQ0KVG86IHphbGkgPHphbGlAY2lzY28uY29tPiwgImNj YW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+DQpDYzogImpkcmFrZUBqdW5pcGVyLm5ldCIg PGpkcmFrZUBqdW5pcGVyLm5ldD4sIEZhdGFpIFpoYW5nDQo8emhhbmdmYXRhaUBodWF3ZWkuY29t Pg0KU3ViamVjdDogUkU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJh ZmZpYyBFbmdpbmVlcmluZw0KKFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUg Um91dGVzDQoNCj5IaSwgWmFmYXIsIA0KPiAgICANCj4gICAgVGhhbmsgeW91IGZvciBzaGFyaW5n IHRoZSB0aG91Z2h0cy4gQnV0IEkgY2Fubm90IGFncmVlIHdpdGggd2hhdCB5b3UNCj5zYWlkIGJl bG93LiANCj4NCj4gICAgUGF0aCBrZXkgc29sdXRpb24gZG9lcyBub3QgbmVjZXNzYXJpbHkgbmVl ZCB0aGUgcHJlc2VuY2Ugb2YgYQ0KPnN0YXRlZnVsIFBDRS4gU2ltaWxhcmx5IHdpdGggUkZDNTU1 MywgdGhlIHBhdGgga2V5IG93bmVyIG5lZWRzIHRvIHJldGFpbg0KPnRoaXMgaW5mb3JtYXRpb24g c28gdGhhdCBJIGNhbiBpbnRlcnByZXQgd2hlbiB1c2VkIGF0IGEgbGF0ZXIgdGltZS4NCj5SZXRh aW5pbmcgc3VjaCBpbmZvcm1hdGlvbiBkb2VzIG5vdCBlcXVhbCB0byBhIHN0YXRlZnVsIFBDRSB3 aGljaCBuZWVkcw0KPnRvIGtub3cgdGhlIExTUCBzdGF0ZXMgb2YgdGhlIHdob2xlIG5ldHdvcmsg aXQgc2VydmVzLg0KPg0KPlJlZ2FyZHMsDQo+WGlhbg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+RnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPlphZmFyIEFsaSAoemFsaSkNCj5TZW50OiAyMDEz 5bm0MTDmnIg55pelIDEzOjI2DQo+VG86IEpvaG4gRSBEcmFrZTsgRmF0YWkgWmhhbmc7IENDQU1Q IChjY2FtcEBpZXRmLm9yZykNCj5TdWJqZWN0OiBSZTogW0NDQU1QXSBSZXNvdXJjZSBSZXNlclZh dGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+KFJTVlAtVEUpIFBhdGggRGl2ZXJz aXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVzDQo+DQo+SGkgSm9objogDQo+DQo+Tm8sIFJGQyA1NTIw LyBSRkM1NTMzIGFyZSBmaW5lLiBUaGUgaXNzdWUgaXMgdGhhdCBzb2x1dGlvbiBwcm9wb3NlZCBi eQ0KPmRyYWZ0LXpoYW5nLWNjYW1wLXJvdXRlLWV4Y2x1c2lvbi1wYXRoa2V5LTAwLnR4dCBmb3Jj ZXMgY3VzdG9tZXJzIHRvDQo+ZGVwbG95IGEgc3RhdGVmdWwgUENFIHdoZXJlIFBDRSBuZWVkIHRv IHJlbWVtYmVyIHBhdGggaXQgaGFzIHNlcnZlZCBmb3INCj5pbmRlZmluaXRlIHRpbWUuIA0KPg0K PlRoYW5rcw0KPg0KPlJlZ2FyZHMgLi4uIFphZmFyDQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj5Gcm9tOiAiamRyYWtlQGp1bmlwZXIubmV0IiA8amRyYWtlQGp1bmlwZXIubmV0 Pg0KPkRhdGU6IFR1ZXNkYXksIE9jdG9iZXIgOCwgMjAxMyA2OjI2IFBNDQo+VG86IHphbGkgPHph bGlAY2lzY28uY29tPiwgRmF0YWkgWmhhbmcgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbT4sDQo+ImNj YW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+DQo+U3ViamVjdDogUkU6IFtDQ0FNUF0gUmVz b3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZw0KPihSU1ZQLVRF KSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPg0KPj5aYWZhciwNCj4+DQo+ PlNvLCBpcyB5b3VyIGFzc2VydGlvbiB0aGF0IFJGQzU1NTMgaXMgYnJva2VuPw0KPj4NCj4+WW91 cnMgSXJyZXNwZWN0aXZlbHksDQo+Pg0KPj5Kb2huDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4gRnJvbTogWmFmYXIgQWxpICh6YWxpKSBbbWFpbHRvOnphbGlAY2lzY28u Y29tXQ0KPj4+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDgsIDIwMTMgMTA6NDcgQU0NCj4+PiBU bzogRmF0YWkgWmhhbmc7IEpvaG4gRSBEcmFrZTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnKQ0KPj4+ IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZm aWMgRW5naW5lZXJpbmcNCj4+PiAoUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVk ZSBSb3V0ZXMNCj4+PiANCj4+PiBGYXRhaSBhbmQgYWxsLQ0KPj4+IA0KPj4+IEluIGEgc3RhdGVs ZXNzIFBDRSwgUGF0aCBLZXlzIGFyZSB0cmFuc2llbnQgYW5kIHRoZXkgZXhwaXJlLiBGb3IgdGhp cw0KPj4+c29sdXRpb24NCj4+PiB0byB3b3JrIHlvdSBuZWVkIGEgUENFIHRoYXQgY2FuIGtlZXAg UGF0aHMgYXNzb2NpYXRlZCB3aXRoIGEgUGF0aCBLZXkNCj4+PiBhcm91bmQgKGEgc3RhdGVmdWwg UENFIHdoZXJlIHN0YXRlcyBhcmUgcGF0aCBjb21wdXRlZCBieSB0aGUgUENFKS4NCj4+PiANCj4+ PiBUaGFua3MNCj4+PiANCj4+PiBSZWdhcmRzIMWgIFphZmFyDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBGYXRhaSBaaGFuZyA8emhhbmdmYXRh aUBodWF3ZWkuY29tPg0KPj4+IERhdGU6IFR1ZXNkYXksIE9jdG9iZXIgOCwgMjAxMyAzOjAxIEFN DQo+Pj4gVG86ICJqZHJha2VAanVuaXBlci5uZXQiIDxqZHJha2VAanVuaXBlci5uZXQ+LCAiY2Nh bXBAaWV0Zi5vcmciDQo+Pj4gPGNjYW1wQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJlOiBbQ0NB TVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcNCj4+ PiAoUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4+PiANCj4+ PiA+SGkgSm9obiwNCj4+PiA+DQo+Pj4gPlRvdGFsbHkgYWdyZWUgd2l0aCB5b3UsIEkgYWxyZWFk eSBmb3VuZCB0aGVzZSB0d28gZHJhZnRzIGFyZSBtdWNoDQo+Pj4gPip1c2VsZXNzKi4NCj4+PiA+ DQo+Pj4gPlRoaXMgaXMgd2h5IHdlIG1hZGUgYSBuZXcgZHJhZnQgKHZlcnkgc2ltcGxlIGFuZCB1 c2VmdWwpIGFuZCBwdXQgb3VyDQo+Pj4gPmZlZXQgb24gdGhlIGdyb3VuZC4NCj4+PiA+DQo+Pj4g DQo+Pj4+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctY2Nh bXAtcm91dGUtZXhjbHVzaW9uLXANCj4+PiA+YXRoDQo+Pj4gPmtleS0wMC50eHQNCj4+PiA+DQo+ Pj4gPg0KPj4+ID4NCj4+PiA+DQo+Pj4gPkJlc3QgUmVnYXJkcw0KPj4+ID4NCj4+PiA+RmF0YWkN Cj4+PiA+DQo+Pj4gPg0KPj4+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ID5Gcm9t OiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10g T24NCj4+PiBCZWhhbGYNCj4+PiA+T2YgSm9obiBFIERyYWtlDQo+Pj4gPlNlbnQ6IFRodXJzZGF5 LCBPY3RvYmVyIDAzLCAyMDEzIDI6MjcgQU0NCj4+PiA+VG86IENDQU1QIChjY2FtcEBpZXRmLm9y ZykNCj4+PiA+U3ViamVjdDogW0NDQU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1U cmFmZmljIEVuZ2luZWVyaW5nDQo+Pj4gPihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBF eGNsdWRlIFJvdXRlcw0KPj4+ID4NCj4+PiA+SEksDQo+Pj4gPg0KPj4+ID5JIHdhcyByZWFkaW5n Og0KPj4+IA0KPj4+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1j Y2FtcC1sc3AtZGl2ZXJzaXR5Lz9pbmNsdWRlDQo+Pj4gPl90ZSB4dD0xLCBhbmQgSSBoYXBwZW5l ZCB0byBub3RpY2UgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGg6DQo+Pj4gPg0KPj4+ID4iVGhlIG1l YW5zIGJ5IHdoaWNoIHRoZSBub2RlIGNhbGN1bGF0aW5nIG9yIGV4cGFuZGluZyB0aGUgcm91dGUg b2YgdGhlDQo+Pj4gPnNpZ25hbGVkIExTUCBkaXNjb3ZlcnMgdGhlIHJvdXRlIG9mIHRoZSBwYXRo KHMpIGZyb20gd2hpY2ggdGhlDQo+Pj5zaWduYWxlZA0KPj4+ID5MU1AgIHJlcXVpcmVzIGRpdmVy c2l0eSBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAiDQo+Pj4gPg0KPj4+ ID5Eb2Vzbid0IHRoaXMgZGlzY2xhaW1lciBlZmZlY3RpdmVseSByZW5kZXIgdGhpcyBkcmFmdCB1 c2VsZXNzPyAgVGhlDQo+Pj4gPmRyYWZ0IGFsc28gZG9lcyBub3QgZGVmaW5lIGhvdyB0aGUgbm9k ZSB0aGF0IGluaXRpYWxseSBzaWduYWxlZCB0aGUNCj4+PkxTUA0KPj4+ID5maW5kcyB0aGUgJ25v ZGUgY2FsY3VsYXRpbmcgb3IgZXhwYW5kaW5nIHRoZSByb3V0ZScgIG5vciBob3cgaXQNCj4+PiA+ ZGVsaXZlcnMgdGhlIHNpZ25hbGVkIExTUCByZXF1ZXN0IHRvIHRoYXQgbm9kZS4NCj4+PiA+DQo+ Pj4gPkFzIGFuIGFzaWRlLCB0aGUgZHJhZnQ6DQo+Pj4gDQo+Pj4+aHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1hbGktY2NhbXAtcnN2cC10ZS1pbmNsdWRlLXJvdXRlLz8NCj4+ PiA+aW5jDQo+Pj4gPmx1ZGVfdGV4dD0xIHdvdWxkIGJlIHN1YmplY3QgdG8gdGhlIHNhbWUgY3Jp dGljaXNtIGV4Y2VwdCB0aGF0IHRoZQ0KPj4+ID5hYm92ZSBxdW90ZWQgcGFyYWdyYXBoIGlzIHJl cGxhY2VkIHdpdGg6DQo+Pj4gPg0KPj4+ID4iVGhlIGFib3ZlLW1lbnRpb25lZCB1c2UgY2FzZXMg cmVxdWlyZSByZWxldmFudCBwYXRoIGluY2x1c2lvbg0KPj4+ID5yZXF1aXJlbWVudHMgdG8gYmUg Y29tbXVuaWNhdGVkIHRvIHRoZSByb3V0ZSBleHBhbmRpbmcgbm9kZXMuICBUaGlzDQo+Pj4gPmRv Y3VtZW50IGFkZHJlc3NlcyAgdGhlc2UgcmVxdWlyZW1lbnRzIGFuZCBkZWZpbmVzIHByb2NlZHVy ZXMgdG8NCj4+PiA+YWRkcmVzcyB0aGVtLiINCj4+PiA+DQo+Pj4gPkV2ZW4gdGhvdWdoIHRoaXMg aXMgaGVscGZ1bCwgdGhlIGRyYWZ0IGRvZXNuJ3QgYWN0dWFsbHkgZGVmaW5lIHRoZXNlDQo+Pj4g PnByb2NlZHVyZXMuDQo+Pj4gPg0KPj4+ID5Zb3VycyBJcnJlc3BlY3RpdmVseSwNCj4+PiA+DQo+ Pj4gPkpvaG4NCj4+PiA+DQo+Pj4gPg0KPj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+ID5DQ0FNUCBtYWlsaW5nIGxpc3QNCj4+PiA+Q0NBTVBA aWV0Zi5vcmcNCj4+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cA0KPj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+ID5DQ0FNUCBtYWlsaW5nIGxpc3QNCj4+PiA+Q0NBTVBAaWV0Zi5vcmcNCj4+PiA+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+IA0KPj4+IA0KPj4NCj4+ DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5D Q0FNUCBtYWlsaW5nIGxpc3QNCj5DQ0FNUEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2NhbXANCg0K From zali@cisco.com Tue Oct 8 23:50:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4239821F9654 for ; Tue, 8 Oct 2013 23:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98mEGKVlUt0e for ; Tue, 8 Oct 2013 23:49:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5288B21F99FB for ; Tue, 8 Oct 2013 23:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10600; q=dns/txt; s=iport; t=1381301393; x=1382510993; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=m+4Hz0e0d8RvBokqEM1hx7SDZ924XLdnKhgMGSdgD2E=; b=YiaoS/PzYBy1m7ME1ljYX3dFvqv0JzSUrfdh+DKlWKagVH5+NV3b1uyv 3sEcUuDgVYmFwaZDR0JGrImBnNq2l9GqvSRMQGcIQiOn8ldz6+EuGWuMV msqshA+l1JrMzzFBbcNp1I5/aimeoV30oIBfRzhW163/4RGwDv2LqCRrs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FADr7VFKtJV2a/2dsb2JhbABagwc4UoMovggXgQkWdIIlAQEBBAEBASAROgsMBgEGAhEDAQEBAwIGGQQDAgQlCxQBCAgCBAENBQgBEodrDIpYm1ySQYEpjWgCFhsHBoJkNYEEA5kxkFGBZoE+gio X-IronPort-AV: E=Sophos;i="4.90,1061,1371081600"; d="scan'208";a="269834785" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 09 Oct 2013 06:49:52 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r996nq5a009626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 06:49:52 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 01:49:51 -0500 From: "Zafar Ali (zali)" To: Fatai Zhang , "Zhangxian (Xian)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYAAEh8IgAAGSCKAAAmjooD//745AIAARJEA///HfwA= Date: Wed, 9 Oct 2013 06:49:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.233.245] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 06:50:07 -0000 RmF0YWktIA0KDQpJbiBSRkMgNTUyMCBhbmQgUkZDNTU1MywgUENFIGlzIG9ubHkgZXhwZWN0ZWQg dG8ga2VlcCB0aGUgKHBhdGgga2V5LCBQYXRoDQppbmZvKSBzdGF0ZSBmb3Igb25seSBhIHNob3J0 IGFtb3VudCBvZiB0aW1lLiBUaW1lIHRoYXQgaXMgcmVxdWlyZWQgdG8NCnNpZ25hbCBhbiBMU1Ag cHJvdmlkZXMgYW4gdXBwZXIgYm91bmQgb24gdGhlIHRpbWUgdGhlIChwYXRoIGtleSwgUGF0aA0K aW5mbykgc3RhdGUgbmVlZHMgdG8gYmUgc3RvcmVkIGJ5IHRoZSBQQ0UuIFRoZSBSRkM1NTIwIHNw ZWNpZmljYWxseSB0YWxrcw0KYWJvdXQgcGF0aCBrZXkgZXhwaXJhdGlvbiBhbmQgaXMgcHVyZ2Vk LiAxNiBiaXQgcGF0aCBrZXlzIGFyZSB1c2VkIGFzDQpyZXVzZSBvZiB0aGUgcGF0aCBrZXkgaXMg YXNzdW1lZC4NCg0KSW4geW91ciBkcmFmdCB0aGUgUENFIG5lZWRzIHRvIHJlbWVtYmVyIHRoZSAo cGF0aCBrZXksIHBhdGggaW5mbykgInN0YXRlcyINCmZvciAiaW5kZWZpbml0ZSIgdGltZS4gSWYg eW91IGxpa2Ugd2UgY2FsbCBzdWNoIFBDRSAicGF0aC1zdGF0ZWZ1bCBQQ0UiDQpidXQgaXQgaXMg c3RhdGVmdWwuIEFsc28sIHRoZSBzb2x1dGlvbiBpcyBub3Qgc2NhbGFibGUgYXMgYSBQQ0UgY2Fu IG9ubHkNCmhvbGQgNjRLIG9mIChwYXRoIGtleSwgcGF0aCBpbmZvKSBzdGF0ZXMuDQoNClRoYW5r cw0KDQpSZWdhcmRzIOKApiBaYWZhcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBGYXRhaSBaaGFuZyA8emhhbmdmYXRhaUBodWF3ZWkuY29tPg0KRGF0ZTogV2VkbmVzZGF5 LCBPY3RvYmVyIDksIDIwMTMgMjoxMiBBTQ0KVG86IHphbGkgPHphbGlAY2lzY28uY29tPiwgIlpo YW5neGlhbiAoWGlhbikiIDx6aGFuZy54aWFuQGh1YXdlaS5jb20+LA0KImNjYW1wQGlldGYub3Jn IiA8Y2NhbXBAaWV0Zi5vcmc+DQpDYzogImpkcmFrZUBqdW5pcGVyLm5ldCIgPGpkcmFrZUBqdW5p cGVyLm5ldD4NClN1YmplY3Q6IFJFOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3Rv Y29sLVRyYWZmaWMgRW5naW5lZXJpbmcNCihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBF eGNsdWRlIFJvdXRlcw0KDQo+SGkgWmFmYXIsDQo+DQo+UmVhbGx5IGludGVyZXN0aW5nIGZvciB5 b3VyIGFzc2VydGlvbi4NCj4NCj5EaWQgeW91IG1lYW4gdGhhdCBSRkMgNTUyMCBpcyBzcGVjaWZp YyBmb3Igc3RhdGVmdWwgUENFPw0KPg0KPkluIGFkZGl0b24sIHBsZWFzZSBsb29rIGF0ICJDb250 cm9sIG9mIEZ1bmN0aW9uIHRocm91Z2ggQ29uZmlndXJhdGlvbiBhbmQNCj5Qb2xpY3kiIG9mIFJG QyA1NTIwIGFuZCBSRkM1NTUzLg0KPg0KPg0KPkJlc3QgUmVnYXJkcw0KPg0KPkZhdGFpDQo+DQo+ DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBaYWZhciBBbGkgKHphbGkpIFtt YWlsdG86emFsaUBjaXNjby5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA5LCAyMDEz IDI6MDcgUE0NCj5UbzogWmhhbmd4aWFuIChYaWFuKTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnKQ0K PkNjOiBKb2huIEUgRHJha2U7IEZhdGFpIFpoYW5nDQo+U3ViamVjdDogUmU6IFtDQ0FNUF0gUmVz b3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZw0KPihSU1ZQLVRF KSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPg0KPkhpIFpoYW5neGlhbjog DQo+DQo+U3RhdGUgZG9lcyBub3QgYWx3YXlzIG1lYW5zIFJTVlAgVEUgc3RhdGVzIGluIHRoZSBu ZXR3b3JrLiBQQ0UgKHNldmVyKQ0KPm5lZWRzIHRvIHJlbWVtYmVyIHBhdGggaW5mb3JtYXRpb24g KHBvc3NpYmx5IHdpdGggb3RoZXIgcGF0aCBhdHRyaWJ1dGVzKQ0KPml0IGNvbXB1dGVkIGZvciBp bmRlZmluaXRlIHRpbWUuIFRoZXNlIGFyZSBzdGF0ZXMgdGhhdCBQQ0UgbmVlZHMgdG8NCj5yZW1l bWJlci4gSGVuY2UsIHN0YXRlZnVsIFBDRS4NCj4NCj5UaGFua3MNCj4NCj5SZWdhcmRzIOKApiBa YWZhcg0KPg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogIlpoYW5neGlh biAgIChYaWFuKSIgPHpoYW5nLnhpYW5AaHVhd2VpLmNvbT4NCj5EYXRlOiBXZWRuZXNkYXksIE9j dG9iZXIgOSwgMjAxMyAyOjAyIEFNDQo+VG86IHphbGkgPHphbGlAY2lzY28uY29tPiwgImNjYW1w QGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+DQo+Q2M6ICJqZHJha2VAanVuaXBlci5uZXQiIDxq ZHJha2VAanVuaXBlci5uZXQ+LCBGYXRhaSBaaGFuZw0KPjx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+ DQo+U3ViamVjdDogUkU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJh ZmZpYyBFbmdpbmVlcmluZw0KPihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRl IFJvdXRlcw0KPg0KPj5IaSwgWmFmYXIsIA0KPj4gICAgDQo+PiAgICBUaGFuayB5b3UgZm9yIHNo YXJpbmcgdGhlIHRob3VnaHRzLiBCdXQgSSBjYW5ub3QgYWdyZWUgd2l0aCB3aGF0IHlvdQ0KPj5z YWlkIGJlbG93LiANCj4+DQo+PiAgICBQYXRoIGtleSBzb2x1dGlvbiBkb2VzIG5vdCBuZWNlc3Nh cmlseSBuZWVkIHRoZSBwcmVzZW5jZSBvZiBhDQo+PnN0YXRlZnVsIFBDRS4gU2ltaWxhcmx5IHdp dGggUkZDNTU1MywgdGhlIHBhdGgga2V5IG93bmVyIG5lZWRzIHRvIHJldGFpbg0KPj50aGlzIGlu Zm9ybWF0aW9uIHNvIHRoYXQgSSBjYW4gaW50ZXJwcmV0IHdoZW4gdXNlZCBhdCBhIGxhdGVyIHRp bWUuDQo+PlJldGFpbmluZyBzdWNoIGluZm9ybWF0aW9uIGRvZXMgbm90IGVxdWFsIHRvIGEgc3Rh dGVmdWwgUENFIHdoaWNoIG5lZWRzDQo+PnRvIGtub3cgdGhlIExTUCBzdGF0ZXMgb2YgdGhlIHdo b2xlIG5ldHdvcmsgaXQgc2VydmVzLg0KPj4NCj4+UmVnYXJkcywNCj4+WGlhbg0KPj4NCj4+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj5aYWZhciBBbGkg KHphbGkpDQo+PlNlbnQ6IDIwMTPlubQxMOaciDnml6UgMTM6MjYNCj4+VG86IEpvaG4gRSBEcmFr ZTsgRmF0YWkgWmhhbmc7IENDQU1QIChjY2FtcEBpZXRmLm9yZykNCj4+U3ViamVjdDogUmU6IFtD Q0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZw0K Pj4oUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4+DQo+Pkhp IEpvaG46IA0KPj4NCj4+Tm8sIFJGQyA1NTIwLyBSRkM1NTMzIGFyZSBmaW5lLiBUaGUgaXNzdWUg aXMgdGhhdCBzb2x1dGlvbiBwcm9wb3NlZCBieQ0KPj5kcmFmdC16aGFuZy1jY2FtcC1yb3V0ZS1l eGNsdXNpb24tcGF0aGtleS0wMC50eHQgZm9yY2VzIGN1c3RvbWVycyB0bw0KPj5kZXBsb3kgYSBz dGF0ZWZ1bCBQQ0Ugd2hlcmUgUENFIG5lZWQgdG8gcmVtZW1iZXIgcGF0aCBpdCBoYXMgc2VydmVk IGZvcg0KPj5pbmRlZmluaXRlIHRpbWUuIA0KPj4NCj4+VGhhbmtzDQo+Pg0KPj5SZWdhcmRzIC4u LiBaYWZhcg0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206ICJq ZHJha2VAanVuaXBlci5uZXQiIDxqZHJha2VAanVuaXBlci5uZXQ+DQo+PkRhdGU6IFR1ZXNkYXks IE9jdG9iZXIgOCwgMjAxMyA2OjI2IFBNDQo+PlRvOiB6YWxpIDx6YWxpQGNpc2NvLmNvbT4sIEZh dGFpIFpoYW5nIDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+LA0KPj4iY2NhbXBAaWV0Zi5vcmciIDxj Y2FtcEBpZXRmLm9yZz4NCj4+U3ViamVjdDogUkU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRp b24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZw0KPj4oUlNWUC1URSkgUGF0aCBEaXZlcnNp dHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4+DQo+Pj5aYWZhciwNCj4+Pg0KPj4+U28sIGlzIHlv dXIgYXNzZXJ0aW9uIHRoYXQgUkZDNTU1MyBpcyBicm9rZW4/DQo+Pj4NCj4+PllvdXJzIElycmVz cGVjdGl2ZWx5LA0KPj4+DQo+Pj5Kb2huDQo+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+Pj4gRnJvbTogWmFmYXIgQWxpICh6YWxpKSBbbWFpbHRvOnphbGlAY2lzY28uY29t XQ0KPj4+PiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDA4LCAyMDEzIDEwOjQ3IEFNDQo+Pj4+IFRv OiBGYXRhaSBaaGFuZzsgSm9obiBFIERyYWtlOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+Pj4+ IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZm aWMgRW5naW5lZXJpbmcNCj4+Pj4gKFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1 ZGUgUm91dGVzDQo+Pj4+IA0KPj4+PiBGYXRhaSBhbmQgYWxsLQ0KPj4+PiANCj4+Pj4gSW4gYSBz dGF0ZWxlc3MgUENFLCBQYXRoIEtleXMgYXJlIHRyYW5zaWVudCBhbmQgdGhleSBleHBpcmUuIEZv ciB0aGlzDQo+Pj4+c29sdXRpb24NCj4+Pj4gdG8gd29yayB5b3UgbmVlZCBhIFBDRSB0aGF0IGNh biBrZWVwIFBhdGhzIGFzc29jaWF0ZWQgd2l0aCBhIFBhdGggS2V5DQo+Pj4+IGFyb3VuZCAoYSBz dGF0ZWZ1bCBQQ0Ugd2hlcmUgc3RhdGVzIGFyZSBwYXRoIGNvbXB1dGVkIGJ5IHRoZSBQQ0UpLg0K Pj4+PiANCj4+Pj4gVGhhbmtzDQo+Pj4+IA0KPj4+PiBSZWdhcmRzIMWgIFphZmFyDQo+Pj4+IA0K Pj4+PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogRmF0YWkg WmhhbmcgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbT4NCj4+Pj4gRGF0ZTogVHVlc2RheSwgT2N0b2Jl ciA4LCAyMDEzIDM6MDEgQU0NCj4+Pj4gVG86ICJqZHJha2VAanVuaXBlci5uZXQiIDxqZHJha2VA anVuaXBlci5uZXQ+LCAiY2NhbXBAaWV0Zi5vcmciDQo+Pj4+IDxjY2FtcEBpZXRmLm9yZz4NCj4+ Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJh ZmZpYyBFbmdpbmVlcmluZw0KPj4+PiAoUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhj bHVkZSBSb3V0ZXMNCj4+Pj4gDQo+Pj4+ID5IaSBKb2huLA0KPj4+PiA+DQo+Pj4+ID5Ub3RhbGx5 IGFncmVlIHdpdGggeW91LCBJIGFscmVhZHkgZm91bmQgdGhlc2UgdHdvIGRyYWZ0cyBhcmUgbXVj aA0KPj4+PiA+KnVzZWxlc3MqLg0KPj4+PiA+DQo+Pj4+ID5UaGlzIGlzIHdoeSB3ZSBtYWRlIGEg bmV3IGRyYWZ0ICh2ZXJ5IHNpbXBsZSBhbmQgdXNlZnVsKSBhbmQgcHV0IG91cg0KPj4+PiA+ZmVl dCBvbiB0aGUgZ3JvdW5kLg0KPj4+PiA+DQo+Pj4+IA0KPj4+Pj5odHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGFuZy1jY2FtcC1yb3V0ZS1leGNsdXNpb24tDQo+Pj4+ PnANCj4+Pj4gPmF0aA0KPj4+PiA+a2V5LTAwLnR4dA0KPj4+PiA+DQo+Pj4+ID4NCj4+Pj4gPg0K Pj4+PiA+DQo+Pj4+ID5CZXN0IFJlZ2FyZHMNCj4+Pj4gPg0KPj4+PiA+RmF0YWkNCj4+Pj4gPg0K Pj4+PiA+DQo+Pj4+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiA+RnJvbTogY2Nh bXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ Pj4+IEJlaGFsZg0KPj4+PiA+T2YgSm9obiBFIERyYWtlDQo+Pj4+ID5TZW50OiBUaHVyc2RheSwg T2N0b2JlciAwMywgMjAxMyAyOjI3IEFNDQo+Pj4+ID5UbzogQ0NBTVAgKGNjYW1wQGlldGYub3Jn KQ0KPj4+PiA+U3ViamVjdDogW0NDQU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1U cmFmZmljIEVuZ2luZWVyaW5nDQo+Pj4+ID4oUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcg RXhjbHVkZSBSb3V0ZXMNCj4+Pj4gPg0KPj4+PiA+SEksDQo+Pj4+ID4NCj4+Pj4gPkkgd2FzIHJl YWRpbmc6DQo+Pj4+IA0KPj4+Pj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtY2NhbXAtbHNwLWRpdmVyc2l0eS8/aW5jbHVkDQo+Pj4+PmUNCj4+Pj4gPl90ZSB4dD0x LCBhbmQgSSBoYXBwZW5lZCB0byBub3RpY2UgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGg6DQo+Pj4+ ID4NCj4+Pj4gPiJUaGUgbWVhbnMgYnkgd2hpY2ggdGhlIG5vZGUgY2FsY3VsYXRpbmcgb3IgZXhw YW5kaW5nIHRoZSByb3V0ZSBvZg0KPj4+PnRoZQ0KPj4+PiA+c2lnbmFsZWQgTFNQIGRpc2NvdmVy cyB0aGUgcm91dGUgb2YgdGhlIHBhdGgocykgZnJvbSB3aGljaCB0aGUNCj4+Pj5zaWduYWxlZA0K Pj4+PiA+TFNQICByZXF1aXJlcyBkaXZlcnNpdHkgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudC4gIg0KPj4+PiA+DQo+Pj4+ID5Eb2Vzbid0IHRoaXMgZGlzY2xhaW1lciBlZmZl Y3RpdmVseSByZW5kZXIgdGhpcyBkcmFmdCB1c2VsZXNzPyAgVGhlDQo+Pj4+ID5kcmFmdCBhbHNv IGRvZXMgbm90IGRlZmluZSBob3cgdGhlIG5vZGUgdGhhdCBpbml0aWFsbHkgc2lnbmFsZWQgdGhl DQo+Pj4+TFNQDQo+Pj4+ID5maW5kcyB0aGUgJ25vZGUgY2FsY3VsYXRpbmcgb3IgZXhwYW5kaW5n IHRoZSByb3V0ZScgIG5vciBob3cgaXQNCj4+Pj4gPmRlbGl2ZXJzIHRoZSBzaWduYWxlZCBMU1Ag cmVxdWVzdCB0byB0aGF0IG5vZGUuDQo+Pj4+ID4NCj4+Pj4gPkFzIGFuIGFzaWRlLCB0aGUgZHJh ZnQ6DQo+Pj4+IA0KPj4+Pj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFs aS1jY2FtcC1yc3ZwLXRlLWluY2x1ZGUtcm91dGUvDQo+Pj4+Pj8NCj4+Pj4gPmluYw0KPj4+PiA+ bHVkZV90ZXh0PTEgd291bGQgYmUgc3ViamVjdCB0byB0aGUgc2FtZSBjcml0aWNpc20gZXhjZXB0 IHRoYXQgdGhlDQo+Pj4+ID5hYm92ZSBxdW90ZWQgcGFyYWdyYXBoIGlzIHJlcGxhY2VkIHdpdGg6 DQo+Pj4+ID4NCj4+Pj4gPiJUaGUgYWJvdmUtbWVudGlvbmVkIHVzZSBjYXNlcyByZXF1aXJlIHJl bGV2YW50IHBhdGggaW5jbHVzaW9uDQo+Pj4+ID5yZXF1aXJlbWVudHMgdG8gYmUgY29tbXVuaWNh dGVkIHRvIHRoZSByb3V0ZSBleHBhbmRpbmcgbm9kZXMuICBUaGlzDQo+Pj4+ID5kb2N1bWVudCBh ZGRyZXNzZXMgIHRoZXNlIHJlcXVpcmVtZW50cyBhbmQgZGVmaW5lcyBwcm9jZWR1cmVzIHRvDQo+ Pj4+ID5hZGRyZXNzIHRoZW0uIg0KPj4+PiA+DQo+Pj4+ID5FdmVuIHRob3VnaCB0aGlzIGlzIGhl bHBmdWwsIHRoZSBkcmFmdCBkb2Vzbid0IGFjdHVhbGx5IGRlZmluZSB0aGVzZQ0KPj4+PiA+cHJv Y2VkdXJlcy4NCj4+Pj4gPg0KPj4+PiA+WW91cnMgSXJyZXNwZWN0aXZlbHksDQo+Pj4+ID4NCj4+ Pj4gPkpvaG4NCj4+Pj4gPg0KPj4+PiA+DQo+Pj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiA+Q0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+ID5D Q0FNUEBpZXRmLm9yZw0KPj4+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0KPj4+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4gPkNDQU1QIG1haWxpbmcgbGlzdA0KPj4+PiA+Q0NBTVBAaWV0Zi5vcmcNCj4+ Pj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4gDQo+ Pj4+IA0KPj4+DQo+Pj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PkNDQU1QIG1haWxpbmcgbGlzdA0KPj5DQ0FNUEBpZXRmLm9yZw0KPj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+DQoNCg== From cyril.margaria@coriant.com Wed Oct 9 00:21:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0A321E80E7 for ; Wed, 9 Oct 2013 00:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[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 p76RiPSwcd5g for ; Wed, 9 Oct 2013 00:21:35 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id F16AD21E80D4 for ; Wed, 9 Oct 2013 00:21:26 -0700 (PDT) Received: from mail26-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 07:21:26 +0000 Received: from mail26-ch1 (localhost [127.0.0.1]) by mail26-ch1-R.bigfish.com (Postfix) with ESMTP id 0BB5B3A0163; Wed, 9 Oct 2013 07:21:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.165; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0411HT002.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371Ic89bh542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received-SPF: pass (mail26-ch1: domain of coriant.com designates 157.56.249.165 as permitted sender) client-ip=157.56.249.165; envelope-from=cyril.margaria@coriant.com; helo=AM2PRD0411HT002.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail26-ch1 (localhost.localdomain [127.0.0.1]) by mail26-ch1 (MessageSwitch) id 1381303283742201_20367; Wed, 9 Oct 2013 07:21:23 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail26-ch1.bigfish.com (Postfix) with ESMTP id AFCE510006B; Wed, 9 Oct 2013 07:21:23 +0000 (UTC) Received: from AM2PRD0411HT002.eurprd04.prod.outlook.com (157.56.249.165) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 07:21:23 +0000 Received: from AM2PRD0411MB422.eurprd04.prod.outlook.com ([169.254.4.83]) by AM2PRD0411HT002.eurprd04.prod.outlook.com ([10.255.163.37]) with mapi id 14.16.0371.000; Wed, 9 Oct 2013 07:21:21 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: "Zafar Ali (zali)" , Daniele Ceccarelli , Fatai Zhang , John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABN/2rAAHhLcgAABdsyw Date: Wed, 9 Oct 2013 07:21:22 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D02DB2DB2@AM2PRD0411MB422.eurprd04.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE48161FF7@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.159.77.165] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%JUNIPER.NET$RO%1$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 07:21:41 -0000 SGkgWmFmYXIsIA0KDQpJbiBteSB1bmRlcnN0YW5kaW5nIHRoZSBQS1MgZHJhZnQgZG9lcyBub3Qg cmVxdWlyZSBhbnkgc3RhdGVmdWwgUENFIGNhcGFiaWxpdHksIG9ubHkgYSBQS1MgcmVzb2x1dGlv biBjYXBhYmlsaXR5Lg0KQ291bGQgeW91IGRldGFpbCB3aHkgeW91IHNlZSBzdGF0ZWZ1bCBhIHJl cXVpZXJlbWVudD8NCg0KDQpNaXQgZnJldW5kbGljaGVuIEdyw7zDn2VuIC8gQmVzdCBSZWdhcmRz DQpDeXJpbCBNYXJnYXJpYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YNCj4gWmFmYXIgQWxpICh6YWxpKQ0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9i ZXIgMDksIDIwMTMgNzozNyBBTQ0KPiBUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBGYXRhaSBaaGFu ZzsgSm9obiBFIERyYWtlOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+IFN1YmplY3Q6IFJlOiBb Q0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcg KFJTVlAtDQo+IFRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPiANCj4g RGFuaWVsZToNCj4gDQo+IFRoZSBtYWluIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgZHJhZnRzIGlz IHRoYXQgb25lIGlzIFJTVlAtVEUgc2lnbmFsaW5nIGJhc2VkDQo+IHNvbHV0aW9uLCB3aGlsZSB0 aGUgb3RoZXIgZm9yY2VzIGN1c3RvbWVycyB0byBkZXBsb3kgc3RhdGVmdWwgUENFLg0KPiBDYWxs aW5nIGEgUlNWUC1URSBiYXNlZCBzaWduYWxpbmcgc29sdXRpb24gdGhhdCBpcyBhIFdHIGRvY3Vt ZW50ICJ1c2VsZXNzIg0KPiB0byBmb3JjZSBhICJzdGF0ZWZ1bCIgUENFIGJhc2VkIHNvbHV0aW9u LyBhcmNoaXRlY3R1cmUgdG8gc2VydmljZSBwcm92aWRlcnMgaXMNCj4gdmVyeSBpbmFwcHJvcHJp YXRlLg0KPiANCj4gVGhhbmtzDQo+IA0KPiBSZWdhcmRzIMWgIFphZmFyDQo+IA0KPiANCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5p ZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPg0KPiBEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDgs IDIwMTMgMTI6MzIgUE0NCj4gVG86IEZhdGFpIFpoYW5nIDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+ LCAiamRyYWtlQGp1bmlwZXIubmV0Ig0KPiA8amRyYWtlQGp1bmlwZXIubmV0PiwgImNjYW1wQGll dGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNl IFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcNCj4gKFJTVlAtVEUpIFBh dGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVzDQo+IA0KPiA+VGhhbmtzIEpvaG4gZm9y IHBvaW50aW5nIHRoYXQgb3V0LiBXaGVuIEkgZmlyc3QgcmVhZCB0aGUgZHJhZnQgSSBtaXNzZWQN Cj4gPnRoYXQgcG9pbnQuDQo+ID4NCj4gPkkgc2VlIHR3byBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRo ZSB0d28gZHJhZnRzOg0KPiA+MS4gdXRpbGl6YXRpb24gb2YgNXBsZSB2cyBQYXRoIGtleQ0KPiA+ Mi4gVGhlIHBhdGggZGl2ZXJzaXR5IGRyYWZ0IGRvZXMgbm90IHNheSBob3cgdG8gY29sbGVjdCB0 aGUgNXBsZSAod2hpY2gNCj4gPmluIHNvbWUgY2FzZXMgY291bGQgbm90IGJlIGF2YWlsYWJsZSBh dCBhbGwpLCB0aGUgcGF0aCBrZXkgZHJhZnQgY292ZXJzDQo+ID50aGlzIGFzcGVjdCBhbHNvDQo+ ID4NCj4gPlJlIDEgSSBoYXZlIGEgbW9kZXJhdGUgcHJlZmVyZW5jZSBmb3IgdGhlIHBhdGgga2V5 IGZvciB0aGUgc2VjdXJpdHkNCj4gPnJlYXNvbnMgdGhhdCBsZWFkIHRvIHRoZSBkZWZpbml0aW9u IG9mIHRoZSBQYXRoIEtleSB5ZWFycyBhZ28gYW5kDQo+ID5zZWNvbmRseSBpdCdzIHNpbXBsZXIu DQo+ID5SZSAyIEkgZG9uJ3Qga25vdyBob3cgdGhlIFdHIHdpbGwgbWFuYWdlIHRoZSBpc3N1ZSBv ZiB0d28gY29tcGV0aW5nDQo+ID5kcmFmdHMgKG9uZSB3ZywgdGhlIG90aGVyIGluZGl2aWR1YWwp IGJ1dCBpbiBhbnkgY2FzZSBpdCdzIGFuIGlzc3VlDQo+ID50aGF0IG5lZWQgdG8gYmUgZml4ZWQg c29tZWhvdy4NCj4gPg0KPiA+QlINCj4gPkRhbmllbGUNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPj4gQmVoYWxmIE9mIEZhdGFpIFpoYW5nDQo+ ID4+IFNlbnQ6IG1hcnRlZMOsIDggb3R0b2JyZSAyMDEzIDA5OjAyDQo+ID4+IFRvOiBKb2huIEUg RHJha2U7IENDQU1QIChjY2FtcEBpZXRmLm9yZykNCj4gPj4gU3ViamVjdDogUmU6IFtDQ0FNUF0g UmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYw0KPiA+PiBFbmdpbmVlcmluZw0K PiA+PiAoUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4gPj4N Cj4gPj4gSGkgSm9obiwNCj4gPj4NCj4gPj4gVG90YWxseSBhZ3JlZSB3aXRoIHlvdSwgSSBhbHJl YWR5IGZvdW5kIHRoZXNlIHR3byBkcmFmdHMgYXJlIG11Y2gNCj4gPj4qdXNlbGVzcyouDQo+ID4+ DQo+ID4+IFRoaXMgaXMgd2h5IHdlIG1hZGUgYSBuZXcgZHJhZnQgKHZlcnkgc2ltcGxlIGFuZCB1 c2VmdWwpIGFuZCBwdXQgb3VyDQo+ID4+ZmVldCBvbiAgdGhlIGdyb3VuZC4NCj4gPj4NCj4gPj4g aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctY2NhbXAtcm91 dGUtZXhjbHVzaW9uDQo+ID4+IC0NCj4gPj4gcGF0aGtleS0wMC50eHQNCj4gPj4NCj4gPj4NCj4g Pj4NCj4gPj4NCj4gPj4gQmVzdCBSZWdhcmRzDQo+ID4+DQo+ID4+IEZhdGFpDQo+ID4+DQo+ID4+ DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+PkJlaGFs ZiAgT2YgSm9obiBFIERyYWtlDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDAzLCAyMDEz IDI6MjcgQU0NCj4gPj4gVG86IENDQU1QIChjY2FtcEBpZXRmLm9yZykNCj4gPj4gU3ViamVjdDog W0NDQU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5n DQo+ID4+KFJTVlAtDQo+ID4+IFRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRl cw0KPiA+Pg0KPiA+PiBISSwNCj4gPj4NCj4gPj4gSSB3YXMgcmVhZGluZzogICBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtbHNwLQ0KPiA+PiBkaXZlcnNp dHkvP2luY2x1ZGVfdGV4dD0xLCBhbmQgSSBoYXBwZW5lZCB0byBub3RpY2UgdGhlIGZvbGxvd2lu Zw0KPiA+PnBhcmFncmFwaDoNCj4gPj4NCj4gPj4gIlRoZSBtZWFucyBieSB3aGljaCB0aGUgbm9k ZSBjYWxjdWxhdGluZyBvciBleHBhbmRpbmcgdGhlIHJvdXRlIG9mDQo+ID4+dGhlICBzaWduYWxl ZCBMU1AgZGlzY292ZXJzIHRoZSByb3V0ZSBvZiB0aGUgcGF0aChzKSBmcm9tIHdoaWNoIHRoZQ0K PiA+PnNpZ25hbGVkIExTUCAgcmVxdWlyZXMgZGl2ZXJzaXR5IGFyZSBiZXlvbmQgdGhlIHNjb3Bl IG9mIHRoaXMNCj4gPj5kb2N1bWVudC4gIg0KPiA+Pg0KPiA+PiBEb2Vzbid0IHRoaXMgZGlzY2xh aW1lciBlZmZlY3RpdmVseSByZW5kZXIgdGhpcyBkcmFmdCB1c2VsZXNzPyAgVGhlDQo+ID4+ZHJh ZnQgYWxzbyAgZG9lcyBub3QgZGVmaW5lIGhvdyB0aGUgbm9kZSB0aGF0IGluaXRpYWxseSBzaWdu YWxlZCB0aGUNCj4gPj5MU1AgZmluZHMgdGhlICdub2RlICBjYWxjdWxhdGluZyBvciBleHBhbmRp bmcgdGhlIHJvdXRlJyAgbm9yIGhvdyBpdA0KPiA+PmRlbGl2ZXJzIHRoZSBzaWduYWxlZCBMU1Ag IHJlcXVlc3QgdG8gdGhhdCBub2RlLg0KPiA+Pg0KPiA+PiBBcyBhbiBhc2lkZSwgdGhlIGRyYWZ0 Og0KPiA+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWxpLWNjYW1wLXJz dnAtDQo+ID4+IHRlLWluY2x1ZGUtcm91dGUvP2luY2x1ZGVfdGV4dD0xIHdvdWxkIGJlIHN1Ympl Y3QgdG8gdGhlIHNhbWUNCj4gPj5jcml0aWNpc20gIGV4Y2VwdCB0aGF0IHRoZSBhYm92ZSBxdW90 ZWQgcGFyYWdyYXBoIGlzIHJlcGxhY2VkIHdpdGg6DQo+ID4+DQo+ID4+ICJUaGUgYWJvdmUtbWVu dGlvbmVkIHVzZSBjYXNlcyByZXF1aXJlIHJlbGV2YW50IHBhdGggaW5jbHVzaW9uDQo+ID4+IHJl cXVpcmVtZW50cyB0byBiZSBjb21tdW5pY2F0ZWQgdG8gdGhlIHJvdXRlIGV4cGFuZGluZyBub2Rl cy4gIFRoaXMNCj4gPj4gZG9jdW1lbnQgYWRkcmVzc2VzICB0aGVzZSByZXF1aXJlbWVudHMgYW5k IGRlZmluZXMgcHJvY2VkdXJlcyB0bw0KPiA+PiBhZGRyZXNzIHRoZW0uIg0KPiA+Pg0KPiA+PiBF dmVuIHRob3VnaCB0aGlzIGlzIGhlbHBmdWwsIHRoZSBkcmFmdCBkb2Vzbid0IGFjdHVhbGx5IGRl ZmluZSB0aGVzZQ0KPiA+PiBwcm9jZWR1cmVzLg0KPiA+Pg0KPiA+PiBZb3VycyBJcnJlc3BlY3Rp dmVseSwNCj4gPj4NCj4gPj4gSm9obg0KPiA+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBDQ0FNUCBtYWlsaW5nIGxpc3QN Cj4gPj4gQ0NBTVBAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcA0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gPj4gQ0NBTVBAaWV0Zi5vcmcN Cj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiA+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPkNDQU1QIG1h aWxpbmcgbGlzdA0KPiA+Q0NBTVBAaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2NhbXANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg== From zhangfatai@huawei.com Wed Oct 9 00:24:05 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F12721E80D4 for ; Wed, 9 Oct 2013 00:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=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 dQtC5FPDvyeB for ; Wed, 9 Oct 2013 00:24:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BE6E021E80C7 for ; Wed, 9 Oct 2013 00:23:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYU04692; Wed, 09 Oct 2013 07:23:54 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 08:23:12 +0100 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 08:23:43 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.86]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 15:23:32 +0800 From: Fatai Zhang To: "Zafar Ali (zali)" , "Zhangxian (Xian)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYD//7cKgIAAdVAA//9yNXCAAJkkgP//eVVwgACSuID//3dPMA== Date: Wed, 9 Oct 2013 07:23:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 07:24:05 -0000 SGkgWmFmYXIsDQoNClRoaXMgaXMgb3BlcmF0b3IncyBwb2xpY3ksIGFuZCB0aW1lciBjYW4gaGVs cCBhcyB3aGF0IFJGQzU1MjAgYW5kIFJGQyA1NTUzIGRlZmluZWQuDQoNCkkgcmVhbGx5IGRvbid0 IHdhbnQgdG8gc3BlbmQgbXkgdGltZSBvbiBkaXNjdXNzaW5nIHRoZSB0ZXJtaW5vbG9neSBvciBw aGlsb3NvcGh5IChvbiB3aGF0IGlzIHN0YXRlZnVsIFBDRSksIGJ1dCBJIG1vcmUgY2FyZSBhYm91 dCBob3cgeW91ciBkcmFmdCBjYW4gd29yay4gDQoNCkNvdWxkIHlvdSBjbGFyaWZ5IEpvaG4ncyBx dWVzdGlvbiBiZWxvdyAoaXQgaXMgYWxzbyBteSBxdWVzdGlvbik/IA0KSG93IGRvZXMgeW91ciBk cmFmdCB3b3JrIGluIHRoZSByZWFsIGltcGxlbWVudGF0aW9uPyBXaG8gY2FuIGludGVycHJldCB0 aGUgKkxTUCBpZGVudGlmaWVyKiAoNXBsZSkgZGVmaW5lZCBpbiB5b3VyIGRyYWZ0PyANCg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQo+PiJUaGUgbWVhbnMgYnkgd2hpY2ggdGhlIG5vZGUgY2FsY3VsYXRpbmcgb3Ig ZXhwYW5kaW5nIHRoZSByb3V0ZSBvZiB0aGUgc2lnbmFsZWQgTFNQIGRpc2NvdmVycyB0aGUgcm91 dGUgb2YgdGhlIHBhdGgocykgZnJvbSB3aGljaCB0aGUgc2lnbmFsZWQgTFNQIHJlcXVpcmVzIGRp dmVyc2l0eSBhcmUgYmV5b25kIHRoZSBzY29wZSANCj4+b2YgdGhpcyBkb2N1bWVudC4gIiANCg0K Pj5Eb2Vzbid0IHRoaXMgZGlzY2xhaW1lciBlZmZlY3RpdmVseSByZW5kZXIgdGhpcyBkcmFmdCB1 c2VsZXNzPyBUaGUgZHJhZnQgYWxzbyBkb2VzIG5vdCBkZWZpbmUgaG93IHRoZSBub2RlIHRoYXQg aW5pdGlhbGx5IHNpZ25hbGVkIHRoZSBMU1AgZmluZHMgdGhlICdub2RlIGNhbGN1bGF0aW5nIG9y IGV4cGFuZGluZyB0aGUgcm91dGUnICANCj4+bm9yIGhvdyBpdCBkZWxpdmVycyB0aGUgc2lnbmFs ZWQgTFNQIHJlcXVlc3QgdG8gdGhhdCBub2RlLg0KDQoNCg0KQmVzdCBSZWdhcmRzDQoNCkZhdGFp DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFphZmFyIEFsaSAoemFsaSkg W21haWx0bzp6YWxpQGNpc2NvLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDksIDIw MTMgMjo1MCBQTQ0KVG86IEZhdGFpIFpoYW5nOyBaaGFuZ3hpYW4gKFhpYW4pOyBDQ0FNUCAoY2Nh bXBAaWV0Zi5vcmcpDQpDYzogSm9obiBFIERyYWtlDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBSZXNv dXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nIChSU1ZQLVRFKSBQ YXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KDQpGYXRhaS0gDQoNCkluIFJGQyA1 NTIwIGFuZCBSRkM1NTUzLCBQQ0UgaXMgb25seSBleHBlY3RlZCB0byBrZWVwIHRoZSAocGF0aCBr ZXksIFBhdGgNCmluZm8pIHN0YXRlIGZvciBvbmx5IGEgc2hvcnQgYW1vdW50IG9mIHRpbWUuIFRp bWUgdGhhdCBpcyByZXF1aXJlZCB0bw0Kc2lnbmFsIGFuIExTUCBwcm92aWRlcyBhbiB1cHBlciBi b3VuZCBvbiB0aGUgdGltZSB0aGUgKHBhdGgga2V5LCBQYXRoDQppbmZvKSBzdGF0ZSBuZWVkcyB0 byBiZSBzdG9yZWQgYnkgdGhlIFBDRS4gVGhlIFJGQzU1MjAgc3BlY2lmaWNhbGx5IHRhbGtzDQph Ym91dCBwYXRoIGtleSBleHBpcmF0aW9uIGFuZCBpcyBwdXJnZWQuIDE2IGJpdCBwYXRoIGtleXMg YXJlIHVzZWQgYXMNCnJldXNlIG9mIHRoZSBwYXRoIGtleSBpcyBhc3N1bWVkLg0KDQpJbiB5b3Vy IGRyYWZ0IHRoZSBQQ0UgbmVlZHMgdG8gcmVtZW1iZXIgdGhlIChwYXRoIGtleSwgcGF0aCBpbmZv KSAic3RhdGVzIg0KZm9yICJpbmRlZmluaXRlIiB0aW1lLiBJZiB5b3UgbGlrZSB3ZSBjYWxsIHN1 Y2ggUENFICJwYXRoLXN0YXRlZnVsIFBDRSINCmJ1dCBpdCBpcyBzdGF0ZWZ1bC4gQWxzbywgdGhl IHNvbHV0aW9uIGlzIG5vdCBzY2FsYWJsZSBhcyBhIFBDRSBjYW4gb25seQ0KaG9sZCA2NEsgb2Yg KHBhdGgga2V5LCBwYXRoIGluZm8pIHN0YXRlcy4NCg0KVGhhbmtzDQoNClJlZ2FyZHMg4oCmIFph ZmFyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEZhdGFpIFpoYW5nIDx6 aGFuZ2ZhdGFpQGh1YXdlaS5jb20+DQpEYXRlOiBXZWRuZXNkYXksIE9jdG9iZXIgOSwgMjAxMyAy OjEyIEFNDQpUbzogemFsaSA8emFsaUBjaXNjby5jb20+LCAiWmhhbmd4aWFuIChYaWFuKSIgPHpo YW5nLnhpYW5AaHVhd2VpLmNvbT4sDQoiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4N CkNjOiAiamRyYWtlQGp1bmlwZXIubmV0IiA8amRyYWtlQGp1bmlwZXIubmV0Pg0KU3ViamVjdDog UkU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVl cmluZw0KKFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVzDQoNCj5I aSBaYWZhciwNCj4NCj5SZWFsbHkgaW50ZXJlc3RpbmcgZm9yIHlvdXIgYXNzZXJ0aW9uLg0KPg0K PkRpZCB5b3UgbWVhbiB0aGF0IFJGQyA1NTIwIGlzIHNwZWNpZmljIGZvciBzdGF0ZWZ1bCBQQ0U/ DQo+DQo+SW4gYWRkaXRvbiwgcGxlYXNlIGxvb2sgYXQgIkNvbnRyb2wgb2YgRnVuY3Rpb24gdGhy b3VnaCBDb25maWd1cmF0aW9uIGFuZA0KPlBvbGljeSIgb2YgUkZDIDU1MjAgYW5kIFJGQzU1NTMu DQo+DQo+DQo+QmVzdCBSZWdhcmRzDQo+DQo+RmF0YWkNCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPkZyb206IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxpQGNpc2NvLmNv bV0NCj5TZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDksIDIwMTMgMjowNyBQTQ0KPlRvOiBaaGFu Z3hpYW4gKFhpYW4pOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+Q2M6IEpvaG4gRSBEcmFrZTsg RmF0YWkgWmhhbmcNCj5TdWJqZWN0OiBSZTogW0NDQU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQ cm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+KFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVz aW5nIEV4Y2x1ZGUgUm91dGVzDQo+DQo+SGkgWmhhbmd4aWFuOiANCj4NCj5TdGF0ZSBkb2VzIG5v dCBhbHdheXMgbWVhbnMgUlNWUCBURSBzdGF0ZXMgaW4gdGhlIG5ldHdvcmsuIFBDRSAoc2V2ZXIp DQo+bmVlZHMgdG8gcmVtZW1iZXIgcGF0aCBpbmZvcm1hdGlvbiAocG9zc2libHkgd2l0aCBvdGhl ciBwYXRoIGF0dHJpYnV0ZXMpDQo+aXQgY29tcHV0ZWQgZm9yIGluZGVmaW5pdGUgdGltZS4gVGhl c2UgYXJlIHN0YXRlcyB0aGF0IFBDRSBuZWVkcyB0bw0KPnJlbWVtYmVyLiBIZW5jZSwgc3RhdGVm dWwgUENFLg0KPg0KPlRoYW5rcw0KPg0KPlJlZ2FyZHMg4oCmIFphZmFyDQo+DQo+DQo+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiAiWmhhbmd4aWFuICAgKFhpYW4pIiA8emhhbmcu eGlhbkBodWF3ZWkuY29tPg0KPkRhdGU6IFdlZG5lc2RheSwgT2N0b2JlciA5LCAyMDEzIDI6MDIg QU0NCj5UbzogemFsaSA8emFsaUBjaXNjby5jb20+LCAiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBp ZXRmLm9yZz4NCj5DYzogImpkcmFrZUBqdW5pcGVyLm5ldCIgPGpkcmFrZUBqdW5pcGVyLm5ldD4s IEZhdGFpIFpoYW5nDQo+PHpoYW5nZmF0YWlAaHVhd2VpLmNvbT4NCj5TdWJqZWN0OiBSRTogW0ND QU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+ KFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVzDQo+DQo+PkhpLCBa YWZhciwgDQo+PiAgICANCj4+ICAgIFRoYW5rIHlvdSBmb3Igc2hhcmluZyB0aGUgdGhvdWdodHMu IEJ1dCBJIGNhbm5vdCBhZ3JlZSB3aXRoIHdoYXQgeW91DQo+PnNhaWQgYmVsb3cuIA0KPj4NCj4+ ICAgIFBhdGgga2V5IHNvbHV0aW9uIGRvZXMgbm90IG5lY2Vzc2FyaWx5IG5lZWQgdGhlIHByZXNl bmNlIG9mIGENCj4+c3RhdGVmdWwgUENFLiBTaW1pbGFybHkgd2l0aCBSRkM1NTUzLCB0aGUgcGF0 aCBrZXkgb3duZXIgbmVlZHMgdG8gcmV0YWluDQo+PnRoaXMgaW5mb3JtYXRpb24gc28gdGhhdCBJ IGNhbiBpbnRlcnByZXQgd2hlbiB1c2VkIGF0IGEgbGF0ZXIgdGltZS4NCj4+UmV0YWluaW5nIHN1 Y2ggaW5mb3JtYXRpb24gZG9lcyBub3QgZXF1YWwgdG8gYSBzdGF0ZWZ1bCBQQ0Ugd2hpY2ggbmVl ZHMNCj4+dG8ga25vdyB0aGUgTFNQIHN0YXRlcyBvZiB0aGUgd2hvbGUgbmV0d29yayBpdCBzZXJ2 ZXMuDQo+Pg0KPj5SZWdhcmRzLA0KPj5YaWFuDQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj5Gcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+PlphZmFyIEFsaSAoemFsaSkNCj4+U2VudDogMjAx M+W5tDEw5pyIOeaXpSAxMzoyNg0KPj5UbzogSm9obiBFIERyYWtlOyBGYXRhaSBaaGFuZzsgQ0NB TVAgKGNjYW1wQGlldGYub3JnKQ0KPj5TdWJqZWN0OiBSZTogW0NDQU1QXSBSZXNvdXJjZSBSZXNl clZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+PihSU1ZQLVRFKSBQYXRoIERp dmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPj4NCj4+SGkgSm9objogDQo+Pg0KPj5Obywg UkZDIDU1MjAvIFJGQzU1MzMgYXJlIGZpbmUuIFRoZSBpc3N1ZSBpcyB0aGF0IHNvbHV0aW9uIHBy b3Bvc2VkIGJ5DQo+PmRyYWZ0LXpoYW5nLWNjYW1wLXJvdXRlLWV4Y2x1c2lvbi1wYXRoa2V5LTAw LnR4dCBmb3JjZXMgY3VzdG9tZXJzIHRvDQo+PmRlcGxveSBhIHN0YXRlZnVsIFBDRSB3aGVyZSBQ Q0UgbmVlZCB0byByZW1lbWJlciBwYXRoIGl0IGhhcyBzZXJ2ZWQgZm9yDQo+PmluZGVmaW5pdGUg dGltZS4gDQo+Pg0KPj5UaGFua3MNCj4+DQo+PlJlZ2FyZHMgLi4uIFphZmFyDQo+Pg0KPj4NCj4+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogImpkcmFrZUBqdW5pcGVyLm5ldCIg PGpkcmFrZUBqdW5pcGVyLm5ldD4NCj4+RGF0ZTogVHVlc2RheSwgT2N0b2JlciA4LCAyMDEzIDY6 MjYgUE0NCj4+VG86IHphbGkgPHphbGlAY2lzY28uY29tPiwgRmF0YWkgWmhhbmcgPHpoYW5nZmF0 YWlAaHVhd2VpLmNvbT4sDQo+PiJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPg0KPj5T dWJqZWN0OiBSRTogW0NDQU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmlj IEVuZ2luZWVyaW5nDQo+PihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJv dXRlcw0KPj4NCj4+PlphZmFyLA0KPj4+DQo+Pj5TbywgaXMgeW91ciBhc3NlcnRpb24gdGhhdCBS RkM1NTUzIGlzIGJyb2tlbj8NCj4+Pg0KPj4+WW91cnMgSXJyZXNwZWN0aXZlbHksDQo+Pj4NCj4+ PkpvaG4NCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBa YWZhciBBbGkgKHphbGkpIFttYWlsdG86emFsaUBjaXNjby5jb21dDQo+Pj4+IFNlbnQ6IFR1ZXNk YXksIE9jdG9iZXIgMDgsIDIwMTMgMTA6NDcgQU0NCj4+Pj4gVG86IEZhdGFpIFpoYW5nOyBKb2hu IEUgRHJha2U7IENDQU1QIChjY2FtcEBpZXRmLm9yZykNCj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FN UF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZw0KPj4+ PiAoUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4+Pj4gDQo+ Pj4+IEZhdGFpIGFuZCBhbGwtDQo+Pj4+IA0KPj4+PiBJbiBhIHN0YXRlbGVzcyBQQ0UsIFBhdGgg S2V5cyBhcmUgdHJhbnNpZW50IGFuZCB0aGV5IGV4cGlyZS4gRm9yIHRoaXMNCj4+Pj5zb2x1dGlv bg0KPj4+PiB0byB3b3JrIHlvdSBuZWVkIGEgUENFIHRoYXQgY2FuIGtlZXAgUGF0aHMgYXNzb2Np YXRlZCB3aXRoIGEgUGF0aCBLZXkNCj4+Pj4gYXJvdW5kIChhIHN0YXRlZnVsIFBDRSB3aGVyZSBz dGF0ZXMgYXJlIHBhdGggY29tcHV0ZWQgYnkgdGhlIFBDRSkuDQo+Pj4+IA0KPj4+PiBUaGFua3MN Cj4+Pj4gDQo+Pj4+IFJlZ2FyZHMgxaAgWmFmYXINCj4+Pj4gDQo+Pj4+IA0KPj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBGYXRhaSBaaGFuZyA8emhhbmdmYXRhaUBo dWF3ZWkuY29tPg0KPj4+PiBEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDgsIDIwMTMgMzowMSBBTQ0K Pj4+PiBUbzogImpkcmFrZUBqdW5pcGVyLm5ldCIgPGpkcmFrZUBqdW5pcGVyLm5ldD4sICJjY2Ft cEBpZXRmLm9yZyINCj4+Pj4gPGNjYW1wQGlldGYub3JnPg0KPj4+PiBTdWJqZWN0OiBSZTogW0ND QU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+ Pj4+IChSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPj4+PiAN Cj4+Pj4gPkhpIEpvaG4sDQo+Pj4+ID4NCj4+Pj4gPlRvdGFsbHkgYWdyZWUgd2l0aCB5b3UsIEkg YWxyZWFkeSBmb3VuZCB0aGVzZSB0d28gZHJhZnRzIGFyZSBtdWNoDQo+Pj4+ID4qdXNlbGVzcyou DQo+Pj4+ID4NCj4+Pj4gPlRoaXMgaXMgd2h5IHdlIG1hZGUgYSBuZXcgZHJhZnQgKHZlcnkgc2lt cGxlIGFuZCB1c2VmdWwpIGFuZCBwdXQgb3VyDQo+Pj4+ID5mZWV0IG9uIHRoZSBncm91bmQuDQo+ Pj4+ID4NCj4+Pj4gDQo+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXpoYW5nLWNjYW1wLXJvdXRlLWV4Y2x1c2lvbi0NCj4+Pj4+cA0KPj4+PiA+YXRoDQo+Pj4+ ID5rZXktMDAudHh0DQo+Pj4+ID4NCj4+Pj4gPg0KPj4+PiA+DQo+Pj4+ID4NCj4+Pj4gPkJlc3Qg UmVnYXJkcw0KPj4+PiA+DQo+Pj4+ID5GYXRhaQ0KPj4+PiA+DQo+Pj4+ID4NCj4+Pj4gPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ID5Gcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+Pj4gQmVoYWxmDQo+Pj4+ID5P ZiBKb2huIEUgRHJha2UNCj4+Pj4gPlNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDAzLCAyMDEzIDI6 MjcgQU0NCj4+Pj4gPlRvOiBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+Pj4+ID5TdWJqZWN0OiBb Q0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcN Cj4+Pj4gPihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPj4+ PiA+DQo+Pj4+ID5ISSwNCj4+Pj4gPg0KPj4+PiA+SSB3YXMgcmVhZGluZzoNCj4+Pj4gDQo+Pj4+ Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1sc3AtZGl2 ZXJzaXR5Lz9pbmNsdWQNCj4+Pj4+ZQ0KPj4+PiA+X3RlIHh0PTEsIGFuZCBJIGhhcHBlbmVkIHRv IG5vdGljZSB0aGUgZm9sbG93aW5nIHBhcmFncmFwaDoNCj4+Pj4gPg0KPj4+PiA+IlRoZSBtZWFu cyBieSB3aGljaCB0aGUgbm9kZSBjYWxjdWxhdGluZyBvciBleHBhbmRpbmcgdGhlIHJvdXRlIG9m DQo+Pj4+dGhlDQo+Pj4+ID5zaWduYWxlZCBMU1AgZGlzY292ZXJzIHRoZSByb3V0ZSBvZiB0aGUg cGF0aChzKSBmcm9tIHdoaWNoIHRoZQ0KPj4+PnNpZ25hbGVkDQo+Pj4+ID5MU1AgIHJlcXVpcmVz IGRpdmVyc2l0eSBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAiDQo+Pj4+ ID4NCj4+Pj4gPkRvZXNuJ3QgdGhpcyBkaXNjbGFpbWVyIGVmZmVjdGl2ZWx5IHJlbmRlciB0aGlz IGRyYWZ0IHVzZWxlc3M/ICBUaGUNCj4+Pj4gPmRyYWZ0IGFsc28gZG9lcyBub3QgZGVmaW5lIGhv dyB0aGUgbm9kZSB0aGF0IGluaXRpYWxseSBzaWduYWxlZCB0aGUNCj4+Pj5MU1ANCj4+Pj4gPmZp bmRzIHRoZSAnbm9kZSBjYWxjdWxhdGluZyBvciBleHBhbmRpbmcgdGhlIHJvdXRlJyAgbm9yIGhv dyBpdA0KPj4+PiA+ZGVsaXZlcnMgdGhlIHNpZ25hbGVkIExTUCByZXF1ZXN0IHRvIHRoYXQgbm9k ZS4NCj4+Pj4gPg0KPj4+PiA+QXMgYW4gYXNpZGUsIHRoZSBkcmFmdDoNCj4+Pj4gDQo+Pj4+Pmh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWxpLWNjYW1wLXJzdnAtdGUtaW5j bHVkZS1yb3V0ZS8NCj4+Pj4+Pw0KPj4+PiA+aW5jDQo+Pj4+ID5sdWRlX3RleHQ9MSB3b3VsZCBi ZSBzdWJqZWN0IHRvIHRoZSBzYW1lIGNyaXRpY2lzbSBleGNlcHQgdGhhdCB0aGUNCj4+Pj4gPmFi b3ZlIHF1b3RlZCBwYXJhZ3JhcGggaXMgcmVwbGFjZWQgd2l0aDoNCj4+Pj4gPg0KPj4+PiA+IlRo ZSBhYm92ZS1tZW50aW9uZWQgdXNlIGNhc2VzIHJlcXVpcmUgcmVsZXZhbnQgcGF0aCBpbmNsdXNp b24NCj4+Pj4gPnJlcXVpcmVtZW50cyB0byBiZSBjb21tdW5pY2F0ZWQgdG8gdGhlIHJvdXRlIGV4 cGFuZGluZyBub2Rlcy4gIFRoaXMNCj4+Pj4gPmRvY3VtZW50IGFkZHJlc3NlcyAgdGhlc2UgcmVx dWlyZW1lbnRzIGFuZCBkZWZpbmVzIHByb2NlZHVyZXMgdG8NCj4+Pj4gPmFkZHJlc3MgdGhlbS4i DQo+Pj4+ID4NCj4+Pj4gPkV2ZW4gdGhvdWdoIHRoaXMgaXMgaGVscGZ1bCwgdGhlIGRyYWZ0IGRv ZXNuJ3QgYWN0dWFsbHkgZGVmaW5lIHRoZXNlDQo+Pj4+ID5wcm9jZWR1cmVzLg0KPj4+PiA+DQo+ Pj4+ID5Zb3VycyBJcnJlc3BlY3RpdmVseSwNCj4+Pj4gPg0KPj4+PiA+Sm9obg0KPj4+PiA+DQo+ Pj4+ID4NCj4+Pj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+ID5DQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4gPkNDQU1QQGlldGYub3JnDQo+Pj4+ ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4+ID5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiA+Q0NBTVAg bWFpbGluZyBsaXN0DQo+Pj4+ID5DQ0FNUEBpZXRmLm9yZw0KPj4+PiA+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+PiANCj4+Pj4gDQo+Pj4NCj4+Pg0KPj4N Cj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Q0NB TVAgbWFpbGluZyBsaXN0DQo+PkNDQU1QQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4NCg0K From zali@cisco.com Wed Oct 9 00:54:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CB221E80D5 for ; Wed, 9 Oct 2013 00:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynuOzozjsL7y for ; Wed, 9 Oct 2013 00:53:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 56B9721F9D17 for ; Wed, 9 Oct 2013 00:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14742; q=dns/txt; s=iport; t=1381305239; x=1382514839; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7RWkPCoAMUiJPF0ikudXMeZd10cq/jPZHeNCsoVloHI=; b=Nld2c3YoIG62izoP+UPaNZPcr9Z36Wk/LZYYFXtkrMlhzOvt7knyoH4F IjApE+twRiNAWXy4W4rFAnGjjTXTIAw6F6FEp5JcSTUdx/AJNRBv275Hh ag1lNNvlBm9Xydv3lDt/BVWvOIvcgt8VXMUF64K3XFBbqQgw/JDMtrV8s s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAAAKVVKtJXHB/2dsb2JhbABagwc4UoMovgoXgQkWdIIlAQEBBAEBASAROgsMBgEGAhEDAQEBAwIGGQQDAgQlCxQBCAgCBAENBQgBEodrDIo5m1ySPIEpjWkCFhsHBoJkNYEEA5kykFKBZoE+gio X-IronPort-AV: E=Sophos;i="4.90,1062,1371081600"; d="scan'208";a="269936377" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2013 07:53:36 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r997rZXd015323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 07:53:35 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 02:53:35 -0500 From: "Zafar Ali (zali)" To: Fatai Zhang , "Zhangxian (Xian)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYAAEh8IgAAGSCKAAAmjooD//745AIAARJEA///HfwCAAEx3gP//xVaA Date: Wed, 9 Oct 2013 07:53:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.247.60] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 07:54:04 -0000 RmF0YWkgYW5kIEpvaG46IA0KDQpJbiBtb3N0IG9mIHRoZSBjYXNlcywgd2hlbiB0aGUgVU5JLU4g bm9kZSBjb21wdXRpbmcgdGhlIHBhdGggaXMgYWxzbw0KaG9zdGluZyB0aGUgUlNWUC1URSBGRUMg YWdhaW5zdCB3aGljaCBleGNsdXNpb24gaXMgcmVxdWlyZWQsIGl0IGtub3dzIHRoZQ0KcGF0aCB0 YWtlIGJ5IHRoZSBvdGhlciBMU1AuIEZvciB0aGUgb3RoZXIgY2FzZXMsIHBsZWFzZSBub3RlIHRo YXQganVzdA0KYmVjYXVzZSBvcHRpY2FsIG5ldHdvcmsgaXMgcnVubmluZyBHTVBMUyBVTkkgZm9y IGNsaWVudCBpbnRlcmZhY2UgZG9lcyBub3QNCm1lYW4gdGhhdCBpdCBpcyBydW5uaW5nIFJTVlAt VEUgZm9yIHRoZSBvcHRpY2FsIHRyYWlsIG1hbmFnZW1lbnQuIEUuZy4sDQpvcHRpY2FsIHRyYWls IG1hbmFnZW1lbnQgY2FuIHN0aWxsIHVzaW5nIGFuIGFscmVhZHkgZGVwbG95ZWQgcHJvcHJpZXRh cnkNCm1lY2hhbmlzbXMgb3IgYW4gTk1TIGJhc2VkIHNjaGVtZS4gVGhlIGRyYWZ0IGlzIGFkZHJl c3Npbmcgc2NoZW1lcyB0aGF0DQphcmUgY2FwYWJsZSBvZiB0aGlzIGZ1bmN0aW9uYWxpdHkuDQoN CkZhdGFpOiANCg0KTmVlZCBmb3IgdGhlIHBhdGgga2V5cyBpbiBYUk8gc2NoZW1lIHJlcXVpcmlu ZyBQQ0UgdG8gcmVtZW1iZXIgdGhlIChwYXRoDQprZXksIHBhdGggaW5mbykgInN0YXRlcyIgZm9y ICJpbmRlZmluaXRlIiB0aW1lIGFuZCBzY2FsaW5nIHJlc3RyaWN0aW9uIG9mDQp0aGUgc29sdXRp b24gSSBtZW50aW9uZWQgaW4gbXkgZW1haWwgaXMgbm90IGEgbWF0dGVyIG9mIHRlcm1pbm9sb2d5 IG9yDQpwaGlsb3NvcGh5LiBZb3UgYXJlIGludHJvZHVjaW5nIG5ldyBwZXJtYW5lbnQgc3RhdGVz IGF0IFBDRS4NCg0KVGhhbmtzDQoNClJlZ2FyZHMg4oCmIFphZmFyDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEZhdGFpIFpoYW5nIDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+ DQpEYXRlOiBXZWRuZXNkYXksIE9jdG9iZXIgOSwgMjAxMyAzOjIzIEFNDQpUbzogemFsaSA8emFs aUBjaXNjby5jb20+LCAiWmhhbmd4aWFuIChYaWFuKSIgPHpoYW5nLnhpYW5AaHVhd2VpLmNvbT4s DQoiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4NCkNjOiAiamRyYWtlQGp1bmlwZXIu bmV0IiA8amRyYWtlQGp1bmlwZXIubmV0Pg0KU3ViamVjdDogUkU6IFtDQ0FNUF0gUmVzb3VyY2Ug UmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZw0KKFJTVlAtVEUpIFBhdGgg RGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVzDQoNCj5IaSBaYWZhciwNCj4NCj5UaGlzIGlz IG9wZXJhdG9yJ3MgcG9saWN5LCBhbmQgdGltZXIgY2FuIGhlbHAgYXMgd2hhdCBSRkM1NTIwIGFu ZCBSRkMNCj41NTUzIGRlZmluZWQuDQo+DQo+SSByZWFsbHkgZG9uJ3Qgd2FudCB0byBzcGVuZCBt eSB0aW1lIG9uIGRpc2N1c3NpbmcgdGhlIHRlcm1pbm9sb2d5IG9yDQo+cGhpbG9zb3BoeSAob24g d2hhdCBpcyBzdGF0ZWZ1bCBQQ0UpLCBidXQgSSBtb3JlIGNhcmUgYWJvdXQgaG93IHlvdXINCj5k cmFmdCBjYW4gd29yay4gDQo+DQo+Q291bGQgeW91IGNsYXJpZnkgSm9obidzIHF1ZXN0aW9uIGJl bG93IChpdCBpcyBhbHNvIG15IHF1ZXN0aW9uKT8NCj5Ib3cgZG9lcyB5b3VyIGRyYWZ0IHdvcmsg aW4gdGhlIHJlYWwgaW1wbGVtZW50YXRpb24/IFdobyBjYW4gaW50ZXJwcmV0DQo+dGhlICpMU1Ag aWRlbnRpZmllciogKDVwbGUpIGRlZmluZWQgaW4geW91ciBkcmFmdD8NCj4NCj49PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCj4+PiJUaGUgbWVhbnMgYnkgd2hpY2ggdGhlIG5vZGUgY2FsY3VsYXRpbmcgb3IgZXhw YW5kaW5nIHRoZSByb3V0ZSBvZiB0aGUNCj4+PnNpZ25hbGVkIExTUCBkaXNjb3ZlcnMgdGhlIHJv dXRlIG9mIHRoZSBwYXRoKHMpIGZyb20gd2hpY2ggdGhlIHNpZ25hbGVkDQo+Pj5MU1AgcmVxdWly ZXMgZGl2ZXJzaXR5IGFyZSBiZXlvbmQgdGhlIHNjb3BlDQo+Pj5vZiB0aGlzIGRvY3VtZW50LiAi DQo+DQo+Pj5Eb2Vzbid0IHRoaXMgZGlzY2xhaW1lciBlZmZlY3RpdmVseSByZW5kZXIgdGhpcyBk cmFmdCB1c2VsZXNzPyBUaGUNCj4+PmRyYWZ0IGFsc28gZG9lcyBub3QgZGVmaW5lIGhvdyB0aGUg bm9kZSB0aGF0IGluaXRpYWxseSBzaWduYWxlZCB0aGUgTFNQDQo+Pj5maW5kcyB0aGUgJ25vZGUg Y2FsY3VsYXRpbmcgb3IgZXhwYW5kaW5nIHRoZSByb3V0ZScNCj4+Pm5vciBob3cgaXQgZGVsaXZl cnMgdGhlIHNpZ25hbGVkIExTUCByZXF1ZXN0IHRvIHRoYXQgbm9kZS4NCj4NCj4NCj4NCj5CZXN0 IFJlZ2FyZHMNCj4NCj5GYXRhaQ0KPg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogWmFmYXIgQWxpICh6YWxpKSBbbWFpbHRvOnphbGlAY2lzY28uY29tXQ0KPlNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAwOSwgMjAxMyAyOjUwIFBNDQo+VG86IEZhdGFpIFpoYW5nOyBaaGFu Z3hpYW4gKFhpYW4pOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+Q2M6IEpvaG4gRSBEcmFrZQ0K PlN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZm aWMgRW5naW5lZXJpbmcNCj4oUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBS b3V0ZXMNCj4NCj5GYXRhaS0gDQo+DQo+SW4gUkZDIDU1MjAgYW5kIFJGQzU1NTMsIFBDRSBpcyBv bmx5IGV4cGVjdGVkIHRvIGtlZXAgdGhlIChwYXRoIGtleSwgUGF0aA0KPmluZm8pIHN0YXRlIGZv ciBvbmx5IGEgc2hvcnQgYW1vdW50IG9mIHRpbWUuIFRpbWUgdGhhdCBpcyByZXF1aXJlZCB0bw0K PnNpZ25hbCBhbiBMU1AgcHJvdmlkZXMgYW4gdXBwZXIgYm91bmQgb24gdGhlIHRpbWUgdGhlIChw YXRoIGtleSwgUGF0aA0KPmluZm8pIHN0YXRlIG5lZWRzIHRvIGJlIHN0b3JlZCBieSB0aGUgUENF LiBUaGUgUkZDNTUyMCBzcGVjaWZpY2FsbHkgdGFsa3MNCj5hYm91dCBwYXRoIGtleSBleHBpcmF0 aW9uIGFuZCBpcyBwdXJnZWQuIDE2IGJpdCBwYXRoIGtleXMgYXJlIHVzZWQgYXMNCj5yZXVzZSBv ZiB0aGUgcGF0aCBrZXkgaXMgYXNzdW1lZC4NCj4NCj5JbiB5b3VyIGRyYWZ0IHRoZSBQQ0UgbmVl ZHMgdG8gcmVtZW1iZXIgdGhlIChwYXRoIGtleSwgcGF0aCBpbmZvKSAic3RhdGVzIg0KPmZvciAi aW5kZWZpbml0ZSIgdGltZS4gSWYgeW91IGxpa2Ugd2UgY2FsbCBzdWNoIFBDRSAicGF0aC1zdGF0 ZWZ1bCBQQ0UiDQo+YnV0IGl0IGlzIHN0YXRlZnVsLiBBbHNvLCB0aGUgc29sdXRpb24gaXMgbm90 IHNjYWxhYmxlIGFzIGEgUENFIGNhbiBvbmx5DQo+aG9sZCA2NEsgb2YgKHBhdGgga2V5LCBwYXRo IGluZm8pIHN0YXRlcy4NCj4NCj5UaGFua3MNCj4NCj5SZWdhcmRzIOKApiBaYWZhcg0KPg0KPg0K Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogRmF0YWkgWmhhbmcgPHpoYW5nZmF0 YWlAaHVhd2VpLmNvbT4NCj5EYXRlOiBXZWRuZXNkYXksIE9jdG9iZXIgOSwgMjAxMyAyOjEyIEFN DQo+VG86IHphbGkgPHphbGlAY2lzY28uY29tPiwgIlpoYW5neGlhbiAoWGlhbikiIDx6aGFuZy54 aWFuQGh1YXdlaS5jb20+LA0KPiJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPg0KPkNj OiAiamRyYWtlQGp1bmlwZXIubmV0IiA8amRyYWtlQGp1bmlwZXIubmV0Pg0KPlN1YmplY3Q6IFJF OiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJp bmcNCj4oUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4NCj4+ SGkgWmFmYXIsDQo+Pg0KPj5SZWFsbHkgaW50ZXJlc3RpbmcgZm9yIHlvdXIgYXNzZXJ0aW9uLg0K Pj4NCj4+RGlkIHlvdSBtZWFuIHRoYXQgUkZDIDU1MjAgaXMgc3BlY2lmaWMgZm9yIHN0YXRlZnVs IFBDRT8NCj4+DQo+PkluIGFkZGl0b24sIHBsZWFzZSBsb29rIGF0ICJDb250cm9sIG9mIEZ1bmN0 aW9uIHRocm91Z2ggQ29uZmlndXJhdGlvbiBhbmQNCj4+UG9saWN5IiBvZiBSRkMgNTUyMCBhbmQg UkZDNTU1My4NCj4+DQo+Pg0KPj5CZXN0IFJlZ2FyZHMNCj4+DQo+PkZhdGFpDQo+Pg0KPj4NCj4+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogWmFmYXIgQWxpICh6YWxpKSBbbWFp bHRvOnphbGlAY2lzY28uY29tXQ0KPj5TZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDksIDIwMTMg MjowNyBQTQ0KPj5UbzogWmhhbmd4aWFuIChYaWFuKTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnKQ0K Pj5DYzogSm9obiBFIERyYWtlOyBGYXRhaSBaaGFuZw0KPj5TdWJqZWN0OiBSZTogW0NDQU1QXSBS ZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+PihSU1ZQ LVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPj4NCj4+SGkgWmhhbmd4 aWFuOiANCj4+DQo+PlN0YXRlIGRvZXMgbm90IGFsd2F5cyBtZWFucyBSU1ZQIFRFIHN0YXRlcyBp biB0aGUgbmV0d29yay4gUENFIChzZXZlcikNCj4+bmVlZHMgdG8gcmVtZW1iZXIgcGF0aCBpbmZv cm1hdGlvbiAocG9zc2libHkgd2l0aCBvdGhlciBwYXRoIGF0dHJpYnV0ZXMpDQo+Pml0IGNvbXB1 dGVkIGZvciBpbmRlZmluaXRlIHRpbWUuIFRoZXNlIGFyZSBzdGF0ZXMgdGhhdCBQQ0UgbmVlZHMg dG8NCj4+cmVtZW1iZXIuIEhlbmNlLCBzdGF0ZWZ1bCBQQ0UuDQo+Pg0KPj5UaGFua3MNCj4+DQo+ PlJlZ2FyZHMg4oCmIFphZmFyDQo+Pg0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+RnJvbTogIlpoYW5neGlhbiAgIChYaWFuKSIgPHpoYW5nLnhpYW5AaHVhd2VpLmNvbT4NCj4+ RGF0ZTogV2VkbmVzZGF5LCBPY3RvYmVyIDksIDIwMTMgMjowMiBBTQ0KPj5UbzogemFsaSA8emFs aUBjaXNjby5jb20+LCAiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4NCj4+Q2M6ICJq ZHJha2VAanVuaXBlci5uZXQiIDxqZHJha2VAanVuaXBlci5uZXQ+LCBGYXRhaSBaaGFuZw0KPj48 emhhbmdmYXRhaUBodWF3ZWkuY29tPg0KPj5TdWJqZWN0OiBSRTogW0NDQU1QXSBSZXNvdXJjZSBS ZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+PihSU1ZQLVRFKSBQYXRo IERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPj4NCj4+PkhpLCBaYWZhciwgDQo+Pj4g ICAgDQo+Pj4gICAgVGhhbmsgeW91IGZvciBzaGFyaW5nIHRoZSB0aG91Z2h0cy4gQnV0IEkgY2Fu bm90IGFncmVlIHdpdGggd2hhdCB5b3UNCj4+PnNhaWQgYmVsb3cuIA0KPj4+DQo+Pj4gICAgUGF0 aCBrZXkgc29sdXRpb24gZG9lcyBub3QgbmVjZXNzYXJpbHkgbmVlZCB0aGUgcHJlc2VuY2Ugb2Yg YQ0KPj4+c3RhdGVmdWwgUENFLiBTaW1pbGFybHkgd2l0aCBSRkM1NTUzLCB0aGUgcGF0aCBrZXkg b3duZXIgbmVlZHMgdG8gcmV0YWluDQo+Pj50aGlzIGluZm9ybWF0aW9uIHNvIHRoYXQgSSBjYW4g aW50ZXJwcmV0IHdoZW4gdXNlZCBhdCBhIGxhdGVyIHRpbWUuDQo+Pj5SZXRhaW5pbmcgc3VjaCBp bmZvcm1hdGlvbiBkb2VzIG5vdCBlcXVhbCB0byBhIHN0YXRlZnVsIFBDRSB3aGljaCBuZWVkcw0K Pj4+dG8ga25vdyB0aGUgTFNQIHN0YXRlcyBvZiB0aGUgd2hvbGUgbmV0d29yayBpdCBzZXJ2ZXMu DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj5YaWFuDQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj5Gcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj5PZg0KPj4+WmFmYXIgQWxpICh6YWxpKQ0KPj4+ U2VudDogMjAxM+W5tDEw5pyIOeaXpSAxMzoyNg0KPj4+VG86IEpvaG4gRSBEcmFrZTsgRmF0YWkg Wmhhbmc7IENDQU1QIChjY2FtcEBpZXRmLm9yZykNCj4+PlN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJl c291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcNCj4+PihSU1ZQ LVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPj4+DQo+Pj5IaSBKb2hu OiANCj4+Pg0KPj4+Tm8sIFJGQyA1NTIwLyBSRkM1NTMzIGFyZSBmaW5lLiBUaGUgaXNzdWUgaXMg dGhhdCBzb2x1dGlvbiBwcm9wb3NlZCBieQ0KPj4+ZHJhZnQtemhhbmctY2NhbXAtcm91dGUtZXhj bHVzaW9uLXBhdGhrZXktMDAudHh0IGZvcmNlcyBjdXN0b21lcnMgdG8NCj4+PmRlcGxveSBhIHN0 YXRlZnVsIFBDRSB3aGVyZSBQQ0UgbmVlZCB0byByZW1lbWJlciBwYXRoIGl0IGhhcyBzZXJ2ZWQg Zm9yDQo+Pj5pbmRlZmluaXRlIHRpbWUuDQo+Pj4NCj4+PlRoYW5rcw0KPj4+DQo+Pj5SZWdhcmRz IC4uLiBaYWZhcg0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5G cm9tOiAiamRyYWtlQGp1bmlwZXIubmV0IiA8amRyYWtlQGp1bmlwZXIubmV0Pg0KPj4+RGF0ZTog VHVlc2RheSwgT2N0b2JlciA4LCAyMDEzIDY6MjYgUE0NCj4+PlRvOiB6YWxpIDx6YWxpQGNpc2Nv LmNvbT4sIEZhdGFpIFpoYW5nIDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+LA0KPj4+ImNjYW1wQGll dGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+DQo+Pj5TdWJqZWN0OiBSRTogW0NDQU1QXSBSZXNvdXJj ZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+Pj4oUlNWUC1URSkg UGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4+Pg0KPj4+PlphZmFyLA0KPj4+ Pg0KPj4+PlNvLCBpcyB5b3VyIGFzc2VydGlvbiB0aGF0IFJGQzU1NTMgaXMgYnJva2VuPw0KPj4+ Pg0KPj4+PllvdXJzIElycmVzcGVjdGl2ZWx5LA0KPj4+Pg0KPj4+PkpvaG4NCj4+Pj4NCj4+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBaYWZhciBBbGkgKHphbGkp IFttYWlsdG86emFsaUBjaXNjby5jb21dDQo+Pj4+PiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDA4 LCAyMDEzIDEwOjQ3IEFNDQo+Pj4+PiBUbzogRmF0YWkgWmhhbmc7IEpvaG4gRSBEcmFrZTsgQ0NB TVAgKGNjYW1wQGlldGYub3JnKQ0KPj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gUmVzb3VyY2Ug UmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYw0KPj4+Pj5FbmdpbmVlcmluZw0KPj4+Pj4gKFJT VlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVzDQo+Pj4+PiANCj4+Pj4+ IEZhdGFpIGFuZCBhbGwtDQo+Pj4+PiANCj4+Pj4+IEluIGEgc3RhdGVsZXNzIFBDRSwgUGF0aCBL ZXlzIGFyZSB0cmFuc2llbnQgYW5kIHRoZXkgZXhwaXJlLiBGb3IgdGhpcw0KPj4+Pj5zb2x1dGlv bg0KPj4+Pj4gdG8gd29yayB5b3UgbmVlZCBhIFBDRSB0aGF0IGNhbiBrZWVwIFBhdGhzIGFzc29j aWF0ZWQgd2l0aCBhIFBhdGggS2V5DQo+Pj4+PiBhcm91bmQgKGEgc3RhdGVmdWwgUENFIHdoZXJl IHN0YXRlcyBhcmUgcGF0aCBjb21wdXRlZCBieSB0aGUgUENFKS4NCj4+Pj4+IA0KPj4+Pj4gVGhh bmtzDQo+Pj4+PiANCj4+Pj4+IFJlZ2FyZHMgxaAgWmFmYXINCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogRmF0YWkgWmhhbmcgPHpo YW5nZmF0YWlAaHVhd2VpLmNvbT4NCj4+Pj4+IERhdGU6IFR1ZXNkYXksIE9jdG9iZXIgOCwgMjAx MyAzOjAxIEFNDQo+Pj4+PiBUbzogImpkcmFrZUBqdW5pcGVyLm5ldCIgPGpkcmFrZUBqdW5pcGVy Lm5ldD4sICJjY2FtcEBpZXRmLm9yZyINCj4+Pj4+IDxjY2FtcEBpZXRmLm9yZz4NCj4+Pj4+IFN1 YmplY3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMN Cj4+Pj4+RW5naW5lZXJpbmcNCj4+Pj4+IChSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBF eGNsdWRlIFJvdXRlcw0KPj4+Pj4gDQo+Pj4+PiA+SGkgSm9obiwNCj4+Pj4+ID4NCj4+Pj4+ID5U b3RhbGx5IGFncmVlIHdpdGggeW91LCBJIGFscmVhZHkgZm91bmQgdGhlc2UgdHdvIGRyYWZ0cyBh cmUgbXVjaA0KPj4+Pj4gPip1c2VsZXNzKi4NCj4+Pj4+ID4NCj4+Pj4+ID5UaGlzIGlzIHdoeSB3 ZSBtYWRlIGEgbmV3IGRyYWZ0ICh2ZXJ5IHNpbXBsZSBhbmQgdXNlZnVsKSBhbmQgcHV0IG91cg0K Pj4+Pj4gPmZlZXQgb24gdGhlIGdyb3VuZC4NCj4+Pj4+ID4NCj4+Pj4+IA0KPj4+Pj4+aHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctY2NhbXAtcm91dGUtZXhj bHVzaW9uDQo+Pj4+Pj4tDQo+Pj4+Pj5wDQo+Pj4+PiA+YXRoDQo+Pj4+PiA+a2V5LTAwLnR4dA0K Pj4+Pj4gPg0KPj4+Pj4gPg0KPj4+Pj4gPg0KPj4+Pj4gPg0KPj4+Pj4gPkJlc3QgUmVnYXJkcw0K Pj4+Pj4gPg0KPj4+Pj4gPkZhdGFpDQo+Pj4+PiA+DQo+Pj4+PiA+DQo+Pj4+PiA+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+ID5Gcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+Pj4+IEJlaGFsZg0KPj4+Pj4gPk9m IEpvaG4gRSBEcmFrZQ0KPj4+Pj4gPlNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDAzLCAyMDEzIDI6 MjcgQU0NCj4+Pj4+ID5UbzogQ0NBTVAgKGNjYW1wQGlldGYub3JnKQ0KPj4+Pj4gPlN1YmplY3Q6 IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmlu Zw0KPj4+Pj4gPihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0K Pj4+Pj4gPg0KPj4+Pj4gPkhJLA0KPj4+Pj4gPg0KPj4+Pj4gPkkgd2FzIHJlYWRpbmc6DQo+Pj4+ PiANCj4+Pj4+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2Ft cC1sc3AtZGl2ZXJzaXR5Lz9pbmNsdQ0KPj4+Pj4+ZA0KPj4+Pj4+ZQ0KPj4+Pj4gPl90ZSB4dD0x LCBhbmQgSSBoYXBwZW5lZCB0byBub3RpY2UgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGg6DQo+Pj4+ PiA+DQo+Pj4+PiA+IlRoZSBtZWFucyBieSB3aGljaCB0aGUgbm9kZSBjYWxjdWxhdGluZyBvciBl eHBhbmRpbmcgdGhlIHJvdXRlIG9mDQo+Pj4+PnRoZQ0KPj4+Pj4gPnNpZ25hbGVkIExTUCBkaXNj b3ZlcnMgdGhlIHJvdXRlIG9mIHRoZSBwYXRoKHMpIGZyb20gd2hpY2ggdGhlDQo+Pj4+PnNpZ25h bGVkDQo+Pj4+PiA+TFNQICByZXF1aXJlcyBkaXZlcnNpdHkgYXJlIGJleW9uZCB0aGUgc2NvcGUg b2YgdGhpcyBkb2N1bWVudC4gIg0KPj4+Pj4gPg0KPj4+Pj4gPkRvZXNuJ3QgdGhpcyBkaXNjbGFp bWVyIGVmZmVjdGl2ZWx5IHJlbmRlciB0aGlzIGRyYWZ0IHVzZWxlc3M/ICBUaGUNCj4+Pj4+ID5k cmFmdCBhbHNvIGRvZXMgbm90IGRlZmluZSBob3cgdGhlIG5vZGUgdGhhdCBpbml0aWFsbHkgc2ln bmFsZWQgdGhlDQo+Pj4+PkxTUA0KPj4+Pj4gPmZpbmRzIHRoZSAnbm9kZSBjYWxjdWxhdGluZyBv ciBleHBhbmRpbmcgdGhlIHJvdXRlJyAgbm9yIGhvdyBpdA0KPj4+Pj4gPmRlbGl2ZXJzIHRoZSBz aWduYWxlZCBMU1AgcmVxdWVzdCB0byB0aGF0IG5vZGUuDQo+Pj4+PiA+DQo+Pj4+PiA+QXMgYW4g YXNpZGUsIHRoZSBkcmFmdDoNCj4+Pj4+IA0KPj4+Pj4+aHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1hbGktY2NhbXAtcnN2cC10ZS1pbmNsdWRlLXJvdXRlDQo+Pj4+Pj4vDQo+ Pj4+Pj4/DQo+Pj4+PiA+aW5jDQo+Pj4+PiA+bHVkZV90ZXh0PTEgd291bGQgYmUgc3ViamVjdCB0 byB0aGUgc2FtZSBjcml0aWNpc20gZXhjZXB0IHRoYXQgdGhlDQo+Pj4+PiA+YWJvdmUgcXVvdGVk IHBhcmFncmFwaCBpcyByZXBsYWNlZCB3aXRoOg0KPj4+Pj4gPg0KPj4+Pj4gPiJUaGUgYWJvdmUt bWVudGlvbmVkIHVzZSBjYXNlcyByZXF1aXJlIHJlbGV2YW50IHBhdGggaW5jbHVzaW9uDQo+Pj4+ PiA+cmVxdWlyZW1lbnRzIHRvIGJlIGNvbW11bmljYXRlZCB0byB0aGUgcm91dGUgZXhwYW5kaW5n IG5vZGVzLiAgVGhpcw0KPj4+Pj4gPmRvY3VtZW50IGFkZHJlc3NlcyAgdGhlc2UgcmVxdWlyZW1l bnRzIGFuZCBkZWZpbmVzIHByb2NlZHVyZXMgdG8NCj4+Pj4+ID5hZGRyZXNzIHRoZW0uIg0KPj4+ Pj4gPg0KPj4+Pj4gPkV2ZW4gdGhvdWdoIHRoaXMgaXMgaGVscGZ1bCwgdGhlIGRyYWZ0IGRvZXNu J3QgYWN0dWFsbHkgZGVmaW5lIHRoZXNlDQo+Pj4+PiA+cHJvY2VkdXJlcy4NCj4+Pj4+ID4NCj4+ Pj4+ID5Zb3VycyBJcnJlc3BlY3RpdmVseSwNCj4+Pj4+ID4NCj4+Pj4+ID5Kb2huDQo+Pj4+PiA+ DQo+Pj4+PiA+DQo+Pj4+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4+ID5DQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4+ID5DQ0FNUEBpZXRmLm9y Zw0KPj4+Pj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+ Pj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4gPkNDQU1QIG1haWxpbmcgbGlzdA0KPj4+Pj4gPkNDQU1QQGlldGYub3JnDQo+Pj4+PiA+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pj4gDQo+Pj4+PiAN Cj4+Pj4NCj4+Pj4NCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+PkNDQU1QIG1haWxpbmcgbGlzdA0KPj4+Q0NBTVBAaWV0Zi5vcmcNCj4+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+DQo+DQoNCg== From daniele.ceccarelli@ericsson.com Wed Oct 9 08:14:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82DF21E8096 for ; Wed, 9 Oct 2013 08:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=1.216, BAYES_00=-2.599, HELO_EQ_SE=0.35, HS_INDEX_PARAM=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 dKfGBVbGCZDK for ; Wed, 9 Oct 2013 08:13:58 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CB45521E8138 for ; Wed, 9 Oct 2013 08:13:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-b0-525572b02ec3 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 32.62.16099.0B275525; Wed, 9 Oct 2013 17:13:52 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Wed, 9 Oct 2013 17:13:52 +0200 From: Daniele Ceccarelli To: "Zafar Ali (zali)" , Fatai Zhang , "Zhangxian (Xian)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYAAA3PwgAAOqg0AAAFBt4AAACltgAAAL9UAAAFRz4AAAS0BgAABDKsAABLiYRA= Date: Wed, 9 Oct 2013 15:13:51 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481627D6@ESESSMB301.ericsson.se> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvre6GotAgg4u7TS2ezLnBYvF6x1d2 i8XbOlks+prPszqweEz5vZHVo+XIW1aPJUt+MgUwR3HZpKTmZJalFunbJXBlfHl2ialgQh9j xZZDx5gbGPd0MXYxcnJICJhI3D37E8oWk7hwbz0biC0kcJhRom2LRBcjF5C9mFFi5vyXQEUc HGwCVhJPDvmAxEUEljNKLP95iR2kQVigTOLR6qtgzSIC5RIzfm9jhLDLJL7df8ICYrMIqEi0 nG8As3kFvCUWLD3JDLFgBqPE1MmHwZo5BXwlfv1tBmtmFJCVmLB7EZjNLCAucevJfCaISwUk luw5zwxhi0q8fPyPFcJWlPj4ah/YocwCmhLrd+lDtCpKTOl+yA6xV1Di5MwnLBMYRWchmToL oWMWko5ZSDoWMLKsYmTPTczMSS833MQIjJWDW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhi1zj0NbZeTPv3N/tDuzEiLGyddHVVePeOvv69xjzczSPGf yTLz5Nhw77+Mk6LX6VTX1WpVJid8ShBLvFUhaSq+r9v78wSjANZpH4QdC7fdfXTm5UVnaXaB e5WPHSvPrEvwuvD37vriRGuGpksc08svn/i9/tdUs09/befpln6+spih9cWZjRFKLMUZiYZa zEXFiQB142LOYwIAAA== Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:14:03 -0000 SGkgWmFmYXIsDQoNClRoYXQncyBvbmUgb2YgdGhlIHJlYXNvbnMgd2h5IEkgcHJlZmVyIHRoZSBw YXRoIGtleSBhcHByb2FjaCB3aXRoIHRoZSBwYXRoIHN0YXRlZnVsIFBDRSAob3Igd2hhdGV2ZXIg d2UgY2FsbCBpdCwgSSBkb24ndCBjYXJlKS4NCkluIHRoaXMgZXhhbXBsZSwgd2hlcmUgUiBhcmUg dGhlIHJvdXRlcnMgYW5kIE8gdGhlIG9wdGljYWwgbm9kZXMgaG93IGRvZXMgdGhlIExTUCBkaXZl cnNpdHkgbWVjaGFuaXNtcyB3b3JrPw0KDQogICAgICAgICAgICAgICAgICAgVU5JICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFVOSQ0KUjEgLS0tIFIyIC0tLS0tLS1PMS0tLS1PMi0t LS1PMy0tLS0tUjQtLS0tUjUNCiAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIC8NCiAgICAgICAgXCBSMyAtLS0tLS0t TzQtLS0tLU81LS0tLU82LS0tLS1SNiAvDQogICAgICAgICAgICAgICAgICBVTkkgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFVOSQ0KDQpJbiB0aGUgY2FzZSBvZiBMU1AgZGl2ZXJz aXR5IHRoZSBvbmx5IHdheSBpIHVuZGVyc3RhbmQgdGhpbmdzIGNhbiB3b3JrIGlzLg0KMS4gSSBz ZXR1cCBhIHdvcmtpbmcgcGF0aCBSMS1SMi1PMS1PMi1PMy1SNC1SNS4gDQoyLiBSMSBzb21laG93 IGNvbGxlY3RzIHRoZSA1cGxlIG9mIExTUCBPMS1PMi1PMw0KMy4gUjEgd2FudHMgdG8gc2V0dXAg YSBwcm90ZWN0aW9uIHBhdGggaW4gZGl2ZXJzaXR5IGFuZCBhc2tzIFIzIHRvIGFzayBPNCBmb3Ig YSBwYXRoIGluIGRpdmVyc2l0eSByZSB0aGUgNXBsZSBvZiBPMS0wMi0wMw0KNC4gaG93IGNhbiBP NCByZXNvbHZlIHRoYXQgdGhlIG5vZGVzL2xpbmsgY29ycmVzcG9uZGluZyB0byB0aGUgNXBsZSBh cmUgTzEtTzItTzM/IEl0IGlzIG5vdCBwb3NzaWJsZS4gVGhlIG9ubHkgd2F5IGlzIGEgaG9wIGJ5 IGhvcCBjaGVjayB3aXRoIGNyYW5ja2JhY2sgaWYgdGhlIHNpZ25hbGluZyBnZW5lcmF0ZWQgZnJv bSBPNCBnb2VzIHRocm91Z2ggYSBub2RlIGFtb25nIE8xLU8yLU8zLg0KDQpJZiB0aGVyZSBhcmUg bm8gUlNWUCBzdGF0ZXMgaW4gdGhlIG5vZGVzLCBob3cgY2FuIGl0IHdvcms/IFRoZSBwYXRoIGtl eSBzaG91bGQgd29yayBpbiB0aGF0IGNhc2UuDQoNClBsZWFzZSBjb3JyZWN0IGFueSBtaXN0YWtl IGluIHRoZSBwcm9jZWR1cmUgSSB3cm90ZSBhYm92ZSAoYnR3IGEgcHJvY2VkdXJlLCBldmVuIGlu IGV4YW1wbGUgb3IgYXBwZW5kaXgsIGluIHlvdXIgZHJhZnQgY291bGQgYmUgaGVscGZ1bCkNCg0K VGhhbmtzDQpEYW5pZWxlDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmDQo+IE9mIFphZmFyIEFsaSAoemFsaSkNCj4gU2VudDogbWVyY29sZWTDrCA5IG90 dG9icmUgMjAxMyAwOTo1NA0KPiBUbzogRmF0YWkgWmhhbmc7IFpoYW5neGlhbiAoWGlhbik7IEND QU1QIChjY2FtcEBpZXRmLm9yZykNCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVz ZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZw0KPiAoUlNWUC1URSkgUGF0aCBE aXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4gDQo+IEZhdGFpIGFuZCBKb2huOg0KPiAN Cj4gSW4gbW9zdCBvZiB0aGUgY2FzZXMsIHdoZW4gdGhlIFVOSS1OIG5vZGUgY29tcHV0aW5nIHRo ZSBwYXRoIGlzIGFsc28NCj4gaG9zdGluZyB0aGUgUlNWUC1URSBGRUMgYWdhaW5zdCB3aGljaCBl eGNsdXNpb24gaXMgcmVxdWlyZWQsIGl0IGtub3dzIHRoZQ0KPiBwYXRoIHRha2UgYnkgdGhlIG90 aGVyIExTUC4gRm9yIHRoZSBvdGhlciBjYXNlcywgcGxlYXNlIG5vdGUgdGhhdCBqdXN0DQo+IGJl Y2F1c2Ugb3B0aWNhbCBuZXR3b3JrIGlzIHJ1bm5pbmcgR01QTFMgVU5JIGZvciBjbGllbnQgaW50 ZXJmYWNlIGRvZXMgbm90DQo+IG1lYW4gdGhhdCBpdCBpcyBydW5uaW5nIFJTVlAtVEUgZm9yIHRo ZSBvcHRpY2FsIHRyYWlsIG1hbmFnZW1lbnQuIEUuZy4sIG9wdGljYWwNCj4gdHJhaWwgbWFuYWdl bWVudCBjYW4gc3RpbGwgdXNpbmcgYW4gYWxyZWFkeSBkZXBsb3llZCBwcm9wcmlldGFyeSBtZWNo YW5pc21zDQo+IG9yIGFuIE5NUyBiYXNlZCBzY2hlbWUuIFRoZSBkcmFmdCBpcyBhZGRyZXNzaW5n IHNjaGVtZXMgdGhhdCBhcmUgY2FwYWJsZQ0KPiBvZiB0aGlzIGZ1bmN0aW9uYWxpdHkuDQo+IA0K PiBGYXRhaToNCj4gDQo+IE5lZWQgZm9yIHRoZSBwYXRoIGtleXMgaW4gWFJPIHNjaGVtZSByZXF1 aXJpbmcgUENFIHRvIHJlbWVtYmVyIHRoZSAocGF0aA0KPiBrZXksIHBhdGggaW5mbykgInN0YXRl cyIgZm9yICJpbmRlZmluaXRlIiB0aW1lIGFuZCBzY2FsaW5nIHJlc3RyaWN0aW9uIG9mIHRoZQ0K PiBzb2x1dGlvbiBJIG1lbnRpb25lZCBpbiBteSBlbWFpbCBpcyBub3QgYSBtYXR0ZXIgb2YgdGVy bWlub2xvZ3kgb3INCj4gcGhpbG9zb3BoeS4gWW91IGFyZSBpbnRyb2R1Y2luZyBuZXcgcGVybWFu ZW50IHN0YXRlcyBhdCBQQ0UuDQo+IA0KPiBUaGFua3MNCj4gDQo+IFJlZ2FyZHMg4oCmIFphZmFy DQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRmF0YWkgWmhh bmcgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbT4NCj4gRGF0ZTogV2VkbmVzZGF5LCBPY3RvYmVyIDks IDIwMTMgMzoyMyBBTQ0KPiBUbzogemFsaSA8emFsaUBjaXNjby5jb20+LCAiWmhhbmd4aWFuIChY aWFuKSIgPHpoYW5nLnhpYW5AaHVhd2VpLmNvbT4sDQo+ICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1w QGlldGYub3JnPg0KPiBDYzogImpkcmFrZUBqdW5pcGVyLm5ldCIgPGpkcmFrZUBqdW5pcGVyLm5l dD4NCj4gU3ViamVjdDogUkU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wt VHJhZmZpYyBFbmdpbmVlcmluZw0KPiAoUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhj bHVkZSBSb3V0ZXMNCj4gDQo+ID5IaSBaYWZhciwNCj4gPg0KPiA+VGhpcyBpcyBvcGVyYXRvcidz IHBvbGljeSwgYW5kIHRpbWVyIGNhbiBoZWxwIGFzIHdoYXQgUkZDNTUyMCBhbmQgUkZDDQo+ID41 NTUzIGRlZmluZWQuDQo+ID4NCj4gPkkgcmVhbGx5IGRvbid0IHdhbnQgdG8gc3BlbmQgbXkgdGlt ZSBvbiBkaXNjdXNzaW5nIHRoZSB0ZXJtaW5vbG9neSBvcg0KPiA+cGhpbG9zb3BoeSAob24gd2hh dCBpcyBzdGF0ZWZ1bCBQQ0UpLCBidXQgSSBtb3JlIGNhcmUgYWJvdXQgaG93IHlvdXINCj4gPmRy YWZ0IGNhbiB3b3JrLg0KPiA+DQo+ID5Db3VsZCB5b3UgY2xhcmlmeSBKb2huJ3MgcXVlc3Rpb24g YmVsb3cgKGl0IGlzIGFsc28gbXkgcXVlc3Rpb24pPw0KPiA+SG93IGRvZXMgeW91ciBkcmFmdCB3 b3JrIGluIHRoZSByZWFsIGltcGxlbWVudGF0aW9uPyBXaG8gY2FuIGludGVycHJldA0KPiA+dGhl ICpMU1AgaWRlbnRpZmllciogKDVwbGUpIGRlZmluZWQgaW4geW91ciBkcmFmdD8NCj4gPg0KPiA+ PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQo+ID09PT09PT09PT09PT09DQo+ID49PT0gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+Pj4iVGhlIG1lYW5zIGJ5IHdoaWNoIHRoZSBub2Rl IGNhbGN1bGF0aW5nIG9yIGV4cGFuZGluZyB0aGUgcm91dGUgb2YNCj4gPj4+dGhlIHNpZ25hbGVk IExTUCBkaXNjb3ZlcnMgdGhlIHJvdXRlIG9mIHRoZSBwYXRoKHMpIGZyb20gd2hpY2ggdGhlDQo+ ID4+PnNpZ25hbGVkIExTUCByZXF1aXJlcyBkaXZlcnNpdHkgYXJlIGJleW9uZCB0aGUgc2NvcGUg b2YgdGhpcw0KPiA+Pj5kb2N1bWVudC4gIg0KPiA+DQo+ID4+PkRvZXNuJ3QgdGhpcyBkaXNjbGFp bWVyIGVmZmVjdGl2ZWx5IHJlbmRlciB0aGlzIGRyYWZ0IHVzZWxlc3M/IFRoZQ0KPiA+Pj5kcmFm dCBhbHNvIGRvZXMgbm90IGRlZmluZSBob3cgdGhlIG5vZGUgdGhhdCBpbml0aWFsbHkgc2lnbmFs ZWQgdGhlDQo+ID4+PkxTUCBmaW5kcyB0aGUgJ25vZGUgY2FsY3VsYXRpbmcgb3IgZXhwYW5kaW5n IHRoZSByb3V0ZScNCj4gPj4+bm9yIGhvdyBpdCBkZWxpdmVycyB0aGUgc2lnbmFsZWQgTFNQIHJl cXVlc3QgdG8gdGhhdCBub2RlLg0KPiA+DQo+ID4NCj4gPg0KPiA+QmVzdCBSZWdhcmRzDQo+ID4N Cj4gPkZhdGFpDQo+ID4NCj4gPg0KPiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPkZy b206IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxpQGNpc2NvLmNvbV0NCj4gPlNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAwOSwgMjAxMyAyOjUwIFBNDQo+ID5UbzogRmF0YWkgWmhhbmc7IFpo YW5neGlhbiAoWGlhbik7IENDQU1QIChjY2FtcEBpZXRmLm9yZykNCj4gPkNjOiBKb2huIEUgRHJh a2UNCj4gPlN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29s LVRyYWZmaWMgRW5naW5lZXJpbmcNCj4gPihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBF eGNsdWRlIFJvdXRlcw0KPiA+DQo+ID5GYXRhaS0NCj4gPg0KPiA+SW4gUkZDIDU1MjAgYW5kIFJG QzU1NTMsIFBDRSBpcyBvbmx5IGV4cGVjdGVkIHRvIGtlZXAgdGhlIChwYXRoIGtleSwNCj4gPlBh dGgNCj4gPmluZm8pIHN0YXRlIGZvciBvbmx5IGEgc2hvcnQgYW1vdW50IG9mIHRpbWUuIFRpbWUg dGhhdCBpcyByZXF1aXJlZCB0bw0KPiA+c2lnbmFsIGFuIExTUCBwcm92aWRlcyBhbiB1cHBlciBi b3VuZCBvbiB0aGUgdGltZSB0aGUgKHBhdGgga2V5LCBQYXRoDQo+ID5pbmZvKSBzdGF0ZSBuZWVk cyB0byBiZSBzdG9yZWQgYnkgdGhlIFBDRS4gVGhlIFJGQzU1MjAgc3BlY2lmaWNhbGx5DQo+ID50 YWxrcyBhYm91dCBwYXRoIGtleSBleHBpcmF0aW9uIGFuZCBpcyBwdXJnZWQuIDE2IGJpdCBwYXRo IGtleXMgYXJlDQo+ID51c2VkIGFzIHJldXNlIG9mIHRoZSBwYXRoIGtleSBpcyBhc3N1bWVkLg0K PiA+DQo+ID5JbiB5b3VyIGRyYWZ0IHRoZSBQQ0UgbmVlZHMgdG8gcmVtZW1iZXIgdGhlIChwYXRo IGtleSwgcGF0aCBpbmZvKSAic3RhdGVzIg0KPiA+Zm9yICJpbmRlZmluaXRlIiB0aW1lLiBJZiB5 b3UgbGlrZSB3ZSBjYWxsIHN1Y2ggUENFICJwYXRoLXN0YXRlZnVsIFBDRSINCj4gPmJ1dCBpdCBp cyBzdGF0ZWZ1bC4gQWxzbywgdGhlIHNvbHV0aW9uIGlzIG5vdCBzY2FsYWJsZSBhcyBhIFBDRSBj YW4NCj4gPm9ubHkgaG9sZCA2NEsgb2YgKHBhdGgga2V5LCBwYXRoIGluZm8pIHN0YXRlcy4NCj4g Pg0KPiA+VGhhbmtzDQo+ID4NCj4gPlJlZ2FyZHMg4oCmIFphZmFyDQo+ID4NCj4gPg0KPiA+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPkZyb206IEZhdGFpIFpoYW5nIDx6aGFuZ2ZhdGFp QGh1YXdlaS5jb20+DQo+ID5EYXRlOiBXZWRuZXNkYXksIE9jdG9iZXIgOSwgMjAxMyAyOjEyIEFN DQo+ID5UbzogemFsaSA8emFsaUBjaXNjby5jb20+LCAiWmhhbmd4aWFuIChYaWFuKSIgPHpoYW5n LnhpYW5AaHVhd2VpLmNvbT4sDQo+ID4iY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4N Cj4gPkNjOiAiamRyYWtlQGp1bmlwZXIubmV0IiA8amRyYWtlQGp1bmlwZXIubmV0Pg0KPiA+U3Vi amVjdDogUkU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYyBF bmdpbmVlcmluZw0KPiA+KFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91 dGVzDQo+ID4NCj4gPj5IaSBaYWZhciwNCj4gPj4NCj4gPj5SZWFsbHkgaW50ZXJlc3RpbmcgZm9y IHlvdXIgYXNzZXJ0aW9uLg0KPiA+Pg0KPiA+PkRpZCB5b3UgbWVhbiB0aGF0IFJGQyA1NTIwIGlz IHNwZWNpZmljIGZvciBzdGF0ZWZ1bCBQQ0U/DQo+ID4+DQo+ID4+SW4gYWRkaXRvbiwgcGxlYXNl IGxvb2sgYXQgIkNvbnRyb2wgb2YgRnVuY3Rpb24gdGhyb3VnaCBDb25maWd1cmF0aW9uDQo+ID4+ YW5kIFBvbGljeSIgb2YgUkZDIDU1MjAgYW5kIFJGQzU1NTMuDQo+ID4+DQo+ID4+DQo+ID4+QmVz dCBSZWdhcmRzDQo+ID4+DQo+ID4+RmF0YWkNCj4gPj4NCj4gPj4NCj4gPj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+PkZyb206IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxpQGNp c2NvLmNvbV0NCj4gPj5TZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDksIDIwMTMgMjowNyBQTQ0K PiA+PlRvOiBaaGFuZ3hpYW4gKFhpYW4pOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+ID4+Q2M6 IEpvaG4gRSBEcmFrZTsgRmF0YWkgWmhhbmcNCj4gPj5TdWJqZWN0OiBSZTogW0NDQU1QXSBSZXNv dXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+ID4+KFJTVlAt VEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVzDQo+ID4+DQo+ID4+SGkgWmhh bmd4aWFuOg0KPiA+Pg0KPiA+PlN0YXRlIGRvZXMgbm90IGFsd2F5cyBtZWFucyBSU1ZQIFRFIHN0 YXRlcyBpbiB0aGUgbmV0d29yay4gUENFIChzZXZlcikNCj4gPj5uZWVkcyB0byByZW1lbWJlciBw YXRoIGluZm9ybWF0aW9uIChwb3NzaWJseSB3aXRoIG90aGVyIHBhdGgNCj4gPj5hdHRyaWJ1dGVz KSBpdCBjb21wdXRlZCBmb3IgaW5kZWZpbml0ZSB0aW1lLiBUaGVzZSBhcmUgc3RhdGVzIHRoYXQg UENFDQo+ID4+bmVlZHMgdG8gcmVtZW1iZXIuIEhlbmNlLCBzdGF0ZWZ1bCBQQ0UuDQo+ID4+DQo+ ID4+VGhhbmtzDQo+ID4+DQo+ID4+UmVnYXJkcyDigKYgWmFmYXINCj4gPj4NCj4gPj4NCj4gPj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PkZyb206ICJaaGFuZ3hpYW4gICAoWGlhbiki IDx6aGFuZy54aWFuQGh1YXdlaS5jb20+DQo+ID4+RGF0ZTogV2VkbmVzZGF5LCBPY3RvYmVyIDks IDIwMTMgMjowMiBBTQ0KPiA+PlRvOiB6YWxpIDx6YWxpQGNpc2NvLmNvbT4sICJjY2FtcEBpZXRm Lm9yZyIgPGNjYW1wQGlldGYub3JnPg0KPiA+PkNjOiAiamRyYWtlQGp1bmlwZXIubmV0IiA8amRy YWtlQGp1bmlwZXIubmV0PiwgRmF0YWkgWmhhbmcNCj4gPj48emhhbmdmYXRhaUBodWF3ZWkuY29t Pg0KPiA+PlN1YmplY3Q6IFJFOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29s LVRyYWZmaWMgRW5naW5lZXJpbmcNCj4gPj4oUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcg RXhjbHVkZSBSb3V0ZXMNCj4gPj4NCj4gPj4+SGksIFphZmFyLA0KPiA+Pj4NCj4gPj4+ICAgIFRo YW5rIHlvdSBmb3Igc2hhcmluZyB0aGUgdGhvdWdodHMuIEJ1dCBJIGNhbm5vdCBhZ3JlZSB3aXRo IHdoYXQNCj4gPj4+eW91IHNhaWQgYmVsb3cuDQo+ID4+Pg0KPiA+Pj4gICAgUGF0aCBrZXkgc29s dXRpb24gZG9lcyBub3QgbmVjZXNzYXJpbHkgbmVlZCB0aGUgcHJlc2VuY2Ugb2YgYQ0KPiA+Pj5z dGF0ZWZ1bCBQQ0UuIFNpbWlsYXJseSB3aXRoIFJGQzU1NTMsIHRoZSBwYXRoIGtleSBvd25lciBu ZWVkcyB0bw0KPiA+Pj5yZXRhaW4gdGhpcyBpbmZvcm1hdGlvbiBzbyB0aGF0IEkgY2FuIGludGVy cHJldCB3aGVuIHVzZWQgYXQgYSBsYXRlciB0aW1lLg0KPiA+Pj5SZXRhaW5pbmcgc3VjaCBpbmZv cm1hdGlvbiBkb2VzIG5vdCBlcXVhbCB0byBhIHN0YXRlZnVsIFBDRSB3aGljaA0KPiA+Pj5uZWVk cyB0byBrbm93IHRoZSBMU1Agc3RhdGVzIG9mIHRoZSB3aG9sZSBuZXR3b3JrIGl0IHNlcnZlcy4N Cj4gPj4+DQo+ID4+PlJlZ2FyZHMsDQo+ID4+PlhpYW4NCj4gPj4+DQo+ID4+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+PkZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+Pj5CZWhhbGYgT2YgWmFmYXIgQWxpICh6 YWxpKQ0KPiA+Pj5TZW50OiAyMDEz5bm0MTDmnIg55pelIDEzOjI2DQo+ID4+PlRvOiBKb2huIEUg RHJha2U7IEZhdGFpIFpoYW5nOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+ID4+PlN1YmplY3Q6 IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMNCj4gPj4+ RW5naW5lZXJpbmcNCj4gPj4+KFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUg Um91dGVzDQo+ID4+Pg0KPiA+Pj5IaSBKb2huOg0KPiA+Pj4NCj4gPj4+Tm8sIFJGQyA1NTIwLyBS RkM1NTMzIGFyZSBmaW5lLiBUaGUgaXNzdWUgaXMgdGhhdCBzb2x1dGlvbiBwcm9wb3NlZA0KPiA+ Pj5ieSBkcmFmdC16aGFuZy1jY2FtcC1yb3V0ZS1leGNsdXNpb24tcGF0aGtleS0wMC50eHQgZm9y Y2VzIGN1c3RvbWVycw0KPiA+Pj50byBkZXBsb3kgYSBzdGF0ZWZ1bCBQQ0Ugd2hlcmUgUENFIG5l ZWQgdG8gcmVtZW1iZXIgcGF0aCBpdCBoYXMNCj4gPj4+c2VydmVkIGZvciBpbmRlZmluaXRlIHRp bWUuDQo+ID4+Pg0KPiA+Pj5UaGFua3MNCj4gPj4+DQo+ID4+PlJlZ2FyZHMgLi4uIFphZmFyDQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+RnJvbTog ImpkcmFrZUBqdW5pcGVyLm5ldCIgPGpkcmFrZUBqdW5pcGVyLm5ldD4NCj4gPj4+RGF0ZTogVHVl c2RheSwgT2N0b2JlciA4LCAyMDEzIDY6MjYgUE0NCj4gPj4+VG86IHphbGkgPHphbGlAY2lzY28u Y29tPiwgRmF0YWkgWmhhbmcgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbT4sDQo+ID4+PiJjY2FtcEBp ZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPg0KPiA+Pj5TdWJqZWN0OiBSRTogW0NDQU1QXSBSZXNv dXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljDQo+ID4+PkVuZ2luZWVyaW5nDQo+ID4+ PihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPiA+Pj4NCj4g Pj4+PlphZmFyLA0KPiA+Pj4+DQo+ID4+Pj5TbywgaXMgeW91ciBhc3NlcnRpb24gdGhhdCBSRkM1 NTUzIGlzIGJyb2tlbj8NCj4gPj4+Pg0KPiA+Pj4+WW91cnMgSXJyZXNwZWN0aXZlbHksDQo+ID4+ Pj4NCj4gPj4+PkpvaG4NCj4gPj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+Pj4+PiBGcm9tOiBaYWZhciBBbGkgKHphbGkpIFttYWlsdG86emFsaUBjaXNjby5jb21d DQo+ID4+Pj4+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDgsIDIwMTMgMTA6NDcgQU0NCj4gPj4+ Pj4gVG86IEZhdGFpIFpoYW5nOyBKb2huIEUgRHJha2U7IENDQU1QIChjY2FtcEBpZXRmLm9yZykN Cj4gPj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9j b2wtVHJhZmZpYw0KPiA+Pj4+PkVuZ2luZWVyaW5nDQo+ID4+Pj4+IChSU1ZQLVRFKSBQYXRoIERp dmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPiA+Pj4+Pg0KPiA+Pj4+PiBGYXRhaSBhbmQg YWxsLQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBJbiBhIHN0YXRlbGVzcyBQQ0UsIFBhdGggS2V5cyBhcmUg dHJhbnNpZW50IGFuZCB0aGV5IGV4cGlyZS4gRm9yDQo+ID4+Pj4+dGhpcyBzb2x1dGlvbiAgdG8g d29yayB5b3UgbmVlZCBhIFBDRSB0aGF0IGNhbiBrZWVwIFBhdGhzDQo+ID4+Pj4+YXNzb2NpYXRl ZCB3aXRoIGEgUGF0aCBLZXkgIGFyb3VuZCAoYSBzdGF0ZWZ1bCBQQ0Ugd2hlcmUgc3RhdGVzIGFy ZQ0KPiA+Pj4+PnBhdGggY29tcHV0ZWQgYnkgdGhlIFBDRSkuDQo+ID4+Pj4+DQo+ID4+Pj4+IFRo YW5rcw0KPiA+Pj4+Pg0KPiA+Pj4+PiBSZWdhcmRzIMWgIFphZmFyDQo+ID4+Pj4+DQo+ID4+Pj4+ DQo+ID4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+IEZyb206IEZhdGFp IFpoYW5nIDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+DQo+ID4+Pj4+IERhdGU6IFR1ZXNkYXksIE9j dG9iZXIgOCwgMjAxMyAzOjAxIEFNDQo+ID4+Pj4+IFRvOiAiamRyYWtlQGp1bmlwZXIubmV0IiA8 amRyYWtlQGp1bmlwZXIubmV0PiwgImNjYW1wQGlldGYub3JnIg0KPiA+Pj4+PiA8Y2NhbXBAaWV0 Zi5vcmc+DQo+ID4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9u IFByb3RvY29sLVRyYWZmaWMNCj4gPj4+Pj5FbmdpbmVlcmluZw0KPiA+Pj4+PiAoUlNWUC1URSkg UGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4gPj4+Pj4NCj4gPj4+Pj4gPkhp IEpvaG4sDQo+ID4+Pj4+ID4NCj4gPj4+Pj4gPlRvdGFsbHkgYWdyZWUgd2l0aCB5b3UsIEkgYWxy ZWFkeSBmb3VuZCB0aGVzZSB0d28gZHJhZnRzIGFyZSBtdWNoDQo+ID4+Pj4+ID4qdXNlbGVzcyou DQo+ID4+Pj4+ID4NCj4gPj4+Pj4gPlRoaXMgaXMgd2h5IHdlIG1hZGUgYSBuZXcgZHJhZnQgKHZl cnkgc2ltcGxlIGFuZCB1c2VmdWwpIGFuZCBwdXQNCj4gPj4+Pj4gPm91ciBmZWV0IG9uIHRoZSBn cm91bmQuDQo+ID4+Pj4+ID4NCj4gPj4+Pj4NCj4gPj4+Pj4+aHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctY2NhbXAtcm91dGUtDQo+IGV4Y2x1cw0KPiA+Pj4+ Pj5pb24NCj4gPj4+Pj4+LQ0KPiA+Pj4+Pj5wDQo+ID4+Pj4+ID5hdGgNCj4gPj4+Pj4gPmtleS0w MC50eHQNCj4gPj4+Pj4gPg0KPiA+Pj4+PiA+DQo+ID4+Pj4+ID4NCj4gPj4+Pj4gPg0KPiA+Pj4+ PiA+QmVzdCBSZWdhcmRzDQo+ID4+Pj4+ID4NCj4gPj4+Pj4gPkZhdGFpDQo+ID4+Pj4+ID4NCj4g Pj4+Pj4gPg0KPiA+Pj4+PiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4gPkZy b206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3Jn XQ0KPiBPbg0KPiA+Pj4+PiBCZWhhbGYNCj4gPj4+Pj4gPk9mIEpvaG4gRSBEcmFrZQ0KPiA+Pj4+ PiA+U2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDMsIDIwMTMgMjoyNyBBTQ0KPiA+Pj4+PiA+VG86 IENDQU1QIChjY2FtcEBpZXRmLm9yZykNCj4gPj4+Pj4gPlN1YmplY3Q6IFtDQ0FNUF0gUmVzb3Vy Y2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYw0KPiA+Pj4+PiA+RW5naW5lZXJpbmcNCj4g Pj4+Pj4gPihSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPiA+ Pj4+PiA+DQo+ID4+Pj4+ID5ISSwNCj4gPj4+Pj4gPg0KPiA+Pj4+PiA+SSB3YXMgcmVhZGluZzoN Cj4gPj4+Pj4NCj4gPj4+Pj4+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWNjYW1wLWxzcC1kaXZlcnNpdHkvP2luDQo+ID4+Pj4+PmNsdQ0KPiA+Pj4+Pj5kDQo+ID4+ Pj4+PmUNCj4gPj4+Pj4gPl90ZSB4dD0xLCBhbmQgSSBoYXBwZW5lZCB0byBub3RpY2UgdGhlIGZv bGxvd2luZyBwYXJhZ3JhcGg6DQo+ID4+Pj4+ID4NCj4gPj4+Pj4gPiJUaGUgbWVhbnMgYnkgd2hp Y2ggdGhlIG5vZGUgY2FsY3VsYXRpbmcgb3IgZXhwYW5kaW5nIHRoZSByb3V0ZQ0KPiA+Pj4+PiA+ b2YNCj4gPj4+Pj50aGUNCj4gPj4+Pj4gPnNpZ25hbGVkIExTUCBkaXNjb3ZlcnMgdGhlIHJvdXRl IG9mIHRoZSBwYXRoKHMpIGZyb20gd2hpY2ggdGhlDQo+ID4+Pj4+c2lnbmFsZWQNCj4gPj4+Pj4g PkxTUCAgcmVxdWlyZXMgZGl2ZXJzaXR5IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9j dW1lbnQuICINCj4gPj4+Pj4gPg0KPiA+Pj4+PiA+RG9lc24ndCB0aGlzIGRpc2NsYWltZXIgZWZm ZWN0aXZlbHkgcmVuZGVyIHRoaXMgZHJhZnQgdXNlbGVzcz8NCj4gPj4+Pj4gPlRoZSBkcmFmdCBh bHNvIGRvZXMgbm90IGRlZmluZSBob3cgdGhlIG5vZGUgdGhhdCBpbml0aWFsbHkNCj4gPj4+Pj4g PnNpZ25hbGVkIHRoZQ0KPiA+Pj4+PkxTUA0KPiA+Pj4+PiA+ZmluZHMgdGhlICdub2RlIGNhbGN1 bGF0aW5nIG9yIGV4cGFuZGluZyB0aGUgcm91dGUnICBub3IgaG93IGl0DQo+ID4+Pj4+ID5kZWxp dmVycyB0aGUgc2lnbmFsZWQgTFNQIHJlcXVlc3QgdG8gdGhhdCBub2RlLg0KPiA+Pj4+PiA+DQo+ ID4+Pj4+ID5BcyBhbiBhc2lkZSwgdGhlIGRyYWZ0Og0KPiA+Pj4+Pg0KPiA+Pj4+Pj5odHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFsaS1jY2FtcC1yc3ZwLXRlLWluY2x1ZGUt cm8NCj4gPj4+Pj4+dXRlDQo+ID4+Pj4+Pi8NCj4gPj4+Pj4+Pw0KPiA+Pj4+PiA+aW5jDQo+ID4+ Pj4+ID5sdWRlX3RleHQ9MSB3b3VsZCBiZSBzdWJqZWN0IHRvIHRoZSBzYW1lIGNyaXRpY2lzbSBl eGNlcHQgdGhhdA0KPiA+Pj4+PiA+dGhlIGFib3ZlIHF1b3RlZCBwYXJhZ3JhcGggaXMgcmVwbGFj ZWQgd2l0aDoNCj4gPj4+Pj4gPg0KPiA+Pj4+PiA+IlRoZSBhYm92ZS1tZW50aW9uZWQgdXNlIGNh c2VzIHJlcXVpcmUgcmVsZXZhbnQgcGF0aCBpbmNsdXNpb24NCj4gPj4+Pj4gPnJlcXVpcmVtZW50 cyB0byBiZSBjb21tdW5pY2F0ZWQgdG8gdGhlIHJvdXRlIGV4cGFuZGluZyBub2Rlcy4NCj4gPj4+ Pj4gPlRoaXMgZG9jdW1lbnQgYWRkcmVzc2VzICB0aGVzZSByZXF1aXJlbWVudHMgYW5kIGRlZmlu ZXMNCj4gPj4+Pj4gPnByb2NlZHVyZXMgdG8gYWRkcmVzcyB0aGVtLiINCj4gPj4+Pj4gPg0KPiA+ Pj4+PiA+RXZlbiB0aG91Z2ggdGhpcyBpcyBoZWxwZnVsLCB0aGUgZHJhZnQgZG9lc24ndCBhY3R1 YWxseSBkZWZpbmUNCj4gPj4+Pj4gPnRoZXNlIHByb2NlZHVyZXMuDQo+ID4+Pj4+ID4NCj4gPj4+ Pj4gPllvdXJzIElycmVzcGVjdGl2ZWx5LA0KPiA+Pj4+PiA+DQo+ID4+Pj4+ID5Kb2huDQo+ID4+ Pj4+ID4NCj4gPj4+Pj4gPg0KPiA+Pj4+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4+Pj4gPkNDQU1QIG1haWxpbmcgbGlzdA0KPiA+Pj4+PiA+ Q0NBTVBAaWV0Zi5vcmcNCj4gPj4+Pj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2NhbXANCj4gPj4+Pj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+Pj4+ID5DQ0FNUCBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gPkNDQU1Q QGlldGYub3JnDQo+ID4+Pj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NjYW1wDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4NCj4gPj4+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Q0NBTVAg bWFpbGluZyBsaXN0DQo+ID4+PkNDQU1QQGlldGYub3JnDQo+ID4+Pmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gPj4NCj4gPg0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0 DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2NhbXANCg== From jdrake@juniper.net Wed Oct 9 12:06:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAC521F9F0A for ; Wed, 9 Oct 2013 12:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.661 X-Spam-Level: X-Spam-Status: No, score=-3.661 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAf8phVUtF8l for ; Wed, 9 Oct 2013 12:06:02 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 7927721E818F for ; Wed, 9 Oct 2013 12:05:31 -0700 (PDT) Received: from mail185-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE030.bigfish.com (10.243.66.95) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 19:05:26 +0000 Received: from mail185-co1 (localhost [127.0.0.1]) by mail185-co1-R.bigfish.com (Postfix) with ESMTP id 6B89D2C00F7; Wed, 9 Oct 2013 19:05:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail185-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(199002)(189002)(13464003)(37854004)(54316002)(56776001)(85306002)(81686001)(76482001)(65816001)(66066001)(80022001)(74366001)(79102001)(77982001)(63696002)(59766001)(81816001)(74876001)(74706001)(83072001)(69226001)(47736001)(49866001)(50986001)(47976001)(53806001)(4396001)(46102001)(51856001)(54356001)(80976001)(31966008)(47446002)(74662001)(74502001)(19580405001)(83322001)(19580395003)(81542001)(74316001)(76796001)(76786001)(76576001)(81342001)(77096001)(33646001)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.51; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail185-co1 (localhost.localdomain [127.0.0.1]) by mail185-co1 (MessageSwitch) id 1381345524210481_24049; Wed, 9 Oct 2013 19:05:24 +0000 (UTC) Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.231]) by mail185-co1.bigfish.com (Postfix) with ESMTP id 2EEDC5C007A; Wed, 9 Oct 2013 19:05:24 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS005.bigfish.com (10.243.66.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 19:05:23 +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; Wed, 9 Oct 2013 19:05:23 +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; Wed, 9 Oct 2013 19:05:21 +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; Wed, 9 Oct 2013 19:05:21 +0000 From: John E Drake To: "Zafar Ali (zali)" , Fatai Zhang , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: AQHOw/RvMrBCr56VuU2xebXAhUabxpnrFPqAgABNoZCAAHWXAIAA5NPg Date: Wed, 9 Oct 2013 19:05:21 +0000 Message-ID: <99bfea416ebf44029b44cd87391ba5e4@BY2PR05MB142.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] x-forefront-prvs: 0994F5E0C5 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:06:15 -0000 Zafar, This sounds like nonsense. Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Tuesday, October 08, 2013 10:26 PM > To: John E Drake; Fatai Zhang; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > (RSVP-TE) Path Diversity using Exclude Routes >=20 > Hi John: >=20 > No, RFC 5520/ RFC5533 are fine. The issue is that solution proposed by dr= aft- > zhang-ccamp-route-exclusion-pathkey-00.txt forces customers to deploy a > stateful PCE where PCE need to remember path it has served for indefinite > time. >=20 > Thanks >=20 > Regards ... Zafar >=20 >=20 > -----Original Message----- > From: "jdrake@juniper.net" > Date: Tuesday, October 8, 2013 6:26 PM > To: zali , Fatai Zhang , > "ccamp@ietf.org" > Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > (RSVP-TE) Path Diversity using Exclude Routes >=20 > >Zafar, > > > >So, is your assertion that RFC5553 is broken? > > > >Yours Irrespectively, > > > >John > > > >> -----Original Message----- > >> From: Zafar Ali (zali) [mailto:zali@cisco.com] > >> Sent: Tuesday, October 08, 2013 10:47 AM > >> To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org) > >> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic > >> Engineering > >> (RSVP-TE) Path Diversity using Exclude Routes > >> > >> Fatai and all- > >> > >> In a stateless PCE, Path Keys are transient and they expire. For this > >>solution to work you need a PCE that can keep Paths associated with a > >>Path Key around (a stateful PCE where states are path computed by the > >>PCE). > >> > >> Thanks > >> > >> Regards =A9 Zafar > >> > >> > >> -----Original Message----- > >> From: Fatai Zhang > >> Date: Tuesday, October 8, 2013 3:01 AM > >> To: "jdrake@juniper.net" , "ccamp@ietf.org" > >> > >> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic > >> Engineering > >> (RSVP-TE) Path Diversity using Exclude Routes > >> > >> >Hi John, > >> > > >> >Totally agree with you, I already found these two drafts are much > >> >*useless*. > >> > > >> >This is why we made a new draft (very simple and useful) and put our > >> >feet on the ground. > >> > > >> >http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusio > >> >n-p > >> >ath > >> >key-00.txt > >> > > >> > > >> > > >> > > >> >Best Regards > >> > > >> >Fatai > >> > > >> > > >> >-----Original Message----- > >> >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >> Behalf > >> >Of John E Drake > >> >Sent: Thursday, October 03, 2013 2:27 AM > >> >To: CCAMP (ccamp@ietf.org) > >> >Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > >> >(RSVP-TE) Path Diversity using Exclude Routes > >> > > >> >HI, > >> > > >> >I was reading: > >> >http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?incl > >> >ude _te xt=3D1, and I happened to notice the following paragraph: > >> > > >> >"The means by which the node calculating or expanding the route of > >> >the signaled LSP discovers the route of the path(s) from which the > >> >signaled LSP requires diversity are beyond the scope of this documen= t. " > >> > > >> >Doesn't this disclaimer effectively render this draft useless? The > >> >draft also does not define how the node that initially signaled the > >> >LSP finds the 'node calculating or expanding the route' nor how it > >> >delivers the signaled LSP request to that node. > >> > > >> >As an aside, the draft: > >> >http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-te-include-route= /? > >> >inc > >> >lude_text=3D1 would be subject to the same criticism except that the > >> >above quoted paragraph is replaced with: > >> > > >> >"The above-mentioned use cases require relevant path inclusion > >> >requirements to be communicated to the route expanding nodes. This > >> >document addresses these requirements and defines procedures to > >> >address them." > >> > > >> >Even though this is helpful, the draft doesn't actually define these > >> >procedures. > >> > > >> >Yours Irrespectively, > >> > > >> >John > >> > > >> > > >> >_______________________________________________ > >> >CCAMP mailing list > >> >CCAMP@ietf.org > >> >https://www.ietf.org/mailman/listinfo/ccamp > >> >_______________________________________________ > >> >CCAMP mailing list > >> >CCAMP@ietf.org > >> >https://www.ietf.org/mailman/listinfo/ccamp > >> > >> > > > > >=20 >=20 From jdrake@juniper.net Wed Oct 9 12:07:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2147221F9E63 for ; Wed, 9 Oct 2013 12:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.154 X-Spam-Level: X-Spam-Status: No, score=-5.154 tagged_above=-999 required=5 tests=[AWL=1.444, BAYES_00=-2.599, HS_INDEX_PARAM=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 bQXuGl7kX4wf for ; Wed, 9 Oct 2013 12:07:26 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 460A121E818E for ; Wed, 9 Oct 2013 12:06:48 -0700 (PDT) Received: from mail239-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 19:06:47 +0000 Received: from mail239-tx2 (localhost [127.0.0.1]) by mail239-tx2-R.bigfish.com (Postfix) with ESMTP id 63E50220261; Wed, 9 Oct 2013 19:06:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371Ic89bh542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail239-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=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(199002)(189002)(13464003)(37854004)(54316002)(56776001)(85306002)(81686001)(76482001)(65816001)(66066001)(80022001)(74366001)(79102001)(77982001)(63696002)(59766001)(15975445006)(81816001)(74876001)(74706001)(83072001)(69226001)(47736001)(49866001)(50986001)(47976001)(53806001)(4396001)(46102001)(51856001)(54356001)(80976001)(31966008)(47446002)(74662001)(74502001)(19580405001)(83322001)(19580395003)(81542001)(74316001)(76796001)(76786001)(76576001)(81342001)(77096001)(33646001)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.51; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail239-tx2 (localhost.localdomain [127.0.0.1]) by mail239-tx2 (MessageSwitch) id 1381345605260253_26029; Wed, 9 Oct 2013 19:06:45 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.248]) by mail239-tx2.bigfish.com (Postfix) with ESMTP id 29452440056; Wed, 9 Oct 2013 19:06:45 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 19:06:44 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 9 Oct 2013 19:06:39 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 9 Oct 2013 19:06:36 +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; Wed, 9 Oct 2013 19:06:36 +0000 From: John E Drake To: "Zhangxian (Xian)" , "Zafar Ali (zali)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: AQHOw/RvMrBCr56VuU2xebXAhUabxpnrFPqAgABNoZCAAHWXAIAACg2AgADbKBA= Date: Wed, 9 Oct 2013 19:06:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] x-forefront-prvs: 0994F5E0C5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:07:32 -0000 RXhhY3RseS4NCg0KWW91cnMgSXJyZXNwZWN0aXZlbHksDQoNCkpvaG4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBaaGFuZ3hpYW4gKFhpYW4pIFttYWlsdG86emhhbmcu eGlhbkBodWF3ZWkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDA4LCAyMDEzIDExOjAy IFBNDQo+IFRvOiBaYWZhciBBbGkgKHphbGkpOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+IENj OiBKb2huIEUgRHJha2U7IEZhdGFpIFpoYW5nDQo+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIFJlc291 cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcNCj4gKFJTVlAtVEUp IFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVzDQo+IA0KPiBIaSwgWmFmYXIsDQo+ IA0KPiAgICAgVGhhbmsgeW91IGZvciBzaGFyaW5nIHRoZSB0aG91Z2h0cy4gQnV0IEkgY2Fubm90 IGFncmVlIHdpdGggd2hhdCB5b3Ugc2FpZA0KPiBiZWxvdy4NCj4gDQo+ICAgICBQYXRoIGtleSBz b2x1dGlvbiBkb2VzIG5vdCBuZWNlc3NhcmlseSBuZWVkIHRoZSBwcmVzZW5jZSBvZiBhIHN0YXRl ZnVsIFBDRS4NCj4gU2ltaWxhcmx5IHdpdGggUkZDNTU1MywgdGhlIHBhdGgga2V5IG93bmVyIG5l ZWRzIHRvIHJldGFpbiB0aGlzIGluZm9ybWF0aW9uDQo+IHNvIHRoYXQgSSBjYW4gaW50ZXJwcmV0 IHdoZW4gdXNlZCBhdCBhIGxhdGVyIHRpbWUuIFJldGFpbmluZyBzdWNoIGluZm9ybWF0aW9uDQo+ IGRvZXMgbm90IGVxdWFsIHRvIGEgc3RhdGVmdWwgUENFIHdoaWNoIG5lZWRzIHRvIGtub3cgdGhl IExTUCBzdGF0ZXMgb2YgdGhlDQo+IHdob2xlIG5ldHdvcmsgaXQgc2VydmVzLg0KPiANCj4gUmVn YXJkcywNCj4gWGlhbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZg0KPiBPZiBaYWZhciBBbGkgKHphbGkpDQo+IFNlbnQ6IDIwMTPlubQxMOaciDnml6Ug MTM6MjYNCj4gVG86IEpvaG4gRSBEcmFrZTsgRmF0YWkgWmhhbmc7IENDQU1QIChjY2FtcEBpZXRm Lm9yZykNCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9j b2wtVHJhZmZpYyBFbmdpbmVlcmluZw0KPiAoUlNWUC1URSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcg RXhjbHVkZSBSb3V0ZXMNCj4gDQo+IEhpIEpvaG46DQo+IA0KPiBObywgUkZDIDU1MjAvIFJGQzU1 MzMgYXJlIGZpbmUuIFRoZSBpc3N1ZSBpcyB0aGF0IHNvbHV0aW9uIHByb3Bvc2VkIGJ5IGRyYWZ0 LQ0KPiB6aGFuZy1jY2FtcC1yb3V0ZS1leGNsdXNpb24tcGF0aGtleS0wMC50eHQgZm9yY2VzIGN1 c3RvbWVycyB0byBkZXBsb3kgYQ0KPiBzdGF0ZWZ1bCBQQ0Ugd2hlcmUgUENFIG5lZWQgdG8gcmVt ZW1iZXIgcGF0aCBpdCBoYXMgc2VydmVkIGZvciBpbmRlZmluaXRlDQo+IHRpbWUuDQo+IA0KPiBU aGFua3MNCj4gDQo+IFJlZ2FyZHMgLi4uIFphZmFyDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogImpkcmFrZUBqdW5pcGVyLm5ldCIgPGpkcmFrZUBqdW5pcGVy Lm5ldD4NCj4gRGF0ZTogVHVlc2RheSwgT2N0b2JlciA4LCAyMDEzIDY6MjYgUE0NCj4gVG86IHph bGkgPHphbGlAY2lzY28uY29tPiwgRmF0YWkgWmhhbmcgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbT4s DQo+ICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogW0ND QU1QXSBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nDQo+ IChSU1ZQLVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPiANCj4gPlph ZmFyLA0KPiA+DQo+ID5TbywgaXMgeW91ciBhc3NlcnRpb24gdGhhdCBSRkM1NTUzIGlzIGJyb2tl bj8NCj4gPg0KPiA+WW91cnMgSXJyZXNwZWN0aXZlbHksDQo+ID4NCj4gPkpvaG4NCj4gPg0KPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBaYWZhciBBbGkgKHphbGkp IFttYWlsdG86emFsaUBjaXNjby5jb21dDQo+ID4+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDgs IDIwMTMgMTA6NDcgQU0NCj4gPj4gVG86IEZhdGFpIFpoYW5nOyBKb2huIEUgRHJha2U7IENDQU1Q IChjY2FtcEBpZXRmLm9yZykNCj4gPj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gUmVzb3VyY2UgUmVz ZXJWYXRpb24gUHJvdG9jb2wtVHJhZmZpYw0KPiA+PiBFbmdpbmVlcmluZw0KPiA+PiAoUlNWUC1U RSkgUGF0aCBEaXZlcnNpdHkgdXNpbmcgRXhjbHVkZSBSb3V0ZXMNCj4gPj4NCj4gPj4gRmF0YWkg YW5kIGFsbC0NCj4gPj4NCj4gPj4gSW4gYSBzdGF0ZWxlc3MgUENFLCBQYXRoIEtleXMgYXJlIHRy YW5zaWVudCBhbmQgdGhleSBleHBpcmUuIEZvciB0aGlzDQo+ID4+c29sdXRpb24gIHRvIHdvcmsg eW91IG5lZWQgYSBQQ0UgdGhhdCBjYW4ga2VlcCBQYXRocyBhc3NvY2lhdGVkIHdpdGggYQ0KPiA+ PlBhdGggS2V5ICBhcm91bmQgKGEgc3RhdGVmdWwgUENFIHdoZXJlIHN0YXRlcyBhcmUgcGF0aCBj b21wdXRlZCBieSB0aGUNCj4gPj5QQ0UpLg0KPiA+Pg0KPiA+PiBUaGFua3MNCj4gPj4NCj4gPj4g UmVnYXJkcyDFoCBaYWZhcg0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+PiBGcm9tOiBGYXRhaSBaaGFuZyA8emhhbmdmYXRhaUBodWF3ZWkuY29tPg0KPiA+ PiBEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDgsIDIwMTMgMzowMSBBTQ0KPiA+PiBUbzogImpkcmFr ZUBqdW5pcGVyLm5ldCIgPGpkcmFrZUBqdW5pcGVyLm5ldD4sICJjY2FtcEBpZXRmLm9yZyINCj4g Pj4gPGNjYW1wQGlldGYub3JnPg0KPiA+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBSZXNvdXJjZSBS ZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljDQo+ID4+IEVuZ2luZWVyaW5nDQo+ID4+IChSU1ZQ LVRFKSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPiA+Pg0KPiA+PiA+SGkg Sm9obiwNCj4gPj4gPg0KPiA+PiA+VG90YWxseSBhZ3JlZSB3aXRoIHlvdSwgSSBhbHJlYWR5IGZv dW5kIHRoZXNlIHR3byBkcmFmdHMgYXJlIG11Y2gNCj4gPj4gPip1c2VsZXNzKi4NCj4gPj4gPg0K PiA+PiA+VGhpcyBpcyB3aHkgd2UgbWFkZSBhIG5ldyBkcmFmdCAodmVyeSBzaW1wbGUgYW5kIHVz ZWZ1bCkgYW5kIHB1dCBvdXINCj4gPj4gPmZlZXQgb24gdGhlIGdyb3VuZC4NCj4gPj4gPg0KPiA+ PiA+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctY2NhbXAt cm91dGUtZXhjbHVzaW8NCj4gPj4gPm4tcA0KPiA+PiA+YXRoDQo+ID4+ID5rZXktMDAudHh0DQo+ ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPkJlc3QgUmVnYXJkcw0KPiA+PiA+ DQo+ID4+ID5GYXRhaQ0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4+ID5Gcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4gPj4gQmVoYWxmDQo+ID4+ID5PZiBKb2huIEUgRHJha2UN Cj4gPj4gPlNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDAzLCAyMDEzIDI6MjcgQU0NCj4gPj4gPlRv OiBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQo+ID4+ID5TdWJqZWN0OiBbQ0NBTVBdIFJlc291cmNl IFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcNCj4gPj4gPihSU1ZQLVRF KSBQYXRoIERpdmVyc2l0eSB1c2luZyBFeGNsdWRlIFJvdXRlcw0KPiA+PiA+DQo+ID4+ID5ISSwN Cj4gPj4gPg0KPiA+PiA+SSB3YXMgcmVhZGluZzoNCj4gPj4gPmh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1sc3AtZGl2ZXJzaXR5Lz9pbmNsDQo+ID4+ID51 ZGUgX3RlIHh0PTEsIGFuZCBJIGhhcHBlbmVkIHRvIG5vdGljZSB0aGUgZm9sbG93aW5nIHBhcmFn cmFwaDoNCj4gPj4gPg0KPiA+PiA+IlRoZSBtZWFucyBieSB3aGljaCB0aGUgbm9kZSBjYWxjdWxh dGluZyBvciBleHBhbmRpbmcgdGhlIHJvdXRlIG9mDQo+ID4+ID50aGUgc2lnbmFsZWQgTFNQIGRp c2NvdmVycyB0aGUgcm91dGUgb2YgdGhlIHBhdGgocykgZnJvbSB3aGljaCB0aGUNCj4gPj4gPnNp Z25hbGVkIExTUCAgcmVxdWlyZXMgZGl2ZXJzaXR5IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQuICINCj4gPj4gPg0KPiA+PiA+RG9lc24ndCB0aGlzIGRpc2NsYWltZXIgZWZm ZWN0aXZlbHkgcmVuZGVyIHRoaXMgZHJhZnQgdXNlbGVzcz8gIFRoZQ0KPiA+PiA+ZHJhZnQgYWxz byBkb2VzIG5vdCBkZWZpbmUgaG93IHRoZSBub2RlIHRoYXQgaW5pdGlhbGx5IHNpZ25hbGVkIHRo ZQ0KPiA+PiA+TFNQIGZpbmRzIHRoZSAnbm9kZSBjYWxjdWxhdGluZyBvciBleHBhbmRpbmcgdGhl IHJvdXRlJyAgbm9yIGhvdyBpdA0KPiA+PiA+ZGVsaXZlcnMgdGhlIHNpZ25hbGVkIExTUCByZXF1 ZXN0IHRvIHRoYXQgbm9kZS4NCj4gPj4gPg0KPiA+PiA+QXMgYW4gYXNpZGUsIHRoZSBkcmFmdDoN Cj4gPj4gPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWxpLWNjYW1wLXJz dnAtdGUtaW5jbHVkZS1yb3V0ZS8/DQo+ID4+ID5pbmMNCj4gPj4gPmx1ZGVfdGV4dD0xIHdvdWxk IGJlIHN1YmplY3QgdG8gdGhlIHNhbWUgY3JpdGljaXNtIGV4Y2VwdCB0aGF0IHRoZQ0KPiA+PiA+ YWJvdmUgcXVvdGVkIHBhcmFncmFwaCBpcyByZXBsYWNlZCB3aXRoOg0KPiA+PiA+DQo+ID4+ID4i VGhlIGFib3ZlLW1lbnRpb25lZCB1c2UgY2FzZXMgcmVxdWlyZSByZWxldmFudCBwYXRoIGluY2x1 c2lvbg0KPiA+PiA+cmVxdWlyZW1lbnRzIHRvIGJlIGNvbW11bmljYXRlZCB0byB0aGUgcm91dGUg ZXhwYW5kaW5nIG5vZGVzLiAgVGhpcw0KPiA+PiA+ZG9jdW1lbnQgYWRkcmVzc2VzICB0aGVzZSBy ZXF1aXJlbWVudHMgYW5kIGRlZmluZXMgcHJvY2VkdXJlcyB0bw0KPiA+PiA+YWRkcmVzcyB0aGVt LiINCj4gPj4gPg0KPiA+PiA+RXZlbiB0aG91Z2ggdGhpcyBpcyBoZWxwZnVsLCB0aGUgZHJhZnQg ZG9lc24ndCBhY3R1YWxseSBkZWZpbmUgdGhlc2UNCj4gPj4gPnByb2NlZHVyZXMuDQo+ID4+ID4N Cj4gPj4gPllvdXJzIElycmVzcGVjdGl2ZWx5LA0KPiA+PiA+DQo+ID4+ID5Kb2huDQo+ID4+ID4N Cj4gPj4gPg0KPiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4gPkNDQU1QIG1haWxpbmcgbGlzdA0KPiA+PiA+Q0NBTVBAaWV0Zi5vcmcNCj4g Pj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gPj4gPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID5DQ0FN UCBtYWlsaW5nIGxpc3QNCj4gPj4gPkNDQU1QQGlldGYub3JnDQo+ID4+ID5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ID4+DQo+ID4+DQo+ID4NCj4gPg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NB TVAgbWFpbGluZyBsaXN0DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== From jdrake@juniper.net Wed Oct 9 12:14:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4191921E81B0 for ; Wed, 9 Oct 2013 12:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZROcRQoY6OGZ for ; Wed, 9 Oct 2013 12:14:13 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9B91E21E81AD for ; Wed, 9 Oct 2013 12:14:12 -0700 (PDT) Received: from mail217-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE027.bigfish.com (10.243.66.90) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 19:14:11 +0000 Received: from mail217-co1 (localhost [127.0.0.1]) by mail217-co1-R.bigfish.com (Postfix) with ESMTP id 7BAF0880170; Wed, 9 Oct 2013 19:14:11 +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(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097hz2fh2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail217-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(37854004)(377454003)(51704005)(189002)(199002)(13464003)(69226001)(49866001)(47736001)(50986001)(47976001)(74706001)(83072001)(76576001)(81542001)(76786001)(76796001)(74316001)(33646001)(77096001)(56816003)(81342001)(54356001)(53806001)(46102001)(51856001)(4396001)(74662001)(47446002)(83322001)(74502001)(19580405001)(31966008)(80976001)(19580395003)(81686001)(65816001)(76482001)(56776001)(54316002)(85306002)(59766001)(74876001)(81816001)(80022001)(66066001)(63696002)(79102001)(74366001)(77982001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.51; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail217-co1 (localhost.localdomain [127.0.0.1]) by mail217-co1 (MessageSwitch) id 1381346048496557_24525; Wed, 9 Oct 2013 19:14:08 +0000 (UTC) Received: from CO1EHSMHS026.bigfish.com (unknown [10.243.78.237]) by mail217-co1.bigfish.com (Postfix) with ESMTP id 6B1A29C0041; Wed, 9 Oct 2013 19:14:08 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS026.bigfish.com (10.243.66.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 19:14:08 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 9 Oct 2013 19:14:05 +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; Wed, 9 Oct 2013 19:14:03 +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; Wed, 9 Oct 2013 19:14:03 +0000 From: John E Drake To: "Zafar Ali (zali)" , Fatai Zhang , "Zhangxian (Xian)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: AQHOw/RvMrBCr56VuU2xebXAhUabxpnrFPqAgABNoZCAAHWXAIAACg2AgAABTICAAAF+AIAACo+AgAAJaICAAAhlAIAAvOIg Date: Wed, 9 Oct 2013 19:14:03 +0000 Message-ID: <0ace45976a434fb0b096b5f084c14756@BY2PR05MB142.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] x-forefront-prvs: 0994F5E0C5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:14:19 -0000 WmFmYXIsDQoNClNuaXBwZWQsIGNvbW1lbnQgaW5saW5lLg0KDQpZb3VycyBJcnJlc3BlY3RpdmVs eSwNCg0KSm9obg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFphZmFy IEFsaSAoemFsaSkgW21haWx0bzp6YWxpQGNpc2NvLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBP Y3RvYmVyIDA5LCAyMDEzIDEyOjU0IEFNDQo+IFRvOiBGYXRhaSBaaGFuZzsgWmhhbmd4aWFuIChY aWFuKTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnKQ0KPiBDYzogSm9obiBFIERyYWtlDQo+IFN1Ympl Y3Q6IFJlOiBbQ0NBTVBdIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5n aW5lZXJpbmcNCj4gKFJTVlAtVEUpIFBhdGggRGl2ZXJzaXR5IHVzaW5nIEV4Y2x1ZGUgUm91dGVz DQo+IA0KPiBGYXRhaSBhbmQgSm9objoNCj4gDQo+IEluIG1vc3Qgb2YgdGhlIGNhc2VzLCB3aGVu IHRoZSBVTkktTiBub2RlIGNvbXB1dGluZyB0aGUgcGF0aCBpcyBhbHNvDQo+IGhvc3RpbmcgdGhl IFJTVlAtVEUgRkVDIGFnYWluc3Qgd2hpY2ggZXhjbHVzaW9uIGlzIHJlcXVpcmVkLCBpdCBrbm93 cyB0aGUNCj4gcGF0aCB0YWtlIGJ5IHRoZSBvdGhlciBMU1AuIEZvciB0aGUgb3RoZXIgY2FzZXMs IHBsZWFzZSBub3RlIHRoYXQganVzdA0KPiBiZWNhdXNlIG9wdGljYWwgbmV0d29yayBpcyBydW5u aW5nIEdNUExTIFVOSSBmb3IgY2xpZW50IGludGVyZmFjZSBkb2VzIG5vdA0KPiBtZWFuIHRoYXQg aXQgaXMgcnVubmluZyBSU1ZQLVRFIGZvciB0aGUgb3B0aWNhbCB0cmFpbCBtYW5hZ2VtZW50LiBF LmcuLCBvcHRpY2FsDQo+IHRyYWlsIG1hbmFnZW1lbnQgY2FuIHN0aWxsIHVzaW5nIGFuIGFscmVh ZHkgZGVwbG95ZWQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcw0KPiBvciBhbiBOTVMgYmFzZWQgc2No ZW1lLiBUaGUgZHJhZnQgaXMgYWRkcmVzc2luZyBzY2hlbWVzIHRoYXQgYXJlIGNhcGFibGUNCj4g b2YgdGhpcyBmdW5jdGlvbmFsaXR5Lg0KDQpbSkRdICBTbywgeW91IGFyZSBmaW5hbGx5IGFkbWl0 dGluZyB0aGF0IGRlc3BpdGUgd2hhdCB5b3VyIGRyYWZ0IGN1cnJlbnRseSBzdGF0ZXMsIHlvdXIg ZHJhZnQgb25seSB3b3Jrcw0KSWYgdGhlIHNlcnZlciBuZXR3b3JrIGlzIGNvbnRyb2xsZWQgYnkg YSBzaW5nbGUgb21uaXNjaWVudCBlbnRpdHkuICBBcyBJIHNhaWQgYmVmb3JlLCB0aGlzIGlzIHVz ZWxlc3MuICANCg0K From IHussain@infinera.com Wed Oct 9 14:53:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A228121F855F for ; Wed, 9 Oct 2013 14:53:26 -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 UQ4RTrtigR-I for ; Wed, 9 Oct 2013 14:53:22 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7070B21E81E7 for ; Wed, 9 Oct 2013 14:53:22 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Wed, 9 Oct 2013 14:53:21 -0700 From: Iftekhar Hussain To: "ccamp@ietf.org" Thread-Topic: New Version: draft-hussain-ccamp-super-channel-label-06.txt Thread-Index: Ac7FOX2RfcYJ6wOLSOerPOTUNG2pwA== Date: Wed, 9 Oct 2013 21:53:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CCAMP] New Version: draft-hussain-ccamp-super-channel-label-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 21:53:26 -0000 SGksDQoNCkZZSS4uLiAgSSBoYXZlIHBvc3RlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4N Cg0KSWZ0ZWtoYXINCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDog VHVlc2RheSwgT2N0b2JlciAwOCwgMjAxMyA5OjI2IFBNDQpUbzogQW5kcmV3IEcuTWFsaXM7IE1h cmNvIFNvc2E7IEFiaW5kZXIgRGhpbGxvbjsgTWFyY28gU29zYTsgSWZ0ZWtoYXIgSHVzc2Fpbjsg WmhvbmcgUGFuDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1 c3NhaW4tY2NhbXAtc3VwZXItY2hhbm5lbC1sYWJlbC0wNi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtaHVzc2Fpbi1jY2FtcC1zdXBlci1jaGFubmVsLWxhYmVsLTA2LnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBJZnRla2hhciBIdXNzYWluIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1odXNzYWlu LWNjYW1wLXN1cGVyLWNoYW5uZWwtbGFiZWwNClJldmlzaW9uOgkgMDYNClRpdGxlOgkJIEdlbmVy YWxpemVkIExhYmVsIGZvciBTdXBlci1DaGFubmVsIEFzc2lnbm1lbnQgb24gRmxleGlibGUgR3Jp ZA0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTAtMDgNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxNg0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odXNzYWluLWNjYW1wLXN1cGVyLWNoYW5uZWwt bGFiZWwtMDYudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaHVzc2Fpbi1jY2FtcC1zdXBlci1jaGFubmVsLWxhYmVsDQpIdG1saXplZDog ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1c3NhaW4tY2NhbXAtc3Vw ZXItY2hhbm5lbC1sYWJlbC0wNg0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1odXNzYWluLWNjYW1wLXN1cGVyLWNoYW5uZWwtbGFiZWwtMDYN Cg0KQWJzdHJhY3Q6DQogICBUbyBlbmFibGUgc2NhbGluZyBvZiBleGlzdGluZyB0cmFuc3BvcnQg c3lzdGVtcyB0byB1bHRyYSBoaWdoIGRhdGENCiAgIHJhdGVzIG9mIDEgVGJwcyBhbmQgYmV5b25k LCBuZXh0IGdlbmVyYXRpb24gc3lzdGVtcyBwcm92aWRpbmcgc3VwZXItDQogICBjaGFubmVsIHN3 aXRjaGluZyBjYXBhYmlsaXR5IGFyZSBjdXJyZW50bHkgYmVpbmcgZGV2ZWxvcGVkLiBUbyBhbGxv dw0KICAgZWZmaWNpZW50IGFsbG9jYXRpb24gb2Ygb3B0aWNhbCBzcGVjdHJhbCBiYW5kd2lkdGgg Zm9yIHN1Y2ggaGlnaCBiaXQNCiAgIHJhdGUgc3lzdGVtcywgSW50ZXJuYXRpb25hbCBUZWxlY29t bXVuaWNhdGlvbiBVbmlvbg0KICAgVGVsZWNvbW11bmljYXRpb24gU3RhbmRhcmRpemF0aW9uIFNl Y3RvciAoSVRVLVQpIGlzIGV4dGVuZGluZyB0aGUNCiAgIEcuNjk0LjEgZ3JpZCBzdGFuZGFyZCAo dGVybWVkICJGaXhlZC1HcmlkIikgdG8gaW5jbHVkZSBmbGV4aWJsZSBncmlkDQogICAodGVybWVk ICJGbGV4LUdyaWQiKSBzdXBwb3J0IChkcmFmdCByZXZpc2VkIElUVS1UIEcuNjk0LjEsIHJldmlz aW9uDQogICAxLjQsIE9jdCAyMDExKS4gVGhpcyBuZWNlc3NpdGF0ZXMgZGVmaW5pdGlvbiBvZiBu ZXcgbGFiZWwgZm9ybWF0IGZvcg0KICAgdGhlIEZsZXgtR3JpZC4gVGhpcyBkb2N1bWVudCBkZWZp bmVzIGEgc3VwZXItY2hhbm5lbCBsYWJlbCBhcyBhDQogICBTdXBlci1DaGFubmVsIElkZW50aWZp ZXIgYW5kIGFuIGFzc29jaWF0ZWQgbGlzdCBvZiAxMi41IEdIeiBzbGljZXMNCiAgIHJlcHJlc2Vu dGluZyB0aGUgb3B0aWNhbCBzcGVjdHJ1bSBvZiB0aGUgc3VwZXItY2hhbm5lbC4gVGhlIGxhYmVs DQogICBpbmZvcm1hdGlvbiBjYW4gYmUgZW5jb2RlZCB1c2luZyBhIGZpeGVkIGxlbmd0aCBvciB2 YXJpYWJsZSBsZW5ndGgNCiAgIGZvcm1hdC4gVGhpcyBsYWJlbCBmb3JtYXQgY2FuIGJlIHVzZWQg aW4gR01QTFMgc2lnbmFsaW5nIGFuZCByb3V0aW5nDQogICBwcm90b2NvbCB0byBlc3RhYmxpc2gg c3VwZXItY2hhbm5lbCBiYXNlZCBvcHRpY2FsIGxhYmVsIHN3aXRjaGVkDQogICBwYXRocyAoTFNQ cykuDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg== From zali@cisco.com Wed Oct 9 15:04:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA4821E81DD for ; Wed, 9 Oct 2013 15:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhBDkuNmGOCu for ; Wed, 9 Oct 2013 15:04:23 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DB77121E81DC for ; Wed, 9 Oct 2013 15:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1994; q=dns/txt; s=iport; t=1381356260; x=1382565860; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=7jMQ2JmMjqnzDndf8iE985Kv8bpGKWpxYN+JAyOqzqw=; b=E4pVT3hlWlNdJSO3/Ml/872fxe+4tewYbl+w+szBlfjjU4uMDFdwZqrs +beoO0nKIwsARImpLDG6sj0XhD3aB0hyycHPLpwbFMbSL8bjbRKKllbW1 xJNtgRFPa76RZ2Ul9JBg6OGa0QuY7BGbaPI76BEs0gwjiAzr4f8QZV2Gq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAK7RVVKtJXG9/2dsb2JhbABagweBCsFDgSAWdIIlAQEBBIEFBgEIEQMBAQELGQQ5FAkIAgQBEgiHfrkgjxQ4BoMZgQQDqgSBZoE+gio X-IronPort-AV: E=Sophos;i="4.90,1066,1371081600"; d="scan'208";a="270233678" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 09 Oct 2013 22:04:19 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r99M4JjL027436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 22:04:19 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 17:04:18 -0500 From: "Zafar Ali (zali)" To: John E Drake , Fatai Zhang , "Zhangxian (Xian)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYAAEh8IgAAGSCKAAAmjooD//745AIAARJEA///HfwCAAEx3gP//xVaAgAEBL4D//+yBAA== Date: Wed, 9 Oct 2013 22:04:18 +0000 Message-ID: In-Reply-To: <0ace45976a434fb0b096b5f084c14756@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.238.1] Content-Type: text/plain; charset="Windows-1252" Content-ID: <988AA088EEA1E54DBE514862D58D0B24@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 22:04:29 -0000 John:=20 Scope of the draft is to define UNI-C and the problem you are hanged on beyond the scope of UNI-C and that aspect is clear stated in the draft. Furthermore, I cited two deployment use cases one of which is based on distributed path computation and other does not require single omniscient entity. =20 Thanks Regards =8A Zafar -----Original Message----- From: "jdrake@juniper.net" Date: Wednesday, October 9, 2013 3:14 PM To: zali , Fatai Zhang , "Zhangxian (Xian)" , "ccamp@ietf.org" Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes >Zafar, > >Snipped, comment inline. > >Yours Irrespectively, > >John > >> -----Original Message----- >> From: Zafar Ali (zali) [mailto:zali@cisco.com] >> Sent: Wednesday, October 09, 2013 12:54 AM >> To: Fatai Zhang; Zhangxian (Xian); CCAMP (ccamp@ietf.org) >> Cc: John E Drake >> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering >> (RSVP-TE) Path Diversity using Exclude Routes >>=20 >> Fatai and John: >>=20 >> In most of the cases, when the UNI-N node computing the path is also >> hosting the RSVP-TE FEC against which exclusion is required, it knows >>the >> path take by the other LSP. For the other cases, please note that just >> because optical network is running GMPLS UNI for client interface does >>not >> mean that it is running RSVP-TE for the optical trail management. E.g., >>optical >> trail management can still using an already deployed proprietary >>mechanisms >> or an NMS based scheme. The draft is addressing schemes that are capable >> of this functionality. > >[JD] So, you are finally admitting that despite what your draft >currently states, your draft only works >If the server network is controlled by a single omniscient entity. As I >said before, this is useless. > From lsmt@ietf.org Thu Oct 10 07:24:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29911E817B; Thu, 10 Oct 2013 07:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJsi-M4ht2TY; Thu, 10 Oct 2013 07:24:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3063D11E8176; Thu, 10 Oct 2013 07:24:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: jdrake@juniper.net X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131010142408.30339.94162.idtracker@ietfa.amsl.com> Date: Thu, 10 Oct 2013 07:24:08 -0700 Cc: peter.stassar@huawei.com, tsbsg15@itu.int, panslow@ciena.com, ccamp@ietf.org, dbrungard@att.com Subject: [CCAMP] New Liaison Statement, "CCAMP Liaison to ITU-T SG15's Q6 and Q12 on Flexible Grid DWDM networks" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:24:15 -0000 Title: CCAMP Liaison to ITU-T SG15's Q6 and Q12 on Flexible Grid DWDM netwo= rks Submission Date: 2013-10-09 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1284/ Please reply by 2013-12-20 From: Common Control and Measurement Plane (Deborah Brungard ) To: ITU-T SG 15 (jdrake@juniper.net) Cc: tsbsg15@itu.int,steve.trowbridge@alcatel-lucent.com,greg.jones@itu.int,= peter.stassar@huawei.com,panslow@ciena.com,sshew@ciena.com,ccamp@ietf.org,l= berger@labn.net,dbrungard@att.com,scott.mansfield@ericsson.com,adrian@olddo= g.co.uk,stbryant@cisco.com,jdrake@juniper.net Reponse Contact: dbrungard@att.com Technical Contact: dbrungard@att.com Purpose: For action Body: The CCAMP Working Group would like to inform you that we have initiat= ed control plane work on supporting Flexible Grid DWDM networks with the fo= llowing document: http://www.ietf.org/id/draft-ietf-ccamp-flexi-grid-fwk-00.txt Our understanding of the n and m parameters, when used to describe a freque= ncy slot, have to be integer, as per G.694.1. From a signaling perspective= , since we are signaling actual frequency slots on a hop per hop basis, we = would use integer values. It is our understanding that typically a consiste= nt value of n would be used for a path over multiple network elements, thou= gh the Recommendation does not constrain it. = The CCAMP WG would like to ask if our understanding is accurate. = We would appreciate if you would continue to keep us informed of your progr= ess and development on capabilities for the data plane that may affect the = control plane. = Best regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs Attachments: No document has been attached From jdrake@juniper.net Thu Oct 10 09:58:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070B821F9E39 for ; Thu, 10 Oct 2013 09:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.781 X-Spam-Level: X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLhRrEtBYeig for ; Thu, 10 Oct 2013 09:58:27 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id A26F321F9D92 for ; Thu, 10 Oct 2013 09:58:25 -0700 (PDT) Received: from mail218-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 16:58:24 +0000 Received: from mail218-ch1 (localhost [127.0.0.1]) by mail218-ch1-R.bigfish.com (Postfix) with ESMTP id 9FD86601AD; Thu, 10 Oct 2013 16:58:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de097h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail218-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:(37854004)(377454003)(51704005)(199002)(189002)(13464003)(69226001)(49866001)(47736001)(50986001)(47976001)(74706001)(83072001)(76576001)(81542001)(76786001)(76796001)(74316001)(33646001)(77096001)(56816003)(81342001)(54356001)(46102001)(53806001)(51856001)(74662001)(4396001)(83322001)(74502001)(19580405001)(19580395003)(47446002)(80976001)(31966008)(76482001)(81686001)(65816001)(56776001)(54316002)(85306002)(59766001)(74876001)(81816001)(80022001)(66066001)(63696002)(79102001)(74366001)(77982001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.53; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail218-ch1 (localhost.localdomain [127.0.0.1]) by mail218-ch1 (MessageSwitch) id 138142430311996_22833; Thu, 10 Oct 2013 16:58:23 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail218-ch1.bigfish.com (Postfix) with ESMTP id F132F3E020B; Thu, 10 Oct 2013 16:58:22 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 16:58:21 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 10 Oct 2013 16:58:20 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 10 Oct 2013 16:58:18 +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; Thu, 10 Oct 2013 16:58:18 +0000 From: John E Drake To: "Zafar Ali (zali)" , Fatai Zhang , "Zhangxian (Xian)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes Thread-Index: AQHOw/RvMrBCr56VuU2xebXAhUabxpnrFPqAgABNoZCAAHWXAIAACg2AgAABTICAAAF+AIAACo+AgAAJaICAAAhlAIAAvOIggAAwzwCAATq90A== Date: Thu, 10 Oct 2013 16:58:17 +0000 Message-ID: References: <0ace45976a434fb0b096b5f084c14756@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] x-forefront-prvs: 0995196AA2 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 16:58:34 -0000 Zafar, Comments inline. Yours Irrespectively, John > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Wednesday, October 09, 2013 3:04 PM > To: John E Drake; Fatai Zhang; Zhangxian (Xian); CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > (RSVP-TE) Path Diversity using Exclude Routes >=20 > John: >=20 > Scope of the draft is to define UNI-C and the problem you are hanged on > beyond the scope of UNI-C and that aspect is clear stated in the draft. [JD] This is incorrect. You go to great pains to claim that your draft ha= s general applicability and is not restricted only to UNI. > Furthermore, I cited two deployment use cases one of which is based on > distributed path computation and other does not require single omniscient > entity. [JD] As I noted in the email I sent on Tuesday: "In order to allow the in= gress node at the edge of an abstract node to expand the explicit route and= provide a disjoint route will require that each such ingress node has comp= lete knowledge of the RSVP-TE explicit route and identifier of every LSP tr= ansiting that abstract node." For you consideration: Com.nis.cient (m-nshnt) adj. Having total knowledge; knowing everything: an omniscient deity; the omnisc= ient narrator. n. 1. One having total knowledge. >=20 > Thanks >=20 > Regards =A9 Zafar >=20 >=20 > -----Original Message----- > From: "jdrake@juniper.net" > Date: Wednesday, October 9, 2013 3:14 PM > To: zali , Fatai Zhang , > "Zhangxian (Xian)" , "ccamp@ietf.org" > > Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering > (RSVP-TE) Path Diversity using Exclude Routes >=20 > >Zafar, > > > >Snipped, comment inline. > > > >Yours Irrespectively, > > > >John > > > >> -----Original Message----- > >> From: Zafar Ali (zali) [mailto:zali@cisco.com] > >> Sent: Wednesday, October 09, 2013 12:54 AM > >> To: Fatai Zhang; Zhangxian (Xian); CCAMP (ccamp@ietf.org) > >> Cc: John E Drake > >> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic > >> Engineering > >> (RSVP-TE) Path Diversity using Exclude Routes > >> > >> Fatai and John: > >> > >> In most of the cases, when the UNI-N node computing the path is also > >>hosting the RSVP-TE FEC against which exclusion is required, it knows > >>the path take by the other LSP. For the other cases, please note that > >>just because optical network is running GMPLS UNI for client > >>interface does not mean that it is running RSVP-TE for the optical > >>trail management. E.g., optical trail management can still using an > >>already deployed proprietary mechanisms or an NMS based scheme. The > >>draft is addressing schemes that are capable of this functionality. > > > >[JD] So, you are finally admitting that despite what your draft > >currently states, your draft only works If the server network is > >controlled by a single omniscient entity. As I said before, this is > >useless. > > >=20 >=20 From lberger@labn.net Thu Oct 10 13:55:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8056B21E808F for ; Thu, 10 Oct 2013 13:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.132 X-Spam-Level: X-Spam-Status: No, score=-102.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8j+7umPDRFt for ; Thu, 10 Oct 2013 13:55:26 -0700 (PDT) Received: from outbound-ss-330.hostmonster.com (outbound-ss-330.hostmonster.com [74.220.205.49]) by ietfa.amsl.com (Postfix) with SMTP id 7D0DA21E8087 for ; Thu, 10 Oct 2013 13:55:21 -0700 (PDT) Received: (qmail 29715 invoked by uid 0); 10 Oct 2013 20:54:59 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.mail.unifiedlayer.com with SMTP; 10 Oct 2013 20:54:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=38igmRQZXgJXAgqKqU3hAwXikpXgvQzWDeqSvhNXFMw=; b=LJhXYM6lC/aUG8Cpg+ZnHdYahggggYteArf0GETAAhGu7Tya5kzDIiP1zgKFAK7/lK9p7JpaNuEJr6OSsgRjnL5ZldksluTjBa4MwvedTv+OCNSN+v1ADUM0YOQEjraQ; Received: from box313.bluehost.com ([69.89.31.113]:50510 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VUNG7-0006DL-K6 for ccamp@ietf.org; Thu, 10 Oct 2013 14:54:59 -0600 Message-ID: <52571423.8000407@labn.net> Date: Thu, 10 Oct 2013 16:54:59 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Planning for Vancouver X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 20:55:32 -0000 All, We are currently scheduled to meet Thursday during the first 2.5 hour and the last 1 hour sessions. We'd like to use a block of the time, perhaps 30-60 minutes, to help move the discussion on UNI/PCE/ENNI/MLN/... forward. The current set of GMPLS RFCs allow for different choices in implementation and deployment by vendors and operators, both with and without PCE. From the discussion on the list, it's clear that there are some very different perspectives on these choices. While its not the WG's job to dictate how operators build their networks, having some common understanding is helpful. The topics we'd like to focus the discussion on are: 1) Use cases (which are important) e.g. which GMPLS protocols are used, layer model, if&how PCE is used, etc. Some drafts that touch on this include (we may have unintentionally overlooked others): draft-ali-ccamp-gmpls-uni-error-notification draft-beeram-ccamp-gmpls-enni draft-ceccadedios-ccamp-overlay-use-cases draft-fedyk-ccamp-uni-extensions draft-zhang-ccamp-gmpls-uni-app draft-farrel-interconnected-te-info-exchange 2) Current limitations Covering functions that are not supported by current RFCs. e.g., it's not possible to signal a services that has in specific use case. Not I can't signal this object, or routing doesn't carry this field. LSP diversity/similarity in certain UNI cases is an example discussed on the list. Please note: we will avoid/stop discussions on any new mechanisms in this part of the meeting. To present as part of this discussion, request a slot per Danielle's message. Deborah and Lou From lberger@labn.net Thu Oct 10 14:45:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A5121E8152 for ; Thu, 10 Oct 2013 14:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.049 X-Spam-Level: X-Spam-Status: No, score=-102.049 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 pN7Nolso3szo for ; Thu, 10 Oct 2013 14:45:09 -0700 (PDT) Received: from outbound-ss-1919.hostmonster.com (outbound-ss-1919.hostmonster.com [67.222.32.96]) by ietfa.amsl.com (Postfix) with SMTP id 4935D21E8140 for ; Thu, 10 Oct 2013 14:45:06 -0700 (PDT) Received: (qmail 15643 invoked by uid 0); 10 Oct 2013 21:44:44 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 10 Oct 2013 21:44:44 -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=hBYaAFstb2qnG0WqsFaysKNeCZW8GoxdqtnlqdGSjO0=; b=jDd472mTiHlK2AZemihsJ6l7JC37R+Bx31uNH+tZYQ9J+jLC+o64iCnQBss6wbhX/5FIXO3VD9OS03l+OzYeY/P+wtLMA9ixiy32ut12Ny2YWX/TAMjwusbOCi1xyxML; Received: from box313.bluehost.com ([69.89.31.113]:59574 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VUO2G-0004yg-Bp; Thu, 10 Oct 2013 15:44:44 -0600 Message-ID: <52571FCC.6030405@labn.net> Date: Thu, 10 Oct 2013 17:44:44 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org" Subject: Re: [CCAMP] Request for early IANA Allocation of values for new flag and RRO sub-object in draft-ietf-ccamp-rsvp-te-srlg-collect-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 21:45:13 -0000 Oscar, Authors, We'd like to allow a bit more time for the generic SO flags discussion to play out before moving forward on this, as the format of the SO may be impacted. My be is that sometime soon after Vancouver will be the right time to re ask. Lou (and Deborah) On 10/1/2013 3:38 AM, Oscar Gonz醠ez de Dios wrote: > Dear CCAMP WG chairs, > > Following the procedure for Early IANA Allocation of Standards Track > Code Points defined in Section 3.1 of RFC 4020, on behalf of the authors > of the WG draft "RSVP-TE Extensions for Collecting SRLG > Information", draft-ietf-ccamp-rsvp-te-srlg-collect-03, it is requested > to CCAMP WG chairs the early allocation of the following values: > > --> Value for a new flag, named "SRLG Collection Flag" in the RSVP > Attribute Bit Flags space. IANA has created a registry and manages the > space of attributes bit flags of Attribute Flags TLV, as described in > section 11.3 of [RFC5420], in the "Attributes TLV Space" section of the > "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) > Parameters" registry located in > https://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xhtml. > > The document "RSVP-TE Extensions for Collecting SRLG > Information",draft-ietf-ccamp-rsvp-te-srlg-collect-03, introduces and > defines a new Attribute Bit Flag, named "SRLG Collection Flag". It is > requested that IANA makes an early assignment of the value of the "SRLG > Collection Flag" from the Attribute Bit Flags. > > --> Type for a new RRO sub-object, named "SRLG sub-object " within > the ROUTE_RECORD Object space. IANA has made assignments in the "Class > Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" > registry located at http://www.iana.org/assignments/rsvp-parameters. > It is requested that IANA makes an early assignment of the type of the > new proposed RRO sub object in the > document draft-ietf-ccamp-rsvp-te-srlg-collect-03 named "SRLG > sub-object" from the ROUTE_RECORD portions of the mentioned registry. > > The main reason for the request of the early allocation is to facilitate > interoperability of early implementations, as other WG documents have > also new values in the same registry and clashes have been identified > with the suggested values in the drafts. We only request the allocation > of those parameters whose definition we think to be stable. > Best Regards, > > Oscar > > > ------------------------------------------------------------------------ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra pol韙ica de env韔 y recepci髇 de correo electr髇ico en el enlace > situado m醩 abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx From ogondio@tid.es Fri Oct 11 00:55:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230C321F938E for ; Fri, 11 Oct 2013 00:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.998 X-Spam-Level: X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[AWL=1.301, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9qJQw57HsZY for ; Fri, 11 Oct 2013 00:55:52 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8735521F9ADD for ; Fri, 11 Oct 2013 00:55:47 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MUH00I18VCVGR@tid.hi.inet> for ccamp@ietf.org; Fri, 11 Oct 2013 09:55:45 +0200 (MEST) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id D1.94.03197.10FA7525; Fri, 11 Oct 2013 09:55:45 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MUH00I1JVCXGR@tid.hi.inet> for ccamp@ietf.org; Fri, 11 Oct 2013 09:55:45 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Fri, 11 Oct 2013 09:55:45 +0200 Date: Fri, 11 Oct 2013 07:55:43 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: <52571FCC.6030405@labn.net> X-Originating-IP: [10.95.64.115] To: Lou Berger Message-id: Content-id: <0C72B7EF6A30794096C8698EE3C21C3D@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: Request for early IANA Allocation of values for new flag and RRO sub-object in draft-ietf-ccamp-rsvp-te-srlg-collect-03 Thread-index: AQHOvnkqNCPHky1ky0iNDxJLfoE5EZnuZWMAgADMRwA= user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4068-b7f3e8e000000c7d-d5-5257af01a706 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42Lhinfg0mVcHx5kcP66nMWTOTdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcebvH8aCNtmKxXOusDYwXhbvYuTkkBAwkTg2bRczhC0mceHe erYuRi4OIYGDjBJ7H/SwQDg/GCVa9r9ghHBmAjlfDgBlODhYBFQl3k9wBOlmE3CQWLeoF6xb WKCNUeJV5ztWkASngIbEtXsnGSFWKEj8OfeYBcQWEVCU+PpxERNIA7PAJkaJrT9+soMM5RXQ llj/UgykhlnATGLe9Gdg5/EKCEr8mHyPBSKuI9H7/RszhC0uMefXRFYIW1viybsLYDajgKzE yvOnwY4WEWhnlNjytJMdYrGVxPtDn9hAbFEBPYm2Y2fYIY4TkFiy5zw0LEQlXj7+xzqBUWIW kjtmIbljFpI7ZiG5YxaSOxYwsq5iFCtOKspMzyjJTczMSTcw1MvI1MvMSy3ZxAiJvYwdjMt3 qhxiFOBgVOLhdWQPDxJiTSwrrsw9xCjBwawkwrtvPlCINyWxsiq1KD++qDQntfgQIxMHp1QD Y5Pseg7GGL3bDmdbL5979U09UnPeoattCh+zZGNCUi6uNO7Y7xQf0PvMz3eSg49UU5bloWfB Sd2eseazFlyTDvryw/WqX8izIIYZbQ2eb5ic9HMXznzwssYl0aZR9jSTn8yyukNCn63Xs3n+ +upSvGPW7Dfr9P48+3+bY9vZKe65dW3Pd+/cqsRSnJFoqMVcVJwIADHPsk+bAgAA Cc: CCAMP , "draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org" Subject: Re: [CCAMP] Request for early IANA Allocation of values for new flag and RRO sub-object in draft-ietf-ccamp-rsvp-te-srlg-collect-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 07:55:56 -0000 Lou, Deborah, Thanks for the answer. Taking into account current ongoing discussi= ons, I am OK with postponing the request after Vancouver, as requested values must be part of stable parameters. Best Regards, Oscar El 10/10/13 23:44, "Lou Berger" escribi=F3: >Oscar, Authors, > We'd like to allow a bit more time for the generic SO flags discuss= ion >to play out before moving forward on this, as the format of the SO may >be impacted. My be is that sometime soon after Vancouver will be the >right time to re ask. > >Lou (and Deborah) > >On 10/1/2013 3:38 AM, Oscar Gonz=E1lez de Dios wrote: >> Dear CCAMP WG chairs, >> >> Following the procedure for Early IANA Allocation of Standards Track >> Code Points defined in Section 3.1 of RFC 4020, on behalf of the authors >> of the WG draft "RSVP-TE Extensions for Collecting SRLG >> Information", draft-ietf-ccamp-rsvp-te-srlg-collect-03, it is requested >> to CCAMP WG chairs the early allocation of the following values: >> >> --> Value for a new flag, named "SRLG Collection Flag" in the RSVP >> Attribute Bit Flags space. IANA has created a registry and manages the >> space of attributes bit flags of Attribute Flags TLV, as described in >> section 11.3 of [RFC5420], in the "Attributes TLV Space" section of the >> "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) >> Parameters" registry located in >> >>https://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xh >>tml. >> >> The document "RSVP-TE Extensions for Collecting SRLG >> Information",draft-ietf-ccamp-rsvp-te-srlg-collect-03, introduces and >> defines a new Attribute Bit Flag, named "SRLG Collection Flag". It is >> requested that IANA makes an early assignment of the value of the "SRLG >> Collection Flag" from the Attribute Bit Flags. >> >> --> Type for a new RRO sub-object, named "SRLG sub-object " within >> the ROUTE_RECORD Object space. IANA has made assignments in the "Class >> Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" >> registry located at http://www.iana.org/assignments/rsvp-parameters. >> It is requested that IANA makes an early assignment of the type of the >> new proposed RRO sub object in the >> document draft-ietf-ccamp-rsvp-te-srlg-collect-03 named "SRLG >> sub-object" from the ROUTE_RECORD portions of the mentioned registry. >> >> The main reason for the request of the early allocation is to facilitate >> interoperability of early implementations, as other WG documents have >> also new values in the same registry and clashes have been identified >> with the suggested values in the drafts. We only request the allocation >> of those parameters whose definition we think to be stable. >> Best Regards, >> >> Oscar >> >> >> ------------------------------------------------------------------------ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en e= l enlace >> situado m=E1s abajo. >> This message is intended exclusively for its addressee. We only send and >> receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From rjsparks@nostrum.com Fri Oct 11 08:16:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C287A11E81C8; Fri, 11 Oct 2013 08:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-nk57K4S8u6; Fri, 11 Oct 2013 08:16:14 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8E011E81FE; Fri, 11 Oct 2013 08:16:12 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-224.dllstx.fios.verizon.net [173.57.89.224]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9BFGAlw014938 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Fri, 11 Oct 2013 10:16:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <52581639.4050602@nostrum.com> Date: Fri, 11 Oct 2013 10:16:09 -0500 From: Robert Sparks 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: General Area Review Team , ccamp@ietf.org, draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org Content-Type: multipart/alternative; boundary="------------030706070101080604030104" Received-SPF: pass (shaman.nostrum.com: 173.57.89.224 is authenticated by a trusted mechanism) Subject: [CCAMP] Gen-Art LC review draft-ietf-ccamp-gmpls-ospf-g709v3-09 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:16:15 -0000 This is a multi-part message in MIME format. --------------030706070101080604030104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ccamp-gmpls-ospf-g709v3-09 Reviewer: Robert Sparks Review Date: 11-Oct-2013 IETF LC End Date: 16-Oct-2013 IESG Telechat date: Not yet scheduled for a telechat Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This document is dense (as in it puts a lot of information in a small number of characters), but it reads clearly. I did not carefully review the contents of the example fields for editorial mistakes - please be sure someone in the group has done that. The largest issue I see is on the border of being more than a nit. I'm calling it a nit because it should be very easy to fix: The sentence "Same type of modification needs to applied to the IANA-GMPLS-TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib" is not sufficient instruction to IANA to cause that registry to be modified. Please provide more precise instructions as to how this mib should change. I note also that the value 40 from RFC6060 didn't make it into the mib. The rest of these are more nitty nits: --- In section 4, I think you've repeated a MUST, and risk introducing confusion. It's awkward to point to this with paragraph numbers because of the interspersed tables, so I'll quote the relevant block: When supporting the extensions defined in this document, the Switching Capability and Encoding values MUST be used as follows: - Switching Capability = OTN-TDM - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328] Both for fixed and flexible ODUs the same switching type and encoding values MUST be used. If I read that correctly , those are the same MUST and you're saying it's a MUST no matter whether you're talking about fixed or flexible ODUs. If that's correct I suggest replacing this with: When supporting the extensions defined in this document, for both fixed and flexible ODUs, the Switching Capability and Encoding values MUST be used as follows: - Switching Capability = OTN-TDM - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328] (or leave out the fixed and flexible clarification altogether - I would not have been confused without it). --- In section 8.2, where you say "IANA will create and maintain a new registry", I suggest you say "new sub-registry". RjS --------------030706070101080604030104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ccamp-gmpls-ospf-g709v3-09
Reviewer: Robert Sparks
Review Date: 11-Oct-2013
IETF LC End Date: 16-Oct-2013
IESG Telechat date: Not yet scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits that should be fixed before publication.

This document is dense (as in it puts a lot of information in a small number of characters), but it reads clearly.
I did not carefully review the contents of the example fields for editorial mistakes - please be sure someone in the group has done that.

The largest issue I see is on the border of being more than a nit. I'm calling it a nit because it should be very easy to fix:
The sentence "Same type of modification needs to applied to the IANA-GMPLS-TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib" is not sufficient instruction to IANA to cause that registry to be modified. Please provide more precise
instructions as to how this mib should change.

I note also that the value 40 from RFC6060 didn't make it into the mib.

The rest of these are more nitty nits:

---
In section 4, I think you've repeated a MUST, and risk introducing confusion.
It's awkward to point to this with paragraph numbers because of the interspersed tables, so I'll quote the relevant block:

   When supporting the extensions defined in this document, the
   Switching Capability and Encoding values MUST be used as follows:

   - Switching Capability = OTN-TDM
   - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]

   Both for fixed and flexible ODUs the same switching type and encoding
   values MUST be used.
If I read that correctly , those are the same MUST and you're saying it's a MUST no matter whether you're talking about fixed or flexible ODUs.
If that's correct I suggest replacing this with:

   When supporting the extensions defined in this document, for both
   fixed and flexible ODUs, the Switching Capability and Encoding values 
   MUST be used as follows:

   - Switching Capability = OTN-TDM
   - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]
(or leave out the fixed and flexible clarification altogether - I would not have been confused without it). 

---

In section 8.2, where you say "IANA will create and maintain a new registry", I suggest you say "new sub-registry".

RjS
--------------030706070101080604030104-- From lberger@labn.net Mon Oct 14 06:05:53 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2167A21F9C68 for ; Mon, 14 Oct 2013 06:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.766 X-Spam-Level: X-Spam-Status: No, score=-101.766 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fl0-76Na8WT for ; Mon, 14 Oct 2013 06:05:48 -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 843A421F9C38 for ; Mon, 14 Oct 2013 06:05:47 -0700 (PDT) Received: (qmail 9363 invoked by uid 0); 14 Oct 2013 13:05:25 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.mail.unifiedlayer.com with SMTP; 14 Oct 2013 13:05:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=3Reepl/IMvwv1lMt62LzW2ukSLHefxfJdiPH3iBrnak=; b=ml4sTl7zG2V6QiE7ZYadwhVeDaxn/r2n9CXt8I8hjnjm8cHA8heOp6ppwS2lCn5mEQDy/0+is3F7TbQwDZ8KAjNBFsfXmjNpLSOkXdEJWAZRl46uf6Qu3myQrfmJLEoa; Received: from box313.bluehost.com ([69.89.31.113]:44429 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VVhpt-0003BW-GZ for ccamp@ietf.org; Mon, 14 Oct 2013 07:05:25 -0600 Message-ID: <525BEC13.10306@labn.net> Date: Mon, 14 Oct 2013 09:05:23 -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: CCAMP References: <52571423.8000407@labn.net> In-Reply-To: <52571423.8000407@labn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] Planning for Vancouver X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 13:05:53 -0000 All, We were asked to clarify a few points this planned discussion: 1) What do we expect to be presented during this discussion? As discussed in the original message, we expected presentations on use cases that are precluded from being fully supported by the current set of RFCs, as well as the identification of specific limitations that preclude full support. The presenter gets to choose & defend what they mean by (full) support. 2) Who do we expect to present? Anyone who has a draft that covers a use case, identifies a limitation, or proposes a related extension (mechanism). For those in the last category, remember to present your use case and limitations, *not* the proposed solution. 3) How does one request a slot to be included in the discussion? Go to http://www.surveymonkey.com/s/QLK9BB6, fill in the usual information and say "yes" to question 6. Lou (and Deborah) On 10/10/2013 4:54 PM, Lou Berger wrote: > > All, > We are currently scheduled to meet Thursday during the first 2.5 hour > and the last 1 hour sessions. We'd like to use a block of the time, > perhaps 30-60 minutes, to help move the discussion on > UNI/PCE/ENNI/MLN/... forward. > > The current set of GMPLS RFCs allow for different choices in > implementation and deployment by vendors and operators, both with and > without PCE. From the discussion on the list, it's clear that there are > some very different perspectives on these choices. While its not the > WG's job to dictate how operators build their networks, having some > common understanding is helpful. The topics we'd like to focus the > discussion on are: > > 1) Use cases (which are important) > e.g. which GMPLS protocols are used, layer model, > if&how PCE is used, etc. > Some drafts that touch on this include > (we may have unintentionally overlooked others): > draft-ali-ccamp-gmpls-uni-error-notification > draft-beeram-ccamp-gmpls-enni > draft-ceccadedios-ccamp-overlay-use-cases > draft-fedyk-ccamp-uni-extensions > draft-zhang-ccamp-gmpls-uni-app > draft-farrel-interconnected-te-info-exchange > > 2) Current limitations > Covering functions that are not supported by current RFCs. > e.g., it's not possible to signal a services that has > in specific use case. > Not I can't signal this object, or routing doesn't carry > this field. > > LSP diversity/similarity in certain UNI cases is an > example discussed on the list. > > Please note: we will avoid/stop discussions on any new mechanisms in > this part of the meeting. > > To present as part of this discussion, request a slot per Danielle's > message. > > Deborah and Lou > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From daniele.ceccarelli@ericsson.com Tue Oct 15 01:21:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DBC11E8178; Tue, 15 Oct 2013 01:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.336 X-Spam-Level: X-Spam-Status: No, score=-5.336 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcMmfd6w9Nld; Tue, 15 Oct 2013 01:21:18 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6F01311E8176; Tue, 15 Oct 2013 01:21:12 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-87-525cfaf459c3 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CD.FC.03802.4FAFC525; Tue, 15 Oct 2013 10:21:09 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 10:21:06 +0200 From: Daniele Ceccarelli To: Robert Sparks , General Area Review Team , "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Thread-Topic: Gen-Art LC review draft-ietf-ccamp-gmpls-ospf-g709v3-09 Thread-Index: AQHOxpTYQNmSDPZ5K0y/v1v2nJjxqJn1bOqQ Date: Tue, 15 Oct 2013 08:21:05 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48163DD1@ESESSMB301.ericsson.se> References: <52581639.4050602@nostrum.com> In-Reply-To: <52581639.4050602@nostrum.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48163DD1ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvre7XXzFBBq0z2SyezLnBYvG34TWL xdVXn1ksrs1pZHNg8Viy5CeTx6ydT1g8vlz+zBbAHMVlk5Kak1mWWqRvl8CVcfzrEbaCrQUV t7ZdZGlgnJ/UxcjJISFgIvHj6iRGCFtM4sK99WwgtpDAYUaJndtruxi5gOwljBI3Di4FSnBw sAlYSTw55AMSFxF4zigx7eJkZpAGYQEXiUfLH4LZIgKuEn19f9ggbCOJA68PsILYLAKqEtM+ TgWzeQW8JdZ3nmWBWKYl8bV5MVicU0Bb4t7jV2C9jAKyEhN2LwI7jllAXOLWk/lMEIcKSCzZ c54ZwhaVePn4HyvIbRICihLL++VATGaBfImb56QhNglKnJz5hGUCo8gsJINmIVTNQlIFUaIn cWPqFDYIW1ti2cLXzBC2rsSMf4dYkMUXMLKvYmTPTczMSS832sQIjKmDW36r7mC8c07kEKM0 B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhil8hx336r5b1oX/kbnl/Wsuzvq 6jV/d9pfnPKaU/DLPN7Foi3TRW2jpnY0MyQk/TmleLHuxL0TadylPW+X2/e6RQQ9yZ7iZrvX e/+BZoZFNQ6sKc92re9SLOde0r1I02SP6WtfP8Y7krL1aQc7PcuOlO9r45JxUNu4sHTZ109K n6tWx+4S2qvEUpyRaKjFXFScCACY65oddwIAAA== Subject: Re: [CCAMP] Gen-Art LC review draft-ietf-ccamp-gmpls-ospf-g709v3-09 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:21:23 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48163DD1ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert, Many thanks for your review. Please find comments/replies in line. BR Daniele (& co-authors) From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: venerd=EC 11 ottobre 2013 17:16 To: General Area Review Team; ccamp@ietf.org; draft-ietf-ccamp-gmpls-ospf-g= 709v3@tools.ietf.org Subject: Gen-Art LC review draft-ietf-ccamp-gmpls-ospf-g709v3-09 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ccamp-gmpls-ospf-g709v3-09 Reviewer: Robert Sparks Review Date: 11-Oct-2013 IETF LC End Date: 16-Oct-2013 IESG Telechat date: Not yet scheduled for a telechat Summary: This draft is basically ready for publication, but has nits that s= hould be fixed before publication. This document is dense (as in it puts a lot of information in a small numbe= r of characters), but it reads clearly. I did not carefully review the contents of the example fields for editorial= mistakes - please be sure someone in the group has done that. The largest issue I see is on the border of being more than a nit. I'm call= ing it a nit because it should be very easy to fix: The sentence "Same type of modification needs to applied to the IANA-GMPLS-= TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib"= is not sufficient instruction to IANA to cause that registry to be modifie= d. Please provide more precise instructions as to how this mib should change. [[Authors]] How about the following? OLD Same type of modification needs to applied to the IANA-GMPLS-TC-MIB at http= s://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib NEW Same type of modification needs to applied to the IANA-GMPLS-TC-MIB at http= s://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib, where the val= ue OTN-TDM (110), -- Time-Division-Multiplex OTN-TDM capable Will be added to the IANAGmplsSwitchingTypeTC ::=3D TEXTUAL-CONVENTION synt= ax list. I note also that the value 40 from RFC6060 didn't make it into the mib. The rest of these are more nitty nits: --- In section 4, I think you've repeated a MUST, and risk introducing confusio= n. It's awkward to point to this with paragraph numbers because of the intersp= ersed tables, so I'll quote the relevant block: When supporting the extensions defined in this document, the Switching Capability and Encoding values MUST be used as follows: - Switching Capability =3D OTN-TDM - Encoding Type =3D G.709 ODUk (Digital Path) as defined in [RFC4328] Both for fixed and flexible ODUs the same switching type and encoding values MUST be used. If I read that correctly , those are the same MUST and you're saying it's a= MUST no matter whether you're talking about fixed or flexible ODUs. If that's correct I suggest replacing this with: When supporting the extensions defined in this document, for both fixed and flexible ODUs, the Switching Capability and Encoding values MUST be used as follows: - Switching Capability =3D OTN-TDM - Encoding Type =3D G.709 ODUk (Digital Path) as defined in [RFC4328] (or leave out the fixed and flexible clarification altogether - I would not= have been confused without it). [[Authors]] Comment correct. New text adopted. --- In section 8.2, where you say "IANA will create and maintain a new registry= ", I suggest you say "new sub-registry". [[Authors]] OK RjS --_000_4A1562797D64E44993C5CBF38CF1BE48163DD1ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 <= /p>

Many thanks for your revi= ew. Please find comments/replies in line.

 <= /p>

BR
Daniele (& co-authors)

 <= /p>

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: venerd=EC 11 ottobre 2013 17:16
To: General Area Review Team; ccamp@ietf.org; draft-ietf-ccamp-gmpls= -ospf-g709v3@tools.ietf.org
Subject: Gen-Art LC review draft-ietf-ccamp-gmpls-ospf-g709v3-09

 

I am the&nb= sp;assigned Gen-ART reviewer for this draft. = For background on
Gen-ART, please see the FAQ at

<htt= p://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any&= nbsp;other Last Call comments
you may receive.

Document: draft-ietf-ccamp-gmpls-ospf-g709v3-09
Reviewer: Robert Sparks
Review Date: 11-Oct-2013
IETF LC End Date: 16-Oct-2013
IESG Telechat date: Not yet scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits that s= hould be fixed before publication.

This document is dense (as in it puts a lot of information in a small numbe= r of characters), but it reads clearly.
I did not carefully review the contents of the example fields for editorial= mistakes - please be sure someone in the group has done that.

The largest issue I see is on the border of being more than a nit. I'm call= ing it a nit because it should be very easy to fix:
The sentence "Same type of modification needs to applied to the IANA-G= MPLS-TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib"= ; is not sufficient instruction to IANA to cause that registry to be modifi= ed. Please provide more precise
instructions as to how this mib should change.

[[Authors]] How about the following?<= /p>

OLD

Same type of modifica= tion needs to applied to the IANA-GMPLS-TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib

NEW

Same type of modifica= tion needs to applied to the IANA-GMPLS-TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib, whe= re the value

OTN-TDM (110), &= nbsp;   -- Time-Division-Multiplex OTN-TDM capable

Will be added to the = IANAGmplsSwitchingTypeTC ::=3D TEXTUAL-CONVENTION syntax list.



I note also that the value 40 from RFC6060 didn't make it into the mib.

The rest of these are more nitty nits:

---
In section 4, I think you've repeated a MUST, and risk introducing confusio= n.
It's awkward to point to this with paragraph numbers because of the intersp= ersed tables, so I'll quote the relevant block:

   When supporting the extensions defined in this document, =
the
   Switching Capability and Encoding values MUST be used as =
follows:
 
   - Switching Capability =3D OTN-TDM
   - Encoding Type =3D G.709 ODUk (Digital Path) as defined =
in [RFC4328]
 
   Both for fixed and flexible ODUs the same switching type =
and encoding
   values MUST be used.

If I read that correc= tly , those are the same MUST and you're saying it's a MUST no matter wheth= er you're talking about fixed or flexible ODUs.
If that's correct I suggest replacing this with:

   When supporting the extensions defined in this document, =
for both
   fixed and flexible ODUs, the Switching Capability and Enc=
oding values 
   MUST be used as follows:
 
   - Switching Capability =3D OTN-TDM
   - Encoding Type =3D G.709 ODUk (Digital Path) as defined =
in [RFC4328]

(or leave out the fixed and flexible clarification a= ltogether - I would not have been confused without it). 

[[Authors]] Comment= correct. New text adopted.



---

In section 8.2, where you say "IANA will create and maintain a new reg= istry", I suggest you say "new sub-registry".

[[Authors]] OK=



RjS

--_000_4A1562797D64E44993C5CBF38CF1BE48163DD1ESESSMB301ericsso_-- From daniele.ceccarelli@ericsson.com Tue Oct 15 01:21:48 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [CCAMP] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:21:50 -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 adrian@olddog.co.uk Wed Oct 16 11:37:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E732711E817B for ; Wed, 16 Oct 2013 11:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 6T9k6-7EAZRJ for ; Wed, 16 Oct 2013 11:37:29 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id C037611E814C for ; Wed, 16 Oct 2013 11:37:28 -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 r9GIbR1F014805; Wed, 16 Oct 2013 19:37:27 +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 r9GIbQFs014788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Oct 2013 19:37:26 +0100 From: "Adrian Farrel" To: Date: Wed, 16 Oct 2013 19:37:25 +0100 Message-ID: <013201ceca9e$c2bc0ab0$48342010$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7Kni6QedlajqGxR0SxjsRig87Mng== Content-Language: en-gb Cc: 'CCAMP WG' Subject: Re: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 18:37:42 -0000 It looks like everything was agreed for the next revision, but then you = stalled. Can you get a revision out really fast? If you do I can get it to the = IESG before Vancouver. If you can't the OSPF document gets backed up = behind it. Thanks, Adrian > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On = Behalf Of > Joel M. Halpern > Sent: 02 October 2013 19:33 > To: Lou Berger > 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 >=20 > While I tend to think of optimizations and gaps as very different > things, I can live with the text changes. > Yours, > Joel >=20 > 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=C3=AC 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=E2=80=99t 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=C3=AC 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 acee.lindem@ericsson.com Wed Oct 16 13:19:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [CCAMP] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 rrao@infinera.com Wed Oct 16 16:52:31 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CAE11E8153 for ; Wed, 16 Oct 2013 16:52:31 -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 1npKCDuLj01p for ; Wed, 16 Oct 2013 16:52:27 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 26C0021F99E7 for ; Wed, 16 Oct 2013 16:52:27 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Wed, 16 Oct 2013 16:52:26 -0700 From: Rajan Rao To: "CCAMP (ccamp@ietf.org)" Thread-Topic: New Version Notification for draft-dhillon-ccamp-super-channel-ospfte-ext-06.txt Thread-Index: AQHOysk58SwxEJRFVU6fPzkiQvUJppn3/hWQ Date: Wed, 16 Oct 2013 23:52:25 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D3FBF7DAC@SV-EXDB-PROD1.infinera.com> References: <20131016234122.5015.21888.idtracker@ietfa.amsl.com> In-Reply-To: <20131016234122.5015.21888.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Marco Sosa , Abinder Dhillon , Iftekhar Hussain Subject: Re: [CCAMP] New Version Notification for draft-dhillon-ccamp-super-channel-ospfte-ext-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 23:52:31 -0000 SGksDQoNCkkgaGF2ZSByZWZyZXNoZWQgRmxleEdyaWQgcm91dGluZyBleHRlbnNpb25zIGRyYWZ0 IHdpdGggbWlub3IgZWRpdHMuICBDb21tZW50cyBhcmUgd2VsY29tZS4NCg0KVGhhbmtzDQpSYWph bg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciAxNiwgMjAxMyA0OjQxIFBNDQpUbzogSWZ0ZWtoYXIgSHVzc2FpbjsgTWFyY28g U29zYTsgUmFqYW4gUmFvOyBBYmluZGVyIERoaWxsb247IE1hcmNvIFNvc2ENClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGhpbGxvbi1jY2FtcC1zdXBlci1jaGFu bmVsLW9zcGZ0ZS1leHQtMDYudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRo aWxsb24tY2NhbXAtc3VwZXItY2hhbm5lbC1vc3BmdGUtZXh0LTA2LnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBJZnRla2hhciBIdXNzYWluIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1kaGlsbG9uLWNjYW1wLXN1cGVy LWNoYW5uZWwtb3NwZnRlLWV4dA0KUmV2aXNpb246CSAwNg0KVGl0bGU6CQkgT1NQRlRFIGV4dGVu c2lvbiB0byBzdXBwb3J0IEdNUExTIGZvciBGbGV4IEdyaWQNCkNyZWF0aW9uIGRhdGU6CSAyMDEz LTEwLTE2DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczog MTINClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtZGhpbGxvbi1jY2FtcC1zdXBlci1jaGFubmVsLW9zcGZ0ZS1leHQtMDYudHh0DQpTdGF0 dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZGhpbGxv bi1jY2FtcC1zdXBlci1jaGFubmVsLW9zcGZ0ZS1leHQNCkh0bWxpemVkOiAgICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGhpbGxvbi1jY2FtcC1zdXBlci1jaGFubmVsLW9z cGZ0ZS1leHQtMDYNCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtZGhpbGxvbi1jY2FtcC1zdXBlci1jaGFubmVsLW9zcGZ0ZS1leHQtMDYNCg0K QWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgZXh0ZW5zaW9uIHRvIFRF TElOSyBMU0Egb2YgT1NQRiByb3V0aW5nDQogICBwcm90b2NvbCBbUkZDNDIwM10gWzNdIGluIHN1 cHBvcnQgb2YgR01QTFMgWzFdIGZvciBmbGV4LWdyaWQNCiAgIG5ldHdvcmtzIFsyXS4NCg0KDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From internet-drafts@ietf.org Thu Oct 17 00:28:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA5D11E8241; Thu, 17 Oct 2013 00:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhgoqzpEjYYJ; Thu, 17 Oct 2013 00:28:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C90E621F9396; Thu, 17 Oct 2013 00:28:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131017072838.4800.65475.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 00:28:38 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-12.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 07:28:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Evaluation of existing GMPLS encoding against G.709v3 Op= tical Transport Networks (OTN) Author(s) : Sergio Belotti Pietro Vittorio Grandi Daniele Ceccarelli Diego Caviglia Fatai Zhang Dan Li Filename : draft-ietf-ccamp-otn-g709-info-model-12.txt Pages : 22 Date : 2013-10-17 Abstract: ITU-T recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709-2012 OTN networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-otn-g709-info-model-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniele.ceccarelli@ericsson.com Thu Oct 17 00:37:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D3F11E8258 for ; Thu, 17 Oct 2013 00:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.689 X-Spam-Level: X-Spam-Status: No, score=-5.689 tagged_above=-999 required=5 tests=[AWL=0.560, 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 eejQKZbmbvud for ; Thu, 17 Oct 2013 00:37:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D933611E8250 for ; Thu, 17 Oct 2013 00:37:23 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-e9-525f93b222fb Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5D.DE.03802.2B39F525; Thu, 17 Oct 2013 09:37:22 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Thu, 17 Oct 2013 09:37:21 +0200 From: Daniele Ceccarelli To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt Thread-Index: Ac7Kni6QedlajqGxR0SxjsRig87MngAbFjBA Date: Thu, 17 Oct 2013 07:37:20 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48164CFC@ESESSMB301.ericsson.se> References: <013201ceca9e$c2bc0ab0$48342010$@olddog.co.uk> In-Reply-To: <013201ceca9e$c2bc0ab0$48342010$@olddog.co.uk> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6myfFBBv9vC1r86LnBbPFkzg0W i2Vz9jM5MHssWfKTyWPF5pWMHl8uf2YLYI7isklJzcksSy3St0vgyvja0sVc8G89Y8WaN6/Y Gxj3rGbsYuTkkBAwkTjetpQFwhaTuHBvPVsXIxeHkMBhRomjU7ewQzhLGCW+Nv4BynBwsAlY STw55AMSFxFYwSjxvnseWDezgLzE8f9nwaYKC7hLdDV+YgKpFxHwkOhuyAMJiwgYSVze8pod xGYRUJW4sOcbmM0r4C3RcOojE4gtBDS+6/4GsDingLVE67omVhCbUUBWYsLuRYwQq8Qlbj2Z zwRxtIDEkj3nmSFsUYmXj/+xQtiKElenLwc7gVlAU2L9Ln2IVkWJKd0PodYKSpyc+YRlAqPY LCRTZyF0zELSMQtJxwJGllWM7LmJmTnp5UabGIFxc3DLb9UdjHfOiRxilOZgURLn/fDWOUhI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo4f9g0s7i9bfs5hSUnvvgbmVqAjPFTemB0/kbbtS 5zty/zEJXmohfudEzrMb5lWL09ct0rqp96U9eup2aeF58vWyP3kWKz6KED/kVXP0NYvFo7M3 /3O+qGULan4wc9KXz6oczc3buNlsjyT1S3fmnuN/222gNLmDa92MGxfN509WTbv/prbfT4ml OCPRUIu5qDgRAAGVaRFpAgAA Cc: 'CCAMP WG' Subject: Re: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 07:37:32 -0000 SSB3YXMgMTAwJSBzdXJlIEkgaGFkIHVwbG9hZGVkIGl0Li4uYXBwYXJlbnRseSBpJ20gb25lIG9m IHRoZSByYXJlIGNhc2VzIG9mICJzZW5pbGUgZGVtZW50aWEiIGF0IHRoZSBhZ2Ugb2YgMzIgOikN Cg0KVXBsb2FkZWQgcmlnaHQgbm93Lg0KDQpNYW55IHRoYW5rcywNCkRhbmllbGUNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBZHJpYW4gRmFycmVsIFttYWlsdG86YWRy aWFuQG9sZGRvZy5jby51a10NCj4gU2VudDogbWVyY29sZWTDrCAxNiBvdHRvYnJlIDIwMTMgMjA6 MzcNCj4gVG86IGRyYWZ0LWlldGYtY2NhbXAtb3RuLWc3MDktaW5mby1tb2RlbC5hbGxAdG9vbHMu aWV0Zi5vcmcNCj4gQ2M6ICdDQ0FNUCBXRycNCj4gU3ViamVjdDogUkU6IFJ0Z0RpciByZXZpZXc6 IGRyYWZ0LWlldGYtY2NhbXAtb3RuLWc3MDktaW5mby1tb2RlbC0xMS50eHQNCj4gDQo+IEl0IGxv b2tzIGxpa2UgZXZlcnl0aGluZyB3YXMgYWdyZWVkIGZvciB0aGUgbmV4dCByZXZpc2lvbiwgYnV0 IHRoZW4geW91IHN0YWxsZWQuDQo+IA0KPiBDYW4geW91IGdldCBhIHJldmlzaW9uIG91dCByZWFs bHkgZmFzdD8gSWYgeW91IGRvIEkgY2FuIGdldCBpdCB0byB0aGUgSUVTRyBiZWZvcmUNCj4gVmFu Y291dmVyLiBJZiB5b3UgY2FuJ3QgdGhlIE9TUEYgZG9jdW1lbnQgZ2V0cyBiYWNrZWQgdXAgYmVo aW5kIGl0Lg0KPiANCj4gVGhhbmtzLA0KPiBBZHJpYW4NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpy dGctZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVy bg0KPiA+IFNlbnQ6IDAyIE9jdG9iZXIgMjAxMyAxOTozMw0KPiA+IFRvOiBMb3UgQmVyZ2VyDQo+ ID4gQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7IENDQU1QIFdHOyBydGctYWRzQHRvb2xzLmlldGYub3Jn Ow0KPiA+IGRyYWZ0LWlldGYtY2NhbXAtb3RuLSBnNzA5LWluZm8tbW9kZWwuYWxsQHRvb2xzLmll dGYub3JnOyBEYW5pZWxlDQo+ID4gQ2VjY2FyZWxsaTsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8p DQo+ID4gU3ViamVjdDogUmU6IFtSVEctRElSXSBJOiBSOiBbQ0NBTVBdIFJ0Z0RpciByZXZpZXc6 DQo+ID4gZHJhZnQtaWV0Zi1jY2FtcC1vdG4tZzcwOS0gaW5mby1tb2RlbC0xMS50eHQNCj4gPg0K PiA+IFdoaWxlIEkgdGVuZCB0byB0aGluayBvZiBvcHRpbWl6YXRpb25zIGFuZCBnYXBzIGFzIHZl cnkgZGlmZmVyZW50DQo+ID4gdGhpbmdzLCBJIGNhbiBsaXZlIHdpdGggdGhlIHRleHQgY2hhbmdl cy4NCj4gPiBZb3VycywNCj4gPiBKb2VsDQo+ID4NCj4gPiBPbiAxMC8xLzEzIDg6MjYgQU0sIExv dSBCZXJnZXIgd3JvdGU6DQo+ID4gPiBEYW5pZWxlLA0KPiA+ID4NCj4gPiA+PiBTb3VuZHMgcmVh c29uYWJsZT8NCj4gPiA+DQo+ID4gPiBXaGlsZSBJIHN0aWxsIGxpa2Ugb3B0aW9uIDMsIEkgY2Fu IGxpdmUgd2l0aCB0aGUgcmV2aXNlZCB0ZXh0Lg0KPiA+ID4NCj4gPiA+IEpvZWwsDQo+ID4gPg0K PiA+ID4gSXMgdGhlIHJldmlzZWQgdGV4dCBhY2NlcHRhYmxlPw0KPiA+ID4NCj4gPiA+IExvdQ0K PiA+ID4NCj4gPiA+IE9uIDEwLzAxLzIwMTMgMDM6NDAgQU0sIERhbmllbGUgQ2VjY2FyZWxsaSB3 cm90ZToNCj4gPiA+PiBIaSBMb3UsDQo+ID4gPj4NCj4gPiA+PiBObyBubyBubywgbm8gT1NQRiBk aXNjdXNzaW9uIHJlb3BlbmluZy4gVGhlIE9TUEYgZHJhZnRzIGNsZWFybHkNCj4gPiA+PiBzdGF0 ZXMgdGhhdA0KPiA+IG9ubHkgc3VwcG9ydGVkIHByaW9yaXRpZXMgbXVzdCBiZSBhZHZlcnRpc2Vk LCB3aGF0IGRvZXMgbm90IHNheSBpcyB3aHkNCj4gPiAoaS5lLiBmb3Igb3B0aW1pemF0aW9uKS4N Cj4gPiA+PiBXaXRoIHNlY3Rpb24gOCBhbmQgc2VjdGlvbiAxMCBtb2RpZmllZCBhcyBiZWxvdywg dGhlcmUgaXMgbm8gbmVlZA0KPiA+ID4+IHRvIG1vZGlmeQ0KPiA+IE9TUEYgYXMgdGhlICJ3aHki IGlzIHN0YXRlZCBpbiB0aGUgZ2FwLWFuYWx5c2lzIGRyYWZ0Lg0KPiA+ID4+DQo+ID4gPj4gVHJ5 aW5nIHRvIHN1bW1hcml6ZS4NCj4gPiA+PiBTZWN0aW9uIDggYXMgeW91IHByb3Bvc2VkOg0KPiA+ ID4+PiA4LiBNYXhpbXVtIExTUCBCYW5kd2lkdGgNCj4gPiA+Pj4gTWF4aW11bSBMU1AgYmFuZHdp ZHRoIGlzIGN1cnJlbnRseSBhZHZlcnRpc2VkIHBlciBwcmlvcml0eSBpbiB0aGUNCj4gPiA+Pj4g Y29tbW9uIHBhcnQgb2YgdGhlIElTQ0QuICBTZWN0aW9uIDUgcmV2aWV3cyBzb21lIG9mIHRoZQ0K PiA+ID4+PiBpbXBsaWNhdGlvbnMgb2YgYWR2ZXJ0aXNpbmcgT1ROIG5ldHdvcmsgaW5mb3JtYXRp b24gdXNpbmcgSVNDRHMsDQo+ID4gPj4+IGFuZCBpZGVudGlmaWVzIHRoZSBuZWVkIGZvciBhIG1v cmUgb3B0aW1pemVkIHNvbHV0aW9uLg0KPiA+ID4+PiBXaGlsZSBzdHJpY3RseSBub3QgcmVxdWly ZWQsIHN1Y2ggYW4gb3B0aW1pemF0aW9uIGVmZm9ydCBzaG91bGQNCj4gPiA+Pj4gYWxzbyBjb25z aWRlciB0aGUgb3B0aW1pemF0aW9uIG9mIHRoZSBwZXIgcHJpb3JpdHkgbWF4aW11bSBMU1ANCj4g PiA+Pj4gYmFuZHdpZHRoIGFkdmVydGlzZW1lbnQgb2YgYm90aCBmaXhlZCBhbmQgdmFyaWFibGUg T0RVIHR5cGVzLg0KPiA+ID4+DQo+ID4gPj4gU2VjdGlvbiAxMCAoYXMgcGVyIHlvdXIgbGFzdCBw cm9wb3NhbCkNCj4gPiA+Pj4gIltSRkM0MjAyXSBkZWZpbmVzIDggcHJpb3JpdGllcyBmb3IgcmVz b3VyY2UgYXZhaWxhYmlsaXR5IGFuZA0KPiA+ID4+PiB1c2FnZS4gQXMgZGVmaW5lZCwgZWFjaCBp cyBhZHZlcnRpc2VkIGluZGVwZW5kZW50IG9mIHRoZSBudW1iZXIgb2YNCj4gPiA+Pj4gcHJpb3Jp dGllcyBzdXBwb3J0ZWQgYnkgYSBuZXR3b3JrLCBhbmQgZXZlbiB1bnN1cHBvcnRlZCBwcmlvcml0 aWVzDQo+ID4gPj4+IGFyZSBpbmNsdWRlZC4uIEFzIGlzIHRoZSBjYXNlIGluIFNlY3Rpb24gOCwg YWRkcmVzc2luZyBhbnkNCj4gPiA+Pj4gaW5lZmZpY2llbmN5IHdpdGggc3VjaCBhZHZlcnRpc2Vt ZW50cyBpcyBub3QgcmVxdWlyZWQgdG8gc3VwcG9ydA0KPiA+ID4+PiBPVE4gbmV0d29ya3MuICBC dXQgYW55IHN1Y2ggaW5lZmZpY2llbmN5IHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQNCj4gPiA+ Pj4gYXMgcGFydCBvZiB0aGUgb3B0aW1pemF0aW9uIGVmZm9ydCBpZGVudGlmaWVkIGluIFNlY3Rp b24gNS4iDQo+ID4gPj4NCj4gPiA+PiBTb3VuZHMgcmVhc29uYWJsZT8NCj4gPiA+PiBCUg0KPiA+ ID4+IEF1dGhvcnMNCj4gPiA+Pg0KPiA+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+ID4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4gPiA+ Pj4gU2VudDogbHVuZWTDrCAzMCBzZXR0ZW1icmUgMjAxMyAyMzozOQ0KPiA+ID4+PiBUbzogQkVM T1RUSSwgU0VSR0lPIChTRVJHSU8pDQo+ID4gPj4+IENjOiBKb2VsIE0uIEhhbHBlcm47IHJ0Zy1k aXJAaWV0Zi5vcmc7IENDQU1QIFdHOw0KPiA+ID4+PiBkcmFmdC1pZXRmLWNjYW1wLW90bi1nNzA5 LSBpbmZvLW1vZGVsLmFsbEB0b29scy5pZXRmLm9yZzsNCj4gPiA+Pj4gcnRnLWFkc0B0b29scy5p ZXRmLm9yZw0KPiA+ID4+PiBTdWJqZWN0OiBSZTogSTogW1JURy1ESVJdIFI6IFtDQ0FNUF0gUnRn RGlyIHJldmlldzoNCj4gPiA+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1vdG4tIGc3MDktaW5mby1tb2Rl bC0xMS50eHQNCj4gPiA+Pj4NCj4gPiA+Pj4gU2VyZ2lvLA0KPiA+ID4+PiAJU2VlIGJlbG93Lg0K PiA+ID4+Pg0KPiA+ID4+PiBPbiA5LzMwLzIwMTMgMTE6MTUgQU0sIEJFTE9UVEksIFNFUkdJTyAo U0VSR0lPKSB3cm90ZToNCj4gPiA+Pj4+IExvdSwNCj4gPiA+Pj4+IG91ciBhbnN3ZXIgaW4gbGlu ZSBtYXJrZWQgImF1dGhvcnMiDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gVGhhbmtzDQo+ID4gPj4+Pg0K PiA+ID4+Pj4gQXV0aG9ycw0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+ID4+Pj4gLS0tLS0NCj4gPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPj4+PiBEYW5p ZWxlLA0KPiA+ID4+Pj4NCj4gPiA+Pj4+IE9uIDA5LzMwLzIwMTMgMDk6NTkgQU0sIERhbmllbGUg Q2VjY2FyZWxsaSB3cm90ZToNCj4gPiA+Pj4+PiBMb3UsIEpvZWwsDQo+ID4gPj4+Pj4NCj4gPiA+ Pj4+PiBUaGUgdGV4dCBwcm9wb3NlZCBzb3VuZHMgZ29vZCBidXQgaXQgb25seSBzdGF0ZXMgdGhl IHByb2JsZW0NCj4gPiA+Pj4+PiB3aXRob3V0DQo+ID4gPj4+IGFueSBoaW50IG9uIHRoZSBzb2x1 dGlvbnMgKGkuZS4gc2F5cyB0aGVyZSBpcyBhbiBpbmVmZmljaWVuY3kgYnV0DQo+ID4gPj4+IGRv ZXNu4oCZdCBzYXkgdGhhdCBhZHZlcnRpc2luZyBvbmx5IHN1cHBvcnRlZCBwcmlvcml0aWVzIGlz IGEgd2F5IHRvDQo+ID4gPj4+IGFkZHJlc3Mgc3VjaCBpbmVmZmljaWVuY3kpLg0KPiA+ID4+Pj4+ IFRoZXJlIGFyZSB0d28gb3B0aW9uczoNCj4gPiA+Pj4+DQo+ID4gPj4+PiBXZWxsLCB0aGVyZSdz IGFsc28gdGhlIG9wdGlvbiBvZiBkcm9wcGluZyB0aGUgc2VjdGlvbnMuDQo+ID4gPj4+Pg0KPiA+ ID4+Pj4gQXV0aG9ycz4gYXMgYWxyZWFkeSBzYWlkIFRoZSBiYXNpYyBzY29wZSBvZiB0aGUgZHJh ZnQgaXMgdG8NCj4gPiA+Pj4+IEF1dGhvcnM+IHVuZGVybGluZQ0KPiA+ID4+Pj4gZ2FwcywgYW5k IGV2ZW4gaWYgd2hhdCBkZXNjcmliZWQgaW4gQ2guOCBhbmQgMTAsIGRvIG5vdCBwcmV2ZW50DQo+ ID4gPj4+PiByb3V0aW5nIHRvIHdvcmssIGl0IGlzIHN1Z2dlc3RlZCBoZXJlIGFuIHJlcXVpcmVt ZW50IGZvcg0KPiA+ID4+Pj4gb3B0aW1pemF0aW9uIGJhc2VkIG9uIE9UTiByZXF1aXJlbWVudHMg KGUuZy4gbm8gbmVlZCB0byBhZHZlcnRpc2UNCj4gPiA+Pj4+IGZpeGVkIE9EVSBjb250YWluZXIg TWF4IExTUCBCVyBzaW5jZSBpbXBsaWNpdCBpbiB0aGUgc2lnbmFsDQo+ID4gPj4+PiB0eXBlLiku IFNvLCBpbiBvdXIgb3Bpbmlvbiwgbm8gZHJvcHBpbmcuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4g PiA+Pj4+PiAxLiBJbXByb3ZlIHRoZSB0ZXh0ICh0aGUgTkVXIG9uZSkgc2F5aW5nIGUuZy4gb25s eSB0aGUNCj4gPiA+Pj4+PiBhZHZlcnRpc2VtZW50IG9mIGJhbmR3aWR0aCBmb3Igc3VwcG9ydGVk IHByaW9yaXRpZXMgaXMgbmVlZGVkDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gSSBhbHdheXMgZmluZCBp dCBlYXNpZXIgdG8gbWFrZSBhIGRlY2lzaW9uIHdoZW4gdGhlIHRyYWRlb2ZmcyBhcmUNCj4gY29u Y3JldGUuDQo+ID4gPj4+IENhbiB5b3UgKGF1dGhvcnMpIHByb3Bvc2UgcmV2aXNlZCB0ZXh0Pw0K PiA+ID4+Pj4NCj4gPiA+Pj4+IEF1dGhvcnM+ICJbUkZDNDIwMl0gZGVmaW5lcyA4IHByaW9yaXRp ZXMgZm9yIHJlc291cmNlDQo+ID4gPj4+PiBBdXRob3JzPiBhdmFpbGFiaWxpdHkNCj4gPiA+Pj4+ IGFuZCB1c2FnZS4gQXMgZGVmaW5lZCwgZWFjaCBpcyBhZHZlcnRpc2VkIGluZGVwZW5kZW50IG9m IHRoZQ0KPiA+ID4+Pj4gbnVtYmVyIG9mIHByaW9yaXRpZXMgc3VwcG9ydGVkIGJ5IGEgbmV0d29y ayB2cy4gdG8gYWR2ZXJ0aXNlIG9ubHkNCj4gPiA+Pj4+IHRoZSBpbmZvcm1hdGlvbiByZWxhdGVk IHRvIHRoZSByZWFsbHkgc3VwcG9ydGVkIHByaW9yaXRpZXMgYXMNCj4gPiA+Pj4+IHBvc3NpYmxl IG9wdGltaXphdGlvbiBpbXByb3ZlbWVudC4gQXMgaXMgdGhlIGNhc2UgaW4gU2VjdGlvbiA4LA0K PiA+ID4+Pj4gYWRkcmVzc2luZyBhbnkgaW5lZmZpY2llbmN5IHdpdGggc3VjaCBhZHZlcnRpc2Vt ZW50cyBpcyBub3QNCj4gPiA+Pj4+IHJlcXVpcmVkIHRvIHN1cHBvcnQgT1ROIG5ldHdvcmtzLiAg QnV0IGFueSBzdWNoIGluZWZmaWNpZW5jeQ0KPiA+ID4+Pj4gc2hvdWxkIGFsc28gYmUgY29uc2lk ZXJlZCBhcyBwYXJ0IG9mIHRoZSBvcHRpbWl6YXRpb24gZWZmb3J0IGlkZW50aWZpZWQNCj4gaW4g U2VjdGlvbiA1LiINCj4gPiA+Pj4+DQo+ID4gPj4+DQo+ID4gPj4+IEhvdyBhYm91dDoNCj4gPiA+ Pj4gT0xEDQo+ID4gPj4+ICAgIEFzIGRlZmluZWQsIGVhY2ggaXMgYWR2ZXJ0aXNlZCBpbmRlcGVu ZGVudCBvZiB0aGUgbnVtYmVyDQo+ID4gPj4+ICAgIG9mIHByaW9yaXRpZXMgc3VwcG9ydGVkIGJ5 IGEgbmV0d29yayB2cy4gdG8gYWR2ZXJ0aXNlIG9ubHkgdGhlDQo+ID4gPj4+ICAgIGluZm9ybWF0 aW9uIHJlbGF0ZWQgdG8gdGhlIHJlYWxseSBzdXBwb3J0ZWQgcHJpb3JpdGllcyBhcyBwb3NzaWJs ZQ0KPiA+ID4+PiAgICBvcHRpbWl6YXRpb24gaW1wcm92ZW1lbnQuDQo+ID4gPj4+IE5FVw0KPiA+ ID4+PiAgICBBcyBkZWZpbmVkLCBlYWNoIGlzIGFkdmVydGlzZWQgaW5kZXBlbmRlbnQgb2YgdGhl IG51bWJlcg0KPiA+ID4+PiAgICBvZiBwcmlvcml0aWVzIHN1cHBvcnRlZCBieSBhIG5ldHdvcmss IGFuZCBldmVuIHVuc3VwcG9ydGVkDQo+ID4gPj4+ICAgIHByaW9yaXRpZXMgYXJlIGluY2x1ZGVk Lg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+Pj4+IDIuIEFkb3B0IHRoZSBORVcgdGV4dCBhcyBp dCBpcyBhbmQgbW92ZSB0aGUgcmVtYWluaW5nIHBhcnQgb2YNCj4gPiA+Pj4+PiB0aGUgdGV4dCB0 bw0KPiA+ID4+PiB0aGUgT1NQRiBkcmFmdCAod2hlcmUgd2Ugc2F5IGUuZy4gdGhhdCBvbmx5IGJh bmR3aWR0aCBmb3INCj4gPiA+Pj4gc3VwcG9ydGVyIHByaW9yaXRpZXMgbmVlZCB0byBiZSBhZHZl cnRpc2VkIGJ1dCBkb24ndCBzYXkgd2h5KS4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4gRG9lc24ndCB0 aGUgT1NQRiBkcmFmdCBhbHJlYWR5IGFscmVhZHkgZG8gd2hhdCB5b3Ugc2F5LCBpLmUuLA0KPiA+ ID4+Pj4gYWR2ZXJ0aXNlIG9ubHkNCj4gPiA+Pj4gdXNlZCBwcmlvcml0aWVzLiBXaGF0IHNwZWNp ZmljIHRleHQgYXJlIHlvdSBwcm9wb3NpbmcgdG8gYWRkPw0KPiA+ID4+Pj4+DQo+ID4gPj4+PiBB dXRob3JzPiBObywgaXQgZG9lc24ndC4NCj4gPiA+Pj4NCj4gPiA+Pj4gU28gdGhlIE9TUEYgZHJh ZnQgY3VycmVudGx5IHNheXMgdGhhdCBhbGwgcHJpb3JpdGllcyBhcmUgYWR2ZXJ0aXNlZD8NCj4g PiA+Pj4gUmVhbGx5Pz8/PyAgSWYgc28gYWRkaW5nIHRoaXMgbmV3IHRleHQgZG9lcyBsaXR0bGUg dG8gY2hhbmdlIHRoaXMuDQo+ID4gPj4+IEFyZSB5b3UgcmVhbGx5IGFkdm9jYXRpbmcgcmVvcGVu aW5nIGRpc2N1c3Npb24gb24gdGhlIE9TUEYgZHJhZnQgaW4NCj4gYWRkaXRpb24gdG8gdGhpcyBv bmU/DQo+ID4gPj4+DQo+ID4gPj4+IExvdQ0KPiA+ID4+Pg0KPiA+ID4+Pj4gLi4uIFRleHQgcHJv cG9zZWQgaXMgdGhlIG9sZCBvbmUgdGhhdCB0b3RhbGx5IGFkZHJlc3MgZXhwbGFuYXRpb24NCj4g PiA+Pj4+IGluIG91ciB2aWV3DQo+ID4gPj4+IDoiIFtSRkM0MjAyXSBkZWZpbmVzIDggcHJpb3Jp dGllcyBmb3IgcmVzb3VyY2UgYXZhaWxhYmlsaXR5IGFuZA0KPiA+ID4+PiB1c2FnZS4gQWxsIG9m IHRoZW0gaGF2ZSB0byBiZSBhZHZlcnRpc2VkIGluZGVwZW5kZW50bHkgb24gdGhlDQo+ID4gPj4+ IG51bWJlciBvZiBwcmlvcml0aWVzIHN1cHBvcnRlZCBieSB0aGUgaW1wbGVtZW50YXRpb24uQ29u c2lkZXJpbmcNCj4gPiA+Pj4gdGhhdCB0aGUgYWR2ZXJ0aXNlbWVudCBvZiBhbGwgdGhlIGRpZmZl cmVudCBzdXBwb3J0ZWQgc2lnbmFsIHR5cGVzDQo+ID4gPj4+IHdpbGwgb3JpZ2luYXRlIGxhcmdl IExTQXMsIGl0IGlzIGFkdmlzZWQgdG8gYWR2ZXJ0aXNlIG9ubHkgdGhlIGluZm9ybWF0aW9uDQo+ IHJlbGF0ZWQgdG8gdGhlIHJlYWxseSBzdXBwb3J0ZWQgcHJpb3JpdGllcy4NCj4gPiA+Pj4+DQo+ ID4gPj4+PiBUaGFua3MsDQo+ID4gPj4+PiBMb3UNCj4gPiA+Pj4+DQo+ID4gPj4+Pj4gUmUgYWxs IHRoZSBvdGhlciBjb21tZW50cy9zdWdnZXN0aW9uIHdlJ3JlIG9rIGFuZCB3aWxsIGZpeCB0aGVt DQo+ID4gPj4+Pj4gYXMNCj4gPiA+Pj4gc3VnZ2VzdGVkLg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4g QlINCj4gPiA+Pj4+PiBBdXRob3JzDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiA+Pj4+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJn ZXJAbGFibi5uZXRdDQo+ID4gPj4+Pj4+IFNlbnQ6IHZlbmVyZMOsIDI3IHNldHRlbWJyZSAyMDEz IDIxOjU1DQo+ID4gPj4+Pj4+IFRvOiBKb2VsIE0uIEhhbHBlcm4NCj4gPiA+Pj4+Pj4gQ2M6IHJ0 Zy1kaXJAaWV0Zi5vcmc7IENDQU1QIFdHOyBkcmFmdC1pZXRmLWNjYW1wLW90bi1nNzA5LWluZm8t DQo+ID4gPj4+Pj4+IG1vZGVsLmFsbEB0b29scy5pZXRmLm9yZzsgQkVMT1RUSSwgU0VSR0lPIFwo U0VSR0lPXCk7DQo+ID4gPj4+Pj4+IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+Pj4+Pj4g U3ViamVjdDogUmU6IFtSVEctRElSXSBSOiBbQ0NBTVBdIFJ0Z0RpciByZXZpZXc6DQo+ID4gPj4+ Pj4+IGRyYWZ0LWlldGYtY2NhbXAtb3RuLWc3MDktIGluZm8tbW9kZWwtMTEudHh0DQo+ID4gPj4+ Pj4+DQo+ID4gPj4+Pj4+IEdyZWF0LiBTbyB5b3UgYW5kIEkgYXJlIGluIGFncmVlbWVudC4gV2Un bGwgc2VlIHdoYXQgdGhlDQo+ID4gPj4+Pj4+IGF1dGhvcnMgaGF2ZSB0byBzYXkuLi4NCj4gPiA+ Pj4+Pj4NCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gT24gMzoyNnBtLCBTZXB0ZW1iZXIgMjcsIDIw MTMsIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4gPiA+Pj4+Pj4+IFRoZSBwcm9wb3NlZCBhbHRl cm5hdGl2ZSB0ZXh0IHdvdWxkIHN1ZmZpY2UsIGFsdGhvdWdoDQo+ID4gPj4+Pj4+PiBwZXJzb25h bGx5IEkgd291bGQganVzdCByZW1vdmUgdGhlIHR3byBzZWN0aW9ucy4NCj4gPiA+Pj4+Pj4+DQo+ ID4gPj4+Pj4+PiBZb3VycywNCj4gPiA+Pj4+Pj4+IEpvZWwNCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+ Pj4+PiBPbiA5LzI3LzEzIDM6MDAgUE0sIExvdSBCZXJnZXIgd3JvdGU6DQo+ID4gPj4+Pj4+Pj4g Sm9lbCwNCj4gPiA+Pj4+Pj4+PiBEb2VzIHRoZSBwcm9wb3NlZCBhbHRuZXJhdGUgdGV4dCBhZGRy ZXNzIHlvdXIgY29tbWVudA0KPiA+ID4+Pj4+Pj4+IChhc3N1bWluZyB0aGUgYXV0aG9yJ3Mgd2Fu dCB0byBrZWVwIHRoZSBzZWN0aW9ucyk/ICBJZiBub3QsDQo+ID4gPj4+Pj4+Pj4gY2FuIHlvdSBz dWdnZXN0DQo+ID4gPj4+IGNoYW5nZXM/DQo+ID4gPj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+PiBUaGFu a3MsDQo+ID4gPj4+Pj4+Pj4gTG91DQo+ID4gPj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+PiBPbiAwOS8y Ny8yMDEzIDAyOjMwIFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4gPj4+Pj4+Pj4+IExv dSwgdGhhbmtzIGZvciBzdGVwcGluZyBpbi4NCj4gPiA+Pj4+Pj4+Pj4gV2l0aCB5b3VyIGV4cGxh bmF0aW9uIEkgY2FuIGxpdmUgd2l0aCB0aGUgTFNQIHRleHQgYXMgaXQgaXMuDQo+ID4gPj4+Pj4+ Pj4+DQo+ID4gPj4+Pj4+Pj4+IEkgbG9vayBmb3J3YXJkIHRvIGZ1cnRoZXIgY29udmVyc2F0aW9u IG9uIHRoZSBvdGhlciBwb2ludC4NCj4gPiA+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4gWW91cnMs DQo+ID4gPj4+Pj4+Pj4+IEpvZWwNCj4gPiA+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4gT24gOS8y Ny8xMyAxOjM3IFBNLCBMb3UgQmVyZ2VyIHdyb3RlOg0KPiA+ID4+Pj4+Pj4+Pj4gSm9lbC9BdXRo b3JzLA0KPiA+ID4+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4+IEkgdGhvdWdodCBJIG1pZ2h0IGp1 bXAgaW4gb24gdHdvIHBvaW50czoNCj4gPiA+Pj4+Pj4+Pj4+DQo+ID4gPj4+Pj4+Pj4+Pg0KPiA+ ID4+Pj4+Pj4+Pj4gT24gOS8yNi8yMDEzIDQ6NTAgQU0sIEJFTE9UVEksIFNFUkdJTyAoU0VSR0lP KSB3cm90ZToNCj4gPiA+Pj4+Pj4+Pj4+PiBIZWxsbyBKb2VsLA0KPiA+ID4+Pj4+Pj4+Pj4+DQo+ ID4gPj4+Pj4+Pj4+Pj4gdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KPiA+ID4+Pj4+Pj4+Pj4+ IEJlbG93IGluIGxpbmUgb3VyIHJlcGx5LCBtYXJrZWQgImF1dGhvcnMiLg0KPiA+ID4+Pj4+Pj4+ Pj4+DQo+ID4gPj4+Pj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4+Pj4gLi4uDQo+ID4gPj4+Pj4+Pj4+Pg0K PiA+ID4+Pj4+Pj4+Pj4+IEdpdmVuIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBhYm91dCBtYXBwaW5n IHRvIEcuNzA5LCBpdCBpcw0KPiA+ID4+Pj4+Pj4+Pj4+IHVuY2xlYXIgd2hhdCBpcyBpbnRlbmRl ZCBieSB0aGUgdXNhZ2Ugb2YgIkxTUCIuICBNeSBndWVzcw0KPiA+ID4+Pj4+Pj4+Pj4+IGlzIHRo YXQgaXQgaXMgaW50ZW5kZWQgdG8gbWVhbiBMYWJlbCBTd2l0Y2ggUGF0aHMgc2V0IHVwDQo+ID4g Pj4+Pj4+Pj4+Pj4gYnkgR01QTFMgdG8gY2FycnkgT1RVL1VEVSBlbGVtZW50cy4NCj4gPiA+Pj4+ Pj4+Pj4+PiBJdCBzaG91bGQgYmUgc3RhdGVkIGV4cGxpY2l0bHkuDQo+ID4gPj4+Pj4+Pj4+Pj4N Cj4gPiA+Pj4+Pj4+Pj4+PiBBdXRob3JzPiBXZSBjYW4gc3BlY2lmeSB0aGlzIGFzIHlvdSBzdWdn ZXN0IGV2ZW4gaWYgd2UNCj4gPiA+Pj4+Pj4+Pj4+PiBBdXRob3JzPiBjb25zaWRlcmVkIG5vdA0K PiA+ID4+Pj4+Pj4+Pj4+IG5lY2Vzc2FyeSB0byBzcGVjaWZ5IHRoZSB1c2FnZSBvZiBMU1AgaW4g cmVsYXRpb24gdG8gZGF0YQ0KPiA+ID4+Pj4+Pj4+Pj4+IHBsYW5lIHNwZWNpZmljLiBFbmNvZGlu ZyB0eXBlIHNob3VsZCBjb3BlIHdpdGggdGhpcyBpc3N1ZS4NCj4gPiA+Pj4+Pj4+Pj4+Pg0KPiA+ ID4+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4+IEpvZWwsDQo+ID4gPj4+Pj4+Pj4+Pg0KPiA+ID4+ Pj4+Pj4+Pj4gSSBzdXNwZWN0IHRoYXQgdGhlIHVzYWdlIG9mIExTUCBpbiB0aGUgYWJzZW5jZSBv ZiB0aGUgTVBMUw0KPiA+ID4+Pj4+Pj4+Pj4gZGF0YSBwbGFuZSBpcyB3aGF0J3MgY2F1c2luZyBj b25mdXNpb24gaGVyZS4gIElzIHRoaXMgY29ycmVjdD8NCj4gPiA+Pj4+Pj4+Pj4+DQo+ID4gPj4+ Pj4+Pj4+PiBJZiBzbywgSSB0aGluayBHTVBMUyByZWZlcmVuY2luZyBjb250cm9sbGVkIGRhdGEg cGF0aHMNCj4gPiA+Pj4+Pj4+Pj4+IChjaXJjdWl0cykgYnkgdGhlIGNvbW1vbiBuYW1lIG9mIExh YmVsIFN3aXRjaGVkIFBhdGggKExTUCkNCj4gPiA+Pj4+Pj4+Pj4+IGlzIHN1ZmZpY2llbnRseSBl c3RhYmxpc2hlZCB0aGF0IHRoaXMgZG9jdW1lbnQgZG9lc24ndCBuZWVkDQo+ID4gPj4+Pj4+Pj4+ PiB0byByZXZpc2l0IGl0LiAgSW4gYW55IGNhc2UsIHRoZSBkb2N1bWVudCBhbHJlYWR5IHByb3Zp ZGVzDQo+IGNvbnRleHQ6DQo+ID4gPj4+Pj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4+Pj4gR01QTFMgcm91 dGluZyBhbmQgc2lnbmFsaW5nLCBhcyBkZWZpbmVkIGJ5IFtSRkM0MjAzXSwNCj4gPiA+Pj4+Pj4+ Pj4+IFtSRkM1MzA3XSwgW1JGQzM0NzNdIGFuZCBbUkZDNDMyOF0sIHByb3ZpZGVzIHRoZQ0KPiBt ZWNoYW5pc21zDQo+ID4gPj4+Pj4+Pj4+PiBmb3IgYmFzaWMNCj4gPiA+Pj4gR01QTFMNCj4gPiA+ Pj4+Pj4+Pj4+IGNvbnRyb2wgb2YgT1ROIG5ldHdvcmtzIGJhc2VkIG9uIHRoZSAyMDAxIHJldmlz aW9uIG9mIHRoZQ0KPiA+ID4+Pj4+Pj4+Pj4gRy43MDkgc3BlY2lmaWNhdGlvbi4NCj4gPiA+Pj4+ Pj4+Pj4+IGFuZA0KPiA+ID4+Pj4+Pj4+Pj4gQmFja2dyb3VuZCBpbmZvcm1hdGlvbiBhbmQgYSBm cmFtZXdvcmsgZm9yIHRoZSBHTVBMUw0KPiA+ID4+Pj4+Pj4+Pj4gcHJvdG9jb2wgZXh0ZW5zaW9u cyBuZWVkIHRvIHN1cHBvcnQgW0cuNzA5LTIwMTJdIGlzIHByb3ZpZGVkDQo+IGluIFtPVE4tRldL XS4NCj4gPiA+Pj4+Pj4+Pj4+DQo+ID4gPj4+Pj4+Pj4+PiBbT1ROLUZXS10gaGFzIHRoZSBvZnRl biByZXBlYXRlZCBjb25jZXB0Og0KPiA+ID4+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4+IEdNUExT IGV4dGVuZHMgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKSB0bw0KPiA+ID4+ PiBlbmNvbXBhc3MNCj4gPiA+Pj4+Pj4+Pj4+IHRpbWUgZGl2aXNpb24gbXVsdGlwbGV4aW5nIChU RE0pIG5ldHdvcmtzIChlLmcuLA0KPiA+ID4+Pj4+Pj4+Pj4gU3luY2hyb25vdXMgT3B0aWNhbCBO RVR3b3JrIChTT05FVCkvIFN5bmNocm9ub3VzIERpZ2l0YWwNCj4gPiA+Pj4+Pj4+Pj4+IEhpZXJh cmNoeSAoU0RIKSwgUGxlc2lvY2hyb25vdXMgRGlnaXRhbCBIaWVyYXJjaHkgKFBESCksDQo+ID4g Pj4+Pj4+Pj4+PiBhbmQgRy43MDkgc3ViLWxhbWJkYSksIGxhbWJkYSBzd2l0Y2hpbmcgb3B0aWNh bCBuZXR3b3JrcywNCj4gPiA+Pj4+Pj4+Pj4+IGFuZCBzcGF0aWFsIHN3aXRjaGluZyAoZS5nLiwg aW5jb21pbmcgcG9ydCBvciBmaWJlciB0bw0KPiA+ID4+Pj4+Pj4+Pj4gb3V0Z29pbmcgcG9ydCBv ciBmaWJlcikuICBUaGUgR01QTFMgYXJjaGl0ZWN0dXJlIGlzDQo+ID4gPj4+Pj4+Pj4+PiBwcm92 aWRlZCBpbiBbUkZDMzk0NV0sDQo+ID4gPj4+Pj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4+Pj4gSWYgdGhp cyBkb2Vzbid0IGNvdmVyIHRoZSBjb21tZW50LCBjYW4geW91IGVsYWJvcmF0ZSBvbg0KPiA+ID4+ Pj4+Pj4+Pj4gd2hhdCB5b3Ugd2FudCBleHBsaWNpdGx5IHN0YXRlZD8NCj4gPiA+Pj4+Pj4+Pj4+ DQo+ID4gPj4+Pj4+Pj4+Pj4gLi4uDQo+ID4gPj4+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4+PiBT ZWN0aW9uIDggb24gTWF4aW11bSBMU1AgQmFuZHdkaXRoIHNlZW1zIHRvIGJlDQo+IG9iamVjdGlu Zw0KPiA+ID4+Pj4+Pj4+Pj4+IHRvDQo+ID4gPj4+IHRvbw0KPiA+ID4+Pj4+Pj4+Pj4+IG11Y2gg aW5mb3JtYXRpb24gbGVhZGluZyB0byBhICJ3YXN0ZSBvZiBiaXRzIi4gIFdoaWxlDQo+ID4gPj4+ Pj4+Pj4+Pj4gcG9zc2libHkgb2YgaW50ZXJlc3QgdG8gdGhlIFdHLCB0aGF0IGRvZXMgbm90IHNl ZW0gdG8gZml0DQo+ID4gPj4+Pj4+Pj4+Pj4gYSBnYXANCj4gPiA+Pj4+Pj4gYW5hbHlzaXMuDQo+ ID4gPj4+Pj4+Pj4+Pj4gU2ltaWxhcmx5LCBzZWN0aW9uIDEwIG9uIFByaW9yaXR5IFN1cHBvcnQg cmVhZHMgYXMNCj4gPiA+Pj4+Pj4+Pj4+PiBpbXBsZW1lbnRhdGlvbiBhZHZpY2UgcmF0aGVyIHRo YW4gYSBnYXAgbmVlZGluZyBwcm90b2NvbA0KPiA+ID4+PiBjaGFuZ2VzLg0KPiA+ID4+Pj4+Pj4+ Pj4+DQo+ID4gPj4+Pj4+Pj4+Pj4gQXV0aG9ycz4gVGhlIGJhc2ljIHNjb3BlIG9mIHRoZSBkcmFm dCBpcyB0byB1bmRlcmxpbmUNCj4gPiA+Pj4+Pj4+Pj4+PiBBdXRob3JzPiBnYXBzLCBhbmQgZXZl bg0KPiA+ID4+Pj4+Pj4+Pj4+IGlmIHdoYXQgZGVzY3JpYmVkIGluIENoLjggYW5kIDEwLCBkbyBu b3QgcHJldmVudCByb3V0aW5nDQo+ID4gPj4+Pj4+Pj4+Pj4gdG8gd29yayAsIGl0IGlzIHN1Z2dl c3RlZCBoZXJlIGFuIHJlcXVpcmVtZW50IGZvcg0KPiA+ID4+Pj4+Pj4+Pj4+IG9wdGltaXphdGlv biBiYXNlZCBvbiBPVE4gcmVxdWlyZW1lbnRzIChlLmcuIG5vIG5lZWQgdG8NCj4gPiA+Pj4+Pj4+ Pj4+PiBhZHZlcnRpc2UgZml4ZWQgT0RVIGNvbnRhaW5lciBNYXggTFNQIEJXIHNpbmNlIGltcGxp Y2l0IGluDQo+ID4gPj4+Pj4+Pj4+Pj4gdGhlIHNpZ25hbCB0eXBlLikNCj4gPiA+Pj4+Pj4+Pj4+ Pg0KPiA+ID4+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4+IEF1dGhvcnMsDQo+ID4gPj4+Pj4+Pj4+ PiBJIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCBKb2VsIG9uIHRoaXMgcG9pbnQsIGZ1cnRoZXJtb3Jl DQo+ID4gPj4+Pj4+Pj4+PiBzZWN0aW9ucw0KPiA+ID4+Pj4+Pj4+Pj4gMTAgYW5kDQo+ID4gPj4+ Pj4+Pj4+PiA4IG92ZXJsYXAuICBPbmUgYXBwcm9hY2ggdG8gYWRkcmVzcyBoaXMgcG9pbnQgd291 bGQgYmUgdG8NCj4gPiA+Pj4+Pj4+Pj4+IHNpbXBseSBkcm9wIGJvdGggc2VjdGlvbnMuICBBbiBh bHRlcm5hdGl2ZSBpcyB0cnkgdG8NCj4gPiA+Pj4+Pj4+Pj4+IHJlcGhyYXNlIHRoZW0gdG8gYWRk cmVzcyBKb2VsJ3MgcG9pbnRzLiAgSSd2ZSB0YWtlbiBhIHBhc3MNCj4gPiA+Pj4+Pj4+Pj4+IGF0 IHRoZSBsYXR0ZXIgYmVsb3csIGJ1dCB3b24ndCBvYmplY3QgaWYgdGhlIGF1dGhvcnMgcHJlZmVy IHRoZQ0KPiBmb3JtZXIuDQo+ID4gPj4+Pj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4+Pj4gSGVyZSdzIGEg c3VnZ2VzdGVkIHdvcmRpbmcgY2hhbmdlIGlmIHlvdSBjaG9vc2UgdG8ga2VlcCB0aGUNCj4gPiA+ Pj4+Pj4gc2VjdGlvbnM6DQo+ID4gPj4+Pj4+Pj4+PiBPTEQ6DQo+ID4gPj4+Pj4+Pj4+PiA4LiBN YXhpbXVtIExTUCBCYW5kd2lkdGgNCj4gPiA+Pj4+Pj4+Pj4+DQo+ID4gPj4+Pj4+Pj4+PiBNYXhp bXVtIExTUCBiYW5kd2lkdGggaXMgY3VycmVudGx5IGFkdmVydGlzZWQgaW4gdGhlDQo+IGNvbW1v bg0KPiA+ID4+PiBwYXJ0DQo+ID4gPj4+Pj4+Pj4+PiBvZiB0aGUgSVNDRCBhbmQgYWR2ZXJ0aXNl ZCBwZXIgcHJpb3JpdHksIHdoaWxlIGluIE9UTg0KPiA+ID4+Pj4+Pj4+Pj4gbmV0d29ya3MgaXQg aXMgb25seSByZXF1aXJlZCBmb3IgT0RVZmxleCBhZHZlcnRpc2luZy4gIFRoaXMNCj4gPiA+Pj4+ Pj4+Pj4+IGxlYWRzIHRvIGEgc2lnbmlmaWNhbnQgd2FzdGUgb2YgYml0cyBpbnNpZGUgZWFjaCBM U0EuDQo+ID4gPj4+Pj4+Pj4+PiBhbmQNCj4gPiA+Pj4+Pj4+Pj4+DQo+ID4gPj4+Pj4+Pj4+PiBO RVcNCj4gPiA+Pj4+Pj4+Pj4+IDguIE1heGltdW0gTFNQIEJhbmR3aWR0aA0KPiA+ID4+Pj4+Pj4+ Pj4NCj4gPiA+Pj4+Pj4+Pj4+IE1heGltdW0gTFNQIGJhbmR3aWR0aCBpcyBjdXJyZW50bHkgYWR2 ZXJ0aXNlZCBwZXIgcHJpb3JpdHkNCj4gPiA+Pj4+Pj4+Pj4+IGluIHRoZSBjb21tb24gcGFydCBv ZiB0aGUgSVNDRC4gIFNlY3Rpb24gNSByZXZpZXdzIHNvbWUgb2YNCj4gPiA+Pj4+Pj4+Pj4+IHRo ZSBpbXBsaWNhdGlvbnMgb2YgYWR2ZXJ0aXNpbmcgT1ROIG5ldHdvcmsgaW5mb3JtYXRpb24NCj4g PiA+Pj4+Pj4+Pj4+IHVzaW5nIElTQ0RzLCBhbmQgaWRlbnRpZmllcyB0aGUgbmVlZCBmb3IgYSBt b3JlIG9wdGltaXplZA0KPiBzb2x1dGlvbi4NCj4gPiA+Pj4+Pj4+Pj4+IFdoaWxlIHN0cmljdGx5 IG5vdCByZXF1aXJlZCwgc3VjaCBhbiBvcHRpbWl6YXRpb24gZWZmb3J0DQo+ID4gPj4+Pj4+Pj4+ PiBzaG91bGQgYWxzbyBjb25zaWRlciB0aGUgb3B0aW1pemF0aW9uIG9mIHRoZSBwZXIgcHJpb3Jp dHkNCj4gPiA+Pj4+Pj4+Pj4+IG1heGltdW0gTFNQIGJhbmR3aWR0aCBhZHZlcnRpc2VtZW50IG9m IGJvdGggZml4ZWQgYW5kDQo+IHZhcmlhYmxlIE9EVSB0eXBlcy4NCj4gPiA+Pj4+Pj4+Pj4+DQo+ ID4gPj4+Pj4+Pj4+PiBPTEQNCj4gPiA+Pj4+Pj4+Pj4+IDEwLiBQcmlvcml0eSBTdXBwb3J0DQo+ ID4gPj4+Pj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4+Pj4gW1JGQzQyMDJdIGRlZmluZXMgOCBwcmlvcml0 aWVzIGZvciByZXNvdXJjZSBhdmFpbGFiaWxpdHkgYW5kDQo+IHVzYWdlLg0KPiA+ID4+Pj4+Pj4+ Pj4gQWxsIG9mIHRoZW0gaGF2ZSB0byBiZSBhZHZlcnRpc2VkIGluZGVwZW5kZW50bHkgb24gdGhl DQo+ID4gPj4+Pj4+Pj4+PiBudW1iZXIgb2YgcHJpb3JpdGllcyBzdXBwb3J0ZWQgYnkgdGhlIGlt cGxlbWVudGF0aW9uLg0KPiA+ID4+Pj4+Pj4+Pj4gQ29uc2lkZXJpbmcgdGhhdCB0aGUgYWR2ZXJ0 aXNlbWVudCBvZiBhbGwgdGhlIGRpZmZlcmVudA0KPiA+ID4+Pj4+Pj4+Pj4gc3VwcG9ydGVkIHNp Z25hbCB0eXBlcyB3aWxsIG9yaWdpbmF0ZSBsYXJnZSBMU0FzLCBpdCBpcw0KPiA+ID4+Pj4+Pj4+ Pj4gYWR2aXNlZCB0byBhZHZlcnRpc2Ugb25seSB0aGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0 aGUgcmVhbGx5DQo+IHN1cHBvcnRlZCBwcmlvcml0aWVzLg0KPiA+ID4+Pj4+Pj4+Pj4gTkVXDQo+ ID4gPj4+Pj4+Pj4+PiAxMC4gUHJpb3JpdHkgU3VwcG9ydA0KPiA+ID4+Pj4+Pj4+Pj4NCj4gPiA+ Pj4+Pj4+Pj4+IFtSRkM0MjAyXSBkZWZpbmVzIDggcHJpb3JpdGllcyBmb3IgcmVzb3VyY2UgYXZh aWxhYmlsaXR5IGFuZA0KPiB1c2FnZS4NCj4gPiA+Pj4+Pj4+Pj4+IEFzIGRlZmluZWQsIGVhY2gg aXMgYWR2ZXJ0aXNlZCBpbmRlcGVuZGVudCBvZiB0aGUgbnVtYmVyIG9mDQo+ID4gPj4+Pj4+Pj4+ PiBwcmlvcml0aWVzIHN1cHBvcnRlZCBieSBhIG5ldHdvcmsuICBBcyBpcyB0aGUgY2FzZSBpbg0K PiA+ID4+Pj4+Pj4+Pj4gU2VjdGlvbiA4LCBhZGRyZXNzaW5nIGFueSBpbmVmZmljaWVuY3kgd2l0 aCBzdWNoDQo+ID4gPj4+Pj4+Pj4+PiBhZHZlcnRpc2VtZW50cyBpcyBub3QgcmVxdWlyZWQgdG8g c3VwcG9ydCBPVE4gbmV0d29ya3MuDQo+ID4gPj4+Pj4+Pj4+PiBCdXQgYW55IHN1Y2ggaW5lZmZp Y2llbmN5IHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQgYXMgcGFydA0KPiA+ID4+Pj4+Pj4+Pj4g b2YgdGhlIG9wdGltaXphdGlvbiBlZmZvcnQgaWRlbnRpZmllZCBpbiBTZWN0aW9uIDUuDQo+ID4g Pj4+Pj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4+Pj4gQWxzbyBwbGVhc2UgcmVwbGFjZSAiQnciIHdpdGgg IkJhbmR3aWR0aCIgaW4gdGhlIGRvY3VtZW50Lg0KPiA+ID4+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+ Pj4+IExvdQ0KPiA+ID4+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pg0KPiA+ ID4+Pj4+Pj4+DQo+ID4gPj4+Pj4+Pg0KPiA+ID4+Pj4NCj4gPiA+DQoNCg== From kpithewan@infinera.com Sat Oct 19 00:57:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8447911E818C for ; Sat, 19 Oct 2013 00:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTU5lgTvpuIM for ; Sat, 19 Oct 2013 00:57:23 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1446B11E818E for ; Sat, 19 Oct 2013 00:57:14 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Sat, 19 Oct 2013 00:57:13 -0700 From: Khuzema Pithewan To: "CCAMP (ccamp@ietf.org)" Thread-Topic: New Version Notification for draft-bardalai-ccamp-overlay-path-comp-02.txt Thread-Index: AQHOyv8EUafGCbaJb0Kva4jUsJ/oa5n7q5pQ Date: Sat, 19 Oct 2013 07:57:12 +0000 Message-ID: References: <20131017060615.4800.41943.idtracker@ietfa.amsl.com> In-Reply-To: <20131017060615.4800.41943.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CCAMP] FW: New Version Notification for draft-bardalai-ccamp-overlay-path-comp-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 07:57:27 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXks IE9jdG9iZXIgMTcsIDIwMTMgMTE6MzYgQU0NClRvOiBSYWphbiBSYW87IEtodXplbWEgUGl0aGV3 YW47IFNuaWdkaG8gQmFyZGFsYWkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtYmFyZGFsYWktY2NhbXAtb3ZlcmxheS1wYXRoLWNvbXAtMDIudHh0DQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJhcmRhbGFpLWNjYW1wLW92ZXJsYXktcGF0aC1jb21w LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTbmlnZGhvIEJhcmRh bGFpIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFm dC1iYXJkYWxhaS1jY2FtcC1vdmVybGF5LXBhdGgtY29tcA0KUmV2aXNpb246CSAwMg0KVGl0bGU6 CQkgT3ZlcmxheSBOZXR3b3JrIC0gUGF0aCBDb21wdXRhdGlvbiBBcHByb2FjaGVzDQpDcmVhdGlv biBkYXRlOgkgMjAxMy0xMC0xNA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1i ZXIgb2YgcGFnZXM6IDEzDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWJhcmRhbGFpLWNjYW1wLW92ZXJsYXktcGF0aC1jb21wLTAyLnR4 dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWJhcmRhbGFpLWNjYW1wLW92ZXJsYXktcGF0aC1jb21wDQpIdG1saXplZDogICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJhcmRhbGFpLWNjYW1wLW92ZXJsYXktcGF0aC1j b21wLTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWJhcmRhbGFpLWNjYW1wLW92ZXJsYXktcGF0aC1jb21wLTAyDQoNCkFic3RyYWN0Og0K ICAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgdmFyaW91cyBwYXRoIGNvbXB1dGF0aW9ucyBhcHBy b2FjaGVzIHdoaWNoDQogICBhcmUgYXBwbGljYWJsZSB0byBvdmVybGF5IG5ldHdvcmtzIFtmcmFt ZXdvcmsgZG9jIHJlZl0uIEl0IGRpc2N1c3Nlcw0KICAgaG93IHRoZSBjdXN0b21lciBlZGdlIG5v ZGVzIHVzZXMgdGhlIGluZm9ybWF0aW9uIGFkdmVydGlzZWQgYnkgdGhlDQogICBwcm92aWRlciBu ZXR3b3JrIHRvIGNvbXB1dGUgYSBwYXRoIGJldHdlZW4gdHdvIGN1c3RvbWVyIGVkZ2Ugbm9kZXMg b3INCiAgIGhvdyBpdCBjYW4gcmVxdWVzdCB0aGUgcHJvdmlkZXIgbmV0d29yayB0byBjb21wdXRl IGEgcGF0aCBhbmQgc2V0dXANCiAgIGFuIGVuZC0yLWVuZCBMU1AuDQoNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K From kpithewan@infinera.com Sat Oct 19 01:03:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81BB11E8136 for ; Sat, 19 Oct 2013 01:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] 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 wJ0rZbe4yytn for ; Sat, 19 Oct 2013 01:03:26 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id BFDF921F9EDB for ; Sat, 19 Oct 2013 01:03:26 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Sat, 19 Oct 2013 01:03:26 -0700 From: Khuzema Pithewan To: "CCAMP (ccamp@ietf.org)" Thread-Topic: New Version Notification for draft-rao-ccamp-mlnmrn-otn-ospfte-ext-03.txt Thread-Index: AQHOzKC9JjUhNYm+5UCkIbWg/WJZBZn7qGNw Date: Sat, 19 Oct 2013 08:03:25 +0000 Message-ID: References: <20131019075636.9656.65055.idtracker@ietfa.amsl.com> In-Reply-To: <20131019075636.9656.65055.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CCAMP] FW: New Version Notification for draft-rao-ccamp-mlnmrn-otn-ospfte-ext-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 08:03:31 -0000 SGkgQ0NBTVBlcnMsDQoNClRoaXMgZHJhZnQgcHJvdmlkZXMgdGhlIE9TUEYgZXh0ZW5zaW9ucyB0 aGF0IGFyZSBuZWVkZWQgZm9yIGVuZC0yLWVuZCBwYXRoIGNvbXB1dGF0aW9uIGFjcm9zcyBtdWx0 aXBsZSByZWdpb25zIChtdWx0aXBsZSB0ZWNobm9sb2dpZXMgLSBTd2l0Y2hDYXAsRW5jb2Rpbmcp LCB3aGVyZSBhdGxlYXN0IG9uZSBvZiB0aGUgcmVnaW9uIGlzIG11bHRpLWxheWVyLiANCg0KTWFp biBkcml2ZXIgZm9yIHRoZXNlIGV4dGVuc2lvbiBpcyBPVE4gbXVsdGktbGF5ZXIgdGVjaG5vbG9n eSwgaG93ZXZlciB0aGUgZXh0ZW5zaW9ucyBhcmUgZG9uZSBpbiBzdWNoIGEgd2F5IGl0IGlzIGV4 cGVjdGVkIHRvIHdvcmsgaW4gb3RoZXIgbXVsdGktbGF5ZXIgdGVjaG5vbG9naWVzIGFzIHdlbGwu DQoNCkV4YW1wbGVzIGhhdmUgYmVlbiBwcm92aWRlZCBmb3IgU09ORVQvU0RIIGFuZCBPVE4uDQoN CkNvbW1lbnRzIFdlbGNvbWUuDQoNClJlZ2RzDQpLaHV6ZW1hDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMTksIDIwMTMgMToy NyBQTQ0KVG86IFJhamFuIFJhbzsgS2h1emVtYSBQaXRoZXdhbg0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yYW8tY2NhbXAtbWxubXJuLW90bi1vc3BmdGUtZXh0 LTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yYW8tY2NhbXAtbWxubXJu LW90bi1vc3BmdGUtZXh0LTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBLaHV6ZW1hIFBpdGhld2FuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K RmlsZW5hbWU6CSBkcmFmdC1yYW8tY2NhbXAtbWxubXJuLW90bi1vc3BmdGUtZXh0DQpSZXZpc2lv bjoJIDAzDQpUaXRsZToJCSBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIE1MTk1STiBiYXNlZCBvbiBP VE4NCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTE3DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCk51bWJlciBvZiBwYWdlczogOQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yYW8tY2NhbXAtbWxubXJuLW90bi1vc3BmdGUt ZXh0LTAzLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXJhby1jY2FtcC1tbG5tcm4tb3RuLW9zcGZ0ZS1leHQNCkh0bWxpemVkOiAgICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFvLWNjYW1wLW1sbm1ybi1vdG4t b3NwZnRlLWV4dC0wMw0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1yYW8tY2NhbXAtbWxubXJuLW90bi1vc3BmdGUtZXh0LTAzDQoNCkFic3Ry YWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgT1NQRiBleHRlbnNpb25zIGZvciBtdWx0 aS1sYXllci9tdWx0aS1yZWdpb24NCiAgIHdoZXJlIG9uZSBvZiB0aGUgcmVnaW9ucyBpcyBtdWx0 aS1sYXllciBlLmcuIE9UTiwgU09ORVQvU0RILg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K From internet-drafts@ietf.org Sun Oct 20 23:47:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B15511E84D5; Sun, 20 Oct 2013 23:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsfMdlZXHs2k; Sun, 20 Oct 2013 23:47:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A6C11E833B; Sun, 20 Oct 2013 23:47:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021064725.8699.48125.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 23:47:25 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 06:47:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : GMPLS RSVP-TE Extensions for Lock Instruct and Loopback Author(s) : Jie Dong Mach(Guoyi) Chen Zhenqiang Li Daniele Ceccarelli Filename : draft-ietf-ccamp-rsvp-te-li-lb-02.txt Pages : 8 Date : 2013-10-20 Abstract: This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanism for Label Switched Paths (LSPs). The mechanisms are applicable to technologies which use Generalized Multi-Protocol Label Switching (GMPLS) as control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-li-lb There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-li-lb-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rsvp-te-li-lb-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniele.ceccarelli@ericsson.com Mon Oct 21 06:18:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179B111E83AE for ; Mon, 21 Oct 2013 06:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.751 X-Spam-Level: X-Spam-Status: No, score=-5.751 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-z9qiUjLgfW for ; Mon, 21 Oct 2013 06:18:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1E76011E85A8 for ; Mon, 21 Oct 2013 06:15:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-d3-526529088a40 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 33.BD.16099.80925625; Mon, 21 Oct 2013 15:15:52 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.27]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 15:15:52 +0200 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" Thread-Topic: IETF 88 - CCAMP agenda requests Thread-Index: Ac7A62fizl6s11uwRBqP7yxjH/V66QNc0f+g Date: Mon, 21 Oct 2013 13:15:51 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48174DD2@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.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_4A1562797D64E44993C5CBF38CF1BE48174DD2ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjS6HZmqQwanduhZP5txgsbjc1c1u 0dH8lsWB2eNl/xxGjyVLfjJ5fNjUzBbAHMVlk5Kak1mWWqRvl8CV0Xz0MFvB1+mMFYcOPmVt YLzfxtjFyMkhIWAi8e3eJjYIW0ziwr31QDYXh5DAYUaJV7fOM0E4ixkl7n67wN7FyMHBJmAl 8eSQD0iDiICuxN6N15lBbGaBaokTu7czgZQIC+hIvN8tD1Ny5HEvE4RtJPHi/0tWkBIWAVWJ D62VICavgLfEtcdaIBVCQOazRTvAruEU8JFYd+Au2JWMArISE3YvYoRYJC5x68l8JoiLBSSW 7DnPDGGLSrx8/I8VwlaU2Hm2HeqwfInn86eC2bwCghInZz5hmcAoOgvJqFlIymYhKYOI60nc mDqFDcLWlli28DUzhK0rMePfIRZk8QWM7KsY2XMTM3PSyw03MQKj7OCW37o7GE+dEznEKM3B oiTO++Gtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRnfhvYeL/v891un0kCdSaa7FLm1D mQiFxEX67VeumO2U2WjFF3FijSFPwJrw7DSFjecK5/4vKXrrmNemM/ct/460pDwtXwPOB7/W 1ufx991+d7Jw6h912bL1i0Q+yNgXCl29EXJ6z9ajBfwn/lwxS68OUy9T1ypRsloa43+899z+ DBZP3eopSizFGYmGWsxFxYkAQV4FAIACAAA= Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:18:33 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48174DD2ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We noticed that surveymonkey has issues with multiple slot requests from th= e same user as it relies on cookies. If you requested multiple slots, every time surveymonkey overwrote your las= t request with the new one and hence only the last one is stored on the ser= ver. There are actually 3 workaround: 1. Use a different browser for each of your requests 2. Delete the cookies of your browser after any submission 3. Drop me an email (ccing the chairs) as usual with all the data req= uested in the survey and I'll fill that for you. Please do that asap as Tuesday 22nd the agenda needs to be finalized. BR Daniele From: Daniele Ceccarelli Sent: venerd=EC 4 ottobre 2013 12:31 To: CCAMP (ccamp@ietf.org) Cc: Lou Berger (lberger@labn.net); BRUNGARD, DEBORAH A (ATTLABS) (db3546@at= t.com); Daniele Ceccarelli Subject: IETF 88 - CCAMP agenda requests Dear CCAMP, IETF 88 meeting is approaching and it's time to start collecting agenda slo= ts requests. Keeping this in mind: Authors of active working group documents should plan on presenting status = (briefly, including recent changes), open issues/discussion topics and plan= ned next steps at the meeting. Alternatively, an update can be provided vi= a e-mail to the list in the *week prior* to the meeting. Agenda Requests: - To submit a request, please fill the survey at the following link: http:/= /www.surveymonkey.com/s/QLK9BB6 - Please fill the survey no later than Sunday, October 20. Presentations: If you are presenting slides please make sure you send them to all *indi= viduals* listed above (Chairs, Secretary and exclude CCAMP) no later than = Sunday, November 3. Reminder about a few important dates: * 2013-10-21 (Monday): Internet Draft submission cut-off (for all draft= s, including -00) by UTC 24:00, upload using IETF ID Submission Tool. * 2013-10-23 (Wednesday): Draft Working Group agendas due by UTC 24:00,= upload using IETF Meeting Materials Management Tool. * 2013-10-28 (Monday): Revised Working Group agendas due by UTC 24:00, = upload using IETF Meeting Materials Management Tool. * 2013-11-03 - 2013-11-08: 88th IETF Meeting in Vancouver, BC, Canada. BR Daniele & CCAMP chairs --_000_4A1562797D64E44993C5CBF38CF1BE48174DD2ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We noticed that survey= monkey has issues with multiple slot requests from the same user as = it relies on cookies.

 

If you requested multi= ple slots, every time surveymonkey overwrote your last request with the new= one and hence only the last one is stored on the server. There are actuall= y 3 workaround:

 

1.&= nbsp;      Use a differen= t browser for each of your requests

2.&= nbsp;      Delete the coo= kies of your browser after any submission

3.&= nbsp;      Drop me an ema= il (ccing the chairs) as usual with all the data requested in the survey an= d I’ll fill that for you.

 

Please do that asap as= Tuesday 22nd the agenda needs to be finalized.

 

BR
Daniele

 

 

 

From: Daniele = Ceccarelli
Sent: venerd=EC 4 ottobre 2013 12:31
To: CCAMP (ccamp@ietf.org)
Cc: Lou Berger (lberger@labn.net); BRUNGARD, DEBORAH A (ATTLABS) (db= 3546@att.com); Daniele Ceccarelli
Subject: IETF 88 - CCAMP agenda requests

 

Dear CCAMP,

 

IETF 88 meeting is approaching and it’s time t= o start collecting agenda slots requests.

 

Keeping this in mind:

Authors of active working group documents should = plan on presenting status (briefly, including recent changes), open issues/= discussion topics and planned next steps at the meeting.  Alternativel= y, an update can be provided via e-mail to the list in the *week prior* to the meeting.

 

Agenda Requests:

- To submit a request, please fill the sur= vey at the following link: http://www.surveymonkey.c= om/s/QLK9BB6

- Please fill the survey no later than Sunday,= October 20.

 

Presentations:

  If you are presenting slides please make s= ure you send them to  all *individuals* listed above (Chairs, Secretar= y and exclude CCAMP) no later  than Sunday, November 3.

 

Reminder about a few important dates:

BR

Daniele & CCAMP cha= irs

 

--_000_4A1562797D64E44993C5CBF38CF1BE48174DD2ESESSMB301ericsso_-- From internet-drafts@ietf.org Mon Oct 21 07:28:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4977F21E80A6; Mon, 21 Oct 2013 07:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWCX4J8TUBoY; Mon, 21 Oct 2013 07:28:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7250821E808D; Mon, 21 Oct 2013 07:27:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021142749.29521.85707.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 07:27:49 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:28:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Traffic Engineering Extensions to OSPF for Generalized M= PLS (GMPLS) Control of Evolving G.709 OTN Networks Author(s) : Daniele Ceccarelli Fatai Zhang Sergio Belotti Rajan Rao John E Drake Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-10.txt Pages : 35 Date : 2013-10-21 Abstract: This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC4203. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniele.ceccarelli@ericsson.com Mon Oct 21 07:30:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [CCAMP] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 amy.yemin@huawei.com Tue Oct 22 00:40:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1135311E84B9 for ; Tue, 22 Oct 2013 00:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.227, 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 LUu6dRW+Auqi for ; Tue, 22 Oct 2013 00:40:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A0CAE11E8355 for ; Tue, 22 Oct 2013 00:40:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZI05234; Tue, 22 Oct 2013 07:40:13 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 08:39:01 +0100 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 08:39:59 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.229]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0146.000; Tue, 22 Oct 2013 15:39:56 +0800 From: "Yemin (Amy)" To: "ccamp@ietf.org" Thread-Topic: New Version Notification for draft-long-ccamp-rsvp-te-bandwidth-availability-02.txt Thread-Index: AQHOznNkwTb8zq8rN0KfYGPzVDg2l5oAVH8Q Date: Tue, 22 Oct 2013 07:39:55 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F73D41226@szxema506-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.33.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] FW: New Version Notification for draft-long-ccamp-rsvp-te-bandwidth-availability-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 07:40:27 -0000 SGkgQ0NBTVBlcnMsDQoNCkkgdXBkYXRlZCB0aGUgZHJhZnQgb24gUlNWUC1URSBleHRlbnNpb24g Zm9yIGRpc2NyZXRlIGJhbmR3aWR0aCBsaW5rIHdpdGggZm9sbG93aW5nIGNoYW5nZXM6DQrvgawJ MS5BcyB0aGUgZHJhZnQgZXh0ZW5kcyBiYXNlZCBvbiBSRkM2MDAzLCB0aGUgY29ycmVzcG9uZGlu ZyB0ZXh0cyBhbmQgZmlndXJlcyB3YXMgdXBkYXRlZCB0byBiZSBjb25zaXN0ZW50IHdpdGggNjAw My4NCu+BrAkyLkNsYXJpZnkgd2hhdCBpZiBhIGhvcCBjYW5ub3Qgc3VwcG9ydCB0aGUgYXZhaWxh YmlsaXR5IHN1Yi1UTFYNCu+BrAkzLkNoYW5nZSB0aGUgZXJyb3IgY29kZSBhbmQgdGhlIGVycm9y IHZhbHVlDQrvgawJNC4gZmlsbCBpbiBJQU5BIGNvbnNpZGVyYXRpb24gc2VjdGlvbg0KDQpBIHJl bGF0ZWQgZHJhZnQgZm9yIE9TUEYtVEUgZXh0ZW5zaW9uIGNhbiBiZSBmb3VuZCBhdCBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sb25nLWNjYW1wLW9zcGYtYXZhaWxh YmlsaXR5LWV4dGVuc2lvbi0wMS50eHQgLg0KDQpDb21tZW50cyBhcmUgd2VsY29tZS4NCg0KQlIs DQpBbXkgWWUNCg0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWP kemAgeaXtumXtDogMjAxM+W5tDEw5pyIMjHml6UgMjM6MzANCuaUtuS7tuS6ujogPT91dGYtOD9x P0dyZWdfTWlyc2t5Xz0zQ2dyZWdvcnk9MkVtaXJza3k9NDBlcmljc3Nvbj0yRWNvbT0zRT0yQ19N aW5fWWU/PUBpZXRmYS5hbXNsLmNvbTsgPT91dGYtOD9xP189M0NhbXk9MkV5ZW1pbj00MGh1YXdl aT0yRWNvbT0zRT0yQ19BbGVzc2FuZHJvX0Q9MjdBbGVzc2E/PUBpZXRmYS5hbXNsLmNvbTsgPT91 dGYtOD9xP25kcm9fPTNDYWxlc3NhbmRybz0yRWRhbGVzc2FuZHJvPTQwdGVsZWNvbWl0YWxpYT0y RWl0PTNFPz1AaWV0ZmEuYW1zbC5jb207ID0/dXRmLTg/cT89MkNfSGFvX0xvbmdfPTNDbG9uZ2hh bz00MGh1YXdlaT0yRWNvbT0zRT0yQ19BbGVzc2FuZHJvX0Q/PUBpZXRmYS5hbXNsLmNvbTsgPT91 dGYtOD9xPz1FMj04MD05OUFsZXNzYW5kcm9fPTNDYWxlc3NhbmRybz0yRWRhbGVzc2FuZHJvPTQw dGVsZWNvbWk/PUBpZXRmYS5hbXNsLmNvbTsgPT91dGYtOD9iP2RHRnNhV0V1YVhRKz89QGlldGZh LmFtc2wuY29tDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbG9u Zy1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFiaWxpdHktMDIudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxvbmctY2NhbXAtcnN2cC10ZS1iYW5kd2lkdGgtYXZhaWxh YmlsaXR5LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaW4gWWUg YW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1s b25nLWNjYW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2YWlsYWJpbGl0eQ0KUmV2aXNpb246CSAwMg0K VGl0bGU6CQkgUlNWUC1URSBTaWduYWxpbmcgRXh0ZW5zaW9uIGZvciBMaW5rcyB3aXRoIFZhcmlh YmxlIERpc2NyZXRlIEJhbmR3aWR0aA0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTAtMTgNCkdyb3Vw OgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMA0KVVJMOiAgICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sb25nLWNj YW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2YWlsYWJpbGl0eS0wMi50eHQNClN0YXR1czogICAgICAg ICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb25nLWNjYW1wLXJzdnAt dGUtYmFuZHdpZHRoLWF2YWlsYWJpbGl0eQ0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1sb25nLWNjYW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2YWlsYWJp bGl0eS0wMg0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1sb25nLWNjYW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2YWlsYWJpbGl0eS0wMg0KDQpB YnN0cmFjdDoNCiAgIFBhY2tldCBzd2l0Y2hpbmcgbmV0d29yayBtYXkgY29udGFpbiBsaW5rcyB3 aXRoIHZhcmlhYmxlIGJhbmR3aWR0aCwNCiAgIGUuZy4sIGNvcHBlciwgcmFkaW8sIGV0Yy4gVGhl IGJhbmR3aWR0aCBvZiBzdWNoIGxpbmsgaXMgc2Vuc2l0aXZlIHRvDQogICBleHRlcm5hbCBlbnZp cm9ubWVudC4gQXZhaWxhYmlsaXR5IGlzIHR5cGljYWxseSB1c2VkIGZvciBkZXNjcmliaW5nDQog ICB0aGUgbGluayBkdXJpbmcgbmV0d29yayBwbGFubmluZy4gVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYW4NCiAgIGV4dGVuc2lvbiBmb3IgUlNWUC1URSBzaWduYWxpbmcgZm9yIHNldHRpbmcgdXAg YSBsYWJlbCBzd2l0Y2hpbmcNCiAgIHBhdGggKExTUCkgaW4gYSBQYWNrZXQgU3dpdGNoZWQgTmV0 d29yayAoUFNOKSBuZXR3b3JrIHdoaWNoIGNvbnRhaW5zDQogICBsaW5rcyB3aXRoIGRpc2NyZXRl bHkgdmFyaWFibGUgYmFuZHdpZHRoIGJ5IGludHJvZHVjaW5nIGFuIG9wdGlvbmFsDQogICBhdmFp bGFiaWxpdHkgZmllbGQgaW4gUlNWUC1URSBzaWduYWxpbmcuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From cyril.margaria@coriant.com Tue Oct 22 03:53:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08AD11E8256 for ; Tue, 22 Oct 2013 03:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.597 X-Spam-Level: X-Spam-Status: No, score=-4.597 tagged_above=-999 required=5 tests=[AWL=2.002, 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 RiJV75OFCT7B for ; Tue, 22 Oct 2013 03:53:51 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id BFDE811E8117 for ; Tue, 22 Oct 2013 03:53:51 -0700 (PDT) Received: from mail97-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE042.bigfish.com (10.236.130.105) with Microsoft SMTP Server id 14.1.225.22; Tue, 22 Oct 2013 10:53:51 +0000 Received: from mail97-co9 (localhost [127.0.0.1]) by mail97-co9-R.bigfish.com (Postfix) with ESMTP id 3768018008F for ; Tue, 22 Oct 2013 10:53:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT005.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zzc89bh31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068h1954cbh8275bhz2fh2a8h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received-SPF: pass (mail97-co9: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT005.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail97-co9 (localhost.localdomain [127.0.0.1]) by mail97-co9 (MessageSwitch) id 1382439229359746_24988; Tue, 22 Oct 2013 10:53:49 +0000 (UTC) Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.249]) by mail97-co9.bigfish.com (Postfix) with ESMTP id 4A6E8900067 for ; Tue, 22 Oct 2013 10:53:49 +0000 (UTC) Received: from DB3PRD0411HT005.eurprd04.prod.outlook.com (157.56.253.53) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 22 Oct 2013 10:53:49 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.169]) by DB3PRD0411HT005.eurprd04.prod.outlook.com ([10.255.73.40]) with mapi id 14.16.0371.000; Tue, 22 Oct 2013 10:53:48 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: "CCAMP (ccamp@ietf.org)" Thread-Topic: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling Thread-Index: Ac7PFPsDhmt/uF1bTWymUSOtwlOYqw== Date: Tue, 22 Oct 2013 10:53:47 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D02DE3549@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.159.77.167] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Tue, 22 Oct 2013 06:17:49 -0700 Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 10:55:30 -0000 http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 I've reviewed this document and believe it is ready for publication, with c= omments: I think the document is good to go, I have two editorial comments: - I find the document history good to have, but maybe in an annex. - My stable mail address is cyril.margaria@gmail.com , affiliation is Cori= ant. http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 I've reviewed this document and believe it is ready for publication, with c= omment: I have the same comment as the rwa info regarding the history to be maybe m= oved to the annex=20 http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 I've reviewed this document and believe it is ready for publication, with c= omments: - editorial: The document history could be moved to the annex=20 - section 3.3 : rbState (16 bit) : nits : is it signed or unsigned integer = ? I would tend to understand unsigned. - My stable mail address is cyril.margaria@gmail.com , affiliation is Coria= nt, not NSN http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-= te-05 I've reviewed this document and believe it is ready for publication http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-= 12 I've reviewed this document and believe it is ready for publication, with c= omments: - editorial: The document history could be moved to the annex=20 - Section 2 : the section reference to WSON-Encode are wrong (this affect s= ection 2, section 2.1 - Section 3 : it would be useful to reference the exact section of [Gen-enc= ode] for the Available Label Sub-TLV and Shared Backup Label Sub-TLV.=20 http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06=20 I've reviewed this document and I have the following comments: - section 4.3 : "If more than two objects are encountered, two MUST be processed and the rest SHOULD be ignored." This is ambiguous : the section refers to the RB information sub tlv, does= this refers to the WSON_signaling object or RBInformation? - section 4.3 : http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52, please= remove this paragraph, the restriction is strong and would not allow a nod= e to choose one RB per local policy /sharing.. etc - section 7 : the section assume a LSP_REQUIRED_ATTRIBUTE, but this is a t= argeted information as described in section 4.2, or should it be distinguis= hed between targeted attribute (to be assigned in the ERO HOP_attribut, thi= s depends on the space choosen by the draft-ietf-ccamp-lsp-attribute-ro) an= d e2e attribute (WA)?. =20 Best Regards/ Mit freundlichen Gr=FC=DFen Cyril Margaria cyril.margaria@gmail.com http://www.coriant.com Coriant R&D GmbH Gesch=E4ftsleitung / Board of Directors: Robert Richter, Rolf Nauerz=20 Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRB 197143 From lberger@labn.net Tue Oct 22 13:34:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9117E11E822E for ; Tue, 22 Oct 2013 13:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 c1ATNf3IjHC2 for ; Tue, 22 Oct 2013 13:34:28 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 8B97611E824D for ; Tue, 22 Oct 2013 13:34:28 -0700 (PDT) Received: (qmail 6736 invoked by uid 0); 22 Oct 2013 20:34:06 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by qproxy1.mail.unifiedlayer.com with SMTP; 22 Oct 2013 20:34:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=EWP/cdyf02WlPZppZqOkm+0N0C8xMEm0rzs6x62GywI=; b=zVRGOqW1+h85ca5UTmytav/57kpJzTqIh+FSvwAw1YlHczMxF1fUXRFqvNWCQW4V9AgdW7THHPflogZdcyvdH0wTcBJAwj512NcDUfnICnl8aa+h7ydxmoFmpP/TiOUo; Received: from box313.bluehost.com ([69.89.31.113]:34495 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VYieU-0007Kg-0T for ccamp@ietf.org; Tue, 22 Oct 2013 14:34:06 -0600 Message-ID: <5266E138.8080605@labn.net> Date: Tue, 22 Oct 2013 16:34:00 -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: CCAMP References: <524AF9A9.3040006@labn.net> In-Reply-To: <524AF9A9.3040006@labn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:34:34 -0000 All, Given the recent draft submission deadline and only one comment being received to date, we'd like to extend the WG more time for review. These drafts represent significant work by the authors and WG, so please review and let the WG know what you think (positive or negative)! Please have all comments in by October 29. Thank you, Lou (and Deborah) On 10/1/2013 12:34 PM, Lou Berger wrote: > All, > > This mail begins working group last call on the WSON documents. As > there are 6 documents in this set, the last call will be three weeks. > The documents included in the last call are: > > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 > (Informational, IPR Disclosed) > > http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 > (Standards Track, IPR Disclosed) > > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 > (Standards Track) > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 > (Standards Track, IPR Disclosed) > > http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 > (Standards Track, IPR Disclosed) > > http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards > Track) Also has one open issue that will need to be resolved as part of > LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. > > This working group last call ends on October 22. Comments should be > sent to the CCAMP mailing list. Please remember to include the > technical basis for any comments. > > Positive comments, e.g., "I've reviewed this document and believe it is > ready for publication", are welcome! > > Please note that we're still missing some IPR statements. Any > forthcoming publication request will be delayed by late IPR > statements/disclosures. > > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Tue Oct 22 14:13:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877C611E8265 for ; Tue, 22 Oct 2013 14:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.085 X-Spam-Level: X-Spam-Status: No, score=-102.085 tagged_above=-999 required=5 tests=[AWL=0.180, 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 YDZzMg1KPn4V for ; Tue, 22 Oct 2013 14:13:23 -0700 (PDT) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 835BA11E826C for ; Tue, 22 Oct 2013 14:13:08 -0700 (PDT) Received: (qmail 15408 invoked by uid 0); 22 Oct 2013 21:12:47 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.mail.unifiedlayer.com with SMTP; 22 Oct 2013 21:12:47 -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=G5am7Mi5+W70XVq+yWy7d8+/ZHtxen7YR2tW0qqP4Fw=; b=Q2AogkuZsHdhKlvFKK022/QJQnXXFrykvpzb9t0M/Yzn8pU3kfQsF9EllzEc3Thi7LOfIEHZT95tOCSPjmwAAqLpxrAxEw7+XjZ9KZCGZl+J3S5teyKrq/t9dFECxEAI; Received: from box313.bluehost.com ([69.89.31.113]:41166 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VYjFu-00036Y-PO; Tue, 22 Oct 2013 15:12:46 -0600 Message-ID: <5266EA49.8050408@labn.net> Date: Tue, 22 Oct 2013 17:12:41 -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: "CCAMP (ccamp@ietf.org)" References: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 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} Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 21:13:27 -0000 The draft agenda for Vancouver has been posted at http://www.ietf.org/proceedings/88/agenda/agenda-88-ccamp Kudos to Daniele for pulling the info together. The first 90 minutes are scheduled for the UNI/PCE/ENNI/MLN/... discussion. This portion of the agenda will have presentations that will be limited to use cases and current limitations (presenters, try to limit yourself to 2 slides per use case) and then an open discussion. Please let us know if your request has not been scheduled or if you have any other comment on the agenda. Lou (Deborah, and Daniele) On 10/4/2013 6:30 AM, Daniele Ceccarelli wrote: > Dear CCAMP, > > > > IETF 88 meeting is approaching and it抯 time to start collecting agenda > slots requests. > > > > Keeping this in mind: > > Authors of active working group documents should plan on presenting > status (briefly, including recent changes), open issues/discussion > topics and planned next steps at the meeting. Alternatively, an update > can be provided via e-mail to the list in the *week prior* to the meeting. > > > > *_Agenda Requests_*: > > - *To submit a request*, please fill the survey at the following link: > http://www.surveymonkey.com/s/QLK9BB6 > > - Please fill the survey no later than *Sunday, October 20*. > > > > *_Presentations:_* > > If you are presenting slides please make sure you send them to all > *individuals* listed above (Chairs, Secretary and exclude CCAMP) no > later than *Sunday, November 3*. > > > > *_Reminder about a few important dates_*: > > * *2013-10-21 (Monday):* Internet Draft submission cut-off (for all > drafts, including -00) by UTC 24:00, upload using IETF ID Submission > Tool . > * *2013-10-23 (Wednesday):* Draft Working Group agendas due by UTC > 24:00, upload using IETF Meeting Materials Management Tool > . > * *2013-10-28 (Monday):* Revised Working Group agendas due by UTC > 24:00, upload using IETF Meeting Materials Management Tool > . > * *2013-11-03 - 2013-11-08: 88th IETF Meeting in Vancouver, BC, Canada.*** > > *BR* > > *Daniele & CCAMP chairs* > > > From adrian@olddog.co.uk Tue Oct 22 14:24:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7BC11E8251 for ; Tue, 22 Oct 2013 14:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 ZrPz1xbzwSGz for ; Tue, 22 Oct 2013 14:24:50 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id C80E511E825F for ; Tue, 22 Oct 2013 14:24:46 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r9MLOi4g032421; Tue, 22 Oct 2013 22:24:45 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r9MLOh2a032413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Oct 2013 22:24:43 +0100 From: "Adrian Farrel" To: "'CCAMP WG'" Date: Tue, 22 Oct 2013 22:24:40 +0100 Message-ID: <0e7601cecf6d$1ec53a70$5c4faf50$@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: Ac7PbRtzogRV3DvIRn2nsOXoa+AD1Q== Content-Language: en-gb Cc: draft-farrel-interconnected-te-info-exchange@tools.ietf.org Subject: [CCAMP] Pump-priming UNI/PCE/ENNI/MLN/... discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 21:24:56 -0000 Hi, Now that the draft agenda is out for CCAMP in Vancouver it is worth stirring up a little discussion to see whether we can arrive in British Columbia with some things ironed out and some ideas we want to dig into deeper. A bunch of us have been working on a draft to summarise the problems and propose an architecture. See the latest version at http://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange-02 It might be helpful to break the discussion into consideration of the problem statement first. Do we have any disagreement about the scope, the type of network we need to solve, and the functions we need to deliver. That should take you up to the end of Section 3. Then, as a separate discussion, perhaps we can get into the architecture. From a broad high level, does it do what we want/need? Yes, there are some wrinkles and nits to be sorted out in the details. That should cover section 5. Finally, can we use the architecture to do useful things. That will be sections 7 and (oops) 8. Really looking forward to hearing people's opinions. Thanks, Adrian From adrian@olddog.co.uk Tue Oct 22 14:47:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF3F11E8251 for ; Tue, 22 Oct 2013 14:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 K1ch+viB7iwL for ; Tue, 22 Oct 2013 14:47:26 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id EA0A111E8300 for ; Tue, 22 Oct 2013 14:45:42 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r9MLjDPo006918; Tue, 22 Oct 2013 22:45:13 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r9MLjBq0006900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Oct 2013 22:45:12 +0100 From: "Adrian Farrel" To: "'CCAMP WG'" References: <0e7601cecf6d$1ec53a70$5c4faf50$@olddog.co.uk> In-Reply-To: <0e7601cecf6d$1ec53a70$5c4faf50$@olddog.co.uk> Date: Tue, 22 Oct 2013 22:45:08 +0100 Message-ID: <0e7f01cecf6f$fb2ad1d0$f1807570$@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: AQKmPSb+jhFSzpUJjjc40ISq725v35hSZNvg Content-Language: en-gb Cc: draft-farrel-interconnected-te-info-exchange@tools.ietf.org Subject: Re: [CCAMP] Pump-priming UNI/PCE/ENNI/MLN/... discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 21:47:59 -0000 Sorry! Lou quite correctly points out that I should say... This is not your AD directing how business in the WG should be done, nor at what outcome the WG should arrive with consensus. I am just being a humble co-author on a document that is not even a WG document. If you all want to tell me I am mad or don't understand networks, that will not only be your right, but will be quite refreshing. If you have other ideas about how to arrange the discussion, go right ahead and tell me I am wrong or that you prefer to do it different. Adrian > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 22 October 2013 22:25 > To: 'CCAMP WG' > Cc: draft-farrel-interconnected-te-info-exchange@tools.ietf.org > Subject: [CCAMP] Pump-priming UNI/PCE/ENNI/MLN/... discussion > > Hi, > > Now that the draft agenda is out for CCAMP in Vancouver it is worth stirring up > a little discussion to see whether we can arrive in British Columbia with some > things ironed out and some ideas we want to dig into deeper. > > A bunch of us have been working on a draft to summarise the problems and > propose > an architecture. See the latest version at > http://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange-02 > > It might be helpful to break the discussion into consideration of the problem > statement first. Do we have any disagreement about the scope, the type of > network we need to solve, and the functions we need to deliver. That should > take you up to the end of Section 3. > > Then, as a separate discussion, perhaps we can get into the architecture. From a > broad high level, does it do what we want/need? Yes, there are some wrinkles > and > nits to be sorted out in the details. That should cover section 5. > > Finally, can we use the architecture to do useful things. That will be sections > 7 and (oops) 8. > > Really looking forward to hearing people's opinions. > > Thanks, > Adrian > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Tue Oct 22 15:16:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161F711E827D for ; Tue, 22 Oct 2013 15:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.734 X-Spam-Level: X-Spam-Status: No, score=-2.734 tagged_above=-999 required=5 tests=[AWL=-0.135, 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 dxasJXNqh5i6 for ; Tue, 22 Oct 2013 15:16:23 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA2811E8244 for ; Tue, 22 Oct 2013 15:16:23 -0700 (PDT) Received: from mail9-db8-R.bigfish.com (10.174.8.253) by DB8EHSOBE001.bigfish.com (10.174.4.64) with Microsoft SMTP Server id 14.1.225.22; Tue, 22 Oct 2013 22:16:22 +0000 Received: from mail9-db8 (localhost [127.0.0.1]) by mail9-db8-R.bigfish.com (Postfix) with ESMTP id 3208934011B; Tue, 22 Oct 2013 22:16:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail9-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(51704005)(37854004)(13464003)(189002)(199002)(4396001)(74876001)(15202345003)(74706001)(47976001)(50986001)(33646001)(74366001)(74316001)(49866001)(47736001)(51856001)(53806001)(81542001)(81342001)(74502001)(31966008)(74662001)(47446002)(54356001)(46102001)(69226001)(85306002)(81816001)(83072001)(15975445006)(81686001)(80976001)(59766001)(77982001)(76482001)(54316002)(56776001)(76576001)(19580405001)(83322001)(79102001)(19580395003)(63696002)(65816001)(80022001)(56816003)(66066001)(76786001)(77096001)(76796001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.54; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail9-db8 (localhost.localdomain [127.0.0.1]) by mail9-db8 (MessageSwitch) id 1382480179658093_7515; Tue, 22 Oct 2013 22:16:19 +0000 (UTC) Received: from DB8EHSMHS001.bigfish.com (unknown [10.174.8.240]) by mail9-db8.bigfish.com (Postfix) with ESMTP id 9C3BA3000A1; Tue, 22 Oct 2013 22:16:19 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS001.bigfish.com (10.174.4.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 22 Oct 2013 22:16:19 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 22 Oct 2013 22:16:10 +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.800.7; Tue, 22 Oct 2013 22:16:08 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.54]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.54]) with mapi id 15.00.0800.005; Tue, 22 Oct 2013 22:16:07 +0000 From: John E Drake To: Lou Berger , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] IETF 88 - CCAMP agenda requests Thread-Index: Ac7A62fizl6s11uwRBqP7yxjH/V66QOgAlyAAAHPtPA= Date: Tue, 22 Oct 2013 22:16:06 +0000 Message-ID: <149dc7ad437046e4be741bf1b857a6ec@BY2PR05MB142.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.ericsson.se> <5266EA49.8050408@labn.net> In-Reply-To: <5266EA49.8050408@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] x-forefront-prvs: 00073DB75F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 22:16:29 -0000 Lou, Comment inline. Yours Irrespectively, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Tuesday, October 22, 2013 2:13 PM > To: CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests >=20 > The draft agenda for Vancouver has been posted at > http://www.ietf.org/proceedings/88/agenda/agenda-88-ccamp >=20 > Kudos to Daniele for pulling the info together. >=20 > The first 90 minutes are scheduled for the UNI/PCE/ENNI/MLN/... > discussion. This portion of the agenda will have presentations that will= be > limited to use cases and current limitations (presenters, try to limit yo= urself to > 2 slides per use case) and then an open discussion. [JD] Given what you've written, above, what purpose is served by presentat= ions of the following drafts? I had the impression that you wanted this session to be used by the group to figure out its dir= ection wrt client/server networking issues. I don't think these drafts will help in any way. =20 4 9:27 5 Title: GMPLS-based Hierarchy LSP Creation in Multi-Region and Mu= lti-Layer Networks=20 Draft: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-h-lsp-mln-05= =20 Presenter: Xian Zhang=20 6 9:39 7 Title: RSVP-TE extension for extension for signaling Objective F= unction and Metric Bound=20 Draft: http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function= -metric-bound-04=20 Presenter: George Swallow=20 8 9:53 7 Title: UNI Extensions for Diversity and Latency Support=20 Draft: http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-02=20 Presenter: Dieter Beller=20 10 10:30 5 Title: Mutually Exclusive Link Group=20 Draft: http://tools.ietf.org/html/draft-beeram-ccamp-melg-02=20 Presenter: Vishnu Pavan Beeram=20 11 10:35 7 Title: Shared Resource Link Group=20 Draft: http://tools.ietf.org/html/draft-beeram-ccamp-srclg-00=20 Presenter: Vishnu Pavan Beeram=20 12 10:42 7 Title: Network Assigned Upstream Label:=20 Draft: http://tools.ietf.org/html/draft-beeram-ccamp-network-assigned-u= pstream-label-00=20 Presenter: Vishnu Pavan Beeram=20 13 10:49 8 Title: Extensions to Resource ReSerVation Protocol-Traffic Eng= ineering (RSVP- TE) to Support Route Exclusion Using Path Key Subobject=20 Draft: http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pat= hkey-00=20 Presenter: Xian Zhang=20 14 10:57 8 Title: Extension to LMP/DWDM for DWDM Optical Line Systems to = manage application code of optical interface parameters in DWDM application= =20 Draft: http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp-0= 4=20 Presenter: Gert Grammel=20 15 11:05 10 Title: Routing & signaling extensions for FlexGrid=20 Draft: http://tools.ietf.org/html/draft-dhillon-ccamp-super-channel-osp= fte-ext-06=20 http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-label-06= =20 http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-param-sig= -03=20 http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-param-osp= fte-03=20 Presenter: Rajan Rao=20 16 11:15 7 Title: OSPF-TE extensions for MLNMRN based on OTN=20 Draft: http://tools.ietf.org/html/draft-rao-ccamp-mlnmrn-otn-ospfte-ext= -03=20 Presenter: Rajan Rao=20 17 11:22 8 Title: RSVP-TE extensions for RRO editing=20 Draft: http://tools.ietf.org/html/draft-hartley-ccamp-rro-editing-00=20 Presenter: Zafar Ali=20 From zhang.xian@huawei.com Tue Oct 22 18:34:17 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38BD11E8229 for ; Tue, 22 Oct 2013 18:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.503 X-Spam-Level: X-Spam-Status: No, score=-5.503 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLBHOhP+MT8V for ; Tue, 22 Oct 2013 18:34:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 021CB11E80ED for ; Tue, 22 Oct 2013 18:34:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXB75609; Wed, 23 Oct 2013 01:34:08 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 23 Oct 2013 02:34:08 +0100 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 23 Oct 2013 02:34:08 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.96]) by szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id 14.03.0146.000; Wed, 23 Oct 2013 09:33:58 +0800 From: "Zhangxian (Xian)" To: John E Drake , Lou Berger , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] IETF 88 - CCAMP agenda requests Thread-Index: Ac7A62fizl6s11uwRBqP7yxjH/V66QOPPtOAAAI2/QAAF3FJ4A== Date: Wed, 23 Oct 2013 01:33:57 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.ericsson.se> <5266EA49.8050408@labn.net> <149dc7ad437046e4be741bf1b857a6ec@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <149dc7ad437046e4be741bf1b857a6ec@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 01:34:17 -0000 SGksIEpvaG4sIA0KDQogIFNpbmNlIExvdSBtZW50aW9uZWQgdG8gYWRkcmVzcyAiIFVOSS9QQ0Uv RU5OSS9NTE4vLi4uIiwgSU1PLCBQcmVzZW50YXRpb24gNCwgd2hpY2ggSSBjby1hdXRob3IsIGZp dHMgaW4gdGhlIHNjb3BlLiBPZiBjb3Vyc2UsIGxpbWl0IHRvIHRoZSB1c2UgY2FzZSBhcyBzcGVj aWZpZWQgYmVsb3cuDQoNCiAgSSBjYW5ub3Qgc3BlYWsgZm9yIG90aGVyIGRyYWZ0cy4gQnV0IGZy b20gdGhlIHRpdGxlLCBQcmVzZW50YXRpb24gOCBhbHNvIGZpdHMgaW4gdGhlIHNjb3BlPyBBcyBm b3IgcHJlc2VudGF0aW9ucyBzdGFydGluZyBmcm9tIE5vLiAxMCwgdGhleSBhcmUgbm90IHdpdGhp biAidGhlIGZpcnN0IDkwLW1pbnV0ZSBzbG90Ii4NCg0KUmVnYXJkcywNClhpYW4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBFIERyYWtlDQpTZW50 OiAyMDEzxOoxMNTCMjPI1SA2OjE2DQpUbzogTG91IEJlcmdlcjsgQ0NBTVAgKGNjYW1wQGlldGYu b3JnKQ0KU3ViamVjdDogUmU6IFtDQ0FNUF0gSUVURiA4OCAtIENDQU1QIGFnZW5kYSByZXF1ZXN0 cw0KDQpMb3UsDQoNCkNvbW1lbnQgaW5saW5lLg0KDQpZb3VycyBJcnJlc3BlY3RpdmVseSwNCg0K Sm9obg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4g T2YgTG91IEJlcmdlcg0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIyLCAyMDEzIDI6MTMgUE0N Cj4gVG86IENDQU1QIChjY2FtcEBpZXRmLm9yZykNCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gSUVU RiA4OCAtIENDQU1QIGFnZW5kYSByZXF1ZXN0cw0KPiANCj4gVGhlIGRyYWZ0IGFnZW5kYSBmb3Ig VmFuY291dmVyIGhhcyBiZWVuIHBvc3RlZCBhdA0KPiAgICBodHRwOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzg4L2FnZW5kYS9hZ2VuZGEtODgtY2NhbXANCj4gDQo+IEt1ZG9zIHRvIERhbmll bGUgZm9yIHB1bGxpbmcgdGhlIGluZm8gdG9nZXRoZXIuDQo+IA0KPiBUaGUgZmlyc3QgOTAgbWlu dXRlcyBhcmUgc2NoZWR1bGVkIGZvciB0aGUgVU5JL1BDRS9FTk5JL01MTi8uLi4NCj4gZGlzY3Vz c2lvbi4gIFRoaXMgcG9ydGlvbiBvZiB0aGUgYWdlbmRhIHdpbGwgaGF2ZSBwcmVzZW50YXRpb25z IHRoYXQgd2lsbCBiZQ0KPiBsaW1pdGVkIHRvIHVzZSBjYXNlcyBhbmQgY3VycmVudCBsaW1pdGF0 aW9ucyAocHJlc2VudGVycywgdHJ5IHRvIGxpbWl0IHlvdXJzZWxmIHRvDQo+IDIgc2xpZGVzIHBl ciB1c2UgY2FzZSkgYW5kIHRoZW4gYW4gb3BlbiBkaXNjdXNzaW9uLg0KDQpbSkRdICBHaXZlbiB3 aGF0IHlvdSd2ZSB3cml0dGVuLCBhYm92ZSwgd2hhdCBwdXJwb3NlIGlzIHNlcnZlZCBieSBwcmVz ZW50YXRpb25zIG9mIHRoZSBmb2xsb3dpbmcgZHJhZnRzPyAgSSBoYWQgdGhlIGltcHJlc3Npb24N CiB0aGF0IHlvdSB3YW50ZWQgdGhpcyBzZXNzaW9uIHRvIGJlIHVzZWQgYnkgdGhlIGdyb3VwIHRv IGZpZ3VyZSBvdXQgaXRzIGRpcmVjdGlvbiB3cnQgY2xpZW50L3NlcnZlciBuZXR3b3JraW5nIGlz c3Vlcy4gIEkgZG9uJ3QgdGhpbmsNCnRoZXNlIGRyYWZ0cyB3aWxsIGhlbHAgaW4gYW55IHdheS4g ICAgIA0KDQo0ICAgOToyNyA1IFRpdGxlOiBHTVBMUy1iYXNlZCBIaWVyYXJjaHkgTFNQIENyZWF0 aW9uIGluIE11bHRpLVJlZ2lvbiBhbmQgTXVsdGktTGF5ZXIgTmV0d29ya3MgDQogICAgRHJhZnQ6 IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWgtbHNw LW1sbi0wNSANCiAgICBQcmVzZW50ZXI6IFhpYW4gWmhhbmcgDQoNCjYgICA5OjM5IDcgVGl0bGU6 IFJTVlAtVEUgZXh0ZW5zaW9uIGZvciBleHRlbnNpb24gZm9yIHNpZ25hbGluZyBPYmplY3RpdmUg RnVuY3Rpb24gYW5kIE1ldHJpYyBCb3VuZCANCiAgICBEcmFmdDogaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYWxpLWNjYW1wLXJjLW9iamVjdGl2ZS1mdW5jdGlvbi1tZXRyaWMtYm91 bmQtMDQgDQogICAgUHJlc2VudGVyOiBHZW9yZ2UgU3dhbGxvdyANCg0KOCAgIDk6NTMgNyBUaXRs ZTogIFVOSSBFeHRlbnNpb25zIGZvciBEaXZlcnNpdHkgYW5kIExhdGVuY3kgU3VwcG9ydCANCiAg ICBEcmFmdDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmVkeWstY2NhbXAtdW5p LWV4dGVuc2lvbnMtMDIgDQogICAgUHJlc2VudGVyOiBEaWV0ZXIgQmVsbGVyIA0KDQoxMCAgIDEw OjMwIDUgVGl0bGU6IE11dHVhbGx5IEV4Y2x1c2l2ZSBMaW5rIEdyb3VwIA0KICAgIERyYWZ0OiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWVyYW0tY2NhbXAtbWVsZy0wMiANCiAg ICBQcmVzZW50ZXI6IFZpc2hudSBQYXZhbiBCZWVyYW0gDQoNCjExICAgMTA6MzUgNyBUaXRsZTog U2hhcmVkIFJlc291cmNlIExpbmsgR3JvdXAgDQogICAgRHJhZnQ6IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWJlZXJhbS1jY2FtcC1zcmNsZy0wMCANCiAgICBQcmVzZW50ZXI6IFZp c2hudSBQYXZhbiBCZWVyYW0gDQoNCjEyICAgMTA6NDIgNyBUaXRsZTogTmV0d29yayBBc3NpZ25l ZCBVcHN0cmVhbSBMYWJlbDogDQogICAgRHJhZnQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJlZXJhbS1jY2FtcC1uZXR3b3JrLWFzc2lnbmVkLXVwc3RyZWFtLWxhYmVsLTAwIA0K ICAgIFByZXNlbnRlcjogVmlzaG51IFBhdmFuIEJlZXJhbSANCg0KMTMgICAxMDo0OSA4IFRpdGxl OiBFeHRlbnNpb25zIHRvIFJlc291cmNlIFJlU2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgRW5n aW5lZXJpbmcgKFJTVlAtIFRFKSB0byBTdXBwb3J0IFJvdXRlIEV4Y2x1c2lvbiBVc2luZyBQYXRo IEtleSBTdWJvYmplY3QgDQogICAgRHJhZnQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXpoYW5nLWNjYW1wLXJvdXRlLWV4Y2x1c2lvbi1wYXRoa2V5LTAwIA0KICAgIFByZXNlbnRl cjogWGlhbiBaaGFuZyANCg0KMTQgICAxMDo1NyA4IFRpdGxlOiBFeHRlbnNpb24gdG8gTE1QL0RX RE0gZm9yIERXRE0gT3B0aWNhbCBMaW5lIFN5c3RlbXMgdG8gbWFuYWdlIGFwcGxpY2F0aW9uIGNv ZGUgb2Ygb3B0aWNhbCBpbnRlcmZhY2UgcGFyYW1ldGVycyBpbiBEV0RNIGFwcGxpY2F0aW9uIA0K ICAgIERyYWZ0OiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kaGFyaW5pZ2VydC1j Y2FtcC1nLTY5OC0yLWxtcC0wNCANCiAgICBQcmVzZW50ZXI6IEdlcnQgR3JhbW1lbCANCg0KMTUg ICAxMTowNSAxMCBUaXRsZTogUm91dGluZyAmIHNpZ25hbGluZyBleHRlbnNpb25zIGZvciBGbGV4 R3JpZCANCiAgICBEcmFmdDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGhpbGxv bi1jY2FtcC1zdXBlci1jaGFubmVsLW9zcGZ0ZS1leHQtMDYgDQogICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWh1c3NhaW4tY2NhbXAtc3VwZXItY2hhbm5lbC1sYWJlbC0wNiAN CiAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVzc2Fpbi1jY2FtcC1zdXBl ci1jaGFubmVsLXBhcmFtLXNpZy0wMyANCiAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaHVzc2Fpbi1jY2FtcC1zdXBlci1jaGFubmVsLXBhcmFtLW9zcGZ0ZS0wMyANCiAgICBQ cmVzZW50ZXI6IFJhamFuIFJhbyANCg0KMTYgICAxMToxNSA3IFRpdGxlOiBPU1BGLVRFIGV4dGVu c2lvbnMgZm9yIE1MTk1STiBiYXNlZCBvbiBPVE4gDQogICAgRHJhZnQ6IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXJhby1jY2FtcC1tbG5tcm4tb3RuLW9zcGZ0ZS1leHQtMDMgDQog ICAgUHJlc2VudGVyOiBSYWphbiBSYW8gDQoNCjE3ICAgMTE6MjIgOCBUaXRsZTogUlNWUC1URSBl eHRlbnNpb25zIGZvciBSUk8gZWRpdGluZyANCiAgICBEcmFmdDogaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaGFydGxleS1jY2FtcC1ycm8tZWRpdGluZy0wMCANCiAgICBQcmVzZW50 ZXI6IFphZmFyIEFsaSANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== From db3546@att.com Wed Oct 23 12:02:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B206911E8203 for ; Wed, 23 Oct 2013 12:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFFrnS5qTtAK for ; Wed, 23 Oct 2013 12:02:13 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id AEBB411E8212 for ; Wed, 23 Oct 2013 12:02:12 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 43d18625.0.4350004.00-197.12194777.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 23 Oct 2013 19:02:12 +0000 (UTC) X-MXL-Hash: 52681d34422a0fa4-06f77efdec7c18f30c53078e67b6af73a26bc608 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r9NJ2BCo014786; Wed, 23 Oct 2013 15:02:12 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r9NJ26l4014734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Oct 2013 15:02:08 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 23 Oct 2013 19:01:49 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0158.001; Wed, 23 Oct 2013 15:01:48 -0400 From: "BRUNGARD, DEBORAH A" To: John E Drake , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] IETF 88 - CCAMP agenda requests Thread-Index: AQHOz2t2vecu9tWV/Uegqz8NenKsdJoBjNEAgAEX4lA= Date: Wed, 23 Oct 2013 19:01:48 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.ericsson.se> <5266EA49.8050408@labn.net> <149dc7ad437046e4be741bf1b857a6ec@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <149dc7ad437046e4be741bf1b857a6ec@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=bcXcppzB c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=wSbAmmimycIA:10 a=7kb7fGpXyp8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=dGdpNulJpIYA:10 a=48vgC7mUAAAA:8 a=LIdrFWRhDnSJsG] X-AnalysisOut: [tYKkQA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=P1YRKsAHrxb] X-AnalysisOut: [L6pRB:21 a=HEeUsBhcyfjWB_14:21] Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:02:19 -0000 Hi John, Only slots 4, 6, and 8 are included in the discussion, the rest are slotted= for after the discussion. The authors requested time for the discussion and so we expect them to cove= r their use case and limitations (two slides only). Thanks, Deborah -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Tuesday, October 22, 2013 6:16 PM To: Lou Berger; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests Lou, Comment inline. Yours Irrespectively, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Tuesday, October 22, 2013 2:13 PM > To: CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests >=20 > The draft agenda for Vancouver has been posted at > http://www.ietf.org/proceedings/88/agenda/agenda-88-ccamp >=20 > Kudos to Daniele for pulling the info together. >=20 > The first 90 minutes are scheduled for the UNI/PCE/ENNI/MLN/... > discussion. This portion of the agenda will have presentations that will= be > limited to use cases and current limitations (presenters, try to limit yo= urself to > 2 slides per use case) and then an open discussion. [JD] Given what you've written, above, what purpose is served by presentat= ions of the following drafts? I had the impression that you wanted this session to be used by the group to figure out its dir= ection wrt client/server networking issues. I don't think these drafts will help in any way. =20 4 9:27 5 Title: GMPLS-based Hierarchy LSP Creation in Multi-Region and Mu= lti-Layer Networks=20 Draft: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-h-lsp-mln-05= =20 Presenter: Xian Zhang=20 6 9:39 7 Title: RSVP-TE extension for extension for signaling Objective F= unction and Metric Bound=20 Draft: http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function= -metric-bound-04=20 Presenter: George Swallow=20 8 9:53 7 Title: UNI Extensions for Diversity and Latency Support=20 Draft: http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-02=20 Presenter: Dieter Beller=20 10 10:30 5 Title: Mutually Exclusive Link Group=20 Draft: http://tools.ietf.org/html/draft-beeram-ccamp-melg-02=20 Presenter: Vishnu Pavan Beeram=20 11 10:35 7 Title: Shared Resource Link Group=20 Draft: http://tools.ietf.org/html/draft-beeram-ccamp-srclg-00=20 Presenter: Vishnu Pavan Beeram=20 12 10:42 7 Title: Network Assigned Upstream Label:=20 Draft: http://tools.ietf.org/html/draft-beeram-ccamp-network-assigned-u= pstream-label-00=20 Presenter: Vishnu Pavan Beeram=20 13 10:49 8 Title: Extensions to Resource ReSerVation Protocol-Traffic Eng= ineering (RSVP- TE) to Support Route Exclusion Using Path Key Subobject=20 Draft: http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pat= hkey-00=20 Presenter: Xian Zhang=20 14 10:57 8 Title: Extension to LMP/DWDM for DWDM Optical Line Systems to = manage application code of optical interface parameters in DWDM application= =20 Draft: http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp-0= 4=20 Presenter: Gert Grammel=20 15 11:05 10 Title: Routing & signaling extensions for FlexGrid=20 Draft: http://tools.ietf.org/html/draft-dhillon-ccamp-super-channel-osp= fte-ext-06=20 http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-label-06= =20 http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-param-sig= -03=20 http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-param-osp= fte-03=20 Presenter: Rajan Rao=20 16 11:15 7 Title: OSPF-TE extensions for MLNMRN based on OTN=20 Draft: http://tools.ietf.org/html/draft-rao-ccamp-mlnmrn-otn-ospfte-ext= -03=20 Presenter: Rajan Rao=20 17 11:22 8 Title: RSVP-TE extensions for RRO editing=20 Draft: http://tools.ietf.org/html/draft-hartley-ccamp-rro-editing-00=20 Presenter: Zafar Ali=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Wed Oct 23 12:16:50 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C4911E83BD for ; Wed, 23 Oct 2013 12:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.728 X-Spam-Level: X-Spam-Status: No, score=-4.728 tagged_above=-999 required=5 tests=[AWL=1.871, 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 f-K36KQTCSOZ for ; Wed, 23 Oct 2013 12:16:45 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id E911E11E82F8 for ; Wed, 23 Oct 2013 12:16:41 -0700 (PDT) Received: from mail193-tx2-R.bigfish.com (10.9.14.230) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Oct 2013 19:16:41 +0000 Received: from mail193-tx2 (localhost [127.0.0.1]) by mail193-tx2-R.bigfish.com (Postfix) with ESMTP id 173783200C4; Wed, 23 Oct 2013 19:16:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz9371I542Iec9I1432I4015I1447Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail193-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:(377454003)(189002)(199002)(51704005)(164054003)(51914003)(37854004)(13464003)(81342001)(74876001)(50986001)(47736001)(47976001)(49866001)(4396001)(74706001)(81542001)(33646001)(74366001)(15975445006)(76482001)(69226001)(54316002)(56776001)(81686001)(59766001)(77982001)(51856001)(46102001)(54356001)(31966008)(85306002)(79102001)(53806001)(63696002)(65816001)(66066001)(83072001)(80022001)(47446002)(74502001)(74316001)(74662001)(15202345003)(19580395003)(80976001)(83322001)(19580405001)(56816003)(76796001)(76786001)(77096001)(76576001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail193-tx2 (localhost.localdomain [127.0.0.1]) by mail193-tx2 (MessageSwitch) id 1382555799734112_30194; Wed, 23 Oct 2013 19:16:39 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.236]) by mail193-tx2.bigfish.com (Postfix) with ESMTP id 9C639C0041; Wed, 23 Oct 2013 19:16:39 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Oct 2013 19:16:39 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 23 Oct 2013 19:16:39 +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.800.7; Wed, 23 Oct 2013 19:16:35 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.54]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.54]) with mapi id 15.00.0800.005; Wed, 23 Oct 2013 19:16:35 +0000 From: John E Drake To: "BRUNGARD, DEBORAH A" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] IETF 88 - CCAMP agenda requests Thread-Index: Ac7A62fizl6s11uwRBqP7yxjH/V66QOgAlyAAAHPtPAAK+i2AAAAISqQ Date: Wed, 23 Oct 2013 19:16:34 +0000 Message-ID: <5aa36c70beba485d9f6a8aff721dce7e@BY2PR05MB142.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.ericsson.se> <5266EA49.8050408@labn.net> <149dc7ad437046e4be741bf1b857a6ec@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 000800954F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:16:50 -0000 Deborah, Thanks for the clarification, however, I still have problems w/ 4, 6, & 8, = as they are clearly solutions drafts.=20 Yours Irrespectively, John > -----Original Message----- > From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] > Sent: Wednesday, October 23, 2013 12:02 PM > To: John E Drake; CCAMP (ccamp@ietf.org) > Subject: RE: [CCAMP] IETF 88 - CCAMP agenda requests >=20 > Hi John, >=20 > Only slots 4, 6, and 8 are included in the discussion, the rest are slott= ed for > after the discussion. >=20 > The authors requested time for the discussion and so we expect them to co= ver > their use case and limitations (two slides only). >=20 > Thanks, > Deborah >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of John E Drake > Sent: Tuesday, October 22, 2013 6:16 PM > To: Lou Berger; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests >=20 > Lou, >=20 > Comment inline. >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > > Of Lou Berger > > Sent: Tuesday, October 22, 2013 2:13 PM > > To: CCAMP (ccamp@ietf.org) > > Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests > > > > The draft agenda for Vancouver has been posted at > > http://www.ietf.org/proceedings/88/agenda/agenda-88-ccamp > > > > Kudos to Daniele for pulling the info together. > > > > The first 90 minutes are scheduled for the UNI/PCE/ENNI/MLN/... > > discussion. This portion of the agenda will have presentations that > > will be limited to use cases and current limitations (presenters, try > > to limit yourself to > > 2 slides per use case) and then an open discussion. >=20 > [JD] Given what you've written, above, what purpose is served by > presentations of the following drafts? I had the impression that you wa= nted > this session to be used by the group to figure out its direction wrt clie= nt/server > networking issues. I don't think > these drafts will help in any way. >=20 > 4 9:27 5 Title: GMPLS-based Hierarchy LSP Creation in Multi-Region and = Multi- > Layer Networks > Draft: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-h-lsp-mln-0= 5 > Presenter: Xian Zhang >=20 > 6 9:39 7 Title: RSVP-TE extension for extension for signaling Objective > Function and Metric Bound > Draft: http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-functi= on- > metric-bound-04 > Presenter: George Swallow >=20 > 8 9:53 7 Title: UNI Extensions for Diversity and Latency Support > Draft: http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-02 > Presenter: Dieter Beller >=20 > 10 10:30 5 Title: Mutually Exclusive Link Group > Draft: http://tools.ietf.org/html/draft-beeram-ccamp-melg-02 > Presenter: Vishnu Pavan Beeram >=20 > 11 10:35 7 Title: Shared Resource Link Group > Draft: http://tools.ietf.org/html/draft-beeram-ccamp-srclg-00 > Presenter: Vishnu Pavan Beeram >=20 > 12 10:42 7 Title: Network Assigned Upstream Label: > Draft: http://tools.ietf.org/html/draft-beeram-ccamp-network-assigned= - > upstream-label-00 > Presenter: Vishnu Pavan Beeram >=20 > 13 10:49 8 Title: Extensions to Resource ReSerVation Protocol-Traffic > Engineering (RSVP- TE) to Support Route Exclusion Using Path Key Subobjec= t > Draft: http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion- > pathkey-00 > Presenter: Xian Zhang >=20 > 14 10:57 8 Title: Extension to LMP/DWDM for DWDM Optical Line Systems t= o > manage application code of optical interface parameters in DWDM applicati= on > Draft: http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp= -04 > Presenter: Gert Grammel >=20 > 15 11:05 10 Title: Routing & signaling extensions for FlexGrid > Draft: http://tools.ietf.org/html/draft-dhillon-ccamp-super-channel-o= spfte- > ext-06 > http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-label-0= 6 > http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-param-s= ig-03 > http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-param- > ospfte-03 > Presenter: Rajan Rao >=20 > 16 11:15 7 Title: OSPF-TE extensions for MLNMRN based on OTN > Draft: http://tools.ietf.org/html/draft-rao-ccamp-mlnmrn-otn-ospfte-e= xt-03 > Presenter: Rajan Rao >=20 > 17 11:22 8 Title: RSVP-TE extensions for RRO editing > Draft: http://tools.ietf.org/html/draft-hartley-ccamp-rro-editing-00 > Presenter: Zafar Ali >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From daniele.ceccarelli@ericsson.com Thu Oct 24 02:59:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D54F11E8165 for ; Thu, 24 Oct 2013 02:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[AWL=-1.343, 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 ypzgwvAiKdwQ for ; Thu, 24 Oct 2013 02:59:25 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC8A11E80E3 for ; Thu, 24 Oct 2013 02:59:25 -0700 (PDT) X-AuditID: c1b4fb38-b7f178e00000233b-4e-5268ef7b8005 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5C.18.09019.B7FE8625; Thu, 24 Oct 2013 11:59:24 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.27]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 11:59:23 +0200 From: Daniele Ceccarelli To: John E Drake , "BRUNGARD, DEBORAH A" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] IETF 88 - CCAMP agenda requests Thread-Index: Ac7A62fizl6s11uwRBqP7yxjH/V66QOb0XmAAAI2/gAAK4FtAAAAhAYAACLX2PA= Date: Thu, 24 Oct 2013 09:59:23 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4817C8F7@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.ericsson.se> <5266EA49.8050408@labn.net> <149dc7ad437046e4be741bf1b857a6ec@BY2PR05MB142.namprd05.prod.outlook.com> <5aa36c70beba485d9f6a8aff721dce7e@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <5aa36c70beba485d9f6a8aff721dce7e@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvjW7N+4wgg5WTeSyezLnBYnG5q5vd Ys5dZwdmj5f9cxg9liz5yeRxvekqewBzFJdNSmpOZllqkb5dAlfG7ZZtbAXz9CpmvnjN1sD4 SKWLkZNDQsBEov/5TnYIW0ziwr31bF2MXBxCAkcZJY70bWCFcBYzSnw83AvkcHCwCVhJPDnk A9IgIlAlsWvmFDYQWxho0J6Va9gg4qYSPx5/Y4Kw/SSmH3rBCmKzCKhKPO1qYQaxeQW8Jc7e 7WaBmH+RSeJU5wSwZk6BMInW08tYQGxGAVmJCbsXMYLYzALiEreezGeCuFRAYsme88wQtqjE y8f/WCFsRYn2pw1Q9XoSN6ZCHMcsoC2xbOFrqMWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEj yypGjuLU4qTcdCODTYzACDm45bfFDsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgbGk52WK+OL/VRZ8fJpfYg+y1/gcOirHeqX/zWXNa8WLcu1qE42+sD3Y39Jt sHo74/u4T6fm9cWlVOt7fX+4S2eFztRlaaKZvz9kz5z0requd/o8ibjOAP3q21N+Jq7VFT/6 OMH/n9zLICWpX5d0qrvuyTqtkWs/VvbNplqgSPTid6s77pNS7ZRYijMSDbWYi4oTARQMwLde AgAA Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 09:59:42 -0000 Hi John, You're right those are solution drafts, but the request was (especially for= solution drafts) to give a two slides presentation indicating which use ca= ses they want to solve and what is missing but *not to talk about how to so= lve them*. Hopefully presentations will follow the guidelines and we'll be able to foc= us the whole discussion on use cases and what's missing but not on solution= s. BR Daniele > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of John E Drake > Sent: mercoled=EC 23 ottobre 2013 21:17 > To: BRUNGARD, DEBORAH A; CCAMP (ccamp@ietf.org) > Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests >=20 > Deborah, >=20 > Thanks for the clarification, however, I still have problems w/ 4, 6, & 8= , as > they are clearly solutions drafts. >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] > > Sent: Wednesday, October 23, 2013 12:02 PM > > To: John E Drake; CCAMP (ccamp@ietf.org) > > Subject: RE: [CCAMP] IETF 88 - CCAMP agenda requests > > > > Hi John, > > > > Only slots 4, 6, and 8 are included in the discussion, the rest are > > slotted for after the discussion. > > > > The authors requested time for the discussion and so we expect them to > > cover their use case and limitations (two slides only). > > > > Thanks, > > Deborah > > > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of John E Drake > > Sent: Tuesday, October 22, 2013 6:16 PM > > To: Lou Berger; CCAMP (ccamp@ietf.org) > > Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests > > > > Lou, > > > > Comment inline. > > > > Yours Irrespectively, > > > > John > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf Of Lou Berger > > > Sent: Tuesday, October 22, 2013 2:13 PM > > > To: CCAMP (ccamp@ietf.org) > > > Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests > > > > > > The draft agenda for Vancouver has been posted at > > > http://www.ietf.org/proceedings/88/agenda/agenda-88-ccamp > > > > > > Kudos to Daniele for pulling the info together. > > > > > > The first 90 minutes are scheduled for the UNI/PCE/ENNI/MLN/... > > > discussion. This portion of the agenda will have presentations that > > > will be limited to use cases and current limitations (presenters, > > > try to limit yourself to > > > 2 slides per use case) and then an open discussion. > > > > [JD] Given what you've written, above, what purpose is served by > > presentations of the following drafts? I had the impression that you > > wanted this session to be used by the group to figure out its > > direction wrt client/server networking issues. I don't think these > > drafts will help in any way. > > > > 4 9:27 5 Title: GMPLS-based Hierarchy LSP Creation in Multi-Region an= d > Multi- > > Layer Networks > > Draft: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-h-lsp-mln= -05 > > Presenter: Xian Zhang > > > > 6 9:39 7 Title: RSVP-TE extension for extension for signaling Objecti= ve > > Function and Metric Bound > > Draft: > > http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function- > > metric-bound-04 > > Presenter: George Swallow > > > > 8 9:53 7 Title: UNI Extensions for Diversity and Latency Support > > Draft: http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-= 02 > > Presenter: Dieter Beller > > > > 10 10:30 5 Title: Mutually Exclusive Link Group > > Draft: http://tools.ietf.org/html/draft-beeram-ccamp-melg-02 > > Presenter: Vishnu Pavan Beeram > > > > 11 10:35 7 Title: Shared Resource Link Group > > Draft: http://tools.ietf.org/html/draft-beeram-ccamp-srclg-00 > > Presenter: Vishnu Pavan Beeram > > > > 12 10:42 7 Title: Network Assigned Upstream Label: > > Draft: > > http://tools.ietf.org/html/draft-beeram-ccamp-network-assigned- > > upstream-label-00 > > Presenter: Vishnu Pavan Beeram > > > > 13 10:49 8 Title: Extensions to Resource ReSerVation Protocol-Traffic > > Engineering (RSVP- TE) to Support Route Exclusion Using Path Key > Subobject > > Draft: > > http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion- > > pathkey-00 > > Presenter: Xian Zhang > > > > 14 10:57 8 Title: Extension to LMP/DWDM for DWDM Optical Line Systems > to > > manage application code of optical interface parameters in DWDM > application > > Draft: http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-l= mp-04 > > Presenter: Gert Grammel > > > > 15 11:05 10 Title: Routing & signaling extensions for FlexGrid > > Draft: > > http://tools.ietf.org/html/draft-dhillon-ccamp-super-channel-ospfte- > > ext-06 > > http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-label= -06 > > http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-param= - > sig-03 > > > > http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-param- > > ospfte-03 > > Presenter: Rajan Rao > > > > 16 11:15 7 Title: OSPF-TE extensions for MLNMRN based on OTN > > Draft: http://tools.ietf.org/html/draft-rao-ccamp-mlnmrn-otn-ospfte= - > ext-03 > > Presenter: Rajan Rao > > > > 17 11:22 8 Title: RSVP-TE extensions for RRO editing > > Draft: http://tools.ietf.org/html/draft-hartley-ccamp-rro-editing-0= 0 > > Presenter: Zafar Ali > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Thu Oct 24 06:14:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C07311E81A5 for ; Thu, 24 Oct 2013 06:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.098 X-Spam-Level: X-Spam-Status: No, score=-102.098 tagged_above=-999 required=5 tests=[AWL=0.167, 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 1FBi1QyMDVcm for ; Thu, 24 Oct 2013 06:14:00 -0700 (PDT) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 2F5B911E8329 for ; Thu, 24 Oct 2013 06:14:00 -0700 (PDT) Received: (qmail 14781 invoked by uid 0); 24 Oct 2013 13:13:38 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.mail.unifiedlayer.com with SMTP; 24 Oct 2013 13:13:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=E24L3itSL1G7gtQss4YUGQCKtFmz/N726/Thwdoj5r0=; b=UdEuUvE+a8xlGToE2SlJmYBKgXQ8uXnPi7CsA/S94rgKG0rRYR8kukNLIHRKH9X1e4QPSwXre1UQCjFn7J+IyyExUHrJvoJgL8cf1WjcFJRDc2f+fK+9lTI+TSPN+CsO; Received: from box313.bluehost.com ([69.89.31.113]:51982 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VZKjJ-0002CS-SI; Thu, 24 Oct 2013 07:13:38 -0600 Message-ID: <52691CFB.6080805@labn.net> Date: Thu, 24 Oct 2013 09:13:31 -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: CCAMP , Warren Kumari X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] FWD: [secdir] Review of: draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 13:14:04 -0000 FYI - from http://www.ietf.org/mail-archive/web/secdir/current/msg04230.html To: "iesg at ietf.org" , "secdir at ietf.org" , draft-ietf-ccamp-otn-g709-info-model.all at tools.ietf.org Subject: [secdir] Review of: draft-ietf-ccamp-otn-g709-info-model From: Warren Kumari Date: Fri, 13 Sep 2013 18:53:03 -0400 Delivered-to: secdir at ietfa.amsl.com List-archive: List-help: List-id: Security Area Directorate List-post: List-subscribe: , List-unsubscribe: , Be ye not afraid... I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary for Security AD: Nothing to see here, move along... General summary: This document could do with a careful reading for nits and similar. It also use a large number of acronyms that are not defined in it -- e.g: ODUflex, GFP-F, ODUk. While there may be really well known in some spheres, I have *no* idea what they mean. Please explain / expand them, or (probably much easier) simply say: "Familiarity with GMPLS and is expected, especially [References]". The Security Considerations section contains: "New types of information to be conveyed regard OTN containers and hierarchies and from a security standpoint this memo does not introduce further risks with respect to the information that can be currently conveyed via GMPLS protocols." I had a really hard time parsing this sentence -- I agree that this does't seem to introduce any new security issues, but the sentence seems to missing some words. Or something. Some nits: draft-ietf-ccamp-gmpls-ospf-g709v3-07 is now draft-ietf-ccamp-gmpls-ospf-g709v3-08 draft-ietf-ccamp-gmpls-signaling-g709v3-11 is now draft-ietf-ccamp-gmpls-signaling-g709v3-12 Section 1: O: extensions need to support [G.709-2012] is provided in [OTN-FWK]. P: extensions needed to support [G.709-2012] is provided in [OTN-FWK]. C: s/need/needed/ Section 2. G.709 Mapping and Multiplexing Capabilities O: The digital OTN layered structure is comprised of digital path layer (ODU) and digital section layer (OTU) P: The digital OTN layered structure is comprised of the digital path layer (ODU) and the digital section layer (OTU) O: needs to be advertised and signaled, what is already there in GMPLS and what is missing. P: needs to be advertised and signaled, what already exists GMPLS and what is missing. 3. Tributary Slot Granularity O: ITU-T recommendation defines two types of Tributary Slot (TS) C: Which ITU-T recommendation? Reference. O: - If both ends of a link are new cards supporting both 1.25Gbps TS and 2.5Gbps TS, then the link will work with 1.25Gbps TS. C: Throughout this section you reference "new" and "old" cards. I think you need better names or simply removed the words "new" and "old". I could presumably go to my vendor and buy a card that only supports 2.5Gbps tomorrow and that would be "new" for me. 3.2. Control Plane considerations O: In case they cannot, A will compute an alternate path from itself to Z (see figure 4). P: If not, A will compute an alternate path from itself to Z (see figure 4). or P: If they cannot, A will compute an alternate path from itself to Z (see figure 4). or P: In the case that they cannot, A will compute an alternate path from itself to Z (see figure 4). O: Moreover, also TS granularity information needs to be signaled. P: Moreover, TS granularity information also needs to be signaled. O: the signaling to permit node C (see figure 5) choose the right one P: the signaling to permit node C (see figure 5) to choose the right one O: towards D. In case the full ERO is provided in the signaling with P: towards D. In the case that the full ERO is provided in the signaling with or P: towards D. In cases where the full ERO is provided in the signaling with (I stopped here) W -- I once absend-mindedly ordered Three Mile Island dressing in a restaurant and, with great presence of mind, they brought Thousand Island Dressing and a bottle of chili sauce. -- Terry Pratchett From leeyoung@huawei.com Fri Oct 25 13:43:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD6C11E8201 for ; Fri, 25 Oct 2013 13:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24AU9JZ9b39P for ; Fri, 25 Oct 2013 13:43:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E8E8E11E81DC for ; Fri, 25 Oct 2013 13:43:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXE87610; Fri, 25 Oct 2013 20:43:36 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 21:43:27 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 21:43:35 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 13:43:30 -0700 From: Leeyoung To: "ccamp@ietf.org" Thread-Topic: draft-ietf-ccamp-general-constraint-encode Thread-Index: AQHO0UlhHRmariezxUa6c3vUdmUMgZoFwepAgAB8ggD//4vkcIAAeLMAgAAJQgD//4/fYIAABsOQ Date: Fri, 25 Oct 2013 20:43:29 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17291DC833@dfweml511-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.126] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] FW: draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:43:44 -0000 Here's some comments on draft-ietf-ccamp-general-constraint-encode from Ram= on and the resolution.=20 Thanks, Young -----Original Message----- From: Leeyoung [mailto:leeyoung@huawei.com]=20 Sent: Friday, October 25, 2013 3:19 PM To: Ramon Casellas; draft-ietf-ccamp-general-constraint-encode@tools.ietf.o= rg Cc: Morro Roberto Subject: RE: draft-ietf-ccamp-general-constraint-encode Hi Ramon, It works for me. Please confirm the changes:=20 s/PRI (Priority Flags, 8 bits): Indicates priority level applied to Label Set Field. Bit 8 corresponds to priority level 0 and bit 15 corresponds to priority level 7 /PRI (Priority Flags, 8 bits): A bitmap used to indicate which priorities are being advertised. The bitmap is in ascending order, with the leftmost bit representing priority level 0 (i.e., the highest) and the rightmost bit representing priority level 7 (i.e., the lowest). A bit MUST be set (1) corresponding to each priority represented in the sub-TLV, and MUST NOT be set (0) when the corresponding priority is not represented. At least one priority level MUST be advertised that, unless overridden by local policy, SHALL be at priority level 0. And Appendix A.5 will be changed as follows:=20 A.5. Priority Flags in Available/Shared Backup Labels sub-TLV If one wants to make a set of labels (indicated by Label Set Field #1) available only for highest priority level (Priority Level 0) while allowing a set of labels (indicated by Label Set Field #2) available to all priority levels (Priority Level 7), the following encoding will express such need. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 0 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #2 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----Original Message----- From: Ramon Casellas [mailto:ramon.casellas@cttc.es] Sent: Friday, October 25, 2013 3:00 PM To: Leeyoung; draft-ietf-ccamp-general-constraint-encode@tools.ietf.org Cc: Morro Roberto Subject: Re: draft-ietf-ccamp-general-constraint-encode El 25/10/2013 21:26, Ramon Casellas escribi=F3: > El 25/10/2013 21:24, Leeyoung escribi=F3: >> Hi Ramon, >> >> If I recall, the pri field was 3 bits and someone (I forgot) raised=20 >> that it should be a 8-bit field to match with other priority encoding=20 >> in MPLS. Hi again, my hopeful final message :-) but it is slightly different (the go= od part, it does not change the size and it goes in line with OTN) I checked, for example, http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-10 which is much clearer: - I has 8 bits field, each bit corresponding to a priority - Bits are set to "1" is that priority "applies". - The same labelset can be used for different priorities, without copying e= ach one - So it would leave a 8 bit field - Priority (8 bits): A bitmap used to indicate which priorities are being advertised. The bitmap is in ascending order, with the leftmost bit representing priority level 0 (i.e., the highest) and the rightmost bit representing priority level 7 (i.e., the lowest). A bit MUST be set (1) corresponding to each priority represented in the sub-TLV, and MUST NOT be set (0) when the corresponding priority is not represented. At least one priority level MUST be advertised that, unless overridden by local policy, SHALL be at priority level 0. I guess the final message is "we should change something, not sure what" :)= R. -- Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division Opt= ical Networks and Systems Department -- http://wikiona.cttc.es CTTC - Centr= e Tecnol=F2gic de Telecomunicacions de Catalunya Parc Mediterrani de la Tec= nologia (PMT) - Edifici B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefel= s (Barcelona) - Spain Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01 From zali@cisco.com Sun Oct 27 10:20:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC93411E8299 for ; Sun, 27 Oct 2013 10:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyPoq+Lm1rPe for ; Sun, 27 Oct 2013 10:20:50 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CA19F11E8155 for ; Sun, 27 Oct 2013 10:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9401; q=dns/txt; s=iport; t=1382894450; x=1384104050; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dzRoM2jgRBPVU3OcXV3pLuZuE0ugDAdU28LbDIErbPQ=; b=j0KfuOnf0/j3Vsr5V50OICCjgHoW/dmEKZlS46Mzx7YMB5hFTnHWLudz hkEEBH83w9NYP1RrQxjKeLa1xeNb7xHelaq0IpfG4/p0rKdYMaCc6IJe3 UwbiIPQ0y2LQJHU4ZP+sOurRMYpaqcjYpl9fTuGyOZ+ZwJV4CYixsH90M M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAJhKbVKtJXG8/2dsb2JhbABZgwc4VL5fgRwWdIIlAQEBBAEBAWsLDAYBCBEDAQEBAQodKAYLFAkIAgQBDQUIARKHWgMPDa1+DYlrjGWCPQIxBwaDGYENA5QqgXWDGoshhTeDJoIq X-IronPort-AV: E=Sophos;i="4.93,580,1378857600"; d="scan'208";a="277037336" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 27 Oct 2013 17:20:47 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9RHKltI016503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Oct 2013 17:20:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Sun, 27 Oct 2013 12:20:47 -0500 From: "Zafar Ali (zali)" To: Francesco Fondelli , "BRUNGARD, DEBORAH A" , "lberger@labn.net" Thread-Topic: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps Thread-Index: AQHOLvS39bpyTqTPkUSHnkgWwL1MfZjB/SCAgAD/8wCAAhH+gIABbhGAgAB4gYCADCJzAIE3DIAA Date: Sun, 27 Oct 2013 17:20:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.235.102] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <6261AA644D5C2448A4F79813B1F41DB7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 17:20:54 -0000 Hi Deb:=20 We have removed SNC changes from this draft (see draft-takacs-ccamp-revertive-ps-09.txt). Hi Lou, Deb and the WG: This thread addresses and closes on the comment on why we did not use OAM configuration framework in this draft. We have also again highlighted the requirements and why we used protection object based solution. We now believe that we can move this document for WG adaptation. Please advise of any further comments. Thanks Regards ... Zafar -----Original Message----- From: zali Date: Friday, April 12, 2013 3:19 PM To: Francesco Fondelli , "BRUNGARD, DEBORAH A" Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps >Hi Deborah/ Francesco: > >I don't want SNC changes to become a stopper for this draft. I will be ok >to take them out.=20 > >Thanks > >Regards =A9 Zafar > > >-----Original Message----- >From: Francesco Fondelli >Date: Thursday, April 4, 2013 6:00 PM >To: "BRUNGARD, DEBORAH A" >Cc: "ccamp@ietf.org" >Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps > >>On Thu, Apr 4, 2013 at 4:49 PM, BRUNGARD, DEBORAH A >>wrote: >>> Hi Francesco, >> >>Hi Deborah, >> >>> That was a fast analysis:-) >>> >>> Suggest you first expand on the requirements that you want to support >>>vs. solution. When you detail aspects of SNC/N, SNC/I, and SNC/S, you >>>will find that you also need OAM configuration to support (N/I/S >>>configuration (e.g. DEG, TTI)) and you will need to configure which >>>defects contribute to a "failure". This will all need to be coordinated >>>with the LSP OAM configuration. >> >> SNC sub-type has been introduced only recently in [4] and is a >>Zafar Ali's contribution; I think he can expand/elaborate this >>topic here on the list or in the next draft version. In my emails >>I was referring exclusively to hold off and wtr ([4] is about hold off >>and wtr since day zero: July, 2008), sorry if this was not clear. >> >>> Also on SNC/N, SNC/I, and SNC/S, is this for a segment or e-2-e? The >>>draft needs more detail and alignment with GMPLS protection terminology >>>and mechanisms. >> >> I think [4] addresses both e2e and segment (note: I'm talking about >>hold off and wtr). >> >>> After having a better scope of the requirements, we can discuss the >>>solution tradeoffs. There are always multiple ways to solve, first we >>>need to understand what is needed. >> >> The requirement is straightforward: in order to set up protection >>switching you need hold off and wtr. Either you use default values >>for any LSP on a given network (which is what is happening today) or >>you signal these values (hoff and wtr) on a per LSP basis. The draft >>tries to provide support for the latter. >> >>> Thanks, >>> Deborah >> >>thank you >>Ciao >>Fra >> >>> -----Original Message----- >>> From: Francesco Fondelli [mailto:francesco.fondelli@gmail.com] >>> Sent: Wednesday, April 03, 2013 12:59 PM >>> To: BRUNGARD, DEBORAH A >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] clarification about >>>draft-takacs-ccamp-revertive-ps >>> >>> Hi Deborah, all, >>> >>>> Having said that, I have no problem rewriting [4] using OAM >>>> configuration TLV. It's just weird to me but I can live with it. >>> >>> sorry, I changed my mind, I cannot use the OAM TLV. The more I read >>> about OAM in IETF the more I think protection switching provisioning >>> is completely out-of-scope. >>> >>> I spent some hours looking for the OAM definition within the >>> IETF context(s). The most recent and enlightening (to me at least) >>> documents I found are [A] and [B]. As far as I understand, [1] is >>> perfectly aligned with them. At the same time I cannot find any >>> support of your statement: >>> >>>> Protection switching provisioning has always been treated as a >>>> common equipment management functionality [cut]. So it is in scope >>>> of OAM configuration. >>> >>> Maybe I'm just missing something big (?) Can someone shed some light >>>on >>> this? >>> >>> thank you >>> ciao >>> fra >>> >>> [A] >>> http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08 >>> >>> [B] >>> http://tools.ietf.org/html/rfc6291 >>> >>> On Tue, Apr 2, 2013 at 11:22 AM, Francesco Fondelli >>> wrote: >>>> On Mon, Apr 1, 2013 at 8:06 PM, BRUNGARD, DEBORAH A >>>>wrote: >>>>> Hi Francesco, >>>> >>>> Hi Deborah, >>>> >>>>> While these may be protection switching parameters, this draft is >>>>>about configuration of these parameters. Protection switching >>>>>provisioning has always been treated as a common equipment management >>>>>functionality - same as performance management and fault management >>>>>(refer to G.7710 section 8). So it is in scope of OAM configuration. >>>>>CCAMP's OAM configuration work has been focused on PM and FM but it is >>>>>generally applicable (hopefully) to any equipment management >>>>>configuration. >>>> >>>> Puzzled. If we follow this reasoning (i.e. common equipment >>>>management >>>> functionalities =3D> should use OAM framework) then almost any aspect = of >>>> networking can be applicable to OAM and so any operation should >>>>exploit >>>> the OAM framework draft. >>>> >>>> For example, G.7710 section 8.6.1 describes the provisioning >>>> of cross-connections but this does not imply that we are going to use >>>>the >>>> OAM framework to establish label binding in the next GMPLS controlled >>>> technology, I guess we will continue to use LABEL_REQUEST/LABEL >>>>objects >>>> (plus any other relevant info). >>>> >>>>> Lou's comment is that the WG has chosen the approach used in the OAM >>>>>framework document for configuration. Instead of updating the >>>>>protection object at this time as your draft proposes, the question is >>>>>have you considered using the OAM configuration TLV? First, we need to >>>>>understand why you have chosen to not use this approach. Then we can >>>>>discuss pros and cons. >>>> >>>> Well, at the beginning we did not take it into consideration >>>> because [4] predate [1]. Later we did not take [1] into consideration >>>> simply because we thought [4] was out of OAM framework scope. >>>> >>>> Having said that, I have no problem rewriting [4] using OAM >>>> configuration TLV. It's just weird to me but I can live with it. >>>> >>>>> BR- >>>>> Deborah >>>> >>>> thank you >>>> ciao >>>> fra >>>> >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>Behalf Of Francesco Fondelli >>>>> Sent: Monday, April 01, 2013 12:20 PM >>>>> To: ccamp@ietf.org >>>>> Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps >>>>> >>>>> quoting item 15, from >>>>>www.ietf.org/proceedings/86/minutes/minutes-86-ccamp >>>>> >>>>> Lou Berger: I think you misunderstood my comment from the last >>>>>meeting. You >>>>> should look at leveraging the OAM configuration work which came after >>>>>the >>>>> earlier versions of your draft. >>>>> Zafar Ali: this is applicable to multiple technologies. >>>>> Lou Berger: yes, the OAM configuration framework is also applicable >>>>>to >>>>> multiple technologies. You need a strong reason not to follow the WG >>>>>in >>>>> this area. Please look at the OAM configuration document >>>>> [draft-ietf-ccamp-oam-configuration-fwk] and either follow it or >>>>>state why >>>>> your work is justified in not following the existing WG solution in >>>>>this >>>>> area. >>>>> >>>>> --- >>>>> >>>>> Hi all, >>>>> >>>>> the OAM configuration framework [1] is about OAM. Therefore, it is >>>>>used in >>>>> order to signal OAM functionalities: CC/CV and PM/FM in MPLS-TP [2], >>>>>CC/CV >>>>> TTI/SAPI/DAPI in SONET/SDH/OTN [3]... while our draft [4] is about >>>>>*protection >>>>> switching*. HOFF, WTR and SNC sub-type are protection switching >>>>>parameters. >>>>> >>>>> I believe HOFF, WTR and SNC sub-type are outside of the OAM >>>>>configuration >>>>> framework scope and should be signaled as any other protection >>>>>switching >>>>> params (i.e. via PROTECTION object). >>>>> >>>>> I hope this answer Lou question reported above (item 15, IETF 86 >>>>>ccamp >>>>> minutes). Authors of [4] would like to understand WG's view about >>>>>this point >>>>> and are soliciting for comments. >>>>> >>>>> thank you >>>>> ciao >>>>> FF >>>>> >>>>> [1] >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09 >>>>> >>>>> [2] >>>>>=20 >>>>>http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11 >>>>> >>>>> [3] >>>>>=20 >>>>>http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05 >>>>> >>>>> [4] >>>>> http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08 >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>_______________________________________________ >>CCAMP mailing list >>CCAMP@ietf.org >>https://www.ietf.org/mailman/listinfo/ccamp > From jie.dong@huawei.com Sun Oct 27 18:27:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853EB11E82E7 for ; Sun, 27 Oct 2013 18:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUXVQsho5Oql for ; Sun, 27 Oct 2013 18:27:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0937511E82E4 for ; Sun, 27 Oct 2013 18:27:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZN83546; Mon, 28 Oct 2013 01:27:34 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 01:27:20 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 01:27:33 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.74]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 28 Oct 2013 09:27:27 +0800 From: "Dongjie (Jimmy)" To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-02.txt Thread-Index: AQHOzinSTEwqt2I650aUkdMTMASLA5oJW0Ag Date: Mon, 28 Oct 2013 01:27:27 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273353440B@nkgeml512-mbx.china.huawei.com> References: <20131021064725.8699.48125.idtracker@ietfa.amsl.com> In-Reply-To: <20131021064725.8699.48125.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.167.240] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 01:27:44 -0000 Dear all,=20 A new version of draft-ietf-ccamp-rsvp-te-li-lb has been submitted. The upd= ates since this draft become WG document are: 1. Expand the Acronyms when first time appear 2. Update document references in section 3 3. Revise the IANA section to make the allocation of new error values clear For the next step, since the draft is getting stable, the authors think may= be it is ready for WG last call.=20 Comments are always welcome. Many thanks, Jie -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, October 21, 2013 2:47 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : GMPLS RSVP-TE Extensions for Lock Instruct and Loopback Author(s) : Jie Dong Mach(Guoyi) Chen Zhenqiang Li Daniele Ceccarelli Filename : draft-ietf-ccamp-rsvp-te-li-lb-02.txt Pages : 8 Date : 2013-10-20 Abstract: This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanism for Label Switched Paths (LSPs). The mechanisms are applicable to technologies which use Generalized Multi-Protocol Label Switching (GMPLS) as control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-li-lb There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-li-lb-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rsvp-te-li-lb-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From acee.lindem@ericsson.com Mon Oct 28 09:01:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [CCAMP] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 leeyoung@huawei.com Mon Oct 28 13:44:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF66421E80D0 for ; Mon, 28 Oct 2013 13:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMatcoNaYT72 for ; Mon, 28 Oct 2013 13:44:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34F6211E828D for ; Mon, 28 Oct 2013 13:44:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXH69312; Mon, 28 Oct 2013 20:44:14 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 20:43:53 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 20:44:10 +0000 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Mon, 28 Oct 2013 13:44:06 -0700 From: Leeyoung To: "Margaria, Cyril (Coriant - DE/Munich)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling Thread-Index: Ac7PFPsDhmt/uF1bTWymUSOtwlOYqwE+7vGg Date: Mon, 28 Oct 2013 20:44:05 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17291DCC3F@dfweml511-mbs.china.huawei.com> References: <523C37072C291347B9730C9291CCA07D02DE3549@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: <523C37072C291347B9730C9291CCA07D02DE3549@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.126] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 20:44:34 -0000 Hi Cyril Thanks for this comprehensive review of all WSON documents.=20 I have resolved all the issues you raised except the signaling draft (Hopef= ully, Giovanni can answer your comment for the signaling draft). Please see inline for my comment. Thanks. Regards, Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of M= argaria, Cyril (Coriant - DE/Munich) Sent: Tuesday, October 22, 2013 5:54 AM To: CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-const= raint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-sign= al-compatibility-ospf, wson-signaling http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 I've reviewed this document and believe it is ready for publication, with c= omments: I think the document is good to go, I have two editorial comments: - I find the document history good to have, but maybe in an annex. - My stable mail address is cyril.margaria@gmail.com , affiliation is Cori= ant. **YOUNG>> History will normally be removed by RFC Editors as it is close to= the final version. Will correct your affiliation.=20 http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 I've reviewed this document and believe it is ready for publication, with c= omment: I have the same comment as the rwa info regarding the history to be maybe m= oved to the annex=20 **YOUNG>> Same comment for history as above. http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 I've reviewed this document and believe it is ready for publication, with c= omments: - editorial: The document history could be moved to the annex=20 - section 3.3 : rbState (16 bit) : nits : is it signed or unsigned integer = ? I would tend to understand unsigned. - My stable mail address is cyril.margaria@gmail.com , affiliation is Coria= nt, not NSN **YOUNG>> Added RB State (16 bit unsigned integer). Will correct your affil= iation.=20 http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-= te-05 I've reviewed this document and believe it is ready for publication http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-= 12 I've reviewed this document and believe it is ready for publication, with c= omments: - editorial: The document history could be moved to the annex=20 - Section 2 : the section reference to WSON-Encode are wrong (this affect s= ection 2, section 2.1 - Section 3 : it would be useful to reference the exact section of [Gen-enc= ode] for the Available Label Sub-TLV and Shared Backup Label Sub-TLV.=20 YOUNG>> Agreed. Corrected all. Section 2.3 and 2.4 are referenced in Sectio= n 3.=20 http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06=20 I've reviewed this document and I have the following comments: - section 4.3 : "If more than two objects are encountered, two MUST be processed and the rest SHOULD be ignored." This is ambiguous : the section refers to the RB information sub tlv, does= this refers to the WSON_signaling object or RBInformation? - section 4.3 : http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52, please= remove this paragraph, the restriction is strong and would not allow a nod= e to choose one RB per local policy /sharing.. etc - section 7 : the section assume a LSP_REQUIRED_ATTRIBUTE, but this is a t= argeted information as described in section 4.2, or should it be distinguis= hed between targeted attribute (to be assigned in the ERO HOP_attribut, thi= s depends on the space choosen by the draft-ietf-ccamp-lsp-attribute-ro) an= d e2e attribute (WA)?. =20 Best Regards/ Mit freundlichen Gr=FC=DFen Cyril Margaria cyril.margaria@gmail.com http://www.coriant.com Coriant R&D GmbH Gesch=E4ftsleitung / Board of Directors: Robert Richter, Rolf Nauerz=20 Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRB 197143 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From giomarti@cisco.com Tue Oct 29 03:29:05 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D5021E8122 for ; Tue, 29 Oct 2013 03:29:05 -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 gVNxCctSvArp for ; Tue, 29 Oct 2013 03:29:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 52E5711E813B for ; Tue, 29 Oct 2013 03:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1860; q=dns/txt; s=iport; t=1383042539; x=1384252139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=29qQRgdSQyR6WQi6Vc3h7PMK3jXVrMMMyJnQA6dX6XE=; b=D/+S/W3NBQE2nmYE0QIfbgUibpF3wxzCzpE27QIU662LcHIm0vhY2TwJ LhgctiFAKHEdeT2alIUK7b2jYwEsySYQt0ATVupZidqvH9jCx1HuPbe8T zkoLmC/5QmKkwxeeUQj2RHsBJrDGmbHUkpKDH/ByCUspg2udq139O6LCD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAA2Nb1KtJXG+/2dsb2JhbABZgwc4VL8xgSgWdIImAQEEeQULAgEIIhkLMiUCBA4FCId/Dbkbjhh8AjEHgx+BDQOJB5AyiSKHN4FogT6CKg X-IronPort-AV: E=Sophos;i="4.93,592,1378857600"; d="scan'208";a="277916200" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 29 Oct 2013 10:28:58 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9TASw3H020276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 10:28:58 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 05:28:58 -0500 From: "Giovanni Martinelli (giomarti)" To: "Margaria, Cyril (Coriant - DE/Munich)" Thread-Topic: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling Thread-Index: AQHO1JGsVmCoWaWmGEW5JbuHqIKecQ== Date: Tue, 29 Oct 2013 10:28:57 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D0EE58754@xmb-rcd-x14.cisco.com> References: <523C37072C291347B9730C9291CCA07D02DE3549@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: <523C37072C291347B9730C9291CCA07D02DE3549@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.166.93] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "CCAMP \(ccamp@ietf.org\)" Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 10:29:06 -0000 Hi Cyril, pls see inline=20 On Oct 22, 2013, at 12:53 , "Margaria, Cyril (Coriant - DE/Munich)" wrote: > http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06=20 > I've reviewed this document and I have the following comments: > - section 4.3 : "If more than two objects are encountered, > two MUST be processed and the rest SHOULD be ignored." > This is ambiguous : the section refers to the RB information sub tlv, do= es this refers to the WSON_signaling object or RBInformation? GM> it refer ti RB information does this change is acceptable to you old: " If more than two objects are encountered, two MUST be processed and the rest SHOULD be ignored." new: "If more than two RB Information objects are encountered, two MUST be processed and the rest SHOULD be ignored." > - section 4.3 : http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52, pleas= e remove this paragraph, the restriction is strong and would not allow a no= de to choose one RB per local policy /sharing.. etc GM> Current change you propose is to remove this sentence "RB Set Field MAY contain more than one RB Indetifier. Only the first one MUST be processed, the others SHOULD be ignored. " I'm ok I'd like to know if anyone else have concern in remving. Simply we b= ecome liberal in in using the RB Identifiers in signaling.=20 > - section 7 : the section assume a LSP_REQUIRED_ATTRIBUTE, but this is a = targeted information as described in section 4.2, or should it be distingui= shed between targeted attribute (to be assigned in the ERO HOP_attribut, th= is depends on the space choosen by the draft-ietf-ccamp-lsp-attribute-ro) a= nd e2e attribute (WA)?. GM> Sounds to me this draft follow the draft-ietf-ccamp-lsp-attribute-ro as= it was one of the use case.=20 Cheers G From giomarti@cisco.com Tue Oct 29 03:38:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4535B21E8145 for ; Tue, 29 Oct 2013 03:38:47 -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 9IJZLv1Pwm5g for ; Tue, 29 Oct 2013 03:38:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4DF21E811D for ; Tue, 29 Oct 2013 03:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=429; q=dns/txt; s=iport; t=1383043109; x=1384252709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RjInMaJahZjAk/x3Y5/7K8JaiBE/1Jmr3i3N9tc5PP4=; b=lRatoHa8XVx/yU99phZNGZ6KzHf5ZtghoI4p0Vgn9DXQCKyLSAvNPQpi /9LwbDWz71gaFhgDA3sb9HV4SjsQvkfdftXrLtdmiLiXdbprRJxuUvFPf BZEHnFdxqZpHv7Y2c1+4e0ho3QX420vM5hNHbT6IbtyGjZjyFpgygTi9f A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAB+Pb1KtJXG//2dsb2JhbABZgwc4VL8xgSgWdIImAQEEOj8QAgEIDhQUBQsyJQIEDgUIh38NuR2PFAIxB4MfgQ0DmTmJIoc3gWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,592,1378857600"; d="scan'208";a="277933920" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 29 Oct 2013 10:38:29 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9TAcRPr008334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 10:38:28 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 05:38:28 -0500 From: "Giovanni Martinelli (giomarti)" To: Lou Berger Thread-Topic: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling Thread-Index: AQHO1JMAVmCoWaWmGEW5JbuHqIKecQ== Date: Tue, 29 Oct 2013 10:38:27 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D0EE587D6@xmb-rcd-x14.cisco.com> References: <524AF9A9.3040006@labn.net> In-Reply-To: <524AF9A9.3040006@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.166.93] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 10:38:47 -0000 Hi all, On Oct 1, 2013, at 18:34 , Lou Berger wrote: >=20 > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 > (Standards Track) We propose an encoding of ITU application codes on 64 bits of Optical Inter= face Class (Section 4.2), just wandering if we already had any ITU/Q6 feedb= ack or we are just ok with proposed encoding. I'm ok with the rest of LC documents Cheers G From acee.lindem@ericsson.com Tue Oct 29 08:13:18 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4B211E82B4 for ; Tue, 29 Oct 2013 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 96Aqp14G8jEZ for ; Tue, 29 Oct 2013 08:13:12 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C28DA21F9991 for ; Tue, 29 Oct 2013 08:13:12 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-47-526fd087dd84 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 64.CA.09414.780DF625; Tue, 29 Oct 2013 16:13:12 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 11:13:11 -0400 From: Acee Lindem To: CCAMP Thread-Topic: WG Last Call Comments on OSPF-TE Extensions for General Network Element Constraints Thread-Index: AQHO1LlhsbBiddDvmE6EoCMAdBaEaA== Date: Tue, 29 Oct 2013 15:13:10 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030AFEAB@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: text/plain; charset="us-ascii" Content-ID: <49D62B8D4562BE47BDDF1A84D105A55F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyuXRPgm7Hhfwgg0sHRCyezLnB4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKmH2hgL+hwrHnXMYWtgXGDcxcjJISFgIvHnxwsWCFtM4sK9 9WxdjFwcQgJHGCX29k9nh3CWM0rM2rETrIpNQEfi+aN/zCC2iICUxM19t4CKODiEBeIlPq7K gwinSMw/3ccEYetJPPg3hRHEZhFQlThy7isriM0r4CvxatYKMJsRaPH3U2vA6pkFxCVuPZnP BHGQgMSSPeeZIWxRiZeP/7FC2MoSS57sZ4Go15FYsPsTG4RtLXF230ZGCFtbYtnC18wQuwQl Ts58wjKBUWQWkhWzkLTPQtI+C0n7LCTtCxhZVzFylBanluWmGxlsYgQG/jEJNt0djHteWh5i lOZgURLn/fLWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY5HndB3+puUP/Nd+ln7wQCY+ QE9fK/doM/Oxf3HLv0wN3PtptoWG/KbHX3z3BDAJlq5Ru+hsueFfn/7d9oSl9nJ7emc3fb/H oyO1ICi3fmf9NjUepg9l56awPuTR+clhbyF6pn5qxlIx98+qj6YYOU8Ld5C4kPUg1rJy4s7u jZI/1zqL+xe2KLEUZyQaajEXFScCADWO3FFKAgAA Subject: [CCAMP] WG Last Call Comments on OSPF-TE Extensions for General Network Element Constraints X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 15:13:18 -0000 I have the following comments on the subject drafts: 1. State explicitly why the general constraint encoding is broken of= f into a separate drafts. At first, it seems the decision is arbitrary but = I guess it is to allow the same encoding to apply to OSPF, ISIS, and PCEP.= =20 2. Section 5.1 - If one includes the Port Label Restrictions sub-TLV= in a separate LSA, that LSA must also include the sub-TLVs necessary to id= entify the link unambiguously. To handle unnumbered links, I believe you'd = need the Link-ID, Local Interface IP Address, and Remote Interface IP Addre= ss sub-TLVs.=20 3. Section 3.1 - Since the Port Label Restrictions sub-TLV is define= d as a sub-TLV of the Link TLV, how is it used to define constraints for a = specific connectivity matrix?=20 3. State the action to take if the new sub-TLVs or their attendant e= ncodings are malformed. You should log the problem and ignore the entire LS= A, subsuming TLV, or just the sub-TLV in GMPLS path computations.=20 4. Section 7 - Explicitly state which are IANA registries are being = extended. Since you are adding a new TLV, you will also need a new registry= for the sub-TLVs. See http://www.iana.org/assignments/ospf-traffic-eng-tlv= s/ospf-traffic-eng-tlvs.xhtml#top-level for examples. =20 =20 Editorial: Section 3.1 - What does the sentence "More dynamic information is co= ntained in the information on available labels." mean?=20 Also some suggested edits for readability. These are optional and my apolog= ies if I changed the meaning of any text.=20 Acee-Lindems-iMac-3:Desktop ealflin$ diff draft-ietf-ccamp-gmpls-general-co= nstraints-ospf-te-05.txt.orig draft-ietf-ccamp-gmpls-general-constraints-os= pf-te-05.txt 77c77 < fiber). In some of these technologies network elements and links may --- > fiber). In some of these technologies, network elements and links may 123,124c123,124 < Some data plane technologies that wish to make use of a GMPLS < control plane contain additional constraints on switching capability --- > Some data plane technologies require the use of a GMPLS control > plane which imposes additional constraints on switching capability 141c141 < TE links can be announced in OSPF TE LSAs. The TE LSA, which is an --- > TE links can be advertised in OSPF TE LSAs. The TE LSA, which is an 157,158c157,158 < representing node switching asymmetry constraints includes Node ID, < connectivity matrix. Except for the Node ID which should comply with --- > representing node switching asymmetry constraints includes Node ID > and connectivity matrix. Except for the Node ID, which should comply 167c167 < Routing Address described in [RFC3630], the other pieces of --- > with Routing Address described in [RFC3630], the other pieces of 172c172 < This Generic Node Attribute TLV contains one or more sub-TLVs --- > This Generic Node Attribute TLV contains one or more sub-TLVs. 174,175c174,175 < Per [GEN-Encode], we have identified the following new Sub-TLVs to < the Generic Node Attribute TLV. Detail description for each newly --- > Per [GEN-Encode], we have identified the following new sub-TLVs to > the Generic Node Attribute TLV. Detailed description for each newly 182c182 < In some specific technologies, e.g., WSON networks, Connectivity --- > In some specific technologies, e.g., WSON networks, the Connectivity 184,188c184,188 < implementations. Usually, for example, in WSON networks, < Connectivity Matrix sub-TLV may appear in the LSAs because WSON < switches are asymmetric at present. It is assumed that the switches < are symmetric switching, if there is no Connectivity Matrix sub-TLV < in the LSAs. --- > implementations. Usually, for example, in WSON networks, the > Connectivity Matrix sub-TLV may be advertised in TE LSAs since WSON > switches are currently asymmetric. If no Connectivity Matrix sub-TLV > is included, It is assumed that the switches support symmetric > switching.=20 192,194c192,194 < It is necessary to identify which ingress ports and labels can be < switched to some specific labels on a specific egress port, if the < switching devices in some technology are highly asymmetric. --- > If the switching devices in a GMPLS technology are asymmetric,=20 > it is necessary to identify which ingress ports and labels can be > switched to some specific labels on a specific egress port. 198c198 < asymmetric switches (e.g. ROADMs and such) or fixed connectivity for --- > asymmetric switches (e.g., ROADMs and such) or fixed connectivity for 207,209c207,209 < multi-matrices within the Generic Node Attribute TLV. In addition a < large connectivity matrix can be decomposed into smaller separate < matrices for transmission in multiple LSAs as described in Section 5. --- > multiple matrices within the Generic Node Attribute TLV. In addition > a large connectivity matrix can be decomposed into smaller > sub-matrices for transmission in multiple LSAs as described in Section= 5. 223c223 < The most common link sub-TLVs nested to link top-level TLV are --- > The most common link sub-TLVs nested in top-level Link TLVs are 238,239c238,240 < control plane implementations. If it is default no restrictions on < labels, Port Label Restrictions sub-TLV may not appear in the LSAs. --- > control plane implementations. The Port Label Restrictions sub-TLV=20 > will not be advertised when there are no restrictions on label=20 > assignment. 247,249c248,250 < is contained in the information on available labels. Port label < restrictions are specified relative to the port in general or to a < specific connectivity matrix for increased modeling flexibility. --- > is contained in the information on available labels. For increased > modeling flexibility, port label restrictions may be specified=20 > relative to a port in general or to a specific connectivity matrix. 251c252 < For example, Port Label Restrictions describes the wavelength --- > For example, the Port Label Restrictions describes the wavelength 258,263c259,264 < The Port Label Restrictions is a sub-TLV (the type is TBD by IANA) < of the Link TLV. The length is the length of value field in octets. < The meaning and format of this sub-TLV are defined in Section 5.4 of < [GEN-Encode]. The Port Label Restrictions sub-TLV may occur more < than once to specify a complex port constraint within the link TLV. <=20 --- > The Port Label Restrictions sub-TLV is a sub-TLV (the type is TBD > by IANA) of the Link TLV. The length is the length of value field > in octets. The meaning and format of this sub-TLV are defined in=20 > Section 5.4 of [GEN-Encode]. The Port Label Restrictions sub-TLV=20 > may occur more than once to specify a complex port constraint within > the link TLV. 277c278 < All the sub-TLVs are nested to top-level TLV(s) and contained in --- > All the sub-TLVs are nested in top-level TLV(s) and contained in 285c286 < is changed. A standard-compliant approach is to separate the dynamic --- > is changed. A standards-compliant approach is to separate the dynamic 287,288c288,289 < nested to top-level TLV ([RFC3630 and RFC5876]), and advertise them < in the separate OSPF TE LSAs. --- > nested in a separate top-level TLV ([RFC3630 and RFC5876]), and=20 > advertise them in the separate OSPF TE LSAs. 297,298c298,299 < information sub-TLV could be nested to the top level link TLVs and < advertised in the separate LSAs. --- > information sub-TLV could be nested in separate top-level Link=20 > TLVs and advertised in the separate LSAs. 306,307c307,308 < specific time. Such mechanisms MUST be configurable if they are < implemented. --- > specific time interval. Such mechanisms MUST be configurable if > they are implemented. 317c318 < splitting of general constraint LSAs into smaller LSA that are under --- > splitting of general constraint LSAs into smaller LSAs that are under Thanks, Acee=20 = From daniele.ceccarelli@ericsson.com Tue Oct 29 09:48:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [CCAMP] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 lberger@labn.net Tue Oct 29 11:26:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8821A11E824C for ; Tue, 29 Oct 2013 11:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.681 X-Spam-Level: X-Spam-Status: No, score=-100.681 tagged_above=-999 required=5 tests=[AWL=-1.328, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SUSPICIOUS_RECIPS=2.912, 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 f+Lt4fnI9wvd for ; Tue, 29 Oct 2013 11:26:00 -0700 (PDT) Received: from outbound-ss-1235.hostmonster.com (outbound-ss-1235.hostmonster.com [67.20.99.188]) by ietfa.amsl.com (Postfix) with SMTP id 5433411E8228 for ; Tue, 29 Oct 2013 11:26:00 -0700 (PDT) Received: (qmail 10786 invoked by uid 0); 29 Oct 2013 18:25:35 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 29 Oct 2013 18:25:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=4CGUYXmgi/NhVkX/X6p0hzS4ypxQbxABSwDl5Z2SsUM=; b=jZsfENdaCa+12x/sbahhIxBNYlpCRGnI+i0BwAAxzmwsRklm//psyuwb7gueBfUM7Kd/FeuTtdNgOkYVRpBtstVJT0YGuecL9sexgF0tVApmou7l9ykhaJf/FRO17UeX; Received: from box313.bluehost.com ([69.89.31.113]:52534 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbDyx-0004xE-K9; Tue, 29 Oct 2013 12:25:35 -0600 Message-ID: <526FFD97.605@labn.net> Date: Tue, 29 Oct 2013 14:25:27 -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: CCAMP , draft-ietf-ccamp-rwa-info@tools.ietf.org, draft-ietf-ccamp-general-constraint-encode@tools.ietf.org, "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" , "draft-ietf-ccamp-gmpls-general-constraints-ospf-te@tools.ietf.org" , draft-ietf-ccamp-wson-signal-compatibility-ospf@tools.ietf.org, "draft-ietf-ccamp-wson-signaling@tools.ietf.org" References: <524AF9A9.3040006@labn.net> In-Reply-To: <524AF9A9.3040006@labn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:26:04 -0000 Authors, I have some general comments on these documents as a set, i.e., that apply to all documents. I also have document specific comments that I'll send separately. Note that I'm the document shepherd, see RFC 4858 for more information. General comments: - Broken cross references: The documents have a lot of pointers to each other, many of which are broken and need to be fixed. For example (and NOT the only one!) the signaling document has: is defined in Section 4.1 of [WSON-Encode]. 1. While the section reference is correct (but check others as this isn't always the case), there is no defined in the document. The problem here is inconsistent usage of BNF and expanded style names. I think it's fine to use both, e.g., and Resource Block Information, but there needs to be consistent cross referencing and definitions. This problem also exists within drafts too. 2. As above, please verify cross referenced section numbers - It looks like there are still some vestigial references to "ingress" and "egress" (noted as replaced by "input" and "output"). This also shows in abbreviations where 'E' is used rather than 'O'. - In a number of documents s/GPID/G-PID - Revision history should be removed at this point. - Please ensure abbreviations are expanded on first use. See http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt for additional guidance. - Your terminology sections include terms that are only used in this section. This does not make sense. The terminology section also duplicates what is already in RFC6163. I suggest eliminating such sections and adding references to RFC6163 if/where needed. - Please double check that there are no idnits - Please update any references that are now RFCs, e.g., RBNF - A general discussion on security in GMPLS networks can be found in RFC5920. I suggest adding an informative reference in your security sections. Thanks, Lou On 10/1/2013 12:34 PM, Lou Berger wrote: > All, > > This mail begins working group last call on the WSON documents. As > there are 6 documents in this set, the last call will be three weeks. > The documents included in the last call are: > > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 > (Informational, IPR Disclosed) > > http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 > (Standards Track, IPR Disclosed) > > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 > (Standards Track) > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 > (Standards Track, IPR Disclosed) > > http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 > (Standards Track, IPR Disclosed) > > http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards > Track) Also has one open issue that will need to be resolved as part of > LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. > > This working group last call ends on October 22. Comments should be > sent to the CCAMP mailing list. Please remember to include the > technical basis for any comments. > > Positive comments, e.g., "I've reviewed this document and believe it is > ready for publication", are welcome! > > Please note that we're still missing some IPR statements. Any > forthcoming publication request will be delayed by late IPR > statements/disclosures. > > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Tue Oct 29 11:26:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B8511E8228 for ; Tue, 29 Oct 2013 11:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 fMVcscSRWve9 for ; Tue, 29 Oct 2013 11:26:45 -0700 (PDT) Received: from oproxy12-pub.mail.unifiedlayer.com (oproxy12-pub.mail.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 8353A11E822E for ; Tue, 29 Oct 2013 11:26:41 -0700 (PDT) Received: (qmail 14145 invoked by uid 0); 29 Oct 2013 18:26:11 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.mail.unifiedlayer.com with SMTP; 29 Oct 2013 18:26: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:To:MIME-Version:From:Date:Message-ID; bh=e0JxwmAV2iKK7KY72C9Fzp1U5HMi/6J+4JqmrCMmqnQ=; b=wpexlzi/4SzoBcIuRIW94sKFy98dZWtFgpBTcuGu1tYnKkBidkn4/C+IyLoyPvv9eq75HZeE9CDudnUCQXKMBUeho+ZMdICdc/dB1kjqmH1S3g29N5hM6mqnTtq081m9; Received: from box313.bluehost.com ([69.89.31.113]:52645 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbDzX-00059f-HK; Tue, 29 Oct 2013 12:26:11 -0600 Message-ID: <526FFDBB.4020504@labn.net> Date: Tue, 29 Oct 2013 14:26:03 -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: CCAMP , draft-ietf-ccamp-rwa-info@tools.ietf.org References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> In-Reply-To: <5266E138.8080605@labn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:26:51 -0000 Authors, I have some comments on draft-ietf-ccamp-rwa-info. Most are strictly editorial. Note that I'm the document shepherd, see RFC 4858 for more information. - Please address my general comments on the WSON document set - You say: " relatively static on the time scales of connection establishment." I suspect you mean: " relatively static and independent of connection establishment." - Your references to [Switch] seem almost normative in nature. I suspect that this is not your intent as it is listed as an informative reference. Please revisit your references and ensure that the draft does not depend on any informative references. (Either change the text, or move the reference to normative.) - s/inputinput/input - s/outputoutput/output - Section 4.1: " ... and path computation [Encode]." While a normative reference to [Encode] is certainly just fine, I reference is unclear in this context. - Why say "potentially switched" vs just "switched"? if "potentially" doesn't add anything please drop it, otherwise please clarify. - Section 4.2: SRNG I don't see SRNG in any other documents. Am I missing it, is SRNG used anywhere? - Section 5: I found it hard to parse the following: As resources are the smallest identifiable unit of processing resource, one can group together resources into blocks if they have similar characteristics relevant to the optical system being modeled, e.g., processing properties, accessibility, etc. Do you perhaps mean? A resource is the smallest identifiable unit of allocation. One can group together resources into blocks if they have similar characteristics relevant to the optical system being modeled, e.g., processing properties, accessibility, etc. -Section 5.1: States: " Note that except for all the other components of are relatively static." But the related definitions are: ::= ... [...] [...] [] (section 5) ::= [] (section 7.2) What's the intent here? - Section 5.2: What is the asterisk "*" all about. - Section 5.3.3 says ::=[]... should be as defined in section 5.2? - Section 5.3.4 repeats section 5.2. replace: " as follows: ::= [] [] [] []" with "." - Section 6.5: I found the following language confused: This allows for the definition of one additional link metric value for traffic engineering separate from the IP link state routing protocols link metric. How about: This allows for the identification of a data channel link metric value for traffic engineering that is separate from the metric used for path cost computation of the control plane. - Section 6.6: Drop "(Wavelength)" from the title, this can be confused with the "WSON" indication in section headings - Section 6.6.: You just say (Wavelength) and leave it to the reader to infer the relationship between it and a label. I suggest you make the relationship explicit. - Section 6.6. I think you have a BNF problem here. The BNF says restriction parameters are always optional, but your text says that there are requirements based on . I think the BNF needs to be aligned with the text and reflect the requirements. - Section 7: You say " An example usage of this information in a WSON setting is given in [Shared]." References to URLs should be avoided (particularity when they aren't valid even at the time of publication, i.e., now). That's it on this one, Lou On 10/22/2013 4:34 PM, Lou Berger wrote: > > All, > Given the recent draft submission deadline and only one comment being > received to date, we'd like to extend the WG more time for review. > > These drafts represent significant work by the authors and WG, so please > review and let the WG know what you think (positive or negative)! > > Please have all comments in by October 29. > > Thank you, > Lou (and Deborah) > > On 10/1/2013 12:34 PM, Lou Berger wrote: >> All, >> >> This mail begins working group last call on the WSON documents. As >> there are 6 documents in this set, the last call will be three weeks. >> The documents included in the last call are: >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 >> (Informational, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 >> (Standards Track) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards >> Track) Also has one open issue that will need to be resolved as part of >> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. >> >> This working group last call ends on October 22. Comments should be >> sent to the CCAMP mailing list. Please remember to include the >> technical basis for any comments. >> >> Positive comments, e.g., "I've reviewed this document and believe it is >> ready for publication", are welcome! >> >> Please note that we're still missing some IPR statements. Any >> forthcoming publication request will be delayed by late IPR >> statements/disclosures. >> >> >> Thank you, >> Lou (and Deborah) >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Tue Oct 29 11:27:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EAB11E825D for ; Tue, 29 Oct 2013 11:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 KBHXIDTN+P74 for ; Tue, 29 Oct 2013 11:27:49 -0700 (PDT) Received: from outbound-ss-1226.bluehost.com (outbound-ss-1226.bluehost.com [74.220.217.6]) by ietfa.amsl.com (Postfix) with SMTP id 4422A21F9E3A for ; Tue, 29 Oct 2013 11:27:49 -0700 (PDT) Received: (qmail 4662 invoked by uid 0); 29 Oct 2013 18:27:26 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.mail.unifiedlayer.com with SMTP; 29 Oct 2013 18:27:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=A4e7EcenDGl+9RWwjhds5oa8YuLvyMptvui1V0W+ytE=; b=Chyd1fl474HDOcRudTx7BbAyCYpFKc0Bh17OZT+GTlV0kuR+wcG9kV7kJJZGbutZ+pt3jelL35dU1+w85diq8XPyyiQD+5QncsQvaCchjMF3s0TRUByN9M4KcwsAZx05; Received: from box313.bluehost.com ([69.89.31.113]:52898 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbE0k-0005WY-8b; Tue, 29 Oct 2013 12:27:26 -0600 Message-ID: <526FFE06.20207@labn.net> Date: Tue, 29 Oct 2013 14:27:18 -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: CCAMP , "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> In-Reply-To: <5266E138.8080605@labn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:27:54 -0000 Authors, I have some comments on this document. Many are strictly editorial. Note that I'm the document shepherd, see RFC 4858 for more information. - Please address my general comments on the WSON document set - section 1 This document makes use of the Label Set Field encoding of [Gen-Encode] and refers to it as a Wavelength Set Field. Why? Why not just refer to it as Label Set? Perhaps you mean that a Wavelength Set Field is a Label Set Field that MUST carry a label as defined in RFC6205? If so, this needs to be made explicit. (probably in a section other than the introduction.) - section2/3 section alignment with rwa-info It's probably a good idea to align naming and ordering wherever possible. - section 2 1st two paragraphs. Why does this section try to introduce concepts that are defined in 6163 and in [WSON-INFO]? Is something missing from those documents? If so, at least wson info should be fixed. If not, these paragraphs should be replaced with simple terminology/concept references. - Section 2, same comment WRT TLVs as made on general-constraint- encode: The text reads: This document defines the following sub-TLVs pertaining to resources within an optical node: All references to sub-TLVs should dropped, again see related comment in my may on general-constraint-encode. This doesn't hold for sub-sub-TLVs, and I'll get to this below. - Section 3.1 0 1 2 3 4 5 6 7 8 | Connectivity | Why is connectivity a byte here, but only a bit in section 2.1? Either it should be a bit here to, or section 2.1 should be a byte. Note, that this can be fixed in a compatible way by defining it here as: 0 1 2 3 4 5 6 7 8 | Reserved |C| - Section 4. The definitions of sub-sub-TLVs are a bit underspecified. Some specific questions to address: - Are there any sub-sub-TLV ordering requirements? - How are multiple sub-sub-TLVs of the same type to be handled? - What is the sub-sub-TLV header (TL format)? - Are there any alignment requirements? - What happens when a sub-sub-TLV is larger than 256 bytes? (There are already systems that advertise 192 wavelengths on a fiber and an application code takes 8 bytes, right? But of course this presents a problem when carried within an RSVP object too.) If you find you need more specifics, we can discuss / I can propose new text. Feel free to discuss the details on or off list (your choice.) - Section 4.1 Title and 1st sentence don't agree on the element's name. - Section 3.4, 4.1 - Bits I & E are defined here, but I & O are used in parallel ways in Section 3.2. For consistency it should be I & O everywhere (to match input and output). - Section 4.2.1 s/[ITU-G.695.1]/[ITU-G.695] - Section 4.2.2, 4.2.3 Why do you use bit names that are different than the ITU-T definitions for p and s (rather than D and F)? WRT Section 8: - [RFC3471] is an informative reference. - [Gen-Encode] needs to be normative, this document reuses its definitions. - I'm surprised [WSON-Info] is informative (and not normative). Do you think this is correct? That's it on this one, Lou On 10/22/2013 4:34 PM, Lou Berger wrote: > > All, > Given the recent draft submission deadline and only one comment being > received to date, we'd like to extend the WG more time for review. > > These drafts represent significant work by the authors and WG, so please > review and let the WG know what you think (positive or negative)! > > Please have all comments in by October 29. > > Thank you, > Lou (and Deborah) > > On 10/1/2013 12:34 PM, Lou Berger wrote: >> All, >> >> This mail begins working group last call on the WSON documents. As >> there are 6 documents in this set, the last call will be three weeks. >> The documents included in the last call are: >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 >> (Informational, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 >> (Standards Track) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards >> Track) Also has one open issue that will need to be resolved as part of >> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. >> >> This working group last call ends on October 22. Comments should be >> sent to the CCAMP mailing list. Please remember to include the >> technical basis for any comments. >> >> Positive comments, e.g., "I've reviewed this document and believe it is >> ready for publication", are welcome! >> >> Please note that we're still missing some IPR statements. Any >> forthcoming publication request will be delayed by late IPR >> statements/disclosures. >> >> >> Thank you, >> Lou (and Deborah) >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Tue Oct 29 11:28:18 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADF111E8256 for ; Tue, 29 Oct 2013 11:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.117 X-Spam-Level: X-Spam-Status: No, score=-101.117 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, MANGLED_LIST=2.3, 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 n1ztVPLOselj for ; Tue, 29 Oct 2013 11:28:14 -0700 (PDT) Received: from oproxy19-pub.mail.unifiedlayer.com (oproxy19-pub.mail.unifiedlayer.com [70.40.200.33]) by ietfa.amsl.com (Postfix) with SMTP id 4A5EC11E8185 for ; Tue, 29 Oct 2013 11:28:14 -0700 (PDT) Received: (qmail 330 invoked by uid 0); 29 Oct 2013 18:28:13 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy19-pub.mail.unifiedlayer.com with SMTP; 29 Oct 2013 18:28:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=/TFVft1RKbw+FSSsK3f1hHGvKT9XHoxo8KFPVYPbxKc=; b=sudTA265IQvVv8cqAbEocdaw0i1B3Hf7XTGJI1ecgXi7JHipQH2eATox/BxkuqB8tv4UkHK2mF9etCK4IxsxhuljSnE9vBc/Rz9hKpzq1IqZ9clJ36J1AM0/LFGrEcvA; Received: from box313.bluehost.com ([69.89.31.113]:53102 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbE1V-0005s2-CE; Tue, 29 Oct 2013 12:28:13 -0600 Message-ID: <526FFE35.70404@labn.net> Date: Tue, 29 Oct 2013 14:28:05 -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: CCAMP , draft-ietf-ccamp-wson-signal-compatibility-ospf@tools.ietf.org References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> In-Reply-To: <5266E138.8080605@labn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-wson-signal-compatibility-ospf X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:28:18 -0000 Authors, I have some comments on this document. Many are strictly editorial. Note that I'm the document shepherd, see RFC 4858 for more information. - Please address my general comments on the WSON document set - In two places s/These routing enhancements are required/These routing enhancements are applicable - Do you want to reference draft-ietf-ccamp-gmpls-general-constraints-ospf-te? Perhaps in the intro. - Section 2, SUB-TLV ordering Looks like this ordering matches rwa-info, even though the encoding document doesn't. (Suggest the encoding document be fixed.) - Section 2 says: All sub-TLVs defined here may occur at most once in any given Optical Node TLV. "At most once" means that if there is sub-TLV related information, it should be always included. The second sentence reads to me to be closer to "at least once". "At most once" means no more than one time. Please clarify your intent. - Section 2.1: title s/Sub-TLV Details/Resource Block Information - Section 2.1, 1st paragraph Looks like this belongs at the end of the section 2 (intro) - Section 2.1, should be sub-sub-tlv, and there are 4 not 3 or 5 There are four nested sub-sub-TLVs defined in the Resource Block Information sub-TLV. Value Length sub-Sub-TLV Type also add lines for "Input Bit Rate List" - Sections 2.1.1->2.1.4 shouldn't these be sections 2.2 -> 2.5? - Section 2.1.3 Drop "16 bit" - Section 3: Don't you want to require the use of the RFC6205 defined label format for interfaces advertised with WSON-LSC? - Section 6: Acee's comment on IANA applies here too. (Should look at his other comments too and see if they apply to this document.) That's it on this one, Lou On 10/22/2013 4:34 PM, Lou Berger wrote: > > All, > Given the recent draft submission deadline and only one comment being > received to date, we'd like to extend the WG more time for review. > > These drafts represent significant work by the authors and WG, so please > review and let the WG know what you think (positive or negative)! > > Please have all comments in by October 29. > > Thank you, > Lou (and Deborah) > > On 10/1/2013 12:34 PM, Lou Berger wrote: >> All, >> >> This mail begins working group last call on the WSON documents. As >> there are 6 documents in this set, the last call will be three weeks. >> The documents included in the last call are: >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 >> (Informational, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 >> (Standards Track) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards >> Track) Also has one open issue that will need to be resolved as part of >> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. >> >> This working group last call ends on October 22. Comments should be >> sent to the CCAMP mailing list. Please remember to include the >> technical basis for any comments. >> >> Positive comments, e.g., "I've reviewed this document and believe it is >> ready for publication", are welcome! >> >> Please note that we're still missing some IPR statements. Any >> forthcoming publication request will be delayed by late IPR >> statements/disclosures. >> >> >> Thank you, >> Lou (and Deborah) >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Tue Oct 29 11:28:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5672621F9E3A for ; Tue, 29 Oct 2013 11:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.081 X-Spam-Level: X-Spam-Status: No, score=-101.081 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQMf+EfTSKrL for ; Tue, 29 Oct 2013 11:28:31 -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 CB20711E8228 for ; Tue, 29 Oct 2013 11:28:30 -0700 (PDT) Received: (qmail 16063 invoked by uid 0); 29 Oct 2013 18:28:09 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.mail.unifiedlayer.com with SMTP; 29 Oct 2013 18:28:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=yHVJQQsp/KAYIIHVJ+x7f+wXtVGzbbq1qTEezWf5Ihg=; b=up950oFKpZ/TkxyGrjxv0WIB9vpSqGDH74n7woL6wTsKY2jFefUnC8kqBeLBQgsW/gJsq08bHatB36d8DD4KITb2UWV2Grf04Jzael/XGPgYsDADsuv2h0FJ1wCo1AEO; Received: from box313.bluehost.com ([69.89.31.113]:53079 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbE1Q-0005qZ-VC; Tue, 29 Oct 2013 12:28:09 -0600 Message-ID: <526FFE31.40601@labn.net> Date: Tue, 29 Oct 2013 14:28:01 -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: CCAMP , "draft-ietf-ccamp-gmpls-general-constraints-ospf-te@tools.ietf.org" References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> In-Reply-To: <5266E138.8080605@labn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-gmpls-general-constraints-ospf-te X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:28:35 -0000 Authors, I have some comments on this document. Many are strictly editorial. Note that I'm the document shepherd, see RFC 4858 for more information. - Please address my general comments on the WSON document set - You define a new top-level TLV, the Generic Node Attribute TLV. Did you consider using the Node Attribute TLV defined in RFC5786? Why not use it? - The Generic Node Attribute TLV is underspecified as is. - What is the sub-tlv format - how are unknown TLVs handled - are there ordering or other processing constraints - etc. - Section 2.1 and 3.1: no need to defined the type twice, drop "(the type is TBD by IANA)" the TLV isn't defined in GEN-ENCODE, the format of the value field is. in both sections: s/meaning and format of this sub-TLV/meaning and format of the sub-TLV value field - Section 4 OLD The flooding of Opaque LSAs must follow the rules specified in [RFC2328], [RFC5250], [RFC3630], [RFC4203]. NEW The flooding rules of Opaque LSAs are specified in [RFC2328], [RFC5250], [RFC3630], [RFC4203]. - Section 4, last paragraph Text should be aligned with the preexisting TE procedures as defined in Section 3 of RFC3630. - Section 7 Looks like Acee already covered this section. - References. [RFC6205] is listed but not used. That's it on this one, Lou On 10/22/2013 4:34 PM, Lou Berger wrote: > > All, > Given the recent draft submission deadline and only one comment being > received to date, we'd like to extend the WG more time for review. > > These drafts represent significant work by the authors and WG, so please > review and let the WG know what you think (positive or negative)! > > Please have all comments in by October 29. > > Thank you, > Lou (and Deborah) > > On 10/1/2013 12:34 PM, Lou Berger wrote: >> All, >> >> This mail begins working group last call on the WSON documents. As >> there are 6 documents in this set, the last call will be three weeks. >> The documents included in the last call are: >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 >> (Informational, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 >> (Standards Track) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards >> Track) Also has one open issue that will need to be resolved as part of >> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. >> >> This working group last call ends on October 22. Comments should be >> sent to the CCAMP mailing list. Please remember to include the >> technical basis for any comments. >> >> Positive comments, e.g., "I've reviewed this document and believe it is >> ready for publication", are welcome! >> >> Please note that we're still missing some IPR statements. Any >> forthcoming publication request will be delayed by late IPR >> statements/disclosures. >> >> >> Thank you, >> Lou (and Deborah) >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Tue Oct 29 11:28:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F90211E8256 for ; Tue, 29 Oct 2013 11:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.026 X-Spam-Level: X-Spam-Status: No, score=-102.026 tagged_above=-999 required=5 tests=[AWL=0.239, 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 RKVWSSevwahs for ; Tue, 29 Oct 2013 11:28:39 -0700 (PDT) Received: from outbound-ss-2156.bluehost.com (outbound-ss-2156.bluehost.com [67.20.64.47]) by ietfa.amsl.com (Postfix) with SMTP id A3B0121F9E3B for ; Tue, 29 Oct 2013 11:28:39 -0700 (PDT) Received: (qmail 486 invoked by uid 0); 29 Oct 2013 18:28:39 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy17-pub.mail.unifiedlayer.com with SMTP; 29 Oct 2013 18:28:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=4mZDHzXbnMq3y3SCHM/ZRpp1o/qqGIZ8ZI3JZHWNxgk=; b=vIAccEpVhP3K/WPbhYYxq9+/AHC1infNag1n3kCbhXKUbWzPEnyyGAmEM22rOzyeRnG52dwGVKFgxqzpwZwB1de68U0RvPqXnmhxNefutMSJ47C2YSqj0T60Cg/DxSKX; Received: from box313.bluehost.com ([69.89.31.113]:53192 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbE1u-0005zv-SS; Tue, 29 Oct 2013 12:28:39 -0600 Message-ID: <526FFE4F.30309@labn.net> Date: Tue, 29 Oct 2013 14:28:31 -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: CCAMP , "draft-ietf-ccamp-wson-signaling@tools.ietf.org" References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> In-Reply-To: <5266E138.8080605@labn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:28:44 -0000 Authors, I have some comments on this document. Most are strictly editorial. Note that I'm the document shepherd, see RFC 4858 for more information. - Please address my general comments on the WSON document set - in document s/Bi-Directional/Bidirectional - Abstract s/Such extensions are necessary/Such extensions are applicable drop "bidirectional LSPs, and" - Section 1 These extensions build on previous work for the control of lambda and G.709 based networks. Please add appropriate references. It seems to that it would be worth mentioning the rwa-info document and the encoding document in this section. - section 3.1 s/MUST/needs to - Section 3.3 s/MAY/can s/MAY/need to be - Section 3.4 s/MAY/can - section 3.5 title s/Out of Scope/Optical Impairments - Section 4.2: To target a specific node, this section defines a WSON_Processing object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures defined in [RSVP-RO]. The content of this object is defined in the subsequent sections. (See Section 4.3 for TLV and Section 4.4 for TLV, respectively.) Do you mean To target a specific node, this section defines a WSON_Processing HOP Attribute TLV which is processed according to the procedures defined in [RSVP-RO]. The content of this TLV is defined in the subsequent sections. (See Section 4.3 for sub-TLV and Section 4.4 for sub-TLV, respectively.) if yes, also need to s/WSON Processing object/WSON Processing TLV in rest of document. - Section 4.2 You need to define the Length. Perhaps. replace the whole definition: OLD The WSON Processing object encoding is defined as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEW The WSON Processing carries sub-TLVs of the same format as a HOP Attributes TLV, as defined in [RSVP-RO]. - Section 4.3. "... PathErr SHALL be generated." Which code/value? Are you sure? Generally malformed messages don't result in a PathErr. What is an upstream node expected to do with the PathErr? How should other parsing errors be handled? What about allocation errors? - Section 4.4 I'm really confused by this sub-tlv. Is it intended to be an end to end construct, information that is used/updated hop-by-hop, or used at specific hops only? I suspect that the desire is for this to be communicated end to end and accessible at each hop. If so, it looks like then intent is for this to be carried as a TLV in the LSP_ATTRIBUTES Object. Is this correct? If so the section needs to be updated accordingly. - Section 5 I'm really not sure that this section adds anything beyond what is already stated in other documents/RFCs, and it doesn't match this documenting being a protocol specification. I can see some informative value in the third paragraph. I suggest moving just this paragraph to the end of section 4.3 and dropping the rest. - Section 6 I think this section needs to be replaced. Perhaps use the following which is based on draft-ietf-ccamp-gmpls-signaling-g709v3 This document is builds on the mechanisms defined in [RFC3473], and only differs in specific information communicated. As such, this document introduces no new security considerations to the existing GMPLS signaling protocols. See [RFC3473], for details of the supported security measures. Additionally, [RFC5920] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane. - Section 7 This section needs a bit of work See http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-12#section-11 for an example. Contact me off list if you think need help with specific text. That's it on this one, Lou On 10/22/2013 4:34 PM, Lou Berger wrote: > > All, > Given the recent draft submission deadline and only one comment being > received to date, we'd like to extend the WG more time for review. > > These drafts represent significant work by the authors and WG, so please > review and let the WG know what you think (positive or negative)! > > Please have all comments in by October 29. > > Thank you, > Lou (and Deborah) > > On 10/1/2013 12:34 PM, Lou Berger wrote: >> All, >> >> This mail begins working group last call on the WSON documents. As >> there are 6 documents in this set, the last call will be three weeks. >> The documents included in the last call are: >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 >> (Informational, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 >> (Standards Track) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards >> Track) Also has one open issue that will need to be resolved as part of >> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. >> >> This working group last call ends on October 22. Comments should be >> sent to the CCAMP mailing list. Please remember to include the >> technical basis for any comments. >> >> Positive comments, e.g., "I've reviewed this document and believe it is >> ready for publication", are welcome! >> >> Please note that we're still missing some IPR statements. Any >> forthcoming publication request will be delayed by late IPR >> statements/disclosures. >> >> >> Thank you, >> Lou (and Deborah) >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Tue Oct 29 12:07:50 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CB911E8110 for ; Tue, 29 Oct 2013 12:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.396, 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 p6RgauyfHu6z for ; Tue, 29 Oct 2013 12:07:38 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id AA40911E8263 for ; Tue, 29 Oct 2013 12:07:35 -0700 (PDT) Received: (qmail 24361 invoked by uid 0); 29 Oct 2013 19:07:11 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by qproxy1.mail.unifiedlayer.com with SMTP; 29 Oct 2013 19:07: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:To:MIME-Version:From:Date:Message-ID; bh=Wq67fQhBd+YXERLPWqWSoOHoHghD/ddNXC1Yo3CCjPs=; b=lQD/qIJyDz6mIEfHHDY6QVYQH04fteX39BkbxamlcKu7GaKj0WrViuRhZva/0APWBjQySh+l+t/ZY9kkzPvKOAg1kVy0KyXRJ7Vcg9SrY3PXu/5xftLK/jrcgpsiewai; Received: from box313.bluehost.com ([69.89.31.113]:52861 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbE0W-0005Td-Kz; Tue, 29 Oct 2013 12:27:12 -0600 Message-ID: <526FFDF8.1060101@labn.net> Date: Tue, 29 Oct 2013 14:27:04 -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: CCAMP , draft-ietf-ccamp-general-constraint-encode@tools.ietf.org References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> In-Reply-To: <5266E138.8080605@labn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:07:50 -0000 Authors, I have some comments on this document. A number are strictly editorial. Note that I'm the document shepherd, see RFC 4858 for more information. - Please address my general comments on the WSON document set - I'm a bit surprised that this document does *not* reference the rwa-info draft. Given that it provides the context for this document, it should be there, and probably as a normative reference. - Your references to [Switch] seem almost normative in nature. I suspect that this is not your intent as it is listed as an informative reference. Please revisit your references and ensure that the draft does not depend on any informative references. (Either change the text, or move the reference to normative.) Perhaps these are places where a reference to rwa-info are more appropriate. - An editorial comment on section ordering: Section 2 is ordered as follows: 2. Encoding.......................................................6 2.1. Link Set Field............................................6 2.2. Label Set Field...........................................8 2.3. Available Labels Sub-TLV.................................11 2.4. Shared Backup Labels Sub-TLV.............................11 2.5. Connectivity Matrix Sub-TLV..............................12 2.6. Port Label Restriction sub-TLV...........................13 Is there a logical order to these sections? They don't seem to be aligned with the rwa-info draft which has: 4. Node Information (General).....................................8 4.1. Connectivity Matrix.......................................9 4.2. Shared Risk Node Group...................................10 6. Link Information (General)....................................17 6.6. Port Label (Wavelength) Restrictions.....................18 7. Dynamic Components of the Information Model...................21 7.1. Dynamic Link Information (General).......................22 Perhaps it makes sense from a readability standpoint to realign to match rwa-info? - Section 2 says: A type-length-value (TLV) encoding of the general connectivity and label restrictions and availability extensions is given in this section. This encoding is designed to be suitable for use in the GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in the PCE protocol PCEP [PCEP]. Note that the information distributed in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs within TLVs and this document makes use of such constructs... Yet there are no types or (sub)TLVs actually defined in this document. As such, I think this document should not use the term "sub-TLV" for the information elements it defines. In most cases this just means substituting "the sub-TLV" with just "". Section 2 can be revised to read something along the lines of: This section provides encodings for the information elements defined in [RWA-INFO] that have general applicability. The encodings are designed to be suitable for use in the GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in the PCE protocol PCEP [PCEP]. Note that the information distributed in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs within TLVs and this document defines elements to be used within such constructs... - section 2.2. Labels are variable in lengh and need not be 4 bytes long. This needs to be represented and accounted for in the encodings defined in this section. - Section 2.2.1 and 2.2.2 says "Num Labels (not used)" and "Num Labels is not used in this particular format since the Length parameter is sufficient to determine the number of labels in the list." Is there a reason to not set the Num Labels Field in these cases? Recall that labels are themselves variable length fields. - section A.2 s/With the Grid/Using the label format defined in [RFC 6205], with the Grid... s/Num Wavelengths/Num Labels (multiple places) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Num Wavelengths = 40 | Length = 20 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ shouldn't Num Labels either be 0 (if unused) or = 7 (assuming num labels used in this case)? That's it on this one, Lou On 10/22/2013 4:34 PM, Lou Berger wrote: > > All, > Given the recent draft submission deadline and only one comment being > received to date, we'd like to extend the WG more time for review. > > These drafts represent significant work by the authors and WG, so please > review and let the WG know what you think (positive or negative)! > > Please have all comments in by October 29. > > Thank you, > Lou (and Deborah) > > On 10/1/2013 12:34 PM, Lou Berger wrote: >> All, >> >> This mail begins working group last call on the WSON documents. As >> there are 6 documents in this set, the last call will be three weeks. >> The documents included in the last call are: >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 >> (Informational, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 >> (Standards Track) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards >> Track) Also has one open issue that will need to be resolved as part of >> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. >> >> This working group last call ends on October 22. Comments should be >> sent to the CCAMP mailing list. Please remember to include the >> technical basis for any comments. >> >> Positive comments, e.g., "I've reviewed this document and believe it is >> ready for publication", are welcome! >> >> Please note that we're still missing some IPR statements. Any >> forthcoming publication request will be delayed by late IPR >> statements/disclosures. >> >> >> Thank you, >> Lou (and Deborah) >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From leeyoung@huawei.com Tue Oct 29 12:09:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DD711E8110 for ; Tue, 29 Oct 2013 12:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cVkL+0qSBVs for ; Tue, 29 Oct 2013 12:09:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 395BD11E8257 for ; Tue, 29 Oct 2013 12:09:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZP70237; Tue, 29 Oct 2013 19:09:05 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 19:08:46 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 19:09:04 +0000 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Tue, 29 Oct 2013 12:08:57 -0700 From: Leeyoung To: "Giovanni Martinelli (giomarti)" , Lou Berger Thread-Topic: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling Thread-Index: AQHOvsRPNOeuDADDv0SQJTTbfFVtKZoMHdCAgAAYY9A= Date: Tue, 29 Oct 2013 19:08:57 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17291DCEF7@dfweml511-mbs.china.huawei.com> References: <524AF9A9.3040006@labn.net> <0D7F95913F470A4B83AB5F5833A4390D0EE587D6@xmb-rcd-x14.cisco.com> In-Reply-To: <0D7F95913F470A4B83AB5F5833A4390D0EE587D6@xmb-rcd-x14.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:09:17 -0000 Hi Giovanni, I thought 64 bit field has been already assigned for the application codes = in Section 4.2.1 as follows:=20 "In case of ITU Application Code, the mapping between the string defining t= he application code and the 64 bits number implementing the optical interfa= ce class is given in the following sections." Let me know if this is good enough.=20 Thanks. Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= iovanni Martinelli (giomarti) Sent: Tuesday, October 29, 2013 5:38 AM To: Lou Berger Cc: CCAMP Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-const= raint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-sign= al-compatibility-ospf, wson-signaling Hi all, On Oct 1, 2013, at 18:34 , Lou Berger wrote: >=20 > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 > (Standards Track) We propose an encoding of ITU application codes on 64 bits of Optical Inter= face Class (Section 4.2), just wandering if we already had any ITU/Q6 feedb= ack or we are just ok with proposed encoding. I'm ok with the rest of LC documents Cheers G _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From leeyoung@huawei.com Tue Oct 29 13:48:50 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338ED11E814C for ; Tue, 29 Oct 2013 13:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=-3.402, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEVH4chtTZJP for ; Tue, 29 Oct 2013 13:48:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BA44111E818D for ; Tue, 29 Oct 2013 13:48:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXI69693; Tue, 29 Oct 2013 20:48:32 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 20:48:14 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 20:48:17 +0000 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 29 Oct 2013 13:48:10 -0700 From: Leeyoung To: Lou Berger Thread-Topic: Regarding IPR on draft-ietf-ccamp-wson-signaling Thread-Index: AQHOvZI58Zu+GH9G5E2MAKduooqeHpoMVL6Q Date: Tue, 29 Oct 2013 20:48:09 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17291DCF36@dfweml511-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.126] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E17291DCF36dfweml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: [CCAMP] FW: Regarding IPR on draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:48:50 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E17291DCF36dfweml511mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTG91LA0KDQpMaW4gR3VvIGhhcyBhbHJlYWR5IGRlY2xhcmVkIHRoZSBmb2xsb3dpbmcgSVBS IHN0YXRlbWVudCBmb3IgPGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWxpbmc+Lg0KDQpUaGFu a3MsDQpZb3VuZw0KDQpGcm9tOiC5+cHWIFttYWlsdG86Z3VvbGludG9tQGdtYWlsLmNvbV0NClNl bnQ6IFN1bmRheSwgU2VwdGVtYmVyIDI5LCAyMDEzIDExOjA1IFBNDQpUbzogTG91IEJlcmdlcg0K Q2M6IGdyZWdiQGdyb3R0by1uZXR3b3JraW5nLmNvbTsgbmlja0Bzc3N1cC5pdDsgYS5naW9yZ2V0 dGlAc3NzdXAuaXQ7IGhhcmFpQG5pY3QuZ28uanA7ILzNwM/KpjsgZGFuaWVsQG9sZGRvZy5jby51 azsgTGVleW91bmc7IHhzZ0BuaWN0LmdvLmpwOyBnaW9tYXJ0aUBjaXNjby5jb207IGNjYW1wQGll dGYub3JnDQpTdWJqZWN0OiBSZTogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRmLWNjYW1wLXdz b24tc2lnbmFsaW5nDQoNCk5vLCBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGll cyB0byB0aGlzIGRyYWZ0Lg0KDQpMaW4gR3VvDQoNCjIwMTMvNy8xOSBMb3UgQmVyZ2VyIDxsYmVy Z2VyQGxhYm4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4NCkF1dGhvcnMsIENvbnRyaWJ1 dG9ycywgKENDQU1QKQ0KDQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBD YWxsOg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlk ZW50aWZpZWQgYWJvdmU/DQoNCiAgUGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAiTm8sIEknbSBu b3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCiAgb3INCiAg IlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCg0KSWYg c28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJ UFIgcnVsZXMNCihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRl dGFpbHMpPw0KDQogICBJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0K DQogICJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJ RVRGIElQUiBydWxlcyINCiAgb3INCiAgIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9z ZWQiDQoNCiAgSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwg ZGV0YWlscyB5b3UgdGhpbmsNCiAgYXBwcm9wcmlhdGUuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFz IGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3ZXIgdGhlDQphYm92 ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5v dCB5b3UgYXJlDQphd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiAgVGhpcyBkb2N1bWVudCB3aWxs IG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0DQpzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVu IHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZA0KY29udHJpYnV0b3IuICBOT1RF OiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUw0KTUVTU0FHRSdTIFRP IExJTkVTLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBDQ0FNUCBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUg bm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3INCmNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9m IHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzDQp3aGljaCBlbmNvdXJh Z2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2YNCm90 aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRpY2lw YXRpbmcgaW4gYW55DQpjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIg dW5kaXNjbG9zZWQgSVBSLiAgRm9yIG1vcmUNCmluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBS RkNzIGxpc3RlZCBhYm92ZSBhbmQNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2ll c2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpDQ0FNUCBX RyBDaGFpcnMNCg0KUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBv ZiB0aGlzIG1lc3NhZ2UgaW4geW91cg0KcmVzcG9uc2UuDQoNCg0KDQotLQ0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCrn5wdYNCtbQufrBqs2osbG+ qbfWuavLvrzGt9HT69DFz6LPtc2zsr8NCrGxvqnK0Lqjte3H+NHyt7u16sK3OS0xusW+qcPFtPPP wzG2zjSy4yAgICAgICAgINPKseCjujEwMDAzOA0Ktee7sKO6MDEwLTYzOTk5NDY4o6iw7KOpIMrW u/o6MTU2MTEwMzI2ODUNCtPKz+Q6IGd1b2xpbnRvbUBnbWFpbC5jb208bWFpbHRvOmd1b2xpbnRv bUBnbWFpbC5jb20+DQo= --_000_7AEB3D6833318045B4AE71C2C87E8E17291DCF36dfweml511mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Lou,=

 <= /p>

Lin Guo has already decla= red the following IPR statement for <draft-ietf-ccamp-wson-signaling>= .

 <= /p>

Thanks,=

Young

 <= /p>

From: =B9=F9=C1=D6<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif""> [mailto:guolintom@gmail.com]
Sent: Sunday, September 29, 2013 11:05 PM
To: Lou Berger
Cc: gregb@grotto-networking.com; nick@sssup.it; a.giorgetti@sssup.it= ; harai@nict.go.jp; =BC=CD=C0=CF=CA=A6; daniel@olddog.co.uk; Leeyoung; xsg@nict.go.jp; giomarti@= cisco.com; ccamp@ietf.org
Subject: Re: Regarding IPR on draft-ietf-ccamp-wson-signaling

 

No, I am not aware of any IPR that applie= s to this draft.

 

Lin Guo

 

2013/7/19 Lou Berger <lberger@labn.net>

Authors, Contributors, (CCAMP)

As part of the preparation for WG Last Call:

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

  Please state either:

  "No, I'm not aware of any IPR that applies to this draft"<= br>   or
  "Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

   If yes to the above, please state either:

  "Yes, the IPR has been disclosed in compliance with IETF IPR ru= les"
  or
  "No, the IPR has not been disclosed"

  If you answer no, please provide any additional details you think   appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR.  This document will not advance to the next=
stage until a response has been received from each author and listed
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.

If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules
which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in any
contribution or discussion related to your undisclosed IPR.  For more<= br> information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/Int= ellectualProperty.

Thank you,
CCAMP WG Chairs

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



 

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=B9=F9=C1=D6
=D6=D0=B9=FA=C1=AA=CD=A8=B1=B1=BE=A9=B7=D6=B9=AB=CB=BE= =BC=C6=B7=D1=D3=EB=D0=C5=CF=A2=CF=B5=CD=B3=B2=BF
=B1=B1=BE=A9=CA=D0=BA=A3=B5=ED=C7=F8=D1=F2=B7=BB=B5=EA= =C2=B79-1=BA=C5=BE=A9=C3=C5=B4=F3=CF=C31= =B6=CE4=B2=E3 =        =D3=CA=B1=E0=A3=BA100038
=B5=E7=BB=B0=A3=BA010-63999468=A3=A8=B0=EC=A3=A9 =CA=D6=BB=FA:15611032685
=D3=CA=CF=E4: guolintom@gmail.com

--_000_7AEB3D6833318045B4AE71C2C87E8E17291DCF36dfweml511mbschi_-- From lberger@labn.net Tue Oct 29 14:06:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B888611E81C9 for ; Tue, 29 Oct 2013 14:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.25 X-Spam-Level: X-Spam-Status: No, score=-100.25 tagged_above=-999 required=5 tests=[AWL=-1.590, BAYES_05=-1.11, MIME_CHARSET_FARAWAY=2.45, 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 GTK5Ek9w7tEh for ; Tue, 29 Oct 2013 14:05:49 -0700 (PDT) Received: from outbound-ss-713.hostmonster.com (outbound-ss-713.hostmonster.com [74.220.207.38]) by ietfa.amsl.com (Postfix) with SMTP id 27EDC21F9BDB for ; Tue, 29 Oct 2013 14:05:48 -0700 (PDT) Received: (qmail 5917 invoked by uid 0); 29 Oct 2013 21:05:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy4.mail.unifiedlayer.com with SMTP; 29 Oct 2013 21:05:46 -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=SALtRiIyWnQKGTw9RdUjR3uflC7kb24JnrJb4kNrD7c=; b=Jyqc1oWEWZ5Dxw07fxhsZjbbS+ItuL5iaDt6vGs59VuRXpCYjJ+anJ0sS94VSa7JG3Fx7bhloXNiRz1DT99s5tUueWFfPfeO4dGP57o/w4B/PyC529hYkMHHSF1ooiXL; Received: from box313.bluehost.com ([69.89.31.113]:52204 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbGTx-0000F7-Ug; Tue, 29 Oct 2013 15:05:46 -0600 Message-ID: <52702329.6050106@labn.net> Date: Tue, 29 Oct 2013 17:05:45 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Leeyoung References: <7AEB3D6833318045B4AE71C2C87E8E17291DCF36@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E17291DCF36@dfweml511-mbs.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=GB2312 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: CCAMP Subject: Re: [CCAMP] FW: Regarding IPR on draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 21:06:18 -0000 Young, Thanks for forwarding this for the archives. I'm not sure why his messages are not making it in... Lou On 10/29/2013 04:48 PM, Leeyoung wrote: > Hi Lou, > > > > Lin Guo has already declared the following IPR statement for > . > > > > Thanks, > > Young > > > > *From:*郭林[mailto:guolintom@gmail.com] > *Sent:* Sunday, September 29, 2013 11:05 PM > *To:* Lou Berger > *Cc:* gregb@grotto-networking.com; nick@sssup.it; a.giorgetti@sssup.it; > harai@nict.go.jp; 纪老师; daniel@olddog.co.uk; Leeyoung; xsg@nict.go.jp; > giomarti@cisco.com; ccamp@ietf.org > *Subject:* Re: Regarding IPR on draft-ietf-ccamp-wson-signaling > > > > No, I am not aware of any IPR that applies to this draft. > > > > Lin Guo > > > > 2013/7/19 Lou Berger > > > Authors, Contributors, (CCAMP) > > As part of the preparation for WG Last Call: > > Are you aware of any IPR that applies to draft identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE'S TO LINES. > > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > CCAMP WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > > > -- > ================================================== > 郭林 > 中国联通北京分公司计费与信息系统部 > 北京市海淀区羊坊店路9-1号京门大厦1段4层 邮编：100038 > 电话：010-63999468（办） 手机:15611032685 > 邮箱: guolintom@gmail.com > From acee.lindem@ericsson.com Tue Oct 29 15:16:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED62611E80F7 for ; Tue, 29 Oct 2013 15:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 oSWq-iHXCZ1R for ; Tue, 29 Oct 2013 15:16:26 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 230DD11E8214 for ; Tue, 29 Oct 2013 15:16:15 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-9a-527033ae583f Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A7.73.03458.EA330725; Tue, 29 Oct 2013 23:16:14 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 18:16:14 -0400 From: Acee Lindem To: CCAMP Thread-Topic: WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks" Thread-Index: AQHO1PR6OxsJkAR0EUmBv2bkfRkIWg== Date: Tue, 29 Oct 2013 22:16:13 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030B0E4A@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_94A203EA12AECE4BA92D42DBFFE0AE47030B0E4Aeusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyuXRPoO4644Igg941RhZP5txgcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRv+GNywFqwIrlu3fzNLA2OPcxcjJISFgIvFn3ipWCFtM4sK9 9WxdjFwcQgJHGCUONB5nhXCWM0osWQZRxSagI/H80T9mEFtEQEri5r5b7CBFwgK9jBK3T18E c0QEJjFK/Fm7lAmiSk/i7fH3YN0sAqoSx5bcZwGxeQV8JTqPvWIDsRmBdn8/tQasnllAXOLW k/lMEDcJSCzZc54ZwhaVePn4H9StyhJLnuxngajPlzh08DYjxExBiZMzn7BMYBSahWTULCRl s5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMVSvtUTvgQ+MyGoWMHKsYuQoLU4ty003MtzECIyL YxJsjjsYF3yyPMQozcGiJM775a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGaP81/6ft ltyxueg872mlJDt3Uc3fgVMmNlu8XbHLxePvzFB574giR/1Zx5fIH7jL/tWBc0/Fi9tfzyQt jvaeKLdtk2v8J1c9iU3NypusBcU5Mt4ILul3FWt8yvY9Y0u/TeEauf3Z3OWWss8rWa/cP3bl y6L7zHmf2vd9XzTllNzB0rZJT061KrEUZyQaajEXFScCAAnkeE1ZAgAA Subject: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 22:16:34 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030B0E4Aeusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have the following comments on the subject draft: 1. State the action to take if the new TLV and sub-TLVs or t= heir attendant encodings are malformed. You should log the problem and igno= re the entire LSA, subsuming TLV, or just the sub-TLV in GMPLS path computa= tions. 2. Section 2 - Your definition of "At most once" is semantic= ally wrong. "At most once" means the TLV or sub-TLV can be include one time= or not at all. It has nothing to with whether or not it should be specifie= d. I hope we are not going to attempt to change the English language with t= his draft. 3. Section 3 - Figure 1 should not span multiple pages and t= he scale is off by one - it should be shifted right 1 column. 4. Section 6 - Explicitly state which are IANA registries ar= e being extended. Since you are adding a new TLV, you will also need a new = registry for the sub-TLVs. Seehttp://www.iana.org/assignments/ospf-traffic-= eng-tlvs/ospf-traffic-eng-tlvs.xhtml#top-level for examples. Editorial Comments: I would suggest the following corrections: 125c125 < to allow both multiple WSON signal types and common hybrid electro --- > to support both multiple WSON signal types and common hybrid electro 197c197 < node. It is constructed of a set of sub-TLVs. There are no ordering --- > node. It is comprised of a set of sub-TLVs. There are no ordering 203c203 < encodings of these properties are defined in [WSON-Encode]. --- > encodings for these properties are defined in [WSON-Encode]. 253,254c253 < router, as described in [RFC3630] and [RFC5250]. Resource Block < Information --- > router, as described in [RFC3630] and [RFC5250]. 279,280c278,279 < The detail encodings of these sub-TLVs are found in [WSON-Encode] as < indicated in the table below. --- > The detailed encodings of these sub-TLVs are found in [WSON-Encode] > as indicated in the table below. 293c292 < relation to the switching device. In particular it indicates the --- > relation to the switching device. In particular, it indicates the 302,303c301,302 < reach or leave all the resources. Resource Block Wavelength < Constraints sub-TLV describe these properties. --- > reach or leave all the resources. The Resource Block Wavelength > Constraints sub-TLV describes these properties. 316c315 < case then wavelength availability on these shared fibers is needed --- > case, then wavelength availability on these shared fibers is needed 353c352 < Bandwidth TLV are defined (TBA by IANA): --- > Bandwidth sub-TLVs are defined (TBA by IANA): 402c401 < produce LSAs that exceed the IP Maximum Transmission Unit (MTU). In --- > produce LSAs that exceeds the IP Maximum Transmission Unit (MTU). In 417,422c416,421 < is received for a system path cannot make use of the other four sub- < TLVs since it does not know the nature of the resources, e.g., are < the resources wavelength converters, regenerators, or something < else. Once this sub-TLV is received path computation can proceed < with whatever of the additional types of sub-TLVs it may have < received (there use is dependent upon the system type). If path --- > is received for a system, path compuation cannot make use of the > other four sub-TLVs since it does not know the nature of the > resources, e.g., are the resources wavelength converters, > regenerators, or something else. Once this sub-TLV is received, > path computation can proceed with whatever sub-TLVs it may have > received (their use is dependent upon the system type). If path 433c432 < these sub-TLVs then there is the possibility of either (a) path --- > these sub-TLVs, then there is the possibility of either (a) path Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE47030B0E4Aeusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <4AF3C6B65E08F947AA71F1380C04EC51@ericsson.com> Content-Transfer-Encoding: quoted-printable
I have the following comments on the subject draft:

               1. State t= he action to take if the new TLV and sub-TLVs or their attendant encodings = are malformed. You should log the problem and ignore the entire LSA, subsum= ing TLV, or just the sub-TLV in GMPLS path computations. 
               2. Section 2 - = Your definition of "At most once" is semantically wrong. "At= most once" means the TLV or sub-TLV can be include one time or not at= all. It has nothing to with whether or not it should be specified. I hope = we are not going to attempt to change the English language with this draft. 
               3. Section 3 - = Figure 1 should not span multiple pages and the scale is off by one - it sh= ould be shifted right 1 column.  
               4. Section 6 - = Explicitly state which are IANA registries are being extended. Since you ar= e adding a new TLV, you will also need a new registry for the sub-TLVs. See= http://www.iana.org/assignments/ospf-traffic-e= ng-tlvs/ospf-traffic-eng-tlvs.xhtml#top-level for examples.  
         

Editorial Comments:

I would suggest the following corrections:
  

125c125
<    to allow both multiple WSON signal types and common = hybrid electro
---
>    to support both multiple WSON signal types and commo= n hybrid electro
197c197
<    node. It is constructed of a set of sub-TLVs. There = are no ordering
---
>    node. It is comprised of a set of sub-TLVs. There ar= e no ordering
203c203
<    encodings of these properties are defined in [WSON-E= ncode].
---
>    encodings for these properties are defined in [WSON-= Encode].
253,254c253
<    router, as described in [RFC3630] and [RFC5250]. Res= ource Block
<    Information
---
>    router, as described in [RFC3630] and [RFC5250].
279,280c278,279
<    The detail encodings of these sub-TLVs are found in = [WSON-Encode] as
<    indicated in the table below.
---
>    The detailed encodings of these sub-TLVs are found i= n [WSON-Encode]
>    as indicated in the table below.
293c292
<    relation to the switching device. In particular it i= ndicates the
---
>    relation to the switching device. In particular, it = indicates the
302,303c301,302
<    reach or leave all the resources. Resource Block Wav= elength
<    Constraints sub-TLV describe these properties.
---
>    reach or leave all the resources. The Resource Block= Wavelength
>    Constraints sub-TLV describes these properties.
316c315
<    case then wavelength availability on these shared fi= bers is needed
---
>    case, then wavelength availability on these shared f= ibers is needed
353c352
<    Bandwidth TLV are defined (TBA by IANA):
---
>    Bandwidth sub-TLVs are defined (TBA by IANA):
402c401
<    produce LSAs that exceed the IP Maximum Transmission= Unit (MTU). In
---
>    produce LSAs that exceeds the IP Maximum Transmissio= n Unit (MTU). In
417,422c416,421
<    is received for a system path cannot make use of the= other four sub-
<    TLVs since it does not know the nature of the resour= ces, e.g., are
<    the resources wavelength converters, regenerators, o= r something
<    else. Once this sub-TLV is received path computation= can proceed
<    with whatever of the additional types of sub-TLVs it= may have
<    received (there use is dependent upon the system typ= e). If path
---
>    is received for a system, path compuation cannot mak= e use of the 
>    other four sub-TLVs since it does not know the natur= e of the 
>    resources, e.g., are the resources wavelength conver= ters, 
>    regenerators, or something else. Once this sub-TLV i= s received,
>    path computation can proceed with whatever sub-TLVs = it may have
>    received (their use is dependent upon the system typ= e). If path
433c432
<    these sub-TLVs then there is the possibility of eith= er (a) path
---
>    these sub-TLVs, then there is the possibility of eit= her (a) path

Thanks,
Acee
 
--_000_94A203EA12AECE4BA92D42DBFFE0AE47030B0E4Aeusaamb101erics_-- From lberger@labn.net Wed Oct 30 05:59:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE3011E811D for ; Wed, 30 Oct 2013 05:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.176 X-Spam-Level: X-Spam-Status: No, score=-101.176 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPu185mg0fLs for ; Wed, 30 Oct 2013 05:59:07 -0700 (PDT) Received: from outbound-ss-713.hostmonster.com (outbound-ss-713.hostmonster.com [74.220.207.38]) by ietfa.amsl.com (Postfix) with SMTP id 3EBF911E818D for ; Wed, 30 Oct 2013 05:58:37 -0700 (PDT) Received: (qmail 24210 invoked by uid 0); 30 Oct 2013 12:58:36 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy4.mail.unifiedlayer.com with SMTP; 30 Oct 2013 12:58:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=MPd3pBMOmOfCPIA7lV+Hi2mGspwuhx5orSJNmvSu8o8=; b=P0stPcH4AWYuk8pPfoMYAmHiYqiayCQusOqmDYZZ1jI4sHypsgjtnpyL/3Eh6lMJR0qdr1jLBJnAibO1AZduBsn/sagIWiuIxU2dzQ7wSrBCHvH8PijePW898X3JbjGd; Received: from box313.bluehost.com ([69.89.31.113]:52434 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbVM4-0004Ky-7m; Wed, 30 Oct 2013 06:58:36 -0600 Message-ID: <52710273.80805@labn.net> Date: Wed, 30 Oct 2013 08:58:27 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: CCAMP , "draft-ietf-ccamp-wson-signaling@tools.ietf.org" References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> <526FFE4F.30309@labn.net> In-Reply-To: <526FFE4F.30309@labn.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 12:59:12 -0000 Authors, Sorry, I missed an important one when writing up my notes: Somewhere you should state that the LSPs signaled per the document must use Switching Type = WSON-LSC [WSON-OSPF] Encoding Type = Lambda [RFC3471] Label format = per [RFC6205] You should probably also state that this draft updates 5205 in that it permits use of the defined label type for WSON-LSC. This will need to be mentioned in both the abstract and in the body. Lou On 10/29/2013 2:28 PM, Lou Berger wrote: > Authors, > I have some comments on this document. Most are strictly > editorial. Note that I'm the document shepherd, see RFC 4858 for more > information. > > - Please address my general comments on the WSON document set > > - in document > s/Bi-Directional/Bidirectional > > - Abstract > s/Such extensions are necessary/Such extensions are applicable > drop "bidirectional LSPs, and" > > - Section 1 > > These extensions build on previous work for the control of lambda > and G.709 based networks. > > Please add appropriate references. > > It seems to that it would be worth mentioning the rwa-info document > and the encoding document in this section. > > - section 3.1 > s/MUST/needs to > > - Section 3.3 > s/MAY/can > s/MAY/need to be > > - Section 3.4 > s/MAY/can > > - section 3.5 title > s/Out of Scope/Optical Impairments > > - Section 4.2: > To target a specific node, this section defines a WSON_Processing > object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures > defined in [RSVP-RO]. > > The content of this object is defined in the subsequent sections. > (See Section 4.3 for TLV and Section 4.4 for > TLV, respectively.) > > Do you mean > > To target a specific node, this section defines a WSON_Processing > HOP Attribute TLV which is processed according to the procedures > defined in [RSVP-RO]. > > The content of this TLV is defined in the subsequent sections. > (See Section 4.3 for sub-TLV and Section 4.4 for > sub-TLV, respectively.) > > if yes, also need to s/WSON Processing object/WSON Processing TLV > in rest of document. > > - Section 4.2 > You need to define the Length. Perhaps. replace the whole definition: > OLD > > The WSON Processing object encoding is defined as: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Value ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > NEW > The WSON Processing carries sub-TLVs of the same format as a HOP > Attributes TLV, as defined in [RSVP-RO]. > > - Section 4.3. "... PathErr SHALL be generated." Which code/value? > Are you sure? Generally malformed messages don't result in a PathErr. > What is an upstream node expected to do with the PathErr? > > How should other parsing errors be handled? > > What about allocation errors? > > - Section 4.4 > > I'm really confused by this sub-tlv. Is it intended to be an end to > end construct, information that is used/updated hop-by-hop, or used at > specific hops only? I suspect that the desire is for this to be > communicated end to end and accessible at each hop. If so, it looks > like then intent is for this to be carried as a TLV in the > LSP_ATTRIBUTES Object. Is this correct? If so the section needs to be > updated accordingly. > > - Section 5 > > I'm really not sure that this section adds anything beyond what is > already stated in other documents/RFCs, and it doesn't match this > documenting being a protocol specification. I can see some informative > value in the third paragraph. I suggest moving just this paragraph to > the end of section 4.3 and dropping the rest. > > - Section 6 > I think this section needs to be replaced. Perhaps use the following > which is based on draft-ietf-ccamp-gmpls-signaling-g709v3 > > This document is builds on the mechanisms defined in [RFC3473], > and only differs in specific information communicated. As such, > this document introduces no new security considerations to the > existing GMPLS signaling protocols. See [RFC3473], for > details of the supported security measures. Additionally, > [RFC5920] provides an overview of security vulnerabilities and > protection mechanisms for the GMPLS control plane. > > - Section 7 > This section needs a bit of work See > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-12#section-11 > for an example. Contact me off list if you think need help with > specific text. > > That's it on this one, > Lou > > > On 10/22/2013 4:34 PM, Lou Berger wrote: >> >> All, >> Given the recent draft submission deadline and only one comment being >> received to date, we'd like to extend the WG more time for review. >> >> These drafts represent significant work by the authors and WG, so please >> review and let the WG know what you think (positive or negative)! >> >> Please have all comments in by October 29. >> >> Thank you, >> Lou (and Deborah) >> >> On 10/1/2013 12:34 PM, Lou Berger wrote: >>> All, >>> >>> This mail begins working group last call on the WSON documents. As >>> there are 6 documents in this set, the last call will be three weeks. >>> The documents included in the last call are: >>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 >>> (Informational, IPR Disclosed) >>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 >>> (Standards Track, IPR Disclosed) >>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 >>> (Standards Track) >>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 >>> (Standards Track, IPR Disclosed) >>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 >>> (Standards Track, IPR Disclosed) >>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards >>> Track) Also has one open issue that will need to be resolved as part of >>> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. >>> >>> This working group last call ends on October 22. Comments should be >>> sent to the CCAMP mailing list. Please remember to include the >>> technical basis for any comments. >>> >>> Positive comments, e.g., "I've reviewed this document and believe it is >>> ready for publication", are welcome! >>> >>> Please note that we're still missing some IPR statements. Any >>> forthcoming publication request will be delayed by late IPR >>> statements/disclosures. >>> >>> >>> Thank you, >>> Lou (and Deborah) >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Wed Oct 30 06:14:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F54111E80E3 for ; Wed, 30 Oct 2013 06:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.989 X-Spam-Level: X-Spam-Status: No, score=-100.989 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmYXUtLQii4I for ; Wed, 30 Oct 2013 06:14:37 -0700 (PDT) Received: from outbound-ss-1235.hostmonster.com (outbound-ss-1235.hostmonster.com [67.20.99.188]) by ietfa.amsl.com (Postfix) with SMTP id 0F93221F9F4F for ; Wed, 30 Oct 2013 06:14:36 -0700 (PDT) Received: (qmail 17196 invoked by uid 0); 30 Oct 2013 13:14:15 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 30 Oct 2013 13:14:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=Og97jOrSBiuhrMDdeVBfe5ElSahRma/wtpEm4j+NGCY=; b=qhcGekVsKmU+ZYyu9mhn7TSOpzm7RF5nbZLuC5o9eZQbZJRJdSpyF9JwsiOKOGW6tQo2jdF66unbYixoMSisBkhBP2ar5jj2Hr6z8ryjb5sUvR/b0UH8nnCnM+XY/MNO; Received: from box313.bluehost.com ([69.89.31.113]:55431 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbVbD-0001WQ-4t for ccamp@ietf.org; Wed, 30 Oct 2013 07:14:15 -0600 Message-ID: <5271061E.8030308@labn.net> Date: Wed, 30 Oct 2013 09:14:06 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: CCAMP References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> In-Reply-To: <5266E138.8080605@labn.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 13:14:41 -0000 The WG last call is complete. Authors, please address all received comments. Lou On 10/22/2013 4:34 PM, Lou Berger wrote: > > All, > Given the recent draft submission deadline and only one comment being > received to date, we'd like to extend the WG more time for review. > > These drafts represent significant work by the authors and WG, so please > review and let the WG know what you think (positive or negative)! > > Please have all comments in by October 29. > > Thank you, > Lou (and Deborah) > > On 10/1/2013 12:34 PM, Lou Berger wrote: >> All, >> >> This mail begins working group last call on the WSON documents. As >> there are 6 documents in this set, the last call will be three weeks. >> The documents included in the last call are: >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 >> (Informational, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21 >> (Standards Track) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12 >> (Standards Track, IPR Disclosed) >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards >> Track) Also has one open issue that will need to be resolved as part of >> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52. >> >> This working group last call ends on October 22. Comments should be >> sent to the CCAMP mailing list. Please remember to include the >> technical basis for any comments. >> >> Positive comments, e.g., "I've reviewed this document and believe it is >> ready for publication", are welcome! >> >> Please note that we're still missing some IPR statements. Any >> forthcoming publication request will be delayed by late IPR >> statements/disclosures. >> >> >> Thank you, >> Lou (and Deborah) >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From adrian@olddog.co.uk Wed Oct 30 16:45:09 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1C411E8145 for ; Wed, 30 Oct 2013 16:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 drutt2ncMByd for ; Wed, 30 Oct 2013 16:45:01 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9EE21E8143 for ; Wed, 30 Oct 2013 16:44:44 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r9UNihA3019519; Wed, 30 Oct 2013 23:44:43 GMT Received: from 950129200 ([213.27.245.161]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r9UNigEG019513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Oct 2013 23:44:43 GMT From: "Adrian Farrel" To: "'CCAMP WG'" References: <0e7601cecf6d$1ec53a70$5c4faf50$@olddog.co.uk> <0e7f01cecf6f$fb2ad1d0$f1807570$@olddog.co.uk> In-Reply-To: <0e7f01cecf6f$fb2ad1d0$f1807570$@olddog.co.uk> Date: Wed, 30 Oct 2013 23:44:41 -0000 Message-ID: <202b01ced5ca$01443380$03cc9a80$@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: AQKmPSb+jhFSzpUJjjc40ISq725v3wHombQimE/UxKA= Content-Language: en-gb Cc: draft-farrel-interconnected-te-info-exchange@tools.ietf.org Subject: Re: [CCAMP] Pump-priming UNI/PCE/ENNI/MLN/... discussion X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 23:45:09 -0000 ...or, if you prefer, keep absolutely silent :-) > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 22 October 2013 22:45 > To: 'CCAMP WG' > Cc: draft-farrel-interconnected-te-info-exchange@tools.ietf.org > Subject: Re: [CCAMP] Pump-priming UNI/PCE/ENNI/MLN/... discussion > > Sorry! > > Lou quite correctly points out that I should say... > > This is not your AD directing how business in the WG should be done, nor at what > outcome the WG should arrive with consensus. > > I am just being a humble co-author on a document that is not even a WG > document. > > If you all want to tell me I am mad or don't understand networks, that will not > only be your right, but will be quite refreshing. If you have other ideas about > how to arrange the discussion, go right ahead and tell me I am wrong or that you > prefer to do it different. > > Adrian > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > > Adrian Farrel > > Sent: 22 October 2013 22:25 > > To: 'CCAMP WG' > > Cc: draft-farrel-interconnected-te-info-exchange@tools.ietf.org > > Subject: [CCAMP] Pump-priming UNI/PCE/ENNI/MLN/... discussion > > > > Hi, > > > > Now that the draft agenda is out for CCAMP in Vancouver it is worth stirring > up > > a little discussion to see whether we can arrive in British Columbia with some > > things ironed out and some ideas we want to dig into deeper. > > > > A bunch of us have been working on a draft to summarise the problems and > > propose > > an architecture. See the latest version at > > http://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange-02 > > > > It might be helpful to break the discussion into consideration of the problem > > statement first. Do we have any disagreement about the scope, the type of > > network we need to solve, and the functions we need to deliver. That should > > take you up to the end of Section 3. > > > > Then, as a separate discussion, perhaps we can get into the architecture. From > a > > broad high level, does it do what we want/need? Yes, there are some wrinkles > > and > > nits to be sorted out in the details. That should cover section 5. > > > > Finally, can we use the architecture to do useful things. That will be > sections > > 7 and (oops) 8. > > > > Really looking forward to hearing people's opinions. > > > > Thanks, > > Adrian > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Thu Oct 31 14:00:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EDC11E8110 for ; Thu, 31 Oct 2013 14:00:06 -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=-1.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz0rIzDrvh8t for ; Thu, 31 Oct 2013 14:00:01 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA6A21F9DAD for ; Thu, 31 Oct 2013 13:59:56 -0700 (PDT) X-AuditID: c1b4fb38-b7faa8e000004f6c-01-5272569ab97f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E9.03.20332.A9652725; Thu, 31 Oct 2013 14:09:47 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.27]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 31 Oct 2013 14:09:46 +0100 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" Thread-Topic: IETF 88 - CCAMP agenda requests Thread-Index: Ac7A62fizl6s11uwRBqP7yxjH/V66QVTrLrQ Date: Thu, 31 Oct 2013 13:09:46 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48180CBC@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4815CE4D@ESESSMB301.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.20] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48180CBCESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7ssKIggwsbOCyezLnBYnG5q5vd oqP5LYsDs8fL/jmMHkuW/GTy+LCpmS2AOYrLJiU1J7MstUjfLoEr43H7JOaCXb2MFTtfrGFs YHxX08XIySEhYCJx5GEHO4QtJnHh3nq2LkYuDiGBI4wS/77tYARJCAksZpRYtcypi5GDg03A SuLJIR+QsIiArsTejdeZQWxmgWqJE7u3M4GUCAvoSLzfLQ9TcuRxLxOEbSTx4us8sBIWAVWJ KxuqQcK8At4Sr07fYINY5C3xbNEOMJtTwEdi3YG7YAcwCshKTNi9iBFik7jErSfzmSAuFpBY suc8M4QtKvHy8T9WCFtR4ur05UwQ9fkS6zcsY4PYJShxcuYTlgmMorOQjJqFpGwWkjKIuJ7E jalT2CBsbYllC18zQ9i6EjP+HWJBFl/AyL6KkaM4tTgpN93IYBMjMMoObvltsYPx8l+bQ4zS HCxK4rwf3zoHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDcNvH2BJZ9i169Csh9ojtnWb2E 5pKz/E2Bgr8Fdb+FPHfOXT+r/+DW/RP8z6yQFKw1d52lv/eWUINNDd/Tpacftnfs3rfn4PXy 5oUJfqVLvt4JYt1g9mPvGU4Gw6tXI25PyzatkFSbsc89VP3nhJZHHG8KS88ot9UHfTkQt+NY yJylBoJz1rE1K7EUZyQaajEXFScCAJfG0XCAAgAA Subject: Re: [CCAMP] IETF 88 - CCAMP agenda requests X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:00:06 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48180CBCESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Friendly reminder for presenters! Presentations: If you are presenting slides please make sure you send them to all *indi= viduals* listed above (Chairs, Secretary and exclude CCAMP) no later than = Sunday, November 3. Moreover, please remember the guidelines for overlay session presentations 1) What do we expect to be presented during this discussion? As discussed in the original message, we expected presentations on use cases that are precluded from being fully supported by the current set of RFCs, as well as the identification of specific limitations that preclude full support. The presenter gets to choose & defend what they mean by (full) support. 2) Who do we expect to present? Anyone who has a draft that covers a use case, identifies a limitation, or proposes a related extension (mechanism). For those in the last category, remember to present your use case and limitations, *not* the proposed solution. BR Daniele From: Daniele Ceccarelli Sent: venerd=EC 4 ottobre 2013 12:31 To: CCAMP (ccamp@ietf.org) Cc: Lou Berger (lberger@labn.net); BRUNGARD, DEBORAH A (ATTLABS) (db3546@at= t.com); Daniele Ceccarelli Subject: IETF 88 - CCAMP agenda requests Dear CCAMP, IETF 88 meeting is approaching and it's time to start collecting agenda slo= ts requests. Keeping this in mind: Authors of active working group documents should plan on presenting status = (briefly, including recent changes), open issues/discussion topics and plan= ned next steps at the meeting. Alternatively, an update can be provided vi= a e-mail to the list in the *week prior* to the meeting. Agenda Requests: - To submit a request, please fill the survey at the following link: http:/= /www.surveymonkey.com/s/QLK9BB6 - Please fill the survey no later than Sunday, October 20. Presentations: If you are presenting slides please make sure you send them to all *indi= viduals* listed above (Chairs, Secretary and exclude CCAMP) no later than = Sunday, November 3. Reminder about a few important dates: * 2013-10-21 (Monday): Internet Draft submission cut-off (for all draft= s, including -00) by UTC 24:00, upload using IETF ID Submission Tool. * 2013-10-23 (Wednesday): Draft Working Group agendas due by UTC 24:00,= upload using IETF Meeting Materials Management Tool. * 2013-10-28 (Monday): Revised Working Group agendas due by UTC 24:00, = upload using IETF Meeting Materials Management Tool. * 2013-11-03 - 2013-11-08: 88th IETF Meeting in Vancouver, BC, Canada. BR Daniele & CCAMP chairs --_000_4A1562797D64E44993C5CBF38CF1BE48180CBCESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Friendly reminder for = presenters!

 

Presentations:

  If you are presenting slides please make s= ure you send them to  all *individuals* listed above (Chairs, Secretar= y and exclude CCAMP) no later  than Sunday, November 3.

 

Moreover, please remem= ber the guidelines for overlay session presentations

 

1) What do we expect to be presented during this = discussion?

 

   As discussed in the original message= , we expected presentations

   on use cases that are precluded from= being fully supported by the

   current set of RFCs, as well as the = identification of specific

   limitations that preclude full suppo= rt. The presenter gets to

   choose & defend what they mean b= y (full) support.

 

2) Who do we expect to present?

 

   Anyone who has a draft that covers a= use case, identifies a

   limitation, or proposes a related ex= tension (mechanism).  For

   those in the last category, remember= to present your use case

   and limitations, *not* the proposed = solution.

 

BR

Daniele

 

 

 

From: Daniele = Ceccarelli
Sent: venerd=EC 4 ottobre 2013 12:31
To: CCAMP (ccamp@ietf.org)
Cc: Lou Berger (lberger@labn.net); BRUNGARD, DEBORAH A (ATTLABS) (db= 3546@att.com); Daniele Ceccarelli
Subject: IETF 88 - CCAMP agenda requests

 

Dear CCAMP,

 

IETF 88 meeting is approaching and it’s time t= o start collecting agenda slots requests.

 

Keeping this in mind:

Authors of active working group documents should = plan on presenting status (briefly, including recent changes), open issues/= discussion topics and planned next steps at the meeting.  Alternativel= y, an update can be provided via e-mail to the list in the *week prior* to the meeting.

 

Agenda Requests:

- To submit a request, please fill the sur= vey at the following link: http://www.surveymonkey.c= om/s/QLK9BB6

- Please fill the survey no later than Sunday,= October 20.

 

Presentations:

  If you are presenting slides please make s= ure you send them to  all *individuals* listed above (Chairs, Secretar= y and exclude CCAMP) no later  than Sunday, November 3.

 

Reminder about a few important dates:

BR

Daniele & CCAMP cha= irs

 

--_000_4A1562797D64E44993C5CBF38CF1BE48180CBCESESSMB301ericsso_--