From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 1 00:20:43 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28590 for ; Fri, 1 Nov 2002 00:20:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.007A1AFB@cherry.ease.lsoft.com>; Fri, 1 Nov 2002 0:23:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 304727 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 1 Nov 2002 00:23:03 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 1 Nov 2002 00:23:03 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 7118BCAB6A for ; Thu, 31 Oct 2002 21:23:01 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DC20FA5.6010608@redback.com> Date: Fri, 1 Nov 2002 00:22:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF Hitless Restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit In working toward the goal of getting to WG last call for this document, I've incorporated many of your comments. I tried to include items that made sense and were not a radical departure from John's original draft. Here is an excerpt from the change log: Changes from 03 to 04 version: 1. Add change log (Appendix B). 2. Document that the grace period is restricted to LSRefreshTime (Section 2.1). 3. Document an alternative to saving cryptographic sequence numbers in non-volatile storage (Section 2.1). 4. Document that an implementation may disable graceful restart helper termination when the link-state database changes (Section 3.2). 5. In the case of an unplanned restart, document that grace LSAs should be flooded to AllSPFRouters on broadcast networks (Section 5). 6. Remove MOSPF from future work. Add Vishwas's suggested technique for less conservative helper mode termination as possible future work (Section 7). 7. Change references and citations to meet prevailing IETF standards. I have not incorporated Padma's suggested change that the grace LSA apply to all neighbor adjacencies with the router ID of the restarting router. In a nutshell, here are the arguments for making the change versus leaving the document as is: Arguments for changing the behavior so that reception of a grace LSA for router ID X causes a router to enter helper mode for all neighbor adjacencies with router X. 1. Restart applies to the OSPF process so the grace LSA should be applied to all neighbor adjacencies for the restarting router. 2. Slighty better chance that grace LSA originations and purges will be received by a helping router with multiple adjacencies. Arguments for leaving the document as is with the grace LSA applying only to neighbor adjacencies on the link received. 1. Since the grace LSA is link local scope, it is more consistent to apply it only to neighbor adjacencies on that link. 2. Simplifies changes to grace LSA TLVs. The current draft just states that new TLV values (grace LSA and reason) replace the old ones. The rules for handling differences would need to be defined and would be more complex. 3. Slightly less overhead when a grace LSA is received since you don't have to search through all your neighbor adjacencies looking for the restart router ID (although there may be other reasons to maintain these parallel adjacencies in a separate list ;^). All in all, there doesn't appear to be that compelling an argument of one approach over the other. I would have been inclined to reject the change had Padma not felt so strongly. One thing I am strongly against is trying to define determiniation of which of multiple instances of *different* LSAs is more recent - we just don't want to go there. Please voice your opinions on the list of changes and the last issue. The 03 version of the draft is available: http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-03.txt I don't intend to post the complete 04 version to the list or re-spin it for a while. ----- Thanks, Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 1 14:23:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29951 for ; Fri, 1 Nov 2002 14:23:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.007A38CE@cherry.ease.lsoft.com>; Fri, 1 Nov 2002 14:25:24 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307120 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 1 Nov 2002 14:25:24 -0500 Received: from 66.51.65.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 1 Nov 2002 14:15:24 -0500 Received: from BLUEAZ2Y4F1H6R (162-84-51-66.reonbroadband.com [66.51.84.162]) by kona.reonbroadband.com (8.9.3/8.8.7) with SMTP id OAA22106; Fri, 1 Nov 2002 14:15:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Message-ID: Date: Fri, 1 Nov 2002 14:16:43 -0500 Reply-To: Mailing List Sender: Mailing List From: Steve Mastrorilli To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Does anyone know what the percentage breakdown is of OSPF vs. xGRP (IGRP & EIGRP) networks US or worldwide? I realize there may be some RIP, RIPv2, etc. but I am assuming that there probably isn't as much of those networks as OSPF or xIGRP. Thanks From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 1 15:53:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03888 for ; Fri, 1 Nov 2002 15:53:19 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.007A3CC0@cherry.ease.lsoft.com>; Fri, 1 Nov 2002 15:55:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307317 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 1 Nov 2002 15:55:41 -0500 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 1 Nov 2002 15:45:40 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA1CxFB8004949 for ; Fri, 1 Nov 2002 14:45:40 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B560500DABF99 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 1 Nov 2002 15:45:39 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C281E7.A317630A" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: yes Thread-Topic: New Internet Draft Submission Thread-Index: AcKB5WNbOMEokuqDEdaixgDAT2iu5gAAAamw Message-ID: <28F05913385EAC43AF019413F674A017023F6838@OCCLUST04EVS1.ugd.att.com> Date: Fri, 1 Nov 2002 15:45:39 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALASO" Subject: New Internet Draft on Flooding Simulation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C281E7.A317630A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have just submitted the attached Internet draft = "draft-choudhury-manral-flooding-simulation-00.txt". Please give us = comments electronically and during the OSPF WG meeting at Atlanta. The = Title and abstract are given below. Gagan Choudhury=20 Vishwas Manral <>=20 Title: LSA Flooding Optimization Algorithms and Their Simulation Study Abstract: The full flooding of LSAs in OSPF may cause large CPU and = memory consumption at node processors of a network with large number of nodes, links, adjacencies per node and LSDB size. An LSA storm, defined as =20 the near-simultaneous update of a large number of LSAs, in such =20 networks may cause network instability and outage. We do a simulation study of four alternative algorithms to full=20 flooding to determine their ability to handle large LSA storms. Algorithm 2 does full flooding but in case two neighbors are connected by multiple interfaces, flooding is done over only one such interface. The other algorithms are based on Algorithm 2 and employ further flooding restrictions. In Algorithm 3 each node asks only a subset of its one-hop neighbors, known as multipoint relays, to flood further. In Algorithm 4 flooding is done only over a minimum spanning tree. Algorithm 5 uses full flooding (as in Algorithm 2) for LSAs carrying intra-area topology information and restricted flooding over a minimum spanning tree (as in Algorithm 4) for other LSAs. In terms of handling large LSA storms and in terms of robustness under link failures, it appears that Algorithms 2 and 5 are the most=20 desirable ones and it is proposed that they be pursued further. =20 ------_=_NextPart_001_01C281E7.A317630A Content-Type: text/plain; name="draft-choudhury-manral-flooding-simulation-00.txt" Content-Description: draft-choudhury-manral-flooding-simulation-00.txt Content-Disposition: attachment; filename="draft-choudhury-manral-flooding-simulation-00.txt" Content-Transfer-Encoding: base64 DQogICBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAgICBHYWdh biBMLiBDaG91ZGh1cnkNCiAgIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEFUJlQNCiAgIEV4cGlyZXMgaW4gTWF5LCAyMDAzICAgICAgICAgICAgICAgICAg ICAgICAgDQogICBkcmFmdC1jaG91ZGh1cnktbWFucmFsLWZsb29kaW5nLXNpbXVsYXRpb24tMDAu dHh0ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBWaXNod2FzIE1hbnJhbA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTmV0cGxhbmUgU3lzdGVtcw0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3ZlbWJlciwgMjAwMg0KDQoNCiAgTFNB IEZsb29kaW5nIE9wdGltaXphdGlvbiBBbGdvcml0aG1zIGFuZCBUaGVpciBTaW11bGF0aW9uIFN0 dWR5DQoNCg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4g SW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2UNCiAgIHdpdGggYWxsIHBy b3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMg YXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFz ayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUg dGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4DQogICBtb250aHMgYW5kIG1h eSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cw0K ICAgYXQgYW55IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFm dHMgYXMNCiAgIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBh cyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQt RHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ll dGYvMWlkLWFic3RyYWN0cy50eHQNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRv dyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9zaGFkb3cuaHRtbC4NCiAgIERpc3RyaWJ1dGlvbiBvZiB0aGlzIG1lbW8gaXMgdW5saW1p dGVkLg0KDQoNCkFic3RyYWN0DQoNClRoZSBmdWxsIGZsb29kaW5nIG9mIExTQXMgaW4gT1NQRiBt YXkgY2F1c2UgbGFyZ2UgQ1BVIGFuZCBtZW1vcnkNCmNvbnN1bXB0aW9uIGF0IG5vZGUgcHJvY2Vz c29ycyBvZiBhIG5ldHdvcmsgd2l0aCBsYXJnZSBudW1iZXIgb2Ygbm9kZXMsDQpsaW5rcywgYWRq YWNlbmNpZXMgcGVyIG5vZGUgYW5kIExTREIgc2l6ZS4gIEFuIExTQSBzdG9ybSwgZGVmaW5lZCBh cyAgDQp0aGUgbmVhci1zaW11bHRhbmVvdXMgdXBkYXRlIG9mIGEgbGFyZ2UgbnVtYmVyIG9mIExT QXMsIGluIHN1Y2ggIA0KbmV0d29ya3MgbWF5IGNhdXNlIG5ldHdvcmsgaW5zdGFiaWxpdHkgYW5k IG91dGFnZS4NCg0KV2UgZG8gYSBzaW11bGF0aW9uIHN0dWR5IG9mIGZvdXIgYWx0ZXJuYXRpdmUg YWxnb3JpdGhtcyB0byBmdWxsIA0KZmxvb2RpbmcgdG8gZGV0ZXJtaW5lIHRoZWlyIGFiaWxpdHkg dG8gaGFuZGxlIGxhcmdlIExTQSBzdG9ybXMuDQpBbGdvcml0aG0gMiBkb2VzIGZ1bGwgZmxvb2Rp bmcgYnV0IGluIGNhc2UgdHdvIG5laWdoYm9ycyBhcmUgY29ubmVjdGVkDQpieSBtdWx0aXBsZSBp bnRlcmZhY2VzLCBmbG9vZGluZyBpcyBkb25lIG92ZXIgb25seSBvbmUgc3VjaCBpbnRlcmZhY2Uu DQpUaGUgb3RoZXIgYWxnb3JpdGhtcyBhcmUgYmFzZWQgb24gQWxnb3JpdGhtIDIgYW5kIGVtcGxv eQ0KZnVydGhlciBmbG9vZGluZyByZXN0cmljdGlvbnMuIEluIEFsZ29yaXRobSAzIGVhY2ggbm9k ZSBhc2tzIG9ubHkNCmEgc3Vic2V0IG9mIGl0cyBvbmUtaG9wIG5laWdoYm9ycywga25vd24gYXMg bXVsdGlwb2ludCByZWxheXMsIHRvDQpmbG9vZCBmdXJ0aGVyLiBJbiBBbGdvcml0aG0gNCBmbG9v ZGluZyBpcyBkb25lIG9ubHkgb3ZlciBhDQoNCg0KIENob3VkaHVyeSBldC4gYWwuICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KIEludGVybmV0 IERyYWZ0ICAgICAgICAgICAgIEZsb29kaW5nIFNpbXVsYXRpb24gICAgICAgICAgICAgIE1heSwg MjAwMw0KDQoNCm1pbmltdW0gc3Bhbm5pbmcgdHJlZS4gQWxnb3JpdGhtIDUgdXNlcyBmdWxsIGZs b29kaW5nIChhcyBpbiBBbGdvcml0aG0NCjIpIGZvciBMU0FzIGNhcnJ5aW5nIGludHJhLWFyZWEg dG9wb2xvZ3kgaW5mb3JtYXRpb24gYW5kIHJlc3RyaWN0ZWQNCmZsb29kaW5nIG92ZXIgYSBtaW5p bXVtIHNwYW5uaW5nIHRyZWUgKGFzIGluIEFsZ29yaXRobSA0KSBmb3Igb3RoZXINCkxTQXMuDQoN CkluIHRlcm1zIG9mIGhhbmRsaW5nIGxhcmdlIExTQSBzdG9ybXMgYW5kIGluIHRlcm1zIG9mIHJv YnVzdG5lc3MgdW5kZXINCmxpbmsgZmFpbHVyZXMsIGl0IGFwcGVhcnMgdGhhdCBBbGdvcml0aG1z IDIgYW5kIDUgYXJlIHRoZSBtb3N0IA0KZGVzaXJhYmxlIG9uZXMgYW5kIGl0IGlzIHByb3Bvc2Vk IHRoYXQgdGhleSBiZSBwdXJzdWVkIGZ1cnRoZXIuICAgICAgICAgDQoNCg0KMS4gSW50cm9kdWN0 aW9uDQoNCkluIE9TUEYsIExTQXMgKExpbmstU3RhdGUtQWR2ZXJ0aXNlbWVudHMpIHJlY2VpdmVk IGF0IGEgbm9kZSANCihyb3V0ZXIpIGFyZSBmbG9vZGVkIG92ZXIgYWxsIGludGVyZmFjZXMgZXhj ZXB0IHRoZSBvbmUgaXQgY2FtZSBvdmVyLg0KVGhpcyBmdWxsIGZsb29kaW5nIGFkZHMgYSBsb3Qg b2YgcmVkdW5kYW5jeSBhbmQgZW5zdXJlcyB0aGF0IExTQXMgZG8gDQpyZWFjaCBhbGwgaW50ZW5k ZWQgZGVzdGluYXRpb25zIHJlbGlhYmx5IGFuZCBxdWlja2x5LiBIb3dldmVyLCB0aGlzICANCm1h eSBhbHNvIGNvbnN1bWUgYSBsYXJnZSBhbW91bnQgb2YgQ1BVIGFuZCBtZW1vcnkgcmVzb3VyY2Vz IGF0IHRoZSANCm5vZGUgcHJvY2Vzc29ycyBvZiBhIGxhcmdlIG5ldHdvcmsgKGxhcmdlbmVzcyBp biB0ZXJtcyBvZiBudW1iZXIgb2YgDQpub2RlcywgbnVtYmVyIG9mIGxpbmtzLCBhZGphY2VuY2ll cyBwZXIgbm9kZSwgYW5kIExTQSBEYXRhYmFzZSBzaXplKS4NCg0KVGhpcyBpcyBwYXJ0aWN1bGFy bHkgdHJ1ZSBpbiB0aGUgY2FzZSBvZiBhIExTQSBzdG9ybSwgd2hpY2ggd2UgZGVmaW5lIA0KYXMg dGhlIHNpbXVsdGFuZW91cyBvciBuZWFyLXNpbXVsdGFuZW91cyB1cGRhdGUgb2YgYSBsYXJnZSBu dW1iZXIgb2YgDQpMU0FzLiAgQW4gTFNBIHN0b3JtIG1heSBiZSBjYXVzZWQgYnkgKGEpIG9uZSBv ciBtb3JlIGxpbmsgZmFpbHVyZXMgZHVlIA0KdG8gZmliZXIgY3V0cywgKGIpIG9uZSBvciBtb3Jl IG5vZGUgZmFpbHVyZXMgZm9yIHNvbWUgcmVhc29uLCBlLmcuLCANCnNvZnR3YXJlIGNyYXNoIG9y IHNvbWUgdHlwZSBvZiBkaXNhc3RlciBpbiBhbiBvZmZpY2UgY29tcGxleCBob3N0aW5nIA0KbWFu eSBub2RlcywgKGMpIHJlcXVpcmVtZW50IG9mIHRha2luZyBkb3duIGFuZCBsYXRlciBicmluZ2lu ZyBiYWNrIA0KbWFueSBub2RlcyBkdXJpbmcgYSBzb2Z0d2FyZS9oYXJkd2FyZSB1cGdyYWRlLCAo ZCkgbmVhci0NCnN5bmNocm9uaXphdGlvbiBvZiB0aGUgb25jZS1pbi0zMC1taW51dGVzIHJlZnJl c2ggaW5zdGFudHMgb2YgYSBzdWJzZXQNCm9mIHRoZSBMU0FzLCAoZSkgcmVmcmVzaCBvZiBhbGwg TFNBcyBpbiB0aGUgc3lzdGVtIGR1cmluZyBhIGNoYW5nZSBpbg0Kc29mdHdhcmUgdmVyc2lvbi4g IA0KDQpJZiB0aGUgQ1BVIHV0aWxpemF0aW9uIGF0IGEgbm9kZSBzdGF5cyBoaWdoIGZvciBhIA0K bG9uZyB0aW1lIHRoZW4gdGhhdCBtYXkgcmVzdWx0IGluIG1hbnkgcmV0cmFuc21pc3Npb25zIChy ZXRyYW5zbWlzc2lvbiANCnRpbWVyIGlzIHR5cGljYWxseSA1IHNlY29uZHMpIGFuZCBtYXkgYWxz byByZXN1bHQgaW4gbGlua3MgYmVpbmcgDQpkZWNsYXJlZCBkb3duIGR1ZSB0byBtaXNzZWQgSGVs bG8gcGFja2V0cyAoUm91dGVyLURlYWQgaW50ZXJ2YWwgaXMgDQp0eXBpY2FsbHkgNDAgc2Vjb25k cykuICBUaGUgYWJvdmUgZXZlbnRzIHdvdWxkIGJlIHJlaW5mb3JjZWQgaW4gdGhlIA0KY2FzZSBv ZiBoZWF2eSBtZW1vcnkgdXRpbGl6YXRpb24gYW5kIGRyb3BwZWQgcGFja2V0cy4gIElmIGEgbGlu ayBpcyANCmRlY2xhcmVkIGRvd24gdGhlbiB0aGF0IHdvdWxkIGdlbmVyYXRlIGFkZGl0aW9uYWwg TFNBcyB0byBjYXJyeSB0aGUgDQpsaW5rLWRvd24gaW5mb3JtYXRpb24gYW5kIGlmIGl0IHJlc3Vs dHMgaW4gcmVyb3V0aW5nIG9mIE1QTFMgTFNQcyB0aGVuIA0KdGhhdCBtYXkgZ2VuZXJhdGUgZnVy dGhlciBMU0FzIGNhcnJ5aW5nIHRyYWZmaWMtZW5naW5lZXJpbmcgaW5mb3JtYXRpb24uICANCkV2 ZW50dWFsbHkgd2hlbiB0aGUgbGluayBjb21lcyBiYWNrIHVwLCBmdXJ0aGVyIExTQXMgd291bGQg YmUgZ2VuZXJhdGVkDQphZ2FpbiB0byBjYXJyeSB0aGUgbGluay11cCBpbmZvcm1hdGlvbiBhbmQg cG90ZW50aWFsbHkgTFNBcyBjYXJyeWluZyANCnRyYWZmaWMtZW5naW5lZXJpbmcgaW5mb3JtYXRp b24gZHVlIHRvIGEgcG9zc2libGUgcmVyb3V0ZSBvZiBNUExTIExTUHMuDQoNClRoZSByZXRyYW5z bWlzc2lvbnMgYW5kIGFkZGl0aW9uYWwgTFNBIGdlbmVyYXRpb25zIHJlc3VsdCBpbiBmdXJ0aGVy IA0KQ1BVIGFuZCBtZW1vcnkgdXNhZ2UsIGVzc2VudGlhbGx5IGNhdXNpbmcgYSBwb3NpdGl2ZSBm ZWVkYmFjayBsb29wLiAgDQpXZSBkZWZpbmUgdGhlIExTQSBzdG9ybSBzaXplIGFzIHRoZSBudW1i ZXIgb2YgTFNBcyBpbiB0aGUgb3JpZ2luYWwgDQpzdG9ybSBhbmQgbm90IGNvdW50aW5nIGFueSBh ZGRpdGlvbmFsIExTQXMgcmVzdWx0aW5nIGZyb20gdGhlIGZlZWRiYWNrIA0KbG9vcCBkZXNjcmli ZWQgYWJvdmUuICBJZiB0aGUgTFNBIHN0b3JtIGlzIHRvbyBsYXJnZSB0aGVuIHRoZSBwb3NpdGl2 ZSANCg0KDQogQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgRmxv b2RpbmcgU2ltdWxhdGlvbiAgICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0KZmVlZGJhY2sgbG9v cCBtZW50aW9uZWQgYWJvdmUgbWF5IGJlIGxhcmdlIGVub3VnaCB0byBpbmRlZmluaXRlbHkgDQpz dXN0YWluIGEgbGFyZ2UgQ1BVIGFuZCBtZW1vcnkgdXRpbGl6YXRpb24gYXQgbWFueSBuZXR3b3Jr IG5vZGVzLCANCnRoZXJlYnkgZHJpdmluZyB0aGUgbmV0d29yayB0byBhbiB1bnN0YWJsZSBzdGF0 ZS4gIA0KDQpJbiB0aGUgcGFzdCwgbmV0d29yaw0Kb3V0YWdlIGV2ZW50cyBoYXZlIGJlZW4gcmVw b3J0ZWQgaW4gSVAgYW5kIEFUTSBuZXR3b3JrcyB1c2luZyANCmxpbmstc3RhdGUgcHJvdG9jb2xz IHN1Y2ggYXMgT1NQRiwgSVMtSVMsIFBOTkkgb3Igc29tZSBwcm9wcmlldGFyeSANCnZhcmlhbnRz LiAgU2VlLCBmb3IgZXhhbXBsZSBbUmVmMS1SZWY0XS4gIEluIG1hbnkgb2YgdGhlc2UgZXhhbXBs ZXMsDQpsYXJnZSBzY2FsZSBmbG9vZGluZyBvZiBMU0FzIG9yIG90aGVyIHNpbWlsYXIgY29udHJv bCBtZXNzYWdlcyAoZWl0aGVyDQpuYXR1cmFsbHkgb3IgdHJpZ2dlcmVkIGJ5IHNvbWUgYnVnIG9y IGluYXBwcm9wcmlhdGUgcHJvY2VkdXJlKSBoYXZlDQpiZWVuIHBhcnRseSBvciBmdWxseSByZXNw b25zaWJsZSBmb3IgbmV0d29yayBpbnN0YWJpbGl0eSBhbmQgb3V0YWdlLiANCg0KSW4gdGhpcyBj b250cmlidXRpb24gd2UgY29uc2lkZXIgc2V2ZXJhbCBhbHRlcm5hdGl2ZXMgdG8gdGhlIGJhc2lj IGZ1bGwgDQpmbG9vZGluZyBhbGdvcml0aG0gaW4gb3JkZXIgdG8gc2lnbmlmaWNhbnRseSBpbmNy ZWFzZSB0aGUgTFNBIHN0b3JtIA0KdGhyZXNob2xkIHRoYXQgY2FuIGNhdXNlIG5ldHdvcmsgaW5z dGFiaWxpdHkuIElkZWFsbHksIHRoZSBMU0Egc3Rvcm0gDQp0aHJlc2hvbGQgc2hvdWxkIGJlIHRo ZSBzYW1lIGFzIHRoZSBmdWxsIExTREIgKExTQSBEYXRhYmFzZSkgc2l6ZSBzaW5jZSANCm5vcm1h bGx5IHRoaXMgaXMgdGhlIHVwcGVyIGxpbWl0IG9mIHRoZSBudW1iZXIgb2YgTFNBcyB0aGF0IGNh biBiZSANCnByZXNlbnQgaW4gYSBMU0Egc3Rvcm0uDQoNCk9uZSBvZiB0aGUgYWxnb3JpdGhtcyB3 ZSBjb25zaWRlciBpcyBzaW1pbGFyIGluIHNwaXJpdCB0byBmbG9vZGluZyANCm9wdGltaXphdGlv biBtZWNoYW5pc21zIHByb3Bvc2VkIGluIHRoZSBwYXN0IFtSZWY1LFJlZjZdLiBBbHNvLCBvdXIN CndvcmsgaXMgc3luZXJnaXN0aWMgd2l0aCBhIGJyb2FkZXIgc2V0IG9mIHNjYWxhYmlsaXR5IGFu ZCBzdGFiaWxpdHkgDQppbXByb3ZlbWVudCBwcm9wb3NhbHMuIFtSZWY3XSBwcm9wb3NlcyBhIG1l Y2hhbmlzbSBmb3IgZ3JlYXRseSANCnJlZHVjaW5nIExTQSByZWZyZXNoZXMgaW4gc3RhYmxlIHRv cG9sb2dpZXMuIFtSZWY4XSBwcm9wb3Nlcw0KcHJpb3JpdGl6YXRpb24gb2YgY2VydGFpbiBjcml0 aWNhbCBPU1BGIHBhY2tldHMgKGUuZy4sIEhlbGxvcyBhbmQgDQpMU0EgQWNrbm93bGVkZ2VtZW50 cykgaW4gb3JkZXIgdG8gZW5zdXJlIHRoYXQgbGlua3MgYXJlIG5vdCBkZWNsYXJlZA0KZG93biBk dWUgdG8gbWlzc2VkIGhlbGxvcyBhbmQgcmV0cmFuc21pc3Npb24gdHJhZmZpYyBpcyByZWR1Y2Vk DQpkdXJpbmcgcGVyaW9kcyBvZiBjb25nZXN0aW9uLiBbUmVmOV0gcHJvcG9zZXMgYSB3aWRlIHJh bmdlIG9mIA0KY29uZ2VzdGlvbiBjb250cm9sIGFuZCBmYWlsdXJlIHJlY292ZXJ5IG1lY2hhbmlz bXMuICAgDQogIA0KDQoyLiBUaGUgRmxvb2RpbmcgQWxnb3JpdGhtcw0KDQpBbGwgYWxnb3JpdGht cyB3ZSBkZXNjcmliZSBpbiB0aGlzIFNlY3Rpb24gYXJlIGFwcGxpY2FibGUgdG8gYSBzaW5nbGUg DQpPU1BGIEFyZWEuICBJZiB0aGVyZSBhcmUgbXVsdGlwbGUgYXJlYXMgdGhlbiB0aGUgc2FtZSBm bG9vZGluZyANCmFsZ29yaXRobSBtYXkgYmUgcnVuIGluZGVwZW5kZW50bHkgYW5kIGluIHBhcmFs bGVsIHdpdGhpbiBlYWNoIGFyZWEuDQoNCg0KQWxnb3JpdGhtIDEgKEZ1bGwgRmxvb2RpbmcpOiBM U0FzIGFyZSBmbG9vZGVkIG92ZXIgYWxsIGludGVyZmFjZXMganVzdA0KYXMgaW4gUkZDIDIzMjgu DQoNCg0KQWxnb3JpdGhtIDIgKEZsb29kaW5nIG92ZXIgb25lIG9mIG1hbnkgcGFyYWxsZWwgbGlu a3MgYmV0d2VlbiANCm5laWdoYm9ycyk6IElmIHR3byByb3V0ZXJzIGFyZSBjb25uZWN0ZWQgYnkg bXVsdGlwbGUgcGFyYWxsZWwgcG9pbnQtDQp0by1wb2ludCBsaW5rcyB0aGVuIGZsb29kaW5nIGlz IGRvbmUgb3ZlciBvbmx5IG9uZSBzdWNoIGxpbmsuICBJZiB0aGUgDQpsaW5rIGRlc2lnbmF0ZWQg Zm9yIGZsb29kaW5nIGdvZXMgZG93biBhbmQgYXQgbGVhc3Qgb25lIG90aGVyIHBhcmFsbGVsIA0K bGluayBpcyBzdGlsbCB1cCB0aGVuIGEgZGlmZmVyZW50IHBhcmFsbGVsIGxpbmsgaXMgZGVzaWdu YXRlZCBmb3IgDQpmbG9vZGluZy4gIE1lY2hhbmlzbXMgc2ltaWxhciBpbiBzcGlyaXQgdG8gdGhp cyB3ZXJlIHByb3Bvc2VkIGluIA0KW1JlZjUsUmVmNl0uIFBOTkksIGEgTGluay1zdGF0ZSBwcm90 b2NvbCANCg0KDQogQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAg Rmxvb2RpbmcgU2ltdWxhdGlvbiAgICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0KdXNlZCBpbiBB VE0gbmV0d29ya3MgYWxzbyB1c2VzIGEgc2ltaWxhciBtZWNoYW5pc20gW1JlZjEwXS4gIA0KDQoo SXQgaXMgYWxzbyB0byBiZQ0Kbm90ZWQgdGhhdCBvdGhlciB2YXJpYW50cyBhcmUgcG9zc2libGUu ICBGb3IgZXhhbXBsZSwgTFNBcyBtYXkgYmUgDQpzY2hlZHVsZWQgZm9yIHRyYW5zbWlzc2lvbiBv dmVyIGFsbCBpbnRlcmZhY2VzIHRvIGEgbmVpZ2hib3IgYnV0IHdpdGgNCnJhbmRvbSBkZWxheXMg YW5kIGFzIHNvb24gYXMgYW4gYWNrbm93bGVkZ2VtZW50IGlzIHJlY2VpdmVkLCB0aGUNCnJlbWFp bmluZyB0cmFuc21pc3Npb25zIGFyZSBkaXNhYmxlZC4gRm9yIHRoZSBwdXJwb3NlIG9mIHNpbXVs YXRpb24NCndlIHN0aWNrIHRvIHRoZSBiYXNpYyBtZWNoYW5pc20gZGVzY3JpYmVkIGJ5IHRoZSBm aXJzdCB0d28NCnNlbnRlbmNlcyBvZiB0aGUgYWxnb3JpdGhtIGRlc2NyaXB0aW9uKSAgICAgDQoN Cg0KQWxnb3JpdGhtIDMgKEZsb29kaW5nIG92ZXIgb25lIG9mIG1hbnkgcGFyYWxsZWwgbGlua3Mg YmV0d2VlbiANCm5laWdoYm9ycyBwbHVzIE11bHRpcG9pbnQgUmVsYXlzKTogIEluIGFkZGl0aW9u IHRvIHRoZSBmbG9vZGluZyANCnJlc3RyaWN0aW9ucyBpbiBBbGdvcml0aG0gMiAoaS5lLiwgaWYg dGhlcmUgYXJlIG11bHRpcGxlIHBhcmFsbGVsIA0KbGlua3MgdG8gYW4gaW1tZWRpYXRlIG5laWdo Ym9yIHRoZW4gb25seSBvbmUgaXMgdXNlZCBmb3IgZmxvb2RpbmcpLCANCndlIGFsc28gaW50cm9k dWNlIGEgZnVydGhlciByZXN0cmljdGlvbiBieSB1c2luZyB0aGUgZGlzdHJpYnV0ZWQgDQptdWx0 aXBvaW50IHJlbGF5IG1lY2hhbmlzbS4gIEZvciBhIGdpdmVuIG5vZGUgeCwgd2UgZGVmaW5lIE4x KHgpIGFzIA0KdGhlIHNldCBvZiBpdHMgaW1tZWRpYXRlIG9yIG9uZS1ob3AgbmVpZ2hib3JzLiAg V2UgYWxzbyBkZWZpbmUgTjIoeCksIA0KdGhlIHNldCBvZiB0d28taG9wIG5laWdoYm9ycyBvZiB4 LCBhcyB0aGUgc2V0IG9mIG5vZGVzIHRoYXQgYXJlIG5vdCANCmEgb25lLWhvcCBuZWlnaGJvciBv ZiB4IGJ1dCBhcmUgYSBvbmUtaG9wIG5laWdoYm9yIG9mIGF0IGxlYXN0IG9uZSANCm1lbWJlciBv ZiBOMSh4KS4gIEEgc3Vic2V0IG9mIE4xKHgpIHdob3NlIG9uZS1ob3AgbmVpZ2hib3JzIGluY2x1 ZGUgDQphbGwgdHdvLWhvcCBuZWlnaGJvcnMgb2YgeCwgaS5lLiwgYWxsIG1lbWJlcnMgb2YgTjIo eCksIGlzIGRlZmluZWQgDQphcyBNKHgpLCB0aGUgIk11bHRpcG9pbnQgIFJlbGF5IFNldCIgb2Yg bm9kZSB4LiAgDQoNCkFzIG5vZGUgeCBmbG9vZHMgYW4gDQpMU0EgdG8gaXRzIG9uZS1ob3AgbmVp Z2hib3JzLCBpdCBhc2tzIG9ubHkgdGhlIG11bHRpcG9pbnQgcmVsYXlzIHRvIA0KZmxvb2QgZnVy dGhlci4gIEEgb25lLWhvcCBuZWlnaGJvciBvZiB4IHRoYXQgaXMgbm90IG9uZSBvZiBpdHMgDQpt dWx0aXBvaW50IHJlbGF5cywgaS5lLiwgZG9lcyBub3QgYmVsb25nIHRvIE0oeCksIHdvdWxkIHJl Y2VpdmUgdGhlIA0KTFNBIGFuZCBhY2tub3dsZWRnZSBpdCBidXQgd291bGQgbm90IHJldHJhbnNt aXQgaXQgYW55IGZ1cnRoZXIuICAgQSANCm9uZS1ob3AgbmVpZ2hib3Igb2YgeCB0aGF0IGlzIG9u ZSBvZiBpdHMgbXVsdGlwb2ludCByZWxheXMsIGkuZS4sIA0KYmVsb25ncyB0byBNKHgpLCB3b3Vs ZCBmbG9vZCBmdXJ0aGVyIHVzaW5nIHRoZSBzYW1lIGFsZ29yaXRobSwgaS5lLiwgDQppdCB3aWxs IGZsb29kIHRvIGFsbCBpdHMgb25lLWhvcCBuZWlnaGJvcnMgKGV4Y2VwdCBOb2RlIE4xKSBhbmQg YXNrIA0Kb25seSBpdHMgbXVsdGlwb2ludCByZWxheXMgdG8gZmxvb2QgZnVydGhlci4gIFRoaXMg aXMgYSBkaXN0cmlidXRlZCANCmFsZ29yaXRobSBpbiB0aGUgc2Vuc2UgdGhhdCBlYWNoIG5vZGUg ZGV0ZXJtaW5lcyB0aGUgc2V0IG9mIGl0cyANCm11bHRpcG9pbnQgcmVsYXlzIGluZGVwZW5kZW50 IG9mIHRoZSBzZWxlY3Rpb24gcHJvY2VzcyBhdCBhbnkgb3RoZXIgDQpub2RlLiAgIA0KDQpJZiBm b3IgYWxsIG5vZGUgeCwgdGhlIHNldCBvZiBtdWx0aXBvaW50IHJlbGF5cyBpcyB0aGUgc2FtZSAN CmFzIHRoZSBzZXQgb2YgYWxsIG9uZS1ob3AgbmVpZ2hib3JzIHRoZW4gQWxnb3JpdGhtIDMgd291 bGQgYmUgDQppZGVudGljYWwgdG8gQWxnb3JpdGhtIDIuICBJbiBnZW5lcmFsLCBob3dldmVyLCBp dCB3b3VsZCBiZSBwb3NzaWJsZSANCnRvIGNob29zZSBhIG11bHRpcG9pbnQgcmVsYXkgc2V0IHRo YXQgaXMgc21hbGxlciB0aGFuIHRoZSBzZXQgb2YgYWxsIA0Kb25lLWhvcCBuZWlnaGJvcnMuICAg RmluZGluZyBhbiBvcHRpbWFsIG11bHRpcG9pbnQgcmVsYXkgc2V0IGhhcyBsYXJnZSANCmNvbXB1 dGF0aW9uYWwgY29tcGxleGl0eSBhbmQgc28gd2UgY2hvb3NlIHRoZSBmb2xsb3dpbmcgbmVhci1v cHRpbWFsIA0KaGV1cmlzdGljIGFsZ29yaXRobS4NCg0KU3RlcCAxOiBJbmNsdWRlIGEgb25lLWhv cCBuZWlnaGJvciAoc2F5IHkpIG9mIHggYXMgcGFydCBvZiBNKHgpIGlmIA0KdGhlcmUgZXhpc3Rz IGF0IGxlYXN0IG9uZSBtZW1iZXIgb2YgTjIoeCkgd2hvIGhhcyB5IGFzIGl0cyBvbmx5IG9uZS1o b3AgDQpuZWlnaGJvciBpbiB0aGUgc2V0IE4xKHgpLiAgS2VlcCByZXBlYXRpbmcgdGhpcyBwcm9j ZXNzIHVudGlsIG5vIG1vcmUgDQpvbmUtaG9wIG5laWdoYm9yIHkgd2l0aCBhYm92ZS1tZW50aW9u ZWQgcHJvcGVydHkgZXhpc3RzLg0KDQoNCiBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCiBJbnRlcm5ldCBEcmFm dCAgICAgICAgICAgICBGbG9vZGluZyBTaW11bGF0aW9uICAgICAgICAgICAgICBNYXksIDIwMDMN Cg0KDQpTdGVwIDI6IElmIGFsbCBub2RlcyBpbiBOMih4KSBhcmUgY292ZXJlZCBhcyBvbmUtaG9w IG5laWdoYm9ycyBvZiANCm1lbWJlcnMgb2YgTSh4KSB0aGVuIHN0b3AuICBPdGhlcndpc2UsIGNo b29zZSBhIG1lbWJlciBvZiBOMSh4KSAtIE0oeCkgDQphcyBhIG5ldyBtZW1iZXIgb2YgTSh4KSB3 aGljaCBjb3ZlcnMgYXMgb25lLWhvcCBuZWlnaGJvcnMgdGhlIG1heGltdW0gDQpudW1iZXIgb2Yg cHJldmlvdXNseSB1bmNvdmVyZWQgbWVtYmVycyBvZiBOMih4KS4gIEtlZXAgcmVwZWF0aW5nIHRo aXMgDQpzdGVwIHVudGlsIGFsbCBtZW1iZXJzIG9mIE4yKHgpIGFyZSBjb3ZlcmVkIGF0IHdoaWNo IHBvaW50IHRoZSANCnNlbGVjdGlvbiBvZiB0aGUgbXVsdGlwb2ludCByZWxheSBzZXQgTSh4KSBp cyBjb21wbGV0ZS4NCkZvciBldmVyeSBub2RlIHggaW4gdGhlIG5ldHdvcmssIHBlcmZvcm0gdGhl IG11bHRpcG9pbnQgcmVsYXkgc2V0IA0Kc2VsZWN0aW9uIHByb2Nlc3MgaW4gcGFyYWxsZWwgYW5k IGluZGVwZW5kZW50bHkuICANCg0KVGhlIG11bHRpcG9pbnQgcmVsYXkgDQptZWNoYW5pc20gaGFz IGJlZW4gcHJvcG9zZWQgZm9yIHVzZSBpbiBNb2JpbGUgV2lyZWxlc3MgbmV0d29ya3MgDQpbUmVm MTFdLg0KDQoNCkFsZ29yaXRobSA0IChGbG9vZGluZyBvdmVyIG9uZSBvZiBtYW55IHBhcmFsbGVs IGxpbmtzIGJldHdlZW4gbmVpZ2hib3JzIA0KcGx1cyBmbG9vZGluZyBvdmVyIGEgbWluaW11bSBz cGFubmluZyB0cmVlKTogIEluIGFkZGl0aW9uIHRvIHRoZSANCmZsb29kaW5nIHJlc3RyaWN0aW9u cyBpbiBBbGdvcml0aG0gMiAoaS5lLiwgaWYgdGhlcmUgYXJlIG11bHRpcGxlIA0KcGFyYWxsZWwg bGlua3MgdG8gYW4gaW1tZWRpYXRlIG5laWdoYm9yIHRoZW4gb25seSBvbmUgaXMgdXNlZCBmb3Ig DQpmbG9vZGluZyksIHdlIGFsc28gaW50cm9kdWNlIGEgZnVydGhlciByZXN0cmljdGlvbiBieSBk ZXZlbG9waW5nIGEgDQptaW5pbXVtIHNwYW5uaW5nIHRyZWUgdGhhdCBjb25uZWN0cyBhbGwgbm9k ZXMgYW5kIGZsb29kaW5nIG9ubHkgb3ZlciANCnRoZSBtaW5pbXVtIHNwYW5uaW5nIHRyZWUuICAg SXQgaXMgcG9zc2libGUgdG8gY3JlYXRlIGEgdHJlZSBzcGFubmluZyANCmFsbCBuZXR3b3JrIG5v ZGVzIGluIGEgZ2l2ZW4gYXJlYSBpbiBtYW55IHdheXMuICANCg0KV2UgY3JlYXRlIGEgc3Bhbm5p bmcgDQp0cmVlIHdpdGggdGhlIG9iamVjdGl2ZXMgb2YgbWluaW1pemluZyB0aGUgbWF4aW11bSBk ZWxheSBiZXR3ZWVuIGFueSANCnR3byBuZXR3b3JrIG5vZGVzIGluIGEgZ2l2ZW4gYXJlYSBhbmQg cmVzdHJpY3RpbmcgdGhlIGFkamFjZW5jeSBhdCBhIA0Kbm9kZSBpbiB0aGUgc3Bhbm5pbmcgdHJl ZSB0byBubyBtb3JlIHRoYW4gYSBjZXJ0YWluIG1heGltdW0gdmFsdWUgDQphZGptYXguICBUaGUg Zmlyc3Qgb2JqZWN0aXZlIGlzIHRvIG1pbmltaXplIHRoZSBMU0EgY29udmVyZ2VuY2UgdGltZSAN CmFuZCB0aGUgc2Vjb25kIG9iamVjdGl2ZSBpcyB0byByZWR1Y2UgdGhlIGltcGFjdCBvZiBMU0Eg c3Rvcm0gb24gbm9kZXMgDQpzaW5jZSB0aGUgbm9kZSB3aXRoIHRoZSBoaWdoZXN0IGFkamFjZW5j eSBpcyBpbXBhY3RlZCB0aGUgbW9zdC4gIEZvciANCmRlbGF5IGJldHdlZW4gdHdvIG5vZGVzIHdl IHVzZSBqdXN0IHRoZSBzdW0gb2YgdGhlIHByb3BhZ2F0aW9uIGFuZCANCnByb2Nlc3NpbmcgZGVs YXlzIGFsb25nIHRoZSBzcGFubmluZyB0cmVlIGJldHdlZW4gdGhlIHNvdXJjZSBhbmQgdGhlDQpk ZXN0aW5hdGlvbi4gIE90aGVyIGRlbGF5IGNvbXBvbmVudHMgc3VjaCBhcyBxdWV1ZWluZyBkZWxh eXMgYW5kIA0Kc2NoZWR1bGluZyBkZWxheXMgYXJlIG5vdCBjb25zaWRlcmVkIHNpbmNlIHRoZXkg YXJlIGRlcGVuZGVudCBvbiB0aGUgDQp0cmFmZmljIGxvYWQsIGV4YWN0IExTQSBnZW5lcmF0aW9u IHRpbWUsIGV0Yy4gYW5kIGRpZmZpY3VsdCB0byANCmVzdGltYXRlIGZvciB0aGUgcHVycG9zZSBv ZiBvcHRpbWl6YXRpb24gKHRoZXNlIHF1YW50aXRpZXMgYXJlIA0KbmV2ZXJ0aGVsZXNzIGNvbXB1 dGVkIGV4YWN0bHkgYXMgcGFydCBvZiB0aGUgc2ltdWxhdGlvbiBtb2RlbCB0byBiZSANCmRlc2Ny aWJlZCBsYXRlcikuICBOb3RlIHRoYXQgb25seSBhIHN1YnNldCBvZiB0aGUgYWRqYWNlbmNpZXMg YXJlIG9uIA0KdGhlIHNwYW5uaW5nIHRyZWUgKGFsc28gbm8gbW9yZSB0aGFuIG9uZSBiZXR3ZWVu IGltbWVkaWF0ZSBuZWlnaGJvcnMpIA0KYW5kIG9ubHkgdGhlIHN1bSBvZiB0aG9zZSBpcyBub3Qg dG8gZXhjZWVkIGFkam1heC4gDQoNCldlIGRldmVsb3AgdGhlIGZvbGxvd2luZyBoZXVyaXN0aWMg YWxnb3JpdGhtLiAgQnVpbGQgdGhlIHNwYW5uaW5nIHRyZWUNCnNlcXVlbnRpYWxseSBzdGFydGlu ZyBmcm9tIGEgc2luZ2xlIG5vZGUgdGhhdCBpcyBuZWFyZXN0IHRvIHRoZSANCmdlb2dyYXBoaWMg Y2VudGVyIG9mIHRoZSBuZXR3b3JrIGFyZWEuICBJbiBlYWNoIHN0YWdlIGFkZCB0aGF0IGxpbmsg DQphbmQgYXNzb2NpYXRlZCBub2RlIHRvIHRoZSB0cmVlIHRoYXQgd291bGQgbWluaW1pemUgdGhl IG1heGltdW0gZGVsYXkgDQooYWxvbmcgdGhlIHNwYW5uaW5nIHRyZWUpIGZyb20gdGhlIG5ldyBu b2RlIHRvIGFueSBvdGhlciBub2RlIGluIHRoZSANCmV4aXN0aW5nIHNwYW5uaW5nIHRyZWUgYnV0 IHdpdGggdGhlIHJlc3RyaWN0aW9uIHRoYXQgdGhlIGFkamFjZW5jeSBvZiANCmFueSBub2RlIGNh bm5vdCBleGNlZWQgYWRqbWF4LiAoV2UgaGF2ZSBzZWVuIHRoYXQgYSBzcGFubmluZyB0cmVlDQpn ZW5lcmF0ZWQgdXNpbmcgdGhpcyBhbGdvcml0aG0gY2FuIGhhdmUgc2lnbmlmaWNhbnRseSBsb3dl ciBtYXhpbXVtDQoNCg0KIENob3VkaHVyeSBldC4gYWwuICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KIEludGVybmV0IERyYWZ0ICAgICAgICAg ICAgIEZsb29kaW5nIFNpbXVsYXRpb24gICAgICAgICAgICAgIE1heSwgMjAwMw0KDQoNCmVuZC10 by1lbmQgZGVsYXkgYmV0d2VlbiBub2RlcyBjb21wYXJlZCB0byBhIHJhbmRvbWx5IGdlbmVyYXRl ZA0Kc3Bhbm5pbmcgdHJlZSB3aXRoIHRoZSBzYW1lIGFkam1heCB2YWx1ZSkuICANCg0KQWZ0ZXIg dGhlIGZvcm1hdGlvbiBvZiBhIHNwYW5uaW5nIHRyZWUgaWYgYSBsaW5rIG9uIHRoZSBzcGFubmlu ZyB0cmVlIA0KZ29lcyBkb3duIHRoZW4gaXQgaXMgcmVwbGFjZWQgd2l0aCBhIHBhcmFsbGVsIGxp bmsgYmV0d2VlbiB0aGUgc2FtZSANCnNldCBvZiBub2RlcywgaWYgYW55IHN1Y2ggZXhpc3RzLiAg SWYgbm8gc3VjaCBwYXJhbGxlbCBsaW5rIGV4aXN0cyB0aGVuIA0KdGhlIHNwYW5uaW5nIHRyZWUg aXMgdG8gYmUgcmVjb21wdXRlZC4gIFRoZSBzcGFubmluZyB0cmVlIA0KcmUtY29tcHV0YXRpb24g aXMgYWxzbyBuZWVkZWQgaW4gdGhlIGNhc2Ugb2YgZmFpbHVyZSBvZiBhIG5vZGUgb24gdGhlIA0K c3Bhbm5pbmcgdHJlZS4gIFRoZSBzcGFubmluZyB0cmVlIGNvbXB1dGF0aW9uL3JlLWNvbXB1dGF0 aW9uIG1heSBiZSANCmRvbmUgaW5kZXBlbmRlbnRseSBhdCBlYWNoIG5vZGUgaW4gYSBkaXN0cmli dXRlZCBmYXNoaW9uIGJ1dCB1c2luZyB0aGUgDQpzYW1lIGFsZ29yaXRobSwgb3IgaXQgbWF5IGJl IGNvbXB1dGVkIGF0IG9uZSBub2RlIGFuZCBmbG9vZGVkIHRvIHRoZSANCndob2xlIG5ldHdvcmsg cGVyaW9kaWNhbGx5IHVzaW5nIEFsZ29yaXRobSAyLg0KDQoNCkFsZ29yaXRobSA1IChGbG9vZGlu ZyBvdmVyIG9uZSBvZiBtYW55IHBhcmFsbGVsIGxpbmtzIGJldHdlZW4gbmVpZ2hib3JzIA0KZm9y IGFsbCBMU0FzIHBsdXMgZmxvb2Rpbmcgb3ZlciBhIG1pbmltdW0gc3Bhbm5pbmcgdHJlZSBmb3Ig TFNBcyB0aGF0IA0KZG8gbm90IGNhcnJ5IGludHJhLWFyZWEgdG9wb2xvZ3kgaW5mb3JtYXRpb24p OiBUaGlzIGFsZ29yaXRobSBpcyBhIA0KaHlicmlkIGJldHdlZW4gQWxnb3JpdGhtcyAyIGFuZCA0 LiAgRm9yIExTQXMgdGhhdCBjYXJyeSBpbnRyYS1hcmVhIA0KdG9wb2xvZ3kgaW5mb3JtYXRpb24g KGUuZy4sIFJvdXRlciBhbmQgTmV0d29yayBMU0FzKSwgZmxvb2RpbmcgaXMgZG9uZSANCmFzIGlu IEFsZ29yaXRobSAyLiAgV2UgY2FsbCB0aGVzZSBUeXBlIEEgTFNBcy4gIEZvciBMU0FzIHRoYXQg ZG8gbm90IA0KY2FycnkgYXJlYSB0b3BvbG9neSBpbmZvcm1hdGlvbiwgZmxvb2RpbmcgaXMgZG9u ZSBhcyBpbiBBbGdvcml0aG0gNCANCmFuZCB3ZSBjYWxsIHRoZW0gVHlwZSBCIExTQXMuIEl0IGlz IHRvIGJlIG5vdGVkIHRoYXQgc2luY2UgVHlwZSBBIGFuZA0KVHlwZSBCIExTQXMgYXJlIGZsb29k ZWQgZGlmZmVyZW50bHksIHRoZXkgc2hvdWxkIG5vdCBiZSBwYWNrZWQgYXMgcGFydA0KT2YgdGhl IHNhbWUgTFNVLiAgRXhhbXBsZXMgb2YgVHlwZSBCIExTQXMgaW5jbHVkZSBBU0UgTFNBLCANCnN1 bW1hcnkgTFNBIGFuZCBBU0JSLXN1bW1hcnkgTFNBLiAgQW5vdGhlciBleGFtcGxlIG1heSBiZSBP cGFxdWUgTFNBcyANCnVzZWQgdG8gY2FycnkgbGluayBiYW5kd2lkdGggaW5mb3JtYXRpb24gYXMg dXNlZCBpbiB0aGUgVHJhZmZpYyANCkVuZ2luZWVyaW5nIGV4dGVuc2lvbiBvZiBPU1BGVjIgW1Jl ZjEyXS4gIA0KDQpUaGUgcmVhc29uIGZvciBpbnRyb2R1Y2luZyBBbGdvcml0aG0gNSBpcyB0aGF0 IA0KaW4gb3JkZXIgdG8gY29tcHV0ZSB0aGUgbWluaW11bSBzcGFubmluZyB0cmVlIChhbmQgcmUt Y29tcHV0ZSBpdCANCnVuZGVyIGxpbmsvbm9kZSBmYWlsdXJlKSB3ZSBuZWVkIHRoZSBpbnRyYS1h cmVhIHRvcG9sb2d5IGluZm9ybWF0aW9uLiAgDQpJZiB3ZSBhbHNvIHJlbHkgb24gdGhlIG1pbmlt dW0gc3Bhbm5pbmcgdHJlZSB0byBnZXQgdGhlIHRvcG9sb2d5IA0KaW5mb3JtYXRpb24sIGFzIGlu IEFsZ29yaXRobSA0LCB0aGVuIGl0IG1heSBiZSBkaWZmaWN1bHQgdG8gZ2V0IGFuIA0KYWNjdXJh dGUgcGljdHVyZSBvZiB0aGUgdG9wb2xvZ3kgdW5kZXIgdGhlIGZhaWx1cmUgb2YgdGhlIG1pbmlt dW0gDQpzcGFubmluZyB0cmVlLiAgSW4gQWxnb3JpdGhtIDUsIGhvd2V2ZXIsIHRoZSB0b3BvbG9n eSBpbmZvcm1hdGlvbiB0aGF0IA0KaXMgbmVlZGVkIHRvIGNvbXB1dGUvcmUtY29tcHV0ZSB0aGUg bWluaW11bSBzcGFubmluZyB0cmVlIGlzIA0KZGlzdHJpYnV0ZWQgdXNpbmcgdGhlIG1vcmUgcm9i dXN0IEFsZ29yaXRobSAyIGFuZCBzbyBldmVuIGlmIHNvbWUgDQpsaW5rcy9ub2RlcyBvZiB0aGUg bWluaW11bSBzcGFubmluZyB0cmVlIGZhaWxzIGJ1dCB0aGUgcmVzdCBvZiB0aGUgDQpuZXR3b3Jr IHJlbWFpbnMgY29ubmVjdGVkIHRoZW4gdGhlIHRvcG9sb2d5IGluZm9ybWF0aW9uIHdvdWxkIGJl IA0KYWNjdXJhdGVseSBjYXJyaWVkIHRvIGFsbCBuZXR3b3JrIG5vZGVzIGluIHRoZSBhcmVhIGFu ZCBpdCB3b3VsZCBiZSANCnBvc3NpYmxlIHRvIHJlLWNvbXB1dGUgdGhlIG1pbmltdW0gc3Bhbm5p bmcgdHJlZS4gICAgDQoNCk9uIHRoZSBvdGhlciBoYW5kLCANCkFsZ29yaXRobSA0IGlzIGxlc3Mg bWVzc2FnZSBpbnRlbnNpdmUgY29tcGFyZWQgdG8gQWxnb3JpdGhtIDIgYW5kIFR5cGUgDQpCIExT QXMgY2FuIGJlbmVmaXQgZnJvbSB0aGlzIHJlZHVjZWQgYW1vdW50IG9mIG1lc3NhZ2luZy4gICBJ biBtYW55IA0Kc2l0dWF0aW9ucyBUeXBlIEIgTFNBcyBtYXkgYmUgbWFueSBtb3JlIGluIG51bWJl ciBjb21wYXJlZCB0byBUeXBlIEEgDQpMU0FzLiAgSW4gb25lIGV4YW1wbGUgdGhlcmUgbWF5IGJl IG1hbnkgbW9yZSBBU0UsIFN1bW1hcnkgYW5kIA0KQVNCUi1TdW1tYXJ5IExTQXMgY29tcGFyZWQg dG8gUm91dGVyIGFuZCBOZXR3b3JrIExTQXMuICBJbiBhbm90aGVyIA0KZXhhbXBsZSwgaWYgYSB0 cmFmZmljLWVuZ2luZWVyaW5nLXJlbGF0ZWQgT3BhcXVlIExTQSBpcyB1c2VkIGZvciBlYWNoIA0K DQoNCiBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgNl0NCgwNCiBJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBGbG9vZGlu ZyBTaW11bGF0aW9uICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQpkaXJlY3Rpb24gb2YgZWFj aCBsaW5rIG9mIHRoZSBuZXR3b3JrIHRoZW4gdGhlcmUgd291bGQgdHlwaWNhbGx5IGJlIA0KbWFu eSBtb3JlIExTQXMgb2YgdGhpcyB0eXBlIGNvbXBhcmVkIHRvIFJvdXRlciBhbmQgTmV0d29yayBM U0FzLiAgIA0KQWxnb3JpdGhtIDUgaGFzIHRoZSBzYW1lIGFtb3VudCBvZiByb2J1c3RuZXNzIGFz IEFsZ29yaXRobSAyIGZvciAgDQpDYXJyeWluZyB0b3BvbG9neS1yZWxhdGVkIGluZm9ybWF0aW9u IGJ1dCBpdCBjYW4gYmUgZmFyIGxlc3MgDQptZXNzYWdlLWludGVuc2l2ZSBpZiBtYWpvcml0eSBv ZiB0aGUgTFNBcyBhcmUgb2YgVHlwZSBCLg0KDQoNCg0KMy4gVGhlIE5ldHdvcmsgdW5kZXIgU2lt dWxhdGlvbg0KDQpXZSBnZW5lcmF0ZSBhIHJhbmRvbSBuZXR3b3JrIG92ZXIgYSByZWN0YW5ndWxh ciBncmlkIHVzaW5nIGEgbW9kaWZpZWQgDQp2ZXJzaW9uIG9mIFdheG1hbidzIGFsZ29yaXRobSBb UmVmMTNdIHRoYXQgZW5zdXJlcyB0aGF0IHRoZSBuZXR3b3JrIGlzIA0KY29ubmVjdGVkIGFuZCBo YXMgYSBwcmUtc3BlY2lmaWVkIG51bWJlciBvZiBub2RlcywgbGlua3MsIG1heGltdW0gDQpudW1i ZXIgb2YgbmVpZ2hib3JzIHBlciBub2RlLCANCmFuZCBtYXhpbXVtIG51bWJlciBvZiBhZGphY2Vu Y2llcyBwZXIgbm9kZS4gVGhlIHJlY3Rhbmd1bGFyIGdyaWQgDQpyZXNlbWJsZXMgdGhlIGNvbnRp bmVudGFsIFUuUy5BLiB3aXRoIG1heGltdW0gcHJvcGFnYXRpb24gZGVsYXkgb2YgDQozMCBtcyBp biB0aGUgRWFzdC1XZXN0IGRpcmVjdGlvbiBhbmQgbWF4aW11bSBwcm9wYWdhdGlvbiBkZWxheSBv ZiANCjE1IG1zIGluIHRoZSBOb3J0aC1Tb3V0aCBkaXJlY3Rpb24uICBXZSBjb25zaWRlciB0d28g ZGlmZmVyZW50IA0KbmV0d29yayBzaXplcyBhcyBleHBsYWluZWQgaW4gU2VjdGlvbiA0Lg0KDQpU aGUgbmV0d29yayBoYXMgYSBmbGF0LCBzaW5nbGUtYXJlYSB0b3BvbG9neS4NCg0KRWFjaCBub2Rl IGlzIGEgUm91dGVyIGFuZCBlYWNoIGxpbmsgaXMgYSBwb2ludC10by1wb2ludCBsaW5rIA0KY29u bmVjdGluZyB0d28gcm91dGVycy4NCg0KV2UgYXNzdW1lIHRoYXQgbm9kZSBDUFUgYW5kIG1lbW9y eSAobm90IHRoZSBsaW5rIGJhbmR3aWR0aCkgaXMgdGhlIG1haW4gDQpib3R0bGVuZWNrIGluIHRo ZSBMU0EgZmxvb2RpbmcgcHJvY2Vzcy4gIFRoaXMgd2lsbCB0eXBpY2FsbHkgYmUgdHJ1ZSANCmZv ciBoaWdoIHNwZWVkIGxpbmtzIChlLmcuLCBPQzMgb3IgYWJvdmUpIGFuZC9vciBsaW5rcyB3aGVy ZSBPU1BGDQp0cmFmZmljIGdldHMgYW4gYWRlcXVhdGUgUXVhbGl0eSBvZiBTZXJ2aWNlIChRb1Mp IGNvbXBhcmVkIHRvIG90aGVyDQp0cmFmZmljLg0KIA0KRGlmZmVyZW50IFRpbWVycyAodXN1YWxs eSBkZWZhdWx0IHZhbHVlcyk6IExTQSByZWZyZXNoIGludGVydmFsID0gDQoxODAwIHNlY29uZHMs IEhlbGxvIHJlZnJlc2ggaW50ZXJ2YWwgPSAxMCBTZWNvbmRzLCBSb3V0ZXItRGVhZCANCmludGVy dmFsID0gNDAgc2Vjb25kcywgTFNBIHJldHJhbnNtaXNzaW9uIGludGVydmFsID0gNSBTZWNvbmRz IChub3RlDQp0aGF0IGEgcmV0cmFuc21pc3Npb24gaXMgZGlzYWJsZWQgb24gdGhlIHJlY2VpcHQg b2YgZWl0aGVyIGFuDQpleHBsaWNpdCBhY2tub3dsZWRnbWVudCBvciBhIGR1cGxpY2F0ZSBMU0Eg b3ZlciB0aGUgc2FtZSBpbnRlcmZhY2UNCnRoYXQgYWN0cyBhcyBhbiBpbXBsaWNpdCBhY2tub3ds ZWRnbWVudCksIA0KTWluaW11bSBUaW1lIEJldHdlZW4gZ2VuZXJhdGlvbiBvZiB0aGUgc2FtZSBM U0EgPSA1IFNlY29uZHMsIE1pbmltdW0gDQp0aW1lIGJldHdlZW4gc3VjY2Vzc2l2ZSBEaWprc3Ry YSBTUEYgY2FsY3VsYXRpb25zIGlzIDEgc2Vjb25kLg0KDQpQYWNraW5nIG9mIExTQXM6IEl0IGlz IGFzc3VtZWQgdGhhdCBmb3IgYW55IGdpdmVuIG5vZGUsIHRoZSBMU0FzIA0KZ2VuZXJhdGVkIG92 ZXIgYSAxLXNlY29uZCBwZXJpb2QgYXJlIHBhY2tlZCB0b2dldGhlciB0byBmb3JtIGFuIExTVSAN CmJ1dCBubyBtb3JlIHRoYW4gMyBMU0FzIGFyZSBwYWNrZWQgaW4gb25lIExTVS4NCg0KTFNVL0Fj ay9IZWxsbyBQcm9jZXNzaW5nIFRpbWVzOiBBbGwgcHJvY2Vzc2luZyB0aW1lcyBhcmUgZXhwcmVz c2VkIGluIA0KdGVybXMgb2YgdGhlIHBhcmFtZXRlciBULiAgRGlmZmVyZW50IHZhbHVlcyBvZiBU IGluIHRoZSByYW5nZSBvZiAwLjUgbXMNCnRvIDIgbXMgYXJlIGNvbnNpZGVyZWQuIA0KDQpJbiB0 aGUgY2FzZSBvZiBhIGRlZGljYXRlZCBwcm9jZXNzb3IgZm9yIHByb2Nlc3NpbmcgT1NQRiBwYWNr ZXRzIHRoZSANCg0KDQogQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICAg ICAgRmxvb2RpbmcgU2ltdWxhdGlvbiAgICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0KcHJvY2Vz c2luZyB0aW1lIHJlcG9ydGVkIHJlcHJlc2VudHMgdGhlIHRydWUgcHJvY2Vzc2luZyB0aW1lLiAg SWYgdGhlIA0KcHJvY2Vzc29yIGRvZXMgb3RoZXIgd29yayBhbmQgb25seSBhIGZyYWN0aW9uIG9m IGl0cyBjYXBhY2l0eSBjYW4gYmUgDQpkZWRpY2F0ZWQgdG8gT1NQRiBwcm9jZXNzaW5nIHRoZW4g d2UgaGF2ZSB0byBpbmZsYXRlIHRoZSBwcm9jZXNzaW5nIA0KdGltZSBhcHByb3ByaWF0ZWx5IHRv IGdldCB0aGUgZWZmZWN0aXZlIHByb2Nlc3NpbmcgdGltZSBhbmQgaW4gdGhhdCANCmNhc2UgaXQg aXMgYXNzdW1lZCB0aGF0IHRoZSBpbmZsYXRpb24gZmFjdG9yIGlzIGFscmVhZHkgdGFrZW4gaW50 byANCmFjY291bnQgYXMgcGFydCBvZiB0aGUgcmVwb3J0ZWQgcHJvY2Vzc2luZyB0aW1lLiANCg0K VGhlIGZpeGVkIHRpbWUgdG8gc2VuZCBvciByZWNlaXZlIGFueSBMU1UsIEFjayBvciBIZWxsbyBw YWNrZXQgaXMgVC4gIA0KSW4gYWRkaXRpb24sIGEgdmFyaWFibGUgcHJvY2Vzc2luZyB0aW1lIGlz IHVzZWQgZm9yIExTVSBhbmQgQWNrIA0KZGVwZW5kaW5nIG9uIHRoZSBudW1iZXIgYW5kIHR5cGVz IG9mIExTQXMgcGFja2VkLiAgTm8gdmFyaWFibGUgDQpwcm9jZXNzaW5nIHRpbWUgaXMgdXNlZCBm b3IgSGVsbG8uDQpWYXJpYWJsZSBwcm9jZXNzaW5nIHRpbWUgcGVyIFJvdXRlciBMU0EgaXMgKDAu NSArIDAuMTdMKVQgd2hlcmUgTCBpcyANCnRoZSBudW1iZXIgb2YgYWRqYWNlbmNpZXMgYWR2ZXJ0 aXNlZCBieSB0aGUgUm91dGVyIExTQS4gIEZvciBvdGhlciANCkxTQSB0eXBlcyAoZS5nLiwgQVNF IExTQSBvciBhICJMaW5rIiBMU0EgY2FycnlpbmcgdHJhZmZpYyBlbmdpbmVlcmluZw0KaW5mb3Jt YXRpb24gYWJvdXQgYSBsaW5rKSwgdGhlIHZhcmlhYmxlIHByb2Nlc3NpbmcgdGltZSBwZXIgTFNB IGlzIA0KMC41VC4NCg0KVmFyaWFibGUgcHJvY2Vzc2luZyB0aW1lIGZvciBhbiBBY2sgaXMgMjUl IHRoYXQgb2YgdGhlIGNvcnJlc3BvbmRpbmcgDQpMU0EuDQoNCkl0IGlzIHRvIGJlIG5vdGVkIHRo YXQgaWYgbXVsdGlwbGUgTFNBcyBhcmUgcGFja2VkIGluIGEgc2luZ2xlIExTVSANCnBhY2tldCB0 aGVuIHRoZSBmaXhlZCBwcm9jZXNzaW5nIHRpbWUgaXMgbmVlZGVkIG9ubHkgb25jZSBidXQgdGhl IA0KdmFyaWFibGUgcHJvY2Vzc2luZyB0aW1lIGlzIG5lZWRlZCBmb3IgZXZlcnkgY29tcG9uZW50 IG9mIHRoZSBwYWNrZXQuDQoNCkxTVS9BY2svSGVsbG8gUHJpb3JpdHk6IEFsbCBMU1VzL0Fja3Mv SGVsbG9zIHJlY2VpdmVkIGF0IGEgbm9kZSBhcmUgDQpxdWV1ZWQgYXQgdGhlIHNhbWUgcHJpb3Jp dHkgYW5kIHByb2Nlc3NlZCBpbiBhIEZJRk8gbWFubmVyLiAgQW55IA0KcGFja2V0cyBnZW5lcmF0 ZWQgaW50ZXJuYWxseSB0byBhIG5vZGUgYW5kIHVzdWFsbHkgYmFzZWQgb24gYSB0aW1lciANCmFy ZSBwcm9jZXNzZWQgYXQgYSBoaWdoZXIgcHJpb3JpdHkuICAgVGhpcyBpbmNsdWRlcyB0aGUgaW5p dGlhbCBMU0EgDQpzdG9ybSwgTFNBIHJlZnJlc2gsIEhlbGxvIHJlZnJlc2gsIExTQSByZXRyYW5z bWlzc2lvbiBhbmQgbmV3IExTQSANCmdlbmVyYXRpb24gYWZ0ZXIgZGV0ZWN0aW9uIG9mIGEgZmFp bHVyZSBvciByZWNvdmVyeS4NCg0KQnVmZmVyIFNpemUgZm9yIEluY29taW5nIExTVXMvQWNrcy9I ZWxsb3M6IEJ1ZmZlciBzaXplIGlzIGFzc3VtZWQgDQp0byBiZSAyMDAwIHBhY2tldHMgd2hlcmUg YSBwYWNrZXQgaXMgZWl0aGVyIGFuIGluY29taW5nIExTVSwgQWNrIG9yIA0KSGVsbG8uICBUaGUg YnVmZmVyIGlzIG1hbmFnZWQgaW4gYSBGSUZPIG1hbm5lciBhbmQgd2hlbiB0aGUgYnVmZmVyIGlz IA0KZnVsbCwgbmV3IHBhY2tldCBhcnJpdmFscyBhcmUgZHJvcHBlZC4NCg0KUHJvY2Vzc2luZyBU aW1lIGZvciBNUFIvTVNUIGNvbXB1dGF0aW9uIGF0IGEgbm9kZSAoQWxnb3JpdGhtcw0KMywgNCBh bmQgNSk6IDEwIG1zLiAgVGhpcyBpcyBuZWVkZWQgb25jZSBpbiB0aGUgYmVnaW5uaW5nIGFuZCAN Cm90aGVyd2lzZSBvbmx5IHdoZW4gdGhlIGxhc3QgbGl2ZSBsaW5rIGJldHdlZW4gYSBwYWlyIG9m IG5vZGVzIGluIHRoZSANCm5ldHdvcmsgZ29lcyBkb3duLg0KDQpMU0EgUmVmcmVzaDogRWFjaCBM U0EgaXMgcmVmcmVzaGVkIG9uY2UgaW4gMTgwMCBzZWNvbmRzIGFuZCB0aGUgDQpyZWZyZXNoIGlu c3RhbnRzIG9mIHZhcmlvdXMgTFNBcyBpbiB0aGUgTFNEQiBhcmUgYXNzdW1lZCB0byBiZSANCnVu aWZvcm1seSBkaXN0cmlidXRlZCBvdmVyIHRoZSAxODAwIHNlY29uZHMgcGVyaW9kLCBpLmUuLCB0 aGV5IGFyZSANCmNvbXBsZXRlbHkgdW5zeW5jaHJvbml6ZWQuICBJZiBob3dldmVyLCBhbiBMU0Eg aXMgZ2VuZXJhdGVkIGFzIHBhcnQgDQpvZiB0aGUgaW5pdGlhbCBMU0Egc3Rvcm0gdGhlbiBpdCBn b2VzIG9uIGEgbmV3IHJlZnJlc2ggc2NoZWR1bGUgb2YgDQpvbmNlIGluIDE4MDAgc2Vjb25kcyBz dGFydGluZyBmcm9tIGl0cyBnZW5lcmF0aW9uIHRpbWUuICAgDQoNCkxTQSBTdG9ybSBHZW5lcmF0 aW9uOiBBcyBkZWZpbmVkIGVhcmxpZXIsICJMU0Egc3Rvcm0iIGlzIHRoZSANCg0KDQogQ2hvdWRo dXJ5IGV0LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDhdDQoMDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgRmxvb2RpbmcgU2ltdWxhdGlv biAgICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0Kc2ltdWx0YW5lb3VzIG9yIG5lYXIgc2ltdWx0 YW5lb3VzIGdlbmVyYXRpb24gb2YgYSBsYXJnZSBudW1iZXIgb2YgTFNBcy4NCkluIHRoZSBjYXNl IG9mIG9ubHkgUm91dGVyIGFuZCBBU0UgTFNBcyB3ZSBub3JtYWxseSBhc3N1bWUgdGhhdCB0aGUg DQpudW1iZXIgb2YgQVNFIExTQXMgaW4gdGhlIHN0b3JtIGlzIGFib3V0IDQgdGltZXMgdGhhdCBv ZiB0aGUgUm91dGVyIA0KTFNBcywgYnV0IHRoZSByYXRpbyBpcyBhbGxvd2VkIHRvIGNoYW5nZSBp ZiBlaXRoZXIgdGhlIFJvdXRlciBvciB0aGUgDQpBU0UgTFNBcyBoYXZlIHJlYWNoZWQgdGhlaXIg bWF4aW11bSBwb3NzaWJsZSB2YWx1ZS4gIEluIHRoZSBjYXNlIG9mIA0Kb25seSBSb3V0ZXIgYW5k IExpbmsgTFNBcyAoY2FycnlpbmcgdHJhZmZpYyBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbikgDQp3 ZSBub3JtYWxseSBhc3N1bWUgdGhhdCB0aGUgbnVtYmVyIG9mIExpbmsgTFNBcyBpbiB0aGUgc3Rv cm0gaXMgYWJvdXQgDQo0IHRpbWVzIHRoYXQgb2YgdGhlIFJvdXRlciBMU0FzLCBidXQgdGhlIHJh dGlvIGlzIGFsbG93ZWQgdG8gY2hhbmdlIA0KaWYgZWl0aGVyIHRoZSBSb3V0ZXIgb3IgdGhlIExp bmsgTFNBcyBoYXZlIHJlYWNoZWQgdGhlaXIgbWF4aW11bSANCnBvc3NpYmxlIHZhbHVlLiAgRm9y IGFueSBnaXZlbiBMU0Egc3Rvcm0gd2Uga2VlcCBnZW5lcmF0aW5nIExTQXMgDQpzdGFydGluZyBm cm9tIE5vZGUgaW5kZXggMSBhbmQgbW92aW5nIHVwd2FyZHMgYW5kIHN0b3AgdW50aWwgdGhlIA0K Y29ycmVjdCBudW1iZXIgb2YgTFNBcyBvZiBlYWNoIHR5cGUgaGF2ZSBiZWVuIGdlbmVyYXRlZC4g IFRoZSBMU0FzIA0KZ2VuZXJhdGVkIGF0IGFueSBnaXZlbiBub2RlIGlzIGFzc3VtZWQgdG8gc3Rh cnQgYXQgYW4gaW5zdGFudCANCnVuaWZvcm1seSBkaXN0cmlidXRlZCBiZXR3ZWVuIDIwIGFuZCAz MCBzZWNvbmRzIGZyb20gdGhlIHN0YXJ0IG9mIHRoZQ0Kc2ltdWxhdGlvbi4gIFN1Y2Nlc3NpdmUg TFNBIGdlbmVyYXRpb25zIGF0IGEgbm9kZSBhcmUgYXNzdW1lZCB0byBiZSANCnNwYWNlZCBhcGFy dCBieSA0MDAgbXMuIEl0IGlzIHRvIGJlIG5vdGVkIHRoYXQgZHVyaW5nIHRoZSBwZXJpb2Qgb2Yg DQpvYnNlcnZhdGlvbiB0aGVyZSBhcmUgb3RoZXIgTFNBcyBnZW5lcmF0ZWQgYmVzaWRlcyB0aGUg b25lcyBpbiB0aGUgDQpzdG9ybS4gIFRoZXNlIGluY2x1ZGUgcmVmcmVzaCBvZiBMU0FzIHRoYXQg YXJlIG5vdCBwYXJ0IG9mIHRoZSBzdG9ybSANCmFuZCBMU0FzIGdlbmVyYXRlZCBkdWUgdG8gcG9z c2libGUgbGluayBmYWlsdXJlcyBhbmQgc3Vic2VxdWVudCANCnBvc3NpYmxlIGxpbmsgcmVjb3Zl cmllcy4NCg0KRmFpbHVyZS9SZWNvdmVyeSBvZiBMaW5rczogSWYgbm8gSGVsbG8gaXMgcmVjZWl2 ZWQgb3ZlciBhIGxpbmsgKGR1ZSB0bw0KQ1BVL21lbW9yeSBjb25nZXN0aW9uKSBmb3IgbG9uZ2Vy IHRoYW4gUm91dGVyLURlYWQgSW50ZXJ2YWwgdGhlbg0KdGhlIGxpbmsgaXMgZGVjbGFyZWQgZG93 bi4gIEF0IGEgbGF0ZXIgdGltZSwgaWYgSGVsbG9zIGFyZSByZWNlaXZlZA0KdGhlbiB0aGUgbGlu ayB3b3VsZCBiZSBkZWNsYXJlZCB1cC4gIFdoZW5ldmVyIGEgbGluayBpcyBkZWNsYXJlZA0KdXAg b3IgZG93biwgb25lIFJvdXRlciBMU0EgaXMgZ2VuZXJhdGVkIGJ5IGVhY2ggUm91dGVyIG9uIHRo ZQ0KdHdvIHNpZGVzIG9mIHRoZSBwb2ludC10by1wb2ludCBsaW5rLiAgSWYgIkxpbmsgTFNBcyIg Y2FycnlpbmcNCnRyYWZmaWMgZW5naW5lZXJpbmcgaW5mb3JtYXRpb24gaXMgdXNlZCB0aGVuIGl0 IGlzIGFzc3VtZWQgdGhhdCBlYWNoDQpSb3V0ZXIgd291bGQgYWxzbyBnZW5lcmF0ZSBhIExpbmsg TFNBLiAgSW4gdGhpcyBjYXNlIGl0IGlzIGFsc28gYXNzdW1lZA0KdGhhdCBkdWUgdG8gcmVyb3V0 aW5nIG9mIExTUHMsIG9uZSBvdGhlciBsaW5rIGluIHRoZSBuZXR3b3JrDQooc2VsZWN0ZWQgcmFu ZG9tbHkgaW4gdGhlIHNpbXVsYXRpb24pIHdvdWxkIGhhdmUgc2lnbmlmaWNhbnQgY2hhbmdlIA0K aW4gcmVzZXJ2ZWQgYmFuZHdpZHRoIHdoaWNoIHdvdWxkIHJlc3VsdCBpbiBvbmUgTGluayBMU0Eg YmVpbmcNCmdlbmVyYXRlZCBieSB0aGUgcm91dGVycyBvbiB0aGUgdHdvIGVuZHMgb2YgdGhlIGxp bmsuDQoNCg0KNC4gU2ltdWxhdGlvbiBSZXN1bHRzDQoNCkluIHRoaXMgc2VjdGlvbiB3ZSBzdHVk eSB0aGUgcmVsYXRpdmUgcGVyZm9ybWFuY2Ugb2YgdGhlIGZpdmUNCmFsZ29yaXRobXMgd2l0aCBh IHJhbmdlIG9mIE5ldHdvcmsgc2l6ZXMsIExTQSB0eXBlcywgYW5kIHByb2Nlc3NpbmcgDQp0aW1l IHZhbHVlcyBhcyBleHBsYWluZWQgYmVsb3c6DQoNCk5ldHdvcmsgc2l6ZTogVHdvIG5ldHdvcmtz IGFyZSBjb25zaWRlcmVkLiAgTmV0d29yayAxIGhhcyAxMDAgbm9kZXMsIA0KMTIwMCBsaW5rcywg bWF4aW11bSBudW1iZXIgb2YgbmVpZ2hib3JzIHBlciBub2RlIGlzIDMwIGFuZCBtYXhpbXVtIA0K bnVtYmVyIG9mIGFkamFjZW5jaWVzIHBlciBub2RlIGlzIDUwIChzYW1lIG5laWdoYm9yIG1heSBo YXZlIG1vcmUgDQp0aGFuIG9uZSBhZGphY2VuY2llcykuICAgTmV0d29yayAyIGhhcyA1MCBub2Rl cywgNjAwIGxpbmtzLCBtYXhpbXVtIA0KbnVtYmVyIG9mIG5laWdoYm9ycyBwZXIgbm9kZSBpcyAy NSBhbmQgbWF4aW11bSBudW1iZXIgb2YgYWRqYWNlbmNpZXMgDQpwZXIgbm9kZSBpcyA0OC4gRGlq a3N0cmEgU1BGIGNhbGN1bGF0aW9uIHRpbWUgZm9yIE5ldHdvcmsgMSBpcyBhc3N1bWVkIA0KdG8g YmUgMTAwIG1zIGFuZCB0aGF0IGZvciBOZXR3b3JrIDIgaXMgYXNzdW1lZCB0byBiZSA3MCBtcy4N Cg0KDQoNCiBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCiBJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBGbG9v ZGluZyBTaW11bGF0aW9uICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQpMU0EgVHlwZTogRWFj aCBub2RlIGhhcyAxIFJvdXRlciBMU0EgKFRvdGFsIG9mIDEwMCBmb3IgTmV0d29yayAxIGFuZCAN CjUwIGZvciBOZXR3b3JrIDIpLiBUaGVyZSBhcmUgbm8gTmV0d29yayBMU0FzIHNpbmNlIGFsbCBs aW5rcyBhcmUgcG9pbnQtDQp0by1wb2ludCBsaW5rcyBhbmQgbm8gU3VtbWFyeSBMU0FzIHNpbmNl IHRoZSBuZXR3b3JrIGhhcyBvbmx5IG9uZSBhcmVhLg0KUmVnYXJkaW5nIG90aGVyIExTQSB0eXBl cyB3ZSBjb25zaWRlciB0d28gc2NlbmFyaW9zLiAgSW4gU2NlbmFyaW8gMSB3ZSANCmFzc3VtZSB0 aGF0IHRoZXJlIGFyZSBubyBBU0UgTFNBcyBhbmQgZWFjaCBsaW5rIGhhcyBvbmUgIkxpbmsiIExT QSANCmNhcnJ5aW5nIHRyYWZmaWMgZW5naW5lZXJpbmcgaW5mb3JtYXRpb24gKFRvdGFsIG9mIDI0 MDAgZm9yIE5ldHdvcmsgMSANCmFuZCAxMjAwIGZvciBOZXR3b3JrIDIpLiBJbiBTY2VuYXJpbyAy IHdlIGFzc3VtZSB0aGF0IHRoZXJlIGFyZSBubyANCiJMaW5rIiBMU0FzIGFuZCBoYWxmIG9mIHRo ZSBub2RlcyBhcmUgQVNBLUJvcmRlciBub2RlcyBhbmQgZWFjaCBib3JkZXIgDQpub2RlIGhhcyAx MCBBU0UgTFNBcyAoVG90YWwgb2YgNTAwIGZvciBOZXR3b3JrIDEgYW5kIDI1MCBmb3IgDQpOZXR3 b3JrIDIpLiAgV2UgaWRlbnRpZnkgU2NlbmFyaW8gMSBhcyAiTGluayBMU0FzIiBhbmQgU2NlbmFy aW8gMiBhcyANCiJBU0UgTFNBcyIuDQpQcm9jZXNzaW5nIHRpbWUgdmFsdWVzOiBQcm9jZXNzaW5n IHRpbWVzIGZvciBMU1VzLCBBY2tzIGFuZCBIZWxsbyANCnBhY2tldHMgaGF2ZSBiZWVuIHByZXZp b3VzbHkgZXhwcmVzc2VkIGluIHRlcm1zIG9mIGEgY29tbW9uIHBhcmFtZXRlciANClQuICBUaHJl ZSB2YWx1ZXMgYXJlIGNvbnNpZGVyZWQgZm9yIFQsIHdoaWNoIGFyZSAxIG1zLCAwLjUgbXMgYW5k IDIgbXMNCnJlc3BlY3RpdmVseS4NCg0KQmFzZWQgb24gTmV0d29yayBzaXplLCBMU0EgdHlwZSBh bmQgUHJvY2Vzc2luZyB0aW1lIHZhbHVlcyB3ZSBkZXZlbG9wDQo1IFRlc3QgY2FzZXMgYXMgZm9s bG93czoNCg0KQ2FzZSAxOiBOZXR3b3JrIDEsIExpbmsgTFNBcyBhbmQgVCA9IDEgbXMuDQoNCkNh c2UgMjogTmV0d29yayAxLCBBU0UgTFNBcyBhbmQgVCA9IDEgbXMuDQoNCkNhc2UgMzogTmV0d29y ayAxLCBMaW5rIExTQXMgYW5kIFQgPSAwLjUgbXMuDQoNCkNhc2UgNDogTmV0d29yayAxLCBMaW5r IExTQXMgYW5kIFQgPSAyIG1zLg0KDQpDYXNlIDU6IE5ldHdvcmsgMiwgTGluayBMU0FzIGFuZCBU ID0gMSBtcy4NCg0KRm9yIGVhY2ggY2FzZSBhbmQgZm9yIGVhY2ggYWxnb3JpdGhtIHdlIHN0dWR5 IHRoZSBuZXR3b3JrIHN0YWJpbGl0eSBhcw0KDQo9PT09PT09PT18PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICAgICAgICAgfCBOdW1i ZXIgb2YgTm9uLUNvbnZlcmdlZCBMU1VzIGluIHRoZSBOZXR3b3JrIGF0IFRpbWUoaW4gc2VjKQ0K ICAgIExTQSAgfCAgICAgICAgICAgICAgICAgICAgDQogICBTVE9STSB8PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICAgU0laRSAgfDEw cyAgIDIwcyAgIDMwcyAgIDM1cyAgIDQwcyAgIDUwcyAgIDYwcyAgIDgwcyAgIDEwMHMNCj09PT09 PT09PXw9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQogICAgNTAgICB8IDAgICAgIDAgICAgIDkgICAgMTAgICAgIDAgICAgIDAgICAgIDAg ICAgIDAgICAgIDENCiAoU3RhYmxlKXwNCi0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgMTAwICB8IDAgICAgIDAg ICAgMjQgICAgMjkgICAgMjYgICAgMjEgICAgIDggICAgIDEgICAgIDENCiAoU3RhYmxlKXwNCi0t LS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQogICAgMTMwICB8IDAgICAgIDAgICAgMzEgICAgNDUgICAgNDIgICAgNDEgICAg MzggICAgMTI3ICAgMjM3DQooVW5zdGFibGUpDQo9PT09PT09PT18PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQogICAgVGFibGUgMTog TmV0d29yayBTdGFiaWxpdHkgVnMuIExTQSBTdG9ybSAoQ2FzZSAxLCBBbGdvcml0aG0gMSkNCg0K DQoNCiBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMTBdDQoMDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgRmxvb2Rp bmcgU2ltdWxhdGlvbiAgICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0KYSBmdW5jdGlvbiBvZiB0 aGUgc2l6ZSBvZiB0aGUgTFNBIHN0b3JtLiAgVGhlIHN0YWJpbGl0eSBpcyBkZXRlcm1pbmVkIA0K YnkgbG9va2luZyBhdCB0aGUgbnVtYmVyIG9mIG5vbi1jb252ZXJnZWQgTFNVcyBhcyBhIGZ1bmN0 aW9uIG9mIHRpbWUuICANCkFuIGV4YW1wbGUgaXMgc2hvd24gaW4gVGFibGUgMSBmb3IgQ2FzZSAx IGFuZCBBbGdvcml0aG0gMS4gIA0KDQpUaGUgTFNBIHN0b3JtIHN0YXJ0cyBhIGxpdHRsZSBhZnRl ciAyMCBzZWNvbmRzIGFuZCBzbyBmb3Igc29tZSBwZXJpb2QNCm9mIHRpbWUgYWZ0ZXIgdGhhdCB0 aGUgDQpudW1iZXIgb2Ygbm9uLWNvbnZlcmdlZCBMU1VzIHNob3VsZCBzdGF5IGhpZ2ggYW5kIHRo ZW4gY29tZSBkb3duIGZvciBhIA0Kc3RhYmxlIG5ldHdvcmsuICBUaGlzIGhhcHBlbnMgZm9yIExT QSBzdG9ybXMgb2Ygc2l6ZXMgNTAgYW5kIDEwMC4gIFdpdGggDQphbiBMU0Egc3Rvcm0gb2Ygc2l6 ZSAxMzAsIHRoZSBudW1iZXIgb2Ygbm9uLWNvbnZlcmdlZCBMU0FzIHN0YXkgaGlnaA0KaW5kZWZp bml0ZWx5IGR1ZSB0byByZXBlYXRlZCByZXRyYW5zbWlzc2lvbnMsIGxpbmsgZmFpbHVyZXMgZHVl IHRvIA0KbWlzc2VkIEhlbGxvcyBmb3IgbW9yZSB0aGFuIHRoZSBSb3V0ZXItRGVhZCBpbnRlcnZh bCB3aGljaCBnZW5lcmF0ZXMgDQphZGRpdGlvbmFsIExTQXMgYW5kIGFsc28gZHVlIHRvIHN1YnNl cXVlbnQgbGluayByZWNvdmVyaWVzIHdoaWNoIGFnYWluIA0KZ2VuZXJhdGUgYWRkaXRpb25hbCBM U0FzLiAgSXQgdHVybnMgb3V0IHRoYXQgZm9yIHRoaXMgZXhhbXBsZSB0aGUgDQptYXhpbXVtIExT QSBzdG9ybSBzaXplIHRoYXQgc3RpbGwga2VlcHMgdGhlIG5ldHdvcmsgc3RhYmxlIGlzIDExNS4g IA0KDQp8PT09PT09PT09PT18PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT18DQp8ICAgICAgICAgICB8ICAgIE1heGltdW0gQWxsb3dhYmxlIExT QSBTdG9ybSBTaXplIEZvciAgICAgICAgICAgICAgICB8DQp8QWxnb3JpdGhtICB8PT09PT09PT09 PXw9PT09PT09PT09fD09PT09PT09PT09fD09PT09PT09PT18PT09PT09PT09PT18DQp8ICBUeXBl ICAgICB8IENhc2UgMSAgIHwgICBDYXNlIDIgfCAgQ2FzZSAzICAgfCAgQ2FzZSA0ICB8ICBDYXNl IDUgICB8DQp8ICAgICAgICAgICB8KE5ldC4gMSwgIHwgKE5ldC4gMSwgfCAoTmV0LiAxLCAgfCAo TmV0LiAxLCB8IChOZXQuIDIsICB8DQp8ICAgICAgICAgICB8TGluayBMU0FzLHwgQVNFIExTQXMs fCBMaW5rIExTQXMsfExpbmsgTFNBcyx8IExpbmsgTFNBcyx8DQp8ICAgICAgICAgICB8IFQgPSAx IG1zKXwgVCA9IDEgbXMpfFQgPSAwLjUgbXMpfCBUID0gMiBtcyl8IFQgPSAxIG1zKSB8DQp8PT09 PT09PT09PT18PT09PT09PT09PXw9PT09PT09PT09fD09PT09PT09PT09fD09PT09PT09PT18PT09 PT09PT09PT18DQp8QWxnb3JpdGhtIDF8ICAgMTE1ICAgIHwgICAxMzAgICAgfCAgIDI3NSAgICAg fCAgICAgMjUgICB8ICAgIDEzOCAgICB8DQp8KEZ1bGwgRmxkLil8ICAgICAgICAgIHwgICAgICAg ICAgfCAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICB8DQp8X19fX19fX19fX198X19f X19fX19fX3xfX19fX19fX19ffF9fX19fX19fX19ffF9fX19fX19fX198X19fX19fX19fX198DQp8 QWxnb3JpdGhtIDJ8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8 ICAgICAgICAgICB8DQp8KEZsZC4gT3ZlciB8ICAgMjM4ICAgIHwgICAyNDMgICAgfCAgIDYxMCAg ICAgfCAgICAgODUgICB8ICAgIDQ1MCAgICB8DQp8T25lIFBhcmFsbC58ICAgICAgICAgIHwgICAg ICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICB8DQp8IExpbmspICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICB8 DQp8X19fX19fX19fX198X19fX19fX19fX3xfX19fX19fX19ffF9fX19fX19fX19ffF9fX19fX19f X198X19fX19fX19fX198DQp8QWxnb3JpdGhtIDN8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAg ICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICB8DQp8KEFsZy4gMiArICB8ICAgMjQ4ICAgIHwg ICAyNDkgICAgfCAgIDY0NSAgICAgfCAgICAgOTAgICB8ICAgIDQ1MCAgICB8DQp8TXVsdGlwb2lu dCB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAg ICB8DQp8UmVsYXkpICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgfCAgICAg ICAgICB8ICAgICAgICAgICB8DQp8X19fX19fX19fX198X19fX19fX19fX3xfX19fX19fX19ffF9f X19fX19fX19ffF9fX19fX19fX198X19fX19fX19fX198DQp8QWxnb3JpdGhtIDR8ICAgICAgICAg IHwgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICB8DQp8IChBbGcu IDIgKyB8IEZ1bGwgTFNEQnwgRnVsbCBMU0RCfCBGdWxsIExTREIgfCAgICAxODI1ICB8IEZ1bGwg TFNEQiB8DQp8RmxkLiBPdmVyICB8ICAgKDI1MDApIHwgICg2MDApICAgfCAgICgyNTAwKSAgfCAg ICAgICAgICB8ICAgICgxMjUwKSB8DQp8U3Bhbi4gVHJlZSl8ICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICB8DQp8X19fX19fX19fX198X19fX19f X19fX3xfX19fX19fX19ffF9fX19fX19fX19ffF9fX19fX19fX198X19fX19fX19fX198DQp8QWxn b3JpdGhtIDV8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8ICAg ICAgICAgICB8DQp8KEFsZy4gMiBGb3J8IEZ1bGwgTFNEQnwgRnVsbCBMU0RCfCBGdWxsIExTREIg fCAgICA2MjUgICB8IEZ1bGwgTFNEQiB8DQp8VHlwZSBBLCBBbGd8ICAgKDI1MDApIHwgICg2MDAp ICAgfCAgICgyNTAwKSAgfCAgICAgICAgICB8ICAgICgxMjUwKSB8ICANCnw0IEZvciBUeXBlIHwg ICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgIHwN CnxCIExTQXMgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAg IHwgICAgICAgICAgIHwNCnxfX19fX19fX19fX3xfX19fX19fX19ffF9fX19fX19fX198X19fX19f X19fX198X19fX19fX19fX3xfX19fX19fX19fX3wNCg0KICAgIFRhYmxlIDI6IE1heGltdW0gQWxs b3dhYmxlIExTQSBTdG9ybSBmb3IgYSBTdGFibGUgTmV0d29yaw0KDQoNCiBDaG91ZGh1cnkgZXQu IGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTFd DQoMDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgRmxvb2RpbmcgU2ltdWxhdGlvbiAgICAg ICAgICAgICAgTWF5LCAyMDAzDQoNCg0KVGhpcyBzdGFiaWxpdHkgdGhyZXNob2xkIGRlcGVuZHMg b24gdGhlIENhc2UgYW5kIHRoZSBBbGdvcml0aG0gdW5kZXINCmNvbnNpZGVyYXRpb24uIEEgYmV0 dGVyIGFsZ29yaXRobSBzaG91bGQgYWxsb3cgYSBoaWdoZXIgc3RhYmlsaXR5IA0KdGhyZXNob2xk LiAgDQoNCkluIFRhYmxlIDIgd2Ugc2hvdyB0aGUgbWF4aW11bSBhbGxvd2FibGUgTFNBIHN0b3Jt IHNpemUgdGhhdCB3b3VsZCANCnN0aWxsIGtlZXAgdGhlIG5ldHdvcmsgc3RhYmxlIGZvciB0aGUg Zml2ZSBkaWZmZXJlbnQgY2FzZXMgYW5kIGZvciANCnRoZSBmaXZlIGRpZmZlcmVudCBhbGdvcml0 aG1zLg0KDQo1LiBTdW1tYXJ5IG9mIE9ic2VydmF0aW9ucw0KDQpDb21wYXJpc29uIG9mIEFsZ29y aXRobSAyIGFuZCBBbGdvcml0aG0gMTogIFdlIG9ic2VydmUgdGhhdCBpbiBhbGwgDQpjYXNlcyBp biBUYWJsZSAyLCBBbGdvcml0aG0gMiBzdWJzdGFudGlhbGx5IGluY3JlYXNlcyAodXN1YWxseSBi eSBhIA0KZmFjdG9yIG9mIHR3byBvciBtb3JlKSB0aGUgbWF4aW11bSBMU0Egc3Rvcm0gdGhyZXNo b2xkIG9mIHRoZSBuZXR3b3JrIA0KY29tcGFyZWQgdG8gQWxnb3JpdGhtIDIuICBUaGlzIGltcGxp ZXMgdGhhdCBmbG9vZGluZyBvdmVyIG9ubHkgb25lIG9mIA0KbWFueSBwYXJhbGxlbCBsaW5rcyBi ZXR3ZWVuIG5vZGVzIGhhcyBjbGVhciBiZW5lZmljaWFsIGltcGFjdCBpbiB0ZXJtcyANCm9mIGlt cHJvdmluZyBuZXR3b3JrIHNjYWxhYmlsaXR5IGFuZCBzdGFiaWxpdHkgYW5kIG91Z2h0IHRvIGJl IHB1cnN1ZWQuDQpDb21wYXJpc29uIG9mIEFsZ29yaXRobSAzIGFuZCBBbGdvcml0aG0gMjogVGhl IE11bHRpcG9pbnQgcmVsYXkgDQptZWNoYW5pc20gdXNlZCBpbiBBbGdvcml0aG0gMyBpbmNyZWFz ZXMgdGhlIExTQSBzdG9ybSB0aHJlc2hvbGQNCihjb21wYXJlZCB0byBBbGdvcml0aG0gMikNCmJ1 dCBieSBhIG1vZGVyYXRlIGFtb3VudC4gT25lIHJlYXNvbiBmb3IgdGhpcyBtb2RlcmF0ZSBpbXBy b3ZlbWVudA0KaXMgdGhhdCBldmVuIHRob3VnaCB0aGUgbXVsdGlwb2ludCByZWxheSBtZWNoYW5p c20gY2FuIHNpZ25pZmljYW50bHkNCnJlZHVjZSB0aGUgb3ZlcmFsbCBhbW91bnQgb2YgZmxvb2Rp bmcgaW4gdGhlIG5ldHdvcmssIGl0IGFwcGVhcnMgdGhhdCANCnRoZSBub2RlcyB3aXRoIGhpZ2hl c3QgbnVtYmVyIG9mIG5laWdoYm9ycyB0ZW5kIHRvIGJlIG1vcmUgbGlrZWx5DQp0byBiZSBjaG9z ZW4gYXMgbXVsdGlwb2ludCByZWxheXMgYnkgdGhlaXIgbmVpZ2hib3JzLiAgQXMgYW4gZXhhbXBs ZSwNCmluIE5ldHdvcmsgMSAoQ2FzZXMgMS00IGluIFRhYmxlIDIpIG9uIHRoZSBhdmVyYWdlIGEg bm9kZSBjaG9vc2VzDQo3MCUgb2YgaXRzIG5laWdoYm9ycyBhcyBtdWx0aXBvaW50IHJlbGF5cy4g IEhvd2V2ZXIsIHRoZSBub2RlIHdpdGgNCmhpZ2hlc3QgbnVtYmVyIG9mIG5laWdoYm9ycyAoMzAp LCBpcyBjaG9zZW4gYXMgYSBtdWx0aXBvaW50IHJlbGF5DQpieSAyNyBvdXQgb2YgdGhlIDMwIChp LmUuLCA5MCUpIG9mIGl0cyBuZWlnaGJvcnMuICBUaGlzIG5vZGUsIGR1ZQ0KdG8gaXRzIGxhcmdl IG51bWJlciBvZiBuZWlnaGJvcnMsIGFsc28gaGFwcGVucyB0byBiZSB0aGUgYm90dGxlbmVjaw0K aW4gdGVybXMgb2YgZGV0ZXJtaW5pbmcgTFNBIHN0b3JtIHRocmVzaG9sZCBhbmQgc2luY2UgaXRz IGVmZmVjdGl2ZQ0KbnVtYmVyIG9mIG5laWdoYm9ycyAodGhlIG9uZXMgdGhhdCBhc2sgaXQgdG8g Zmxvb2QgZnVydGhlcikgZ29lcw0KZG93biBvbmx5IHNsaWdodGx5LCB0aGUgb3ZlcmFsbCBpbXBy b3ZlbWVudCBpbiBMU0Egc3Rvcm0gdGhyZXNob2xkDQppcyBtb2RlcmF0ZS4gIEluIE5ldHdvcmsg MiAoQ2FzZSA1IGluIFRhYmxlIDIpIGFsbCBuZWlnaGJvcnMgb2YgdGhlDQpoaWdoZXN0IGFkamFj ZW5jeSBub2RlIGVsZWN0IHRoaXMgbm9kZSBhcyBtdWx0aXBvaW50IHJlbGF5cyBhbmQgDQp0aGVy ZWZvcmUgdGhlcmUgaXMgbm8gaW1wcm92ZW1lbnQgaW4gTFNBIHN0b3JtIHRocmVzaG9sZC4NCg0K Q29tcGFyaXNvbiBvZiBBbGdvcml0aG0gNCBhbmQgQWxnb3JpdGhtIDI6IENvbXBhcmVkIHRvIEFs Z29yaXRobSAyLA0KQWxnb3JpdGhtIDQgYWx3YXlzIHJhaXNlcyB0aGUgTFNBIHN0b3JtIHRocmVz aG9sZCBzdWJzdGFudGlhbGx5IGFuZA0KaW4gZm91ciBvdXQgb2YgdGhlIGZpdmUgY2FzZXMgdGhl IExTQSBzdG9ybSB0aHJlc2hvbGQgaXMgcmFpc2VkIHRvDQppdHMgbWF4aW11bSB2YWx1ZSwgaS5l LiwgaXQgaXMgT0sgdG8gZmxvb2QgYWxsIExTQXMgaW4gdGhlIExTREIgb3Zlcg0KYSBzaG9ydCBw ZXJpb2Qgb2YgdGltZS4gIEhvd2V2ZXIsIG9uZSBpc3N1ZSB3aXRoIEFsZ29yaXRobSA0IGlzIHRo YXQNCmlmIGEgbGluayBvbiB0aGUgbWluaW11bSBzcGFubmluZyB0cmVlIGZhaWxzLCBtYW55IG5v ZGVzIG1heSBub3QgZ2V0DQp0aGUgcmVxdWlyZWQgTFNBcyBjYXJyeWluZyB0aGUgdG9wb2xvZ3kg aW5mb3JtYXRpb24gYW5kIGl0IHdvdWxkIGJlIA0KZGlmZmljdWx0IGZvciB0aGVtIHRvIHJlY29t cHV0ZSB0aGUgbmV3IG1pbmltdW0gc3Bhbm5pbmcgdHJlZS4gIEluIHRoZSANCnNpbXVsYXRpb24g d2UgcmUtY29tcHV0ZWQgdGhlIG1pbmltdW0gc3Bhbm5pbmcgdHJlZSBiYXNlZCBvbiBnbG9iYWwg DQprbm93bGVkZ2UgdW5kZXIgZmFpbHVyZSBjb25kaXRpb25zLg0KDQpDb21wYXJpc29uIG9mIEFs Z29yaXRobSA1IGFuZCBBbGdvcml0aG0gMjogQ29tcGFyZWQgdG8gQWxnb3JpdGhtIDIsDQpBbGdv cml0aG0gNSBhbHdheXMgcmFpc2VzIHRoZSBMU0Egc3Rvcm0gdGhyZXNob2xkIHN1YnN0YW50aWFs bHkgYW5kDQoNCg0KIENob3VkaHVyeSBldC4gYWwuICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCiBJbnRlcm5ldCBEcmFmdCAgICAgICAgICAg ICBGbG9vZGluZyBTaW11bGF0aW9uICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQppbiBmb3Vy IG91dCBvZiB0aGUgZml2ZSBjYXNlcyB0aGUgTFNBIHN0b3JtIHRocmVzaG9sZCBpcyByYWlzZWQg dG8NCml0cyBtYXhpbXVtIHZhbHVlLCBpLmUuLCB0aGUgZnVsbCBMU0RCIHNpemUuICBUaGlzIEFs Z29yaXRobSBpcw0Kd29yc2UgdGhhbiBBbGdvcml0aG0gNCBpbiB0ZXJtcyBvZiBtYXhpbXVtIExT QSBzdG9ybSB0aHJlc2hvbGQgKGFzIA0Kc2hvd24gaW4gQ2FzZSA0KSBidXQgbXVjaCBiZXR0ZXIg dGhhbiBBbGdvcml0aG1zIDEsIDIgYW5kIDMuICBJdCBpcyANCmFsc28gbW9yZSByb2J1c3QgdGhh biBBbGdvcml0aG0gNCB1bmRlciBsaW5rIGZhaWx1cmUgY29uZGl0aW9ucy4gRXZlbiANCmlmIGEg bGluayBvbiB0aGUgbWluaW11bSBzcGFubmluZyB0cmVlICBmYWlscywgdGhvc2UgY2Fycnlpbmcg aW50cmEtDQphcmVhIHRvcG9sb2d5IGluZm9ybWF0aW9uIChkZWZpbmVkIGVhcmxpZXIgYXMgVHlw ZSBBIExTQXMpIHdvdWxkIA0KY29udGludWUgdG8gZ2V0IHRvIGFsbCBkZXN0aW5hdGlvbnMgc2lu Y2UgdGhleSBhcmUgZmxvb2RlZCBhcyBpbiANCkFsZ29yaXRobSAyIChmdWxsIGZsb29kaW5nIGJ1 dCBvdmVyIG9ubHkgb25lIGludGVyZmFjZSBiZXR3ZWVuIA0KbmVpZ2hib3JzKS4gT25jZSBhbGwg dGhlIG5vZGVzIGtub3cgYWJvdXQgdGhlIGxpbmsgZmFpbHVyZSBjb25kaXRpb24sIA0KdGhleSB3 b3VsZCBiZSBhYmxlIHRvIHJlLWNvbXB1dGUgdGhlIG5ldyBtaW5pbXVtIHNwYW5uaW5nIHRyZWUu DQoNCk92ZXJhbGwgT2JzZXJ2YXRpb246IEl0IGFwcGVhcnMgdGhhdCBBbGdvcml0aG0gMiAoZnVs bCBmbG9vZGluZyBidXQNCm9ubHkgb3ZlciBvbmUgb2YgbWFueSBwYXJhbGxlbCBpbnRlcmZhY2Vz IGJldHdlZW4gbmVpZ2hib3JzKSBhbmQNCkFsZ29yaXRobSA1IChmbG9vZGluZyBhcyBpbiBBbGdv cml0aG0gMiBmb3IgTFNBcyBjYXJyeWluZyBpbnRyYS1hcmVhDQp0b3BvbG9neSBpbmZvcm1hdGlv biBhbmQgZmxvb2Rpbmcgb3ZlciBhIG1pbmltdW0gc3Bhbm5pbmcgdHJlZSBmb3INCm90aGVyIExT QXMpIGFyZSB0aGUgYmVzdCBvbmVzIGFuZCBzaG91bGQgYmUgcHVyc3VlZCBmdXJ0aGVyIGZvcg0K ZGV0YWlsZWQgc3BlY2lmaWNhdGlvbi4gICAgICAgICAgICAgDQoNCg0KNi4gQWNrbm93bGVkZ2Vt ZW50cw0KDQpXZSB3b3VsZCBsaWtlIHRvIGFja25vd2xlZGdlIEplcnJ5IEFzaCwgTWFyZ2FyZXQg Q2hpb3NpLCBFbGllIEZyYW5jaXMsDQpBbnVyYWcgTWF1bmRlciwgQmV0aCBNdW5zb24sIE1vc2hl IFNlZ2FsLCBWZXJhIFNhcG96aG5pa292YSwgYW5kIFBhdCANCldpcnRoIGZvciBjb2xsYWJvcmF0 aW9uIGFuZCBlbmNvdXJhZ2VtZW50IGluIG91ciBzY2FsYWJpbGl0eSANCmltcHJvdmVtZW50IGVm Zm9ydHMgZm9yIExpbmstU3RhdGUtUHJvdG9jb2wgYmFzZWQgbmV0d29ya3MuICBXZSBhbHNvDQp0 aGFuayBBbWFuIFNoYWlraCBhbmQgTW9zaGUgU2VnYWwgZm9yIGNvbW1lbnRzIG9uIHRoaXMgZHJh ZnQuDQoNCjcuIFJlZmVyZW5jZXMNCg0KICAgW1JlZjFdIFBhcHBhbGFyZG8sIEQuLCJBVCZULCBj dXN0b21lcnMgZ3JhcHBsZSB3aXRoIEFUTSBuZXQgb3V0YWdlLCINCiAgIE5ldHdvcmsgV29ybGQs IEZlYnJ1YXJ5IDI2LCAyMDAxLg0KDQogICBbUmVmMl0gIkFUJlQgYW5ub3VuY2VzIGNhdXNlIG9m IGZyYW1lLXJlbGF5IG5ldHdvcmsgb3V0YWdlLCIgQVQmVCANCiAgIFByZXNzIFJlbGVhc2UsIEFw cmlsIDIyLCAxOTk4Lg0KDQogICBbUmVmM10gQ2hvbGV3a2EsIEsuLCAiTUNJIE91dGFnZSBIYXMg RG9taW5vIEVmZmVjdCwiIEludGVyQGN0aXZlIA0KICAgV2VlaywgQXVndXN0IDIwLCAxOTk5Lg0K DQogICBbUmVmNF0gSmFuZGVyLCBNLiwgIkluIFF3ZXN0IE91dGFnZSwgQVRNIFRha2VzIFNvbWUg SGVhdCwiIExpZ2h0DQogICBSZWFkaW5nLCBBcHJpbCA2LCAyMDAxLg0KDQogICBbUmVmNV0gQS4g WmluaW4gYW5kIE0uIFNoYW5kLCAiRmxvb2RpbmcgT3B0aW1pemF0aW9ucyBpbiBMaW5rLVN0YXRl DQogICBSb3V0aW5nIFByb3RvY29scywiIFdvcmsgaW4gUHJvZ3Jlc3MuDQoNCiAgIFtSZWY2XSBK LiBNb3ksICJGbG9vZGluZyBvdmVyIFBhcmFsbGVsIFBvaW50LXRvLVBvaW50IExpbmtzLCIgV29y ayBpbg0KICAgcHJvZ3Jlc3MuDQogICANCiAgIFtSZWY3XSBQLiBQaWxsYXktRXNuYXVsdCwgIk9T UEYgUmVmcmVzaCBhbmQgZmxvb2RpbmcgcmVkdWN0aW9uIGluICANCg0KDQogQ2hvdWRodXJ5IGV0 LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEz XQ0KDA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgIEZsb29kaW5nIFNpbXVsYXRpb24gICAg ICAgICAgICAgIE1heSwgMjAwMw0KDQoNCiAgIHN0YWJsZSB0b3BvbG9naWVzLCIgV29yayBpbiBw cm9ncmVzcy4NCg0KICAgW1JlZjhdIEcuIENob3VkaHVyeSwgVi4gU2Fwb3pobmlrb3ZhLCBBLiBN YXVuZGVyIGFuZCBWLiBNYW5yYWwsDQogICAiRXhwbGljaXQgTWFya2luZyBhbmQgUHJpb3JpdGl6 ZWQgVHJlYXRtZW50IG9mIFNwZWNpZmljIElHUA0KICAgUGFja2V0cyBmb3IgRmFzdGVyIElHUCBD b252ZXJnZW5jZSBhbmQgSW1wcm92ZWQgTmV0d29yayBTY2FsYWJpbGl0eSANCiAgIGFuZCBTdGFi aWxpdHksIiBXb3JrIGluIFByb2dyZXNzLg0KDQogICBbUmVmOV0gSi4gQXNoLCBHLiBDaG91ZGh1 cnksIFYuIFNhcG96aG5pa292YSwgTS4gU2hlcmlmLCBBLiBNYXVuZGVyLCANCiAgIFYuIE1hbnJh bCwgIkNvbmdlc3Rpb24gQXZvaWRhbmNlICYgQ29udHJvbCBmb3IgT1NQRiBOZXR3b3JrcyIsDQog ICBXb3JrIGluIFByb2dyZXNzLg0KDQogICBbUmVmMTBdICJQcml2YXRlIE5ldHdvcmstdG8tTmV0 d29yayBJbnRlcmZhY2UiLCBBVE0gRm9ydW0gDQogICBTcGVjaWZpY2F0aW9uIGFmLXBubmktMDA1 NS4wMDAsIE1hcmNoLCAxOTk2Lg0KDQogICBbUkVGMTFdIEEuIFFheXl1bSwgTC4gVmllbm5vdCwg QS4gTGFvdWl0aSwgIk11bHRpcG9pbnQgUmVsYXlpbmcgZm9yIA0KICAgRmxvb2RpbmcgQnJvYWRj YXN0IE1lc3NhZ2VzIGluIE1vYmlsZSBXaXJlbGVzcyBOZXR3b3JrcywiIFByb2plY3QNCiAgIEhp cGVyY29tLCBJTlJJQSBSb2NxdWVuY291cnQsIEZyYW5jZS4NCg0KICAgW1JlZjEyXSBELiBLYXR6 LCBELiBZZXVuZywgSy4gS29tcGVsbGEsICJUcmFmZmljIEVuZ2luZWVyaW5nIA0KICAgRXh0ZW5z aW9ucyB0byBPU1BGIFZlcnNpb24gMiwiIFdvcmsgaW4gcHJvZ3Jlc3MuDQoNCiAgIFtSZWYxM10g Qi4gTS4gV2F4bWFuLCAiUm91dGluZyBvZiBNdWx0aXBvaW50IENvbm5lY3Rpb25zLCIgSUVFRQ0K ICAgSm91cm5hbCBvbiBTZWxlY3RlZCBBcmVhcyBpbiBDb21tdW5pY2F0aW9ucywgNig5KToxNjE3 LTE2MjIsIDE5ODguDQoNCg0KDQo4LiBBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgR2FnYW4gTC4g Q2hvdWRodXJ5DQoNCiAgIEFUJlQNCiAgIFJvb20gRDUtM0MyMQ0KICAgMjAwIExhdXJlbCBBdmVu dWUNCiAgIE1pZGRsZXRvd24sIE5KLCAwNzc0OA0KICAgVVNBDQogICBQaG9uZTogKDczMik0MjAt MzcyMQ0KICAgZW1haWw6IGdjaG91ZGh1cnlAYXR0LmNvbQ0KICAgDQogICANCiAgIFZpc2h3YXMg TWFucmFsDQogICBOZXRwbGFuZQ0KICAgMTg5LCBQcmFzaGFzYW4gTmFnYXIsDQogICBSb2FkIE51 bWJlciA3Mg0KICAgSnViaWxlZSBIaWxscywgSHlkZXJhYmFkDQogICBJbmRpYQ0KICAgZW1haWw6 IFZpc2h3YXNtQG5ldHBsYW5lLmNvbQ0KICAgICANCg0KDQoNCg0KIENob3VkaHVyeSBldC4gYWwu ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCg== ------_=_NextPart_001_01C281E7.A317630A-- From owner-ospf@DISCUSS.MICROSOFT.COM Sat Nov 2 01:35:04 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18821 for ; Sat, 2 Nov 2002 01:35:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.007A5545@cherry.ease.lsoft.com>; Sat, 2 Nov 2002 1:37:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 308860 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 2 Nov 2002 01:37:27 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 2 Nov 2002 01:37:27 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HP4J1>; Sat, 2 Nov 2002 01:37:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 2 Nov 2002 01:39:38 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Steve, A simlar question was asked on the list earlier. Check http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A1=ind0208&L=ospf topic "Usage of OSPF". That could be of interest to you, though may not get exact statistics. Thanks, Vishwas -----Original Message----- From: Steve Mastrorilli [mailto:stevem@BLUEJAVELIN.NET] Sent: Saturday, November 02, 2002 12:47 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Does anyone know what the percentage breakdown is of OSPF vs. xGRP (IGRP & EIGRP) networks US or worldwide? I realize there may be some RIP, RIPv2, etc. but I am assuming that there probably isn't as much of those networks as OSPF or xIGRP. Thanks From owner-ospf@DISCUSS.MICROSOFT.COM Mon Nov 4 09:58:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15444 for ; Mon, 4 Nov 2002 09:58:58 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.007A9622@cherry.ease.lsoft.com>; Mon, 4 Nov 2002 10:01:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 314814 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 4 Nov 2002 10:01:17 -0500 Received: from 192.114.186.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 4 Nov 2002 09:51:17 -0500 Received: from tal (adsl-ayalon-oc-113-227.inter.net.il [213.8.113.227]) by diana.inter.net.il (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id API26748; Mon, 4 Nov 2002 16:50:58 +0200 (IST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01C28422.6EA4E510" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <006d01c28411$b834be50$002010ac@infit.com> Date: Mon, 4 Nov 2002 16:51:33 +0200 Reply-To: Mailing List Sender: Mailing List From: Tal Sarfaty Subject: Tunnels and OSPF. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_006A_01C28422.6EA4E510 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Is it possible to force the traffic flowing between the OSPF backbone = and one of the other areas, to go through a tunnel (for VPN purpose for = instance)? That is without the use of externals and without the use of static = routes of course. The topology can be addressed as a classic "Normal areas" "no summary" = single OSPF AS, or any other. Note that the naive solution would create a "recursive routing" to the = destination address of the tunnel. The last would cause tunnel oscillations. Thanks, Tal. ------=_NextPart_000_006A_01C28422.6EA4E510 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Is it possible to = force the=20 traffic flowing between the OSPF backbone and one of the other = areas, to go through a tunnel (for VPN = purpose for=20 instance)?

That is without the = use of=20 externals and without the use of static routes of course.

The topology can be = addressed as=20 a classic "Normal=20 areas" "no summary" single OSPF AS, or any=20 other.

 

Note that the naive solution would = create a=20 "recursive routing" to the destination address of the tunnel.

The last would cause tunnel = oscillations.

 

Thanks,

Tal.

 

 

 

------=_NextPart_000_006A_01C28422.6EA4E510-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Nov 4 13:07:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26269 for ; Mon, 4 Nov 2002 13:07:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.007A9C0B@cherry.ease.lsoft.com>; Mon, 4 Nov 2002 13:09:45 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 315500 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 4 Nov 2002 13:09:45 -0500 Received: from 128.96.41.1 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 4 Nov 2002 13:09:45 -0500 Received: from research.telcordia.com (ar8-206 [192.4.8.206]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id gA4I9bwD003461 for ; Mon, 4 Nov 2002 13:09:38 -0500 (EST) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <006d01c28411$b834be50$002010ac@infit.com> Content-Type: multipart/alternative; boundary="------------A49497AA5DFE69F56B6BA9D0" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Message-ID: <3DC6B7E0.1EBD8147@research.telcordia.com> Date: Mon, 4 Nov 2002 13:09:36 -0500 Reply-To: Mailing List Sender: Mailing List From: Sanjai Narain Subject: Re: Tunnels and OSPF. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --------------A49497AA5DFE69F56B6BA9D0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tal: One solution that we have successfully tried is to define the VPN as a collection of GRE tunnels. Each GRE tunnel G is protected by an IPSec tunnel between G's physical interfaces. Now, a new OSPF process is run at each router, distinct from any other OSPF process running there. This process will only see the network of GRE tunnels, and thereby route and reroute only over these. GRE gives OSPF the illusion that tunnel end points are directly connected (as intended), so you get routing over your -secure- overlay nework. The overlay OSPF process must be a new one to avoid routing loops. This is a well known solution and typing GRE/OSPF/IPSec into Google will yield numerous case studies. -- Sanjai Narain Tal Sarfaty wrote: > Is it possible to force the traffic flowing between the OSPF backbone > and one of the other areas, to go through a tunnel (for VPN purpose > for instance)? > > That is without the use of externals and without the use of static > routes of course. > > The topology can be addressed as a classic " st1 ns = "urn:schemas-microsoft-com:office:smarttags" />Normal areas" > "no summary" single OSPF AS, or any other. > > > Note that the naive solution would create a "recursive routing" to the > destination address of the tunnel. > > The last would cause tunnel oscillations. > > Thanks, > > Tal. > > -- Sanjai Narain Senior Research Scientist Telcordia Technologies 445 South Street Morristown, NJ 07960 USA Tel: +1 973 829 4515 Fax: +1 973 829 5888 Email: narain@research.telcordia.com --------------A49497AA5DFE69F56B6BA9D0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Tal: One solution that we have successfully tried is to define the VPN as a collection of GRE tunnels. Each GRE tunnel G  is protected by an IPSec tunnel between G's physical interfaces. Now, a new OSPF process is run at each router, distinct from any other OSPF process running there. This process will only see the network of GRE tunnels, and thereby route and reroute only over these. GRE gives OSPF the illusion that tunnel end points are directly connected (as intended), so you get routing over your -secure- overlay nework. The overlay OSPF process must be a new one to avoid routing loops. This is a well known solution and typing GRE/OSPF/IPSec into Google will yield numerous case studies.

-- Sanjai Narain

Tal Sarfaty wrote:

Is it possible to force the traffic flowing between the OSPF backbone and one of the other areas, to go through a tunnel (for VPN purpose for instance)?

That is without the use of externals and without the use of static routes of course.

The topology can be addressed as a classic "<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />Normal areas" "no summary" single OSPF AS, or any other.


Note that the naive solution would create a "recursive routing" to the destination address of the tunnel.

The last would cause tunnel oscillations.

Thanks,

Tal.


--
   Sanjai Narain
   Senior Research Scientist
   Telcordia Technologies
   445 South Street
   Morristown, NJ 07960
   USA
   Tel: +1 973 829 4515 Fax: +1 973 829 5888
   Email: narain@research.telcordia.com
  --------------A49497AA5DFE69F56B6BA9D0-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 01:49:00 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25772 for ; Tue, 5 Nov 2002 01:49:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.007AC081@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 1:51:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 317910 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 01:51:25 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 01:51:25 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 696834483FA for ; Mon, 4 Nov 2002 22:51:24 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080106040604050308020600" Message-ID: <3DC76A27.9050502@redback.com> Date: Tue, 5 Nov 2002 01:50:15 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Atlanta IETF OSPF WG Agenda To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------080106040604050308020600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The agenda is attached. Please let us know ASAP if we've missed something. -- Acee & Rohit --------------080106040604050308020600 Content-Type: text/plain; name="ospf-wg-agenda.txt" Content-Disposition: inline; filename="ospf-wg-agenda.txt" Content-Transfer-Encoding: 7bit Open Shortest Path First WG (OSPF) Thursday, November 12 at 1530-1730 ================================= CHAIRS: Rohit Dube Acee Lindem AGENDA: Agenda Bashing 5 Mins WG document status and Charter Update 15 Mins Chairs Extensions to IS-IS and OSPF for Advertising 10 Mins Rahul Aggarwal Optional Router Capabilities OSPFv3 Traffic Engineering Extensions 15 Mins Kunihiro Ishiguro Congestion Avoidance & Control for 10 Mins Jerry Ash OSPF Neworks LSA Flooding Optimization Algorithms and 10 Mins Gagan L. Choudhury Their Simulation Study --------------080106040604050308020600-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 01:53:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25857 for ; Tue, 5 Nov 2002 01:53:37 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.007AC0BC@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 1:56:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 317932 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 01:56:04 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 01:56:04 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPXV4>; Tue, 5 Nov 2002 01:56:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 5 Nov 2002 01:58:07 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Atlanta IETF OSPF WG Agenda To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, We intend to present the scalability draft too, a slot for which was requested by Gagan. The draft is at http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt . Gagan has posted the next version of the draft with some more simulation results. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Tuesday, November 05, 2002 12:20 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Atlanta IETF OSPF WG Agenda The agenda is attached. Please let us know ASAP if we've missed something. -- Acee & Rohit From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 01:59:45 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26032 for ; Tue, 5 Nov 2002 01:59:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007AC106@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 2:02:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 317949 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 02:02:11 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 02:02:11 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 26F3F1B8EEA for ; Mon, 4 Nov 2002 23:02:10 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DC76CAD.808@redback.com> Date: Tue, 5 Nov 2002 02:01:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Atlanta IETF OSPF WG Agenda To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Acee, > > We intend to present the scalability draft too, a slot for which was > requested by Gagan. Sounds good - I was copied on the re-spin of the draft. Please let me know how long. Thanks, Acee > > The draft is at > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt . > Gagan has posted the next version of the draft with some more simulation > results. > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, November 05, 2002 12:20 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Atlanta IETF OSPF WG Agenda > > > The agenda is attached. Please let us know ASAP if > we've missed something. > -- > Acee & Rohit > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 02:07:30 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05855 for ; Tue, 5 Nov 2002 02:07:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.007AC0E6@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 2:09:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 317972 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 02:09:56 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 02:09:55 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPXWJ>; Tue, 5 Nov 2002 02:09:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 5 Nov 2002 02:11:59 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Atlanta IETF OSPF WG Agenda To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, A 10 minute slot would do. By the way don't we intend to present the hitless restart draft (I remember issues had been raised by you on the list regarding it) Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Tuesday, November 05, 2002 12:31 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Atlanta IETF OSPF WG Agenda Manral, Vishwas wrote: > Hi Acee, > > We intend to present the scalability draft too, a slot for which was > requested by Gagan. Sounds good - I was copied on the re-spin of the draft. Please let me know how long. Thanks, Acee > > The draft is at > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt . > Gagan has posted the next version of the draft with some more simulation > results. > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, November 05, 2002 12:20 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Atlanta IETF OSPF WG Agenda > > > The agenda is attached. Please let us know ASAP if > we've missed something. > -- > Acee & Rohit -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 02:22:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06132 for ; Tue, 5 Nov 2002 02:22:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.007AC0C1@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 2:24:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 318034 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 02:24:58 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 02:24:58 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id B18F7F2C46 for ; Mon, 4 Nov 2002 23:24:56 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DC77203.5080800@redback.com> Date: Tue, 5 Nov 2002 02:23:47 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Atlanta IETF OSPF WG Agenda To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Acee, > > A 10 minute slot would do. > > By the way don't we intend to present the hitless restart draft (I remember > issues had been raised by you on the list regarding it) Hi Vishwas, I was considering it but I didn't get many additional comments on the 04 version. I'll add it to the agenda and cover the additions and clarifications as well as the suggested change. Thanks, Acee > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, November 05, 2002 12:31 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Atlanta IETF OSPF WG Agenda > > > Manral, Vishwas wrote: > >>Hi Acee, >> >>We intend to present the scalability draft too, a slot for which was >>requested by Gagan. > > > Sounds good - I was copied on the re-spin of the draft. Please let > me know how long. > > Thanks, > Acee > > >>The draft is at >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt . >>Gagan has posted the next version of the draft with some more simulation >>results. >> >>Thanks, >>Vishwas >> >>-----Original Message----- >>From: Acee Lindem [mailto:acee@REDBACK.COM] >>Sent: Tuesday, November 05, 2002 12:20 PM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Atlanta IETF OSPF WG Agenda >> >> >>The agenda is attached. Please let us know ASAP if >>we've missed something. >>-- >>Acee & Rohit > > -- > Acee > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 04:29:00 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08448 for ; Tue, 5 Nov 2002 04:29:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.007AC1E9@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 4:31:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 318236 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 04:31:26 -0500 Received: from 192.114.186.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 04:31:26 -0500 Received: from tal (adsl-ayalon-oc-113-227.inter.net.il [213.8.113.227]) by odin.inter.net.il (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ASE57632; Tue, 5 Nov 2002 11:30:52 +0200 (IST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C284BE.DD2FB860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <008401c284ae$2e9c0cf0$002010ac@infit.com> Date: Tue, 5 Nov 2002 11:31:20 +0200 Reply-To: Mailing List Sender: Mailing List From: Tal Sarfaty Subject: Re: Tunnels and OSPF. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0081_01C284BE.DD2FB860 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Sanjai, first of all thank you very much for you comment. i think you have missed one key item in my question - that is "no = externals" should be used. when you talk about more than one process you need redistribution = between the processes and of the destination tunnel. the reason that an ASBR solution is not good for us is that we intend to = have many tunnels in the AS, so we would have many externals (two for = each tunnel), that cannot be summarized and would be added to any = router's route rules in the AS. instead we are looking for an ABR solution, one process - no externals. Thanks, Tal. -----Original Message----- From: Sanjai Narain [mailto:narain@RESEARCH.TELCORDIA.COM]=20 Sent: Monday, November 04, 2002 8:10 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Tunnels and OSPF. =20 Tal: One solution that we have successfully tried is to define the VPN = as a collection of GRE tunnels. Each GRE tunnel G is protected by an = IPSec tunnel between G's physical interfaces. Now, a new OSPF process is = run at each router, distinct from any other OSPF process running there. = This process will only see the network of GRE tunnels, and thereby route = and reroute only over these. GRE gives OSPF the illusion that tunnel end = points are directly connected (as intended), so you get routing over = your -secure- overlay nework. The overlay OSPF process must be a new one = to avoid routing loops. This is a well known solution and typing = GRE/OSPF/IPSec into Google will yield numerous case studies.=20 -- Sanjai Narain=20 Tal Sarfaty wrote:=20 Is it possible to force the traffic flowing between the OSPF backbone = and one of the other areas, to go through a tunnel (for VPN purpose for = instance)? That is without the use of externals and without the use of static = routes of course.=20 The topology can be addressed as a classic "Normal areas" = "no summary" single OSPF AS, or any other.=20 Note that the naive solution would create a "recursive routing" to the = destination address of the tunnel.=20 The last would cause tunnel oscillations.=20 Thanks,=20 Tal.=20 --=20 Sanjai Narain=20 Senior Research Scientist=20 Telcordia Technologies=20 445 South Street=20 Morristown, NJ 07960=20 USA=20 Tel: +1 973 829 4515 Fax: +1 973 829 5888=20 Email: narain@research.telcordia.com=20 ------=_NextPart_000_0081_01C284BE.DD2FB860 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Sanjai,
first of all thank you very much = for you=20 comment.
 
i think you have missed one key = item in my=20 question - that is "no externals" should be used.
when you talk about more than one = process=20 you need redistribution between the processes and of the destination=20 tunnel.
the reason that an ASBR solution = is not good=20 for us is that we intend to have many tunnels in the AS, so we = would have=20 many externals (two for each tunnel), that cannot be summarized and = would=20 be added to any router's route rules in the AS.
 
instead we are looking for an ABR = solution,=20 one process - no externals.
 
Thanks,
Tal.
 
-----Original Message-----
From: Sanjai Narain=20 [mailto:narain@RESEARCH.TELCORDIA.COM]
Sent: Monday, November = 04,=20 2002 8:10 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: = Re:=20 Tunnels and OSPF.

 
Tal: One solution that = we have=20 successfully tried is to define the VPN as a collection of GRE tunnels. = Each GRE=20 tunnel G  is protected by an IPSec tunnel between G's physical = interfaces.=20 Now, a new OSPF process is run at each router, distinct from any other = OSPF=20 process running there. This process will only see the network of GRE = tunnels,=20 and thereby route and reroute only over these. GRE gives OSPF the = illusion that=20 tunnel end points are directly connected (as intended), so you get = routing over=20 your -secure- overlay nework. The overlay OSPF process must be a new one = to=20 avoid routing loops. This is a well known solution and typing = GRE/OSPF/IPSec=20 into Google will yield numerous case studies.=20

-- Sanjai Narain=20

Tal Sarfaty wrote:=20

Is it possible to = force the=20 traffic flowing between the OSPF backbone and one of the other = areas, to go through a tunnel (for VPN = purpose for=20 instance)?

That is without the = use of=20 externals and without the use of static routes of course.=20

The topology can be = addressed=20 as a classic "<?xml:namespace prefix =3D st1 ns =3D "urn:schemas-microsoft= -com:office:smarttags"=20 />Normal = areas" "no=20 summary" single OSPF AS, or = any other.=20


Note that the naive solution would create a = "recursive routing" to the destination address of the tunnel.=20

The last would cause tunnel = oscillations.=20

Thanks,=20

Tal.=20


--
   Sanjai Narain
   Senior Research = Scientist=20
   Telcordia Technologies
   445 South = Street=20
   Morristown, NJ 07960
   USA =
   Tel:=20 +1 973 829 4515 Fax: +1 973 829 5888
   Email:=20 narain@research.telcordia.com =

------=_NextPart_000_0081_01C284BE.DD2FB860-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 06:20:37 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12053 for ; Tue, 5 Nov 2002 06:20:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.007AC328@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 6:23:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 318622 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 06:23:03 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 06:13:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11191; Tue, 5 Nov 2002 06:10:33 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200211051110.GAA11191@ietf.org> Date: Tue, 5 Nov 2002 06:10:33 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-dc-05.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Detecting Inactive Neighbors over OSPF Demand Circuits Author(s) : S. Rao, A. Zinin, A. Roy Filename : draft-ietf-ospf-dc-05.txt Pages : 5 Date : 2002-11-4 OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits is optimized in RFC1793 to minimize the amount of overhead traffic. A part of OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect a OSPF-inactive neighbor over such a link. This memo addresses the above problem by the neighbor probing mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-dc-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-dc-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-4172442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-dc-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-dc-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4172442.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 10:17:04 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22806 for ; Tue, 5 Nov 2002 10:17:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.007AC85A@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 10:19:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 319182 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 10:19:28 -0500 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 10:19:28 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA5Dx3nk009812 for ; Tue, 5 Nov 2002 09:19:27 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B560500EF927A for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 10:19:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C284DE.BA6BE9C2" X-MS-Has-Attach: yes Thread-Topic: Atlanta IETF OSPF WG Agenda Thread-Index: AcKEmUwNekCef23qTtqYqYXOdThtQQAQ8OeA Message-ID: <28F05913385EAC43AF019413F674A017023F683E@OCCLUST04EVS1.ugd.att.com> Date: Tue, 5 Nov 2002 10:19:26 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALASO" Subject: Version 2 of OSPF Scalability Draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C284DE.BA6BE9C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Everybody, Here is version 2 of "draft-ietf-ospf-scalability-02.txt" which has = been submitted but will take a few days to appear at the IETF Web-site. = It has new simulation results to quantitatively show how much = scalability improvement can be achieved by prioritizing Hello and/or LSA = Acknowledgment packets under various scenarios. Please give your = comments electronically or at the Atlanta Meeting. Thanks, Gagan -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Tuesday, November 05, 2002 2:01 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Atlanta IETF OSPF WG Agenda Manral, Vishwas wrote: > Hi Acee, > > We intend to present the scalability draft too, a slot for which was > requested by Gagan. Sounds good - I was copied on the re-spin of the draft. Please let me know how long. Thanks, Acee > > The draft is at > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt = . > Gagan has posted the next version of the draft with some more = simulation > results. > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, November 05, 2002 12:20 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Atlanta IETF OSPF WG Agenda > > > The agenda is attached. Please let us know ASAP if > we've missed something. > -- > Acee & Rohit > -- Acee ------_=_NextPart_001_01C284DE.BA6BE9C2 Content-Type: text/plain; name="draft-ietf-ospf-scalability-02.txt" Content-Description: draft-ietf-ospf-scalability-02.txt Content-Disposition: attachment; filename="draft-ietf-ospf-scalability-02.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQogICBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAg ICBHYWdhbiBMLiBDaG91ZGh1cnkNCiAgIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFZlcmEgRC4gU2Fwb3pobmlrb3ZhDQogICBFeHBpcmVzIGluIE1heSwg MjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICBBVCZUDQogICBkcmFmdC1pZXRmLW9zcGYt c2NhbGFiaWxpdHktMDIudHh0ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBbnVyYWcgUy4gTWF1bmRlcg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2FuZXJhIFN5c3RlbXMNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVmlzaHdhcyBN YW5yYWwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE5ldHBsYW5lIFN5c3RlbXMNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTm92ZW1iZXIsIDIwMDINCg0KDQogICAgRXhwbGljaXQgTWFya2luZyBh bmQgUHJpb3JpdGl6ZWQgVHJlYXRtZW50IG9mIFNwZWNpZmljIE9TUEYgUGFja2V0cw0KICAgICAg Zm9yIEZhc3RlciBDb252ZXJnZW5jZSBhbmQgSW1wcm92ZWQgTmV0d29yayBTY2FsYWJpbGl0eSBh bmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0YWJpbGl0eQ0KDQoNClN0YXR1 cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBh bmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZQ0KICAgd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0 aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwg aXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBn cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0N CiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXgNCiAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzDQogICBhdCBhbnkgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcw0KICAgcmVmZXJl bmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dy ZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj Y2Vzc2VkIGF0DQogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3Rz LnR4dA0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNh biBiZSBhY2Nlc3NlZCBhdA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s Lg0KICAgRGlzdHJpYnV0aW9uIG9mIHRoaXMgbWVtbyBpcyB1bmxpbWl0ZWQuDQoNCg0KQWJzdHJh Y3QNCg0KICAgSW4gdGhpcyBkcmFmdCB3ZSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgbWVjaGFuaXNt cyB0byBpbXByb3ZlIA0KICAgdGhlIHNjYWxhYmlsaXR5IGFuZCBzdGFiaWxpdHkgb2YgT1NQRi1i YXNlZCBuZXR3b3JrOg0KDQogICAoMSkgUHJvY2VzcyB0aGUgSGVsbG8gcGFja2V0cyBhdCBhIGhp Z2hlciBwcmlvcml0eSBjb21wYXJlZCB0byBvdGhlcg0KICAgICAgIE9TUEYgcGFja2V0cy4gIElu IG9yZGVyIHRvIGZhY2lsaXRhdGUgdGhpcywgZXhwbGljaXRseSBtYXJrIHRoZSANCiAgICAgICBI ZWxsbyBwYWNrZXRzLCB0byBkaWZmZXJlbnRpYXRlIHRoZW0gZnJvbSBvdGhlciBPU1BGIHBhY2tl dHMuDQogICAgICAgT25lIHdheSBvZiBzcGVjaWFsIG1hcmtpbmcgaXMgdG8gdXNlIGEgZGlmZmVy ZW50IERpZmZzZXJ2IA0KDQogICAgICAgICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCiAgIEludGVybmV0 IERyYWZ0ICAgICAgICAgIEV4cGxpY2l0IE1hcmtpbmcgICAgICAgICAgICAgICAgIE1heSwgMjAw Mw0KDQoNCiAgICAgICBjb2RlcG9pbnQgZm9yIEhlbGxvIHBhY2tldHMgY29tcGFyZWQgdG8gb3Ro ZXIgT1NQRiBwYWNrZXRzLg0KDQogICAoMikgSW4gdGhlIGFic2VuY2Ugb2Ygc3BlY2lhbCBtYXJr aW5nLCBvciBpbiBhZGRpdGlvbiB0byBpdCwgdXNlIA0KICAgICAgIG90aGVyIG1lY2hhbmlzbXMg aW4gb3JkZXIgbm90IHRvIG1pc3MgSGVsbG8gcGFja2V0cy4gT25lIGV4YW1wbGUNCiAgICAgICBp cyB0byB0cmVhdCBhbnkgcGFja2V0IHJlY2VpdmVkIG92ZXIgYSBsaW5rIGFzIGEgc3Vycm9nYXRl IGZvcg0KICAgICAgIGEgSGVsbG8gcGFja2V0IChhbiBpbXBsaWNpdCBIZWxsbykgZm9yIHRoZSBw dXJwb3NlIG9mIGtlZXBpbmcgDQogICAgICAgdGhlIGxpbmsgYWxpdmUuDQoNCiAgICgzKSBUaGUg c2FtZSB0eXBlIG9mIGV4cGxpY2l0IG1hcmtpbmcgYW5kIHByaW9yaXRpemVkIHRyZWF0bWVudCBt YXkNCiAgICAgICBiZSBiZW5lZmljaWFsIHRvIG90aGVyIE9TUEYgcGFja2V0cyBhcyB3ZWxsLiAg T25lIGltcG9ydGFudCANCiAgICAgICBleGFtcGxlIGlzIExTQSBhY2tub3dsZWRnbWVudCBwYWNr ZXQgdGhhdCBjYW4gcmVkdWNlIA0KICAgICAgIHJldHJhbnNtaXNzaW9ucyBkdXJpbmcgcGVyaW9k cyBvZiBjb25nZXN0aW9uLiAgT3RoZXIgZXhhbXBsZXMgDQogICAgICAgaW5jbHVkZSAoYSkgRGF0 YWJhc2UgZGVzY3JpcHRpb24gKERCRCkgcGFja2V0IGZyb20gYSBzbGF2ZSB0aGF0IA0KICAgICAg IGlzIHVzZWQgYXMgYW4gYWNrbm93bGVkZ2VtZW50LCBhbmQgKGIpIExTQXMgY2FycnlpbmcgaW50 cmEtYXJlYSANCiAgICAgICB0b3BvbG9neSBjaGFuZ2UgaW5mb3JtYXRpb24uDQogICANCiAgIEl0 IGlzIHBvc3NpYmxlIHRoYXQgc29tZSBpbXBsZW1lbnRhdGlvbnMgYXJlIGFscmVhZHkgdXNpbmcg b25lIG9yDQogICBtb3JlIG9mIHRoZSBhYm92ZSBtZWNoYW5pc21zIGluIG9yZGVyIG5vdCB0byBt aXNzIHRoZSBwcm9jZXNzaW5nIG9mDQogICBjcml0aWNhbCBwYWNrZXRzIGR1cmluZyBwZXJpb2Rz IG9mIGNvbmdlc3Rpb24uICBIb3dldmVyLCB3ZSBzdWdnZXN0DQogICB0aGUgYWJvdmUgbWVjaGFu aXNtcyB0byBiZSBpbmNsdWRlZCBhcyBwYXJ0IG9mIHRoZSBzdGFuZGFyZCBzbyB0aGF0DQogICBh bGwgaW1wbGVtZW50YXRpb25zIGNhbiBiZW5lZml0IGZyb20gdGhlbS4NCg0KDQpUYWJsZSBvZiBD b250ZW50cw0KDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yDQogICAyLiBUaGUgTmV0d29yayBVbmRlciBTaW11bGF0 aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICAzLiBTaW11bGF0aW9u IFJlc3VsdHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43DQog ICA0LiBPYnNlcnZhdGlvbnMgb24gU2ltdWxhdGlvbiBSZXN1bHRzIC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjExDQogICA1LiBOZWVkIGZvciBQcmlvcml0aXplZCBUcmVhdG1lbnQgb2YgQ3Jp dGljYWwgT1NQRiBQYWNrZXRzIGFuZCANCiAgICAgIFNwZWNpYWwgTWFya2luZyB0byBGYWNpbGl0 YXRlIFRoYXQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTINCiAgIDYuIFN1bW1hcnkuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMNCiAg IDcuIEFja25vd2xlZGdtZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTQNCiAgIDguIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQNCiAgIDkuIEF1dGhvcnMnIEFkZHJlc3Nlcy4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUNCg0KDQoxLiBJbnRyb2R1 Y3Rpb24NCg0KICAgRHVlIHRvIHdvcmxkLXdpZGUgaW5jcmVhc2VkIHRyYWZmaWMgZGVtYW5kLCBk YXRhIG5ldHdvcmtzIGFyZSBldmVyIA0KICAgaW5jcmVhc2luZyBpbiBzaXplIGluIHRlcm1zIG9m IG51bWJlciBvZiBub2RlcywgbnVtYmVyIG9mIGxpbmtzLA0KICAgYWRqYWNlbmNpZXMgcGVyIG5v ZGUgYW5kIExpbmsgU3RhdGUgRGF0YWJhc2Ugc2l6ZS4gIE91ciBtb3RpdmF0aW9uDQogICBpcyB0 byBpbXByb3ZlIHRoZSBhYmlsaXR5IG9mIGxhcmdlIG5ldHdvcmtzIHRvIHdpdGhzdGFuZA0KICAg dGhlIHNpbXVsdGFuZW91cyBvciBuZWFyLXNpbXVsdGFuZW91cyB1cGRhdGUgb2YgYSBsYXJnZSBu dW1iZXIgb2YNCiAgIGxpbmstc3RhdGUtYWR2ZXJ0aXNlbWVudCBtZXNzYWdlcywgb3IgTFNBcy4g IFdlIGNhbGwgdGhpcyBldmVudCwgYW4NCiAgIExTQSBzdG9ybS4gIEFuIExTQSBzdG9ybSBtYXkg YmUgaW5pdGlhdGVkIGR1ZSB0byBtYW55IHJlYXNvbnMuICBIZXJlDQogICBhcmUgc29tZSBleGFt cGxlczogIA0KDQogICAoYSkgb25lIG9yIG1vcmUgbGluayBmYWlsdXJlcyBkdWUgdG8gZmliZXIg Y3V0cywNCg0KICAgICAgICAgIA0KICAgQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQogICBJbnRlcm5ldCBEcmFmdCAg ICAgICAgICBFeHBsaWNpdCBNYXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQog ICAoYikgb25lIG9yIG1vcmUgbm9kZSBmYWlsdXJlcyBmb3Igc29tZSByZWFzb24sIGUuZy4sIHNv ZnR3YXJlDQogICAgICAgY3Jhc2ggb3Igc29tZSB0eXBlIG9mIGRpc2FzdGVyIGluIGFuIG9mZmlj ZSBjb21wbGV4IGhvc3RpbmcgDQogICAgICAgbWFueSBub2RlcywNCg0KICAgKGMpIHJlcXVpcmVt ZW50IG9mIHRha2luZyBkb3duIGFuZCBsYXRlciBicmluZ2luZyBiYWNrIG1hbnkgDQogICAgICAg bm9kZXMgZHVyaW5nIGEgc29mdHdhcmUvaGFyZHdhcmUgdXBncmFkZSwgDQoNCiAgIChkKSBuZWFy LXN5bmNocm9uaXphdGlvbiBvZiB0aGUgb25jZS1pbi0zMC1taW51dGVzIHJlZnJlc2ggaW5zdGFu dHMNCiAgICAgICBvZiBzb21lIHR5cGVzIG9mIExTQXMsIA0KDQogICAoZSkgcmVmcmVzaCBvZiBh bGwgTFNBcyBpbiB0aGUgc3lzdGVtIGR1cmluZyBhIGNoYW5nZSBpbiBzb2Z0d2FyZSANCiAgICAg ICB2ZXJzaW9uLiAgDQoNCiAgIEluIGFkZGl0aW9uIHRvIHRoZSBMU0FzIGdlbmVyYXRlZCBhcyBh IGRpcmVjdCByZXN1bHQgb2YgbGluay9ub2RlIA0KICAgZmFpbHVyZXMsIHRoZXJlIG1heSBiZSBv dGhlciBpbmRpcmVjdCBMU0FzIGFzIHdlbGwuICBPbmUgZXhhbXBsZSANCiAgIGluIE1QTFMgbmV0 d29ya3MgaXMgdHJhZmZpYyBlbmdpbmVlcmluZyBMU0FzIGdlbmVyYXRlZCBhdCBvdGhlciANCiAg IGxpbmtzIGFzIGEgcmVzdWx0IG9mIHNpZ25pZmljYW50IGNoYW5nZSBpbiByZXNlcnZlZCBiYW5k d2lkdGggDQogICByZXN1bHRpbmcgZnJvbSByZXJvdXRpbmcgb2YgTGFiZWwgU3dpdGNoZWQgUGF0 aHMgKExTUHMpIHRoYXQgd2VudCANCiAgIGRvd24gZHVyaW5nIHRoZSBsaW5rL25vZGUgZmFpbHVy ZS4NCiANCiAgIFRoZSBMU0Egc3Rvcm0gY2F1c2VzIGhpZ2ggQ1BVIGFuZCBtZW1vcnkgdXRpbGl6 YXRpb24gYXQgdGhlIG5vZGUNCiAgIHByb2Nlc3NvcnMgY2F1c2luZyBpbmNvbWluZyBwYWNrZXRz IHRvIGJlIGRlbGF5ZWQgb3IgZHJvcHBlZC4gIA0KICAgRGVsYXllZCBhY2tub3dsZWRnZW1lbnRz IChiZXlvbmQgdGhlIHJldHJhbnNtaXNzaW9uIHRpbWVyIHZhbHVlKSANCiAgIHJlc3VsdHMgaW4g cmV0cmFuc21pc3Npb25zLCBhbmQgZGVsYXllZCBIZWxsbyBwYWNrZXRzIChiZXlvbmQgdGhlIA0K ICAgUm91dGVyLURlYWQgaW50ZXJ2YWwpIHJlc3VsdHMgaW4gbGlua3MgYmVpbmcgZGVjbGFyZWQg ZG93bi4gIEENCiAgIHRydW5rLWRvd24gZXZlbnQgY2F1c2VzIFJvdXRlciBMU0EgZ2VuZXJhdGlv biBieSBpdHMgZW5kLXBvaW50DQogICBub2Rlcy4gIElmIHRyYWZmaWMgZW5naW5lZXJpbmcgTFNB cyBhcmUgdXNlZCBmb3IgZWFjaCBsaW5rIHRoZW4NCiAgIHRoYXQgdHlwZSBvZiBMU0FzIHdvdWxk IGFsc28gYmUgZ2VuZXJhdGVkIGJ5IHRoZSBlbmQtcG9pbnQgbm9kZXMNCiAgIGFuZCBwb3RlbnRp YWxseSBlbHNld2hlcmUgYXMgd2VsbCBkdWUgdG8gc2lnbmlmaWNhbnQgY2hhbmdlcyBpbg0KICAg cmVzZXJ2ZWQgYmFuZHdpZHRocyBhdCBvdGhlciBsaW5rcyBjYXVzZWQgYnkgdGhlIGZhaWx1cmUg YW5kIHJlcm91dGUNCiAgIG9mIExTUHMgb3JpZ2luYWxseSB1c2luZyB0aGUgZmFpbGVkIHRydW5r LiAgRXZlbnR1YWxseSwgd2hlbiB0aGUNCiAgIGxpbmsgcmVjb3ZlcnMgdGhhdCB3b3VsZCBhbHNv IHRyaWdnZXIgYWRkaXRpb25hbCBSb3V0ZXIgYW5kIHRyYWZmaWMNCiAgIGVuZ2luZWVyaW5nIExT QXMuDQoNCiAgIFRoZSByZXRyYW5zbWlzc2lvbnMgYW5kIGFkZGl0aW9uYWwgTFNBIGdlbmVyYXRp b25zIHJlc3VsdCBpbiBmdXJ0aGVyIA0KICAgQ1BVIGFuZCBtZW1vcnkgdXNhZ2UsIGVzc2VudGlh bGx5IGNhdXNpbmcgYSBwb3NpdGl2ZSBmZWVkYmFjayBsb29wLiAgDQogICBXZSBkZWZpbmUgdGhl IExTQSBzdG9ybSBzaXplIGFzIHRoZSBudW1iZXIgb2YgTFNBcyBpbiB0aGUgb3JpZ2luYWwgDQog ICBzdG9ybSBhbmQgbm90IGNvdW50aW5nIGFueSBhZGRpdGlvbmFsIExTQXMgcmVzdWx0aW5nIGZy b20gdGhlICANCiAgIGZlZWRiYWNrIGxvb3AgZGVzY3JpYmVkIGFib3ZlLiAgSWYgdGhlIExTQSBz dG9ybSBpcyB0b28gbGFyZ2UgdGhlbg0KICAgdGhlIHBvc2l0aXZlIGZlZWRiYWNrIGxvb3AgbWVu dGlvbmVkIGFib3ZlIG1heSBiZSBsYXJnZSBlbm91Z2ggdG8gDQogICBpbmRlZmluaXRlbHkgc3Vz dGFpbiBhIGxhcmdlIENQVSBhbmQgbWVtb3J5IHV0aWxpemF0aW9uIGF0IG1hbnkgDQogICBuZXR3 b3JrIG5vZGVzLCB0aGVyZWJ5IGRyaXZpbmcgdGhlIG5ldHdvcmsgdG8gYW4gdW5zdGFibGUgc3Rh dGUuDQoNCiAgIEluIHRoZSBwYXN0LCBuZXR3b3JrDQogICBvdXRhZ2UgZXZlbnRzIGhhdmUgYmVl biByZXBvcnRlZCBpbiBJUCBhbmQgQVRNIG5ldHdvcmtzIHVzaW5nIA0KICAgbGluay1zdGF0ZSBw cm90b2NvbHMgc3VjaCBhcyBPU1BGLCBJUy1JUywgUE5OSSBvciBzb21lIHByb3ByaWV0YXJ5IA0K ICAgdmFyaWFudHMuICBTZWUsIGZvciBleGFtcGxlIFtSZWYxLVJlZjRdLiAgSW4gbWFueSBvZiB0 aGVzZSBleGFtcGxlcywNCiAgIGxhcmdlIHNjYWxlIGZsb29kaW5nIG9mIExTQXMgb3Igb3RoZXIg c2ltaWxhciBjb250cm9sIG1lc3NhZ2VzIA0KICAgKGVpdGhlciBuYXR1cmFsbHkgb3IgdHJpZ2dl cmVkIGJ5IHNvbWUgYnVnIG9yIGluYXBwcm9wcmlhdGUgDQoNCiAgICAgICAgICANCiAgIENob3Vk aHVyeSBldC4gYWwuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSAzXQ0KDA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgRXhwbGljaXQgTWFya2luZyAgICAg ICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0KICAgcHJvY2VkdXJlKSBoYXZlIGJlZW4gcGFydGx5 IG9yIGZ1bGx5IHJlc3BvbnNpYmxlIGZvciBuZXR3b3JrIA0KICAgaW5zdGFiaWxpdHkgYW5kIG91 dGFnZS4gDQ0KDQogICBJdCBoYXMgYmVlbiBzdWdnZXN0ZWQgW1JlZjVdIHRvIHJlZHVjZSB0aGUg SGVsbG8gaW50ZXJ2YWwgYW5kDQogICBSb3V0ZXItRGVhZCBpbnRlcnZhbCBzaWduaWZpY2FudGx5 IGluIG9yZGVyIGZvciBPU1BGIHRvIGRldGVjdA0KICAgbGluayBmYWlsdXJlcyBhbmQgcmVjb3Zl cmllcyBmYXN0ZXIuIFJlZHVjdGlvbiBvZiBSb3V0ZXItRGVhZA0KICAgaW50ZXJ2YWwgd291bGQg bWFrZSBpdCBldmVuIG1vcmUgbGlrZWx5IGZvciBsaW5rcyB0byBiZSBkZWNsYXJlZCBkb3duDQog ICBkdWUgdG8gbWlzc2VkIEhlbGxvcy4NCg0KICAgV2UgdXNlIGEgc2ltdWxhdGlvbiBtb2RlbCB0 byBzaG93IHRoYXQgdGhlcmUgaXMgYSBjZXJ0YWluIExTQSBzdG9ybQ0KICAgc2l6ZSB0aHJlc2hv bGQgYWJvdmUgd2hpY2ggdGhlIG5ldHdvcmsgbWF5IHNob3cgdW5zdGFibGUgYmVoYXZpb3IgDQog ICBjYXVzZWQgYnkgbGFyZ2UgbnVtYmVyIG9mIHJldHJhbnNtaXNzaW9ucywgbGluayBmYWlsdXJl cyBkdWUgdG8gDQogICBtaXNzZWQgSGVsbG8gcGFja2V0cyBhbmQgc3Vic2VxdWVudCBsaW5rIHJl Y292ZXJpZXMuICBXZSBhbHNvIHNob3cNCiAgIHRoYXQgdGhlIExTQSBzdG9ybSBzaXplIGNhdXNp bmcgaW5zdGFiaWxpdHkgbWF5IGJlIHN1YnN0YW50aWFsbHkNCiAgIGluY3JlYXNlZCBieSBwcm92 aWRpbmcgcHJpb3JpdGl6ZWQgdHJlYXRtZW50IHRvIEhlbGxvIGFuZCBMU0EgDQogICBBY2tub3ds ZWRnbWVudCBwYWNrZXRzLiAgRnVydGhlcm1vcmUsIGlmIHdlIHByaW9yaXRpemUgSGVsbG8gDQog ICBwYWNrZXRzIHRoZW4gZXZlbiB3aGVuIHRoZSBuZXR3b3JrIG9wZXJhdGVzIHNvbWV3aGF0IGFi b3ZlIHRoZSANCiAgIHN0YWJpbGl0eSB0aHJlc2hvbGQsIGxpbmtzIGFyZSBub3QgZGVjbGFyZWQg ZG93biBkdWUgdG8gbWlzc2VkIA0KICAgSGVsbG9zLiAgVGhpcyBpbXBsaWVzIHRoYXQgZXZlbiB0 aG91Z2ggdGhlcmUgaXMgDQogICBjb250cm9sIHBsYW5lIGNvbmdlc3Rpb24gZHVlIHRvIG1hbnkg cmV0cmFuc21pc3Npb25zLCB0aGUgZGF0YSBwbGFuZQ0KICAgc3RheXMgdXAgYW5kIG5vIG5ldyBM U0FzIGFyZSBnZW5lcmF0ZWQgKGJlc2lkZXMgdGhlIG9uZXMgaW4gdGhlIA0KICAgb3JpZ2luYWwg c3Rvcm0gYW5kIHRoZSByZWZyZXNoZXMpLiAgQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zDQog ICB3ZSBwcm9wb3NlIHByaW9yaXRpemVkIHRyZWF0bWVudCBvZiBIZWxsbywgTFNBIGFja25vd2xl ZGdtZW50DQogICBhbmQgb3RoZXIgY3JpdGljYWwgT1NQRiBwYWNrZXRzIGFuZCBhIHNwZWNpYWwg bWFya2luZyB0byBmYWNpbGl0YXRlDQogICB0aGF0Lg0KDQogICBPbmUgbWlnaHQgYXJndWUgdGhh dCB0aGUgc2NhbGFiaWxpdHkgaXNzdWUgb2YgbGFyZ2UgbmV0d29ya3Mgc2hvdWxkDQogICBiZSBz b2x2ZWQgc29sZWx5IGJ5IGRpdmlkaW5nIHRoZSBuZXR3b3JrIGhpZXJhcmNoaWNhbGx5IGludG8g DQogICBtdWx0aXBsZSBhcmVhcyBzbyB0aGF0IGZsb29kaW5nIG9mIExTQXMgcmVtYWlucyBsb2Nh bGl6ZWQgd2l0aGluIA0KICAgYXJlYXMuICBIb3dldmVyLCB0aGlzIGFwcHJvYWNoIGluY3JlYXNl cyB0aGUgbmV0d29yayBtYW5hZ2VtZW50IA0KICAgYW5kIGRlc2lnbiBjb21wbGV4aXR5IGFuZCBt YXkgcmVzdWx0IGluIGxlc3Mgb3B0aW1hbCByb3V0aW5nIGJldHdlZW4gDQogICBhcmVhcy4gQWxz bywgQVNFIExTQXMgYXJlIGZsb29kZWQgdGhyb3VnaG91dCB0aGUgQVMgYW5kIGl0IG1heSBiZQ0K ICAgYSBwcm9ibGVtIGlmIHRoZXJlIGFyZSBsYXJnZSBudW1iZXJzIG9mIHRoZW0uICBGdXJ0aGVy bW9yZSwgDQogICBhIGxhcmdlIG51bWJlciBvZiBzdW1tYXJ5IExTQXMgbWF5IG5lZWQgdG8gYmUg Zmxvb2RlZCBhY3Jvc3MNCiAgIEFyZWFzIGFuZCB0aGVpciBudW1iZXJzIHdvdWxkIGluY3JlYXNl IHNpZ25pZmljYW50bHkgaWYgDQogICBtdWx0aXBsZSBBcmVhIEJvcmRlciBSb3V0ZXJzIGFyZSBl bXBsb3llZCBmb3IgdGhlIHB1cnBvc2Ugb2YNCiAgIHJlbGlhYmlsaXR5LiBUaHVzIGl0IGlzIGlt cG9ydGFudCB0byBhbGxvdyB0aGUgbmV0d29yayB0byBncm93IA0KICAgdG93YXJkcyBhcyBsYXJn ZSBhIHNpemUgYXMgcG9zc2libGUgdW5kZXIgYSBzaW5nbGUgYXJlYS4gIA0KICAgDQogICBPdXIg cHJvcG9zYWwgaGVyZSBpcyBzeW5lcmdpc3RpYyB3aXRoIGEgYnJvYWRlciBzZXQgb2Ygc2NhbGFi aWxpdHkgDQogICBhbmQgc3RhYmlsaXR5IGltcHJvdmVtZW50IHByb3Bvc2Fscy4gW1JlZjYsIFJl ZjddIHByb3Bvc2VzIGZsb29kaW5nDQogICBvdmVyaGVhZCByZWR1Y3Rpb24gaW4gY2FzZSBtb3Jl IHRoYW4gb25lIGludGVyZmFjZSBnb2VzIHRvIHRoZSBzYW1lDQogICBuZWlnaGJvci4gIFtSZWY4 XSBwcm9wb3NlcyBhIG1lY2hhbmlzbSBmb3IgDQogICBncmVhdGx5IHJlZHVjaW5nIExTQSByZWZy ZXNoZXMgaW4gc3RhYmxlIHRvcG9sb2dpZXMuIFtSZWY5XSBjb21wYXJlcw0KICAgc2V2ZXJhbCBy ZXN0cmljdGVkIGZsb29kaW5nIGFsZ29yaXRobXMgaW4gdGVybXMgb2YgdGhlaXIgYWJpbGl0eSB0 bw0KICAgd2l0aHN0YW5kIGxhcmdlIExTQSBzdG9ybXMgYW5kIHJvYnVzdG5lc3MgdG8gZmFpbHVy ZSBjb25kaXRpb25zLg0KICAgW1JlZjEwXSBwcm9wb3NlcyBhIHdpZGUgcmFuZ2Ugb2YgY29uZ2Vz dGlvbiBjb250cm9sIGFuZCBmYWlsdXJlIA0KICAgcmVjb3ZlcnkgbWVjaGFuaXNtcy4gICANCg0K DQogICAgICAgICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCiAgIEludGVybmV0IERyYWZ0ICAgICAgICAg IEV4cGxpY2l0IE1hcmtpbmcgICAgICAgICAgICAgICAgIE1heSwgMjAwMw0KDQoNCiAgIFNlY3Rp b24gMiBkZXNjcmliZXMgdGhlIG5ldHdvcmsgdW5kZXIgc2ltdWxhdGlvbiBhbmQgU2VjdGlvbiAz DQogICBwcm92aWRlcyB0aGUgc2ltdWxhdGlvbiByZXN1bHRzLiAgU2VjdGlvbiA0IGdpdmVzIHRo ZSBiYXNpYw0KICAgb2JzZXJ2YXRpb25zIGJhc2VkIG9uIHRoZSBzaW11bGF0aW9uIHJlc3VsdHMu ICBTZWN0aW9uIDUgZXhwbGFpbnMNCiAgIHRoZSBuZWVkIGZvciBwcmlvcml0aXplZCB0cmVhdG1l bnQgb2YgY2VydGFpbiBjcml0aWNhbCBPU1BGIHBhY2tldHMgDQogICBhbmQgc3BlY2lhbCBtYXJr aW5nIHRvIGZhY2lsaXRhdGUgdGhhdC4gIFNlY3Rpb24gNiBnaXZlcyB0aGUgc3VtbWFyeS4NCiAg ICAgICAgICANCg0KMi4gVGhlIE5ldHdvcmsgVW5kZXIgU2ltdWxhdGlvbg0KDQogICBXZSBnZW5l cmF0ZSBhIHJhbmRvbSBuZXR3b3JrIG92ZXIgYSByZWN0YW5ndWxhciBncmlkIHVzaW5nIGEgIA0K ICAgbW9kaWZpZWQgdmVyc2lvbiBvZiBXYXhtYW4ncyBhbGdvcml0aG0gW1JlZjExXSB0aGF0IGVu c3VyZXMgdGhhdCANCiAgIHRoZSBuZXR3b3JrIGlzIGNvbm5lY3RlZCBhbmQgaGFzIGEgcHJlLXNw ZWNpZmllZCBudW1iZXIgb2Ygbm9kZXMsIA0KICAgbGlua3MsIG1heGltdW0gbnVtYmVyIG9mIG5l aWdoYm9ycyBwZXIgbm9kZSwgYW5kIG1heGltdW0gbnVtYmVyICANCiAgIG9mIGFkamFjZW5jaWVz IHBlciBub2RlLiBUaGUgcmVjdGFuZ3VsYXIgZ3JpZCByZXNlbWJsZXMgdGhlIA0KICAgY29udGlu ZW50YWwgVS5TLkEuIHdpdGggbWF4aW11bSBvbmUtd2F5IHByb3BhZ2F0aW9uIGRlbGF5IG9mIDMw IG1zIA0KICAgaW4gdGhlIEVhc3QtV2VzdCBkaXJlY3Rpb24gYW5kIG1heGltdW0gb25lLXdheSBw cm9wYWdhdGlvbiBkZWxheSBvZiANCiAgIDE1IG1zIGluIHRoZSBOb3J0aC1Tb3V0aCBkaXJlY3Rp b24uICBXZSBjb25zaWRlciB0d28gZGlmZmVyZW50IA0KICAgbmV0d29yayBzaXplcyBhcyBleHBs YWluZWQgaW4gU2VjdGlvbiAzLg0KDQogICBUaGUgbmV0d29yayBoYXMgYSBmbGF0LCBzaW5nbGUt YXJlYSB0b3BvbG9neS4NCg0KICAgRWFjaCBub2RlIGlzIGEgUm91dGVyIGFuZCBlYWNoIGxpbmsg aXMgYSBwb2ludC10by1wb2ludCBsaW5rIA0KICAgY29ubmVjdGluZyB0d28gcm91dGVycy4NCg0K ICAgV2UgYXNzdW1lIHRoYXQgbm9kZSBDUFUgYW5kIG1lbW9yeSAobm90IHRoZSBsaW5rIGJhbmR3 aWR0aCkgaXMgdGhlIA0KICAgbWFpbiBib3R0bGVuZWNrIGluIHRoZSBMU0EgZmxvb2RpbmcgcHJv Y2Vzcy4gIFRoaXMgd2lsbCB0eXBpY2FsbHkgDQogICBiZSB0cnVlIGZvciBoaWdoIHNwZWVkIGxp bmtzIChlLmcuLCBPQzMgb3IgYWJvdmUpIGFuZC9vciBsaW5rcyANCiAgIHdoZXJlIE9TUEYgdHJh ZmZpYyBnZXRzIGFuIGFkZXF1YXRlIFF1YWxpdHkgb2YgU2VydmljZSAoUW9TKSANCiAgIGNvbXBh cmVkIHRvIG90aGVyIHRyYWZmaWMuDQogDQogICBEaWZmZXJlbnQgVGltZXJzOiANCiAgICAgTFNB IHJlZnJlc2ggaW50ZXJ2YWwgPSAxODAwIHNlY29uZHMsIA0KICAgICBIZWxsbyByZWZyZXNoIGlu dGVydmFsID0gMTAgU2Vjb25kcywgDQogICAgIFJvdXRlci1EZWFkIGludGVydmFsID0gNDAgc2Vj b25kcywgDQogICAgIExTQSByZXRyYW5zbWlzc2lvbiBpbnRlcnZhbDogdHdvIHZhbHVlcyBhcmUg Y29uc2lkZXJlZCwgMTAgc2Vjb25kcyANCiAgICAgICBhbmQgNSBTZWNvbmRzIChub3RlIHRoYXQg YSByZXRyYW5zbWlzc2lvbiBpcyBkaXNhYmxlZCBvbiB0aGUgDQogICAgICAgcmVjZWlwdCBvZiBl aXRoZXIgYW4gZXhwbGljaXQgYWNrbm93bGVkZ21lbnQgb3IgYSBkdXBsaWNhdGUgTFNBDQogICAg ICAgb3ZlciB0aGUgc2FtZSBpbnRlcmZhY2UgdGhhdCBhY3RzIGFzIGFuIGltcGxpY2l0IGFja25v d2xlZGdtZW50KSANCiAgICAgTWluaW11bSB0aW1lIGJldHdlZW4gc3VjY2Vzc2l2ZSBnZW5lcmF0 aW9uIG9mIHRoZSBzYW1lIExTQSA9IDUgDQogICAgICAgc2Vjb25kcywgDQogICAgIE1pbmltdW0g dGltZSBiZXR3ZWVuIHN1Y2Nlc3NpdmUgRGlqa3N0cmEgU1BGIGNhbGN1bGF0aW9ucyANCiAgICAg ICBpcyAxIHNlY29uZC4NCg0KICAgUGFja2luZyBvZiBMU0FzOiBJdCBpcyBhc3N1bWVkIHRoYXQg Zm9yIGFueSBnaXZlbiBub2RlLCB0aGUgTFNBcyANCiAgIGdlbmVyYXRlZCBvdmVyIGEgMS1zZWNv bmQgcGVyaW9kIGFyZSBwYWNrZWQgdG9nZXRoZXIgdG8gZm9ybSBhbiBMU1UgDQogICBidXQgbm8g bW9yZSB0aGFuIDMgTFNBcyBhcmUgcGFja2VkIGluIG9uZSBMU1UuDQoNCiAgIExTVS9BY2svSGVs bG8gUHJvY2Vzc2luZyBUaW1lczogQWxsIHByb2Nlc3NpbmcgdGltZXMgYXJlIGV4cHJlc3NlZCAg DQogICBpbiB0ZXJtcyBvZiB0aGUgcGFyYW1ldGVyIFQuICBUd28gdmFsdWVzIG9mIFQgYXJlIGNv bnNpZGVyZWQsIDEgbXMNCg0KICAgICAgICAgIA0KICAgQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQogICBJbnRlcm5l dCBEcmFmdCAgICAgICAgICBFeHBsaWNpdCBNYXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIw MDMNCg0KDQogICBhbmQgMC41IG1zLg0KDQogICBJbiB0aGUgY2FzZSBvZiBhIGRlZGljYXRlZCBw cm9jZXNzb3IgZm9yIHByb2Nlc3NpbmcgT1NQRiBwYWNrZXRzIHRoZSANCiAgIHByb2Nlc3Npbmcg dGltZSByZXBvcnRlZCByZXByZXNlbnRzIHRoZSB0cnVlIHByb2Nlc3NpbmcgdGltZS4gSWYgdGhl IA0KICAgcHJvY2Vzc29yIGRvZXMgb3RoZXIgd29yayBhbmQgb25seSBhIGZyYWN0aW9uIG9mIGl0 cyBjYXBhY2l0eSBjYW4gYmUgDQogICBkZWRpY2F0ZWQgdG8gT1NQRiBwcm9jZXNzaW5nIHRoZW4g d2UgaGF2ZSB0byBpbmZsYXRlIHRoZSBwcm9jZXNzaW5nIA0KICAgdGltZSBhcHByb3ByaWF0ZWx5 IHRvIGdldCB0aGUgZWZmZWN0aXZlIHByb2Nlc3NpbmcgdGltZSBhbmQgaW4gdGhhdCANCiAgIGNh c2UgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBpbmZsYXRpb24gZmFjdG9yIGlzIGFscmVhZHkgdGFr ZW4gaW50byANCiAgIGFjY291bnQgYXMgcGFydCBvZiB0aGUgcmVwb3J0ZWQgcHJvY2Vzc2luZyB0 aW1lLiANCg0KICAgVGhlIGZpeGVkIHRpbWUgdG8gc2VuZCBvciByZWNlaXZlIGFueSBMU1UsIEFj ayBvciBIZWxsbyBwYWNrZXQgaXMgVC4NCiAgIEluIGFkZGl0aW9uLCBhIHZhcmlhYmxlIHByb2Nl c3NpbmcgdGltZSBpcyB1c2VkIGZvciBMU1UgYW5kIEFjayANCiAgIGRlcGVuZGluZyBvbiB0aGUg bnVtYmVyIGFuZCB0eXBlcyBvZiBMU0FzIHBhY2tlZC4gIE5vIHZhcmlhYmxlIA0KICAgcHJvY2Vz c2luZyB0aW1lIGlzIHVzZWQgZm9yIEhlbGxvLg0KICAgVmFyaWFibGUgcHJvY2Vzc2luZyB0aW1l IHBlciBSb3V0ZXIgTFNBIGlzICgwLjUgKyAwLjE3TClUIHdoZXJlIEwgaXMgDQogICB0aGUgbnVt YmVyIG9mIGFkamFjZW5jaWVzIGFkdmVydGlzZWQgYnkgdGhlIFJvdXRlciBMU0EuICBGb3Igb3Ro ZXIgDQogICBMU0EgdHlwZXMgKGUuZy4sIEFTRSBMU0Egb3IgYSAiTGluayIgTFNBIGNhcnJ5aW5n IHRyYWZmaWMgDQogICBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbiBhYm91dCBhIGxpbmspLCB0aGUg dmFyaWFibGUgcHJvY2Vzc2luZyB0aW1lICANCiAgIHBlciBMU0EgaXMgMC41VC4NCg0KICAgVmFy aWFibGUgcHJvY2Vzc2luZyB0aW1lIGZvciBhbiBBY2sgaXMgMjUlIHRoYXQgb2YgdGhlIGNvcnJl c3BvbmRpbmcgDQogICBMU0EuDQoNCiAgIEl0IGlzIHRvIGJlIG5vdGVkIHRoYXQgaWYgbXVsdGlw bGUgTFNBcyBhcmUgcGFja2VkIGluIGEgc2luZ2xlIExTVSANCiAgIHBhY2tldCB0aGVuIHRoZSBm aXhlZCBwcm9jZXNzaW5nIHRpbWUgaXMgbmVlZGVkIG9ubHkgb25jZSBidXQgdGhlIA0KICAgdmFy aWFibGUgcHJvY2Vzc2luZyB0aW1lIGlzIG5lZWRlZCBmb3IgZXZlcnkgY29tcG9uZW50IG9mIHRo ZSANCiAgIHBhY2tldC4NCiANCiAgIFRoZSBwcm9jZXNzaW5nIHRpbWUgdmFsdWVzIHdlIHVzZSBh cmUgcm91Z2hseSBpbiB0aGUgc2FtZSByYW5nZSBvZiANCiAgIHdoYXQgaGFzIGJlZW4gb2JzZXJ2 ZWQgaW4gYW4gb3BlcmF0aW9uYWwgbmV0d29yay4NCg0KICAgTFNVL0Fjay9IZWxsbyBQcmlvcml0 eTogVHdvIG5vbi1wcmVlbXB0aXZlIHByaW9yaXR5IGxldmVscyBhbmQNCiAgIHRocmVlIHByaW9y aXR5IHNjZW5hcmlvcyBhcmUgY29uc2lkZXJlZC4gV2l0aGluIGVhY2ggcHJpb3JpdHkgbGV2ZWwg DQogICBwcm9jZXNzaW5nIGlzIEZJRk8gd2l0aCBuZXcgcGFja2V0cyBvZiBsb3dlciBwcmlvcml0 eSBiZWluZw0KICAgZHJvcHBlZCB3aGVuIHRoZSBsb3dlciBwcmlvcml0eSBxdWV1ZSBpcyBmdWxs LiAgVGhlIGhpZ2hlciBwcmlvcml0eQ0KICAgcGFja2V0cyBhcmUgbmV2ZXIgZHJvcHBlZC4gICAg DQogICAgICBJbiBQcmlvcml0eSBzY2VuYXJpbyAxLCBhbGwgTFNVcy9BY2tzL0hlbGxvcyByZWNl aXZlZCBhdCBhIG5vZGUgDQogICAgICBhcmUgcXVldWVkIGF0IHRoZSBsb3dlciBwcmlvcml0eS4N CiAgICAgIEluIFByaW9yaXR5IHNjZW5hcmlvIDIsIEhlbGxvcyByZWNlaXZlZCBhdCBhIG5vZGUg YXJlIHF1ZXVlZCBhdCANCiAgICAgIHRoZSBoaWdoZXIgcHJpb3JpdHkgYnV0IExTVXMvQWNrcyBh cmUgcXVldWVkIGF0IGxvd2VyIHByaW9yaXR5Lg0KICAgICAgSW4gUHJpb3JpdHkgc2NlbmFyaW8g MywgSGVsbG9zIGFuZCBBY2tzIHJlY2VpdmVkIGF0IGEgbm9kZSBhcmUgDQogICAgICBxdWV1ZWQg YXQgdGhlIGhpZ2hlciBwcmlvcml0eSBidXQgTFNVcyBhcmUgcXVldWVkIGF0IGxvd2VyIA0KICAg ICAgcHJpb3JpdHkuIA0KICAgQWxsIHBhY2tldHMgZ2VuZXJhdGVkIGludGVybmFsbHkgdG8gYSBu b2RlICh1c3VhbGx5IHRyaWdnZXJlZCBieSANCiAgIGEgdGltZXIpIGFyZSBwcm9jZXNzZWQgYXQg dGhlIGhpZ2hlciBwcmlvcml0eS4gIFRoaXMgaW5jbHVkZXMgdGhlIA0KICAgaW5pdGlhbCBMU0Eg c3Rvcm0sIExTQSByZWZyZXNoLCBIZWxsbyByZWZyZXNoLCBMU0EgcmV0cmFuc21pc3Npb24gDQog ICBhbmQgbmV3IExTQSBnZW5lcmF0aW9uIGFmdGVyIGRldGVjdGlvbiBvZiBhIGZhaWx1cmUgb3Ig cmVjb3ZlcnkuDQoNCiAgIEJ1ZmZlciBTaXplIGZvciBJbmNvbWluZyBMU1VzL0Fja3MvSGVsbG9z IChsb3dlciBwcmlvcml0eSk6IEJ1ZmZlciANCg0KICAgICAgICAgIA0KICAgQ2hvdWRodXJ5IGV0 LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoM DQogICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICBFeHBsaWNpdCBNYXJraW5nICAgICAgICAgICAg ICAgICBNYXksIDIwMDMNCg0KDQogICBzaXplIGlzIGFzc3VtZWQgdG8gYmUgMjAwMCBwYWNrZXRz IHdoZXJlIGEgcGFja2V0IGlzIGVpdGhlciBhbiBBY2ssIA0KICAgTFNVLCBvciBIZWxsby4gDQoN CiAgIExTQSBSZWZyZXNoOiBFYWNoIExTQSBpcyByZWZyZXNoZWQgb25jZSBpbiAxODAwIHNlY29u ZHMgYW5kIHRoZSANCiAgIHJlZnJlc2ggaW5zdGFudHMgb2YgdmFyaW91cyBMU0FzIGluIHRoZSBM U0RCIGFyZSBhc3N1bWVkIHRvIGJlIA0KICAgdW5pZm9ybWx5IGRpc3RyaWJ1dGVkIG92ZXIgdGhl IDE4MDAgc2Vjb25kcyBwZXJpb2QsIGkuZS4sIHRoZXkgYXJlIA0KICAgY29tcGxldGVseSB1bnN5 bmNocm9uaXplZC4gIElmIGhvd2V2ZXIsIGFuIExTQSBpcyBnZW5lcmF0ZWQgYXMgcGFydCANCiAg IG9mIHRoZSBpbml0aWFsIExTQSBzdG9ybSB0aGVuIGl0IGdvZXMgb24gYSBuZXcgcmVmcmVzaCBz Y2hlZHVsZSBvZiANCiAgIG9uY2UgaW4gMTgwMCBzZWNvbmRzIHN0YXJ0aW5nIGZyb20gaXRzIGdl bmVyYXRpb24gdGltZS4gICANCg0KICAgTFNBIFN0b3JtIEdlbmVyYXRpb246IEFzIGRlZmluZWQg ZWFybGllciwgIkxTQSBzdG9ybSIgaXMgdGhlIA0KICAgc2ltdWx0YW5lb3VzIG9yIG5lYXIgc2lt dWx0YW5lb3VzIGdlbmVyYXRpb24gb2YgYSBsYXJnZSBudW1iZXIgb2YgDQogICBMU0FzLiBJbiB0 aGUgY2FzZSBvZiBvbmx5IFJvdXRlciBhbmQgQVNFIExTQXMgd2Ugbm9ybWFsbHkgYXNzdW1lICAN CiAgIHRoYXQgdGhlIG51bWJlciBvZiBBU0UgTFNBcyBpbiB0aGUgc3Rvcm0gaXMgYWJvdXQgNCB0 aW1lcyB0aGF0IG9mICANCiAgIHRoZSBSb3V0ZXIgTFNBcywgYnV0IHRoZSByYXRpbyBpcyBhbGxv d2VkIHRvIGNoYW5nZSBpZiBlaXRoZXIgdGhlICANCiAgIFJvdXRlciBvciB0aGUgQVNFIExTQXMg aGF2ZSByZWFjaGVkIHRoZWlyIG1heGltdW0gcG9zc2libGUgdmFsdWUuICAgDQogICBJbiB0aGUg Y2FzZSBvZiBvbmx5IFJvdXRlciBhbmQgTGluayBMU0FzIChjYXJyeWluZyB0cmFmZmljICANCiAg IGVuZ2luZWVyaW5nIGluZm9ybWF0aW9uKSB3ZSBub3JtYWxseSBhc3N1bWUgdGhhdCB0aGUgbnVt YmVyIG9mIExpbmsgIA0KICAgTFNBcyBpbiB0aGUgc3Rvcm0gaXMgYWJvdXQgNCB0aW1lcyB0aGF0 IG9mIHRoZSBSb3V0ZXIgTFNBcywgYnV0IHRoZSAgDQogICByYXRpbyBpcyBhbGxvd2VkIHRvIGNo YW5nZSBpZiBlaXRoZXIgdGhlIFJvdXRlciBvciB0aGUgTGluayBMU0FzICANCiAgIGhhdmUgcmVh Y2hlZCB0aGVpciBtYXhpbXVtIHBvc3NpYmxlIHZhbHVlLiAgRm9yIGFueSBnaXZlbiBMU0Egc3Rv cm0gIA0KICAgd2Uga2VlcCBnZW5lcmF0aW5nIExTQXMgc3RhcnRpbmcgZnJvbSBOb2RlIGluZGV4 IDEgYW5kIG1vdmluZyAgDQogICB1cHdhcmRzIGFuZCBzdG9wIHVudGlsIHRoZSBjb3JyZWN0IG51 bWJlciBvZiBMU0FzIG9mIGVhY2ggdHlwZSBoYXZlICANCiAgIGJlZW4gZ2VuZXJhdGVkLiAgVGhl IExTQXMgZ2VuZXJhdGVkIGF0IGFueSBnaXZlbiBub2RlIGlzIGFzc3VtZWQgdG8gIA0KICAgc3Rh cnQgYXQgYW4gaW5zdGFudCB1bmlmb3JtbHkgZGlzdHJpYnV0ZWQgYmV0d2VlbiAyMCBhbmQgMzAg c2Vjb25kcyANCiAgIGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBzaW11bGF0aW9uLiAgU3VjY2Vzc2l2 ZSBMU0EgZ2VuZXJhdGlvbnMgYXQgYSAgDQogICBub2RlIGFyZSBhc3N1bWVkIHRvIGJlIHNwYWNl ZCBhcGFydCBieSA0MDAgbXMuIEl0IGlzIHRvIGJlIG5vdGVkICANCiAgIHRoYXQgZHVyaW5nIHRo ZSBwZXJpb2Qgb2Ygb2JzZXJ2YXRpb24gdGhlcmUgYXJlIG90aGVyIExTQXMgIA0KICAgZ2VuZXJh dGVkIGJlc2lkZXMgdGhlIG9uZXMgaW4gdGhlIHN0b3JtLiAgVGhlc2UgaW5jbHVkZSByZWZyZXNo IG9mICANCiAgIExTQXMgdGhhdCBhcmUgbm90IHBhcnQgb2YgdGhlIHN0b3JtIGFuZCBMU0FzIGdl bmVyYXRlZCBkdWUgdG8gIA0KICAgcG9zc2libGUgbGluayBmYWlsdXJlcyBhbmQgc3Vic2VxdWVu dCBwb3NzaWJsZSBsaW5rIHJlY292ZXJpZXMuDQoNCiAgIEZhaWx1cmUvUmVjb3Zlcnkgb2YgTGlu a3M6IElmIG5vIEhlbGxvIGlzIHJlY2VpdmVkIG92ZXIgYSBsaW5rIChkdWUgDQogICB0byBDUFUv bWVtb3J5IGNvbmdlc3Rpb24pIGZvciBsb25nZXIgdGhhbiBSb3V0ZXItRGVhZCBJbnRlcnZhbCB0 aGVuDQogICB0aGUgbGluayBpcyBkZWNsYXJlZCBkb3duLiAgQXQgYSBsYXRlciB0aW1lLCBpZiBI ZWxsb3MgYXJlIHJlY2VpdmVkDQogICB0aGVuIHRoZSBsaW5rIHdvdWxkIGJlIGRlY2xhcmVkIHVw LiAgV2hlbmV2ZXIgYSBsaW5rIGlzIGRlY2xhcmVkDQogICB1cCBvciBkb3duLCBvbmUgUm91dGVy IExTQSBpcyBnZW5lcmF0ZWQgYnkgZWFjaCBSb3V0ZXIgb24gdGhlDQogICB0d28gc2lkZXMgb2Yg dGhlIHBvaW50LXRvLXBvaW50IGxpbmsuICBJZiAiTGluayBMU0FzIiBjYXJyeWluZw0KICAgdHJh ZmZpYyBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbiBpcyB1c2VkIHRoZW4gaXQgaXMgYXNzdW1lZCB0 aGF0IGVhY2gNCiAgIFJvdXRlciB3b3VsZCBhbHNvIGdlbmVyYXRlIGEgTGluayBMU0EuICBJbiB0 aGlzIGNhc2UgaXQgaXMgYWxzbyANCiAgIGFzc3VtZWQgdGhhdCBkdWUgdG8gcmVyb3V0aW5nIG9m IExTUHMsIHRocmVlIG90aGVyIGxpbmtzIGluIHRoZSANCiAgIG5ldHdvcmsgKHNlbGVjdGVkIHJh bmRvbWx5IGluIHRoZSBzaW11bGF0aW9uKSB3b3VsZCBoYXZlIHNpZ25pZmljYW50IA0KICAgY2hh bmdlIGluIHJlc2VydmVkIGJhbmR3aWR0aCB3aGljaCB3b3VsZCByZXN1bHQgaW4gb25lIExpbmsg TFNBIA0KICAgYmVpbmcgZ2VuZXJhdGVkIGJ5IHRoZSByb3V0ZXJzIG9uIHRoZSB0d28gZW5kcyBv ZiBlYWNoIHN1Y2ggbGluay4NCg0KDQozLiBTaW11bGF0aW9uIFJlc3VsdHMNCg0KICAgSW4gdGhp cyBzZWN0aW9uIHdlIHN0dWR5IHRoZSByZWxhdGl2ZSBwZXJmb3JtYW5jZSBvZiB0aGUgdGhyZWUg DQoNCiAgICAgICAgICANCiAgIENob3VkaHVyeSBldC4gYWwuICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgRXhwbGljaXQgTWFya2luZyAgICAgICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0KICAgUHJp b3JpdHkgc2NlbmFyaW9zIGRlZmluZWQgZWFybGllciAobm8gcHJpb3JpdHkgdG8gSGVsbG8gb3Ig QWNrLCANCiAgIHByaW9yaXR5IHRvIEhlbGxvIG9ubHksIGFuZCBwcmlvcml0eSB0byBib3RoIEhl bGxvIGFuZCBBY2spIHdpdGggYSANCiAgIHJhbmdlIG9mIE5ldHdvcmsgc2l6ZXMsIExTQSByZXRy YW5zbWlzc2lvbiB0aW1lciB2YWx1ZXMsIExTQSB0eXBlcywgDQogICBwcm9jZXNzaW5nIHRpbWUg dmFsdWVzIGFuZCBIZWxsby9Sb3V0ZXItRGVhZC1JbnRlcnZhbCB2YWx1ZXM6DQogICANCiAgIE5l dHdvcmsgc2l6ZTogVHdvIG5ldHdvcmtzIGFyZSBjb25zaWRlcmVkLiAgTmV0d29yayAxIGhhcyAx MDAgbm9kZXMsIA0KICAgMTIwMCBsaW5rcywgbWF4aW11bSBudW1iZXIgb2YgbmVpZ2hib3JzIHBl ciBub2RlIGlzIDMwIGFuZCBtYXhpbXVtIA0KICAgbnVtYmVyIG9mIGFkamFjZW5jaWVzIHBlciBu b2RlIGlzIDUwIChzYW1lIG5laWdoYm9yIG1heSBoYXZlIG1vcmUgDQogICB0aGFuIG9uZSBhZGph Y2VuY2llcykuICAgTmV0d29yayAyIGhhcyA1MCBub2RlcywgNjAwIGxpbmtzLCBtYXhpbXVtIA0K ICAgbnVtYmVyIG9mIG5laWdoYm9ycyBwZXIgbm9kZSBpcyAyNSBhbmQgbWF4aW11bSBudW1iZXIg b2YgYWRqYWNlbmNpZXMgDQogICBwZXIgbm9kZSBpcyA0OC4gRGlqa3N0cmEgU1BGIGNhbGN1bGF0 aW9uIHRpbWUgZm9yIE5ldHdvcmsgMSBpcyAgDQogICBhc3N1bWVkIHRvIGJlIDEwMCBtcyBhbmQg dGhhdCBmb3IgTmV0d29yayAyIGlzIGFzc3VtZWQgdG8gYmUgNzAgbXMuDQoNCiAgIExTQSBUeXBl OiBFYWNoIG5vZGUgaGFzIDEgUm91dGVyIExTQSAoVG90YWwgb2YgMTAwIGZvciBOZXR3b3JrIDEg YW5kIA0KICAgNTAgZm9yIE5ldHdvcmsgMikuIFRoZXJlIGFyZSBubyBOZXR3b3JrIExTQXMgc2lu Y2UgYWxsIGxpbmtzIGFyZSANCiAgIHBvaW50LXRvLXBvaW50IGxpbmtzIGFuZCBubyBTdW1tYXJ5 IExTQXMgc2luY2UgdGhlIG5ldHdvcmsgaGFzIG9ubHkgDQogICBvbmUgYXJlYS4gUmVnYXJkaW5n IG90aGVyIExTQSB0eXBlcyB3ZSBjb25zaWRlciB0d28gc2l0dWF0aW9ucy4gIEluICANCiAgIFNp dHVhdGlvbiAxIHdlIGFzc3VtZSB0aGF0IHRoZXJlIGFyZSBubyBBU0UgTFNBcyBhbmQgZWFjaCBs aW5rIGhhcyAgDQogICBvbmUgIkxpbmsiIExTQSBjYXJyeWluZyB0cmFmZmljIGVuZ2luZWVyaW5n IGluZm9ybWF0aW9uIChUb3RhbCBvZiAgDQogICAyNDAwIGZvciBOZXR3b3JrIDEgYW5kIDEyMDAg Zm9yIE5ldHdvcmsgMikuIEluIFNpdHVhdGlvbiAyIHdlIGFzc3VtZQ0KICAgdGhhdCB0aGVyZSBh cmUgbm8gIkxpbmsiIExTQXMgYW5kIGhhbGYgb2YgdGhlIG5vZGVzIGFyZSBBU0EtQm9yZGVyICAN CiAgIG5vZGVzIGFuZCBlYWNoIGJvcmRlciBub2RlIGhhcyAxMCBBU0UgTFNBcyAoVG90YWwgb2Yg NTAwIGZvciAgDQogICBOZXR3b3JrIDEgYW5kIDI1MCBmb3IgTmV0d29yayAyKS4gIFdlIGlkZW50 aWZ5IFNpdHVhdGlvbiAxIGFzICJMaW5rICANCiAgIExTQXMiIGFuZCBTaXR1YXRpb24gMiBhcyAi QVNFIExTQXMiLg0KDQogICBMU0EgcmV0cmFuc21pc3Npb24gdGltZXIgdmFsdWU6IFR3byB2YWx1 ZXMgYXJlIGNvbnNpZGVyZWQsIDEwIA0KICAgc2Vjb25kcyBhbmQgNSBzZWNvbmRzIChkZWZhdWx0 IHZhbHVlKS4NCg0KICAgUHJvY2Vzc2luZyB0aW1lIHZhbHVlczogUHJvY2Vzc2luZyB0aW1lcyBm b3IgTFNVcywgQWNrcyBhbmQgSGVsbG8gDQogICBwYWNrZXRzIGhhdmUgYmVlbiBwcmV2aW91c2x5 IGV4cHJlc3NlZCBpbiB0ZXJtcyBvZiBhIGNvbW1vbiAgDQogICBwYXJhbWV0ZXIgVC4gIFR3byB2 YWx1ZXMgYXJlIGNvbnNpZGVyZWQgZm9yIFQsIHdoaWNoIGFyZSAxIG1zIA0KICAgYW5kIDAuNSBt cyByZXNwZWN0aXZlbHkuDQogICANCiAgIEhlbGxvL1JvdXRlci1EZWFkLUludGVydmFsOiBJdCBp cyBhc3N1bWVkIHRoYXQgUm91dGVyLURlYWQgaW50ZXJ2YWwNCiAgIGlzIGZvdXIgdGltZXMgdGhl IEhlbGxvIGludGVydmFsLiAgSW4gb25lIGNhc2UgaXQgaXMgYXNzdW1lZCB0aGF0DQogICBIZWxs byBpbnRlcnZhbCBpcyAxMCBzZWNvbmRzIGFuZCBSb3V0ZXItRGVhZC1JbnRlcnZhbCBpcyA0MA0K ICAgc2Vjb25kcyAoZGVmYXVsdCB2YWx1ZXMpLCBhbmQgaW4gdGhlIG90aGVyIGNhc2UgaXQgaXMg YXNzdW1lZCB0aGF0IA0KICAgSGVsbG8gaW50ZXJ2YWwgaXMgMiBzZWNvbmRzIGFuZCBSb3V0ZXIt RGVhZC1JbnRlcnZhbCBpcyA4IHNlY29uZHMuIA0KDQogICBCYXNlZCBvbiBOZXR3b3JrIHNpemUs IExTQSB0eXBlIGFuZCBwcm9jZXNzaW5nIHRpbWUgdmFsdWVzIHdlIA0KICAgZGV2ZWxvcCA2IFRl c3QgY2FzZXMgYXMgZm9sbG93czoNCg0KICAgQ2FzZSAxOiBOZXR3b3JrIDEsIExpbmsgTFNBcywg cmV0cmFuc21pc3Npb24gdGltZXIgPSAxMCBzZWMuLCANCiAgICAgICAgICAgVCA9IDEgbXMsIEhl bGxvL1JvdXRlci1EZWFkLUludGVydmFsID0gMTAvNDAgc2VjLg0KDQogICBDYXNlIDI6IE5ldHdv cmsgMSwgQVNFIExTQXMsIHJldHJhbnNtaXNzaW9uIHRpbWVyID0gMTAgc2VjLiwgDQogICAgICAg ICAgIFQgPSAxIG1zLCBIZWxsby9Sb3V0ZXItRGVhZC1JbnRlcnZhbCA9IDEwLzQwIHNlYy4NCg0K ICAgQ2FzZSAzOiBOZXR3b3JrIDEsIExpbmsgTFNBcywgcmV0cmFuc21pc3Npb24gdGltZXIgPSA1 IHNlYy4sIA0KDQogICAgICAgICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCiAgIEludGVybmV0IERyYWZ0 ICAgICAgICAgIEV4cGxpY2l0IE1hcmtpbmcgICAgICAgICAgICAgICAgIE1heSwgMjAwMw0KDQoN CiAgICAgICAgICAgVCA9IDEgbXMsIEhlbGxvL1JvdXRlci1EZWFkLUludGVydmFsID0gMTAvNDAg c2VjLg0KDQogICBDYXNlIDQ6IE5ldHdvcmsgMSwgTGluayBMU0FzLCByZXRyYW5zbWlzc2lvbiB0 aW1lciA9IDEwIHNlYy4sIA0KICAgICAgICAgICBUID0gMC41IG1zLCBIZWxsby9Sb3V0ZXItRGVh ZC1JbnRlcnZhbCA9IDEwLzQwIHNlYy4NCg0KICAgQ2FzZSA1OiBOZXR3b3JrIDEsIExpbmsgTFNB cywgcmV0cmFuc21pc3Npb24gdGltZXIgPSAxMCBzZWMuLCANCiAgICAgICAgICAgVCA9IDEgbXMs IEhlbGxvL1JvdXRlci1EZWFkLUludGVydmFsID0gMi84IHNlYy4NCg0KICAgQ2FzZSA2OiBOZXR3 b3JrIDIsIExpbmsgTFNBcywgcmV0cmFuc21pc3Npb24gdGltZXIgPSAxMCBzZWMuLCANCiAgICAg ICAgICAgVCA9IDEgbXMsIEhlbGxvL1JvdXRlci1EZWFkLUludGVydmFsID0gMTAvNDAgc2VjLg0K DQoNCiAgIEZvciBlYWNoIGNhc2UgYW5kIGZvciBlYWNoIFByaW9yaXR5IHNjZW5hcmlvIHdlIHN0 dWR5IHRoZSBuZXR3b3JrIA0KICAgc3RhYmlsaXR5IGFzIGEgZnVuY3Rpb24gb2YgdGhlIHNpemUg b2YgdGhlIExTQSBzdG9ybS4gIFRoZSBzdGFiaWxpdHkNCiAgIGlzIGRldGVybWluZWQgYnkgbG9v a2luZyBhdCB0aGUgbnVtYmVyIG9mIG5vbi1jb252ZXJnZWQgTFNVcyBhcyBhICAgDQogICBmdW5j dGlvbiBvZiB0aW1lLiBBbiBleGFtcGxlIGlzIHNob3duIGluIFRhYmxlIDEgZm9yIENhc2UgMSBh bmQgDQogICBQcmlvcml0eSBzY2VuYXJpbyAxIChObyBwcmlvcml0eSB0byBIZWxsb3Mgb3IgQWNr cykuDQogICANCj09PT09PT09PXw9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQogICAgICAgICB8IE51bWJlciBvZiBOb24tQ29udmVyZ2Vk IExTVXMgaW4gdGhlIE5ldHdvcmsgYXQgVGltZShpbiBzZWMpDQogICAgTFNBICB8ICAgICAgICAg ICAgICAgICAgICANCiAgIFNUT1JNIHw9PT09fD09PT09fD09PT09fD09PT09fD09PT09fD09PT09 fD09PT09fD09PT09fD09PT09PT09fD09DQogICBTSVpFICB8MTBzIHwgMjBzIHwgMzBzIHwgMzVz IHwgNDBzIHwgNTBzIHwgNjBzIHwgODBzIHwgMTAwcyAgIHwNCj09PT09PT09PXw9PT09fD09PT09 fD09PT09fD09PT09fD09PT09fD09PT09fD09PT09fD09PT09fD09PT09PT09fD09DQogICAgMTAw ICB8IDAgIHwgIDAgIHwgMjQgIHwgMjkgIHwgMjQgIHwgIDEgIHwgIDAgIHwgIDEgIHwgIDEgICAg IHwNCiAoU3RhYmxlKXwgICAgfCAgICAgfCAgICAgfCAgICAgfCAgICAgfCAgICAgfCAgICAgfCAg ICAgfCAgICAgICAgfA0KLS0tLS0tLS0tfC0tLS18LS0tLS18LS0tLS18LS0tLS18LS0tLS18LS0t LS18LS0tLS18LS0tLS18LS0tLS0tLS18LS0NCiAgICAxNDAgIHwgMCAgfCAgMCAgfCAzNSAgfCA0 OCAgfCA0NiAgfCAyNyAgfCAxNCAgfCAgMSAgfCAgMSAgICAgfA0KIChTdGFibGUpfCAgICB8ICAg ICB8ICAgICB8ICAgICB8ICAgICB8ICAgICB8ICAgICB8ICAgICB8ICAgICAgICB8DQotLS0tLS0t LS18LS0tLXwtLS0tLXwtLS0tLXwtLS0tLXwtLS0tLXwtLS0tLXwtLS0tLXwtLS0tLXwtLS0tLS0t LXwtLQ0KICAgIDE2MCAgfCAwICB8ICAwICB8IDM4ICB8IDU3ICB8IDU1ICB8IDQwICB8IDI2ICB8 IDY1ICB8IDIwMyAgICB8DQooVW5zdGFibGUpICAgIHwgICAgIHwgICAgIHwgICAgIHwgICAgIHwg ICAgIHwgICAgIHwgICAgIHwgICAgICAgIHwNCj09PT09PT09PXw9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCiAgICAgICAgICAgVGFi bGUgMTogTmV0d29yayBTdGFiaWxpdHkgVnMuIExTQSBTdG9ybSANCiAgICAgICAgICAgICAgKENh c2UgMSwgTm8gcHJpb3JpdHkgdG8gSGVsbG8vQWNrKQ0KDQogICANCg0KICAgVGhlIExTQSBzdG9y bSBzdGFydHMgYSBsaXR0bGUgYWZ0ZXIgMjAgc2Vjb25kcyBhbmQgc28gZm9yIHNvbWUgDQogICBw ZXJpb2Qgb2YgdGltZSBhZnRlciB0aGF0IHRoZSBudW1iZXIgb2Ygbm9uLWNvbnZlcmdlZCBMU1Vz IHNob3VsZA0KICAgc3RheSBoaWdoIGFuZCB0aGVuIGNvbWUgZG93biBmb3IgYSBzdGFibGUgbmV0 d29yay4gDQogICBUaGlzIGhhcHBlbnMgZm9yIExTQSBzdG9ybXMgb2Ygc2l6ZXMgMTAwIGFuZCAx NDAuICBXaXRoIGFuIExTQSBzdG9ybQ0KICAgb2Ygc2l6ZSAxNjAsIHRoZSBudW1iZXIgb2Ygbm9u LWNvbnZlcmdlZCBMU1VzIHN0YXkgaGlnaCBpbmRlZmluaXRlbHkNCiAgIGR1ZSB0byByZXBlYXRl ZCByZXRyYW5zbWlzc2lvbnMsIGxpbmsgZmFpbHVyZXMgZHVlIHRvIG1pc3NlZCBIZWxsb3MgIA0K ICAgZm9yIG1vcmUgdGhhbiB0aGUgUm91dGVyLURlYWQgaW50ZXJ2YWwgd2hpY2ggZ2VuZXJhdGVz IGFkZGl0aW9uYWwgDQogICBMU0FzIGFuZCBhbHNvIGR1ZSB0byBzdWJzZXF1ZW50IGxpbmsgcmVj b3ZlcmllcyB3aGljaCBhZ2FpbiANCiAgIGdlbmVyYXRlIGFkZGl0aW9uYWwgTFNBcy4gIFdlIGRl ZmluZSBuZXR3b3JrIHN0YWJpbGl0eSB0aHJlc2hvbGQgYXMNCiAgIHRoZSBtYXhpbXVtIGFsbG93 YWJsZSBMU0Egc3Rvcm0gc2l6ZSBmb3Igd2hpY2ggdGhlIG51bWJlciBvZiANCg0KICAgICAgICAg IA0KICAgQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDldDQoMDQogICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICBFeHBsaWNpdCBN YXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQogICBub24tY29udmVyZ2VkIExT VXMgY29tZSBkb3duIHRvIGEgbG93IGxldmVsIGFmdGVyIHNvbWUgdGltZS4gSXQgDQogICB0dXJu cyBvdXQgdGhhdCBmb3IgdGhpcyBleGFtcGxlIHRoZSBzdGFiaWxpdHkgdGhyZXNob2xkIGlzDQog ICAxNTAuIA0KDQogICBUaGUgbmV0d29yayBiZWhhdmlvciBhcyBhIGZ1bmN0aW9uIG9mIHRoZSBM U0Egc3Rvcm0gc2l6ZSBjYW4NCiAgIGJlIGNhdGVnb3JpemVkIGFzIGZvbGxvd3M6DQoNCiAgICgx KSBJZiB0aGUgTFNBIHN0b3JtIGlzIHdlbGwgYmVsb3cgdGhlIHN0YWJpbGl0eSB0aHJlc2hvbGQg dGhlbg0KICAgICAgIHRoZSBDUFUvbWVtb3J5IGNvbmdlc3Rpb24gbGFzdHMgb25seSBmb3IgYSBz aG9ydCBwZXJpb2QgYW5kDQogICAgICAgZHVyaW5nIHRoaXMgcGVyaW9kIHRoZXJlIGFyZSB2ZXJ5 IGZldyByZXRyYW5zbWlzc2lvbnMsIHZlcnkNCiAgICAgICBmZXcgZHJvcHBlZCBPU1BGIHBhY2tl dHMgYW5kIG5vIGxpbmsNCiAgICAgICBmYWlsdXJlcyBkdWUgdG8gbWlzc2VkIEhlbGxvcy4gIFRo aXMgdHlwZSBvZiBMU0Egc3Rvcm1zIGFyZQ0KICAgICAgIG9ic2VydmVkIHJvdXRpbmVseSBpbiBv cGVyYXRpb25hbCBuZXR3b3JrcyBhbmQgbmV0d29ya3MNCiAgICAgICByZWNvdmVyIGZyb20gdGhl bSBlYXNpbHkuDQoNCiAgICgyKSBJZiB0aGUgTFNBIHN0b3JtIGlzIGp1c3QgYmVsb3cgdGhlIHN0 YWJpbGl0eSB0aHJlc2hvbGQgdGhlbg0KICAgICAgIHRoZSBDUFUvbWVtb3J5IGNvbmdlc3Rpb24g bGFzdHMgZm9yIGEgbG9uZ2VyIHBlcmlvZCBhbmQgZHVyaW5nDQogICAgICAgdGhpcyBwZXJpb2Qg dGhlcmUgbWF5IGJlIGNvbnNpZGVyYWJsZSBhbW91bnQgb2YgcmV0cmFuc21pc3Npb25zDQogICAg ICAgYW5kIGRyb3BwZWQgT1NQRiBwYWNrZXRzLiAgSWYgSGVsbG8gcGFja2V0cyBhcmUgbm90IGdp dmVuDQogICAgICAgcHJpb3JpdHkgdGhlbiB0aGVyZSBtYXkgYWxzbyBiZSBzb21lIGxpbmsgZmFp bHVyZXMgZHVlIHRvDQogICAgICAgbWlzc2VkIEhlbGxvcy4gIEhvd2V2ZXIsIHRoZSBuZXR3b3Jr IGRvZXMgZ28gYmFjayB0byBhIHN0YWJsZQ0KICAgICAgIHN0YXRlIGV2ZW50dWFsbHkuIFRoaXMg dHlwZSBvZiBMU0Egc3Rvcm0gbWF5IGhhcHBlbiByYXJlbHkgaW4NCiAgICAgICBvcGVyYXRpb25h bCBuZXR3b3JrcyBhbmQgdGhleSByZWNvdmVyIGZyb20gaXQgd2l0aCBzb21lDQogICAgICAgZGlm ZmljdWx0eS4gDQoNCiAgICgzKSBJZiB0aGUgTFNBIHN0b3JtIGlzIGFib3ZlIHRoZSBzdGFiaWxp dHkgdGhyZXNob2xkIHRoZW4NCiAgICAgICB0aGUgQ1BVL21lbW9yeSBjb25nZXN0aW9uIG1heSBs YXN0IGluZGVmaW5pdGVseSB1bmxlc3MNCiAgICAgICBzb21lIHNwZWNpYWwgcHJvY2VkdXJlIGZv ciByZWxpZXZpbmcgY29uZ2VzdGlvbiBpcyBmb2xsb3dlZC4gDQogICAgICAgRHVyaW5nIHRoaXMg cGVyaW9kIHRoZXJlIGFyZSBjb25zaWRlcmFibGUgYW1vdW50IG9mIA0KICAgICAgIHJldHJhbnNt aXNzaW9ucyBhbmQgZHJvcHBlZCBPU1BGIHBhY2tldHMuICBJZiBIZWxsbyBwYWNrZXRzIGFyZQ0K ICAgICAgIG5vdCBnaXZlbiBwcmlvcml0eSB0aGVuIHRoZXJlIHdvdWxkIGFsc28gYmUgbGluayBm YWlsdXJlcyBkdWUgDQogICAgICAgdG8gbWlzc2VkIEhlbGxvcy4gIFRoaXMgdHlwZSBvZiBMU0Eg c3Rvcm0gbWF5IGhhcHBlbiB2ZXJ5IA0KICAgICAgIHJhcmVseSBpbiBvcGVyYXRpb25hbCBuZXR3 b3JrcyBhbmQgdXN1YWxseSBzb21lIG1hbnVhbCBwcm9jZWR1cmUNCiAgICAgICBzdWNoIGFzIHRh a2luZyBkb3duIGFkamFjZW5jaWVzIGluIGhlYXZpbHkgY29uZ2VzdGVkIG5vZGVzIGlzDQogICAg ICAgbmVlZGVkLg0KDQogICAoNCkgSWYgSGVsbG8gcGFja2V0cyBhcmUgZ2l2ZW4gcHJpb3JpdHkg dGhlbiB0aGUgbmV0d29yayBzdGFiaWxpdHkNCiAgICAgICB0aHJlc2hvbGQgaW5jcmVhc2VzLCBp LmUuLCB0aGUgbmV0d29yayBjYW4gd2l0aHN0YW5kIGEgbGFyZ2VyDQogICAgICAgTFNBIHN0b3Jt LiBGdXJ0aGVybW9yZSwgZXZlbiBpZiB0aGUgbmV0d29yayBvcGVyYXRlcyBhdCBvciANCiAgICAg ICBzb21ld2hhdCBhYm92ZSB0aGlzIGhpZ2hlciBzdGFiaWxpdHkgdGhyZXNob2xkLCBIZWxsb3Mg YXJlIA0KICAgICAgIHN0aWxsIG5vdCBtaXNzZWQgYW5kIHNvIHRoZXJlIGFyZSBubyBsaW5rIGZh aWx1cmVzLiAgU28gZXZlbiANCiAgICAgICBpZiB0aGVyZSBpcyBjb25nZXN0aW9uIGluIHRoZSBj b250cm9sIHBsYW5lIGR1ZSB0byBpbmNyZWFzZWQgDQogICAgICAgcmV0cmFuc21pc3Npb25zIHJl cXVpcmluZyBzb21lIHNwZWNpYWwgcHJvY2VkdXJlcyBmb3IgY29uZ2VzdGlvbg0KICAgICAgIHJl ZHVjdGlvbiwgdGhlIGRhdGEgcGxhbmUgcmVtYWlucyB1bmFmZmVjdGVkLg0KICAgICAgICANCiAg ICg1KSBJZiBib3RoIEhlbGxvIGFuZCBBY2tub3dsZWRnZW1lbnQgcGFja2V0cyBhcmUgZ2l2ZW4g cHJpb3JpdHkNCiAgICAgICB0aGVuIHRoZSBzdGFiaWxpdHkgdGhyZXNob2xkIGluY3JlYXNlcyBl dmVuIGZ1cnRoZXIuICAgICAgIA0KICAgDQoNCg0KICAgICAgICAgIA0KICAgQ2hvdWRodXJ5IGV0 LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0K DA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgRXhwbGljaXQgTWFya2luZyAgICAgICAgICAg ICAgICAgTWF5LCAyMDAzDQoNCg0KICAgSW4gVGFibGUgMiB3ZSBzaG93IHRoZSBuZXR3b3JrIHN0 YWJpbGl0eSB0aHJlc2hvbGQgZm9yIHRoZSBmaXZlICANCiAgIGRpZmZlcmVudCBjYXNlcyBhbmQg Zm9yIHRoZSB0aHJlZSBkaWZmZXJlbnQgcHJpb3JpdHkgc2NlbmFyaW9zDQogICBkZWZpbmVkIGVh cmxpZXIuICANCg0KfD09PT09PT09PT09fD09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09fA0KfCAgICAgICAgICAgfCAgICBNYXhpbXVtIEFsbG93 YWJsZSBMU0EgU3Rvcm0gU2l6ZSBGb3IgICAgICAgICAgICAgICAgfA0KfCAgIENhc2UgICAgfD09 PT09PT09PT09PT09PT09fD09PT09PT09PT09PT09PT09PXw9PT09PT09PT09PT09PT09PT09fA0K fCAgTnVtYmVyICAgfCBObyBQcmlvcml0eSB0byAgfFByaW9yaXR5IHRvIEhlbGxvIHwgUHJpb3Jp dHkgdG8gSGVsbG8gfA0KfCAgICAgICAgICAgfCAgSGVsbG8gb3IgQWNrICAgfCAgICAgIE9ubHkg ICAgICAgIHwgICBhbmQgQWNrICAgICAgICAgfA0KfD09PT09PT09PT09fD09PT09PT09PT09PT09 PT09fD09PT09PT09PT09PT09PT09PXw9PT09PT09PT09PT09PT09PT09fA0KfCAgIENhc2UgMSAg fCAgICAgICAgMTUwICAgICAgfCAgICAgICAgMTkwICAgICAgIHwgICAgICAgIDI1MCAgICAgICAg fA0KfF9fX19fX19fX19ffF9fX19fX19fX19fX19fX19ffF9fX19fX19fX19fX19fX19fX3xfX19f X19fX19fX19fX19fX19ffA0KfCAgIENhc2UgMiAgfCAgICAgICAgMTg1ICAgICAgfCAgICAgICAg MjE1ICAgICAgIHwgICAgICAgIDI4NSAgICAgICAgfA0KfF9fX19fX19fX19ffF9fX19fX19fX19f X19fX19ffF9fX19fX19fX19fX19fX19fX3xfX19fX19fX19fX19fX19fX19ffA0KfCAgIENhc2Ug MyAgfCAgICAgICAgMTE1ICAgICAgfCAgICAgICAgMTI3ICAgICAgIHwgICAgICAgIDE3MCAgICAg ICAgfA0KfF9fX19fX19fX19ffF9fX19fX19fX19fX19fX19ffF9fX19fX19fX19fX19fX19fX3xf X19fX19fX19fX19fX19fX19ffA0KfCAgIENhc2UgNCAgfCAgICAgICAgMzIwICAgICAgfCAgICAg ICAgMzc1ICAgICAgIHwgICAgICAgIDU4MCAgICAgICAgfA0KfF9fX19fX19fX19ffF9fX19fX19f X19fX19fX19ffF9fX19fX19fX19fX19fX19fX3xfX19fX19fX19fX19fX19fX19ffA0KfCAgIENh c2UgNSAgfCAgICAgICAgMTIwICAgICAgfCAgICAgICAgMTc1ICAgICAgIHwgICAgICAgIDIyNSAg ICAgICAgfA0KfF9fX19fX19fX19ffF9fX19fX19fX19fX19fX19ffF9fX19fX19fX19fX19fX19f X3xfX19fX19fX19fX19fX19fX19ffA0KfCAgIENhc2UgNiAgfCAgICAgICAgMTg1ICAgICAgfCAg ICAgICAgMjI0ICAgICAgIHwgICAgICAgIDI4NSAgICAgICAgfA0KfF9fX19fX19fX19ffF9fX19f X19fX19fX19fX19ffF9fX19fX19fX19fX19fX19fX3xfX19fX19fX19fX19fX19fX19ffA0KDQog ICAgICAgVGFibGUgMjogTWF4aW11bSBBbGxvd2FibGUgTFNBIFN0b3JtIGZvciBhIFN0YWJsZSBO ZXR3b3JrDQoNCg0KNC4gT2JzZXJ2YXRpb25zIG9uIFNpbXVsYXRpb24gUmVzdWx0cw0KDQogICBU YWJsZSAyIHNob3dzIHRoYXQgaW4gYWxsIGNhc2VzIHByaW9yaXRpemluZyBIZWxsbyBwYWNrZXRz IGluY3JlYXNlcw0KICAgdGhlIG5ldHdvcmsgc3RhYmlsaXR5IHRocmVzaG9sZCwgYW5kIGluIGFk ZGl0aW9uLCBwcmlvcml0aXphdGlvbiBvZiAgDQogICBMU0EgQWNrbm93bGVkZ21lbnQgcGFja2V0 cyBpbmNyZWFzZXMgdGhlIHN0YWJpbGl0eSB0aHJlc2hvbGQgZXZlbg0KICAgZnVydGhlci4gIFRo ZSByZWFzb25zIGZvciB0aGUgYWJvdmUgb2JzZXJ2YXRpb25zIGFyZSBhcyBmb2xsb3dzLg0KICAg VGhlIG1haW4gc291cmNlcyBvZiBzdXN0YWluZWQgQ1BVL21lbW9yeSBjb25nZXN0aW9uIChvciBw b3NpdGl2ZQ0KICAgZmVlZGJhY2sgbG9vcCkgZm9sbG93aW5nIGFuIExTQSBzdG9ybSBhcmUgKDEp IExTQSByZXRyYW5zbWlzc2lvbnMgDQogICBhbmQgKDIpIGxpbmtzIGJlaW5nIGRlY2xhcmVkIGRv d24gZHVlIHRvIG1pc3NlZCBIZWxsb3Mgd2hpY2ggaW4gDQogICB0dXJuIGNhdXNlcyBmdXJ0aGVy IExTQSBnZW5lcmF0aW9uIGFuZCBmdXR1cmUgcmVjb3Zlcnkgb2YgdGhlIGxpbmsgICANCiAgIGNh dXNpbmcgZXZlbiBtb3JlIExTQSBnZW5lcmF0aW9uLiANCiAgIFByaW9yaXRpemluZyBIZWxsbyBw YWNrZXRzIGF2b2lkcyBhbmQgcHJhY3RpY2FsbHkgZWxpbWluYXRlcyB0aGUNCiAgIHNlY29uZCBz b3VyY2Ugb2YgY29uZ2VzdGlvbi4gIFByaW9yaXRpemluZyBBY2tub3dsZWRnZW1lbnRzIA0KICAg c2lnbmlmaWNhbnRseSByZWR1Y2VzIHRoZSBmaXJzdCBzb3VyY2Ugb2YgY29uZ2VzdGlvbiwgaS5l LiwNCiAgIExTQSByZXRyYW5zbWlzc2lvbnMuICBJdCBpcyB0byBiZSBub3RlZCB0aGF0IHJldHJh bnNtaXNzaW9ucyBjYW4NCiAgIG5vdCBiZSBjb21wbGV0ZWx5IGVsaW1pbmF0ZWQgZHVlIHRvIHRo ZSBmb2xsb3dpbmcgcmVhc29ucy4gRmlyc3RseSwNCiAgIG9ubHkgdGhlIGV4cGxpY2l0IEFja25v d2xlZGdtZW50cyBhcmUgcHJpb3JpdGl6ZWQgYnV0IGR1cGxpY2F0ZQ0KICAgTFNBcyBjYXJyeWlu ZyBpbXBsaWNpdCBBY2tub3dsZWRnbWVudHMgYXJlIHN0aWxsIHNlcnZlZCBhdCB0aGUgDQogICBs b3dlciBwcmlvcml0eS4gIFNlY29uZGx5LCBMU0FzIG1heSBnZXQgZ3JlYXRseSBkZWxheWVkIG9y IGRyb3BwZWQNCiAgIGF0IHRoZSBpbnB1dCBxdWV1ZSBvZiByZWNlaXZlcnMgYW5kIHRoZXJlZm9y ZSBBY2tub3dsZWRnbWVudHMgbWF5DQogICBub3QgZXZlbiBnZXQgZ2VuZXJhdGVkIGluIHdoaWNo IGNhc2UgcHJpb3JpdGl6aW5nIEFja3Mgd291bGQgbm90ICAgDQogICBoZWxwLiBBbm90aGVyIGZh Y3RvciB0byBrZWVwIGluIG1pbmQgaXMgdGhhdCBzaW5jZSBIZWxsb3MgYW5kIEFja3MgIA0KICAg YXJlIHByaW9yaXRpemVkLCB0aGUgTFNBcyBzZWUgYmlnZ2VyIGRlbGF5IGFuZCBwb3RlbnRpYWwg Zm9yIA0KDQogICAgICAgICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQogICBJbnRlcm5ldCBEcmFmdCAg ICAgICAgICBFeHBsaWNpdCBNYXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQog ICBkcm9wcGluZy4gSG93ZXZlciwgdGhlIHNpbXVsYXRpb24gcmVzdWx0cyBzaG93IHRoYXQgb24g dGhlIHdob2xlIA0KICAgcHJpb3JpdGl6aW5nIEhlbGxvIGFuZCBMU0EgQWNrcyBhcmUgYWx3YXlz IGJlbmVmaWNpYWwgYW5kIA0KICAgc2lnbmlmaWNhbnRseSBpbXByb3ZlIHRoZSBuZXR3b3JrIHN0 YWJpbGl0eSB0aHJlc2hvbGQuICAgIA0KDQogICBPdXIgc2ltdWxhdGlvbiBzdHVkeSBhbHNvIHNo b3dlZCB0aGF0IGluIGVhY2ggb2YgdGhlIGNhc2VzLCBpbnN0ZWFkIA0KICAgb2YgcHJpb3JpdGl6 aW5nIEhlbGxvIHBhY2tldHMgaWYgd2UgdHJlYXQgYW55IHBhY2tldCByZWNlaXZlZCBvdmVyIA0K ICAgYSBsaW5rIGFzIGEgc3Vycm9nYXRlIGZvciBhIEhlbGxvIHBhY2tldCAoYW4gaW1wbGljaXQg SGVsbG8pIHRoZW4NCiAgIHdlIGdldCBhYm91dCB0aGUgc2FtZSBzdGFiaWxpdHkgdGhyZXNob2xk IGFzIG9idGFpbmVkIHdpdGgNCiAgIHByaW9yaXRpemluZyBIZWxsbyBwYWNrZXRzLg0KDQogICBJ ZiB3ZSBwcmlvcml0aXplIEhlbGxvIHBhY2tldHMgdGhlbiBldmVuIHdoZW4gdGhlIG5ldHdvcmsg b3BlcmF0ZXMNCiAgIHNvbWV3aGF0IGFib3ZlIHRoZSBzdGFiaWxpdHkgdGhyZXNob2xkLCBsaW5r cyBhcmUgbm90IGRlY2xhcmVkDQogICBkb3duIGR1ZSB0byBtaXNzZWQgSGVsbG9zLiAgVGhpcyBp bXBsaWVzIHRoYXQgZXZlbiB0aG91Z2ggdGhlcmUgaXMgDQogICBjb250cm9sIHBsYW5lIGNvbmdl c3Rpb24gZHVlIHRvIG1hbnkgcmV0cmFuc21pc3Npb25zLCB0aGUgZGF0YSBwbGFuZQ0KICAgc3Rh eXMgdXAgYW5kIG5vIG5ldyBMU0FzIGFyZSBnZW5lcmF0ZWQgKGJlc2lkZXMgdGhlIG9uZXMgaW4g dGhlIA0KICAgb3JpZ2luYWwgc3Rvcm0gYW5kIHRoZSByZWZyZXNoZXMpICAgDQoNCg0KNS4gTmVl ZCBmb3IgUHJpb3JpdGl6ZWQgVHJlYXRtZW50IG9mIENyaXRpY2FsIE9TUEYgUGFja2V0cyBhbmQN CiAgIFNwZWNpYWwgTWFya2luZyB0byBGYWNpbGl0YXRlIFRoYXQgDQoNCiAgIFRoZSBvYnNlcnZh dGlvbnMgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb24gY2xlYXJseSBzaG93IHRoYXQNCiAgIHByaW9y aXRpemluZyBIZWxsbyBhbmQgTFNBIEFja25vd2xlZGdtZW50IHBhY2tldHMgYXJlIGdyZWF0bHkN CiAgIGJlbmVmaWNpYWwgaW4gaW1wcm92aW5nIHRoZSBzY2FsYWJpbGl0eSBhbmQgc3RhYmlsaXR5 IG9mIGxhcmdlDQogICBuZXR3b3Jrcy4gIEluIGFkZGl0aW9uIHRvIHRoZXNlIHBhY2tldHMgaXQg bWF5IGJlIGJlbmVmaWNpYWwNCiAgIHRvIHRyZWF0IGNlcnRhaW4gb3RoZXIgT1NQRiBwYWNrZXRz IGF0IHRoZSBoaWdoZXIgcHJpb3JpdHkgYXMgd2VsbC4NCiAgIE9uZSBleGFtcGxlIChkdXJpbmcg dGhlIGRhdGFiYXNlIGV4Y2hhbmdlIHByb2Nlc3MgYmV0d2VlbiBuZWlnaGJvcnMNCiAgIGZvbGxv d2luZyBhIGxpbmsgcmVjb3ZlcnkpIGlzIHRoZSBEYXRhYmFzZSBEZXNjcmlwdGlvbiBwYWNrZXQg ZnJvbSANCiAgIGEgc2xhdmUgdGhhdCBpcyB1c2VkIGFzIGFuIGFja25vd2xlZGdtZW50IGZvciB0 aGUgcHJldmlvdXMgRGF0YWJhc2UNCiAgIERlc2NyaXB0aW9uIHBhY2tldCBzZW50IGZyb20gdGhl IG1hc3Rlci4gQW5vdGhlciBleGFtcGxlIGlzIGFuIExTQSANCiAgIGNhcnJ5aW5nIGEgY2hhbmdl IGluZm9ybWF0aW9uIHdoaWNoIG1heSB0cmlnZ2VyIFNQRiBjYWxjdWxhdGlvbg0KICAgYW5kIHJl cm91dGluZyBvZiBMYWJlbCBTd2l0Y2hlZCBQYXRocy4gSXQgaXMgcHJlZmVyYWJsZSB0byB0cmFu c21pdCAgDQogICB0aGlzIGluZm9ybWF0aW9uIGZhc3RlciB0aGFuIG90aGVyIExTQXMgaW4gdGhl IG5ldHdvcmsgdGhhdCBhcmUgIA0KICAganVzdCBvbmNlLWluLTMwLW1pbnV0ZXMgcmVmcmVzaGVz IGFuZCB0eXBpY2FsbHkgd291bGQgbm90IHRyaWdnZXINCiAgIGFueSByb3V0ZSBjb21wdXRhdGlv biBvciByb3V0ZSBjaGFuZ2UuDQoNCiAgIEdpdmVuIHRoYXQgdGhlcmUgaXMgYSBuZWVkIGZvciBw cm92aWRpbmcgcHJpb3JpdGl6ZWQgdHJlYXRtZW50DQogICB0byBjZXJ0YWluIE9TUEYgcGFja2V0 cywgdGhlIG5leHQgbmF0dXJhbCBxdWVzdGlvbiBpcyBob3cgdG8NCiAgIGZhY2lsaXRhdGUgdGhp cyBwcmlvcml0aXphdGlvbi4gIA0KDQogICBJZiBpdCBpcyBwb3NzaWJsZSB0bw0KICAgZXhhbWlu ZSB0aGUgcGFja2V0IGhlYWRlciAoZm9yIHRoZSBwdXJwb3NlIG9mIHByaW9yaXRpemF0aW9uKSAN CiAgIG11Y2ggZmFzdGVyIHRoYW4gcHJvY2Vzc2luZyB0aGUgd2hvbGUgcGFja2V0IHRoZW4gcHJp b3JpdGl6ZWQNCiAgIHRyZWF0bWVudCBpcyBwb3NzaWJsZSB3aXRob3V0IGFueSBwcm90b2NvbCBj aGFuZ2VzLg0KDQogICBIb3dldmVyLCB3ZSBhbHNvIHByb3Bvc2UgdGhhdCBhIHNwZWNpYWwgbWFy a2luZyBiZSB1c2VkIGZvcg0KICAgY2F0ZWdvcml6aW5nIGFsbCBPU1BGIHBhY2tldHMgaW50byBv bmUgb2YgdHdvIHByaW9yaXR5IGNsYXNzZXMuDQogICBJdCBpcyBhbHNvIGltcG9ydGFudCB0byBz ZXBhcmF0ZWx5IG1hcmsgT1NQRiBwYWNrZXRzIGZyb20gb3RoZXINCiAgIElQIHBhY2tldHMuICBP bmUgd2F5IHRvIGRvIHRoaXMgaXMgdG8gcmVzZXJ2ZSB0d28gZGlmZnNlcnYNCg0KICAgICAgICAg IA0KICAgQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDEyXQ0KDA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgRXhwbGljaXQg TWFya2luZyAgICAgICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0KICAgY29kZXBvaW50cywgb25l IGZvciBoaWdoZXIgcHJpb3JpdHkgT1NQRiBwYWNrZXRzIGFuZCBhbm90aGVyDQogICBvbmUgZm9y IGxvd2VyIHByaW9yaXR5IE9TUEYgcGFja2V0cy4gIFdpdGggdGhpcyBzcGVjaWFsDQogICBtYXJr aW5nIGl0IHdvdWxkIGJlIGVhc3kgZm9yIE9TUEYgaW1wbGVtZW50ZXJzIHRvDQogICB0cmVhdCBI ZWxsbywgTFNBIGFja25vd2xlZGdtZW50LCBhbmQgb3RoZXIgY3JpdGljYWwgT1NQRg0KICAgcGFj a2V0cyBhdCBhIGhpZ2hlciBwcmlvcml0eSBhbmQgdGhlcmVieSBzaWduaWZpY2FudGx5DQogICBp bXByb3ZlIHRoZSBzY2FsYWJpbGl0eSBhbmQgc3RhYmlsaXR5IG9mIG5ldHdvcmtzIHVzaW5nDQog ICBPU1BGLiAgICAgDQoNCg0KNi4gU3VtbWFyeQ0KDQogICBJbiB0aGlzIGRyYWZ0IHdlIHBvaW50 IG91dCB0aGF0IHRoZSBub2RlIHByb2Nlc3NvcnMgb2YgYSBsYXJnZSANCiAgIG5ldHdvcmsgbWF5 IGJlIHN1YmplY3RlZCB0byBhIHN1c3RhaW5lZCBDUFUvTWVtb3J5IGNvbmdlc3Rpb24NCiAgIGFz IGEgcmVzdWx0IG9mIGEgbGFyZ2UgTFNBIHN0b3JtIGNhdXNlZCBieSBzb21lIHR5cGUgb2YgDQog ICBmYWlsdXJlL3JlY292ZXJ5IG9mIG5vZGVzL2xpbmtzIG9yIHN5bmNocm9uaXphdGlvbiBhbW9u ZyByZWZyZXNoZXMuDQogICBUaGVyZSBpcyBhIGNlcnRhaW4gTFNBIHN0b3JtIHNpemUgdGhyZXNo b2xkIGFib3ZlIHdoaWNoIHRoZSBuZXR3b3JrDQogICBtYXkgc2hvdyB1bnN0YWJsZSBiZWhhdmlv ciBjYXVzZWQgYnkgbGFyZ2UgbnVtYmVyIG9mIA0KICAgcmV0cmFuc21pc3Npb25zLCBsaW5rIGZh aWx1cmVzIGR1ZSB0byBtaXNzZWQgSGVsbG8gcGFja2V0cyBhbmQNCiAgIHN1YnNlcXVlbnQgbGlu ayByZWNvdmVyaWVzLiAgVXNpbmcgYSBzaW11bGF0aW9uIHN0dWR5IHdlIHNob3cgdGhhdA0KICAg dGhlIExTQSBzdG9ybSBzaXplIGNhdXNpbmcgaW5zdGFiaWxpdHkgbWF5IGJlIHN1YnN0YW50aWFs bHkNCiAgIGluY3JlYXNlZCBieSBwcm92aWRpbmcgcHJpb3JpdGl6ZWQgdHJlYXRtZW50IHRvIEhl bGxvIGFuZCBMU0EgDQogICBBY2tub3dsZWRnbWVudCBwYWNrZXRzLiAgRnVydGhlcm1vcmUsIGlm IHdlIHByaW9yaXRpemUgSGVsbG8gDQogICBwYWNrZXRzIHRoZW4gZXZlbiB3aGVuIHRoZSBuZXR3 b3JrIG9wZXJhdGVzIHNvbWV3aGF0IGFib3ZlIHRoZSANCiAgIHN0YWJpbGl0eSB0aHJlc2hvbGQs IGxpbmtzIGFyZSBub3QgZGVjbGFyZWQgZG93biBkdWUgdG8gbWlzc2VkIA0KICAgSGVsbG9zLiAg VGhpcyBpbXBsaWVzIHRoYXQgZXZlbiB0aG91Z2ggdGhlcmUgaXMgDQogICBjb250cm9sIHBsYW5l IGNvbmdlc3Rpb24gZHVlIHRvIG1hbnkgcmV0cmFuc21pc3Npb25zLCB0aGUgZGF0YSBwbGFuZQ0K ICAgc3RheXMgdXAgYW5kIG5vIG5ldyBMU0FzIGFyZSBnZW5lcmF0ZWQgKGJlc2lkZXMgdGhlIG9u ZXMgaW4gdGhlIA0KICAgb3JpZ2luYWwgc3Rvcm0gYW5kIHRoZSByZWZyZXNoZXMpLg0KDQogICBC YXNlZCBvbiB0aGUgYWJvdmUgb2JzZXJ2YXRpb25zIHdlIHByb3Bvc2UgdGhlIGZvbGxvd2luZzoN Cg0KICAgKDEpIFByb2Nlc3MgdGhlIEhlbGxvIHBhY2tldHMgYXQgYSBoaWdoZXIgcHJpb3JpdHkg Y29tcGFyZWQgdG8gb3RoZXINCiAgICAgICBPU1BGIHBhY2tldHMuICBJbiBvcmRlciB0byBmYWNp bGl0YXRlIHRoaXMsIGV4cGxpY2l0bHkgbWFyayB0aGUgDQogICAgICAgSGVsbG8gcGFja2V0cywg dG8gZGlmZmVyZW50aWF0ZSB0aGVtIGZyb20gb3RoZXIgT1NQRiBwYWNrZXRzLg0KICAgICAgIE9u ZSB3YXkgb2Ygc3BlY2lhbCBtYXJraW5nIGlzIHRvIHVzZSBhIGRpZmZlcmVudCBEaWZmc2VydiAN CiAgICAgICBjb2RlcG9pbnQgZm9yIEhlbGxvIHBhY2tldHMgY29tcGFyZWQgdG8gb3RoZXIgT1NQ RiBwYWNrZXRzLg0KICAgICAgIA0KICAgKDIpIEluIHRoZSBhYnNlbmNlIG9mIHNwZWNpYWwgbWFy a2luZywgb3IgaW4gYWRkaXRpb24gdG8gaXQsIHVzZSANCiAgICAgICBvdGhlciBtZWNoYW5pc21z IGluIG9yZGVyIG5vdCB0byBtaXNzIEhlbGxvIHBhY2tldHMuIE9uZSBleGFtcGxlDQogICAgICAg aXMgdG8gdHJlYXQgYW55IHBhY2tldCByZWNlaXZlZCBvdmVyIGEgbGluayBhcyBhIHN1cnJvZ2F0 ZSBmb3INCiAgICAgICBhIEhlbGxvIHBhY2tldCAoYW4gaW1wbGljaXQgSGVsbG8pIGZvciB0aGUg cHVycG9zZSBvZiBrZWVwaW5nIA0KICAgICAgIHRoZSBsaW5rIGFsaXZlLiAgT3VyIHNpbXVsYXRp b24gc3R1ZHkgc2hvd3MgdGhhdCB0aGlzIG1lY2hhbmlzbQ0KICAgICAgIGlzIGp1c3QgYXMgZWZm ZWN0aXZlIGFzIGV4cGxpY2l0bHkgcHJpb3JpdGl6aW5nIEhlbGxvDQogICAgICAgcGFja2V0cy4N Cg0KICAgKDMpIFRoZSBzYW1lIHR5cGUgb2YgZXhwbGljaXQgbWFya2luZyBhbmQgcHJpb3JpdGl6 ZWQgdHJlYXRtZW50IG1heQ0KICAgICAgIGJlIGJlbmVmaWNpYWwgdG8gb3RoZXIgT1NQRiBwYWNr ZXRzIGFzIHdlbGwuICBPbmUgaW1wb3J0YW50IA0KICAgICAgIGV4YW1wbGUgaXMgTFNBIGFja25v d2xlZGdtZW50IHBhY2tldCB0aGF0IGNhbiByZWR1Y2UgDQogICAgICAgcmV0cmFuc21pc3Npb25z IGR1cmluZyBwZXJpb2RzIG9mIGNvbmdlc3Rpb24uICBPdXIgc2ltdWxhdGlvbg0KDQogICAgICAg ICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMTNdDQoMDQogICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICBFeHBsaWNp dCBNYXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQogICAgICAgc3R1ZHkgc2hv d3MgdGhhdCBwcmlvcml0aXphdGlvbiBvZiBib3RoIEhlbGxvIGFuZCBMU0ENCiAgICAgICBBY2tu b3dsZWRnbWVudCBwYWNrZXRzIGlzIGNvbnNpZGVyYWJseSBtb3JlIGVmZmVjdGl2ZSB0aGFuDQog ICAgICAganVzdCBwcmlvcml0aXppbmcgSGVsbG8gcGFja2V0cy4gIE90aGVyIGV4YW1wbGVzIA0K ICAgICAgIGluY2x1ZGUgKGEpIERhdGFiYXNlIGRlc2NyaXB0aW9uIChEQkQpIHBhY2tldCBmcm9t IGEgc2xhdmUgdGhhdCANCiAgICAgICBpcyB1c2VkIGFzIGFuIGFja25vd2xlZGdlbWVudCwgYW5k IChiKSBMU0FzIGNhcnJ5aW5nIGludHJhLWFyZWEgDQogICAgICAgdG9wb2xvZ3kgY2hhbmdlIGlu Zm9ybWF0aW9uLg0KDQogICBJdCBpcyBwb3NzaWJsZSB0aGF0IHNvbWUgaW1wbGVtZW50YXRpb25z IGFyZSBhbHJlYWR5IHVzaW5nIG9uZSBvcg0KICAgbW9yZSBvZiB0aGUgYWJvdmUgbWVjaGFuaXNt cyBpbiBvcmRlciBub3QgdG8gbWlzcyB0aGUgcHJvY2Vzc2luZyBvZg0KICAgY3JpdGljYWwgcGFj a2V0cyBkdXJpbmcgcGVyaW9kcyBvZiBjb25nZXN0aW9uLiAgSG93ZXZlciwgd2Ugc3VnZ2VzdA0K ICAgdGhlIGFib3ZlIG1lY2hhbmlzbXMgdG8gYmUgaW5jbHVkZWQgYXMgcGFydCBvZiB0aGUgc3Rh bmRhcmQgc28gdGhhdA0KICAgYWxsIGltcGxlbWVudGF0aW9ucyBjYW4gYmVuZWZpdCBmcm9tIHRo ZW0uDQoNCg0KNy4gQWNrbm93bGVkZ21lbnRzDQoNCiAgIFdlIHdvdWxkIGxpa2UgdG8gYWNrbm93 bGVkZ2UgSmVycnkgQXNoLCBNYXJnYXJldCBDaGlvc2ksIEVsaWUgDQogICBGcmFuY2lzLCBKZWZm IEhhbiwgQmV0aCBNdW5zb24sIFJvc2hhbiBSYW8sIE1vc2hlIFNlZ2FsLCBNaWtlDQogICBXYXJk bG93LCBhbmQgUGF0IFdpcnRoIGZvciBjb2xsYWJvcmF0aW9uIGFuZCBlbmNvdXJhZ2VtZW50IGlu IA0KICAgb3VyIHNjYWxhYmlsaXR5IGltcHJvdmVtZW50IGVmZm9ydHMgZm9yIExpbmstU3RhdGUt UHJvdG9jb2wgYmFzZWQgDQogICBuZXR3b3Jrcy4gDQoNCg0KOC4gUmVmZXJlbmNlcw0KDQoNCiAg IFtSZWYxXSBQYXBwYWxhcmRvLCBELiwgIkFUJlQsIGN1c3RvbWVycyBncmFwcGxlIHdpdGggQVRN IG5ldCANCiAgIG91dGFnZSwiIE5ldHdvcmsgV29ybGQsIEZlYnJ1YXJ5IDI2LCAyMDAxLg0KDQog ICBbUmVmMl0gIkFUJlQgYW5ub3VuY2VzIGNhdXNlIG9mIGZyYW1lLXJlbGF5IG5ldHdvcmsgb3V0 YWdlLCIgQVQmVCANCiAgIFByZXNzIFJlbGVhc2UsIEFwcmlsIDIyLCAxOTk4Lg0KDQogICBbUmVm M10gQ2hvbGV3a2EsIEsuLCAiTUNJIE91dGFnZSBIYXMgRG9taW5vIEVmZmVjdCwiIEludGVyQGN0 aXZlIA0KICAgV2VlaywgQXVndXN0IDIwLCAxOTk5Lg0KDQogICBbUmVmNF0gSmFuZGVyLCBNLiwg IkluIFF3ZXN0IE91dGFnZSwgQVRNIFRha2VzIFNvbWUgSGVhdCwiIExpZ2h0DQogICBSZWFkaW5n LCBBcHJpbCA2LCAyMDAxLg0KDQogICBbUmVmNV0gQy4gQWxhZXR0aW5vZ2x1LCBWLiBKYWNvYnNv biBhbmQgSC4gWXUsICJUb3dhcmRzIE1pbGxpLQ0KICAgc2Vjb25kIElHUCBDb252ZXJnZW5jZSwi IFdvcmsgaW4gUHJvZ3Jlc3MuDQoNCiAgIFtSZWY2XSBBLiBaaW5pbiBhbmQgTS4gU2hhbmQsICJG bG9vZGluZyBPcHRpbWl6YXRpb25zIGluIExpbmstU3RhdGUNCiAgIFJvdXRpbmcgUHJvdG9jb2xz LCIgV29yayBpbiBQcm9ncmVzcy4NCg0KICAgW1JlZjddIEouIE1veSwgIkZsb29kaW5nIG92ZXIg UGFyYWxsZWwgUG9pbnQtdG8tUG9pbnQgTGlua3MsIiBXb3JrIGluDQogICBwcm9ncmVzcy4NCg0K ICAgW1JlZjhdIFAuIFBpbGxheS1Fc25hdWx0LCAiT1NQRiBSZWZyZXNoIGFuZCBmbG9vZGluZyBy ZWR1Y3Rpb24gaW4gIA0KDQogICAgICAgICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQogICBJbnRlcm5l dCBEcmFmdCAgICAgICAgICBFeHBsaWNpdCBNYXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIw MDMNCg0KDQogICBzdGFibGUgdG9wb2xvZ2llcywiIFdvcmsgaW4gcHJvZ3Jlc3MuDQoNCiAgIFtS ZWY5XSBHLiBDaG91ZGh1cnksIFYuIE1hbnJhbCwgIkxTQSBGbG9vZGluZyBPcHRpbWl6YXRpb24N CiAgIEFsZ29yaXRobXMgYW5kIFRoZWlyIFNpbXVsYXRpb24gU3R1ZHksIiBXb3JrIGluIHByb2dy ZXNzLg0KDQogICBbUmVmMTBdIEouIEFzaCwgRy4gQ2hvdWRodXJ5LCBWLiBTYXBvemhuaWtvdmEs IE0uIFNoZXJpZiwgQS4gIA0KICAgTWF1bmRlciwgVi4gTWFucmFsLCAiQ29uZ2VzdGlvbiBBdm9p ZGFuY2UgJiBDb250cm9sIGZvciBPU1BGIA0KICAgTmV0d29ya3MiLCBXb3JrIGluIFByb2dyZXNz Lg0KDQogICBbUmVmMTFdIEIuIE0uIFdheG1hbiwgIlJvdXRpbmcgb2YgTXVsdGlwb2ludCBDb25u ZWN0aW9ucywiIElFRUUNCiAgIEpvdXJuYWwgb24gU2VsZWN0ZWQgQXJlYXMgaW4gQ29tbXVuaWNh dGlvbnMsIDYoOSk6MTYxNy0xNjIyLCAxOTg4Lg0KDQogICANCjkuIEF1dGhvcnMnIEFkZHJlc3Nl cw0KDQogICBHYWdhbiBMLiBDaG91ZGh1cnkNCiAgIEFUJlQNCiAgIFJvb20gRDUtM0MyMQ0KICAg MjAwIExhdXJlbCBBdmVudWUNCiAgIE1pZGRsZXRvd24sIE5KLCAwNzc0OA0KICAgVVNBDQogICBQ aG9uZTogKDczMik0MjAtMzcyMQ0KICAgZW1haWw6IGdjaG91ZGh1cnlAYXR0LmNvbQ0KDQoNCiAg IFZlcmEgRC4gU2Fwb3pobmlrb3ZhDQogICBBVCZUDQogICBSb29tIEM1LTJDMjkNCiAgIDIwMCBM YXVyZWwgQXZlbnVlDQogICBNaWRkbGV0b3duLCBOSiwgMDc3NDgNCiAgIFVTQQ0KICAgUGhvbmU6 ICg3MzIpNDIwLTI2NTMNCiAgIGVtYWlsOiBzYXBvemhuaWtvdmFAYXR0LmNvbQ0KDQoNCiAgIEFu dXJhZyBTLiBNYXVuZGVyDQogICBTYW5lcmEgU3lzdGVtcw0KICAgMzcwIFNhbiBBbGVzbyBBdmUu DQogICBTZWNvbmQgRmxvb3INCiAgIFN1bm55dmFsZSwgQ0EgOTQwODUNCiAgIFBob25lOiAoNDA4 KTczNC02MTIzDQogICBlbWFpbDogYW1hdW5kZXJAc2FuZXJhLm5ldA0KDQogICBWaXNod2FzIE1h bnJhbA0KICAgTmV0UGxhbmUNCiAgIDE4OSwgUHJhc2hhc2FuIE5hZ2FyLA0KICAgUm9hZCBOdW1i ZXIgNzINCiAgIEp1YmlsZWUgSGlsbHMsIEh5ZGVyYWJhZA0KICAgSW5kaWENCiAgIGVtYWlsOiBW aXNod2FzbUBuZXRwbGFuZS5jb20NCg0KICAgQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0K ------_=_NextPart_001_01C284DE.BA6BE9C2-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 10:46:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24995 for ; Tue, 5 Nov 2002 10:46:26 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.007ACA7E@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 10:48:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 319322 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 10:48:54 -0500 Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 10:48:53 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA5EuREo002296 for ; Tue, 5 Nov 2002 10:48:53 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B560500EFCC2B for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 10:48:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C284E2.D72B5A6B" X-MS-Has-Attach: yes Thread-Topic: Atlanta IETF OSPF WG Agenda Thread-Index: AcKEmUwNekCef23qTtqYqYXOdThtQQAQ8OeAAADjm8A= Message-ID: <28F05913385EAC43AF019413F674A017023F6840@OCCLUST04EVS1.ugd.att.com> Date: Tue, 5 Nov 2002 10:48:52 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALASO" Subject: Resend: Version 2 of OSPF Scalability Draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C284E2.D72B5A6B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry for the resend. It appears that the attachment did not go through = in my last email. Gagan Hi Everybody, Here is version 2 of "draft-ietf-ospf-scalability-02.txt" which has = been submitted=20 but will take a few days to appear at the IETF Web-site. It has new = simulation=20 results to quantitatively show how much scalability improvement can be = achieved by=20 prioritizing Hello and/or LSA Acknowledgment packets under various = scenarios. Please=20 give your comments electronically or at the Atlanta Meeting. Thanks, Gagan Title: Explicit Marking and Prioritized Treatment of Specific OSPF = Packets for Faster Convergence and Improved Network Scalability and Stability ------_=_NextPart_001_01C284E2.D72B5A6B Content-Type: text/plain; name="draft-ietf-ospf-scalability-02.txt" Content-Description: draft-ietf-ospf-scalability-02.txt Content-Disposition: attachment; filename="draft-ietf-ospf-scalability-02.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQogICBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAg ICBHYWdhbiBMLiBDaG91ZGh1cnkNCiAgIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFZlcmEgRC4gU2Fwb3pobmlrb3ZhDQogICBFeHBpcmVzIGluIE1heSwg MjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICBBVCZUDQogICBkcmFmdC1pZXRmLW9zcGYt c2NhbGFiaWxpdHktMDIudHh0ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBbnVyYWcgUy4gTWF1bmRlcg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2FuZXJhIFN5c3RlbXMNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVmlzaHdhcyBN YW5yYWwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE5ldHBsYW5lIFN5c3RlbXMNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTm92ZW1iZXIsIDIwMDINCg0KDQogICAgRXhwbGljaXQgTWFya2luZyBh bmQgUHJpb3JpdGl6ZWQgVHJlYXRtZW50IG9mIFNwZWNpZmljIE9TUEYgUGFja2V0cw0KICAgICAg Zm9yIEZhc3RlciBDb252ZXJnZW5jZSBhbmQgSW1wcm92ZWQgTmV0d29yayBTY2FsYWJpbGl0eSBh bmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0YWJpbGl0eQ0KDQoNClN0YXR1 cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBh bmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZQ0KICAgd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0 aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwg aXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBn cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0N CiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXgNCiAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzDQogICBhdCBhbnkgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcw0KICAgcmVmZXJl bmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dy ZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj Y2Vzc2VkIGF0DQogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3Rz LnR4dA0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNh biBiZSBhY2Nlc3NlZCBhdA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s Lg0KICAgRGlzdHJpYnV0aW9uIG9mIHRoaXMgbWVtbyBpcyB1bmxpbWl0ZWQuDQoNCg0KQWJzdHJh Y3QNCg0KICAgSW4gdGhpcyBkcmFmdCB3ZSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgbWVjaGFuaXNt cyB0byBpbXByb3ZlIA0KICAgdGhlIHNjYWxhYmlsaXR5IGFuZCBzdGFiaWxpdHkgb2YgT1NQRi1i YXNlZCBuZXR3b3JrOg0KDQogICAoMSkgUHJvY2VzcyB0aGUgSGVsbG8gcGFja2V0cyBhdCBhIGhp Z2hlciBwcmlvcml0eSBjb21wYXJlZCB0byBvdGhlcg0KICAgICAgIE9TUEYgcGFja2V0cy4gIElu IG9yZGVyIHRvIGZhY2lsaXRhdGUgdGhpcywgZXhwbGljaXRseSBtYXJrIHRoZSANCiAgICAgICBI ZWxsbyBwYWNrZXRzLCB0byBkaWZmZXJlbnRpYXRlIHRoZW0gZnJvbSBvdGhlciBPU1BGIHBhY2tl dHMuDQogICAgICAgT25lIHdheSBvZiBzcGVjaWFsIG1hcmtpbmcgaXMgdG8gdXNlIGEgZGlmZmVy ZW50IERpZmZzZXJ2IA0KDQogICAgICAgICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCiAgIEludGVybmV0 IERyYWZ0ICAgICAgICAgIEV4cGxpY2l0IE1hcmtpbmcgICAgICAgICAgICAgICAgIE1heSwgMjAw Mw0KDQoNCiAgICAgICBjb2RlcG9pbnQgZm9yIEhlbGxvIHBhY2tldHMgY29tcGFyZWQgdG8gb3Ro ZXIgT1NQRiBwYWNrZXRzLg0KDQogICAoMikgSW4gdGhlIGFic2VuY2Ugb2Ygc3BlY2lhbCBtYXJr aW5nLCBvciBpbiBhZGRpdGlvbiB0byBpdCwgdXNlIA0KICAgICAgIG90aGVyIG1lY2hhbmlzbXMg aW4gb3JkZXIgbm90IHRvIG1pc3MgSGVsbG8gcGFja2V0cy4gT25lIGV4YW1wbGUNCiAgICAgICBp cyB0byB0cmVhdCBhbnkgcGFja2V0IHJlY2VpdmVkIG92ZXIgYSBsaW5rIGFzIGEgc3Vycm9nYXRl IGZvcg0KICAgICAgIGEgSGVsbG8gcGFja2V0IChhbiBpbXBsaWNpdCBIZWxsbykgZm9yIHRoZSBw dXJwb3NlIG9mIGtlZXBpbmcgDQogICAgICAgdGhlIGxpbmsgYWxpdmUuDQoNCiAgICgzKSBUaGUg c2FtZSB0eXBlIG9mIGV4cGxpY2l0IG1hcmtpbmcgYW5kIHByaW9yaXRpemVkIHRyZWF0bWVudCBt YXkNCiAgICAgICBiZSBiZW5lZmljaWFsIHRvIG90aGVyIE9TUEYgcGFja2V0cyBhcyB3ZWxsLiAg T25lIGltcG9ydGFudCANCiAgICAgICBleGFtcGxlIGlzIExTQSBhY2tub3dsZWRnbWVudCBwYWNr ZXQgdGhhdCBjYW4gcmVkdWNlIA0KICAgICAgIHJldHJhbnNtaXNzaW9ucyBkdXJpbmcgcGVyaW9k cyBvZiBjb25nZXN0aW9uLiAgT3RoZXIgZXhhbXBsZXMgDQogICAgICAgaW5jbHVkZSAoYSkgRGF0 YWJhc2UgZGVzY3JpcHRpb24gKERCRCkgcGFja2V0IGZyb20gYSBzbGF2ZSB0aGF0IA0KICAgICAg IGlzIHVzZWQgYXMgYW4gYWNrbm93bGVkZ2VtZW50LCBhbmQgKGIpIExTQXMgY2FycnlpbmcgaW50 cmEtYXJlYSANCiAgICAgICB0b3BvbG9neSBjaGFuZ2UgaW5mb3JtYXRpb24uDQogICANCiAgIEl0 IGlzIHBvc3NpYmxlIHRoYXQgc29tZSBpbXBsZW1lbnRhdGlvbnMgYXJlIGFscmVhZHkgdXNpbmcg b25lIG9yDQogICBtb3JlIG9mIHRoZSBhYm92ZSBtZWNoYW5pc21zIGluIG9yZGVyIG5vdCB0byBt aXNzIHRoZSBwcm9jZXNzaW5nIG9mDQogICBjcml0aWNhbCBwYWNrZXRzIGR1cmluZyBwZXJpb2Rz IG9mIGNvbmdlc3Rpb24uICBIb3dldmVyLCB3ZSBzdWdnZXN0DQogICB0aGUgYWJvdmUgbWVjaGFu aXNtcyB0byBiZSBpbmNsdWRlZCBhcyBwYXJ0IG9mIHRoZSBzdGFuZGFyZCBzbyB0aGF0DQogICBh bGwgaW1wbGVtZW50YXRpb25zIGNhbiBiZW5lZml0IGZyb20gdGhlbS4NCg0KDQpUYWJsZSBvZiBD b250ZW50cw0KDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yDQogICAyLiBUaGUgTmV0d29yayBVbmRlciBTaW11bGF0 aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICAzLiBTaW11bGF0aW9u IFJlc3VsdHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43DQog ICA0LiBPYnNlcnZhdGlvbnMgb24gU2ltdWxhdGlvbiBSZXN1bHRzIC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjExDQogICA1LiBOZWVkIGZvciBQcmlvcml0aXplZCBUcmVhdG1lbnQgb2YgQ3Jp dGljYWwgT1NQRiBQYWNrZXRzIGFuZCANCiAgICAgIFNwZWNpYWwgTWFya2luZyB0byBGYWNpbGl0 YXRlIFRoYXQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTINCiAgIDYuIFN1bW1hcnkuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMNCiAg IDcuIEFja25vd2xlZGdtZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTQNCiAgIDguIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQNCiAgIDkuIEF1dGhvcnMnIEFkZHJlc3Nlcy4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUNCg0KDQoxLiBJbnRyb2R1 Y3Rpb24NCg0KICAgRHVlIHRvIHdvcmxkLXdpZGUgaW5jcmVhc2VkIHRyYWZmaWMgZGVtYW5kLCBk YXRhIG5ldHdvcmtzIGFyZSBldmVyIA0KICAgaW5jcmVhc2luZyBpbiBzaXplIGluIHRlcm1zIG9m IG51bWJlciBvZiBub2RlcywgbnVtYmVyIG9mIGxpbmtzLA0KICAgYWRqYWNlbmNpZXMgcGVyIG5v ZGUgYW5kIExpbmsgU3RhdGUgRGF0YWJhc2Ugc2l6ZS4gIE91ciBtb3RpdmF0aW9uDQogICBpcyB0 byBpbXByb3ZlIHRoZSBhYmlsaXR5IG9mIGxhcmdlIG5ldHdvcmtzIHRvIHdpdGhzdGFuZA0KICAg dGhlIHNpbXVsdGFuZW91cyBvciBuZWFyLXNpbXVsdGFuZW91cyB1cGRhdGUgb2YgYSBsYXJnZSBu dW1iZXIgb2YNCiAgIGxpbmstc3RhdGUtYWR2ZXJ0aXNlbWVudCBtZXNzYWdlcywgb3IgTFNBcy4g IFdlIGNhbGwgdGhpcyBldmVudCwgYW4NCiAgIExTQSBzdG9ybS4gIEFuIExTQSBzdG9ybSBtYXkg YmUgaW5pdGlhdGVkIGR1ZSB0byBtYW55IHJlYXNvbnMuICBIZXJlDQogICBhcmUgc29tZSBleGFt cGxlczogIA0KDQogICAoYSkgb25lIG9yIG1vcmUgbGluayBmYWlsdXJlcyBkdWUgdG8gZmliZXIg Y3V0cywNCg0KICAgICAgICAgIA0KICAgQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQogICBJbnRlcm5ldCBEcmFmdCAg ICAgICAgICBFeHBsaWNpdCBNYXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQog ICAoYikgb25lIG9yIG1vcmUgbm9kZSBmYWlsdXJlcyBmb3Igc29tZSByZWFzb24sIGUuZy4sIHNv ZnR3YXJlDQogICAgICAgY3Jhc2ggb3Igc29tZSB0eXBlIG9mIGRpc2FzdGVyIGluIGFuIG9mZmlj ZSBjb21wbGV4IGhvc3RpbmcgDQogICAgICAgbWFueSBub2RlcywNCg0KICAgKGMpIHJlcXVpcmVt ZW50IG9mIHRha2luZyBkb3duIGFuZCBsYXRlciBicmluZ2luZyBiYWNrIG1hbnkgDQogICAgICAg bm9kZXMgZHVyaW5nIGEgc29mdHdhcmUvaGFyZHdhcmUgdXBncmFkZSwgDQoNCiAgIChkKSBuZWFy LXN5bmNocm9uaXphdGlvbiBvZiB0aGUgb25jZS1pbi0zMC1taW51dGVzIHJlZnJlc2ggaW5zdGFu dHMNCiAgICAgICBvZiBzb21lIHR5cGVzIG9mIExTQXMsIA0KDQogICAoZSkgcmVmcmVzaCBvZiBh bGwgTFNBcyBpbiB0aGUgc3lzdGVtIGR1cmluZyBhIGNoYW5nZSBpbiBzb2Z0d2FyZSANCiAgICAg ICB2ZXJzaW9uLiAgDQoNCiAgIEluIGFkZGl0aW9uIHRvIHRoZSBMU0FzIGdlbmVyYXRlZCBhcyBh IGRpcmVjdCByZXN1bHQgb2YgbGluay9ub2RlIA0KICAgZmFpbHVyZXMsIHRoZXJlIG1heSBiZSBv dGhlciBpbmRpcmVjdCBMU0FzIGFzIHdlbGwuICBPbmUgZXhhbXBsZSANCiAgIGluIE1QTFMgbmV0 d29ya3MgaXMgdHJhZmZpYyBlbmdpbmVlcmluZyBMU0FzIGdlbmVyYXRlZCBhdCBvdGhlciANCiAg IGxpbmtzIGFzIGEgcmVzdWx0IG9mIHNpZ25pZmljYW50IGNoYW5nZSBpbiByZXNlcnZlZCBiYW5k d2lkdGggDQogICByZXN1bHRpbmcgZnJvbSByZXJvdXRpbmcgb2YgTGFiZWwgU3dpdGNoZWQgUGF0 aHMgKExTUHMpIHRoYXQgd2VudCANCiAgIGRvd24gZHVyaW5nIHRoZSBsaW5rL25vZGUgZmFpbHVy ZS4NCiANCiAgIFRoZSBMU0Egc3Rvcm0gY2F1c2VzIGhpZ2ggQ1BVIGFuZCBtZW1vcnkgdXRpbGl6 YXRpb24gYXQgdGhlIG5vZGUNCiAgIHByb2Nlc3NvcnMgY2F1c2luZyBpbmNvbWluZyBwYWNrZXRz IHRvIGJlIGRlbGF5ZWQgb3IgZHJvcHBlZC4gIA0KICAgRGVsYXllZCBhY2tub3dsZWRnZW1lbnRz IChiZXlvbmQgdGhlIHJldHJhbnNtaXNzaW9uIHRpbWVyIHZhbHVlKSANCiAgIHJlc3VsdHMgaW4g cmV0cmFuc21pc3Npb25zLCBhbmQgZGVsYXllZCBIZWxsbyBwYWNrZXRzIChiZXlvbmQgdGhlIA0K ICAgUm91dGVyLURlYWQgaW50ZXJ2YWwpIHJlc3VsdHMgaW4gbGlua3MgYmVpbmcgZGVjbGFyZWQg ZG93bi4gIEENCiAgIHRydW5rLWRvd24gZXZlbnQgY2F1c2VzIFJvdXRlciBMU0EgZ2VuZXJhdGlv biBieSBpdHMgZW5kLXBvaW50DQogICBub2Rlcy4gIElmIHRyYWZmaWMgZW5naW5lZXJpbmcgTFNB cyBhcmUgdXNlZCBmb3IgZWFjaCBsaW5rIHRoZW4NCiAgIHRoYXQgdHlwZSBvZiBMU0FzIHdvdWxk IGFsc28gYmUgZ2VuZXJhdGVkIGJ5IHRoZSBlbmQtcG9pbnQgbm9kZXMNCiAgIGFuZCBwb3RlbnRp YWxseSBlbHNld2hlcmUgYXMgd2VsbCBkdWUgdG8gc2lnbmlmaWNhbnQgY2hhbmdlcyBpbg0KICAg cmVzZXJ2ZWQgYmFuZHdpZHRocyBhdCBvdGhlciBsaW5rcyBjYXVzZWQgYnkgdGhlIGZhaWx1cmUg YW5kIHJlcm91dGUNCiAgIG9mIExTUHMgb3JpZ2luYWxseSB1c2luZyB0aGUgZmFpbGVkIHRydW5r LiAgRXZlbnR1YWxseSwgd2hlbiB0aGUNCiAgIGxpbmsgcmVjb3ZlcnMgdGhhdCB3b3VsZCBhbHNv IHRyaWdnZXIgYWRkaXRpb25hbCBSb3V0ZXIgYW5kIHRyYWZmaWMNCiAgIGVuZ2luZWVyaW5nIExT QXMuDQoNCiAgIFRoZSByZXRyYW5zbWlzc2lvbnMgYW5kIGFkZGl0aW9uYWwgTFNBIGdlbmVyYXRp b25zIHJlc3VsdCBpbiBmdXJ0aGVyIA0KICAgQ1BVIGFuZCBtZW1vcnkgdXNhZ2UsIGVzc2VudGlh bGx5IGNhdXNpbmcgYSBwb3NpdGl2ZSBmZWVkYmFjayBsb29wLiAgDQogICBXZSBkZWZpbmUgdGhl IExTQSBzdG9ybSBzaXplIGFzIHRoZSBudW1iZXIgb2YgTFNBcyBpbiB0aGUgb3JpZ2luYWwgDQog ICBzdG9ybSBhbmQgbm90IGNvdW50aW5nIGFueSBhZGRpdGlvbmFsIExTQXMgcmVzdWx0aW5nIGZy b20gdGhlICANCiAgIGZlZWRiYWNrIGxvb3AgZGVzY3JpYmVkIGFib3ZlLiAgSWYgdGhlIExTQSBz dG9ybSBpcyB0b28gbGFyZ2UgdGhlbg0KICAgdGhlIHBvc2l0aXZlIGZlZWRiYWNrIGxvb3AgbWVu dGlvbmVkIGFib3ZlIG1heSBiZSBsYXJnZSBlbm91Z2ggdG8gDQogICBpbmRlZmluaXRlbHkgc3Vz dGFpbiBhIGxhcmdlIENQVSBhbmQgbWVtb3J5IHV0aWxpemF0aW9uIGF0IG1hbnkgDQogICBuZXR3 b3JrIG5vZGVzLCB0aGVyZWJ5IGRyaXZpbmcgdGhlIG5ldHdvcmsgdG8gYW4gdW5zdGFibGUgc3Rh dGUuDQoNCiAgIEluIHRoZSBwYXN0LCBuZXR3b3JrDQogICBvdXRhZ2UgZXZlbnRzIGhhdmUgYmVl biByZXBvcnRlZCBpbiBJUCBhbmQgQVRNIG5ldHdvcmtzIHVzaW5nIA0KICAgbGluay1zdGF0ZSBw cm90b2NvbHMgc3VjaCBhcyBPU1BGLCBJUy1JUywgUE5OSSBvciBzb21lIHByb3ByaWV0YXJ5IA0K ICAgdmFyaWFudHMuICBTZWUsIGZvciBleGFtcGxlIFtSZWYxLVJlZjRdLiAgSW4gbWFueSBvZiB0 aGVzZSBleGFtcGxlcywNCiAgIGxhcmdlIHNjYWxlIGZsb29kaW5nIG9mIExTQXMgb3Igb3RoZXIg c2ltaWxhciBjb250cm9sIG1lc3NhZ2VzIA0KICAgKGVpdGhlciBuYXR1cmFsbHkgb3IgdHJpZ2dl cmVkIGJ5IHNvbWUgYnVnIG9yIGluYXBwcm9wcmlhdGUgDQoNCiAgICAgICAgICANCiAgIENob3Vk aHVyeSBldC4gYWwuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSAzXQ0KDA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgRXhwbGljaXQgTWFya2luZyAgICAg ICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0KICAgcHJvY2VkdXJlKSBoYXZlIGJlZW4gcGFydGx5 IG9yIGZ1bGx5IHJlc3BvbnNpYmxlIGZvciBuZXR3b3JrIA0KICAgaW5zdGFiaWxpdHkgYW5kIG91 dGFnZS4gDQ0KDQogICBJdCBoYXMgYmVlbiBzdWdnZXN0ZWQgW1JlZjVdIHRvIHJlZHVjZSB0aGUg SGVsbG8gaW50ZXJ2YWwgYW5kDQogICBSb3V0ZXItRGVhZCBpbnRlcnZhbCBzaWduaWZpY2FudGx5 IGluIG9yZGVyIGZvciBPU1BGIHRvIGRldGVjdA0KICAgbGluayBmYWlsdXJlcyBhbmQgcmVjb3Zl cmllcyBmYXN0ZXIuIFJlZHVjdGlvbiBvZiBSb3V0ZXItRGVhZA0KICAgaW50ZXJ2YWwgd291bGQg bWFrZSBpdCBldmVuIG1vcmUgbGlrZWx5IGZvciBsaW5rcyB0byBiZSBkZWNsYXJlZCBkb3duDQog ICBkdWUgdG8gbWlzc2VkIEhlbGxvcy4NCg0KICAgV2UgdXNlIGEgc2ltdWxhdGlvbiBtb2RlbCB0 byBzaG93IHRoYXQgdGhlcmUgaXMgYSBjZXJ0YWluIExTQSBzdG9ybQ0KICAgc2l6ZSB0aHJlc2hv bGQgYWJvdmUgd2hpY2ggdGhlIG5ldHdvcmsgbWF5IHNob3cgdW5zdGFibGUgYmVoYXZpb3IgDQog ICBjYXVzZWQgYnkgbGFyZ2UgbnVtYmVyIG9mIHJldHJhbnNtaXNzaW9ucywgbGluayBmYWlsdXJl cyBkdWUgdG8gDQogICBtaXNzZWQgSGVsbG8gcGFja2V0cyBhbmQgc3Vic2VxdWVudCBsaW5rIHJl Y292ZXJpZXMuICBXZSBhbHNvIHNob3cNCiAgIHRoYXQgdGhlIExTQSBzdG9ybSBzaXplIGNhdXNp bmcgaW5zdGFiaWxpdHkgbWF5IGJlIHN1YnN0YW50aWFsbHkNCiAgIGluY3JlYXNlZCBieSBwcm92 aWRpbmcgcHJpb3JpdGl6ZWQgdHJlYXRtZW50IHRvIEhlbGxvIGFuZCBMU0EgDQogICBBY2tub3ds ZWRnbWVudCBwYWNrZXRzLiAgRnVydGhlcm1vcmUsIGlmIHdlIHByaW9yaXRpemUgSGVsbG8gDQog ICBwYWNrZXRzIHRoZW4gZXZlbiB3aGVuIHRoZSBuZXR3b3JrIG9wZXJhdGVzIHNvbWV3aGF0IGFi b3ZlIHRoZSANCiAgIHN0YWJpbGl0eSB0aHJlc2hvbGQsIGxpbmtzIGFyZSBub3QgZGVjbGFyZWQg ZG93biBkdWUgdG8gbWlzc2VkIA0KICAgSGVsbG9zLiAgVGhpcyBpbXBsaWVzIHRoYXQgZXZlbiB0 aG91Z2ggdGhlcmUgaXMgDQogICBjb250cm9sIHBsYW5lIGNvbmdlc3Rpb24gZHVlIHRvIG1hbnkg cmV0cmFuc21pc3Npb25zLCB0aGUgZGF0YSBwbGFuZQ0KICAgc3RheXMgdXAgYW5kIG5vIG5ldyBM U0FzIGFyZSBnZW5lcmF0ZWQgKGJlc2lkZXMgdGhlIG9uZXMgaW4gdGhlIA0KICAgb3JpZ2luYWwg c3Rvcm0gYW5kIHRoZSByZWZyZXNoZXMpLiAgQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zDQog ICB3ZSBwcm9wb3NlIHByaW9yaXRpemVkIHRyZWF0bWVudCBvZiBIZWxsbywgTFNBIGFja25vd2xl ZGdtZW50DQogICBhbmQgb3RoZXIgY3JpdGljYWwgT1NQRiBwYWNrZXRzIGFuZCBhIHNwZWNpYWwg bWFya2luZyB0byBmYWNpbGl0YXRlDQogICB0aGF0Lg0KDQogICBPbmUgbWlnaHQgYXJndWUgdGhh dCB0aGUgc2NhbGFiaWxpdHkgaXNzdWUgb2YgbGFyZ2UgbmV0d29ya3Mgc2hvdWxkDQogICBiZSBz b2x2ZWQgc29sZWx5IGJ5IGRpdmlkaW5nIHRoZSBuZXR3b3JrIGhpZXJhcmNoaWNhbGx5IGludG8g DQogICBtdWx0aXBsZSBhcmVhcyBzbyB0aGF0IGZsb29kaW5nIG9mIExTQXMgcmVtYWlucyBsb2Nh bGl6ZWQgd2l0aGluIA0KICAgYXJlYXMuICBIb3dldmVyLCB0aGlzIGFwcHJvYWNoIGluY3JlYXNl cyB0aGUgbmV0d29yayBtYW5hZ2VtZW50IA0KICAgYW5kIGRlc2lnbiBjb21wbGV4aXR5IGFuZCBt YXkgcmVzdWx0IGluIGxlc3Mgb3B0aW1hbCByb3V0aW5nIGJldHdlZW4gDQogICBhcmVhcy4gQWxz bywgQVNFIExTQXMgYXJlIGZsb29kZWQgdGhyb3VnaG91dCB0aGUgQVMgYW5kIGl0IG1heSBiZQ0K ICAgYSBwcm9ibGVtIGlmIHRoZXJlIGFyZSBsYXJnZSBudW1iZXJzIG9mIHRoZW0uICBGdXJ0aGVy bW9yZSwgDQogICBhIGxhcmdlIG51bWJlciBvZiBzdW1tYXJ5IExTQXMgbWF5IG5lZWQgdG8gYmUg Zmxvb2RlZCBhY3Jvc3MNCiAgIEFyZWFzIGFuZCB0aGVpciBudW1iZXJzIHdvdWxkIGluY3JlYXNl IHNpZ25pZmljYW50bHkgaWYgDQogICBtdWx0aXBsZSBBcmVhIEJvcmRlciBSb3V0ZXJzIGFyZSBl bXBsb3llZCBmb3IgdGhlIHB1cnBvc2Ugb2YNCiAgIHJlbGlhYmlsaXR5LiBUaHVzIGl0IGlzIGlt cG9ydGFudCB0byBhbGxvdyB0aGUgbmV0d29yayB0byBncm93IA0KICAgdG93YXJkcyBhcyBsYXJn ZSBhIHNpemUgYXMgcG9zc2libGUgdW5kZXIgYSBzaW5nbGUgYXJlYS4gIA0KICAgDQogICBPdXIg cHJvcG9zYWwgaGVyZSBpcyBzeW5lcmdpc3RpYyB3aXRoIGEgYnJvYWRlciBzZXQgb2Ygc2NhbGFi aWxpdHkgDQogICBhbmQgc3RhYmlsaXR5IGltcHJvdmVtZW50IHByb3Bvc2Fscy4gW1JlZjYsIFJl ZjddIHByb3Bvc2VzIGZsb29kaW5nDQogICBvdmVyaGVhZCByZWR1Y3Rpb24gaW4gY2FzZSBtb3Jl IHRoYW4gb25lIGludGVyZmFjZSBnb2VzIHRvIHRoZSBzYW1lDQogICBuZWlnaGJvci4gIFtSZWY4 XSBwcm9wb3NlcyBhIG1lY2hhbmlzbSBmb3IgDQogICBncmVhdGx5IHJlZHVjaW5nIExTQSByZWZy ZXNoZXMgaW4gc3RhYmxlIHRvcG9sb2dpZXMuIFtSZWY5XSBjb21wYXJlcw0KICAgc2V2ZXJhbCBy ZXN0cmljdGVkIGZsb29kaW5nIGFsZ29yaXRobXMgaW4gdGVybXMgb2YgdGhlaXIgYWJpbGl0eSB0 bw0KICAgd2l0aHN0YW5kIGxhcmdlIExTQSBzdG9ybXMgYW5kIHJvYnVzdG5lc3MgdG8gZmFpbHVy ZSBjb25kaXRpb25zLg0KICAgW1JlZjEwXSBwcm9wb3NlcyBhIHdpZGUgcmFuZ2Ugb2YgY29uZ2Vz dGlvbiBjb250cm9sIGFuZCBmYWlsdXJlIA0KICAgcmVjb3ZlcnkgbWVjaGFuaXNtcy4gICANCg0K DQogICAgICAgICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCiAgIEludGVybmV0IERyYWZ0ICAgICAgICAg IEV4cGxpY2l0IE1hcmtpbmcgICAgICAgICAgICAgICAgIE1heSwgMjAwMw0KDQoNCiAgIFNlY3Rp b24gMiBkZXNjcmliZXMgdGhlIG5ldHdvcmsgdW5kZXIgc2ltdWxhdGlvbiBhbmQgU2VjdGlvbiAz DQogICBwcm92aWRlcyB0aGUgc2ltdWxhdGlvbiByZXN1bHRzLiAgU2VjdGlvbiA0IGdpdmVzIHRo ZSBiYXNpYw0KICAgb2JzZXJ2YXRpb25zIGJhc2VkIG9uIHRoZSBzaW11bGF0aW9uIHJlc3VsdHMu ICBTZWN0aW9uIDUgZXhwbGFpbnMNCiAgIHRoZSBuZWVkIGZvciBwcmlvcml0aXplZCB0cmVhdG1l bnQgb2YgY2VydGFpbiBjcml0aWNhbCBPU1BGIHBhY2tldHMgDQogICBhbmQgc3BlY2lhbCBtYXJr aW5nIHRvIGZhY2lsaXRhdGUgdGhhdC4gIFNlY3Rpb24gNiBnaXZlcyB0aGUgc3VtbWFyeS4NCiAg ICAgICAgICANCg0KMi4gVGhlIE5ldHdvcmsgVW5kZXIgU2ltdWxhdGlvbg0KDQogICBXZSBnZW5l cmF0ZSBhIHJhbmRvbSBuZXR3b3JrIG92ZXIgYSByZWN0YW5ndWxhciBncmlkIHVzaW5nIGEgIA0K ICAgbW9kaWZpZWQgdmVyc2lvbiBvZiBXYXhtYW4ncyBhbGdvcml0aG0gW1JlZjExXSB0aGF0IGVu c3VyZXMgdGhhdCANCiAgIHRoZSBuZXR3b3JrIGlzIGNvbm5lY3RlZCBhbmQgaGFzIGEgcHJlLXNw ZWNpZmllZCBudW1iZXIgb2Ygbm9kZXMsIA0KICAgbGlua3MsIG1heGltdW0gbnVtYmVyIG9mIG5l aWdoYm9ycyBwZXIgbm9kZSwgYW5kIG1heGltdW0gbnVtYmVyICANCiAgIG9mIGFkamFjZW5jaWVz IHBlciBub2RlLiBUaGUgcmVjdGFuZ3VsYXIgZ3JpZCByZXNlbWJsZXMgdGhlIA0KICAgY29udGlu ZW50YWwgVS5TLkEuIHdpdGggbWF4aW11bSBvbmUtd2F5IHByb3BhZ2F0aW9uIGRlbGF5IG9mIDMw IG1zIA0KICAgaW4gdGhlIEVhc3QtV2VzdCBkaXJlY3Rpb24gYW5kIG1heGltdW0gb25lLXdheSBw cm9wYWdhdGlvbiBkZWxheSBvZiANCiAgIDE1IG1zIGluIHRoZSBOb3J0aC1Tb3V0aCBkaXJlY3Rp b24uICBXZSBjb25zaWRlciB0d28gZGlmZmVyZW50IA0KICAgbmV0d29yayBzaXplcyBhcyBleHBs YWluZWQgaW4gU2VjdGlvbiAzLg0KDQogICBUaGUgbmV0d29yayBoYXMgYSBmbGF0LCBzaW5nbGUt YXJlYSB0b3BvbG9neS4NCg0KICAgRWFjaCBub2RlIGlzIGEgUm91dGVyIGFuZCBlYWNoIGxpbmsg aXMgYSBwb2ludC10by1wb2ludCBsaW5rIA0KICAgY29ubmVjdGluZyB0d28gcm91dGVycy4NCg0K ICAgV2UgYXNzdW1lIHRoYXQgbm9kZSBDUFUgYW5kIG1lbW9yeSAobm90IHRoZSBsaW5rIGJhbmR3 aWR0aCkgaXMgdGhlIA0KICAgbWFpbiBib3R0bGVuZWNrIGluIHRoZSBMU0EgZmxvb2RpbmcgcHJv Y2Vzcy4gIFRoaXMgd2lsbCB0eXBpY2FsbHkgDQogICBiZSB0cnVlIGZvciBoaWdoIHNwZWVkIGxp bmtzIChlLmcuLCBPQzMgb3IgYWJvdmUpIGFuZC9vciBsaW5rcyANCiAgIHdoZXJlIE9TUEYgdHJh ZmZpYyBnZXRzIGFuIGFkZXF1YXRlIFF1YWxpdHkgb2YgU2VydmljZSAoUW9TKSANCiAgIGNvbXBh cmVkIHRvIG90aGVyIHRyYWZmaWMuDQogDQogICBEaWZmZXJlbnQgVGltZXJzOiANCiAgICAgTFNB IHJlZnJlc2ggaW50ZXJ2YWwgPSAxODAwIHNlY29uZHMsIA0KICAgICBIZWxsbyByZWZyZXNoIGlu dGVydmFsID0gMTAgU2Vjb25kcywgDQogICAgIFJvdXRlci1EZWFkIGludGVydmFsID0gNDAgc2Vj b25kcywgDQogICAgIExTQSByZXRyYW5zbWlzc2lvbiBpbnRlcnZhbDogdHdvIHZhbHVlcyBhcmUg Y29uc2lkZXJlZCwgMTAgc2Vjb25kcyANCiAgICAgICBhbmQgNSBTZWNvbmRzIChub3RlIHRoYXQg YSByZXRyYW5zbWlzc2lvbiBpcyBkaXNhYmxlZCBvbiB0aGUgDQogICAgICAgcmVjZWlwdCBvZiBl aXRoZXIgYW4gZXhwbGljaXQgYWNrbm93bGVkZ21lbnQgb3IgYSBkdXBsaWNhdGUgTFNBDQogICAg ICAgb3ZlciB0aGUgc2FtZSBpbnRlcmZhY2UgdGhhdCBhY3RzIGFzIGFuIGltcGxpY2l0IGFja25v d2xlZGdtZW50KSANCiAgICAgTWluaW11bSB0aW1lIGJldHdlZW4gc3VjY2Vzc2l2ZSBnZW5lcmF0 aW9uIG9mIHRoZSBzYW1lIExTQSA9IDUgDQogICAgICAgc2Vjb25kcywgDQogICAgIE1pbmltdW0g dGltZSBiZXR3ZWVuIHN1Y2Nlc3NpdmUgRGlqa3N0cmEgU1BGIGNhbGN1bGF0aW9ucyANCiAgICAg ICBpcyAxIHNlY29uZC4NCg0KICAgUGFja2luZyBvZiBMU0FzOiBJdCBpcyBhc3N1bWVkIHRoYXQg Zm9yIGFueSBnaXZlbiBub2RlLCB0aGUgTFNBcyANCiAgIGdlbmVyYXRlZCBvdmVyIGEgMS1zZWNv bmQgcGVyaW9kIGFyZSBwYWNrZWQgdG9nZXRoZXIgdG8gZm9ybSBhbiBMU1UgDQogICBidXQgbm8g bW9yZSB0aGFuIDMgTFNBcyBhcmUgcGFja2VkIGluIG9uZSBMU1UuDQoNCiAgIExTVS9BY2svSGVs bG8gUHJvY2Vzc2luZyBUaW1lczogQWxsIHByb2Nlc3NpbmcgdGltZXMgYXJlIGV4cHJlc3NlZCAg DQogICBpbiB0ZXJtcyBvZiB0aGUgcGFyYW1ldGVyIFQuICBUd28gdmFsdWVzIG9mIFQgYXJlIGNv bnNpZGVyZWQsIDEgbXMNCg0KICAgICAgICAgIA0KICAgQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQogICBJbnRlcm5l dCBEcmFmdCAgICAgICAgICBFeHBsaWNpdCBNYXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIw MDMNCg0KDQogICBhbmQgMC41IG1zLg0KDQogICBJbiB0aGUgY2FzZSBvZiBhIGRlZGljYXRlZCBw cm9jZXNzb3IgZm9yIHByb2Nlc3NpbmcgT1NQRiBwYWNrZXRzIHRoZSANCiAgIHByb2Nlc3Npbmcg dGltZSByZXBvcnRlZCByZXByZXNlbnRzIHRoZSB0cnVlIHByb2Nlc3NpbmcgdGltZS4gSWYgdGhl IA0KICAgcHJvY2Vzc29yIGRvZXMgb3RoZXIgd29yayBhbmQgb25seSBhIGZyYWN0aW9uIG9mIGl0 cyBjYXBhY2l0eSBjYW4gYmUgDQogICBkZWRpY2F0ZWQgdG8gT1NQRiBwcm9jZXNzaW5nIHRoZW4g d2UgaGF2ZSB0byBpbmZsYXRlIHRoZSBwcm9jZXNzaW5nIA0KICAgdGltZSBhcHByb3ByaWF0ZWx5 IHRvIGdldCB0aGUgZWZmZWN0aXZlIHByb2Nlc3NpbmcgdGltZSBhbmQgaW4gdGhhdCANCiAgIGNh c2UgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBpbmZsYXRpb24gZmFjdG9yIGlzIGFscmVhZHkgdGFr ZW4gaW50byANCiAgIGFjY291bnQgYXMgcGFydCBvZiB0aGUgcmVwb3J0ZWQgcHJvY2Vzc2luZyB0 aW1lLiANCg0KICAgVGhlIGZpeGVkIHRpbWUgdG8gc2VuZCBvciByZWNlaXZlIGFueSBMU1UsIEFj ayBvciBIZWxsbyBwYWNrZXQgaXMgVC4NCiAgIEluIGFkZGl0aW9uLCBhIHZhcmlhYmxlIHByb2Nl c3NpbmcgdGltZSBpcyB1c2VkIGZvciBMU1UgYW5kIEFjayANCiAgIGRlcGVuZGluZyBvbiB0aGUg bnVtYmVyIGFuZCB0eXBlcyBvZiBMU0FzIHBhY2tlZC4gIE5vIHZhcmlhYmxlIA0KICAgcHJvY2Vz c2luZyB0aW1lIGlzIHVzZWQgZm9yIEhlbGxvLg0KICAgVmFyaWFibGUgcHJvY2Vzc2luZyB0aW1l IHBlciBSb3V0ZXIgTFNBIGlzICgwLjUgKyAwLjE3TClUIHdoZXJlIEwgaXMgDQogICB0aGUgbnVt YmVyIG9mIGFkamFjZW5jaWVzIGFkdmVydGlzZWQgYnkgdGhlIFJvdXRlciBMU0EuICBGb3Igb3Ro ZXIgDQogICBMU0EgdHlwZXMgKGUuZy4sIEFTRSBMU0Egb3IgYSAiTGluayIgTFNBIGNhcnJ5aW5n IHRyYWZmaWMgDQogICBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbiBhYm91dCBhIGxpbmspLCB0aGUg dmFyaWFibGUgcHJvY2Vzc2luZyB0aW1lICANCiAgIHBlciBMU0EgaXMgMC41VC4NCg0KICAgVmFy aWFibGUgcHJvY2Vzc2luZyB0aW1lIGZvciBhbiBBY2sgaXMgMjUlIHRoYXQgb2YgdGhlIGNvcnJl c3BvbmRpbmcgDQogICBMU0EuDQoNCiAgIEl0IGlzIHRvIGJlIG5vdGVkIHRoYXQgaWYgbXVsdGlw bGUgTFNBcyBhcmUgcGFja2VkIGluIGEgc2luZ2xlIExTVSANCiAgIHBhY2tldCB0aGVuIHRoZSBm aXhlZCBwcm9jZXNzaW5nIHRpbWUgaXMgbmVlZGVkIG9ubHkgb25jZSBidXQgdGhlIA0KICAgdmFy aWFibGUgcHJvY2Vzc2luZyB0aW1lIGlzIG5lZWRlZCBmb3IgZXZlcnkgY29tcG9uZW50IG9mIHRo ZSANCiAgIHBhY2tldC4NCiANCiAgIFRoZSBwcm9jZXNzaW5nIHRpbWUgdmFsdWVzIHdlIHVzZSBh cmUgcm91Z2hseSBpbiB0aGUgc2FtZSByYW5nZSBvZiANCiAgIHdoYXQgaGFzIGJlZW4gb2JzZXJ2 ZWQgaW4gYW4gb3BlcmF0aW9uYWwgbmV0d29yay4NCg0KICAgTFNVL0Fjay9IZWxsbyBQcmlvcml0 eTogVHdvIG5vbi1wcmVlbXB0aXZlIHByaW9yaXR5IGxldmVscyBhbmQNCiAgIHRocmVlIHByaW9y aXR5IHNjZW5hcmlvcyBhcmUgY29uc2lkZXJlZC4gV2l0aGluIGVhY2ggcHJpb3JpdHkgbGV2ZWwg DQogICBwcm9jZXNzaW5nIGlzIEZJRk8gd2l0aCBuZXcgcGFja2V0cyBvZiBsb3dlciBwcmlvcml0 eSBiZWluZw0KICAgZHJvcHBlZCB3aGVuIHRoZSBsb3dlciBwcmlvcml0eSBxdWV1ZSBpcyBmdWxs LiAgVGhlIGhpZ2hlciBwcmlvcml0eQ0KICAgcGFja2V0cyBhcmUgbmV2ZXIgZHJvcHBlZC4gICAg DQogICAgICBJbiBQcmlvcml0eSBzY2VuYXJpbyAxLCBhbGwgTFNVcy9BY2tzL0hlbGxvcyByZWNl aXZlZCBhdCBhIG5vZGUgDQogICAgICBhcmUgcXVldWVkIGF0IHRoZSBsb3dlciBwcmlvcml0eS4N CiAgICAgIEluIFByaW9yaXR5IHNjZW5hcmlvIDIsIEhlbGxvcyByZWNlaXZlZCBhdCBhIG5vZGUg YXJlIHF1ZXVlZCBhdCANCiAgICAgIHRoZSBoaWdoZXIgcHJpb3JpdHkgYnV0IExTVXMvQWNrcyBh cmUgcXVldWVkIGF0IGxvd2VyIHByaW9yaXR5Lg0KICAgICAgSW4gUHJpb3JpdHkgc2NlbmFyaW8g MywgSGVsbG9zIGFuZCBBY2tzIHJlY2VpdmVkIGF0IGEgbm9kZSBhcmUgDQogICAgICBxdWV1ZWQg YXQgdGhlIGhpZ2hlciBwcmlvcml0eSBidXQgTFNVcyBhcmUgcXVldWVkIGF0IGxvd2VyIA0KICAg ICAgcHJpb3JpdHkuIA0KICAgQWxsIHBhY2tldHMgZ2VuZXJhdGVkIGludGVybmFsbHkgdG8gYSBu b2RlICh1c3VhbGx5IHRyaWdnZXJlZCBieSANCiAgIGEgdGltZXIpIGFyZSBwcm9jZXNzZWQgYXQg dGhlIGhpZ2hlciBwcmlvcml0eS4gIFRoaXMgaW5jbHVkZXMgdGhlIA0KICAgaW5pdGlhbCBMU0Eg c3Rvcm0sIExTQSByZWZyZXNoLCBIZWxsbyByZWZyZXNoLCBMU0EgcmV0cmFuc21pc3Npb24gDQog ICBhbmQgbmV3IExTQSBnZW5lcmF0aW9uIGFmdGVyIGRldGVjdGlvbiBvZiBhIGZhaWx1cmUgb3Ig cmVjb3ZlcnkuDQoNCiAgIEJ1ZmZlciBTaXplIGZvciBJbmNvbWluZyBMU1VzL0Fja3MvSGVsbG9z IChsb3dlciBwcmlvcml0eSk6IEJ1ZmZlciANCg0KICAgICAgICAgIA0KICAgQ2hvdWRodXJ5IGV0 LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoM DQogICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICBFeHBsaWNpdCBNYXJraW5nICAgICAgICAgICAg ICAgICBNYXksIDIwMDMNCg0KDQogICBzaXplIGlzIGFzc3VtZWQgdG8gYmUgMjAwMCBwYWNrZXRz IHdoZXJlIGEgcGFja2V0IGlzIGVpdGhlciBhbiBBY2ssIA0KICAgTFNVLCBvciBIZWxsby4gDQoN CiAgIExTQSBSZWZyZXNoOiBFYWNoIExTQSBpcyByZWZyZXNoZWQgb25jZSBpbiAxODAwIHNlY29u ZHMgYW5kIHRoZSANCiAgIHJlZnJlc2ggaW5zdGFudHMgb2YgdmFyaW91cyBMU0FzIGluIHRoZSBM U0RCIGFyZSBhc3N1bWVkIHRvIGJlIA0KICAgdW5pZm9ybWx5IGRpc3RyaWJ1dGVkIG92ZXIgdGhl IDE4MDAgc2Vjb25kcyBwZXJpb2QsIGkuZS4sIHRoZXkgYXJlIA0KICAgY29tcGxldGVseSB1bnN5 bmNocm9uaXplZC4gIElmIGhvd2V2ZXIsIGFuIExTQSBpcyBnZW5lcmF0ZWQgYXMgcGFydCANCiAg IG9mIHRoZSBpbml0aWFsIExTQSBzdG9ybSB0aGVuIGl0IGdvZXMgb24gYSBuZXcgcmVmcmVzaCBz Y2hlZHVsZSBvZiANCiAgIG9uY2UgaW4gMTgwMCBzZWNvbmRzIHN0YXJ0aW5nIGZyb20gaXRzIGdl bmVyYXRpb24gdGltZS4gICANCg0KICAgTFNBIFN0b3JtIEdlbmVyYXRpb246IEFzIGRlZmluZWQg ZWFybGllciwgIkxTQSBzdG9ybSIgaXMgdGhlIA0KICAgc2ltdWx0YW5lb3VzIG9yIG5lYXIgc2lt dWx0YW5lb3VzIGdlbmVyYXRpb24gb2YgYSBsYXJnZSBudW1iZXIgb2YgDQogICBMU0FzLiBJbiB0 aGUgY2FzZSBvZiBvbmx5IFJvdXRlciBhbmQgQVNFIExTQXMgd2Ugbm9ybWFsbHkgYXNzdW1lICAN CiAgIHRoYXQgdGhlIG51bWJlciBvZiBBU0UgTFNBcyBpbiB0aGUgc3Rvcm0gaXMgYWJvdXQgNCB0 aW1lcyB0aGF0IG9mICANCiAgIHRoZSBSb3V0ZXIgTFNBcywgYnV0IHRoZSByYXRpbyBpcyBhbGxv d2VkIHRvIGNoYW5nZSBpZiBlaXRoZXIgdGhlICANCiAgIFJvdXRlciBvciB0aGUgQVNFIExTQXMg aGF2ZSByZWFjaGVkIHRoZWlyIG1heGltdW0gcG9zc2libGUgdmFsdWUuICAgDQogICBJbiB0aGUg Y2FzZSBvZiBvbmx5IFJvdXRlciBhbmQgTGluayBMU0FzIChjYXJyeWluZyB0cmFmZmljICANCiAg IGVuZ2luZWVyaW5nIGluZm9ybWF0aW9uKSB3ZSBub3JtYWxseSBhc3N1bWUgdGhhdCB0aGUgbnVt YmVyIG9mIExpbmsgIA0KICAgTFNBcyBpbiB0aGUgc3Rvcm0gaXMgYWJvdXQgNCB0aW1lcyB0aGF0 IG9mIHRoZSBSb3V0ZXIgTFNBcywgYnV0IHRoZSAgDQogICByYXRpbyBpcyBhbGxvd2VkIHRvIGNo YW5nZSBpZiBlaXRoZXIgdGhlIFJvdXRlciBvciB0aGUgTGluayBMU0FzICANCiAgIGhhdmUgcmVh Y2hlZCB0aGVpciBtYXhpbXVtIHBvc3NpYmxlIHZhbHVlLiAgRm9yIGFueSBnaXZlbiBMU0Egc3Rv cm0gIA0KICAgd2Uga2VlcCBnZW5lcmF0aW5nIExTQXMgc3RhcnRpbmcgZnJvbSBOb2RlIGluZGV4 IDEgYW5kIG1vdmluZyAgDQogICB1cHdhcmRzIGFuZCBzdG9wIHVudGlsIHRoZSBjb3JyZWN0IG51 bWJlciBvZiBMU0FzIG9mIGVhY2ggdHlwZSBoYXZlICANCiAgIGJlZW4gZ2VuZXJhdGVkLiAgVGhl IExTQXMgZ2VuZXJhdGVkIGF0IGFueSBnaXZlbiBub2RlIGlzIGFzc3VtZWQgdG8gIA0KICAgc3Rh cnQgYXQgYW4gaW5zdGFudCB1bmlmb3JtbHkgZGlzdHJpYnV0ZWQgYmV0d2VlbiAyMCBhbmQgMzAg c2Vjb25kcyANCiAgIGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBzaW11bGF0aW9uLiAgU3VjY2Vzc2l2 ZSBMU0EgZ2VuZXJhdGlvbnMgYXQgYSAgDQogICBub2RlIGFyZSBhc3N1bWVkIHRvIGJlIHNwYWNl ZCBhcGFydCBieSA0MDAgbXMuIEl0IGlzIHRvIGJlIG5vdGVkICANCiAgIHRoYXQgZHVyaW5nIHRo ZSBwZXJpb2Qgb2Ygb2JzZXJ2YXRpb24gdGhlcmUgYXJlIG90aGVyIExTQXMgIA0KICAgZ2VuZXJh dGVkIGJlc2lkZXMgdGhlIG9uZXMgaW4gdGhlIHN0b3JtLiAgVGhlc2UgaW5jbHVkZSByZWZyZXNo IG9mICANCiAgIExTQXMgdGhhdCBhcmUgbm90IHBhcnQgb2YgdGhlIHN0b3JtIGFuZCBMU0FzIGdl bmVyYXRlZCBkdWUgdG8gIA0KICAgcG9zc2libGUgbGluayBmYWlsdXJlcyBhbmQgc3Vic2VxdWVu dCBwb3NzaWJsZSBsaW5rIHJlY292ZXJpZXMuDQoNCiAgIEZhaWx1cmUvUmVjb3Zlcnkgb2YgTGlu a3M6IElmIG5vIEhlbGxvIGlzIHJlY2VpdmVkIG92ZXIgYSBsaW5rIChkdWUgDQogICB0byBDUFUv bWVtb3J5IGNvbmdlc3Rpb24pIGZvciBsb25nZXIgdGhhbiBSb3V0ZXItRGVhZCBJbnRlcnZhbCB0 aGVuDQogICB0aGUgbGluayBpcyBkZWNsYXJlZCBkb3duLiAgQXQgYSBsYXRlciB0aW1lLCBpZiBI ZWxsb3MgYXJlIHJlY2VpdmVkDQogICB0aGVuIHRoZSBsaW5rIHdvdWxkIGJlIGRlY2xhcmVkIHVw LiAgV2hlbmV2ZXIgYSBsaW5rIGlzIGRlY2xhcmVkDQogICB1cCBvciBkb3duLCBvbmUgUm91dGVy IExTQSBpcyBnZW5lcmF0ZWQgYnkgZWFjaCBSb3V0ZXIgb24gdGhlDQogICB0d28gc2lkZXMgb2Yg dGhlIHBvaW50LXRvLXBvaW50IGxpbmsuICBJZiAiTGluayBMU0FzIiBjYXJyeWluZw0KICAgdHJh ZmZpYyBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbiBpcyB1c2VkIHRoZW4gaXQgaXMgYXNzdW1lZCB0 aGF0IGVhY2gNCiAgIFJvdXRlciB3b3VsZCBhbHNvIGdlbmVyYXRlIGEgTGluayBMU0EuICBJbiB0 aGlzIGNhc2UgaXQgaXMgYWxzbyANCiAgIGFzc3VtZWQgdGhhdCBkdWUgdG8gcmVyb3V0aW5nIG9m IExTUHMsIHRocmVlIG90aGVyIGxpbmtzIGluIHRoZSANCiAgIG5ldHdvcmsgKHNlbGVjdGVkIHJh bmRvbWx5IGluIHRoZSBzaW11bGF0aW9uKSB3b3VsZCBoYXZlIHNpZ25pZmljYW50IA0KICAgY2hh bmdlIGluIHJlc2VydmVkIGJhbmR3aWR0aCB3aGljaCB3b3VsZCByZXN1bHQgaW4gb25lIExpbmsg TFNBIA0KICAgYmVpbmcgZ2VuZXJhdGVkIGJ5IHRoZSByb3V0ZXJzIG9uIHRoZSB0d28gZW5kcyBv ZiBlYWNoIHN1Y2ggbGluay4NCg0KDQozLiBTaW11bGF0aW9uIFJlc3VsdHMNCg0KICAgSW4gdGhp cyBzZWN0aW9uIHdlIHN0dWR5IHRoZSByZWxhdGl2ZSBwZXJmb3JtYW5jZSBvZiB0aGUgdGhyZWUg DQoNCiAgICAgICAgICANCiAgIENob3VkaHVyeSBldC4gYWwuICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgRXhwbGljaXQgTWFya2luZyAgICAgICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0KICAgUHJp b3JpdHkgc2NlbmFyaW9zIGRlZmluZWQgZWFybGllciAobm8gcHJpb3JpdHkgdG8gSGVsbG8gb3Ig QWNrLCANCiAgIHByaW9yaXR5IHRvIEhlbGxvIG9ubHksIGFuZCBwcmlvcml0eSB0byBib3RoIEhl bGxvIGFuZCBBY2spIHdpdGggYSANCiAgIHJhbmdlIG9mIE5ldHdvcmsgc2l6ZXMsIExTQSByZXRy YW5zbWlzc2lvbiB0aW1lciB2YWx1ZXMsIExTQSB0eXBlcywgDQogICBwcm9jZXNzaW5nIHRpbWUg dmFsdWVzIGFuZCBIZWxsby9Sb3V0ZXItRGVhZC1JbnRlcnZhbCB2YWx1ZXM6DQogICANCiAgIE5l dHdvcmsgc2l6ZTogVHdvIG5ldHdvcmtzIGFyZSBjb25zaWRlcmVkLiAgTmV0d29yayAxIGhhcyAx MDAgbm9kZXMsIA0KICAgMTIwMCBsaW5rcywgbWF4aW11bSBudW1iZXIgb2YgbmVpZ2hib3JzIHBl ciBub2RlIGlzIDMwIGFuZCBtYXhpbXVtIA0KICAgbnVtYmVyIG9mIGFkamFjZW5jaWVzIHBlciBu b2RlIGlzIDUwIChzYW1lIG5laWdoYm9yIG1heSBoYXZlIG1vcmUgDQogICB0aGFuIG9uZSBhZGph Y2VuY2llcykuICAgTmV0d29yayAyIGhhcyA1MCBub2RlcywgNjAwIGxpbmtzLCBtYXhpbXVtIA0K ICAgbnVtYmVyIG9mIG5laWdoYm9ycyBwZXIgbm9kZSBpcyAyNSBhbmQgbWF4aW11bSBudW1iZXIg b2YgYWRqYWNlbmNpZXMgDQogICBwZXIgbm9kZSBpcyA0OC4gRGlqa3N0cmEgU1BGIGNhbGN1bGF0 aW9uIHRpbWUgZm9yIE5ldHdvcmsgMSBpcyAgDQogICBhc3N1bWVkIHRvIGJlIDEwMCBtcyBhbmQg dGhhdCBmb3IgTmV0d29yayAyIGlzIGFzc3VtZWQgdG8gYmUgNzAgbXMuDQoNCiAgIExTQSBUeXBl OiBFYWNoIG5vZGUgaGFzIDEgUm91dGVyIExTQSAoVG90YWwgb2YgMTAwIGZvciBOZXR3b3JrIDEg YW5kIA0KICAgNTAgZm9yIE5ldHdvcmsgMikuIFRoZXJlIGFyZSBubyBOZXR3b3JrIExTQXMgc2lu Y2UgYWxsIGxpbmtzIGFyZSANCiAgIHBvaW50LXRvLXBvaW50IGxpbmtzIGFuZCBubyBTdW1tYXJ5 IExTQXMgc2luY2UgdGhlIG5ldHdvcmsgaGFzIG9ubHkgDQogICBvbmUgYXJlYS4gUmVnYXJkaW5n IG90aGVyIExTQSB0eXBlcyB3ZSBjb25zaWRlciB0d28gc2l0dWF0aW9ucy4gIEluICANCiAgIFNp dHVhdGlvbiAxIHdlIGFzc3VtZSB0aGF0IHRoZXJlIGFyZSBubyBBU0UgTFNBcyBhbmQgZWFjaCBs aW5rIGhhcyAgDQogICBvbmUgIkxpbmsiIExTQSBjYXJyeWluZyB0cmFmZmljIGVuZ2luZWVyaW5n IGluZm9ybWF0aW9uIChUb3RhbCBvZiAgDQogICAyNDAwIGZvciBOZXR3b3JrIDEgYW5kIDEyMDAg Zm9yIE5ldHdvcmsgMikuIEluIFNpdHVhdGlvbiAyIHdlIGFzc3VtZQ0KICAgdGhhdCB0aGVyZSBh cmUgbm8gIkxpbmsiIExTQXMgYW5kIGhhbGYgb2YgdGhlIG5vZGVzIGFyZSBBU0EtQm9yZGVyICAN CiAgIG5vZGVzIGFuZCBlYWNoIGJvcmRlciBub2RlIGhhcyAxMCBBU0UgTFNBcyAoVG90YWwgb2Yg NTAwIGZvciAgDQogICBOZXR3b3JrIDEgYW5kIDI1MCBmb3IgTmV0d29yayAyKS4gIFdlIGlkZW50 aWZ5IFNpdHVhdGlvbiAxIGFzICJMaW5rICANCiAgIExTQXMiIGFuZCBTaXR1YXRpb24gMiBhcyAi QVNFIExTQXMiLg0KDQogICBMU0EgcmV0cmFuc21pc3Npb24gdGltZXIgdmFsdWU6IFR3byB2YWx1 ZXMgYXJlIGNvbnNpZGVyZWQsIDEwIA0KICAgc2Vjb25kcyBhbmQgNSBzZWNvbmRzIChkZWZhdWx0 IHZhbHVlKS4NCg0KICAgUHJvY2Vzc2luZyB0aW1lIHZhbHVlczogUHJvY2Vzc2luZyB0aW1lcyBm b3IgTFNVcywgQWNrcyBhbmQgSGVsbG8gDQogICBwYWNrZXRzIGhhdmUgYmVlbiBwcmV2aW91c2x5 IGV4cHJlc3NlZCBpbiB0ZXJtcyBvZiBhIGNvbW1vbiAgDQogICBwYXJhbWV0ZXIgVC4gIFR3byB2 YWx1ZXMgYXJlIGNvbnNpZGVyZWQgZm9yIFQsIHdoaWNoIGFyZSAxIG1zIA0KICAgYW5kIDAuNSBt cyByZXNwZWN0aXZlbHkuDQogICANCiAgIEhlbGxvL1JvdXRlci1EZWFkLUludGVydmFsOiBJdCBp cyBhc3N1bWVkIHRoYXQgUm91dGVyLURlYWQgaW50ZXJ2YWwNCiAgIGlzIGZvdXIgdGltZXMgdGhl IEhlbGxvIGludGVydmFsLiAgSW4gb25lIGNhc2UgaXQgaXMgYXNzdW1lZCB0aGF0DQogICBIZWxs byBpbnRlcnZhbCBpcyAxMCBzZWNvbmRzIGFuZCBSb3V0ZXItRGVhZC1JbnRlcnZhbCBpcyA0MA0K ICAgc2Vjb25kcyAoZGVmYXVsdCB2YWx1ZXMpLCBhbmQgaW4gdGhlIG90aGVyIGNhc2UgaXQgaXMg YXNzdW1lZCB0aGF0IA0KICAgSGVsbG8gaW50ZXJ2YWwgaXMgMiBzZWNvbmRzIGFuZCBSb3V0ZXIt RGVhZC1JbnRlcnZhbCBpcyA4IHNlY29uZHMuIA0KDQogICBCYXNlZCBvbiBOZXR3b3JrIHNpemUs IExTQSB0eXBlIGFuZCBwcm9jZXNzaW5nIHRpbWUgdmFsdWVzIHdlIA0KICAgZGV2ZWxvcCA2IFRl c3QgY2FzZXMgYXMgZm9sbG93czoNCg0KICAgQ2FzZSAxOiBOZXR3b3JrIDEsIExpbmsgTFNBcywg cmV0cmFuc21pc3Npb24gdGltZXIgPSAxMCBzZWMuLCANCiAgICAgICAgICAgVCA9IDEgbXMsIEhl bGxvL1JvdXRlci1EZWFkLUludGVydmFsID0gMTAvNDAgc2VjLg0KDQogICBDYXNlIDI6IE5ldHdv cmsgMSwgQVNFIExTQXMsIHJldHJhbnNtaXNzaW9uIHRpbWVyID0gMTAgc2VjLiwgDQogICAgICAg ICAgIFQgPSAxIG1zLCBIZWxsby9Sb3V0ZXItRGVhZC1JbnRlcnZhbCA9IDEwLzQwIHNlYy4NCg0K ICAgQ2FzZSAzOiBOZXR3b3JrIDEsIExpbmsgTFNBcywgcmV0cmFuc21pc3Npb24gdGltZXIgPSA1 IHNlYy4sIA0KDQogICAgICAgICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCiAgIEludGVybmV0IERyYWZ0 ICAgICAgICAgIEV4cGxpY2l0IE1hcmtpbmcgICAgICAgICAgICAgICAgIE1heSwgMjAwMw0KDQoN CiAgICAgICAgICAgVCA9IDEgbXMsIEhlbGxvL1JvdXRlci1EZWFkLUludGVydmFsID0gMTAvNDAg c2VjLg0KDQogICBDYXNlIDQ6IE5ldHdvcmsgMSwgTGluayBMU0FzLCByZXRyYW5zbWlzc2lvbiB0 aW1lciA9IDEwIHNlYy4sIA0KICAgICAgICAgICBUID0gMC41IG1zLCBIZWxsby9Sb3V0ZXItRGVh ZC1JbnRlcnZhbCA9IDEwLzQwIHNlYy4NCg0KICAgQ2FzZSA1OiBOZXR3b3JrIDEsIExpbmsgTFNB cywgcmV0cmFuc21pc3Npb24gdGltZXIgPSAxMCBzZWMuLCANCiAgICAgICAgICAgVCA9IDEgbXMs IEhlbGxvL1JvdXRlci1EZWFkLUludGVydmFsID0gMi84IHNlYy4NCg0KICAgQ2FzZSA2OiBOZXR3 b3JrIDIsIExpbmsgTFNBcywgcmV0cmFuc21pc3Npb24gdGltZXIgPSAxMCBzZWMuLCANCiAgICAg ICAgICAgVCA9IDEgbXMsIEhlbGxvL1JvdXRlci1EZWFkLUludGVydmFsID0gMTAvNDAgc2VjLg0K DQoNCiAgIEZvciBlYWNoIGNhc2UgYW5kIGZvciBlYWNoIFByaW9yaXR5IHNjZW5hcmlvIHdlIHN0 dWR5IHRoZSBuZXR3b3JrIA0KICAgc3RhYmlsaXR5IGFzIGEgZnVuY3Rpb24gb2YgdGhlIHNpemUg b2YgdGhlIExTQSBzdG9ybS4gIFRoZSBzdGFiaWxpdHkNCiAgIGlzIGRldGVybWluZWQgYnkgbG9v a2luZyBhdCB0aGUgbnVtYmVyIG9mIG5vbi1jb252ZXJnZWQgTFNVcyBhcyBhICAgDQogICBmdW5j dGlvbiBvZiB0aW1lLiBBbiBleGFtcGxlIGlzIHNob3duIGluIFRhYmxlIDEgZm9yIENhc2UgMSBh bmQgDQogICBQcmlvcml0eSBzY2VuYXJpbyAxIChObyBwcmlvcml0eSB0byBIZWxsb3Mgb3IgQWNr cykuDQogICANCj09PT09PT09PXw9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQogICAgICAgICB8IE51bWJlciBvZiBOb24tQ29udmVyZ2Vk IExTVXMgaW4gdGhlIE5ldHdvcmsgYXQgVGltZShpbiBzZWMpDQogICAgTFNBICB8ICAgICAgICAg ICAgICAgICAgICANCiAgIFNUT1JNIHw9PT09fD09PT09fD09PT09fD09PT09fD09PT09fD09PT09 fD09PT09fD09PT09fD09PT09PT09fD09DQogICBTSVpFICB8MTBzIHwgMjBzIHwgMzBzIHwgMzVz IHwgNDBzIHwgNTBzIHwgNjBzIHwgODBzIHwgMTAwcyAgIHwNCj09PT09PT09PXw9PT09fD09PT09 fD09PT09fD09PT09fD09PT09fD09PT09fD09PT09fD09PT09fD09PT09PT09fD09DQogICAgMTAw ICB8IDAgIHwgIDAgIHwgMjQgIHwgMjkgIHwgMjQgIHwgIDEgIHwgIDAgIHwgIDEgIHwgIDEgICAg IHwNCiAoU3RhYmxlKXwgICAgfCAgICAgfCAgICAgfCAgICAgfCAgICAgfCAgICAgfCAgICAgfCAg ICAgfCAgICAgICAgfA0KLS0tLS0tLS0tfC0tLS18LS0tLS18LS0tLS18LS0tLS18LS0tLS18LS0t LS18LS0tLS18LS0tLS18LS0tLS0tLS18LS0NCiAgICAxNDAgIHwgMCAgfCAgMCAgfCAzNSAgfCA0 OCAgfCA0NiAgfCAyNyAgfCAxNCAgfCAgMSAgfCAgMSAgICAgfA0KIChTdGFibGUpfCAgICB8ICAg ICB8ICAgICB8ICAgICB8ICAgICB8ICAgICB8ICAgICB8ICAgICB8ICAgICAgICB8DQotLS0tLS0t LS18LS0tLXwtLS0tLXwtLS0tLXwtLS0tLXwtLS0tLXwtLS0tLXwtLS0tLXwtLS0tLXwtLS0tLS0t LXwtLQ0KICAgIDE2MCAgfCAwICB8ICAwICB8IDM4ICB8IDU3ICB8IDU1ICB8IDQwICB8IDI2ICB8 IDY1ICB8IDIwMyAgICB8DQooVW5zdGFibGUpICAgIHwgICAgIHwgICAgIHwgICAgIHwgICAgIHwg ICAgIHwgICAgIHwgICAgIHwgICAgICAgIHwNCj09PT09PT09PXw9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCiAgICAgICAgICAgVGFi bGUgMTogTmV0d29yayBTdGFiaWxpdHkgVnMuIExTQSBTdG9ybSANCiAgICAgICAgICAgICAgKENh c2UgMSwgTm8gcHJpb3JpdHkgdG8gSGVsbG8vQWNrKQ0KDQogICANCg0KICAgVGhlIExTQSBzdG9y bSBzdGFydHMgYSBsaXR0bGUgYWZ0ZXIgMjAgc2Vjb25kcyBhbmQgc28gZm9yIHNvbWUgDQogICBw ZXJpb2Qgb2YgdGltZSBhZnRlciB0aGF0IHRoZSBudW1iZXIgb2Ygbm9uLWNvbnZlcmdlZCBMU1Vz IHNob3VsZA0KICAgc3RheSBoaWdoIGFuZCB0aGVuIGNvbWUgZG93biBmb3IgYSBzdGFibGUgbmV0 d29yay4gDQogICBUaGlzIGhhcHBlbnMgZm9yIExTQSBzdG9ybXMgb2Ygc2l6ZXMgMTAwIGFuZCAx NDAuICBXaXRoIGFuIExTQSBzdG9ybQ0KICAgb2Ygc2l6ZSAxNjAsIHRoZSBudW1iZXIgb2Ygbm9u LWNvbnZlcmdlZCBMU1VzIHN0YXkgaGlnaCBpbmRlZmluaXRlbHkNCiAgIGR1ZSB0byByZXBlYXRl ZCByZXRyYW5zbWlzc2lvbnMsIGxpbmsgZmFpbHVyZXMgZHVlIHRvIG1pc3NlZCBIZWxsb3MgIA0K ICAgZm9yIG1vcmUgdGhhbiB0aGUgUm91dGVyLURlYWQgaW50ZXJ2YWwgd2hpY2ggZ2VuZXJhdGVz IGFkZGl0aW9uYWwgDQogICBMU0FzIGFuZCBhbHNvIGR1ZSB0byBzdWJzZXF1ZW50IGxpbmsgcmVj b3ZlcmllcyB3aGljaCBhZ2FpbiANCiAgIGdlbmVyYXRlIGFkZGl0aW9uYWwgTFNBcy4gIFdlIGRl ZmluZSBuZXR3b3JrIHN0YWJpbGl0eSB0aHJlc2hvbGQgYXMNCiAgIHRoZSBtYXhpbXVtIGFsbG93 YWJsZSBMU0Egc3Rvcm0gc2l6ZSBmb3Igd2hpY2ggdGhlIG51bWJlciBvZiANCg0KICAgICAgICAg IA0KICAgQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDldDQoMDQogICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICBFeHBsaWNpdCBN YXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQogICBub24tY29udmVyZ2VkIExT VXMgY29tZSBkb3duIHRvIGEgbG93IGxldmVsIGFmdGVyIHNvbWUgdGltZS4gSXQgDQogICB0dXJu cyBvdXQgdGhhdCBmb3IgdGhpcyBleGFtcGxlIHRoZSBzdGFiaWxpdHkgdGhyZXNob2xkIGlzDQog ICAxNTAuIA0KDQogICBUaGUgbmV0d29yayBiZWhhdmlvciBhcyBhIGZ1bmN0aW9uIG9mIHRoZSBM U0Egc3Rvcm0gc2l6ZSBjYW4NCiAgIGJlIGNhdGVnb3JpemVkIGFzIGZvbGxvd3M6DQoNCiAgICgx KSBJZiB0aGUgTFNBIHN0b3JtIGlzIHdlbGwgYmVsb3cgdGhlIHN0YWJpbGl0eSB0aHJlc2hvbGQg dGhlbg0KICAgICAgIHRoZSBDUFUvbWVtb3J5IGNvbmdlc3Rpb24gbGFzdHMgb25seSBmb3IgYSBz aG9ydCBwZXJpb2QgYW5kDQogICAgICAgZHVyaW5nIHRoaXMgcGVyaW9kIHRoZXJlIGFyZSB2ZXJ5 IGZldyByZXRyYW5zbWlzc2lvbnMsIHZlcnkNCiAgICAgICBmZXcgZHJvcHBlZCBPU1BGIHBhY2tl dHMgYW5kIG5vIGxpbmsNCiAgICAgICBmYWlsdXJlcyBkdWUgdG8gbWlzc2VkIEhlbGxvcy4gIFRo aXMgdHlwZSBvZiBMU0Egc3Rvcm1zIGFyZQ0KICAgICAgIG9ic2VydmVkIHJvdXRpbmVseSBpbiBv cGVyYXRpb25hbCBuZXR3b3JrcyBhbmQgbmV0d29ya3MNCiAgICAgICByZWNvdmVyIGZyb20gdGhl bSBlYXNpbHkuDQoNCiAgICgyKSBJZiB0aGUgTFNBIHN0b3JtIGlzIGp1c3QgYmVsb3cgdGhlIHN0 YWJpbGl0eSB0aHJlc2hvbGQgdGhlbg0KICAgICAgIHRoZSBDUFUvbWVtb3J5IGNvbmdlc3Rpb24g bGFzdHMgZm9yIGEgbG9uZ2VyIHBlcmlvZCBhbmQgZHVyaW5nDQogICAgICAgdGhpcyBwZXJpb2Qg dGhlcmUgbWF5IGJlIGNvbnNpZGVyYWJsZSBhbW91bnQgb2YgcmV0cmFuc21pc3Npb25zDQogICAg ICAgYW5kIGRyb3BwZWQgT1NQRiBwYWNrZXRzLiAgSWYgSGVsbG8gcGFja2V0cyBhcmUgbm90IGdp dmVuDQogICAgICAgcHJpb3JpdHkgdGhlbiB0aGVyZSBtYXkgYWxzbyBiZSBzb21lIGxpbmsgZmFp bHVyZXMgZHVlIHRvDQogICAgICAgbWlzc2VkIEhlbGxvcy4gIEhvd2V2ZXIsIHRoZSBuZXR3b3Jr IGRvZXMgZ28gYmFjayB0byBhIHN0YWJsZQ0KICAgICAgIHN0YXRlIGV2ZW50dWFsbHkuIFRoaXMg dHlwZSBvZiBMU0Egc3Rvcm0gbWF5IGhhcHBlbiByYXJlbHkgaW4NCiAgICAgICBvcGVyYXRpb25h bCBuZXR3b3JrcyBhbmQgdGhleSByZWNvdmVyIGZyb20gaXQgd2l0aCBzb21lDQogICAgICAgZGlm ZmljdWx0eS4gDQoNCiAgICgzKSBJZiB0aGUgTFNBIHN0b3JtIGlzIGFib3ZlIHRoZSBzdGFiaWxp dHkgdGhyZXNob2xkIHRoZW4NCiAgICAgICB0aGUgQ1BVL21lbW9yeSBjb25nZXN0aW9uIG1heSBs YXN0IGluZGVmaW5pdGVseSB1bmxlc3MNCiAgICAgICBzb21lIHNwZWNpYWwgcHJvY2VkdXJlIGZv ciByZWxpZXZpbmcgY29uZ2VzdGlvbiBpcyBmb2xsb3dlZC4gDQogICAgICAgRHVyaW5nIHRoaXMg cGVyaW9kIHRoZXJlIGFyZSBjb25zaWRlcmFibGUgYW1vdW50IG9mIA0KICAgICAgIHJldHJhbnNt aXNzaW9ucyBhbmQgZHJvcHBlZCBPU1BGIHBhY2tldHMuICBJZiBIZWxsbyBwYWNrZXRzIGFyZQ0K ICAgICAgIG5vdCBnaXZlbiBwcmlvcml0eSB0aGVuIHRoZXJlIHdvdWxkIGFsc28gYmUgbGluayBm YWlsdXJlcyBkdWUgDQogICAgICAgdG8gbWlzc2VkIEhlbGxvcy4gIFRoaXMgdHlwZSBvZiBMU0Eg c3Rvcm0gbWF5IGhhcHBlbiB2ZXJ5IA0KICAgICAgIHJhcmVseSBpbiBvcGVyYXRpb25hbCBuZXR3 b3JrcyBhbmQgdXN1YWxseSBzb21lIG1hbnVhbCBwcm9jZWR1cmUNCiAgICAgICBzdWNoIGFzIHRh a2luZyBkb3duIGFkamFjZW5jaWVzIGluIGhlYXZpbHkgY29uZ2VzdGVkIG5vZGVzIGlzDQogICAg ICAgbmVlZGVkLg0KDQogICAoNCkgSWYgSGVsbG8gcGFja2V0cyBhcmUgZ2l2ZW4gcHJpb3JpdHkg dGhlbiB0aGUgbmV0d29yayBzdGFiaWxpdHkNCiAgICAgICB0aHJlc2hvbGQgaW5jcmVhc2VzLCBp LmUuLCB0aGUgbmV0d29yayBjYW4gd2l0aHN0YW5kIGEgbGFyZ2VyDQogICAgICAgTFNBIHN0b3Jt LiBGdXJ0aGVybW9yZSwgZXZlbiBpZiB0aGUgbmV0d29yayBvcGVyYXRlcyBhdCBvciANCiAgICAg ICBzb21ld2hhdCBhYm92ZSB0aGlzIGhpZ2hlciBzdGFiaWxpdHkgdGhyZXNob2xkLCBIZWxsb3Mg YXJlIA0KICAgICAgIHN0aWxsIG5vdCBtaXNzZWQgYW5kIHNvIHRoZXJlIGFyZSBubyBsaW5rIGZh aWx1cmVzLiAgU28gZXZlbiANCiAgICAgICBpZiB0aGVyZSBpcyBjb25nZXN0aW9uIGluIHRoZSBj b250cm9sIHBsYW5lIGR1ZSB0byBpbmNyZWFzZWQgDQogICAgICAgcmV0cmFuc21pc3Npb25zIHJl cXVpcmluZyBzb21lIHNwZWNpYWwgcHJvY2VkdXJlcyBmb3IgY29uZ2VzdGlvbg0KICAgICAgIHJl ZHVjdGlvbiwgdGhlIGRhdGEgcGxhbmUgcmVtYWlucyB1bmFmZmVjdGVkLg0KICAgICAgICANCiAg ICg1KSBJZiBib3RoIEhlbGxvIGFuZCBBY2tub3dsZWRnZW1lbnQgcGFja2V0cyBhcmUgZ2l2ZW4g cHJpb3JpdHkNCiAgICAgICB0aGVuIHRoZSBzdGFiaWxpdHkgdGhyZXNob2xkIGluY3JlYXNlcyBl dmVuIGZ1cnRoZXIuICAgICAgIA0KICAgDQoNCg0KICAgICAgICAgIA0KICAgQ2hvdWRodXJ5IGV0 LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0K DA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgRXhwbGljaXQgTWFya2luZyAgICAgICAgICAg ICAgICAgTWF5LCAyMDAzDQoNCg0KICAgSW4gVGFibGUgMiB3ZSBzaG93IHRoZSBuZXR3b3JrIHN0 YWJpbGl0eSB0aHJlc2hvbGQgZm9yIHRoZSBmaXZlICANCiAgIGRpZmZlcmVudCBjYXNlcyBhbmQg Zm9yIHRoZSB0aHJlZSBkaWZmZXJlbnQgcHJpb3JpdHkgc2NlbmFyaW9zDQogICBkZWZpbmVkIGVh cmxpZXIuICANCg0KfD09PT09PT09PT09fD09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09fA0KfCAgICAgICAgICAgfCAgICBNYXhpbXVtIEFsbG93 YWJsZSBMU0EgU3Rvcm0gU2l6ZSBGb3IgICAgICAgICAgICAgICAgfA0KfCAgIENhc2UgICAgfD09 PT09PT09PT09PT09PT09fD09PT09PT09PT09PT09PT09PXw9PT09PT09PT09PT09PT09PT09fA0K fCAgTnVtYmVyICAgfCBObyBQcmlvcml0eSB0byAgfFByaW9yaXR5IHRvIEhlbGxvIHwgUHJpb3Jp dHkgdG8gSGVsbG8gfA0KfCAgICAgICAgICAgfCAgSGVsbG8gb3IgQWNrICAgfCAgICAgIE9ubHkg ICAgICAgIHwgICBhbmQgQWNrICAgICAgICAgfA0KfD09PT09PT09PT09fD09PT09PT09PT09PT09 PT09fD09PT09PT09PT09PT09PT09PXw9PT09PT09PT09PT09PT09PT09fA0KfCAgIENhc2UgMSAg fCAgICAgICAgMTUwICAgICAgfCAgICAgICAgMTkwICAgICAgIHwgICAgICAgIDI1MCAgICAgICAg fA0KfF9fX19fX19fX19ffF9fX19fX19fX19fX19fX19ffF9fX19fX19fX19fX19fX19fX3xfX19f X19fX19fX19fX19fX19ffA0KfCAgIENhc2UgMiAgfCAgICAgICAgMTg1ICAgICAgfCAgICAgICAg MjE1ICAgICAgIHwgICAgICAgIDI4NSAgICAgICAgfA0KfF9fX19fX19fX19ffF9fX19fX19fX19f X19fX19ffF9fX19fX19fX19fX19fX19fX3xfX19fX19fX19fX19fX19fX19ffA0KfCAgIENhc2Ug MyAgfCAgICAgICAgMTE1ICAgICAgfCAgICAgICAgMTI3ICAgICAgIHwgICAgICAgIDE3MCAgICAg ICAgfA0KfF9fX19fX19fX19ffF9fX19fX19fX19fX19fX19ffF9fX19fX19fX19fX19fX19fX3xf X19fX19fX19fX19fX19fX19ffA0KfCAgIENhc2UgNCAgfCAgICAgICAgMzIwICAgICAgfCAgICAg ICAgMzc1ICAgICAgIHwgICAgICAgIDU4MCAgICAgICAgfA0KfF9fX19fX19fX19ffF9fX19fX19f X19fX19fX19ffF9fX19fX19fX19fX19fX19fX3xfX19fX19fX19fX19fX19fX19ffA0KfCAgIENh c2UgNSAgfCAgICAgICAgMTIwICAgICAgfCAgICAgICAgMTc1ICAgICAgIHwgICAgICAgIDIyNSAg ICAgICAgfA0KfF9fX19fX19fX19ffF9fX19fX19fX19fX19fX19ffF9fX19fX19fX19fX19fX19f X3xfX19fX19fX19fX19fX19fX19ffA0KfCAgIENhc2UgNiAgfCAgICAgICAgMTg1ICAgICAgfCAg ICAgICAgMjI0ICAgICAgIHwgICAgICAgIDI4NSAgICAgICAgfA0KfF9fX19fX19fX19ffF9fX19f X19fX19fX19fX19ffF9fX19fX19fX19fX19fX19fX3xfX19fX19fX19fX19fX19fX19ffA0KDQog ICAgICAgVGFibGUgMjogTWF4aW11bSBBbGxvd2FibGUgTFNBIFN0b3JtIGZvciBhIFN0YWJsZSBO ZXR3b3JrDQoNCg0KNC4gT2JzZXJ2YXRpb25zIG9uIFNpbXVsYXRpb24gUmVzdWx0cw0KDQogICBU YWJsZSAyIHNob3dzIHRoYXQgaW4gYWxsIGNhc2VzIHByaW9yaXRpemluZyBIZWxsbyBwYWNrZXRz IGluY3JlYXNlcw0KICAgdGhlIG5ldHdvcmsgc3RhYmlsaXR5IHRocmVzaG9sZCwgYW5kIGluIGFk ZGl0aW9uLCBwcmlvcml0aXphdGlvbiBvZiAgDQogICBMU0EgQWNrbm93bGVkZ21lbnQgcGFja2V0 cyBpbmNyZWFzZXMgdGhlIHN0YWJpbGl0eSB0aHJlc2hvbGQgZXZlbg0KICAgZnVydGhlci4gIFRo ZSByZWFzb25zIGZvciB0aGUgYWJvdmUgb2JzZXJ2YXRpb25zIGFyZSBhcyBmb2xsb3dzLg0KICAg VGhlIG1haW4gc291cmNlcyBvZiBzdXN0YWluZWQgQ1BVL21lbW9yeSBjb25nZXN0aW9uIChvciBw b3NpdGl2ZQ0KICAgZmVlZGJhY2sgbG9vcCkgZm9sbG93aW5nIGFuIExTQSBzdG9ybSBhcmUgKDEp IExTQSByZXRyYW5zbWlzc2lvbnMgDQogICBhbmQgKDIpIGxpbmtzIGJlaW5nIGRlY2xhcmVkIGRv d24gZHVlIHRvIG1pc3NlZCBIZWxsb3Mgd2hpY2ggaW4gDQogICB0dXJuIGNhdXNlcyBmdXJ0aGVy IExTQSBnZW5lcmF0aW9uIGFuZCBmdXR1cmUgcmVjb3Zlcnkgb2YgdGhlIGxpbmsgICANCiAgIGNh dXNpbmcgZXZlbiBtb3JlIExTQSBnZW5lcmF0aW9uLiANCiAgIFByaW9yaXRpemluZyBIZWxsbyBw YWNrZXRzIGF2b2lkcyBhbmQgcHJhY3RpY2FsbHkgZWxpbWluYXRlcyB0aGUNCiAgIHNlY29uZCBz b3VyY2Ugb2YgY29uZ2VzdGlvbi4gIFByaW9yaXRpemluZyBBY2tub3dsZWRnZW1lbnRzIA0KICAg c2lnbmlmaWNhbnRseSByZWR1Y2VzIHRoZSBmaXJzdCBzb3VyY2Ugb2YgY29uZ2VzdGlvbiwgaS5l LiwNCiAgIExTQSByZXRyYW5zbWlzc2lvbnMuICBJdCBpcyB0byBiZSBub3RlZCB0aGF0IHJldHJh bnNtaXNzaW9ucyBjYW4NCiAgIG5vdCBiZSBjb21wbGV0ZWx5IGVsaW1pbmF0ZWQgZHVlIHRvIHRo ZSBmb2xsb3dpbmcgcmVhc29ucy4gRmlyc3RseSwNCiAgIG9ubHkgdGhlIGV4cGxpY2l0IEFja25v d2xlZGdtZW50cyBhcmUgcHJpb3JpdGl6ZWQgYnV0IGR1cGxpY2F0ZQ0KICAgTFNBcyBjYXJyeWlu ZyBpbXBsaWNpdCBBY2tub3dsZWRnbWVudHMgYXJlIHN0aWxsIHNlcnZlZCBhdCB0aGUgDQogICBs b3dlciBwcmlvcml0eS4gIFNlY29uZGx5LCBMU0FzIG1heSBnZXQgZ3JlYXRseSBkZWxheWVkIG9y IGRyb3BwZWQNCiAgIGF0IHRoZSBpbnB1dCBxdWV1ZSBvZiByZWNlaXZlcnMgYW5kIHRoZXJlZm9y ZSBBY2tub3dsZWRnbWVudHMgbWF5DQogICBub3QgZXZlbiBnZXQgZ2VuZXJhdGVkIGluIHdoaWNo IGNhc2UgcHJpb3JpdGl6aW5nIEFja3Mgd291bGQgbm90ICAgDQogICBoZWxwLiBBbm90aGVyIGZh Y3RvciB0byBrZWVwIGluIG1pbmQgaXMgdGhhdCBzaW5jZSBIZWxsb3MgYW5kIEFja3MgIA0KICAg YXJlIHByaW9yaXRpemVkLCB0aGUgTFNBcyBzZWUgYmlnZ2VyIGRlbGF5IGFuZCBwb3RlbnRpYWwg Zm9yIA0KDQogICAgICAgICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQogICBJbnRlcm5ldCBEcmFmdCAg ICAgICAgICBFeHBsaWNpdCBNYXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQog ICBkcm9wcGluZy4gSG93ZXZlciwgdGhlIHNpbXVsYXRpb24gcmVzdWx0cyBzaG93IHRoYXQgb24g dGhlIHdob2xlIA0KICAgcHJpb3JpdGl6aW5nIEhlbGxvIGFuZCBMU0EgQWNrcyBhcmUgYWx3YXlz IGJlbmVmaWNpYWwgYW5kIA0KICAgc2lnbmlmaWNhbnRseSBpbXByb3ZlIHRoZSBuZXR3b3JrIHN0 YWJpbGl0eSB0aHJlc2hvbGQuICAgIA0KDQogICBPdXIgc2ltdWxhdGlvbiBzdHVkeSBhbHNvIHNo b3dlZCB0aGF0IGluIGVhY2ggb2YgdGhlIGNhc2VzLCBpbnN0ZWFkIA0KICAgb2YgcHJpb3JpdGl6 aW5nIEhlbGxvIHBhY2tldHMgaWYgd2UgdHJlYXQgYW55IHBhY2tldCByZWNlaXZlZCBvdmVyIA0K ICAgYSBsaW5rIGFzIGEgc3Vycm9nYXRlIGZvciBhIEhlbGxvIHBhY2tldCAoYW4gaW1wbGljaXQg SGVsbG8pIHRoZW4NCiAgIHdlIGdldCBhYm91dCB0aGUgc2FtZSBzdGFiaWxpdHkgdGhyZXNob2xk IGFzIG9idGFpbmVkIHdpdGgNCiAgIHByaW9yaXRpemluZyBIZWxsbyBwYWNrZXRzLg0KDQogICBJ ZiB3ZSBwcmlvcml0aXplIEhlbGxvIHBhY2tldHMgdGhlbiBldmVuIHdoZW4gdGhlIG5ldHdvcmsg b3BlcmF0ZXMNCiAgIHNvbWV3aGF0IGFib3ZlIHRoZSBzdGFiaWxpdHkgdGhyZXNob2xkLCBsaW5r cyBhcmUgbm90IGRlY2xhcmVkDQogICBkb3duIGR1ZSB0byBtaXNzZWQgSGVsbG9zLiAgVGhpcyBp bXBsaWVzIHRoYXQgZXZlbiB0aG91Z2ggdGhlcmUgaXMgDQogICBjb250cm9sIHBsYW5lIGNvbmdl c3Rpb24gZHVlIHRvIG1hbnkgcmV0cmFuc21pc3Npb25zLCB0aGUgZGF0YSBwbGFuZQ0KICAgc3Rh eXMgdXAgYW5kIG5vIG5ldyBMU0FzIGFyZSBnZW5lcmF0ZWQgKGJlc2lkZXMgdGhlIG9uZXMgaW4g dGhlIA0KICAgb3JpZ2luYWwgc3Rvcm0gYW5kIHRoZSByZWZyZXNoZXMpICAgDQoNCg0KNS4gTmVl ZCBmb3IgUHJpb3JpdGl6ZWQgVHJlYXRtZW50IG9mIENyaXRpY2FsIE9TUEYgUGFja2V0cyBhbmQN CiAgIFNwZWNpYWwgTWFya2luZyB0byBGYWNpbGl0YXRlIFRoYXQgDQoNCiAgIFRoZSBvYnNlcnZh dGlvbnMgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb24gY2xlYXJseSBzaG93IHRoYXQNCiAgIHByaW9y aXRpemluZyBIZWxsbyBhbmQgTFNBIEFja25vd2xlZGdtZW50IHBhY2tldHMgYXJlIGdyZWF0bHkN CiAgIGJlbmVmaWNpYWwgaW4gaW1wcm92aW5nIHRoZSBzY2FsYWJpbGl0eSBhbmQgc3RhYmlsaXR5 IG9mIGxhcmdlDQogICBuZXR3b3Jrcy4gIEluIGFkZGl0aW9uIHRvIHRoZXNlIHBhY2tldHMgaXQg bWF5IGJlIGJlbmVmaWNpYWwNCiAgIHRvIHRyZWF0IGNlcnRhaW4gb3RoZXIgT1NQRiBwYWNrZXRz IGF0IHRoZSBoaWdoZXIgcHJpb3JpdHkgYXMgd2VsbC4NCiAgIE9uZSBleGFtcGxlIChkdXJpbmcg dGhlIGRhdGFiYXNlIGV4Y2hhbmdlIHByb2Nlc3MgYmV0d2VlbiBuZWlnaGJvcnMNCiAgIGZvbGxv d2luZyBhIGxpbmsgcmVjb3ZlcnkpIGlzIHRoZSBEYXRhYmFzZSBEZXNjcmlwdGlvbiBwYWNrZXQg ZnJvbSANCiAgIGEgc2xhdmUgdGhhdCBpcyB1c2VkIGFzIGFuIGFja25vd2xlZGdtZW50IGZvciB0 aGUgcHJldmlvdXMgRGF0YWJhc2UNCiAgIERlc2NyaXB0aW9uIHBhY2tldCBzZW50IGZyb20gdGhl IG1hc3Rlci4gQW5vdGhlciBleGFtcGxlIGlzIGFuIExTQSANCiAgIGNhcnJ5aW5nIGEgY2hhbmdl IGluZm9ybWF0aW9uIHdoaWNoIG1heSB0cmlnZ2VyIFNQRiBjYWxjdWxhdGlvbg0KICAgYW5kIHJl cm91dGluZyBvZiBMYWJlbCBTd2l0Y2hlZCBQYXRocy4gSXQgaXMgcHJlZmVyYWJsZSB0byB0cmFu c21pdCAgDQogICB0aGlzIGluZm9ybWF0aW9uIGZhc3RlciB0aGFuIG90aGVyIExTQXMgaW4gdGhl IG5ldHdvcmsgdGhhdCBhcmUgIA0KICAganVzdCBvbmNlLWluLTMwLW1pbnV0ZXMgcmVmcmVzaGVz IGFuZCB0eXBpY2FsbHkgd291bGQgbm90IHRyaWdnZXINCiAgIGFueSByb3V0ZSBjb21wdXRhdGlv biBvciByb3V0ZSBjaGFuZ2UuDQoNCiAgIEdpdmVuIHRoYXQgdGhlcmUgaXMgYSBuZWVkIGZvciBw cm92aWRpbmcgcHJpb3JpdGl6ZWQgdHJlYXRtZW50DQogICB0byBjZXJ0YWluIE9TUEYgcGFja2V0 cywgdGhlIG5leHQgbmF0dXJhbCBxdWVzdGlvbiBpcyBob3cgdG8NCiAgIGZhY2lsaXRhdGUgdGhp cyBwcmlvcml0aXphdGlvbi4gIA0KDQogICBJZiBpdCBpcyBwb3NzaWJsZSB0bw0KICAgZXhhbWlu ZSB0aGUgcGFja2V0IGhlYWRlciAoZm9yIHRoZSBwdXJwb3NlIG9mIHByaW9yaXRpemF0aW9uKSAN CiAgIG11Y2ggZmFzdGVyIHRoYW4gcHJvY2Vzc2luZyB0aGUgd2hvbGUgcGFja2V0IHRoZW4gcHJp b3JpdGl6ZWQNCiAgIHRyZWF0bWVudCBpcyBwb3NzaWJsZSB3aXRob3V0IGFueSBwcm90b2NvbCBj aGFuZ2VzLg0KDQogICBIb3dldmVyLCB3ZSBhbHNvIHByb3Bvc2UgdGhhdCBhIHNwZWNpYWwgbWFy a2luZyBiZSB1c2VkIGZvcg0KICAgY2F0ZWdvcml6aW5nIGFsbCBPU1BGIHBhY2tldHMgaW50byBv bmUgb2YgdHdvIHByaW9yaXR5IGNsYXNzZXMuDQogICBJdCBpcyBhbHNvIGltcG9ydGFudCB0byBz ZXBhcmF0ZWx5IG1hcmsgT1NQRiBwYWNrZXRzIGZyb20gb3RoZXINCiAgIElQIHBhY2tldHMuICBP bmUgd2F5IHRvIGRvIHRoaXMgaXMgdG8gcmVzZXJ2ZSB0d28gZGlmZnNlcnYNCg0KICAgICAgICAg IA0KICAgQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDEyXQ0KDA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgRXhwbGljaXQg TWFya2luZyAgICAgICAgICAgICAgICAgTWF5LCAyMDAzDQoNCg0KICAgY29kZXBvaW50cywgb25l IGZvciBoaWdoZXIgcHJpb3JpdHkgT1NQRiBwYWNrZXRzIGFuZCBhbm90aGVyDQogICBvbmUgZm9y IGxvd2VyIHByaW9yaXR5IE9TUEYgcGFja2V0cy4gIFdpdGggdGhpcyBzcGVjaWFsDQogICBtYXJr aW5nIGl0IHdvdWxkIGJlIGVhc3kgZm9yIE9TUEYgaW1wbGVtZW50ZXJzIHRvDQogICB0cmVhdCBI ZWxsbywgTFNBIGFja25vd2xlZGdtZW50LCBhbmQgb3RoZXIgY3JpdGljYWwgT1NQRg0KICAgcGFj a2V0cyBhdCBhIGhpZ2hlciBwcmlvcml0eSBhbmQgdGhlcmVieSBzaWduaWZpY2FudGx5DQogICBp bXByb3ZlIHRoZSBzY2FsYWJpbGl0eSBhbmQgc3RhYmlsaXR5IG9mIG5ldHdvcmtzIHVzaW5nDQog ICBPU1BGLiAgICAgDQoNCg0KNi4gU3VtbWFyeQ0KDQogICBJbiB0aGlzIGRyYWZ0IHdlIHBvaW50 IG91dCB0aGF0IHRoZSBub2RlIHByb2Nlc3NvcnMgb2YgYSBsYXJnZSANCiAgIG5ldHdvcmsgbWF5 IGJlIHN1YmplY3RlZCB0byBhIHN1c3RhaW5lZCBDUFUvTWVtb3J5IGNvbmdlc3Rpb24NCiAgIGFz IGEgcmVzdWx0IG9mIGEgbGFyZ2UgTFNBIHN0b3JtIGNhdXNlZCBieSBzb21lIHR5cGUgb2YgDQog ICBmYWlsdXJlL3JlY292ZXJ5IG9mIG5vZGVzL2xpbmtzIG9yIHN5bmNocm9uaXphdGlvbiBhbW9u ZyByZWZyZXNoZXMuDQogICBUaGVyZSBpcyBhIGNlcnRhaW4gTFNBIHN0b3JtIHNpemUgdGhyZXNo b2xkIGFib3ZlIHdoaWNoIHRoZSBuZXR3b3JrDQogICBtYXkgc2hvdyB1bnN0YWJsZSBiZWhhdmlv ciBjYXVzZWQgYnkgbGFyZ2UgbnVtYmVyIG9mIA0KICAgcmV0cmFuc21pc3Npb25zLCBsaW5rIGZh aWx1cmVzIGR1ZSB0byBtaXNzZWQgSGVsbG8gcGFja2V0cyBhbmQNCiAgIHN1YnNlcXVlbnQgbGlu ayByZWNvdmVyaWVzLiAgVXNpbmcgYSBzaW11bGF0aW9uIHN0dWR5IHdlIHNob3cgdGhhdA0KICAg dGhlIExTQSBzdG9ybSBzaXplIGNhdXNpbmcgaW5zdGFiaWxpdHkgbWF5IGJlIHN1YnN0YW50aWFs bHkNCiAgIGluY3JlYXNlZCBieSBwcm92aWRpbmcgcHJpb3JpdGl6ZWQgdHJlYXRtZW50IHRvIEhl bGxvIGFuZCBMU0EgDQogICBBY2tub3dsZWRnbWVudCBwYWNrZXRzLiAgRnVydGhlcm1vcmUsIGlm IHdlIHByaW9yaXRpemUgSGVsbG8gDQogICBwYWNrZXRzIHRoZW4gZXZlbiB3aGVuIHRoZSBuZXR3 b3JrIG9wZXJhdGVzIHNvbWV3aGF0IGFib3ZlIHRoZSANCiAgIHN0YWJpbGl0eSB0aHJlc2hvbGQs IGxpbmtzIGFyZSBub3QgZGVjbGFyZWQgZG93biBkdWUgdG8gbWlzc2VkIA0KICAgSGVsbG9zLiAg VGhpcyBpbXBsaWVzIHRoYXQgZXZlbiB0aG91Z2ggdGhlcmUgaXMgDQogICBjb250cm9sIHBsYW5l IGNvbmdlc3Rpb24gZHVlIHRvIG1hbnkgcmV0cmFuc21pc3Npb25zLCB0aGUgZGF0YSBwbGFuZQ0K ICAgc3RheXMgdXAgYW5kIG5vIG5ldyBMU0FzIGFyZSBnZW5lcmF0ZWQgKGJlc2lkZXMgdGhlIG9u ZXMgaW4gdGhlIA0KICAgb3JpZ2luYWwgc3Rvcm0gYW5kIHRoZSByZWZyZXNoZXMpLg0KDQogICBC YXNlZCBvbiB0aGUgYWJvdmUgb2JzZXJ2YXRpb25zIHdlIHByb3Bvc2UgdGhlIGZvbGxvd2luZzoN Cg0KICAgKDEpIFByb2Nlc3MgdGhlIEhlbGxvIHBhY2tldHMgYXQgYSBoaWdoZXIgcHJpb3JpdHkg Y29tcGFyZWQgdG8gb3RoZXINCiAgICAgICBPU1BGIHBhY2tldHMuICBJbiBvcmRlciB0byBmYWNp bGl0YXRlIHRoaXMsIGV4cGxpY2l0bHkgbWFyayB0aGUgDQogICAgICAgSGVsbG8gcGFja2V0cywg dG8gZGlmZmVyZW50aWF0ZSB0aGVtIGZyb20gb3RoZXIgT1NQRiBwYWNrZXRzLg0KICAgICAgIE9u ZSB3YXkgb2Ygc3BlY2lhbCBtYXJraW5nIGlzIHRvIHVzZSBhIGRpZmZlcmVudCBEaWZmc2VydiAN CiAgICAgICBjb2RlcG9pbnQgZm9yIEhlbGxvIHBhY2tldHMgY29tcGFyZWQgdG8gb3RoZXIgT1NQ RiBwYWNrZXRzLg0KICAgICAgIA0KICAgKDIpIEluIHRoZSBhYnNlbmNlIG9mIHNwZWNpYWwgbWFy a2luZywgb3IgaW4gYWRkaXRpb24gdG8gaXQsIHVzZSANCiAgICAgICBvdGhlciBtZWNoYW5pc21z IGluIG9yZGVyIG5vdCB0byBtaXNzIEhlbGxvIHBhY2tldHMuIE9uZSBleGFtcGxlDQogICAgICAg aXMgdG8gdHJlYXQgYW55IHBhY2tldCByZWNlaXZlZCBvdmVyIGEgbGluayBhcyBhIHN1cnJvZ2F0 ZSBmb3INCiAgICAgICBhIEhlbGxvIHBhY2tldCAoYW4gaW1wbGljaXQgSGVsbG8pIGZvciB0aGUg cHVycG9zZSBvZiBrZWVwaW5nIA0KICAgICAgIHRoZSBsaW5rIGFsaXZlLiAgT3VyIHNpbXVsYXRp b24gc3R1ZHkgc2hvd3MgdGhhdCB0aGlzIG1lY2hhbmlzbQ0KICAgICAgIGlzIGp1c3QgYXMgZWZm ZWN0aXZlIGFzIGV4cGxpY2l0bHkgcHJpb3JpdGl6aW5nIEhlbGxvDQogICAgICAgcGFja2V0cy4N Cg0KICAgKDMpIFRoZSBzYW1lIHR5cGUgb2YgZXhwbGljaXQgbWFya2luZyBhbmQgcHJpb3JpdGl6 ZWQgdHJlYXRtZW50IG1heQ0KICAgICAgIGJlIGJlbmVmaWNpYWwgdG8gb3RoZXIgT1NQRiBwYWNr ZXRzIGFzIHdlbGwuICBPbmUgaW1wb3J0YW50IA0KICAgICAgIGV4YW1wbGUgaXMgTFNBIGFja25v d2xlZGdtZW50IHBhY2tldCB0aGF0IGNhbiByZWR1Y2UgDQogICAgICAgcmV0cmFuc21pc3Npb25z IGR1cmluZyBwZXJpb2RzIG9mIGNvbmdlc3Rpb24uICBPdXIgc2ltdWxhdGlvbg0KDQogICAgICAg ICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMTNdDQoMDQogICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICBFeHBsaWNp dCBNYXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIwMDMNCg0KDQogICAgICAgc3R1ZHkgc2hv d3MgdGhhdCBwcmlvcml0aXphdGlvbiBvZiBib3RoIEhlbGxvIGFuZCBMU0ENCiAgICAgICBBY2tu b3dsZWRnbWVudCBwYWNrZXRzIGlzIGNvbnNpZGVyYWJseSBtb3JlIGVmZmVjdGl2ZSB0aGFuDQog ICAgICAganVzdCBwcmlvcml0aXppbmcgSGVsbG8gcGFja2V0cy4gIE90aGVyIGV4YW1wbGVzIA0K ICAgICAgIGluY2x1ZGUgKGEpIERhdGFiYXNlIGRlc2NyaXB0aW9uIChEQkQpIHBhY2tldCBmcm9t IGEgc2xhdmUgdGhhdCANCiAgICAgICBpcyB1c2VkIGFzIGFuIGFja25vd2xlZGdlbWVudCwgYW5k IChiKSBMU0FzIGNhcnJ5aW5nIGludHJhLWFyZWEgDQogICAgICAgdG9wb2xvZ3kgY2hhbmdlIGlu Zm9ybWF0aW9uLg0KDQogICBJdCBpcyBwb3NzaWJsZSB0aGF0IHNvbWUgaW1wbGVtZW50YXRpb25z IGFyZSBhbHJlYWR5IHVzaW5nIG9uZSBvcg0KICAgbW9yZSBvZiB0aGUgYWJvdmUgbWVjaGFuaXNt cyBpbiBvcmRlciBub3QgdG8gbWlzcyB0aGUgcHJvY2Vzc2luZyBvZg0KICAgY3JpdGljYWwgcGFj a2V0cyBkdXJpbmcgcGVyaW9kcyBvZiBjb25nZXN0aW9uLiAgSG93ZXZlciwgd2Ugc3VnZ2VzdA0K ICAgdGhlIGFib3ZlIG1lY2hhbmlzbXMgdG8gYmUgaW5jbHVkZWQgYXMgcGFydCBvZiB0aGUgc3Rh bmRhcmQgc28gdGhhdA0KICAgYWxsIGltcGxlbWVudGF0aW9ucyBjYW4gYmVuZWZpdCBmcm9tIHRo ZW0uDQoNCg0KNy4gQWNrbm93bGVkZ21lbnRzDQoNCiAgIFdlIHdvdWxkIGxpa2UgdG8gYWNrbm93 bGVkZ2UgSmVycnkgQXNoLCBNYXJnYXJldCBDaGlvc2ksIEVsaWUgDQogICBGcmFuY2lzLCBKZWZm IEhhbiwgQmV0aCBNdW5zb24sIFJvc2hhbiBSYW8sIE1vc2hlIFNlZ2FsLCBNaWtlDQogICBXYXJk bG93LCBhbmQgUGF0IFdpcnRoIGZvciBjb2xsYWJvcmF0aW9uIGFuZCBlbmNvdXJhZ2VtZW50IGlu IA0KICAgb3VyIHNjYWxhYmlsaXR5IGltcHJvdmVtZW50IGVmZm9ydHMgZm9yIExpbmstU3RhdGUt UHJvdG9jb2wgYmFzZWQgDQogICBuZXR3b3Jrcy4gDQoNCg0KOC4gUmVmZXJlbmNlcw0KDQoNCiAg IFtSZWYxXSBQYXBwYWxhcmRvLCBELiwgIkFUJlQsIGN1c3RvbWVycyBncmFwcGxlIHdpdGggQVRN IG5ldCANCiAgIG91dGFnZSwiIE5ldHdvcmsgV29ybGQsIEZlYnJ1YXJ5IDI2LCAyMDAxLg0KDQog ICBbUmVmMl0gIkFUJlQgYW5ub3VuY2VzIGNhdXNlIG9mIGZyYW1lLXJlbGF5IG5ldHdvcmsgb3V0 YWdlLCIgQVQmVCANCiAgIFByZXNzIFJlbGVhc2UsIEFwcmlsIDIyLCAxOTk4Lg0KDQogICBbUmVm M10gQ2hvbGV3a2EsIEsuLCAiTUNJIE91dGFnZSBIYXMgRG9taW5vIEVmZmVjdCwiIEludGVyQGN0 aXZlIA0KICAgV2VlaywgQXVndXN0IDIwLCAxOTk5Lg0KDQogICBbUmVmNF0gSmFuZGVyLCBNLiwg IkluIFF3ZXN0IE91dGFnZSwgQVRNIFRha2VzIFNvbWUgSGVhdCwiIExpZ2h0DQogICBSZWFkaW5n LCBBcHJpbCA2LCAyMDAxLg0KDQogICBbUmVmNV0gQy4gQWxhZXR0aW5vZ2x1LCBWLiBKYWNvYnNv biBhbmQgSC4gWXUsICJUb3dhcmRzIE1pbGxpLQ0KICAgc2Vjb25kIElHUCBDb252ZXJnZW5jZSwi IFdvcmsgaW4gUHJvZ3Jlc3MuDQoNCiAgIFtSZWY2XSBBLiBaaW5pbiBhbmQgTS4gU2hhbmQsICJG bG9vZGluZyBPcHRpbWl6YXRpb25zIGluIExpbmstU3RhdGUNCiAgIFJvdXRpbmcgUHJvdG9jb2xz LCIgV29yayBpbiBQcm9ncmVzcy4NCg0KICAgW1JlZjddIEouIE1veSwgIkZsb29kaW5nIG92ZXIg UGFyYWxsZWwgUG9pbnQtdG8tUG9pbnQgTGlua3MsIiBXb3JrIGluDQogICBwcm9ncmVzcy4NCg0K ICAgW1JlZjhdIFAuIFBpbGxheS1Fc25hdWx0LCAiT1NQRiBSZWZyZXNoIGFuZCBmbG9vZGluZyBy ZWR1Y3Rpb24gaW4gIA0KDQogICAgICAgICAgDQogICBDaG91ZGh1cnkgZXQuIGFsLiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQogICBJbnRlcm5l dCBEcmFmdCAgICAgICAgICBFeHBsaWNpdCBNYXJraW5nICAgICAgICAgICAgICAgICBNYXksIDIw MDMNCg0KDQogICBzdGFibGUgdG9wb2xvZ2llcywiIFdvcmsgaW4gcHJvZ3Jlc3MuDQoNCiAgIFtS ZWY5XSBHLiBDaG91ZGh1cnksIFYuIE1hbnJhbCwgIkxTQSBGbG9vZGluZyBPcHRpbWl6YXRpb24N CiAgIEFsZ29yaXRobXMgYW5kIFRoZWlyIFNpbXVsYXRpb24gU3R1ZHksIiBXb3JrIGluIHByb2dy ZXNzLg0KDQogICBbUmVmMTBdIEouIEFzaCwgRy4gQ2hvdWRodXJ5LCBWLiBTYXBvemhuaWtvdmEs IE0uIFNoZXJpZiwgQS4gIA0KICAgTWF1bmRlciwgVi4gTWFucmFsLCAiQ29uZ2VzdGlvbiBBdm9p ZGFuY2UgJiBDb250cm9sIGZvciBPU1BGIA0KICAgTmV0d29ya3MiLCBXb3JrIGluIFByb2dyZXNz Lg0KDQogICBbUmVmMTFdIEIuIE0uIFdheG1hbiwgIlJvdXRpbmcgb2YgTXVsdGlwb2ludCBDb25u ZWN0aW9ucywiIElFRUUNCiAgIEpvdXJuYWwgb24gU2VsZWN0ZWQgQXJlYXMgaW4gQ29tbXVuaWNh dGlvbnMsIDYoOSk6MTYxNy0xNjIyLCAxOTg4Lg0KDQogICANCjkuIEF1dGhvcnMnIEFkZHJlc3Nl cw0KDQogICBHYWdhbiBMLiBDaG91ZGh1cnkNCiAgIEFUJlQNCiAgIFJvb20gRDUtM0MyMQ0KICAg MjAwIExhdXJlbCBBdmVudWUNCiAgIE1pZGRsZXRvd24sIE5KLCAwNzc0OA0KICAgVVNBDQogICBQ aG9uZTogKDczMik0MjAtMzcyMQ0KICAgZW1haWw6IGdjaG91ZGh1cnlAYXR0LmNvbQ0KDQoNCiAg IFZlcmEgRC4gU2Fwb3pobmlrb3ZhDQogICBBVCZUDQogICBSb29tIEM1LTJDMjkNCiAgIDIwMCBM YXVyZWwgQXZlbnVlDQogICBNaWRkbGV0b3duLCBOSiwgMDc3NDgNCiAgIFVTQQ0KICAgUGhvbmU6 ICg3MzIpNDIwLTI2NTMNCiAgIGVtYWlsOiBzYXBvemhuaWtvdmFAYXR0LmNvbQ0KDQoNCiAgIEFu dXJhZyBTLiBNYXVuZGVyDQogICBTYW5lcmEgU3lzdGVtcw0KICAgMzcwIFNhbiBBbGVzbyBBdmUu DQogICBTZWNvbmQgRmxvb3INCiAgIFN1bm55dmFsZSwgQ0EgOTQwODUNCiAgIFBob25lOiAoNDA4 KTczNC02MTIzDQogICBlbWFpbDogYW1hdW5kZXJAc2FuZXJhLm5ldA0KDQogICBWaXNod2FzIE1h bnJhbA0KICAgTmV0UGxhbmUNCiAgIDE4OSwgUHJhc2hhc2FuIE5hZ2FyLA0KICAgUm9hZCBOdW1i ZXIgNzINCiAgIEp1YmlsZWUgSGlsbHMsIEh5ZGVyYWJhZA0KICAgSW5kaWENCiAgIGVtYWlsOiBW aXNod2FzbUBuZXRwbGFuZS5jb20NCg0KICAgQ2hvdWRodXJ5IGV0LiBhbC4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0K ------_=_NextPart_001_01C284E2.D72B5A6B-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 12:02:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29299 for ; Tue, 5 Nov 2002 12:02:11 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.007ACC51@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 12:04:38 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 319574 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 12:04:38 -0500 Received: from 198.178.8.81 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 12:04:38 -0500 Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id gA5H1Ggo012968 for ; Tue, 5 Nov 2002 10:04:34 -0700 (MST) Received: from 147.191.89.201 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Tue, 05 Nov 2002 10:04:25 -0700 X-Server-Uuid: 90826C58-91B0-45EB-95A5-46B6D42E456F Received: by entexchimc02.tci.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 5 Nov 2002 10:04:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11D92593258802-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <9496EA69116CD4119EE800508B72D03E017CED21@coexch01.broadband.att.com> Date: Tue, 5 Nov 2002 10:04:21 -0700 Reply-To: Mailing List Sender: Mailing List From: "Field, Brian" Subject: OSPF reference bandwidth To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Is the 100Mb/s reference bandwidth that's used to cost out links defined in an RFC somewhere or is this it a value informally agreed to by the vendors? I didn't see reference to this value in 2328 and didn't see any other RFCs which looked like they would specify this value. Thanks Brian From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 12:13:09 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29888 for ; Tue, 5 Nov 2002 12:13:09 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.007ACD05@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 12:15:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 319619 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 12:15:36 -0500 Received: from 192.11.222.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 12:15:36 -0500 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gA5HFY001499 for ; Tue, 5 Nov 2002 12:15:34 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 12:15:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 5 Nov 2002 12:15:31 -0500 Reply-To: Mailing List Sender: Mailing List From: "Joyal, Daniel R (Daniel)" Subject: Re: OSPF reference bandwidth To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Brian, It's in the OSPFv2 MIB, RFC 1850. See OSPF Interface Metric Table on pages 39-40. Unfortunately, with this fixed reference bandwidth, anything over 100mbps results in a cost of 1. The update to this MIB should probably add a read-write reference bandwidth object. -Dan -----Original Message----- From: Field, Brian [mailto:BField@BROADBAND.ATT.COM] Sent: Tuesday, November 05, 2002 12:04 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF reference bandwidth Is the 100Mb/s reference bandwidth that's used to cost out links defined in an RFC somewhere or is this it a value informally agreed to by the vendors? I didn't see reference to this value in 2328 and didn't see any other RFCs which looked like they would specify this value. Thanks Brian From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 13:33:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03972 for ; Tue, 5 Nov 2002 13:33:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.007AD036@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 13:35:46 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 320032 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 13:35:46 -0500 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 13:35:45 -0500 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 90E245D0ED for ; Wed, 6 Nov 2002 03:35:44 +0900 (JST) References: <20021030.205107.05507938.yasu@sfc.wide.ad.jp> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021106.033540.16907831.yasu@sfc.wide.ad.jp> Date: Wed, 6 Nov 2002 03:35:40 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: How to set the link costs ? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021030.205107.05507938.yasu@sfc.wide.ad.jp> Precedence: list Content-Transfer-Encoding: 7bit Thank you very much for replying. Below is a list of papers/works mentioned in this thread. regards, yasu - Traffic engineering with traditional IP routing protocols B. Fortz, J. Rexford and M. Thorup. IEEE Communications Magazine, 40(10):118-124, 2002. - Optimizing OSPF/IS-IS Weights in a Changing World IEEE JSAC Special Issue on Advances in Fundamentals of Network Management, Spring 2002 - Fortifying OSPF/IS-IS against link-failure Proceedings of the thirteenth annual ACM-SIAM symposium on Discrete algorithms, San Francisco, California, 2002 p838-843 - Avoiding Ties in Shortest Path Routing - Increasing Internet Capacity Using Local Search - Internet Traffic Engineering by Optimizing OSPF Weights Bernard Fortz, Mikkel Thorup INFOCOM 2000 p519-528 - Internet Traffic Engineering without Full Mesh Overlaying Wang, Wang, Zhang - Dynamic Optimization of OSPF Weights using Online Simulation Ye, ... - A New Approach to Routing With Dynamic Metrics Johnny Chen, Peter Druschel, Devika Subramanian INFOCOM 1999 p661-670 - Minimum Interference Routing with Applications to MPLS Traffic Engineering Murali S. Kodialam, T. V. Lakshman INFOCOM 2000 p884-893 - Intra-Domain TE via IGP Metric Tuning Andrew Lange NANOG 2002/06 From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 14:26:18 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07271 for ; Tue, 5 Nov 2002 14:26:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.007AD2CD@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 14:28:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 320355 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 14:28:44 -0500 Received: from 216.32.171.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 14:28:44 -0500 Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id LAA02342; Tue, 5 Nov 2002 11:25:48 -0800 (PST) References: <20021030.205107.05507938.yasu@sfc.wide.ad.jp> <20021106.033540.16907831.yasu@sfc.wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Message-ID: <20021105112548.L11673@demiurge.exodus.net> Date: Tue, 5 Nov 2002 11:25:48 -0800 Reply-To: Mailing List Sender: Mailing List From: Andrew Lange Subject: Re: How to set the link costs ? Comments: cc: andrewl@cw.net To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021106.033540.16907831.yasu@sfc.wide.ad.jp>; from yasu@SFC.WIDE.AD.JP on Wed, Nov 06, 2002 at 03:35:40AM +0900 Precedence: list I added URL's for the Wang, Wang & Zhang and the Ye, et.al. papers below. Andrew On Wed, Nov 06, 2002 at 03:35:40AM +0900, Yasuhiro Ohara wrote: > X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) > Date: Wed, 6 Nov 2002 03:35:40 +0900 > Reply-To: Mailing List > From: Yasuhiro Ohara > Subject: Re: How to set the link costs ? > To: OSPF@DISCUSS.MICROSOFT.COM > In-Reply-To: <20021030.205107.05507938.yasu@sfc.wide.ad.jp> > Precedence: list > X-Spam-Status: No, hits=-0.5 required=6.0 > tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 > version=2.43 > X-OriginalArrivalTime: 05 Nov 2002 18:35:49.0960 (UTC) FILETIME=[29E8AC80:01C284FA] > > Thank you very much for replying. > Below is a list of papers/works mentioned in this thread. > > regards, > yasu > > > - Traffic engineering with traditional IP routing protocols > B. Fortz, J. Rexford and M. Thorup. > IEEE Communications Magazine, 40(10):118-124, 2002. > > - Optimizing OSPF/IS-IS Weights in a Changing World > IEEE JSAC Special Issue on Advances in Fundamentals of > Network Management, Spring 2002 > > > - Fortifying OSPF/IS-IS against link-failure > Proceedings of the thirteenth annual ACM-SIAM symposium on > Discrete algorithms, San Francisco, California, 2002 p838-843 > > > - Avoiding Ties in Shortest Path Routing > > > - Increasing Internet Capacity Using Local Search > > > - Internet Traffic Engineering by Optimizing OSPF Weights > Bernard Fortz, Mikkel Thorup > INFOCOM 2000 p519-528 > > > - Internet Traffic Engineering without Full Mesh Overlaying > Wang, Wang, Zhang INFOCOM 2001 > > - Dynamic Optimization of OSPF Weights using Online Simulation > Ye, ... > > - A New Approach to Routing With Dynamic Metrics > Johnny Chen, Peter Druschel, Devika Subramanian > INFOCOM 1999 p661-670 > > > - Minimum Interference Routing with Applications to MPLS Traffic Engineering > Murali S. Kodialam, T. V. Lakshman > INFOCOM 2000 p884-893 > > > - Intra-Domain TE via IGP Metric Tuning > Andrew Lange > NANOG 2002/06 > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 15:18:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11028 for ; Tue, 5 Nov 2002 15:18:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007AD68E@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 15:21:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 320613 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 15:21:19 -0500 Received: from 198.178.8.81 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 15:21:18 -0500 Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id gA5KJtge027231 for ; Tue, 5 Nov 2002 13:20:52 -0700 (MST) Received: from 147.191.89.201 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Tue, 05 Nov 2002 13:20:29 -0700 X-Server-Uuid: 43374831-6ABA-4273-9165-009ABBFC7FBB Received: by entexchimc02.tci.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 5 Nov 2002 13:20:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11D6F787140334-03-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <9496EA69116CD4119EE800508B72D03E017CED31@coexch01.broadband.att.com> Date: Tue, 5 Nov 2002 13:20:23 -0700 Reply-To: Mailing List Sender: Mailing List From: "Field, Brian" Subject: Re: OSPF reference bandwidth To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Dan, Thanks for the pointer to 1850. If I'm parsing the MIB correctly, the reference value (100Mb/s) is not in the MIB, but rather the interface cost value, based on the 10^8/ifSpeed, is stored. I'm wondering if it would make sense if the MIB contained an object that holds the reference bandwidth value used to compute link costs? Further, it might be useful if the OspfIfMetricEntry where to be augmented to include an indication if ospfIfMetricValue was computed using the default value (10^8 or other default) or if the OSPF link cost value was assigned to the interface directly. Obviously, the 10^8 default value has limitations for us today. I would be convienent if we were able to reset the default reference bandwidth value (which is possible), but then to perform sanity checks via NM tools that all routers are using the same reference value. Further, we might want to verify that all interfaces costs' are derived from this references value, and those which are not, can be detected by NM tools. Thoughts? Thanks Brian ospfIfMetricValue OBJECT-TYPE SYNTAX Metric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric of using this type of service on this interface. The default value of the TOS 0 Metric is 10^8 / ifSpeed." ::= { ospfIfMetricEntry 4 } -----Original Message----- From: Joyal, Daniel R (Daniel) [mailto:joyal@LUCENT.COM] Sent: Tuesday, November 05, 2002 10:16 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF reference bandwidth Brian, It's in the OSPFv2 MIB, RFC 1850. See OSPF Interface Metric Table on pages 39-40. Unfortunately, with this fixed reference bandwidth, anything over 100mbps results in a cost of 1. The update to this MIB should probably add a read-write reference bandwidth object. -Dan -----Original Message----- From: Field, Brian [mailto:BField@BROADBAND.ATT.COM] Sent: Tuesday, November 05, 2002 12:04 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF reference bandwidth Is the 100Mb/s reference bandwidth that's used to cost out links defined in an RFC somewhere or is this it a value informally agreed to by the vendors? I didn't see reference to this value in 2328 and didn't see any other RFCs which looked like they would specify this value. Thanks Brian From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 16:45:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17083 for ; Tue, 5 Nov 2002 16:45:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.007AD8DC@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 16:47:35 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 320820 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 16:47:35 -0500 Received: from 192.11.222.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 16:47:34 -0500 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gA5LlXL20428 for ; Tue, 5 Nov 2002 16:47:33 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 16:47:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 5 Nov 2002 16:47:17 -0500 Reply-To: Mailing List Sender: Mailing List From: "Joyal, Daniel R (Daniel)" Subject: Re: OSPF reference bandwidth To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Responses inline. -Dan -----Original Message----- From: Field, Brian [mailto:BField@BROADBAND.ATT.COM] Sent: Tuesday, November 05, 2002 3:20 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF reference bandwidth Hi Dan, Thanks for the pointer to 1850. If I'm parsing the MIB correctly, the reference value (100Mb/s) is not in the MIB, but rather the interface cost value, based on the 10^8/ifSpeed, is stored. >> That's correct. The reference bandwidth is not a configurable >> parameter. I don't know how many OSPF implementations actually >> compute the default interface metric based on the above formula, >> though. I'm wondering if it would make sense if the MIB contained an object that holds the reference bandwidth value used to compute link costs? Further, it might be useful if the OspfIfMetricEntry where to be augmented to include an indication if ospfIfMetricValue was computed using the default value (10^8 or other default) or if the OSPF link cost value was assigned to the interface directly. >> I think it could be useful. I know of at least one implementation that >> supports configurable reference bandwidth. Obviously, the 10^8 default value has limitations for us today. I would be convienent if we were able to reset the default reference bandwidth value (which is possible), but then to perform sanity checks via NM tools that all routers are using the same reference value. Further, we might want to verify that all interfaces costs' are derived from this references value, and those which are not, can be detected by NM tools. Thoughts? Thanks Brian ospfIfMetricValue OBJECT-TYPE SYNTAX Metric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric of using this type of service on this interface. The default value of the TOS 0 Metric is 10^8 / ifSpeed." ::= { ospfIfMetricEntry 4 } -----Original Message----- From: Joyal, Daniel R (Daniel) [mailto:joyal@LUCENT.COM] Sent: Tuesday, November 05, 2002 10:16 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF reference bandwidth Brian, It's in the OSPFv2 MIB, RFC 1850. See OSPF Interface Metric Table on pages 39-40. Unfortunately, with this fixed reference bandwidth, anything over 100mbps results in a cost of 1. The update to this MIB should probably add a read-write reference bandwidth object. -Dan -----Original Message----- From: Field, Brian [mailto:BField@BROADBAND.ATT.COM] Sent: Tuesday, November 05, 2002 12:04 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF reference bandwidth Is the 100Mb/s reference bandwidth that's used to cost out links defined in an RFC somewhere or is this it a value informally agreed to by the vendors? I didn't see reference to this value in 2328 and didn't see any other RFCs which looked like they would specify this value. Thanks Brian From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 19:03:56 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26353 for ; Tue, 5 Nov 2002 19:03:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.007ADD89@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 19:06:23 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 321082 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 19:06:23 -0500 Received: from 64.101.210.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 18:56:22 -0500 Received: from cisco.com (sucia.cisco.com [64.101.210.69]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA07727; Tue, 5 Nov 2002 17:56:22 -0600 (CST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DC85AA3.2010505@cisco.com> Date: Tue, 5 Nov 2002 17:56:19 -0600 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: OSPFv3: question about referenced link state type To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello, I've got a question about the correct values to use in the "referenced LS type" field of the intra-area prefix LSA. The OSPFv3 implementations that I'm familiar with set this 16-bit field to either 0x2001 for a router LSA or 0x2002 for a network LSA. In each case the value includes the flooding scope bits, and is the same as would be found in the "LS type" field of the LSA header of the referenced LSA. However, a literal reading of section A.4.9 of RFC 2740 indicates that the referenced LS type should be 1 or 2. I'm wondering if other implementors would comment on what they do here, and whether this is a potential interoperability problem. Thanks. - Paul Wells From owner-ospf@DISCUSS.MICROSOFT.COM Tue Nov 5 19:34:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27865 for ; Tue, 5 Nov 2002 19:34:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.007ADFEE@cherry.ease.lsoft.com>; Tue, 5 Nov 2002 19:36:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 321164 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 5 Nov 2002 19:36:26 -0500 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 5 Nov 2002 19:36:26 -0500 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id DF7855D0AE; Wed, 6 Nov 2002 09:36:24 +0900 (JST) References: <3DC85AA3.2010505@cisco.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021106.093624.132469402.yasu@sfc.wide.ad.jp> Date: Wed, 6 Nov 2002 09:36:24 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: OSPFv3: question about referenced link state type Comments: To: pauwells@CISCO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DC85AA3.2010505@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit pauwells> However, a literal reading of section A.4.9 of RFC 2740 pauwells> indicates that the referenced LS type should be 1 or 2. pauwells> pauwells> I'm wondering if other implementors would comment on what pauwells> they do here, and whether this is a potential pauwells> interoperability problem. Current Zebra ospf6d encodes whole LS-Type including U, S1, S2 bits. I didn't noticed A.4.9, and just refered LS-Type. I think it is possible that this becomes an interoperability problem because A.4.9 specifies the value explicitly. The interoperability tests I've done so far with some other implementations did not show me any problem about this, though. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 6 08:37:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17441 for ; Wed, 6 Nov 2002 08:37:17 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.007B0FEA@cherry.ease.lsoft.com>; Wed, 6 Nov 2002 8:39:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 323648 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 6 Nov 2002 08:39:42 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 6 Nov 2002 08:29:42 -0500 Received: from antiproton.jnpr.net ([172.24.18.101]) by alpha.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 05:29:41 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Looking For An OSPFv3 book. Thread-Index: AcJ/ZEjlVQT4K0oxQkC6n42iu1jfsAGM2sJQ X-OriginalArrivalTime: 06 Nov 2002 13:29:41.0415 (UTC) FILETIME=[8FD0E370:01C28598] Message-ID: <5B671CEC7A3CDA40BA4A8B081D7B046C03FF3383@antiproton.jnpr.net> Date: Wed, 6 Nov 2002 05:29:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Jeff Doyle Subject: Re: Looking For An OSPFv3 book. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA17441 Hello Hatem, I don't know of any book currently on the market on OSPFv3. I am currently writing a book that covers both v2 and v3, but it will not be out until next summer-- not useful to you if you need immediate information. I suggest, however, just reading RF 2740. If you are reasonably familiar with v2, the RFC does a good job in secdtion 2 of summarizing the differences of v3 from v2. Best regards, Jeff Doyle > Hi, > I'm looking for a book which explains OSPFv3. I have looked > around and so far I found books only for OSPFv2. Any suggestions? > > Thanks in advance for your help, > Hatem > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 6 10:33:18 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26947 for ; Wed, 6 Nov 2002 10:33:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.007B2C90@cherry.ease.lsoft.com>; Wed, 6 Nov 2002 10:35:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 324885 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 6 Nov 2002 10:35:36 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 6 Nov 2002 10:35:36 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 7556824606D for ; Wed, 6 Nov 2002 07:35:28 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050808040106070009090803" Message-ID: <3DC93669.6050404@redback.com> Date: Wed, 6 Nov 2002 10:34:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF Hitless Restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------050808040106070009090803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've attached draft-ietf-ospf-hitless-restart-04.txt with the changes discussed in my previous E-mail. --- Acee --------------050808040106070009090803 Content-Type: text/plain; name="draft-ietf-ospf-hitless-restart-04.txt" Content-Disposition: inline; filename="draft-ietf-ospf-hitless-restart-04.txt" Content-Transfer-Encoding: 7bit Network Working Group J. Moy (Sycamore Networks) Internet Draft Padma Pillay-Esnault (Juniper Networks) Expiration Date: April 2003 Acee Lindem, Editor (Redback Networks) File name: draft-ietf-ospf-hitless-restart-04.txt October 2002 Hitless OSPF Restart draft-ietf-ospf-hitless-restart-04.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called "hitless restart" or "non-stop forwarding". A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a hitless restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented. Moy, Pillay-Esnault, Lindem [Page 1] Internet Draft Hitless OSPF Restart October 2002 Table of Contents 1 Overview ............................................... 2 1.1 Acknowledgments ........................................ 3 2 Operation of restarting router ......................... 3 2.1 Entering hitless restart ............................... 4 2.2 When to exit hitless restart ........................... 5 2.3 Actions on exiting hitless restart ..................... 6 3 Operation of helper neighbor ........................... 6 3.1 Entering helper mode ................................... 7 3.2 Exiting helper mode .................................... 8 4 Backward compatibility ................................. 9 5 Unplanned outages ...................................... 9 6 Interaction with Traffic Engineering .................. 10 7 Possible Future Work .................................. 10 References ............................................ 10 A Grace-LSA format ...................................... 11 B Change log ............................................ 13 Security Considerations ............................... 14 Authors' Addresses .................................... 14 1. Overview Today many Internet routers implement a separation of control and forwarding functions. Certain processors are dedicated to control and management tasks such as OSPF routing, while other processors perform the data forwarding tasks. This separation creates the possibility of maintaining a router's data forwarding capability while the router's control software is restarted/reloaded. We call such a possibility "hitless restart" or "non-stop forwarding". The problem that the OSPF protocol presents to hitless restart is that, under normal operation, OSPF intentionally routes around a restarting router while it rebuilds its link-state database. OSPF avoids the restarting router to minimize the possibility of routing loops and/or black holes caused by lack of database synchronization. Avoidance is accomplished by having the router's neighbors reissue their LSAs, omitting links to the restarting router. However, if (a) the network topology remains stable and (b) the restarting router is able to keep its forwarding table(s) across the restart, it would be safe to keep the restarting router on the forwarding path. This memo documents an enhancement to OSPF that makes such hitless restart possible, and one that automatically reverts back to a standard OSPF restart for safety when network topology changes are detected. In a nutshell, the OSPF enhancements for hitless restart are as follows. The router attempting a hitless restart originates link- Moy, Pillay-Esnault, Lindem [Page 2] Internet Draft Hitless OSPF Restart October 2002 local Opaque-LSAs, herein called Grace-LSAs, announcing the intention to perform a hitless restart, and asking for a "grace period". During the grace period its neighbors continue to announce the restarting router in their LSAs as if it were fully adjacent (i.e., OSPF neighbor state Full), but only if the network topology remains static (i.e, the contents of the LSAs in the link-state database having LS types 1-5,7 remain unchanged; periodic refreshes are allowed). There are two roles being played by OSPF routers during hitless restart. First there is the router that is being restarted. The operation of this router during hitless restart, including how the router enters and leaves hitless restart, is the subject of Section 2. Then there are the router's neighbors, which must cooperate in order for the restart to be hitless. During hitless restart we say that the neighbors are executing in "helper mode". Section 3 covers the responsibilities of a router executing in helper mode, including entering and leaving helper mode. 1.1. Acknowledgments The authors wish to thank John Drake, Vishwas Manral, Kent Wong and Don Goodspeed for their helpful comments. 2. Operation of restarting router After the router restarts/reloads, it must change its OSPF processing somewhat until it re-establishes full adjacencies with all its previously fully-adjacent neighbors. This time period, between the restart/reload and the reestablishment of adjacencies, is called "hitless restart". During hitless restart: (1) The restarting router does not originate LSAs with LS types 1-5,7. Instead, the restarting router wants the other routers in the OSPF domain to calculate routes using the LSAs that it had originated prior to its restart. During this time, the restarting router does not modify or flush received self- originated LSAs, (see Section 13.4 of [1]) but instead accepts them as valid. In particular, the grace-LSAs that the restarting router had originated before the restart are left in place. Received self-originated LSAs will be dealt with when the router exits hitless restart (see Section 2.3). (2) The restarting router runs its OSPF routing calculations, as specified in Section 16 of [1]. This is necessary to return any OSPF virtual links to operation. However, the restarting router does *not* install OSPF routes into the system's forwarding table(s), instead relying on the forwarding entries that it had installed prior to the restart. Moy, Pillay-Esnault, Lindem [Page 3] Internet Draft Hitless OSPF Restart October 2002 (3) If the restarting router determines that it was Designated Router on a given segment immediately prior to the restart, it elects itself as Designated Router again. The restarting router knows that it was Designated Router if, while the associated interface is in Waiting state, an Hello packet is received from a neighbor listing the router as Designated Router. Otherwise, the restarting router operates the same as any other OSPF router. It discovers neighbors using OSPF's Hello protocol, elects Designated and Backup Designated Routers, performs the Database Exchange procedure to initially synchronize link-state databases with its neighbors, and maintains this synchronization through flooding. The processes of entering hitless restart, and of exiting hitless restart (either successfully or not) are covered in the following sections. 2.1. Entering hitless restart The router (call it Router X) is informed of the desire for its hitless restart when an appropriate command is issued by the network operator. The network operator may also specify the length of the grace period, or the necessary grace period may be calculated by the router's OSPF software. In order to avoid the restarting router's LSAs from aging out, the grace period should not exceed LSRefreshTime (1800 second) [1]. In preparation for the hitless restart, Router X must perform the following actions before its software is restarted/reloaded. Note that common OSPF shutdown procedures are *not* performed, since we want the other OSPF routers to act as if Router X remains in continuous service. For example, Router X does not flush its locally originated LSAs, since we want them to remain in other routers' link-state databases throughout the restart period. (1) Router X must ensure that its forwarding table(s) is/are up-to-date and will remain in place across the restart. (2) The router must note in non-volatile storage the cryptographic sequence numbers being used for each interface. An alternative is to use the router's clock for cryptographic sequence number generation and ensure the clock is preserved across restarts (either on the same or redundant route processors). If neither of these can be guarenteed, it can take up to RouterDeadInterval seconds after the restart before adjacencies can be reestablished and this would force the grace period to be lengthened severely. Moy, Pillay-Esnault, Lindem [Page 4] Internet Draft Hitless OSPF Restart October 2002 Router X then originates the grace-LSAs. These are link-local Opaque-LSAs (see Appendix A). Their LS Age field is set to 0, and the requested grace period (in seconds) is inserted into the body of the grace-LSA. The precise contents of the grace-LSA are described in Appendix A. A grace-LSA is originated for each of the router's OSPF interfaces. If Router X wants to ensure that its neighbors receive the grace-LSAs, it should retransmit the grace-LSAs until they are acknowledged (i.e, perform standard OSPF reliable flooding of the grace-LSAs). If one or more fully adjacent neighbors do not receive grace-LSAs, they will more than likely cause premature termination of the hitless restart procedure (see Section 4). After the grace-LSAs have been sent, the router should store the fact that it is performing hitless restart along with the length of the requested grace period in non-volatile storage. (Note to implementors: It may be easiest to simply store the absolute time of the end of the grace period). The OSPF software should then be restarted/reloaded, and when the reloaded software starts executing the hitless restart modifications in Section 2 above are followed. (Note that prior to the restart, the router does not know whether its neighbors are going to cooperate as "helpers"; the mere reception of grace-LSAs does not imply acceptance of helper responsibilities. This memo assumes that the router would want to restart anyway, even if the restart is not going to be hitless). 2.2. When to exit hitless restart A Router X exits hitless restart when any of the following occurs: (1) Router X has reestablished all its adjacencies. Router X can determine this by examining the router-LSAs that it had last originated before the restart (called the "pre- restart router-LSA"), and, on those segments where the router is Designated Router, the pre-restart network- LSAs. These LSAs will have been received from the helping neighbors, and need not have been stored in non-volatile storage across the restart. All previous adjacencies will be listed as type-1 and type 2 links in the router-LSA, and as neighbors in the body of the network-LSA. (2) Router X receives an LSA that is inconsistent with its pre-restart router-LSA. For example, X receives a router- LSA originated by router Y that does not contain a link Moy, Pillay-Esnault, Lindem [Page 5] Internet Draft Hitless OSPF Restart October 2002 to X, even though X's pre-start router-LSA did contain a link to Y. This indicates that either a) Y does not support hitless restart, b) Y never received the grace- LSA or c) Y has terminated its helper mode for some reason (Section 3.2). (3) The grace period expires. 2.3. Actions on exiting hitless restart On exiting "hitless restart", the reloaded router reverts back to completely normal OSPF operation, reoriginating LSAs based on the router's current state and updating its forwarding table(s) based on the current contents of the link-state database. In particular, the following actions should be performed when exiting, either successfully or unsuccessfully, hitless restart. (1) The router should reoriginate its router-LSAs for all attached areas, to make sure they have the correct contents. (2) The router should reoriginate network-LSAs on all segments where it is Designated Router. (3) The router reruns its OSPF routing calculations (Section 16 of [1]), this time installing the results into the system forwarding table, and originating summary-LSAs, Type-7 LSAs and AS-external-LSAs as necessary. (4) Any remnant entries in the system forwarding table that were installed before the restart, but that are no longer valid, should be removed. (5) Any received self-originated LSAs that are no longer valid should be flushed. (6) Any grace-LSAs that the router had originated should be flushed. 3. Operation of helper neighbor The helper relationship is per network segment. As a "helper neighbor" on a segment S for a restarting router X, router Y has several duties. It monitors the network for topology changes, and as long as there are none, continues to its advertise its LSAs as if X had remained in continuous OSPF operation. This means that Y's LSAs continue to list an adjacency to X over network segment S, regardless of the adjacency's current synchronization state. This Moy, Pillay-Esnault, Lindem [Page 6] Internet Draft Hitless OSPF Restart October 2002 logic affects the contents of both router-LSAs and network-LSAs, and also depends on the type of network segment S (see Sections 12.4.1.1 through 12.4.1.5 and Section 12.4.2 of [1]). When helping over a virtual link, the helper must also continue to set bit V in its router-LSA for the virtual link's transit area (Section 12.4.1 of [1]). Also, if X was the Designated Router on network segment S when the helping relationship began, Y maintains X as Designated router until the helping relationship is terminated. 3.1. Entering helper mode When a router Y receives a grace-LSA from router X, it enters helper mode for X, on the associated network segment, as long as all the following checks pass: (1) Y currently has a full adjacency with X (neighbor state Full) over the associated network segment. On broadcast, NBMA and Point-to-MultiPoint segments, the neighbor relationship with X is identified by the IP interface address in the body of the grace-LSA (see Appendix A). On all other segment types X is identified by the grace- LSA's Advertising Router field. (2) There have been no changes in content to the link-state database (LS types 1-5,7) since router X restarted. This is determined as follows. Router Y examines the link- state retransmission list for X over the associated network segment. If there are any LSAs with LS types 1-5,7 on the list, then they all must be periodic refreshes. If there are instead LSAs on the list whose contents have changed (see Section 3.3 of [8]), Y must refuse to enter helper mode. (3) The grace period has not yet expired. This means that the LS age of the grace-LSA is less than the grace period specified in the body of the grace-LSA (Appendix A). (4) Local policy allows Y to act as the helper for X. Examples of configured policies might be a) never act as helper, b) never allow the grace period to exceed a Time T, c) only help on software reloads/upgrades, or d) never act as a helper for certain specific routers (specified by OSPF Router ID). There is one exception to the above requirements. If Y was already helping X on the associated network segment, the new Moy, Pillay-Esnault, Lindem [Page 7] Internet Draft Hitless OSPF Restart October 2002 grace-LSA should be accepted and the grace period should be updated accordingly. Note that Router Y may be helping X on some network segments, and not on others. However, that circumstance will probably lead to the premature termination of X's hitless restart, as Y will not continue to advertise adjacencies on the segments where it is not helping (see Section 2.2). A single router is allowed to simultaneously serve as a helper for multiple restarting neighbors. 3.2. Exiting helper mode Router Y ceases to perform the helper function for its neighbor Router X on a given segment when one of the following events occurs. (1) The grace-LSA originated by X on the segment is flushed. This is the successful termination of hitless restart. (2) The grace-LSA's grace period expires. (3) A change in link-state database contents indicates a network topology change, which forces termination of a hitless restart. Specifically, if router Y installs a new LSA in its database with LS types 1-5,7 and having the following two properties, it should cease helping X. The two properties of the LSA are a) the contents of the LSA have changed; this includes LSAs with no previous link-state database instance and the flushing of LSAs from the database, but excludes periodic LSA refreshes (see Section 3.3 of [8]), and b) the LSA would have been flooded to X, had Y and X been fully adjacent. As an example of the second property, if Y installs a changed AS-external-LSA, it should not terminate a helping relationship with a neighbor belonging to a stub area, as that neighbor would not see the AS-external-LSA in any case. An implementation MAY provide a configuration option to disable link-state database options from terminating hitless restart. Such an option will, however, increase the risk of routing loops and black holes. When router Y exits helper mode for X on a given network segment, it reoriginates its LSAs based on the current state of its adjacency to Router X over the segment. In detail, Y takes the following actions: (a) Y recalculates the Designated Router for the segment, (b) Y reoriginates its router-LSA for the segment's OSPF area, (c) if Y is Designated Router for the segment, it reoriginates the network-LSA for the segment and (d) if the segment was a virtual link, Y reoriginates its router-LSA Moy, Pillay-Esnault, Lindem [Page 8] Internet Draft Hitless OSPF Restart October 2002 for the virtual link's transit area. 4. Backward compatibility Backward-compatibility with unmodified OSPF routers is an automatic consequence of the functionality documented above. If one or more neighbors of a router requesting hitless restart are unmodified, or if they do not received the grace-LSA, the hitless restart converts to a normal OSPF restart. The unmodified routers will start routing around the restarted router X as it performs initial database synchronization, by reissuing their LSAs with links to X omitted. These LSAs will be interpreted by helper neighbors as a topology change, and by X as an LSA inconsistency, in either case reverting to normal OSPF operation. 5. Unplanned outages The hitless restart mechanisms in this memo can be used for unplanned outages. (Examples of unplanned outages include the crash of a router's control software, an unexpected switchover to a redundant control processor, etc). However, implementors and network operators should note that attempting hitless restart from an unplanned outage may not be a good idea, owing to the router's inability to properly prepare for the restart (see Section 2.1). In particular, it seems unlikely that a router could guarantee the sanity of its forwarding table(s) across an unplanned restart. In any event, implementors providing the option to recover hitlessly from unplanned outages must allow a network operator to turn the option off. In contrast to the procedure for planned restart/reloads that was described in Section 2.1, a router attempting hitless restart after an unplanned outage must originate grace-LSAs *after* its control software resumes operation. The following points must be observed during this grace-LSA origination. o The grace-LSAs must be originated and sent *before* the restarted router sends any OSPF Hello Packets. On broadcast networks, this LSA must be flooded to the AllSPFRouters multicast address (224.0.0.5) since the restarting router is not aware of its previous DR state. o The grace-LSAs are encapsulated in Link State Update Packets and sent out all interfaces, even though the restarted router has no adjacencies and no knowledge of previous adjacencies. o To improve the probability that grace-LSAs be delivered, an implementation may send them a number of times (see for example the Robustness Variable in [8]). Moy, Pillay-Esnault, Lindem [Page 9] Internet Draft Hitless OSPF Restart October 2002 o The restart reason in the grace-LSAs must be set to unknown(0). This enables the neighbors to decide whether they want to help the router through an unplanned restart. 6. Interaction with Traffic Engineering The operation of the Traffic Engineering Extensions to OSPF [4] during OSPF Hitless Restart is specified in [6]. 7. Possible Future Work Devise a less conservative algorithm for graceful restart helper termination that provides a comparable level of black hole and routing loop avoidance. Normative References [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. Informative References [3] Murphy, S., M. Badger and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. [4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering Extensions to OSPF", work in progress. [5] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA Option", work in progress. [6] Kompella, K., et. al., "Routing Extensions in Support of Generalized MPLS", work in progress. [7] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995. [8] Fenner, W., "Internet Group Membership Protocol, Version 2", RFC 2236, November 1997. Moy, Pillay-Esnault, Lindem [Page 10] Internet Draft Hitless OSPF Restart October 2002 A. Grace-LSA format The grace-LSA is a link-local scoped Opaque-LSA [2] having Opaque Type of 3 and Opaque ID equal to 0. Grace-LSAs are originated by a router that wishes to execute a hitless restart of its OSPF software. A grace-LSA requests that the router's neighbors aid it in its hitless restart by continuing to advertise the router as fully adjacent during a specified grace period. Each grace-LSA has LS age field set to 0 when the LSA is first originated; the current value of LS age then indicates how long ago the restarting router made its request. The body of the LSA is TLV- encoded. The TLV-encoded information includes the length of the grace period, the reason for the hitless restart and, when the grace-LSA is associated with a broadcast, NBMA or Point-to- MultiPoint network segment, the IP interface address of the restarting router. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- TLVs -+ | ... | The format of the TLVs within the body of a grace-LSA is the same as the TLV format used by the Traffic Engineering Extensions to OSPF [4]. The TLV header consists of a 16-bit Type field and a 16-bit length field, and is followed by zero or more bytes of value. The length field indicates the length of the value portion in bytes. The value portion is padded to four-octet alignment, but the padding is not included in the length field. For example, a one byte value would have the length field set to 1, and three bytes of padding would be added to the end of the value portion of the TLV. The following is the list of TLVs that can appear in the body of a grace-LSA. Moy, Pillay-Esnault, Lindem [Page 11] Internet Draft Hitless OSPF Restart October 2002 o Grace Period (Type=1, length=4). The number of seconds that the router's neighbors should continue to advertise the router as fully adjacent, regardless of the the state of database synchronization between the router and its neighbors. Since this time period began when grace-LSA's LS age was equal to 0, the grace period terminates when either a) the LS age of the grace- LSA exceeds the value of Grace Period or b) the grace-LSA is flushed. See Section 3.2 for other conditions which terminate the grace period. This TLV must always appear in a grace-LSA. o Hitless restart reason (Type=2, length=1). Encodes the reason for the router restart, as one of the following: 0 (unknown), 1 (software restart), 2 (software reload/upgrade) or 3 (switch to redundant control processor). This TLV must always appear in a grace-LSA. o IP interface address (Type=3, length=4). The router's IP interface address on the subnet associated with the grace-LSA. Required on broadcast, NBMA and Point-to-MultiPoint segments, where the helper uses the IP interface address to identify the restarting router (see Section 3.1). DoNotAge is never set in a grace-LSA, even if the grace-LSA is flooded over a demand circuit [7]. This is because the grace-LSA's LS age field is used to calculate the extent of the grace period. Grace-LSAs have link-local scope because they only need to be seen by the router's direct neighbors. Moy, Pillay-Esnault, Lindem [Page 12] Internet Draft Hitless OSPF Restart October 2002 B. Change Log (To be removed prior to publication) Changes from 02 to 03 version: 1. Add Padma Pillay-Esnault and Acee Lindem as authors to help finish up the draft. Changes from 03 to 04 version: 1. Add change log (Appendix B). 2. Document that the grace period is restricted to LSRefreshTime (Section 2.1). 3. Document an alternative to saving cryptographic sequence numbers in non-volatile storage (Section 2.1). 4. Document that an implementation may disable graceful restart helper termination when the link-state database changes (Section 3.2). 5. In the case of an unplanned restart, document that grace LSAs should be flooded to AllSPFRouters on broadcast networks (Section 5). 6. Remove MOSPF from future work. Add Vishwas's suggested technique for less conservative helper mode termination as possible future work (Section 7). 7. Change references and citations to meet prevailing IETF standards. Moy, Pillay-Esnault, Lindem [Page 13] Internet Draft Hitless OSPF Restart October 2002 Security Considerations One of the ways to attack a link-state protocol such as OSPF is to inject false LSAs into, or corrupt existing LSAs in, the link-state database. Injecting a false grace-LSA would allow an attacker to spoof a router that, in reality, has been withdrawn from service. The standard way to prevent such corruption of the link-state database is to secure OSPF protocol exchanges using the Cryptographic authentication specified in [1]. An even stronger way of securing link-state database contents has been proposed in [3]. Authors' Addresses J. Moy Sycamore Networks, Inc. 150 Apollo Drive Chelmsford, MA 01824 Phone: (978) 367-2505 Fax: (978) 256-4203 email: jmoy@sycamorenet.com Padma Pillay-Esnault Juniper Networks 1194 N, Mathilda Avenue Sunnyvale, CA 94089-1206 Email: padma@juniper.net Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 Email: acee@redback.com Moy, Pillay-Esnault, Lindem [Page 14] --------------050808040106070009090803-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 6 10:40:12 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27303 for ; Wed, 6 Nov 2002 10:40:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007B2D7E@cherry.ease.lsoft.com>; Wed, 6 Nov 2002 10:42:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 324923 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 6 Nov 2002 10:42:39 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 6 Nov 2002 10:42:39 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id CAB77167CC1 for ; Wed, 6 Nov 2002 07:42:37 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070502070705080505040701" Message-ID: <3DC93816.9000806@redback.com> Date: Wed, 6 Nov 2002 10:41:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Updated OSPF WG Agenda To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------070502070705080505040701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The updated agenda is attached. -- Acee & Rohit --------------070502070705080505040701 Content-Type: text/plain; name="ospf-wg-agenda.txt" Content-Disposition: inline; filename="ospf-wg-agenda.txt" Content-Transfer-Encoding: 7bit Open Shortest Path First WG (OSPF) Thursday, November 12 at 1530-1730 ================================= CHAIRS: Rohit Dube Acee Lindem AGENDA: Agenda Bashing 5 Mins WG document status and Charter Update 15 Mins Chairs Extensions to IS-IS and OSPF for Advertising 10 Mins Rahul Aggarwal Optional Router Capabilities OSPFv3 Traffic Engineering Extensions 15 Mins Kunihiro Ishiguro OSPFv2 Opaques in OSPFv3 10 Mins Kireeti Kompella Congestion Avoidance & Control for 10 Mins Jerry Ash OSPF Neworks Explicit Marking and Prioritized Treatment 10 Mins Gagan L. Choudhury of Specific OSPF Packets for Faster Convergence and Improved Network Scalability and Stability LSA Flooding Optimization Algorithms and 10 Mins Gagan L. Choudhury Their Simulation Study OSPF Hitless Restart Update 5 Mins Acee Lindem - 04 version posted to list --------------070502070705080505040701-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 6 14:54:34 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09536 for ; Wed, 6 Nov 2002 14:54:26 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.007B4929@cherry.ease.lsoft.com>; Wed, 6 Nov 2002 14:56:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 326284 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 6 Nov 2002 14:56:40 -0500 Received: from 171.71.163.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 6 Nov 2002 14:46:39 -0500 Received: from mira-sjcd-3.cisco.com (IDENT:mirapoint@mira-sjcd-3.cisco.com [171.69.2.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA6Jkcot004766 for ; Wed, 6 Nov 2002 11:46:38 -0800 (PST) Received: from cisco.com (sjc-vpn2-693.cisco.com [10.21.114.181]) by mira-sjcd-3.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAR50383; Wed, 6 Nov 2002 11:26:27 -0800 (PST) X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 References: <3DC85AA3.2010505@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3DC96E17.28449672@cisco.com> Date: Wed, 6 Nov 2002 11:31:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: OSPFv3: question about referenced link state type To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Paul, In section 3.4.3.7 there are a number of references that indicate to set Referenced LS Type to 0x2001 or 0x2002. I think all of the implementations go by that. Also, in A.4.9 it doesn't say *to* set the Referenced LS Type to 1 or 2, it says that if the Referenced LS Type *is* set to 1 then it refers to a Router LSA, and if it *is* set to 2 then it refers to a Network LSA. This is a subtle difference, but makes a difference in the interpretation, so we can say there isn't a conflict. Regards, Michael Paul Wells wrote: > > Hello, > > I've got a question about the correct values to use in the "referenced > LS type" field of the intra-area prefix LSA. > > The OSPFv3 implementations that I'm familiar with set this 16-bit field > to either 0x2001 for a router LSA or 0x2002 for a network LSA. In each > case the value includes the flooding scope bits, and is the same as > would be found in the "LS type" field of the LSA header of the > referenced LSA. > > However, a literal reading of section A.4.9 of RFC 2740 indicates that > the referenced LS type should be 1 or 2. > > I'm wondering if other implementors would comment on what they do here, > and whether this is a potential interoperability problem. > > Thanks. > > - Paul Wells -- Michael Barnes Core IP Eng - Routing 408-525-2785 From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 6 15:38:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11321 for ; Wed, 6 Nov 2002 15:38:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.007B4AA5@cherry.ease.lsoft.com>; Wed, 6 Nov 2002 15:41:25 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 326414 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 6 Nov 2002 15:41:25 -0500 Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 6 Nov 2002 15:41:24 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA6JwaDw011872 for ; Wed, 6 Nov 2002 15:41:23 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B560500FA1764; Wed, 6 Nov 2002 15:41:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: OSPF WG Charter Proposal Thread-Index: AcJ/fClyA4rkasndTdG7re9FGZq6nAGUHbAQ Message-ID: <28F05913385EAC43AF019413F674A01701B65690@OCCLUST04EVS1.ugd.att.com> Date: Wed, 6 Nov 2002 15:41:20 -0500 Reply-To: Mailing List Sender: Mailing List From: "Ash, Gerald R (Jerry), ALASO" Subject: Re: OSPF WG Charter Proposal Comments: To: rohit@xebeo.com, Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA11321 Rohit, Acee, From the (consolidated) thread so far: Rohit/Acee> Here is a strawman of the Charter. Please have a look at and send Rohit/Acee> any comments you may have to me or Acee or to the list. Venkata> Can you consider "Flooding Optimizations" into charter? Venkata> If not, can you please explain the reason, why we should not? Venkata> This is field of its own - we might expect lot of drafts. Rohit> We considered this but would like to see some operational requirements Rohit> before including this in the charter. Is anybody running OSPF networks Rohit> hitting this problem with no workarounds in sight? Rohit> It would be a candidate for a future version of the charter once some Rohit> of the current items clear. Vishwas> I do think it can be helpful in a few cases. A recent paper by Aman Vishwas> Shaikh/Albert Greenberg et.al. about analyzing OSPF for Enterprise Vishwas> is one such case. Vishwas> One of our drafts "Congestion Avoidance and Control for OSPF networks" Vishwas> talks about problems that have been caused by flooding overload in Vishwas> production networks. Rohit> I am familiar with Aman's work. The problem identified there was Rohit> that of (a) sub-optimal network/ospf configuration and (b) Rohit> broken router. Rohit> This does not of course justify building new protocol mechanisms, Rohit> thereby complicating the protocol. Rohit> I will look at the congestion again to see if/why it concludes otherwise. We would like to see OSPF 'congestion control' included into the OSPF charter, where 'flooding optimizations' is a key component as discussed in our draft http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt. We can propose a workplan/goals/milestones if you'd like. Several other drafts identify needs related to OSPF congestion control: http://ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt http://www.ietf.org/internet-drafts/draft-choudhury-manral-flooding-simulation-00.txt http://www.ietf.org/internet-drafts/draft-dovolsky-ccamp-ospf-limited-flooding-00.txt AT&T has suffered a few massive failures of operational networks due to control overloads of link-state (LS) protocols ('OSPF', 'PNNI', etc.). These outages are documented and referenced in our draft (and in http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-02.txt). In the instances cited, the link-state protocol overwhelmed the network with a control load 'storm' ('LSA overload'), which brought the network down, and then prevented its recovery. Fortunately such failures are very rare; however, 'rare' for such events is unacceptable, 'never' is the goal. Other service providers have experienced similar outages caused by similar problems. Such failures are not the fault of the service provider operation or the vendor/equipment implementation. They are due to shortcomings in the link-state protocols themselves -- thus the need for the enhancements proposed in the draft. The proposals in http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt will prevent such events from being triggered, and/or provide recovery mechanisms in case such events occur. The problem of control overload is becoming even more acute as LS protocols are enhanced to support new capabilities, such as: MPLS traffic engineering http://search.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt, GMPLS http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-08.txt, multi-area TE http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt, MPLS/DiffServ TE http://search.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-06.txt, etc. With this ever advancing complexity, the need keeps increasing to address the stated problem, soon. Thus the need for the charter item on OSPF congestion control. Thanks, Jerry Ash From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 6 16:48:34 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14071 for ; Wed, 6 Nov 2002 16:48:33 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.007B4DAB@cherry.ease.lsoft.com>; Wed, 6 Nov 2002 16:50:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 326582 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 6 Nov 2002 16:50:58 -0500 Received: from 204.127.198.38 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 6 Nov 2002 16:50:58 -0500 Received: from rwcrwbc56 ([204.127.198.45]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021106215058.BCTY13074.rwcrmhc51.attbi.com@rwcrwbc56> for ; Wed, 6 Nov 2002 21:50:58 +0000 Received: from [12.146.158.112] by rwcrwbc56; Wed, 06 Nov 2002 21:50:57 +0000 X-Mailer: AT&T Message Center Version 1 (Aug 12 2002) Message-ID: <20021106215058.BCTY13074.rwcrmhc51.attbi.com@rwcrwbc56> Date: Wed, 6 Nov 2002 21:50:57 +0000 Reply-To: Mailing List Sender: Mailing List From: Manohar Naidu Ellanti Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Jerry, your comment - "Fortunately such failures are very rare; however, 'rare' for such events is unacceptable, 'never' is the goal. Other service providers have experienced similar outages caused by similar problems." is very apt. You have probably the most qualifying experience to talk about control protocol. I would like to raise the following questions - OSPF as it is , is it suitable to advertise auxiliary information - is the network model right ? spoke and wheel as opposed to hierarchical model. -can the protocol be simplified ; it is becoming too monolithic If you look at SS7 there is clear seperation of applications from signaling protocol- comparison of OSPF to SS7 may not make sense but if you look #7 architecturally - ISUP, TUP etc are applications on top of signaling/control protocl. I have asked long time back about breaking the monilithic function of OSPF into applications/seperate functions that can use the OSPF basic services rather than the applicaitons being part of OSPF itself. But no body seems to be interested or it is too late. If applications and their information elements (TLVs) are seperated from OSPF it woul be feasible to reduce OSPF LSA congestion as the LSDB itself will be segmented or the information stored in LSDB can migrate to the applications themselves. Just my opinions. -ellanti > Rohit, Acee, > > From the (consolidated) thread so far: > > Rohit/Acee> Here is a strawman of the Charter. Please have a look at and send > Rohit/Acee> any comments you may have to me or Acee or to the list. > > Venkata> Can you consider "Flooding Optimizations" into charter? > Venkata> If not, can you please explain the reason, why we should not? > Venkata> This is field of its own - we might expect lot of drafts. > > Rohit> We considered this but would like to see some operational requirements > Rohit> before including this in the charter. Is anybody running OSPF networks > Rohit> hitting this problem with no workarounds in sight? > Rohit> It would be a candidate for a future version of the charter once some > Rohit> of the current items clear. > > Vishwas> I do think it can be helpful in a few cases. A recent paper by Aman > Vishwas> Shaikh/Albert Greenberg et.al. about analyzing OSPF for Enterprise > Vishwas> is one such case. > Vishwas> One of our drafts "Congestion Avoidance and Control for OSPF networks" > Vishwas> talks about problems that have been caused by flooding overload in > Vishwas> production networks. > > Rohit> I am familiar with Aman's work. The problem identified there was > Rohit> that of (a) sub-optimal network/ospf configuration and (b) > Rohit> broken router. > Rohit> This does not of course justify building new protocol mechanisms, > Rohit> thereby complicating the protocol. > Rohit> I will look at the congestion again to see if/why it concludes otherwise. > > We would like to see OSPF 'congestion control' included into the OSPF charter, > where 'flooding optimizations' is a key component as discussed in our draft > http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00. > txt. We can propose a workplan/goals/milestones if you'd like. > > Several other drafts identify needs related to OSPF congestion control: > http://ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt > http://www.ietf.org/internet-drafts/draft-choudhury-manral-flooding-simulation-0 > 0.txt > http://www.ietf.org/internet-drafts/draft-dovolsky-ccamp-ospf-limited-flooding-0 > 0.txt > > AT&T has suffered a few massive failures of operational networks due to control > overloads of link-state (LS) protocols ('OSPF', 'PNNI', etc.). These outages > are documented and referenced in our draft (and in > http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-02 > .txt). > > In the instances cited, the link-state protocol overwhelmed the network with a > control load 'storm' ('LSA overload'), which brought the network down, and then > prevented its recovery. Fortunately such failures are very rare; however, > 'rare' for such events is unacceptable, 'never' is the goal. Other service > providers have experienced similar outages caused by similar problems. > > Such failures are not the fault of the service provider operation or the > vendor/equipment implementation. They are due to shortcomings in the link-state > protocols themselves -- thus the need for the enhancements proposed in the > draft. > > The proposals in > http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00. > txt will prevent such events from being triggered, and/or provide recovery > mechanisms in case such events occur. > > The problem of control overload is becoming even more acute as LS protocols are > enhanced to support new capabilities, such as: > > MPLS traffic engineering > http://search.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt, > GMPLS > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-08.tx > t, > multi-area TE > http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt, > MPLS/DiffServ TE > http://search.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-06.txt, > etc. > > With this ever advancing complexity, the need keeps increasing to address the > stated problem, soon. Thus the need for the charter item on OSPF congestion > control. > > Thanks, > Jerry Ash From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 01:09:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24837 for ; Thu, 7 Nov 2002 01:09:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.007B6E0D@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 1:12:16 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 328277 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 01:12:15 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 01:12:15 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA76CFS89288 for ; Wed, 6 Nov 2002 22:12:15 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id gA76CEm66637; Wed, 6 Nov 2002 22:12:14 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <28F05913385EAC43AF019413F674A01701B65690@OCCLUST04EVS1.ugd.att.com> Message-ID: <200211070612.gA76CEm66637@cirrus.juniper.net> Date: Wed, 6 Nov 2002 22:12:14 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <28F05913385EAC43AF019413F674A01701B65690@OCCLUST04EVS1.ugd.att.com> (gash@ATT.COM) Precedence: list Such failures are not the fault of the service provider operation or the vendor/equipment implementation. They are due to shortcomings in the link-state protocols themselves -- thus the need for the enhancements proposed in the draft. I strongly disagree with this statement. While the design of the protocols can make it challenging, there is ample room in implementation to provide stable and scalable networks. When a network collapses, the fault lies at the feet of the implementors. In every case I've seen (too many), the collapse was inevitable sooner or later, due to naive design choices in software, but at the same time was quite nonlinear in its onset (making any predictive or self-monitoring approach pretty hopeless.) There are some things that would make the job easier, at the cost of additional complexity, but pointing at network collapses and blaming the protocols is disingenuous. --Dave From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 08:25:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22416 for ; Thu, 7 Nov 2002 08:25:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.007B752B@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 8:27:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 329278 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 08:27:39 -0500 Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 08:27:39 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA7DQeLs019553 for ; Thu, 7 Nov 2002 08:27:39 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B560500FF1B9F; Thu, 7 Nov 2002 08:27:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: OSPF WG Charter Proposal Thread-Index: AcKGJKSDPLqgP488Qqq6VGZ3CAKnOQANcfpQ Message-ID: <28F05913385EAC43AF019413F674A0170167B229@OCCLUST04EVS1.ugd.att.com> Date: Thu, 7 Nov 2002 08:27:38 -0500 Reply-To: Mailing List Sender: Mailing List From: "Ash, Gerald R (Jerry), ALASO" Subject: Re: OSPF WG Charter Proposal Comments: To: Dave Katz To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA22416 Dave, > > Such failures are not the fault of the service provider > > operation or the vendor/equipment implementation. They are > > due to shortcomings in the link-state protocols themselves -- > > thus the need for the enhancements proposed in the draft. > I strongly disagree with this statement. While the design of the > protocols can make it challenging, there is ample room in > implementation to provide stable and scalable networks. > > When a network collapses, the fault lies at the feet of the > implementers. In every case I've seen (too many), the collapse was > inevitable sooner or later, due to naive design choices in software, > but at the same time was quite nonlinear in its onset (making any > predictive or self-monitoring approach pretty hopeless.) > > There are some things that would make the job easier, at the cost > of additional complexity, but pointing at network collapses > and blaming the protocols is disingenuous. I think you should review the ample evidence presented in http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt that the protocols need to be enhanced to better respond to congestion collapse: - Section 2: documented failures and their root-cause analysis, across multiple service provider networks (also review the cited references) - Appendix B: vendor analysis of a realistic failure scenario similar to one experienced as discussed in Section 2 (perhaps you would like to provide your own analysis of this scenario based on your OSPF implementation) - Appendix C: simulation analysis of protocol performance (other I-D's being discussed provide analysis of proposed protocol extensions) To say that network collapse in *every* case is due to *naive design choices* ignores the evidence/analysis presented. Based on the evidence/analysis, there is clearly room for the protocols to be improved to the point where networks *never* go down for hours or days at a time (drawing unwanted headlines & business impact). Jerry From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 10:38:37 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28533 for ; Thu, 7 Nov 2002 10:38:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.007B792F@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 10:41:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 329712 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 10:41:04 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 10:41:04 -0500 Received: (qmail 7102 invoked from network); 7 Nov 2002 15:41:03 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 7 Nov 2002 15:41:03 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id KAA22539 for ; Thu, 7 Nov 2002 10:41:03 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200211071541.KAA22539@bigbird.xebeo.com> Date: Thu, 7 Nov 2002 10:41:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from "Ash, Gerald R (Jerry), ALASO" of "Thu, 07 Nov 2002 08:27:38 EST." <28F05913385EAC43AF019413F674A0170167B229@OCCLUST04EVS1.ugd.att.com> Precedence: list Jerry, I looked at one of the sections you pointed out. On Thu, 7 Nov 2002 08:27:38 -0500 "Ash, Gerald R (Jerry), ALASO" writes: [snip] =>I think you should review the ample evidence presented in http://www.ietf.org >/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt that the prot >ocols need to be enhanced to better respond to congestion collapse: => =>- Section 2: documented failures and their root-cause analysis, across multip >le service provider networks (also review the cited references) The cited references [att, cholewka, jander, pappalardo*] are from trade rags. Unless there is some other peer reviewed paper or standards document, these incidents can hardly be used to point to the root cause. No, I am not saying that something wasn't wrong - just that these references don't carr much weight. In one of these reported incidents, I was physically present and happen to know the root cause. It was an "implementation mistake" which was triggered by two different versions of the software being present in the network simultaneously during a network wide s/e upgrade - a flooding storm resulted. The problem here is _not_ in the flooding. While one can certainly provide more knobs to limit flooding, one can also solve the problem equally well or better by fixing the base implementation or doing better tests before upgrading a network. =>- Appendix B: vendor analysis of a realistic failure scenario similar to one >experienced as discussed in Section 2 (perhaps you would like to provide your >own analysis of this scenario based on your OSPF implementation) =>- Appendix C: simulation analysis of protocol performance (other I-D's being >discussed provide analysis of proposed protocol extensions) => =>To say that network collapse in *every* case is due to *naive design choices* > ignores the evidence/analysis presented. Based on the evidence/analysis, the >re is clearly room for the protocols to be improved to the point where network >s *never* go down for hours or days at a time (drawing unwanted headlines & bu >siness impact). I don't think this is what Dave is saying - he is simply referring to all the cases that _he_ has seen. This matches my experience with the caveat that in some cases (a) there was faulty hardware (b) network/ospf parameters were inconsistely or incorrectly applied. --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 10:44:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28708 for ; Thu, 7 Nov 2002 10:44:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.007B79E1@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 10:46:47 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 329696 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 10:46:47 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 10:36:47 -0500 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 3933007 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 07 Nov 2002 10:36:46 -0500 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20021107102407.01642ec8@mail.stevecrocker.com> Date: Thu, 7 Nov 2002 10:34:53 -0500 Reply-To: Mailing List Sender: Mailing List From: "Joel M. Halpern" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <28F05913385EAC43AF019413F674A0170167B229@OCCLUST04EVS1.ugd .att.com> Precedence: list There seem to be multiple things mixes together in this discussion, some of which are nicely separated in the draft below. One set of things are behaviors like pacing link start, pacing flooding, marking critical packets, etc. These have a number of useful properties. They improve the overall result without changing the basic mechanisms. They do not introduce significant risk of interaction between mechanisms. A second set of things mentioned are issues like hitless restart. While these have more impact, they have benefits in a number of different regards, and can be evaluated on their own merits. Then there are manual mechanisms to help flooding in very meshy topologies. While somewhat dangerous, these have proved necessary. Because they are manual, they can be applied with sensitivity to their overall topology impact. Then there are automatic information distribution change mechanisms. This covers such things as automatic area change and alternative flooding algorithms. These are extremely dangers. They interact very strongly with the basic robustness mechanisms of OSPF. They introduce significant additional complexity in many regards. I strongly suggest that we stay away from any such behaviors, and ensure that our charter keeps us away from them. Yours, Joel M. Halpern At 08:27 AM 11/7/2002 -0500, Ash, Gerald R (Jerry), ALASO wrote: >Dave, > > > > Such failures are not the fault of the service provider > > > operation or the vendor/equipment implementation. They are > > > due to shortcomings in the link-state protocols themselves -- > > > thus the need for the enhancements proposed in the draft. > > > I strongly disagree with this statement. While the design of the > > protocols can make it challenging, there is ample room in > > implementation to provide stable and scalable networks. > > > > When a network collapses, the fault lies at the feet of the > > implementers. In every case I've seen (too many), the collapse was > > inevitable sooner or later, due to naive design choices in software, > > but at the same time was quite nonlinear in its onset (making any > > predictive or self-monitoring approach pretty hopeless.) > > > > There are some things that would make the job easier, at the cost > > of additional complexity, but pointing at network collapses > > and blaming the protocols is disingenuous. > >I think you should review the ample evidence presented in >http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt >that the protocols need to be enhanced to better respond to congestion >collapse: > >- Section 2: documented failures and their root-cause analysis, across >multiple service provider networks (also review the cited references) >- Appendix B: vendor analysis of a realistic failure scenario similar to >one experienced as discussed in Section 2 (perhaps you would like to >provide your own analysis of this scenario based on your OSPF implementation) >- Appendix C: simulation analysis of protocol performance (other I-D's >being discussed provide analysis of proposed protocol extensions) > >To say that network collapse in *every* case is due to *naive design >choices* ignores the evidence/analysis presented. Based on the >evidence/analysis, there is clearly room for the protocols to be improved >to the point where networks *never* go down for hours or days at a time >(drawing unwanted headlines & business impact). > >Jerry From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 11:14:54 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00358 for ; Thu, 7 Nov 2002 11:14:54 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.007B7B71@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 11:17:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 329915 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 11:17:19 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 11:17:18 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 6B4C81531CF for ; Thu, 7 Nov 2002 08:17:17 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------030406030405060401030108" Message-ID: <3DCA91A9.5000207@redback.com> Date: Thu, 7 Nov 2002 11:15:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Atlanta IETF OSPF WG Final Agenda To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------030406030405060401030108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've moved the charter update to the end to allow for a little more discussion without delaying all the presentations. -- Acee --------------030406030405060401030108 Content-Type: text/plain; name="ospf-wg-agenda.txt" Content-Disposition: inline; filename="ospf-wg-agenda.txt" Content-Transfer-Encoding: 7bit Open Shortest Path First WG (OSPF) Thursday, November 12 at 1530-1730 ================================= CHAIRS: Rohit Dube Acee Lindem AGENDA: Agenda Bashing 5 Mins WG document status 10 Mins Chairs Extensions to IS-IS and OSPF for Advertising 10 Mins Rahul Aggarwal Optional Router Capabilities OSPFv3 Traffic Engineering Extensions 15 Mins Kunihiro Ishiguro OSPFv2 Opaques in OSPFv3 10 Mins Kireeti Kompella Congestion Avoidance & Control for 10 Mins Jerry Ash OSPF Neworks Explicit Marking and Prioritized Treatment 10 Mins Gagan L. Choudhury of Specific OSPF Packets for Faster Convergence and Improved Network Scalability and Stability LSA Flooding Optimization Algorithms and 10 Mins Gagan L. Choudhury Their Simulation Study OSPF Hitless Restart Update 5 Mins Acee Lindem - 04 version posted to list WG Charter Update 15 Mins Chairs --------------030406030405060401030108-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 11:16:00 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00392 for ; Thu, 7 Nov 2002 11:16:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.007B7ABA@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 11:18:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 329928 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 11:18:26 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 11:18:26 -0500 Received: (qmail 10379 invoked from network); 7 Nov 2002 16:18:25 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 7 Nov 2002 16:18:25 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <28F05913385EAC43AF019413F674A0170167B229@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DCA91FF.3070206@xebeo.com> Date: Thu, 7 Nov 2002 17:17:03 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ash, Gerald R (Jerry), ALASO wrote: >Dave, > >>>Such failures are not the fault of the service provider >>>operation or the vendor/equipment implementation. They are >>>due to shortcomings in the link-state protocols themselves -- >>>thus the need for the enhancements proposed in the draft. >>> > >>I strongly disagree with this statement. While the design of the >>protocols can make it challenging, there is ample room in >>implementation to provide stable and scalable networks. >> >>When a network collapses, the fault lies at the feet of the >>implementers. In every case I've seen (too many), the collapse was >>inevitable sooner or later, due to naive design choices in software, >>but at the same time was quite nonlinear in its onset (making any >>predictive or self-monitoring approach pretty hopeless.) >> >>There are some things that would make the job easier, at the cost >>of additional complexity, but pointing at network collapses >>and blaming the protocols is disingenuous. >> > >I think you should review the ample evidence presented in http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt that the protocols need to be enhanced to better respond to congestion collapse: > >- Section 2: documented failures and their root-cause analysis, across multiple service provider networks (also review the cited references) >- Appendix B: vendor analysis of a realistic failure scenario similar to one experienced as discussed in Section 2 (perhaps you would like to provide your own analysis of this scenario based on your OSPF implementation) >- Appendix C: simulation analysis of protocol performance (other I-D's being discussed provide analysis of proposed protocol extensions) > >To say that network collapse in *every* case is due to *naive design choices* ignores the evidence/analysis presented. Based on the evidence/analysis, there is clearly room for the protocols to be improved to the point where networks *never* go down for hours or days at a time (drawing unwanted headlines & business impact). > >Jerry > Jerry, most of the things you say in your document (which is actually pretty good) has been known to people like Dave and other old-time implementors since years and avoiding exactly those things by smart implementation techniques was what was differentiating the have from the have-nots. I remember myself learning some of those things by hard experience and some by looking at old-hands code ;-) [Albeit I remember also picking up a lot of smart control protocol ideas from your RTNR work]. I do not think that Dave is putting down what you say, rather (and I commit the stupidity to interpret his words by my own beliefs) that what your document says are mostly _implementation_ issues, not _standardization_ and therefore it is not a very wise idea to add them to the charter of a _standards_ group. Good protocol specs are _not_ implementation cookbooks, they are documents governing bits on the wires in such a way that two people implementing things in vastly different ways can still talk to each other. Recommendations of implementation techniques prove long-term inherently dangerous (like Joel pointed out, at a certain point in time adding more code to an implementation introduces more bugs than the performance gain is worth) or utterly ridiculous (look at ISIS 0-63 metric to make SPF real fast, it lead to quite bad contortions). thanks -- tony From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 11:35:04 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01252 for ; Thu, 7 Nov 2002 11:35:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007B7CB9@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 11:37:32 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 329955 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 11:37:32 -0500 Received: from 63.102.55.206 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 11:27:32 -0500 Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZB2CW>; Thu, 7 Nov 2002 08:27:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <9D42C6E086250248810DCADA39CE7EFC971FD1@nimbus> Date: Thu, 7 Nov 2002 08:27:27 -0800 Reply-To: Mailing List Sender: Mailing List From: John Drake Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Tony, You saved me some typing. As another example, implementations of PNNI signalling ranged from something like ten calls per second to several thousand calls per second. Thanks, John -----Original Message----- From: Tony Przygienda [mailto:prz@XEBEO.COM] Sent: Thursday, November 07, 2002 8:17 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF WG Charter Proposal Ash, Gerald R (Jerry), ALASO wrote: >Dave, > >>>Such failures are not the fault of the service provider >>>operation or the vendor/equipment implementation. They are >>>due to shortcomings in the link-state protocols themselves -- >>>thus the need for the enhancements proposed in the draft. >>> > >>I strongly disagree with this statement. While the design of the >>protocols can make it challenging, there is ample room in >>implementation to provide stable and scalable networks. >> >>When a network collapses, the fault lies at the feet of the >>implementers. In every case I've seen (too many), the collapse was >>inevitable sooner or later, due to naive design choices in software, >>but at the same time was quite nonlinear in its onset (making any >>predictive or self-monitoring approach pretty hopeless.) >> >>There are some things that would make the job easier, at the cost >>of additional complexity, but pointing at network collapses >>and blaming the protocols is disingenuous. >> > >I think you should review the ample evidence presented in http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control -00.txt that the protocols need to be enhanced to better respond to congestion collapse: > >- Section 2: documented failures and their root-cause analysis, across multiple service provider networks (also review the cited references) >- Appendix B: vendor analysis of a realistic failure scenario similar to one experienced as discussed in Section 2 (perhaps you would like to provide your own analysis of this scenario based on your OSPF implementation) >- Appendix C: simulation analysis of protocol performance (other I-D's being discussed provide analysis of proposed protocol extensions) > >To say that network collapse in *every* case is due to *naive design choices* ignores the evidence/analysis presented. Based on the evidence/analysis, there is clearly room for the protocols to be improved to the point where networks *never* go down for hours or days at a time (drawing unwanted headlines & business impact). > >Jerry > Jerry, most of the things you say in your document (which is actually pretty good) has been known to people like Dave and other old-time implementors since years and avoiding exactly those things by smart implementation techniques was what was differentiating the have from the have-nots. I remember myself learning some of those things by hard experience and some by looking at old-hands code ;-) [Albeit I remember also picking up a lot of smart control protocol ideas from your RTNR work]. I do not think that Dave is putting down what you say, rather (and I commit the stupidity to interpret his words by my own beliefs) that what your document says are mostly _implementation_ issues, not _standardization_ and therefore it is not a very wise idea to add them to the charter of a _standards_ group. Good protocol specs are _not_ implementation cookbooks, they are documents governing bits on the wires in such a way that two people implementing things in vastly different ways can still talk to each other. Recommendations of implementation techniques prove long-term inherently dangerous (like Joel pointed out, at a certain point in time adding more code to an implementation introduces more bugs than the performance gain is worth) or utterly ridiculous (look at ISIS 0-63 metric to make SPF real fast, it lead to quite bad contortions). thanks -- tony From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 11:46:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01463 for ; Thu, 7 Nov 2002 11:46:17 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.007B7BEB@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 11:48:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330067 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 11:48:44 -0500 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 11:48:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 7 Nov 2002 11:48:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > As another example, implementations of PNNI > signalling ranged from something like ten calls per second to several > thousand calls per second. > > John In the context of this discussion, I'm not sure which of the two statements below you are making. (#1?) "So efficient that we could make thousands of setups per second" or "So out of control that we would make thousands of calls per second." - jeff parker From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 12:21:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02862 for ; Thu, 7 Nov 2002 12:21:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.007B7D31@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 12:23:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330175 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 12:23:56 -0500 Received: from 205.152.58.171 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 12:13:56 -0500 Received: from Allah ([66.156.105.175]) by imf11bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021107171540.IGTZ3483.imf11bis.bellsouth.net@Allah> for ; Thu, 7 Nov 2002 12:15:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Message-ID: <000601c28698$c5f405d0$0201a8c0@bellsouth.net> Date: Thu, 7 Nov 2002 15:03:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Johnny Taylor Subject: Re: Atlanta IETF OSPF WG Final Agenda To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DCA91A9.5000207@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Where will this be hosted? -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Acee Lindem Sent: Thursday, November 07, 2002 11:16 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Atlanta IETF OSPF WG Final Agenda I've moved the charter update to the end to allow for a little more discussion without delaying all the presentations. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 12:27:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03107 for ; Thu, 7 Nov 2002 12:27:22 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.007B7F49@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 12:29:51 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330223 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 12:29:51 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 12:29:51 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HP836>; Thu, 7 Nov 2002 12:29:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 7 Nov 2002 12:31:24 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Dave/Tony/folks, Thanks a lot for the comments. I agree a large part of the draft covers implementation specific stuff like the need for pacing LS updates/reducing the rate of flooding etc. An implementation not doing that could cause problems as Jerry mentioned in his earlier mail, and as Tony mentioned, is not learned the easy way. We did get the comment from Dave(on the prepublished version of the draft) to reduce implementation specific stuff, which we have to the minimum. I however do think we can give implementation recommendations without affecting a good implementation (eg I do not think saying pacing needs to be done hampers a good implementation, though telling the mechanism to do it does, which i think is not implementation specific anymore but a necessary requirement) Besides in case of extreme congestion, we did figure out the only way to bring adjacencies up is signal to the neighbor to slow the rate of flooding further(for which we are using signalling) besides the other way to selectively brining up adjacencies at a time. This I think is the only significant change which requires bits on the wire to change. Our aim is to minimize changes to normal processing/code, while also getting over the problem gracefully when it occurs and not having to go down for days at a time. We also need to reduce the number of configureables, which we do intend to minimize further. Besides I do think from my readings that these problems are more common, than I had initially guessed, though it does not always cause a network collapse. Though Tony I m not sure how ISIS 0-63 bits would add to recommendations of implementation;-) Thanks again, Vishwas -----Original Message----- From: Tony Przygienda [mailto:prz@XEBEO.COM] Sent: Thursday, November 07, 2002 9:47 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF WG Charter Proposal Ash, Gerald R (Jerry), ALASO wrote: >Dave, > >>>Such failures are not the fault of the service provider >>>operation or the vendor/equipment implementation. They are >>>due to shortcomings in the link-state protocols themselves -- >>>thus the need for the enhancements proposed in the draft. >>> > >>I strongly disagree with this statement. While the design of the >>protocols can make it challenging, there is ample room in >>implementation to provide stable and scalable networks. >> >>When a network collapses, the fault lies at the feet of the >>implementers. In every case I've seen (too many), the collapse was >>inevitable sooner or later, due to naive design choices in software, >>but at the same time was quite nonlinear in its onset (making any >>predictive or self-monitoring approach pretty hopeless.) >> >>There are some things that would make the job easier, at the cost >>of additional complexity, but pointing at network collapses >>and blaming the protocols is disingenuous. >> > >I think you should review the ample evidence presented in http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control -00.txt that the protocols need to be enhanced to better respond to congestion collapse: > >- Section 2: documented failures and their root-cause analysis, across multiple service provider networks (also review the cited references) >- Appendix B: vendor analysis of a realistic failure scenario similar to one experienced as discussed in Section 2 (perhaps you would like to provide your own analysis of this scenario based on your OSPF implementation) >- Appendix C: simulation analysis of protocol performance (other I-D's being discussed provide analysis of proposed protocol extensions) > >To say that network collapse in *every* case is due to *naive design choices* ignores the evidence/analysis presented. Based on the evidence/analysis, there is clearly room for the protocols to be improved to the point where networks *never* go down for hours or days at a time (drawing unwanted headlines & business impact). > >Jerry > Jerry, most of the things you say in your document (which is actually pretty good) has been known to people like Dave and other old-time implementors since years and avoiding exactly those things by smart implementation techniques was what was differentiating the have from the have-nots. I remember myself learning some of those things by hard experience and some by looking at old-hands code ;-) [Albeit I remember also picking up a lot of smart control protocol ideas from your RTNR work]. I do not think that Dave is putting down what you say, rather (and I commit the stupidity to interpret his words by my own beliefs) that what your document says are mostly _implementation_ issues, not _standardization_ and therefore it is not a very wise idea to add them to the charter of a _standards_ group. Good protocol specs are _not_ implementation cookbooks, they are documents governing bits on the wires in such a way that two people implementing things in vastly different ways can still talk to each other. Recommendations of implementation techniques prove long-term inherently dangerous (like Joel pointed out, at a certain point in time adding more code to an implementation introduces more bugs than the performance gain is worth) or utterly ridiculous (look at ISIS 0-63 metric to make SPF real fast, it lead to quite bad contortions). thanks -- tony From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 12:44:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03744 for ; Thu, 7 Nov 2002 12:44:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.007B7EBA@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 12:47:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330286 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 12:47:11 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 12:47:10 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HP8PW>; Thu, 7 Nov 2002 12:47:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 7 Nov 2002 12:49:24 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Joel, > There seem to be multiple things mixes together in this discussion, > some of which are nicely separated in the draft below. > One set of things are behaviors like pacing link start, pacing > flooding, marking critical packets, etc. These have a number > of useful properties. They improve the overall result without > changing the basic mechanisms. They do not introduce > significant risk of interaction between mechanisms. I agree totally. > A second set of things mentioned are issues like hitless > restart. While these have more impact, they have benefits in a > number of different regards, and can be evaluated on their own > merits. > Then there are manual mechanisms to help flooding in very meshy > topologies. While somewhat dangerous, these have proved > necessary. Because they are manual, they can be applied with > sensitivity to their overall topology impact. I agree here too. > Then there are automatic information distribution change > mechanisms. This covers such things as automatic area change > and alternative flooding algorithms. These are extremely dangers. > They interact very strongly with the basic robustness mechanisms > of OSPF. They introduce significant additional complexity in > many regards. I strongly suggest that we stay away from any such > behaviors, and ensure that our charter keeps us away from them. I do agree stuff like area change etc would be dangerous. Could you point to the section you are referring for this one? Besides the flooding algos present in the draft as "Related Solution Methods" can be removed if they are causing a problem. I do not think there is any mention to using the methods, just methods used in other protocols that could help in this case. Thanks, Vishwas At 08:27 AM 11/7/2002 -0500, Ash, Gerald R (Jerry), ALASO wrote: >Dave, > > > > Such failures are not the fault of the service provider > > > operation or the vendor/equipment implementation. They are > > > due to shortcomings in the link-state protocols themselves -- > > > thus the need for the enhancements proposed in the draft. > > > I strongly disagree with this statement. While the design of the > > protocols can make it challenging, there is ample room in > > implementation to provide stable and scalable networks. > > > > When a network collapses, the fault lies at the feet of the > > implementers. In every case I've seen (too many), the collapse was > > inevitable sooner or later, due to naive design choices in software, > > but at the same time was quite nonlinear in its onset (making any > > predictive or self-monitoring approach pretty hopeless.) > > > > There are some things that would make the job easier, at the cost > > of additional complexity, but pointing at network collapses > > and blaming the protocols is disingenuous. > >I think you should review the ample evidence presented in >http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-contro l-00.txt >that the protocols need to be enhanced to better respond to congestion >collapse: > >- Section 2: documented failures and their root-cause analysis, across >multiple service provider networks (also review the cited references) >- Appendix B: vendor analysis of a realistic failure scenario similar to >one experienced as discussed in Section 2 (perhaps you would like to >provide your own analysis of this scenario based on your OSPF implementation) >- Appendix C: simulation analysis of protocol performance (other I-D's >being discussed provide analysis of proposed protocol extensions) > >To say that network collapse in *every* case is due to *naive design >choices* ignores the evidence/analysis presented. Based on the >evidence/analysis, there is clearly room for the protocols to be improved >to the point where networks *never* go down for hours or days at a time >(drawing unwanted headlines & business impact). > >Jerry From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 13:08:56 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04659 for ; Thu, 7 Nov 2002 13:08:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007B8038@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 13:11:24 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330406 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 13:11:24 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 13:11:24 -0500 Received: (qmail 19678 invoked from network); 7 Nov 2002 18:11:23 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 7 Nov 2002 18:11:23 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DCAAC7A.6050700@xebeo.com> Date: Thu, 7 Nov 2002 19:10:02 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: >Hi Dave/Tony/folks, > >Though Tony I m not sure how ISIS 0-63 bits would add to recommendations of >implementation;-) > 0-63 was specifically introduced into the spec to support smart implementation that could do extremely fast SPFs that way (think about ordering of candidate list). Radia can totally enlighten you with all the details if you want ... - tony From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 13:12:07 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04829 for ; Thu, 7 Nov 2002 13:12:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.007B8051@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 13:14:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330428 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 13:14:35 -0500 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 13:14:35 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA7Hwqhk020938 for ; Thu, 7 Nov 2002 12:14:35 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B56050101527A; Thu, 7 Nov 2002 13:14:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: OSPF WG Charter Proposal Thread-Index: AcKGdBq71FJLb7xoQs6UJn1g4SeoFQACHP0A Message-ID: <28F05913385EAC43AF019413F674A01701B6569F@OCCLUST04EVS1.ugd.att.com> Date: Thu, 7 Nov 2002 13:14:34 -0500 Reply-To: Mailing List Sender: Mailing List From: "Ash, Gerald R (Jerry), ALASO" Subject: Re: OSPF WG Charter Proposal Comments: To: Rohit Dube To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA04829 Rohit, > > I think you should review the ample evidence presented in > > http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt > > that the protocols need to be enhanced to better respond to congestion collapse: > > Section 2: documented failures and their root-cause analysis, across multiple > > service provider networks (also review the cited references) > The cited references [att, cholewka, jander, pappalardo*] are from trade > rags. Unless there is some other peer reviewed paper or standards document, > these incidents can hardly be used to point to the root cause. No, I am > not saying that something wasn't wrong - just that these references don't > carr much weight. A summary of the extensive root-cause analysis of one incident (performed by both service provider and vendors) is presented in Section 2 of http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt. The other 2 incidents cited had similar extensive root cause analysis with similar conclusions. The trade articles give some additional information about the incidents, yes, they are not refereed papers. I believe the cited failures and summary of root cause analysis presented in the I-D should carry some weight. As a result of these failure experiences, our vendors made protocol upgrades (albeit proprietary upgrades) to address the problems. These protocol upgrades were along the lines of the proposals made in the I-D to address these same problems in a standard, interoperable way. > In one of these reported incidents, I was physically present and happen > to know the root cause. It was an "implementation mistake" which was > triggered by two different versions of the software being present in > the network simultaneously during a network wide s/e upgrade > - a flooding storm resulted. Right, there are many problems/bugs/manual-errors/etc. that trigger a catastrophic failure and flooding storm, this is pointed out specifically in the I-D, from Section 2: "For example, in the failure in the AT&T Frame Relay Network on April 13, 1998 [att], an initial procedural error triggered two undetected software bugs, leading to a huge overload of control messages in the network. The result of this control overload was the loss of all topology information, which the LS protocol then attempted to recover using the usual Hello and LS updates. However, the LS protocol was overwhelmed and unable to recover, and manual means had to be used to restart the network after a long outage." The other failures cited in Section 2 had different means triggering the flooding storm -- there are an infinite number of ways to get into this situation. We would not like flooding storms to be triggered, but unfortunately they *are* triggered, and when they are the problem is getting out of them quickly (not taking hours and days as experienced). > The problem here is _not_ in the flooding. The problem *was* in the flooding storm that was triggered in all the failures cited, and the inability to recover. The scenario presented in Appendix B mimics the failure cited above (from Section 2), for which a few vendors provided analysis of how fast their protocol implementation recovers. We invite other vendors to analyze this scenario for their OSPF implementation. > While one can certainly provide more knobs to limit flooding, > one can also solve the problem equally well or better by fixing > the base implementation or doing better tests before upgrading > a network. As above, even with the best implementations and testing, stuff happens to trigger flooding-storm events from which the protocol cannot adequately recover. We need to limit flooding, etc. *in addition to* having the best implementations and testing. > > To say that network collapse in *every* case is due to *naive design > > choices* ignores the evidence/analysis presented. Based on the > > evidence/analysis, there is clearly room for the protocols to be > > improved to the point where networks *never* go down for hours or > > days at a time (drawing unwanted headlines & business impact). > I don't think this is what Dave is saying - he is simply referring to > all the cases that _he_ has seen. OK. I took his drift to mean that every failure, including the ones I cited, can be attributed to naive design, and that no protocol extensions are necessary, just better design. > This matches my experience with the caveat that > in some cases (a) there was faulty hardware (b) network/ospf > parameters were inconsistently or incorrectly applied. Well, given your above statement that you were physically present at one of the reported incidents and know the root cause ("implementation mistake"), and witnessed the flooding storm that resulted, then you also know that the recovery from that incident was totally inadequate and unacceptable. I would infer that your experience then is similar to my experience and not Dave's. Jerry From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 13:17:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05049 for ; Thu, 7 Nov 2002 13:17:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.007B80E1@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 13:19:48 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330475 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 13:19:47 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 13:19:47 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 6694E40625E for ; Thu, 7 Nov 2002 10:19:46 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000601c28698$c5f405d0$0201a8c0@bellsouth.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DCAAE5D.9040306@redback.com> Date: Thu, 7 Nov 2002 13:18:05 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Atlanta IETF OSPF WG Final Agenda To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Johnny, I'm not sure exactly what you mean - the IETF will held at: MEETING SITE: Atlanta Marriott Marquis 265 Peachtree Center Avenue Atlanta, GA 30303 Tel: + 1-404-521-0000 Fax: + 1-404-586-6299 The OSPF WG meets in Salon 1. Johnny Taylor wrote: > Where will this be hosted? > > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Acee > Lindem > Sent: Thursday, November 07, 2002 11:16 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Atlanta IETF OSPF WG Final Agenda > > > I've moved the charter update to the end to allow > for a little more discussion without delaying > all the presentations. > -- > Acee > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 13:27:52 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05318 for ; Thu, 7 Nov 2002 13:27:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.007B81A2@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 13:30:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330538 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 13:30:21 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 13:30:21 -0500 Received: (qmail 20965 invoked from network); 7 Nov 2002 18:30:21 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 7 Nov 2002 18:30:21 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id NAA30968 for ; Thu, 7 Nov 2002 13:30:21 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200211071830.NAA30968@bigbird.xebeo.com> Date: Thu, 7 Nov 2002 13:30:21 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from "Ash, Gerald R (Jerry), ALASO" of "Thu, 07 Nov 2002 13:14:34 EST." <28F05913385EAC43AF019413F674A01701B6569F@OCCLUST04EVS1.ugd.att.com> Precedence: list Jerry, On Thu, 7 Nov 2002 13:14:34 -0500 "Ash, Gerald R (Jerry), ALASO" writes: [snip] =>> The problem here is _not_ in the flooding. => =>The problem *was* in the flooding storm that was triggered in all the failure >s cited, and the inability to recover. We may be talking about different incidents. The one that I was involved in, was a clear implementation mistake (a case was missed) which was the root cause. It should have been caught in testing if somebody had bothered to look at why certain LSAs were being generated. The excessive flooding was simply the result. I couldn't say this better than Tony/Joel : "at a certain point adding more code to an implementation introduces more bugs than the performance gain is worth". I (like most developers) can attest to this from first hand experience. Regards, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 13:56:00 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06234 for ; Thu, 7 Nov 2002 13:56:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.007B80DA@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 13:58:30 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330646 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 13:58:30 -0500 Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 13:58:29 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04962 for ; Thu, 7 Nov 2002 10:58:28 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA7IwSn26320 for ; Thu, 7 Nov 2002 10:58:28 -0800 X-mProtect: <200211071858> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.11.199, claiming to be "jcruz.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdd6smo6; Thu, 07 Nov 2002 10:58:26 PST Received: from localhost (jcruz@localhost) by jcruz.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id KAA23152 for ; Thu, 7 Nov 2002 10:58:27 -0800 (PST) X-Authentication-Warning: jcruz.iprg.nokia.com: jcruz owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 7 Nov 2002 10:58:27 -0800 Reply-To: Mailing List Sender: Mailing List From: John Cruz Subject: Re: OSPFv3: question about referenced link state type To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021106.093624.132469402.yasu@sfc.wide.ad.jp> Precedence: list We, in Nokia, have also used the "LS type" as defined in Section A.4.2.1 for the value of "Referenced LS Type" for Intra-Area-Prefix LSAs. John On Wed, 6 Nov 2002, Yasuhiro Ohara wrote: > pauwells> However, a literal reading of section A.4.9 of RFC 2740 > pauwells> indicates that the referenced LS type should be 1 or 2. > pauwells> > pauwells> I'm wondering if other implementors would comment on what > pauwells> they do here, and whether this is a potential > pauwells> interoperability problem. > > Current Zebra ospf6d encodes whole LS-Type including U, S1, S2 bits. > I didn't noticed A.4.9, and just refered LS-Type. > > I think it is possible that this becomes an interoperability > problem because A.4.9 specifies the value explicitly. > The interoperability tests I've done so far with some other > implementations did not show me any problem about this, though. > > regards, > yasu > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 14:03:57 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06359 for ; Thu, 7 Nov 2002 14:03:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007B8300@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 14:06:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330640 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 14:06:27 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 13:56:27 -0500 Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 4D4C92848BC; Thu, 7 Nov 2002 10:56:26 -0800 (PST) Received: (from rahul@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id KAA06188; Thu, 7 Nov 2002 10:56:25 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Message-ID: <20021107185625.GD5684@malt.redback.com> Date: Thu, 7 Nov 2002 10:56:25 -0800 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Updated IGP capabilities draft Comments: cc: jpv@cisco.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list We have posted an updated IGP capabilities draft: http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt Following are the major changes: 1. Capability advertisments has been enhanced to allow inclusion of application specific sub-tlvs. 2. Path computation server discovery and LSP mesh groups use this mechanism. as defined in the draft: http://www.ietf.org/internet-drafts/draft-vasseur-mpls-ospf-te-cap-00.txt We will give a brief update in Atlanta. Comments are welcome. rahul From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 15:01:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08660 for ; Thu, 7 Nov 2002 15:01:21 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.007B8430@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 15:00:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330826 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 15:00:53 -0500 Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 15:00:53 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA7JwtLt023186 for ; Thu, 7 Nov 2002 15:00:50 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B56050102234D; Thu, 7 Nov 2002 15:00:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: OSPF WG Charter Proposal Thread-Index: AcKGi8DilqBL5JahS+yzto+1AiJPogACU04A Message-ID: <28F05913385EAC43AF019413F674A0170167B233@OCCLUST04EVS1.ugd.att.com> Date: Thu, 7 Nov 2002 15:00:48 -0500 Reply-To: Mailing List Sender: Mailing List From: "Ash, Gerald R (Jerry), ALASO" Subject: Re: OSPF WG Charter Proposal Comments: To: Rohit Dube To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA08660 Rohit, > > The problem *was* in the flooding storm that was triggered > > in all the failures cited, and the inability to recover. > We may be talking about different incidents. The one that I > was involved in, was a clear implementation mistake > (a case was missed) which was the root cause. It should have > been caught in testing if somebody had bothered to > look at why certain LSAs were being generated. The excessive > flooding was simply the result. So we've both observed flooding storms and their bad effects. They can be started in many different ways, but sometimes bring the network down and take hours or days to recover (that is the problem we want to solve). > I couldn't say this better than Tony/Joel : "at a certain point adding > more code to an implementation introduces more bugs than the > performance gain is worth". I (like most developers) can attest to this > from first hand experience. I certainly agree with you, Dave, Joel, Tony (thanks all!) that excellent implementation and testing is essential, and that adding complexity and more bugs surely isn't the goal. I too have experience designing/testing/implementing new routing methods in large-scale applications, and well appreciate these points. Summary: We've identified a problem and the problem isn't solved entirely by good implementation/testing/operation, we feel some protocol extensions are necessary. Thanks, Regards, Jerry From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 15:17:05 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09469 for ; Thu, 7 Nov 2002 15:17:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007B8496@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 15:19:33 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330867 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 15:19:32 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 15:19:32 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA7KJWS42445; Thu, 7 Nov 2002 12:19:32 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id gA7KJVi68469; Thu, 7 Nov 2002 12:19:31 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <28F05913385EAC43AF019413F674A0170167B229@OCCLUST04EVS1.ugd.att.com> Message-ID: <200211072019.gA7KJVi68469@cirrus.juniper.net> Date: Thu, 7 Nov 2002 12:19:31 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: OSPF WG Charter Proposal Comments: To: gash@att.com Comments: cc: gash@att.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <28F05913385EAC43AF019413F674A0170167B229@OCCLUST04EVS1.ugd.att.com> (gash@att.com) Precedence: list Other folks have pretty well summarized my feelings on this stuff, and I've said all this in the past, but at the risk of redundancy I'll restate. My problems with the document are as follows: Firstly, the claim that LS protocol collapses are primarily due to deficiencies in the protocol design is just not accurate, and lets the implementors off the hook. While a different protocol design might make such collapses more difficult (or at least different) it can be shown on first principles that the existing protocols as specified can be implemented in such a way that collapse (defined as adjacency loss, which is the symptom at the heart of such collapses) will happen only if the volume of Hello traffic exceeds the capacity of the receiver to sink it and get its own Hellos out the door. If properly implemented, the failure mode under extreme flooding conditions should be to have convergence time suffer (there's no free lunch, of course) and *not* to lose adjacencies. Implementations that suffer from this problem are essentially doomed, since the failure mode is not predictable. If everyone stays lucky, the various workarounds to try to avoid the problem will keep the implementation from falling over the edge, but of course you can't control what your neighbor is doing to you. Secondly, most of what the document describes is not subject to standardization. Discussion of implementation techniques is a fine subject for an informational RFC, and in fact a number of of the mechanisms described are already in use in some implementations and are helpful (as are a bunch of other tricks that provide us with product differentiation.) All of the MUSTs and so forth give a false impression that these techniques are required for protocol correctness and interoperability, which they are not. The fact that these are implementation choices underscores my claim that this is not a protocol design issue, which I define to be the bits on the wire and the elements of procedure that determine interoperability. As far as I can see, there is only one suggestion in this paper that involves a protocol change (the signalling of congestion.) The appendices suffer from an excess of academia. The reality of routing protocol implementations is that analysis and simulation seldom bears any resemblance to reality (not to mention that any vendor-supplied data is likely to be self-serving.) If we could actually predict the behavior of networks of the size proposed, we wouldn't be having collapses--they happen because of what the implementors don't know, the subtle interactions and plain old screwups, which of course won't figure into the analysis and simulation. It's certainly true that backing away from the cliff will help avoid collapse, but the problem with this approach is that you never know where the cliff is. As Joel and others have pointed out, the addition of even more complexity to try to fix problems is unlikely to be satisfying. The industry's history shows that these protocols are on the hairy edge of what people are able to implement in a stable, robust way, and making it even harder is not the path to nirvana. There are also operational complexities involved--if you try to avoid disaster by using parametric mechanisms like limiters and such, you end up in a situation where either values are fixed (based on a wet finger in the air or some empirical testing) or else a bunch of mysterious knobs are provided that nobody has any idea how to set. My whipping boy for this approach is the multivariate SPF rate control knob that was recently added by a major vendor. If you put the product together properly, the SPF rate shouldn't matter, and nobody knows how to set the knob anyhow. I guess my primary point is this--if you build your implementation in such a way that it is close to impossible to lose adjacencies under load conditions, the rest of this stuff is gravy (albeit tasty gravy) but if your implementation can lose adjacencies when it is constipated, none of this will address the real robustness problems. The document operates under the assumption that flooding traffic causes adjacency loss (which is certainly true in many implementations) but it is this issue that is the key to stability--the techniques themselves are band-aids. I don't have any particular problem with the techniques discussed in the document (though in-band congestion notification has been shown to be flawed many years ago--see any of the literature on ICMP Source Quench.) Matter of fact, I use a lot of this stuff. It's just that none of this is really a fix, just a workaround, and the only part of it that I can see that should be in the standards track are the congestion notification extensions. Where these and other techniques are quite valuable is when looking at convergence/recovery times after major network events (other than load- related adjacency collapses which, of course, should never happen.) Expeditious flooding for its own sake is a fine goal indeed. --Dave From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 15:23:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09959 for ; Thu, 7 Nov 2002 15:23:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.007B8424@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 15:26:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330864 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 15:26:04 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 15:16:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) x-msg: NoteWell Message-ID: <200211072011.PAA08965@ietf.org> Date: Thu, 7 Nov 2002 15:11:40 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Note Well Statement To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 18:06:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17356 for ; Thu, 7 Nov 2002 18:06:50 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.007B8CB8@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 18:09:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 331385 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 18:09:17 -0500 Received: from 216.148.227.88 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 18:09:17 -0500 Received: from rwcrwbc69 ([204.127.198.52]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021107230916.JPPU12281.rwcrmhc52.attbi.com@rwcrwbc69> for ; Thu, 7 Nov 2002 23:09:16 +0000 Received: from [12.146.158.112] by rwcrwbc69; Thu, 07 Nov 2002 23:09:16 +0000 X-Mailer: AT&T Message Center Version 1 (Nov 5 2002) X-Authenticated-Sender: ZWxsYW50aUBhdHRiaS5jb20= Message-ID: <20021107230916.JPPU12281.rwcrmhc52.attbi.com@rwcrwbc69> Date: Thu, 7 Nov 2002 23:09:16 +0000 Reply-To: Mailing List Sender: Mailing List From: Manohar Naidu Ellanti Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > Other folks have pretty well summarized my feelings on this stuff, and > I've said all this in the past, but at the risk of redundancy I'll > restate. > > > My problems with the document are as follows: > > Firstly, the claim that LS protocol collapses are primarily due to > deficiencies in the protocol design is just not accurate, and lets the > implementors off the hook. While a different protocol design might > make such collapses more difficult (or at least different) it can be > shown on first principles that the existing protocols as specified can > be implemented in such a way that collapse (defined as adjacency loss, > which is the symptom at the heart of such collapses) will happen only > if the volume of Hello traffic exceeds the capacity of the receiver to > sink it and get its own Hellos out the door. If properly implemented, > the failure mode under extreme flooding conditions should be to have > convergence time suffer (there's no free lunch, of course) and *not* > to lose adjacencies. Implementations that suffer from this problem > are essentially doomed, since the failure mode is not predictable. If > everyone stays lucky, the various workarounds to try to avoid the > problem will keep the implementation from falling over the edge, but > of course you can't control what your neighbor is doing to you. > > > Secondly, most of what the document describes is not subject to > standardization. Discussion of implementation techniques is a fine > subject for an informational RFC, and in fact a number of of the > mechanisms described are already in use in some implementations and > are helpful (as are a bunch of other tricks that provide us with > product differentiation.) All of the MUSTs and so forth give a false > impression that these techniques are required for protocol correctness > and interoperability, which they are not. The fact that these are > implementation choices underscores my claim that this is not a > protocol design issue, which I define to be the bits on the wire and > the elements of procedure that determine interoperability. As far as > I can see, there is only one suggestion in this paper that involves a > protocol change (the signalling of congestion.) > > > The appendices suffer from an excess of academia. The reality of > routing protocol implementations is that analysis and simulation > seldom bears any resemblance to reality (not to mention that any > vendor-supplied data is likely to be self-serving.) If we could > actually predict the behavior of networks of the size proposed, we > wouldn't be having collapses--they happen because of what the > implementors don't know, the subtle interactions and plain old > screwups, which of course won't figure into the analysis and > simulation. It's certainly true that backing away from the cliff will > help avoid collapse, but the problem with this approach is that you > never know where the cliff is. > > > As Joel and others have pointed out, the addition of even more > complexity to try to fix problems is unlikely to be satisfying. The > industry's history shows that these protocols are on the hairy edge of > what people are able to implement in a stable, robust way, and making > it even harder is not the path to nirvana. > > > There are also operational complexities involved--if you try to avoid > disaster by using parametric mechanisms like limiters and such, you > end up in a situation where either values are fixed (based on a wet > finger in the air or some empirical testing) or else a bunch of > mysterious knobs are provided that nobody has any idea how to set. My > whipping boy for this approach is the multivariate SPF rate control > knob that was recently added by a major vendor. If you put the > product together properly, the SPF rate shouldn't matter, and nobody > knows how to set the knob anyhow. > > > I guess my primary point is this--if you build your implementation in > such a way that it is close to impossible to lose adjacencies under > load conditions, the rest of this stuff is gravy (albeit tasty gravy) > but if your implementation can lose adjacencies when it is constipated, > none of this will address the real robustness problems. The document > operates under the assumption that flooding traffic causes adjacency > loss (which is certainly true in many implementations) but it is this > issue that is the key to stability--the techniques themselves are > band-aids. > > I don't have any particular problem with the techniques discussed in the > document (though in-band congestion notification has been shown to be > flawed many years ago--see any of the literature on ICMP Source Quench.) > Matter of fact, I use a lot of this stuff. It's just that none of this > is really a fix, just a workaround, and the only part of it that I can > see that should be in the standards track are the congestion notification > extensions. And no need to address to ways of reducing the LSAs that need to be flooded in a timely manner? When both sides have synced up LSDB then only the link is declared FULL. But all the auxliary information is also exchanged before a l ink is declared FULL. Shouldn't that be part of protocol - to declare adjacency is FULL once basic link/node information is in sync and in the second phase the neighbors can exchange auxiliary information such as link colors etc i.e phased DB exchange. This all This all boils down to seperating the basic functionality from extended functionality which should reduce the congestion. > > Where these and other techniques are quite valuable is when looking at > convergence/recovery times after major network events (other than load- > related adjacency collapses which, of course, should never happen.) > Expeditious flooding for its own sake is a fine goal indeed. > > > --Dave From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 18:17:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17618 for ; Thu, 7 Nov 2002 18:17:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007B8D4D@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 18:20:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 331431 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 18:20:27 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 18:20:26 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA7NKQS59191 for ; Thu, 7 Nov 2002 15:20:26 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id gA7NKQ368904; Thu, 7 Nov 2002 15:20:26 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <20021107230916.JPPU12281.rwcrmhc52.attbi.com@rwcrwbc69> Message-ID: <200211072320.gA7NKQ368904@cirrus.juniper.net> Date: Thu, 7 Nov 2002 15:20:26 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021107230916.JPPU12281.rwcrmhc52.attbi.com@rwcrwbc69> (message from Manohar Naidu Ellanti on Thu, 7 Nov 2002 23:09:16 +0000) Precedence: list And no need to address to ways of reducing the LSAs that need to be flooded in a timely manner? When both sides have synced up LSDB then only the link is declared FULL. But all the auxliary information is also exchanged before a l ink is declared FULL. Shouldn't that be part of protocol - to declare adjacency is FULL once basic link/node information is in sync and in the second phase the neighbors can exchange auxiliary information such as link colors etc i.e phased DB exchange. This all This all boils down to seperating the basic functionality from extended functionality which should reduce the congestion. Deciding when the adjacency is declared FULL has no direct impact on congestion, only on convergence time. Playing games along these lines certainly requires protocol spec changes; whether they are sufficiently worthwhile in OSPFv2 to make such changes is open to debate. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 19:14:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19103 for ; Thu, 7 Nov 2002 19:14:17 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007B8E61@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 19:16:45 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 331535 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 19:16:45 -0500 Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 19:16:45 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA7Mx7T2019055 for ; Thu, 7 Nov 2002 19:16:44 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B56050103E1B3 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 19:16:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Re: OSPF WG Charter Proposal Thread-Index: AcKGu+RR8DsOCu/0EdaixgDAT2iu5g== Message-ID: <28F05913385EAC43AF019413F674A017123E4D@OCCLUST04EVS1.ugd.att.com> Date: Thu, 7 Nov 2002 19:16:44 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALASO" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA19103 It is great to see that there are lots of discussions on the OSPF Scalability issues (including flooding optimization, prioritized treatment of Hellos so as not to lose adjacency under congestion, congestion notification to neighbor and slowing down of control messages based on that, etc.). It appears that people mostly agree that occasionally operational networks do see large scale flooding of control messages or LSA storm (triggered by hardware failure, software bug, faulty operational practice, and so on). (I have personal experience of observing such LSA storms and resulting CPU/Memory congestion). In some cases of large scale flooding of control messages the network may get out of it with little difficulty but we all know that there are also cases that results in failures of many nodes and trunks and loss of traffic which is absolutely unacceptable from an operator's point of view. People might also agree that there is a LSA storm threshold (or "cliff") and a near-simultaneous generation of LSA storm exceeding this threshold (or "cliff") may cause problems. Ideally, this threshold should be as large as the LSA database size even in very large networks (with potentially many ASE LSAs, and many Traffic-Engineering-Related LSAs in upcoming MPLS networks) but in reality that does not appear to be the case. The various proposals for OSPF Scalability improvements are to move the LSA storm threshold (or "cliff") significantly upwards. Some people feel that this should be done only through smart (proprietary) implementation. However, the points against that are the following: 1) It may be OK to rely on the smart proprietary implementation of a vendor if we run a single-vendor network. However, Operators would intend to run multi-vendor networks with standard, non-proprietary solution to scalability problems. As an example, Dave Katz points out that it is very important not to lose adjacencies during congestion. We absolutely agree with that and propose either prioritization of Hello messages (facilitated by special marking) or using Implicit Hello (use any received message over an adjacency for the purpose of keeping it alive) to achieve the same goal in a multi-vendor network. We have also seen large number of retransmissions (default retransmission timer is 5 seconds) as a major cause of congestion and propose prioritizing LSA acknowledgments and slowing down retransmissions during congestion to reduce retransmission traffic. This can perhaps be achieved by a specific vendor in a proprietary way but an Operator would like to see a non-proprietary solution to this problem. 2) It has been argued that some of the protocol extensions being proposed would make it too difficult for vendors to implement it. I don't quite get it. Isn't it also being said that some vendors are already implementing them in a proprietary way ? 3) Some of the protocol extensions proposed are difficult (may be even impossible) to implement in a purely proprietary way. One example is congestion notification (already pointed out by Dave Katz). Another example is flooding over only one of many parallel point-to-point links between neighbors (this is already being done in PNNI in a non-proprietary way). Gagan Choudhury From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 7 23:27:45 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24771 for ; Thu, 7 Nov 2002 23:27:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007B9F2C@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 23:30:02 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332219 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 23:30:01 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 23:30:01 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HP9PS>; Thu, 7 Nov 2002 23:30:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 7 Nov 2002 23:31:49 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Rohit, > We may be talking about different incidents. The one that I was > involved in, was a clear implementation mistake (a case was missed) > which was the root cause. It should have been caught in testing if > somebody had bothered to look at why certain LSAs were being > generated. The excessive flooding was simply the result. I disagree. Would you say pacing isn't essential, and you could do without it? If so I think you may not be right there. It is known(atleast from what I read) that not pacing can be very very dangerous to the network, and I would prefer no one ventures without such mechanisms. > I couldn't say this better than Tony/Joel : "at a certain point > adding more code to an implementation introduces more bugs than > the performance gain is worth". I (like most developers) can attest > to this from first hand experience. I dont agree here either. a) As Jerry stated earlier, a lot of these things have already been done in a proprietry way by vendors. I would want to know how you feel having a standard way would clutter the code while a non-standard way would not? b) I think we have made it clear that we do not intend to fiddle with the protocol in the normal case, that is why we have not followed an approach of basing the flooding on RTT unlike some other protocols. c) I think the matter has an operational requirement and there have been implementations of it(although proprietry) for it, and if read your earlier mail correctly these are a few things you said you are looking for before expanding the charter. Please let me know where you disagree. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 8 02:39:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09261 for ; Fri, 8 Nov 2002 02:39:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.007BA2DD@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 2:42:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332595 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 02:42:03 -0500 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 02:42:03 -0500 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 6E5A15D00D; Fri, 8 Nov 2002 16:42:01 +0900 (JST) References: <008401c284ae$2e9c0cf0$002010ac@infit.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Message-ID: <20021108.164200.05237099.yasu@sfc.wide.ad.jp> Date: Fri, 8 Nov 2002 16:42:00 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Tunnels and OSPF. Comments: To: tal@INFIT.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <008401c284ae$2e9c0cf0$002010ac@infit.com> Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA09261 I may ask somthing stupid, but why the "gif" is not applicable in that case ? from NetBSD gif(4): DESCRIPTION The gif interface is a generic tunnelling pseudo device for IPv4 and IPv6. It can tunnel IPv[46] traffic over IPv[46]. Therefore, there can be four possible configurations. The behavior of gif is mainly based on RFC2893 IPv6-over-IPv4 configured tunnel. Guessing that "recursive routing" is caused by that the intermediate router in the tunnel path can not calculate the tunnels route ... Using gif I guess there would be no trouble with one OSPF instance, without using External route nor redistribute. regards, yasu tal> tal> Sanjai, tal> first of all thank you very much for you comment. tal>   tal> i think you have missed one key item in my question - that is "no externals" tal> should be used. tal> when you talk about more than one process you need redistribution between the tal> processes and of the destination tunnel. tal> the reason that an ASBR solution is not good for us is that we intend to have tal> many tunnels in the AS, so we would have many externals (two for each tunnel), tal> that cannot be summarized and would be added to any router's route rules in tal> the AS. tal>   tal> instead we are looking for an ABR solution, one process - no externals. tal>   tal> Thanks, tal> Tal. tal>   tal> -----Original Message----- tal> From: Sanjai Narain [mailto:narain@RESEARCH.TELCORDIA.COM] tal> Sent: Monday, November 04, 2002 8:10 PM tal> To: OSPF@DISCUSS.MICROSOFT.COM tal> Subject: Re: Tunnels and OSPF. tal> tal>   tal> Tal: One solution that we have successfully tried is to define the VPN as a tal> collection of GRE tunnels. Each GRE tunnel G  is protected by an IPSec tunnel tal> between G's physical interfaces. Now, a new OSPF process is run at each tal> router, distinct from any other OSPF process running there. This process will tal> only see the network of GRE tunnels, and thereby route and reroute only over tal> these. GRE gives OSPF the illusion that tunnel end points are directly tal> connected (as intended), so you get routing over your -secure- overlay nework. tal> The overlay OSPF process must be a new one to avoid routing loops. This is a tal> well known solution and typing GRE/OSPF/IPSec into Google will yield numerous tal> case studies. tal> tal> -- Sanjai Narain tal> tal> Tal Sarfaty wrote: tal> tal> Is it possible to force the traffic flowing between the OSPF backbone and tal> one of the other areas, to go through a tunnel (for VPN purpose for tal> instance)? tal> tal> That is without the use of externals and without the use of static routes tal> of course. tal> tal> The topology can be addressed as a classic " ns = "urn:schemas-microsoft-com:office:smarttags" />Normal areas" "no tal> summary" single OSPF AS, or any other. tal> tal> Note that the naive solution would create a "recursive routing" to the tal> destination address of the tunnel. tal> tal> The last would cause tunnel oscillations. tal> tal> Thanks, tal> tal> Tal. tal> tal> -- tal>    Sanjai Narain tal>    Senior Research Scientist tal>    Telcordia Technologies tal>    445 South Street tal>    Morristown, NJ 07960 tal>    USA tal>    Tel: +1 973 829 4515 Fax: +1 973 829 5888 tal>    Email: narain@research.telcordia.com tal> From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 8 02:49:13 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09719 for ; Fri, 8 Nov 2002 02:49:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.007BA4A8@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 2:51:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332616 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 02:51:42 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 02:51:42 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA87pgS84533 for ; Thu, 7 Nov 2002 23:51:42 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id gA87pgx69866; Thu, 7 Nov 2002 23:51:42 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: Message-ID: <200211080751.gA87pgx69866@cirrus.juniper.net> Date: Thu, 7 Nov 2002 23:51:42 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: (VishwasM@NETPLANE.COM) Precedence: list a) As Jerry stated earlier, a lot of these things have already been done in a proprietry way by vendors. I would want to know how you feel having a standard way would clutter the code while a non-standard way would not? Given that most of this stuff is not subject to standardization, it's unlikely that there will be a "standard" way, for what that's worth. The issue is whether the more complex stuff is worth doing, particularly if the implementation is already robust enough to not collapse under load. b) I think we have made it clear that we do not intend to fiddle with the protocol in the normal case, that is why we have not followed an approach of basing the flooding on RTT unlike some other protocols. Actually, flooding based on RTT can certainly be done without "fiddling with the protocol" (assuming that you mean a normative change.) As long as the packets look right, you can do a whole lot without torquing the standard. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 8 03:52:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10823 for ; Fri, 8 Nov 2002 03:52:21 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.007BA4BC@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 3:54:49 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332709 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 03:54:48 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 03:54:48 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HP9Y0>; Fri, 8 Nov 2002 03:54:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 8 Nov 2002 03:56:46 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Dave, b) I think we have made it clear that we do not intend to fiddle with the protocol in the normal case, that is why we have not followed an approach of basing the flooding on RTT unlike some other protocols. > Actually, flooding based on RTT can certainly be done without > "fiddling with the protocol" (assuming that you mean a normative change.) > As long as the packets look right, you can do a whole lot without > torquing the standard. I agree and we did ponder over this approach. However from a previous note of urs, such failures are non-linear, and using the average RTT's prevents it from responding appropriately to such non-linear storms. Besides there are some other issues, I could discuss with you if you think the approach is worth pursuing. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 8 05:20:15 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12303 for ; Fri, 8 Nov 2002 05:20:15 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.007BA60D@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 5:22:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332856 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 05:22:43 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 05:22:43 -0500 Received: (qmail 589 invoked from network); 8 Nov 2002 10:22:42 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 8 Nov 2002 10:22:42 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DCB9003.50203@xebeo.com> Date: Fri, 8 Nov 2002 11:20:51 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: >Hi Dave, > > b) I think we have made it clear that we do not intend to fiddle with the > protocol in the normal case, that is why we have not followed an approach >of > basing the flooding on RTT unlike some other protocols. > >>Actually, flooding based on RTT can certainly be done without >>"fiddling with the protocol" (assuming that you mean a normative change.) >> As long as the packets look right, you can do a whole lot without >>torquing the standard. >> > >I agree and we did ponder over this approach. However from a previous note >of urs, such failures are non-linear, and using the average RTT's prevents >it from responding appropriately to such non-linear storms. Besides there >are some other issues, I could discuss with you if you think the approach is >worth pursuing. > >Thanks, >Vishwas > Last one from me to the IMHO slightly over-excited crowd that tries to protect protocol-implementors and deployments from themselves by giving them gratuitous amounts of soaped rope (aka. congestion notification): There is an Occam's razor to _routing protocol standardization_ (vs. e.g. implementor agreements' or recommendation group): If you can't observe, quantify and prove it based purely on _white-box_ approach, you cannot standardize it! Lots of the stuff you try to do is impossible to prove on an implementation, e.g. Hello priotization/congestion avoidance cannot be proven to work to your desired specs unless you have probes into queues/CPU usage/link-loss of a system. Summa, you cannot standardize it, you can only recommend it via a BCP or maybe informational draft. Compare this discussion to the bashing Naiming got for the proposal of optional time-stamps and hello sequence numbers on ISIS list (albeit it was for my taste a border case) [footnote: e.g. in contrast, Alex's LSA reorigination spread or even timer jitters can be measured and observed so there are certain recommendations that can be 'standardized' but even then they are mostly just BCP]. I personally think any workgroup chair worth his salt will not let you make this congestion avoidance thingy go into anything close to a standards track, maybe informational but even then, I think your stuff will cause possibly more trouble than gain as a working group item in a _protocol standardization_ working group. And a tad more humility would help a long way as well instead of claiming to save the world here, lots of these stuff is research on shaky simulations following deployed reality, I remember learning stuff like hello priotization and much more from simulations and looking at other people's code 1995 or so. And ultimately for all of us, lots of this stuff is known in theory of non-linear control systems since quite a while, just most people get scared by the math on the few first pages. thanks & tony out -- tony From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 8 07:45:51 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16635 for ; Fri, 8 Nov 2002 07:45:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.007BA87F@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 7:48:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 333327 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 07:48:20 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 07:38:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15840; Fri, 8 Nov 2002 07:35:48 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200211081235.HAA15840@ietf.org> Date: Fri, 8 Nov 2002 07:35:48 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-scalability-02.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Explicit Marking and Prioritized Treatment of Specific OSPF Packets for Faster IGP Convergence and Improved Network Scalability and Stability Author(s) : V. Sapozhnikova, G. Choudhury Filename : draft-ietf-ospf-scalability-02.txt Pages : 15 Date : 2002-11-7 In this draft we propose the following mechanisms to improve the scalability and stability of OSPF-based network: (1) Process the Hello packets at a higher priority compared to other OSPF packets. In order to facilitate this, explicitly mark the Hello packets, to differentiate them from other OSPF packets. One way of special marking is to use a different Diffserv codepoint for Hello packets compared to other OSPF packets. (2) In the absence of special marking, or in addition to it, use other mechanisms in order not to miss Hello packets. One example is to treat any packet received over a link as a surrogate for a Hello packet (an implicit Hello) for the purpose of keeping the link alive. (3) The same type of explicit marking and prioritized treatment may be beneficial to other OSPF packets as well. One important example is LSA acknowledgment packet that can reduce retransmissions during periods of congestion. Other examples include (a) Database description (DBD) packet from a slave that is used as an acknowledgement, and (b) LSAs carrying intra-area topology change information. It is possible that some implementations are already using one or more of the above mechanisms in order not to miss the processing of critical packets during periods of congestion. However, we suggest the above mechanisms to be included as part of the standard so that all implementations can benefit from them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-scalability-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-scalability-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7160325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-scalability-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-scalability-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160325.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 8 10:17:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21797 for ; Fri, 8 Nov 2002 10:17:49 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.007BACBE@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 10:20:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 333646 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 10:20:17 -0500 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 10:20:17 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA8EtIiQ025763 for ; Fri, 8 Nov 2002 09:20:16 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B560501086364 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 10:20:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: I-D ACTION:draft-ietf-ospf-scalability-02.txt Thread-Index: AcKHJSBMtPzXSMzkQu+4RQIgNMODqgAFKyhQ Message-ID: <28F05913385EAC43AF019413F674A017023F6849@OCCLUST04EVS1.ugd.att.com> Date: Fri, 8 Nov 2002 10:20:15 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALASO" Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-02.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA21797 Just wanted to point out that the attached ID has two more authors: Anurag Maunder and Vishwas Manral. Gagan Choudhury -----Original Message----- From: Internet-Drafts@IETF.ORG [mailto:Internet-Drafts@IETF.ORG] Sent: Friday, November 08, 2002 7:36 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: I-D ACTION:draft-ietf-ospf-scalability-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Explicit Marking and Prioritized Treatment of Specific OSPF Packets for Faster IGP Convergence and Improved Network Scalability and Stability Author(s) : V. Sapozhnikova, G. Choudhury Filename : draft-ietf-ospf-scalability-02.txt Pages : 15 Date : 2002-11-7 In this draft we propose the following mechanisms to improve the scalability and stability of OSPF-based network: (1) Process the Hello packets at a higher priority compared to other OSPF packets. In order to facilitate this, explicitly mark the Hello packets, to differentiate them from other OSPF packets. One way of special marking is to use a different Diffserv codepoint for Hello packets compared to other OSPF packets. (2) In the absence of special marking, or in addition to it, use other mechanisms in order not to miss Hello packets. One example is to treat any packet received over a link as a surrogate for a Hello packet (an implicit Hello) for the purpose of keeping the link alive. (3) The same type of explicit marking and prioritized treatment may be beneficial to other OSPF packets as well. One important example is LSA acknowledgment packet that can reduce retransmissions during periods of congestion. Other examples include (a) Database description (DBD) packet from a slave that is used as an acknowledgement, and (b) LSAs carrying intra-area topology change information. It is possible that some implementations are already using one or more of the above mechanisms in order not to miss the processing of critical packets during periods of congestion. However, we suggest the above mechanisms to be included as part of the standard so that all implementations can benefit from them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-scalability-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-scalability-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 8 11:53:26 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27086 for ; Fri, 8 Nov 2002 11:53:26 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.007BAFCA@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 11:55:50 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 333977 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 11:55:50 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 11:55:50 -0500 Received: (qmail 21701 invoked from network); 8 Nov 2002 16:55:49 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 8 Nov 2002 16:55:49 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id LAA21280 for ; Fri, 8 Nov 2002 11:55:49 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200211081655.LAA21280@bigbird.xebeo.com> Date: Fri, 8 Nov 2002 11:55:49 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from "Manral, Vishwas" of "Thu, 07 Nov 2002 23:31:49 EST." Precedence: list Vishwas, Some (final) comments inline - On Thu, 7 Nov 2002 23:31:49 -0500 "Manral, Vishwas" writes: =>Hi Rohit, => =>> We may be talking about different incidents. The one that I was =>> involved in, was a clear implementation mistake (a case was missed) =>> which was the root cause. It should have been caught in testing if =>> somebody had bothered to look at why certain LSAs were being =>> generated. The excessive flooding was simply the result. =>I disagree. Would you say pacing isn't essential, and you could do without =>it? If so I think you may not be right there. It is known(atleast from what =>I read) that not pacing can be very very dangerous to the network, and I =>would prefer no one ventures without such mechanisms. I am simply stating what I saw - unless you something different at the same meltdown, there is nothing to disagree with! => =>> I couldn't say this better than Tony/Joel : "at a certain point =>> adding more code to an implementation introduces more bugs than =>> the performance gain is worth". I (like most developers) can attest =>> to this from first hand experience. => =>I dont agree here either. =>a) As Jerry stated earlier, a lot of these things have already been done in =>a proprietry way by vendors. I would want to know how you feel having a =>standard way would clutter the code while a non-standard way would not? Yes. But then stretching the logic one would specify the use of data structures and algorithms in an implementation. OSPF could mandate that everybody should use "splay trees". And one could prove that splay trees are better than say red-black and avl-trees using specific simulation runs. This would make for a fine conference paper and would qualify as a "standard way of cluttering the code". I don't see why the WG would be in this business. =>b) I think we have made it clear that we do not intend to fiddle with the =>protocol in the normal case, that is why we have not followed an approach of =>basing the flooding on RTT unlike some other protocols. This is not a compelling argument to add something to a protocol. For any protocol spec - it is usually the case that protocol extensions, even in the "non-normal" case effect "normal" processing. Often both in code and in operations. =>c) I think the matter has an operational requirement and there have been =>implementations of it(although proprietry) for it, and if read your earlier =>mail correctly these are a few things you said you are looking for before =>expanding the charter. This is correct. We would be looking for operational input to expand the charter. This is a neccessary but not a sufficient condtion. Regardless, something along these lines _could_ be included in a future revision of the charter (say 6 months from now). Personally I am inclinded towards clearing the deck off the listed charter items before adding items whose inclusion doesn't have a clear consensus. => =>Please let me know where you disagree. => =>Thanks, =>Vishwas Regards, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 8 12:34:37 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00792 for ; Fri, 8 Nov 2002 12:34:37 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.007BB15F@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 12:37:06 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 334118 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 12:37:06 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 12:37:06 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 3C92F39B5A9 for ; Fri, 8 Nov 2002 09:37:05 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200211081655.LAA21280@bigbird.xebeo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DCBF5CF.90907@redback.com> Date: Fri, 8 Nov 2002 12:35:11 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vishwas, Rohit, I'm in complete agreement with Rohit on the issue of adding alternate flooding techniques to the charter. We really need to clean up some of the pending work items as our top priority. I feel it is alright to discuss flooding changes but we really don't have a strong enough requirement to add them to the charter. Note that we currently have a draft which reduses LSA refresh overhead using the OSPF demand circuit extensions. With respect to specification and Internet Drafts that are targeted as standards track, I would like to maintain the same high quality of specification as previous OSPF WG documents (such as RFC 2328). Hence, if we were to decide to standardize a different flooding mechanism, any drafts should specify precisely protocol state machine changes, packet transmission changes, packet reception changes, precisely when flooding will be blocked, etc. IMHO, we should not place loose recommendations in the standards track category. Thanks, Acee Rohit Dube wrote: > Vishwas, > > Some (final) comments inline - > > On Thu, 7 Nov 2002 23:31:49 -0500 "Manral, Vishwas" writes: > =>Hi Rohit, > => > =>> We may be talking about different incidents. The one that I was > =>> involved in, was a clear implementation mistake (a case was missed) > =>> which was the root cause. It should have been caught in testing if > =>> somebody had bothered to look at why certain LSAs were being > =>> generated. The excessive flooding was simply the result. > =>I disagree. Would you say pacing isn't essential, and you could do without > =>it? If so I think you may not be right there. It is known(atleast from what > =>I read) that not pacing can be very very dangerous to the network, and I > =>would prefer no one ventures without such mechanisms. > > I am simply stating what I saw - unless you something different at the > same meltdown, there is nothing to disagree with! > > => > =>> I couldn't say this better than Tony/Joel : "at a certain point > =>> adding more code to an implementation introduces more bugs than > =>> the performance gain is worth". I (like most developers) can attest > =>> to this from first hand experience. > => > =>I dont agree here either. > =>a) As Jerry stated earlier, a lot of these things have already been done in > =>a proprietry way by vendors. I would want to know how you feel having a > =>standard way would clutter the code while a non-standard way would not? > > Yes. But then stretching the logic one would specify the use of data > structures and algorithms in an implementation. OSPF could mandate > that everybody should use "splay trees". And one could prove that > splay trees are better than say red-black and avl-trees using specific > simulation runs. This would make for a fine conference paper and > would qualify as a "standard way of cluttering the code". > > I don't see why the WG would be in this business. > > =>b) I think we have made it clear that we do not intend to fiddle with the > =>protocol in the normal case, that is why we have not followed an approach of > =>basing the flooding on RTT unlike some other protocols. > > This is not a compelling argument to add something to a protocol. For > any protocol spec - it is usually the case that protocol extensions, even > in the "non-normal" case effect "normal" processing. Often both in code > and in operations. > > =>c) I think the matter has an operational requirement and there have been > =>implementations of it(although proprietry) for it, and if read your earlier > =>mail correctly these are a few things you said you are looking for before > =>expanding the charter. > > This is correct. We would be looking for operational input to expand the > charter. This is a neccessary but not a sufficient condtion. > > Regardless, something along these lines _could_ be included in a future > revision of the charter (say 6 months from now). Personally I am inclinded > towards clearing the deck off the listed charter items before adding > items whose inclusion doesn't have a clear consensus. > > => > =>Please let me know where you disagree. > => > =>Thanks, > =>Vishwas > > Regards, > --rohit. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 8 13:24:08 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04906 for ; Fri, 8 Nov 2002 13:24:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.007BB31E@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 13:26:35 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 334339 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 13:26:35 -0500 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 13:26:35 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA8H1noP007291 for ; Fri, 8 Nov 2002 12:26:34 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B56050109C773; Fri, 8 Nov 2002 13:26:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: OSPF WG Charter Proposal Thread-Index: AcKHTXeNc8oZqZEoRAmouwKXQ0rLVwABIO2g Message-ID: <28F05913385EAC43AF019413F674A017123E50@OCCLUST04EVS1.ugd.att.com> Date: Fri, 8 Nov 2002 13:26:33 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALASO" Subject: Re: OSPF WG Charter Proposal Comments: cc: zinin@psg.com, jmoy@sycamorenet.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA04906 Acee, There used to be the following two drafts on Flooding Optimizations and I think they also used to be part of the charter. 1) A. Zinin and M. Shand, "Flooding Optimizations in Link-State Routing Protocols,". 2) J. Moy, "Flooding over Parallel Point-to-Point Links,". Is there any effort to revive those ? Alex, John any of you interested in following up on this ? Gagan Choudhury -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Friday, November 08, 2002 12:35 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF WG Charter Proposal Vishwas, Rohit, I'm in complete agreement with Rohit on the issue of adding alternate flooding techniques to the charter. We really need to clean up some of the pending work items as our top priority. I feel it is alright to discuss flooding changes but we really don't have a strong enough requirement to add them to the charter. Note that we currently have a draft which reduses LSA refresh overhead using the OSPF demand circuit extensions. With respect to specification and Internet Drafts that are targeted as standards track, I would like to maintain the same high quality of specification as previous OSPF WG documents (such as RFC 2328). Hence, if we were to decide to standardize a different flooding mechanism, any drafts should specify precisely protocol state machine changes, packet transmission changes, packet reception changes, precisely when flooding will be blocked, etc. IMHO, we should not place loose recommendations in the standards track category. Thanks, Acee Rohit Dube wrote: > Vishwas, > > Some (final) comments inline - > > On Thu, 7 Nov 2002 23:31:49 -0500 "Manral, Vishwas" writes: > =>Hi Rohit, > => > =>> We may be talking about different incidents. The one that I was > =>> involved in, was a clear implementation mistake (a case was missed) > =>> which was the root cause. It should have been caught in testing if > =>> somebody had bothered to look at why certain LSAs were being > =>> generated. The excessive flooding was simply the result. > =>I disagree. Would you say pacing isn't essential, and you could do without > =>it? If so I think you may not be right there. It is known(atleast from what > =>I read) that not pacing can be very very dangerous to the network, and I > =>would prefer no one ventures without such mechanisms. > > I am simply stating what I saw - unless you something different at the > same meltdown, there is nothing to disagree with! > > => > =>> I couldn't say this better than Tony/Joel : "at a certain point > =>> adding more code to an implementation introduces more bugs than > =>> the performance gain is worth". I (like most developers) can attest > =>> to this from first hand experience. > => > =>I dont agree here either. > =>a) As Jerry stated earlier, a lot of these things have already been done in > =>a proprietry way by vendors. I would want to know how you feel having a > =>standard way would clutter the code while a non-standard way would not? > > Yes. But then stretching the logic one would specify the use of data > structures and algorithms in an implementation. OSPF could mandate > that everybody should use "splay trees". And one could prove that > splay trees are better than say red-black and avl-trees using specific > simulation runs. This would make for a fine conference paper and > would qualify as a "standard way of cluttering the code". > > I don't see why the WG would be in this business. > > =>b) I think we have made it clear that we do not intend to fiddle with the > =>protocol in the normal case, that is why we have not followed an approach of > =>basing the flooding on RTT unlike some other protocols. > > This is not a compelling argument to add something to a protocol. For > any protocol spec - it is usually the case that protocol extensions, even > in the "non-normal" case effect "normal" processing. Often both in code > and in operations. > > =>c) I think the matter has an operational requirement and there have been > =>implementations of it(although proprietry) for it, and if read your earlier > =>mail correctly these are a few things you said you are looking for before > =>expanding the charter. > > This is correct. We would be looking for operational input to expand the > charter. This is a neccessary but not a sufficient condtion. > > Regardless, something along these lines _could_ be included in a future > revision of the charter (say 6 months from now). Personally I am inclinded > towards clearing the deck off the listed charter items before adding > items whose inclusion doesn't have a clear consensus. > > => > =>Please let me know where you disagree. > => > =>Thanks, > =>Vishwas > > Regards, > --rohit. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 8 15:47:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13253 for ; Fri, 8 Nov 2002 15:47:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007BB6EC@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 15:50:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 334686 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 15:50:16 -0500 Received: from 216.136.173.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 15:50:16 -0500 Received: from [192.25.240.225] by web12705.mail.yahoo.com via HTTP; Fri, 08 Nov 2002 12:50:15 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021108205015.2967.qmail@web12705.mail.yahoo.com> Date: Fri, 8 Nov 2002 12:50:15 -0800 Reply-To: Mailing List Sender: Mailing List From: Suvani Kaura Subject: Inter-Area-Router LSAs To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA06A766FB@haritha.hclt.com> Precedence: list Hi All, I was trying to figure out what the use of Options is in the Inter Area Router LSAs. Of the 6 options described by RFC2740, N bit should always be unset (because no summary-4 lsa is generated for NSSA ASBR, acc to the NSSA draft) - conversely E-bit will always be set. That leaves DC/MC/R/V6 bits. RFC 1793 indicates that type-4 LSAs are used as "Indication lsas", by clearing the DC bit of those LSAs. Is there any other use of learning the options of a router in another area? Thanks, Suvani __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From owner-ospf@DISCUSS.MICROSOFT.COM Sat Nov 9 00:04:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01916 for ; Sat, 9 Nov 2002 00:04:09 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.007BC796@cherry.ease.lsoft.com>; Sat, 9 Nov 2002 0:04:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 335786 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 9 Nov 2002 00:04:56 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 9 Nov 2002 00:04:55 -0500 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA954sS67699 for ; Fri, 8 Nov 2002 21:04:54 -0800 (PST) (envelope-from dennis@juniper.net) X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: lists/ospf Mime-Version: 1.0 Content-Type: text/plain Message-ID: <200211090504.gA954sS67699@merlot.juniper.net> Date: Fri, 8 Nov 2002 21:04:54 -0800 Reply-To: Mailing List Sender: Mailing List From: Dennis Ferguson Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of "Thu, 07 Nov 2002 19:16:44 EST." <28F05913385EAC43AF019413F674A017123E4D@OCCLUST04EVS1.ugd.att.com> Precedence: list Hello, I just read draft-ietf-ospf-scalability-02.txt, along with draft-ash-manral-ospf-congestion-control-00.txt which seems to be related, and find I am made a little uncomfortable by the way the problem(s) is being described and hence the inevitability (or even desirability) of the solutions offered. Please excuse me if this has been discussed before; I skimmed and deleted a bunch of messages about this before actually reading the documents and discovering that I cared. > The various proposals for OSPF Scalability improvements are to move > the LSA storm threshold (or "cliff") significantly upwards. Some people > feel that this should be done only through smart (proprietary) > implementation. However, the points against that are the following: I think the LSA storm threshold, or cliff, is not a problem in itself, but rather is a symptom of an underlying problem. Because the problem was not identified explicitly, however, it took some time to figure out what might be causing this cliff (guessed at mostly by working backwards from the proposed solution(s)). The problem which causes this appears to me to actually be that the implementation allowed load from non-adjacency- maintenance traffic (i.e. essentially traffic which wasn't Hellos) to effect adjacency maintenance, in particular by incorrectly dropping adjacencies to routers which were in fact still operating. The problem of erroneously dropping adjacencies to routers which are still up when under (unrelated) stress is the canonical problem which leads to network routing collapse. Just about anyone who has implemented a link state protocol (or any protocol where adjacencies are maintained for that matter, e.g. BGP or PPP), deployed it and watched it break a couple of times knows this by heart, though it is certainly worth writing down for implementors who haven't got this far yet. If you want stable routing then implementations must be done in a way such that this *does* *not* *happen*, that is the implementation must ensure that the cost of spikes in database flooding is paid solely by increased convergence time, and is never the cause of adjacencies being incorrectly declared down. If implementations are done this way then the ultimate scalability of the protocol implementation (beyond data base memory requirements, though data base memory has gotten inordinately cheap these days) is dictated solely by how long you are willing to wait for your network to converge after spikes, and that is a continuous degradation with no "cliff" at all. Now I would simply assert that there is nothing about the OSPF protocol, as currently specified, which prevents implementations from achieving the nirvana described in the previous paragraph. Nothing. It may not be easy to get an implementation to work this way, but I think this difficulty is inherent in the problem that needs to be solved within the (inherently proprietary) real-life environment that the implementation runs inside which sometimes leaves it short of resources, and is hence far removed from the protocol definition itself. Errors which cause adjacencies to be incorrectly declared down are implementation errors, not protocol errors, and are probably best addressed in the implementation which is broken rather than the protocol which isn't. An implementation which doesn't work like the previous paragraph is one which still has bugs in need of fixing. So while I like the simulations done in the scalability draft a lot, I'll just point out how this draft seems to go given the assumptions and views above: (1) You did simulations using an OSPF implemention which had a bug, in that it unnecessarily and erroneously declared adjacencies down in the presence of a spike of (non-Hello, not adjacency related) data base traffic. How you came to the conclusion that implementations which don't make this error are "proprietary" while the particular implementation you simulated which made this error is not, I don't understand. (2) Rather than addressing the problem within your implementation, you elected to try to solve the problem by having the implementation's neighbours help out by setting some new bits in packets (i.e. a protocol change) to assist in a prioritization scheme. I don't mind this, except to note that changing an established protocol and then waiting for everyone to catch up to the change is usually the least productive, longest-term way to fix bugs in an implementation which has router neighbours from multiple vendors it is relying on to do this for a "fix". (3) You then redid the simulations after the "fix" was applied, and found that while there was still a cliff the "fix" had moved it up and to the right. That is, despite the fact that you even went to the trouble of making a protocol change, the "fix" still didn't actually fix the problem, which is that you have a cliff at all. The routing failure can apparently still occur, the danger of your network routing melting is still there, it just apparently needs a much bigger event to set it off. This is telling me that, independent of this, you really need to look at the implementation you are simulating with and determine what's actually wrong with it, as it is still an accident waiting to happen. But, more important than this, note that the above comments are still based on speculation about the root cause of the problem, since according to the draft the problem is a "cliff" and that the fix is to move the cliff up and to the right, and it is hard to relate any of this to the underlying protocol. You really, really must identify what the routers are actually doing wrong, in words rather than from numerical simulation results, since if you don't understand and present this your readers will never understand the spectrum of possible fixes and why they should work. For example, if the problem really is one of routers erroneously dropping adjacencies where the neighbour is still up, then prioritization of Hello packet reception and processing seems like not a bad way to help keep this from occurring (we can debate whether this is better done by a protocol change or by just having the routers look at the OSPF packet type before queuing), since its effect is to keep adjacency errors from occuring by spending CPU keeping this accurate before spending CPU doing anything which can be deferred. It is far from the only way to help, however. For example, another way to help fix this (perhaps in addition to the above) might be for the routers to observe when they've been under load, with a long queue of work to do that they've perhaps been dropping packets off the end of, and to defer making any decisions to drop adjacencies until after this condition clears. This still makes errors about the state of adjacencies, but changes the nature of the errors from one where the errors you make are terminating adjacencies which are really still up, which can melt your network, to one where the errors you make are concluding adjacencies might still be up when they have in fact gone down, a temporary booboo whose sole effect might be to increase convergence time (which is how you should be paying for load spikes in any event). Note that this adds robustness (i.e. probably is the best you can do in the circumstance) not only when you are getting too many LSAs, but also when you are temporarily too short of CPU to even keep up to the incoming Hellos. There are a lot of ways to address this particular problem (if this actually is the "cliff" problem) in implementations, enough that your implementation really shouldn't have "cliff" problems to begin with, and you should just keep fixing the implementation until the "cliff" problems go away so you don't have to live in fear that something big will happen which will cause your network routing to melt and fail to recover. This is so fundamental that I wouldn't wait for the wide deployment of protocol changes to ensure that this is fixed (even if protocol changes were exceptionally useful, which I doubt), but would just get it fixed in the implementations you've already got talking to the other routers you've already got. Once you've got basic reliability thing out of the way you can then begin to look at addressing the real scaling problem which remains, which is convergence time and maximizing the size of the network you can have while still having it converge in acceptably short periods. This is the problem which I think might benefit from protocol changes, both related to minimizing flooding load and otherwise. It is just important to be clear on why these changes are being done as well, for about the same reasons it is important to understand what a "cliff" problem is, that is you'll never get the right answer without being very clear about why you're doing it. For example, sending a lot of unnecessary retransmissions to a neighbour should never, ever cause that neighbour to break (if it does he's the one with the problem needing fixing), but it is still not a good thing to do since it makes everyone work harder and that is guaranteed to slow convergence. The latter thing is still very much worth fixing, you just shouldn't be doing the fixing to hack around implementation-robustness "cliff" problems. To cut this short, then, I'll just point out what I wanted to say in the first place about the congestion draft, which is that in general I don't think using rate controls ever works right given the problem which I think this should be addressing. The problem with rate controls is that if they are fixed configuration they're always wrong, while if they're automatically adjustable you need to compute adjustments slowly to ensure stability, which in turn means that the rate you compute is usually wrong for current circumstances. It is either too high or too low. In the case of flooding to neighbours, both of these cases are bad. Sending too fast is bad, not because it will break anything (it absolutely shouldn't) but because processing a big queue of stale stuff, perhaps with accompanying spurious retransmissions, makes everyone work harder than they need to and delays convergence. Sending too slow, however, is also bad because it puts you in the incredibly silly situation of having an unconverged network where the routers are simultaneously idle some of the time, which slows convergence for no discernable advantage at all. I hence, without having thought enough about it, like schemes which attempt to do window control (i.e. limit the number of outstanding, un-acked LSAs instead), using the delay of and rate at which acks come back as the control signal, if only because there are examples of transport protocols working like this which exhibit both stability and a fairly quick response to changes. In the case of the SPF computation, however, imposing standardized rate limits on the maximum frequency with which an implementation may compute this just seems irrational, and makes no sense at all unless the implementation entirely lacks the ability to prioritize its actions, an attribute which is certainly not universal and is unlikely to lead to great success in making any of this stuff work reliably. I mean, if a router is one SPF computation away from converging its routing, and knows it has absolutely nothing else to do at the moment, is there any rational reason to require it to sit idle for the four seconds to some timer expiry before actually doing it? I think most implementations should be able to figure out for themselves when it is a good idea to run the Dykstra and when it isn't, and so should retain the freedom to do this. So I think the "congestion" draft has some good ideas (I also like other attempts to find ways to minimize flooding work) but seems confused about why these are good ideas which makes some of its other ideas not-so-good, while the "scalability" draft is proposing a protocol change to relieve (but not entirely fix) a mysterious problem which, if better defined, might turn out to be a classic adjacency maintenance implementation bug which is fixable with no protocol changes at all. I think the latter draft would be a whole lot better (in fact, would be really, really great) if, instead of making a protocol change, you instead did and documented whatever was necessary to make the "cliff" disappear entirely from your simulation implementation without making protocol changes, at which point the (convergence) scaling problem the former draft should probably be aimed at addressing would be a lot clearer. Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Sat Nov 9 00:12:12 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02008 for ; Sat, 9 Nov 2002 00:12:11 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.007BC78C@cherry.ease.lsoft.com>; Sat, 9 Nov 2002 0:14:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 335818 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 9 Nov 2002 00:14:36 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 9 Nov 2002 00:14:36 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA95EZS67848 for ; Fri, 8 Nov 2002 21:14:35 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id gA95EZL72829; Fri, 8 Nov 2002 21:14:35 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <200211090504.gA954sS67699@merlot.juniper.net> Message-ID: <200211090514.gA95EZL72829@cirrus.juniper.net> Date: Fri, 8 Nov 2002 21:14:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200211090504.gA954sS67699@merlot.juniper.net> (message from Dennis Ferguson on Fri, 8 Nov 2002 21:04:54 -0800) Precedence: list Dennis makes my points much more clearly than I, and without the bad attitude. Thanks. (And we didn't even collude.) From owner-ospf@DISCUSS.MICROSOFT.COM Sat Nov 9 02:28:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13569 for ; Sat, 9 Nov 2002 02:28:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.007BCDEE@cherry.ease.lsoft.com>; Sat, 9 Nov 2002 2:31:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 336065 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 9 Nov 2002 02:31:20 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 9 Nov 2002 02:31:20 -0500 Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18AQ5O-000KK4-00; Fri, 08 Nov 2002 23:31:18 -0800 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <28F05913385EAC43AF019413F674A017123E50@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2275709939.20021108233030@psg.com> Date: Fri, 8 Nov 2002 23:30:30 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPF WG Charter Proposal Comments: To: "Choudhury, Gagan L, ALASO" Comments: cc: jmoy@sycamorenet.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <28F05913385EAC43AF019413F674A017123E50@OCCLUST04EVS1.ugd.att.com> Precedence: list Content-Transfer-Encoding: 7bit Gagan- [wg-member hat on] The charter already has 3 drafts that need to be finished and where I act as a co-author. Given my workload these days, adding more would be an obvious over-commitment on my side. Besides, the WG charter already has enough, I believe. Let's get something done first. There's two fine solutions to the problem, people can pick either of them and interoperate with no issues, so no hurry to get em RFC'ed. -- Alex Friday, November 08, 2002, 10:26:33 AM, Choudhury, Gagan L, ALASO wrote: > Acee, > There used to be the following two drafts on Flooding Optimizations and I think they also used to be part of the charter. > 1) A. Zinin and M. Shand, "Flooding Optimizations in Link-State > Routing Protocols,". > 2) J. Moy, "Flooding over Parallel Point-to-Point Links,". > Is there any effort to revive those ? Alex, John any of you interested in following up on this ? > Gagan Choudhury From owner-ospf@DISCUSS.MICROSOFT.COM Mon Nov 11 12:42:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25630 for ; Mon, 11 Nov 2002 12:42:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.007C1EBF@cherry.ease.lsoft.com>; Mon, 11 Nov 2002 12:45:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 344256 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 11 Nov 2002 12:45:10 -0500 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 11 Nov 2002 12:45:09 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gABGxvkQ012757 for ; Mon, 11 Nov 2002 11:45:10 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B5605011A3B77 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 11 Nov 2002 12:45:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: OSPF WG Charter Proposal Thread-Index: AcKHrcK9KaWiOExTQ+y8b/iUH8+fHQB+7Cvg Message-ID: <28F05913385EAC43AF019413F674A017023F684D@OCCLUST04EVS1.ugd.att.com> Date: Mon, 11 Nov 2002 12:45:08 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALASO" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA25630 Dennis, Thanks for your message and taking the time to read our draft. You point out very correctly that adjacencies should not be taken down in the presence of a spike of (non-Hello, not adjacency related) data base traffic (i.e., LSUs). I suspect that you do it by looking at the OSPF packet header and if you find it to be a Hello then you process it ahead of other packets (LSUs). This way even if there is a large spike of LSUs, you never miss Hello and keep the adjacency up. We call this "Prioritized Treatment to Hello Packets". We are not doubting that you do it but since it is not stated explicitly in OSPF we feel that it is important to explicitly point out the importance of "Prioritizing Hello Packets". We suggest use of special marking so that Hello packets can be easily separated from LSUs and it would be easy to prioritize them. However, even without special marking if you can easily separate out Hello packets and process them ahead of LSUs then that is perfectly alright. We did the simulation study to show what happens if Hellos are processed at the same priority as incoming LSUs (and so can get behind many LSUs under congestion), we did not mean to say "implementations always do this". In fact we say in the abstract that some implementations are perhaps already prioritizing Hellos in order to not lose adjacency but we want all implementations to do them. In the simulation as we prioritized Hello we saw that adjacencies were never declared down (as expected). However, at a larger LSA storm threshold there were a large number of Retransmissions which caused sustained heavy congestion at a subset of the node processors (the ones with high adjacency). (We used fixed retransmission timer values of 5 seconds or 10 seconds throughout the simulation). In this case even though links were not being declared down, the sustained heavy congestion due to retransmissions is unacceptable and so we call this a "cliff" even though it is not as harmful as losing adjacencies. We show by simulations that the retransmission traffic may be reduced significantly (and therefore the "cliff" moved to the right significantly) by prioritizing Acknowledgment packets. However, this is not necessarily the only solution. There are beneficial effects of slowing down retransmissions under congestion as well (those simulation results are not reported yet). Again, we are not saying that implementations do not take any special measures to reduce retransmission traffic under heavy congestion. However, these special measures are not spelled out explicitly in OSPF but are important enough for explicit mention so that all implementations can benefit from it. You wondered the cause of the problem or LSA storm (near synchronous update of a very large number of LSAs). It can be caused by one/more link failures, one/more node failures, sudden synchronization/generation of a large number of LSAs (just by coincidence or even triggered by some software bug or improper operational procedure). The problem happens very rarely but it does happen. Also, it is a problem only in large networks with say hundreds of nodes, thousands of trunks, very high adjacency at some nodes, and very large number of LSAs, e.g., large number of ASE LSAs or large number of LSAs that carry link reserved bandwidth information (similar to traffic-engineering LSAs). Gagan Choudhury -----Original Message----- From: Dennis Ferguson [mailto:dennis@JUNIPER.NET] Sent: Saturday, November 09, 2002 12:05 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF WG Charter Proposal Hello, I just read draft-ietf-ospf-scalability-02.txt, along with draft-ash-manral-ospf-congestion-control-00.txt which seems to be related, and find I am made a little uncomfortable by the way the problem(s) is being described and hence the inevitability (or even desirability) of the solutions offered. Please excuse me if this has been discussed before; I skimmed and deleted a bunch of messages about this before actually reading the documents and discovering that I cared. > The various proposals for OSPF Scalability improvements are to move > the LSA storm threshold (or "cliff") significantly upwards. Some people > feel that this should be done only through smart (proprietary) > implementation. However, the points against that are the following: I think the LSA storm threshold, or cliff, is not a problem in itself, but rather is a symptom of an underlying problem. Because the problem was not identified explicitly, however, it took some time to figure out what might be causing this cliff (guessed at mostly by working backwards from the proposed solution(s)). The problem which causes this appears to me to actually be that the implementation allowed load from non-adjacency- maintenance traffic (i.e. essentially traffic which wasn't Hellos) to effect adjacency maintenance, in particular by incorrectly dropping adjacencies to routers which were in fact still operating. The problem of erroneously dropping adjacencies to routers which are still up when under (unrelated) stress is the canonical problem which leads to network routing collapse. Just about anyone who has implemented a link state protocol (or any protocol where adjacencies are maintained for that matter, e.g. BGP or PPP), deployed it and watched it break a couple of times knows this by heart, though it is certainly worth writing down for implementors who haven't got this far yet. If you want stable routing then implementations must be done in a way such that this *does* *not* *happen*, that is the implementation must ensure that the cost of spikes in database flooding is paid solely by increased convergence time, and is never the cause of adjacencies being incorrectly declared down. If implementations are done this way then the ultimate scalability of the protocol implementation (beyond data base memory requirements, though data base memory has gotten inordinately cheap these days) is dictated solely by how long you are willing to wait for your network to converge after spikes, and that is a continuous degradation with no "cliff" at all. Now I would simply assert that there is nothing about the OSPF protocol, as currently specified, which prevents implementations from achieving the nirvana described in the previous paragraph. Nothing. It may not be easy to get an implementation to work this way, but I think this difficulty is inherent in the problem that needs to be solved within the (inherently proprietary) real-life environment that the implementation runs inside which sometimes leaves it short of resources, and is hence far removed from the protocol definition itself. Errors which cause adjacencies to be incorrectly declared down are implementation errors, not protocol errors, and are probably best addressed in the implementation which is broken rather than the protocol which isn't. An implementation which doesn't work like the previous paragraph is one which still has bugs in need of fixing. So while I like the simulations done in the scalability draft a lot, I'll just point out how this draft seems to go given the assumptions and views above: (1) You did simulations using an OSPF implemention which had a bug, in that it unnecessarily and erroneously declared adjacencies down in the presence of a spike of (non-Hello, not adjacency related) data base traffic. How you came to the conclusion that implementations which don't make this error are "proprietary" while the particular implementation you simulated which made this error is not, I don't understand. (2) Rather than addressing the problem within your implementation, you elected to try to solve the problem by having the implementation's neighbours help out by setting some new bits in packets (i.e. a protocol change) to assist in a prioritization scheme. I don't mind this, except to note that changing an established protocol and then waiting for everyone to catch up to the change is usually the least productive, longest-term way to fix bugs in an implementation which has router neighbours from multiple vendors it is relying on to do this for a "fix". (3) You then redid the simulations after the "fix" was applied, and found that while there was still a cliff the "fix" had moved it up and to the right. That is, despite the fact that you even went to the trouble of making a protocol change, the "fix" still didn't actually fix the problem, which is that you have a cliff at all. The routing failure can apparently still occur, the danger of your network routing melting is still there, it just apparently needs a much bigger event to set it off. This is telling me that, independent of this, you really need to look at the implementation you are simulating with and determine what's actually wrong with it, as it is still an accident waiting to happen. But, more important than this, note that the above comments are still based on speculation about the root cause of the problem, since according to the draft the problem is a "cliff" and that the fix is to move the cliff up and to the right, and it is hard to relate any of this to the underlying protocol. You really, really must identify what the routers are actually doing wrong, in words rather than from numerical simulation results, since if you don't understand and present this your readers will never understand the spectrum of possible fixes and why they should work. For example, if the problem really is one of routers erroneously dropping adjacencies where the neighbour is still up, then prioritization of Hello packet reception and processing seems like not a bad way to help keep this from occurring (we can debate whether this is better done by a protocol change or by just having the routers look at the OSPF packet type before queuing), since its effect is to keep adjacency errors from occuring by spending CPU keeping this accurate before spending CPU doing anything which can be deferred. It is far from the only way to help, however. For example, another way to help fix this (perhaps in addition to the above) might be for the routers to observe when they've been under load, with a long queue of work to do that they've perhaps been dropping packets off the end of, and to defer making any decisions to drop adjacencies until after this condition clears. This still makes errors about the state of adjacencies, but changes the nature of the errors from one where the errors you make are terminating adjacencies which are really still up, which can melt your network, to one where the errors you make are concluding adjacencies might still be up when they have in fact gone down, a temporary booboo whose sole effect might be to increase convergence time (which is how you should be paying for load spikes in any event). Note that this adds robustness (i.e. probably is the best you can do in the circumstance) not only when you are getting too many LSAs, but also when you are temporarily too short of CPU to even keep up to the incoming Hellos. There are a lot of ways to address this particular problem (if this actually is the "cliff" problem) in implementations, enough that your implementation really shouldn't have "cliff" problems to begin with, and you should just keep fixing the implementation until the "cliff" problems go away so you don't have to live in fear that something big will happen which will cause your network routing to melt and fail to recover. This is so fundamental that I wouldn't wait for the wide deployment of protocol changes to ensure that this is fixed (even if protocol changes were exceptionally useful, which I doubt), but would just get it fixed in the implementations you've already got talking to the other routers you've already got. Once you've got basic reliability thing out of the way you can then begin to look at addressing the real scaling problem which remains, which is convergence time and maximizing the size of the network you can have while still having it converge in acceptably short periods. This is the problem which I think might benefit from protocol changes, both related to minimizing flooding load and otherwise. It is just important to be clear on why these changes are being done as well, for about the same reasons it is important to understand what a "cliff" problem is, that is you'll never get the right answer without being very clear about why you're doing it. For example, sending a lot of unnecessary retransmissions to a neighbour should never, ever cause that neighbour to break (if it does he's the one with the problem needing fixing), but it is still not a good thing to do since it makes everyone work harder and that is guaranteed to slow convergence. The latter thing is still very much worth fixing, you just shouldn't be doing the fixing to hack around implementation-robustness "cliff" problems. To cut this short, then, I'll just point out what I wanted to say in the first place about the congestion draft, which is that in general I don't think using rate controls ever works right given the problem which I think this should be addressing. The problem with rate controls is that if they are fixed configuration they're always wrong, while if they're automatically adjustable you need to compute adjustments slowly to ensure stability, which in turn means that the rate you compute is usually wrong for current circumstances. It is either too high or too low. In the case of flooding to neighbours, both of these cases are bad. Sending too fast is bad, not because it will break anything (it absolutely shouldn't) but because processing a big queue of stale stuff, perhaps with accompanying spurious retransmissions, makes everyone work harder than they need to and delays convergence. Sending too slow, however, is also bad because it puts you in the incredibly silly situation of having an unconverged network where the routers are simultaneously idle some of the time, which slows convergence for no discernable advantage at all. I hence, without having thought enough about it, like schemes which attempt to do window control (i.e. limit the number of outstanding, un-acked LSAs instead), using the delay of and rate at which acks come back as the control signal, if only because there are examples of transport protocols working like this which exhibit both stability and a fairly quick response to changes. In the case of the SPF computation, however, imposing standardized rate limits on the maximum frequency with which an implementation may compute this just seems irrational, and makes no sense at all unless the implementation entirely lacks the ability to prioritize its actions, an attribute which is certainly not universal and is unlikely to lead to great success in making any of this stuff work reliably. I mean, if a router is one SPF computation away from converging its routing, and knows it has absolutely nothing else to do at the moment, is there any rational reason to require it to sit idle for the four seconds to some timer expiry before actually doing it? I think most implementations should be able to figure out for themselves when it is a good idea to run the Dykstra and when it isn't, and so should retain the freedom to do this. So I think the "congestion" draft has some good ideas (I also like other attempts to find ways to minimize flooding work) but seems confused about why these are good ideas which makes some of its other ideas not-so-good, while the "scalability" draft is proposing a protocol change to relieve (but not entirely fix) a mysterious problem which, if better defined, might turn out to be a classic adjacency maintenance implementation bug which is fixable with no protocol changes at all. I think the latter draft would be a whole lot better (in fact, would be really, really great) if, instead of making a protocol change, you instead did and documented whatever was necessary to make the "cliff" disappear entirely from your simulation implementation without making protocol changes, at which point the (convergence) scaling problem the former draft should probably be aimed at addressing would be a lot clearer. Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 13 03:12:13 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24382 for ; Wed, 13 Nov 2002 03:12:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.007C821A@cherry.ease.lsoft.com>; Wed, 13 Nov 2002 3:14:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 350472 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 13 Nov 2002 03:14:44 -0500 Received: from 203.199.83.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 13 Nov 2002 03:04:44 -0500 Received: (qmail 11628 invoked by uid 510); 13 Nov 2002 08:04:18 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 13 Nov 2002 08:04:18 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20021113080418.11627.qmail@webmail16.rediffmail.com> Date: Wed, 13 Nov 2002 08:04:18 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Nssa Forwarding address To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Why such a requirement? What scenario or network topology it takes care of? Nssa Draft 11(Section 3.4) Originating Type-7 LSAs: "If an NSSA originates a Type-5 LSA with a forwarding address which is part of the NSSA, it should also originate a Type-7 LSA into the NSSA." thanks, krishna __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 13 03:50:52 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24912 for ; Wed, 13 Nov 2002 03:50:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.007C811C@cherry.ease.lsoft.com>; Wed, 13 Nov 2002 3:53:24 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 350552 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 13 Nov 2002 03:53:23 -0500 Received: from 203.199.83.146 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 13 Nov 2002 03:53:23 -0500 Received: (qmail 5581 invoked by uid 510); 13 Nov 2002 08:53:11 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 13 Nov 2002 08:53:11 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20021113085311.5580.qmail@webmail24.rediffmail.com> Date: Wed, 13 Nov 2002 08:53:11 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Nssa (P-bit Policy Paradox) To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Is there any proposed solution to overcome this paradox. thanks, krishna __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 13 05:59:24 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27327 for ; Wed, 13 Nov 2002 05:59:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.007C836A@cherry.ease.lsoft.com>; Wed, 13 Nov 2002 6:01:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 351804 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 13 Nov 2002 06:01:31 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 13 Nov 2002 06:01:31 -0500 Received: from SMIRTORAW2K (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id gADB1QO00803 for ; Wed, 13 Nov 2002 03:01:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Wed, 13 Nov 2002 03:01:26 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Nssa Forwarding address To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021113080418.11627.qmail@webmail16.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Krishna > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of > Krishna Rao > Sent: Wednesday, November 13, 2002 12:04 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Nssa Forwarding address > > > Hi, > Why such a requirement? What scenario or network > topology it takes care of? > > Nssa Draft 11(Section 3.4) > Originating Type-7 LSAs: > "If an NSSA originates a Type-5 LSA with a forwarding address > which is part of the NSSA, it should also originate a Type-7 LSA > into the NSSA." R3--------------R4 | | | | ABR1 ABR2 | NSSA | | | R1-------------R2 If ABR1 generate a type 5 LSA for N with a FA part of NSSA area, a given router (R4) will send a packet to FA in order to reach N so if the path to FA goes through NSSA area the packet will be dropped since ABR1 did not generate type 7 LSA for N in other word if R4 goes over R4-ABR2-R2-R1-ABR1 to reach FA, R2 will drop the packet Sina > > thanks, > krishna > > > __________________________________________________________ > Give your Company an email address like > ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! > Know more. http://www.rediffmailpro.com/signup/ From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 13 06:33:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27835 for ; Wed, 13 Nov 2002 06:33:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.007C8594@cherry.ease.lsoft.com>; Wed, 13 Nov 2002 6:35:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 352168 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 13 Nov 2002 06:35:42 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 13 Nov 2002 06:35:42 -0500 Received: from SMIRTORAW2K (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id gADBZfO03199 for ; Wed, 13 Nov 2002 03:35:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Wed, 13 Nov 2002 03:35:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Nssa (P-bit Policy Paradox) To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021113085311.5580.qmail@webmail24.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit krishna > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of > Krishna Rao > Sent: Wednesday, November 13, 2002 12:53 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Nssa (P-bit Policy Paradox) > > > Hi, > Is there any proposed solution to overcome this > paradox. > one solution could be to use type-7 to type-5 translation in order to import some prefix into NSSA area therefore there will not be a need to advertise same prefix in both NSSA and external to NSSA area if there is a need to annouce a prefix in both NSSA and outside of NSSA you could advertise say a metric type-1 for prefix outside of NSSA in that case the traffic from outside of NSSA will not be hijacked into NSSA ( since type-1 metric will be prefered over type-2 metric advertised in NSSA ). however the reverse still can occur if the path through NSSA router goes over the ABR, the traffic will go outside of NSSA area which may be acceptable if we consider that NSSA has limited resources ... Sina > thanks, > krishna > __________________________________________________________ > Give your Company an email address like > ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! > Know more. http://www.rediffmailpro.com/signup/ From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 13 13:17:56 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11411 for ; Wed, 13 Nov 2002 13:17:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.007C9A2E@cherry.ease.lsoft.com>; Wed, 13 Nov 2002 13:20:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 353461 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 13 Nov 2002 13:20:29 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 13 Nov 2002 13:20:29 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KOTDNXGTZK8X1I34@omega7.wr.usgs.gov> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 13 Nov 2002 10:20:27 -0700 (PDT) X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM X-VMS-Cc: PMURPHY,ospf_query@REDIFFMAIL.COM MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KOTDNXGVVM8X1I34@omega7.wr.usgs.gov> Date: Wed, 13 Nov 2002 10:20:27 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Nssa (P-bit Policy Paradox) Comments: cc: OSPF_QUERY@REDIFFMAIL.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Krishna, Regarding > Hi, > Is there any proposed solution to overcome this > paradox. > Recall the example in Appendix E. AS 4156 | Area 2 | | A2 A0 Area 0 C0-----Internet | | | Default | | | | | | +-----------------B0---------------+ /\ / \ / \ Internet------------A1 B1------AS 4156 (P-bit clear) Default (P-bit set) NSSA 1 A2 wants access to the networks of AS 4156 through A0. A1 wants access to the networks of AS 4156 through B1. Traffic from both A2 and A1 to AS 4156 must pass through B0. The point of the paradox is that the vanilla OSPF deployment will make a hijacking forwarding choice on B0 unless one compromises A1's preferred path to AS 4156 though B1. Any proposed solution would require a forwarding decision based on the inbound area source, whereas OSPF forwards traffic based on destination address only. This simple example could be resolved by configuring a preferred tunnel adjacency between A1 and B1 through B0 and then tweaking the external metrics (as Sina suggests) so that A0's Type 5 LSAs are more preferred on B0 than B1's Type 7 LSAs. This is not a solution, just a cluge. Pat From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 22 04:01:26 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20757 for ; Fri, 22 Nov 2002 04:01:11 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.007F23AC@cherry.ease.lsoft.com>; Fri, 22 Nov 2002 4:03:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 386254 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 22 Nov 2002 04:03:10 -0500 Received: from 203.199.83.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 22 Nov 2002 04:03:09 -0500 Received: (qmail 31825 invoked by uid 510); 22 Nov 2002 09:02:35 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 22 Nov 2002 09:02:35 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20021122090235.31824.qmail@webmail16.rediffmail.com> Date: Fri, 22 Nov 2002 09:02:35 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Forwarding Address To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I have a doubt as to, in what sequence a NSSA ASBR decides a forwarding address for the Type-7 lsa: Reference : NSSA draft 11 Section 3.3 ------------ 1)If the network between the NSSA AS boundary router and the adjacent AS is advertised into OSPF as an internal OSPF route, the forwarding address should be the next hop address as is currently done with Type-5 LSAs. 2)If the intervening network is not advertised into OSPF as an internal OSPF route and the Type-7 LSA's P-bit is set, a forwarding address should be selected from one of the router's active OSPF interface addresses which belong to the NSSA. 3)When a router is forced to pick a forwarding address for a Type-7 LSA, precedence should be given first to the router's loopback addresses (provided internal addressing is supporte). 4)If a loopback address is not used and the selected forwarding address's interface transitions to a Down state (see OSPF Section 9.3), one must select a new forwarding address for any Type-7 LSAs which reference the previously selected forwarding address and then re-originate these Type-7 LSAs. 5)If internal addresses are not available, preference should be given to the router's active OSPF stub network addresses to avoid the possible extra hop of a transit network's address. Q1) Does steps 1,2 apply at NSSA ASBR which will originally originate the lsa? Q2) Are steps 3,4,5 meant for NSSA ABR which does the translation of Type-7 lsa to Type-5 lsa? What does term "forced" means here. My understanding is that these steps only apply for ASBR, since ABR will just ignore the Type-7 lsa with 0.0.0.0 forwarding address. Q3) If my above understandig is wrong, what is the correct sequence. Thanks in advance, krishna __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 22 08:23:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24468 for ; Fri, 22 Nov 2002 08:23:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007F2F97@cherry.ease.lsoft.com>; Fri, 22 Nov 2002 8:25:00 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 387564 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 22 Nov 2002 08:25:00 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 22 Nov 2002 08:25:00 -0500 Received: from smirtoraw2k01 (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAMDOwO16557 for ; Fri, 22 Nov 2002 05:24:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Message-ID: <000501c2922a$8e3847d0$5938fe90@amer.cisco.com> Date: Fri, 22 Nov 2002 05:24:57 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Forwarding Address To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021122090235.31824.qmail@webmail16.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Krishna, > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM] On > Behalf Of Krishna Rao > Sent: Friday, November 22, 2002 1:03 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Forwarding Address > > > Hi, > I have a doubt as to, in what sequence a NSSA ASBR decides a > forwarding address for the Type-7 lsa: > > Reference : NSSA draft 11 > Section 3.3 > ------------ > 1)If the network between the NSSA AS boundary router > and the adjacent AS is advertised into OSPF as an internal > OSPF route, the forwarding address should be the next hop > address as is currently done with Type-5 LSAs. > > 2)If the intervening network is not advertised into OSPF as > an internal OSPF route and the Type-7 LSA's P-bit is set, a > forwarding address should be selected from one of the > router's active OSPF interface addresses which belong to the NSSA. > > 3)When a router is forced to pick a forwarding address for a > Type-7 LSA, precedence should be given first to the router's > loopback addresses (provided internal addressing is supporte). > > 4)If a loopback address is not used and the selected > forwarding address's interface transitions to a Down state > (see OSPF Section 9.3), one must select a new forwarding > address for any Type-7 LSAs which reference the previously > selected forwarding address and then re-originate these Type-7 LSAs. > > 5)If internal addresses are not available, preference > should be given to the router's active OSPF stub network > addresses to avoid the possible extra hop of a transit > network's address. > > Q1) Does steps 1,2 apply at NSSA ASBR which > will originally originate the lsa? Yes > > Q2) Are steps 3,4,5 meant for NSSA ABR which does the > translation of Type-7 lsa to Type-5 lsa? No to the ASBR, when an ABR translate a type 7 to 5 , FA is kept intact. The only time ABR will change the FA is when there is an agregation and the FA ( for the summary ) will be set to zero > What does term "forced" means here. When the P bit is set, an ASBR should ( is forced to) pick up a FA for that type 7 ( otherwise no translation will occur ) If P bit is not set the setting of FA is optional and it is actually better to set the FA to zero ( in case a loopback address cannot be chosen as FA ) > My understanding is that these steps only apply > for ASBR, since ABR will just ignore the Type-7 > lsa with 0.0.0.0 forwarding address. Yes it applies to ASBR Sina > > Q3) If my above understandig is wrong, what is the > correct sequence. > > Thanks in advance, > > krishna > > > > > __________________________________________________________ > Give your Company an email address like > ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! > Know more. http://www.rediffmailpro.com/signup/ > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Nov 25 18:57:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01846 for ; Mon, 25 Nov 2002 18:57:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.007FA9A3@cherry.ease.lsoft.com>; Mon, 25 Nov 2002 19:00:02 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 401056 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 25 Nov 2002 19:00:02 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 25 Nov 2002 18:50:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01535; Mon, 25 Nov 2002 18:47:18 -0500 (EST) Message-ID: <200211252347.SAA01535@ietf.org> Date: Mon, 25 Nov 2002 18:47:18 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list The IESG has received a request from the Open Shortest Path First IGP Working Group to consider Traffic Engineering Extensions to OSPF Version 2 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 26, 2002 Files can be obtained via http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt From owner-ospf@DISCUSS.MICROSOFT.COM Wed Nov 27 15:50:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27474 for ; Wed, 27 Nov 2002 15:50:06 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00800531@cherry.ease.lsoft.com>; Wed, 27 Nov 2002 15:52:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 410902 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 27 Nov 2002 15:52:41 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 27 Nov 2002 15:52:41 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 1B7952848AA for ; Wed, 27 Nov 2002 12:52:39 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010708020906090908000808" Message-ID: <3DE53168.3050601@redback.com> Date: Wed, 27 Nov 2002 15:56:08 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: 55th IETF OSPF WG Minutes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------010708020906090908000808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks to Dimitri Papadimitriou for taking the minutes. I've done some slight editting. Please send corrections directly to me (e.g., if you feel you were misquoted). In the coming weeks, Rohit and I will follow up on unfinished items. The Web page should be updated with the new charter shortly. Thanks, --- Acee --------------010708020906090908000808 Content-Type: text/plain; name="ospf2_minutes.txt" Content-Disposition: inline; filename="ospf2_minutes.txt" Content-Transfer-Encoding: 7bit OSPF WG meeting - Thursday 22nd of november - 15:00-17:00 ========================================================= Document status (Acee Lindem and Rohit Dube): --------------- - RFC 3101 (not-so-stubby-area) currently in final RFC editorship - traffic engineering extensions to ospf v2 (a.k.a. ospf-te) pass the working group last call (completed) - ietf wide last call to be soon issued - hitless restart, last call to be issued on the v04.txt (and this very quickly) - Detecting Inactive Neighbors over OSPF Demand Circuits (draft-ietf-ospf-dc-05.txt) is pending and is waiting for wg chair comments - OSPF Refresh and flooding reduction in stable topologies (draft-pillay-esnault-ospf-flooding-04.txt) needs a couple of edits sections but no significant changes - Alternative OSPF ABR Implementations (draft-ietf-ospf-abr- alt-05.txt) in the comment cycle, it is pretty much done and the last call to be issued pretty quickly - min-update-05.txt, may want to add the graceful restart capabilities Agenda bashing -------------- - Acee Lindem: propose to move hitless restart after Kireeti presentation - Kireeti Kompella: agrees On the Agenda: ------------- 1) Rahul Aggarwal (10 Mins): Extensions to IS-IS and OSPF for Advertising Optional Router Capabilities http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt Summary: -------- several changes to this i-d since the last meeting, 1. review of the motivation and benefits - mpls-te (and related) capability discovery mechanism - network management and trouble shooting options field is not extensible thus something generic needed 2. ospf router information lsa - optional router information lsa of type 4 and opaque ID 0 - the format of the tlv's in the body of the router info information lsa is the same as the tlv format used for the te lsa's - optional tlv must be included as the router capability sub-tlv (flags representing the capabilities), sub-tlv allows for adding additional information flags in the future depending on the needs 3. router capability bits - see i-d 4. conclusion - applicability through router local policy - optional mechanism Discussion: ----------- Alex Zinin: ? Acee Lindem: LSA option bits limited thus to be extended with the sub-tlv Rohit Dube: Mailing list comments nothing on the list to the question on how it fits into the charter, there is no specific charter item for that purpose, but for instance, opaque lsa is listed as item into the charter Rahul Aggarwal: proposal is made here to pass some information through the use of opaque lsa Acee Lindem: separate the capabilities to extend each of the capabilites Alex Zinin: which part of this work is within the charter? thus confrontation of this work wrt to the charter needs to be covered in addition to an iana consideration section Rahul Aggarwal: agrees Alex Zinin: fifo better std based w/ expert review before the codepoint allocation by the iana (no arbitrary stuff) experimental values to be also considered here Tom Petch: negotiation before exchange these opaque lsa ? as a first step ? Rahul Aggarwal: usage is a local matter, and also avoid the use of negotiation Dimitri Papadimitriou: what are the te mesh groups mentioned in this i-d ? what is behind traffic-engineering ? are we sure that the underlying concepts are well cooked ? what are the relation with TEWG, the current i-d covers one of the application of TE, but generic mechanism can also be considered that overlaps with GMPLS-OSPF Rahul Aggarwal: troubleshooting and specific application such as path computation server, may need additional work Alex Zinin: refers to the previous comments made during the previous meeting it seems that other wg participants prefers the usage of other mechanism to deliver such capability Kireeti Kompella: agrees Rohit Dube: people that oppose may not necessarily be here Rahul Aggarwal: will send another mail for discussion in order to see where in which direction this i-d has to go after this meeting ========================================================== 2) Kunihiro Ishiguro (15 Mins): OSPFv3 Traffic Engineering Extensions http://www.ietf.org/internet-drafts/draft-ishiguro-ospf-ospfv3-traffic-01.txt Summary: - using the proposed framework, proposes an intra-area -te lsa with function code 10, flooding scope is area wide scope, u bit set to 1, thus if the router does not understand lsa it must be flooded anyway - ospfv3 te tlv, katz i-d used as a basement tlv thus the router address and the link tlv are considered here for the ospfv3 router lsa, Acee Lindem: there is an alternate proposal to be discussed thus comments to come after Alex Zinin: router id related question - reachable address because it can be signalled thus what are the signalling implication related to the proposed change Kunihiro Ishiguro: not sure at this moment and depends upon the implementation Kireeti Kompella: does ipv6 provided with a router addressable and/or reachable address ? Kunihiro Ishiguro: depends upon the implementation Kireeti Kompella: take for instance, bgp over ipv6 what do you advertize as the next hop ? Kunihiro Ishiguro: ? Acee Lindem: it can be the router_id Kireeti Kompella: router address tlv has been proposed to sync up isis and ospf topologies, and as used in bgp today (to connect bgp with an incoming lsp request), the missing thing here is that links can be unnumbered and thus the point of the router id (the router address that it identifies) is that it needs to be globally unique or defined as unique wide address or sometimes it may be routable thus the same think is needed with v6 Kunihiro Ishiguro: this comes from the traffic engineering implementation and or bgp, here a "stable ip address is not needed" but for traffic engineering purposes it seems to be. Alex Zinin: wrt to ospfv3 it seems that we change the semantic of the protocol, in ospv2, this address is a reachable ip address, in ipv6 this is not the case, thus if things are different they should be kept separated in order to maintain the consistency and the semantic of the ospfv3 protocol Acee Lindem: questions about the semantic of the router_id Kireeti Kompella: this is the router address tlv ========================================================== 3) Acee Lindem (5 Mins): OSPF Hitless Restart Update http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-03.txt note: version -04.txt posted to list Summary: ------- - Hitless restart i-d of j.moy, Acee Lindem acts as editor for this document and has an implementation for the interoperability testing - Changes from 03->04 . grace period restricted to the lsa refresh . alt to saving crypto seq numbers in non-volatile storage . alternate help mode temrination . always flood to 224.0.0.5 in the case of unplanned restart which is important since a router loss the knwoledge of being previsouly elected as a designated router . remove mospf, from future work and add less conservative helper termination - Proposed change: add alternative to the grace lsa to all neighbor adjacency for orinating router (Padma Pillay-Esnault). This only applies to the case where there are parallel adjacenncies - appears to be fully compatible as long as the grace lsa flooded through all the interfaces. Discussion: ---------- Acee Lindem: thus ready for last call ? will let some weeks for comments Alex Zinin: interoperability tests available ? Acee Lindem: redback is interoperable with juniper (not tried the implementation of j.moy), Force10 also has an implementation. Padma: Implementation between Juniper and Force10 tested. ========================================================== 4) Kireeti Kompella (10 Mins): OSPFv2 Opaques in OSPFv3 http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt Summary: -------- 1. ospfv2 compared to the ospfv3 opaque lsa format 2. proposal to migrate ospfv2 in ospfv3, move the lsa function code into the lsa type, everything else remains the same: the lsa id is the same and the opaque lsa info is the same. 3. Issue with the backdoor problem - yes this is a backdoor but why it is a problem ? 4. Related question ? is ospfv3 for ipv6 (only) or an improvment of ospfv2 ? thus we should be able to run an ipv4 network with ospfv3 ? - if so ospfv3 is a superset of ospfv2 - if not remove all the ipv4 prefix infromation from v3 Consider ospfv3 as superset of ospfv2 - then we can migrate properly from v2 to v3 - if not all sorts of functions will break during the migration Alternative: - define a new lsa function for each of the opaque lsa type: one for te lsa, one for the grace lsa etc. - what's the length of the opaque id ? 24 or 32 bits ? but this would break the migration 5. Conclusion pros and cons for v2 opaque lsa in v3 - pros: code reuse v3 includes v2, migration - cons: theoritcal backdoor issue pros and cons for translating opaque lsa one-by-one - pro: ? - con: would make the migration less pragmatic Next steps: we need to understand what's this backdoor problem is weight, the pro and cons and make a pragmatic decision (to have an opaque lsa ready code) Discussion: ---------- Alex Zinin: questions about ospfv3 for ipv4 ? Acee Lindem: not described in the current RFC Alex Zinin: thus not to be used for the arguments ? since this is an orthogonal problem: announce ipv4 information using ospfv3 does not make sense Kireeti Kompella: the inverse is done today Alex Zinin: do we agree ? Kireeti Kompella: yes Alex Zinin: opaque type ? Kireeti Kompella: opaque lsa, this is a v2 opaque lsa Alex Zinin: have a single level of numbering Kireeti Kompella: this implies to change the code - do you know how long it takes ? Alex Zinin: yes and i try to simplyify the code we use Kireeti Kompella: the code to use is very simple, look at the opaque type... Alex Zinin: what's problem we try to solve ? Kireeti Kompella: new opaque type in ospfv3 and useful for ospfv2 as well since i do not want to change my code for interoperability reasons Alex Zinin: no difference between the two proposals, thus which one to select Kireeti Kompella: want to do it once (for all) Alex Zinin: with the proposal you grab the function code in ospfv3, the only difference here is, v2 in v3, by doing that you create an overlap specification space and please think about the implication Rohit Dube: ospf for ipv6 is a different protocol from v2 in terms of a model it should be considered as different protocols Kireeti Kompella: thus ospfv3 not used for ipv4 Alex Zinin: thus we don't use it for discussion Kireeti Kompella: make a statement, if the protocols are different then state this in the corrresponding document Rohit Dube: could you clarify your point Kireeti Kompella: since ipv4 in ospfv3 is not specified, i will make the clarification in order to allow for that; by analogy, rsvp can use ipv6 identification over ipv4 everything is ready except the opsfv2 document while people ask this from my side, thus this is a real problem and not a theoretical problem as the backdoor one Alex Zinin: the working group should decide what to do, but Alex'concerns with this approach is that it will create potential problem while not solving the intended problem - thus a cleaner approach should be privileged Acee Lindem: this is not a brand new application thus i agree with Alex Alex Zinin: things must always be specificed Kunihiro Ishiguro: type 9 is already used by v2, Kireeti Kompella: types 9 10 and 11 they map in the value 22 in v3, meaning it is a v2 opaque lsa, but the backdoor problem is there anyway Rohit Dube: this problem will be further discussed on the mailing lists ========================================================== 5) Jerry Ash (10 Mins): Congestion Avoidance & Control for OSPF Neworks http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt Summary: -------- 1. introduction: draft addresses the probem of scalability and failure experience of vendors analyzing their own ospf implementations: analysis of the lsa stroms problems 2. background and motivation 3. failure experience: failure experience in 4/13/98 in the att frame relay network 4. Proposed protocol mechanism: signal a congestion state, to become to a specific ospf protocol processing during the congestion detection, the neighbors will be advertized about the slowdown and adjust the flooding rate 5. Lot's of discussion on the list - is there a problem ? Initiate a debate on how to solve the problem, the protocol is complete as it is, and these problem will be resolved by having better implementations but opeators asks for interoperable implementations this is the reason for these i-d's Thus proposal to go beyond this and go to a procedure for that purpose ? potential re-use of the grace restart procedure ? are other mechanisms (re-)usable or definable ? Concerning the approach of better coding ? does it solves the problem but in the mean time we think that the better standard between vendors would be to solve these issues Discussion: ---------- Padma: concerning the protocol extensions, grace lsa is not necessarily applicable since a restarting router is not a (necessarily) a congested router; are these to be considered as real protocol extensions (like for instance the throttling) or just more fine tuned implementations ? Jerry Ash: sometimes you can and sometimes it wouldn't be appropriate Rohit Dube: move discussions after the second presentation Acee Lindem: but keep track of the charter concerning the hello's ========================================================== 6) Gagan L. Choudhury (10 Mins): Explicit Marking and Prioritized Treatment of Specific OSPF Packets for Faster Convergence and Improved Network Scalability and Stability http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-02.txt Summary: ------- 1. Basic issue: failures in the network generating sustained cpu usage, lsa storms, and positive feedback loops 2. Proposal: priority for the hello and the ack's the question is how to deliver it, ask for having this as bcp, for instance diffserv codepoints for high priority and another for low priority 3. Simulation study: three priority scenarios, and two network scenarios, tested with 2 LSA scenaros show graphic(s) on the non converged lsa's vs the lsa storm (in seconds) to represent the strenght of the lsa storm (the actual curves) show graphic(s) illustrating that priority allows for pacing the storm but until a certain threshold only and if the usage of priority for acks is also provided this theshold is higher in all cases, the usage of priorities there is an improvment for the sustainted cpu usage 4. Proposal: use of special marking (at least a to become a bcp) and use of it for the prioritization of the hellos Discussion: ---------- Gagan Choudhury: should we move to the next one Acee Lindem: yes ========================================================== 7) Gagan L. Choudhury (10 Mins) LSA Flooding Optimization Algorithms and their Simulation Study http://www.ietf.org/internet-drafts/draft-choudhury-manral-flooding-simulation-00.txt Summary: ------- 1. How to improve this threshold significantly 2. Basic issue: in very large networks an lsa storm a sustained cpu congestion may appear 3. Flooding algos to be considered: - algo1: lsa flooding over all interfaces - algo2: lsa flooding over only one - algo3: full flooding at mp relays to the immediate neighbors Alex Zinin: algo3 does not guarantee the reliability of the flooding - algo4: flooding only along a minimum spanning tree - algo5: algo2 for non-te (topological) lsa's and algo4 for the te lsa's Alex Zinin: we can't use all of them or a selection 4. Simulation results: . presentation of the five different cases each analyzed with the allowed lsa storm size . observations on the flooding algorithms 5. Conclusion: algo2, algo5 and modified algo5 should be pursued further Discussion: ---------- Alex Zinin (as wg member): algo5 doesn't appear to be robust, can you explain in which context you propose it ? Gagan Choudhury: ? Alex Zinin (as wg member): an atm switch fails, while the ip router is unaware of the routing topology, how does it work ? Gagan Choudhury: network watches for any link and node failure but here we speak about the flooding link (...) Alex Zinin: referring to previous mailing list discussion, flooding trees generates problem when a single link fail, there is a lot of topology activity here, raising potential multiple trees Gagan Choudhury: during the failure, basic lsa's can carry the needed information Alex Zinin: which lsa's are flooded ? Gagan Choudhury: only the ones that are strictly needed Alex Zinin: it is not always safe to say there is no topology info exchange with more efficient flooding algo's, resyncing neighbors may be heavy... something equivalent to isis Acee Lindem: basic flooding paradigm with proposed techniques seems reasonable but anything beyond this is questionable ? Gagan Choudhury: agress Acee Lindem: we would like to see a proposal which is bate Acee Lindem: explicit marking, already in 1812, all spf packets to be send, we can't say we have to do something but precisely explain what to do (in case) Gagan Choudhury: agrees, bcp and explicit marking needs more details Rohit Dube: to be a bit stronger, priority of hellos, acks, use of other packet for the reset timer; all of these can be done without any protocol changes, to be abstracted and added as a wg i-d; everything else should be included in a separate document, Gagan Choudhury: agrees Jerry Ash: not only a bcp but also needs for an explicit notification mechaniusm Rohit Dube: bcp talks about hellos and acks, and this seems to be agreed, everything requiring protocol changes (such as flooding) should be discussed spearataly Jerry Ash: proposed to start with the ecn Rohit Dube: propose a vote concering the ecn Acee Lindem: (describing the concensus) clearly more people against Padma Pillay-Esnault: understand the congestion problems but most of these are related to bugs and implementation issues, the extensions are not really implementation-based solution since they can generate other problems; thus proposes to take them in offline discussions to be tackled by the implementation. Alex Zinin: ec notification and ec detection also needs mailing list discussion, people are afraid of specifying the implementation details, and believes that we don't have to go to these two extremes, (bits on the wire only versus implementation details), Alex would like to open the discussion concerning these very dynamic behaviours ========================================================== Rohit Dube: charter update =========================== Summary: ------- Charter update has been sent out on the list Selection criteria are as follows: - rough consensus on the list - technical quality of these i-ds - urgency of the item - charter proposal pending for a bit (queue up) Done things: ----------- - opsf for ipv6 - nssa update - ospf-te extensions To do list: ---------- - see proposal Dropped: ------- - mospf - ospf flooding reduction note: to be reconsidered in case of strong need Discussion: ---------- Alex Zinin: IPv6 meeting today on "site local" issues. Site border work not needed for now. Rohit Dube: Will submmit the chrter to these i-ds Acee Lindem: if there is something to be done/removed it should be done, for instance the capability i-d and some other draft as well ** end of the meeting ** --------------010708020906090908000808-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 28 06:25:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25463 for ; Thu, 28 Nov 2002 06:25:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.008019CE@cherry.ease.lsoft.com>; Thu, 28 Nov 2002 6:28:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 412950 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 28 Nov 2002 06:28:40 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 28 Nov 2002 06:28:40 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRAZ9>; Thu, 28 Nov 2002 06:28:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 28 Nov 2002 06:30:43 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: OSPFv2 MIB To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I was reading thru the minutes which talked about mib-update-05. While discussing the v3-MIB with Dan, we had some more issues along with the hitless for the OSPFv2 MIB. I thought it may be helpful to put them on list here. 1. We may want to deprecate the ospfExtLsdbTable and instead have a new ospfAsLsdbTable table like in the V3-MIB. There is no table for type-11's rite now. 2. We would want a counter for ExtLSACount besides the ASLSACount for the DBOverflow purposes. 3. The draft http://www.ietf.org/internet-drafts/draft-ietf-ospf-nssa-update-11.txt talks about configuring "external route tag" we would want to add that to the AreaAggregateTable. 4. Besides that for hitless restart we could want objects in the neighbor table a) hitless restart interval - got in the grace LSA b) hitless restart state - whether helper or not c) hitless restart exit reason - restart complete - topology change - indication from restarting router - timer expiry(restart not completed in given time). d) hitless restart time remaining - if the neighbor is acting as a helper 5. Besides that in the general group we could want a configureable hitless restart interval - to be used when we r going hitless restart 6. I did try to reach Spencer G. but the mails to the address specified seem to bounce off, any idea of how we could get to him? These are all I could dig out, I will check if I have missed out anything. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Thursday, November 28, 2002 2:26 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: 55th IETF OSPF WG Minutes Thanks to Dimitri Papadimitriou for taking the minutes. I've done some slight editting. Please send corrections directly to me (e.g., if you feel you were misquoted). In the coming weeks, Rohit and I will follow up on unfinished items. The Web page should be updated with the new charter shortly. Thanks, --- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 28 06:40:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25735 for ; Thu, 28 Nov 2002 06:40:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00801A53@cherry.ease.lsoft.com>; Thu, 28 Nov 2002 6:43:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 413000 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 28 Nov 2002 06:43:29 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 28 Nov 2002 06:43:29 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRA5V>; Thu, 28 Nov 2002 06:43:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 28 Nov 2002 06:45:37 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi folks, I was going thru the OSPFv3 RFC which in section it states that "In IPv6, the calculation of the next hop's IPv6 address (which will be a link-local address) proceeds along the same lines as the IPv4 next hop calculation (see Section 16.1.1 of [Ref1])." I think this is not correct. After carefully reading the RFC I figured out that Link-LSA's can have global scope IPv6 addresses too. I see no reason why we cannot have global addresses as next hop. Besides for some conditions of redistribution we may require global scope addresses for nexthop. Any opinions? Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 28 07:57:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27062 for ; Thu, 28 Nov 2002 07:57:31 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00801CB3@cherry.ease.lsoft.com>; Thu, 28 Nov 2002 8:00:15 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 413176 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 28 Nov 2002 08:00:15 -0500 Received: from 209.202.115.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 28 Nov 2002 07:50:15 -0500 Received: (qmail 28966 invoked from network); 28 Nov 2002 12:56:05 -0000 Received: (ofmipd 138.120.105.122); 28 Nov 2002 12:55:43 -0000 Received: from alcatel.com ([138.120.45.165]) by camail02.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id H6AEBN00.3SE for ; Thu, 28 Nov 2002 07:50:11 -0500 X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3DE61103.649AD7CC@alcatel.com> Date: Thu, 28 Nov 2002 07:50:11 -0500 Reply-To: Mailing List Sender: Mailing List From: Chamkaur Dhaliwal Subject: ABR questions To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, I have a question about ABR. Suppose you have the following configuration: --------------R5---- -------------------- | AREA 0 | AREA 1 | | | R6 | |-------------R3----- ---------------------- Router R5 and R6 are in area 0 Router R6 is in area 1 and is connect to both R3 and R5. That means there are two ABRs between area 0 and 1. Next I configure same area ranges on both R5 and R3. That means both R5 and and R3 will generate Type 3 LSA into area 1. How should R6 handle the both LSAs which advertising the same network. Thanks. Regards, Chamkaur From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 28 08:13:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27343 for ; Thu, 28 Nov 2002 08:13:27 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00801CC2@cherry.ease.lsoft.com>; Thu, 28 Nov 2002 8:16:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 413270 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 28 Nov 2002 08:16:12 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 28 Nov 2002 08:16:12 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRA8Y>; Thu, 28 Nov 2002 08:16:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 28 Nov 2002 08:18:02 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: ABR questions To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Chamkaur, To start off, areas are not configured on a router basis but on a per interface basis. If you check sections 16.2 and 16.3 of RFC2328, the issues will become clearer. If a router is an ABR, only backbone summary LSA's are examined otherwise all summary LSA's in the area are examined. Besides only-intra-area routes are summarized to the area-0, while intra/inter-area routes are advertized into other areas. However if we have two LSA's advertizing the same network, check section 16.2 point (7) i.e. the smaller cost is kept. Thanks, Vishwas -----Original Message----- From: Chamkaur Dhaliwal [mailto:chamkaur.dhaliwal@ALCATEL.COM] Sent: Thursday, November 28, 2002 6:20 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: ABR questions Hi, I have a question about ABR. Suppose you have the following configuration: --------------R5---- -------------------- | AREA 0 | AREA 1 | | | R6 | |-------------R3----- ---------------------- Router R5 and R6 are in area 0 Router R6 is in area 1 and is connect to both R3 and R5. That means there are two ABRs between area 0 and 1. Next I configure same area ranges on both R5 and R3. That means both R5 and and R3 will generate Type 3 LSA into area 1. How should R6 handle the both LSAs which advertising the same network. Thanks. Regards, Chamkaur From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 28 23:33:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10777 for ; Thu, 28 Nov 2002 23:33:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00802F85@cherry.ease.lsoft.com>; Thu, 28 Nov 2002 23:36:13 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 414620 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 28 Nov 2002 23:36:13 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 28 Nov 2002 23:36:13 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 9A4121B77A6 for ; Thu, 28 Nov 2002 20:35:05 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050109070102030205000008" Message-ID: <3DE6EF3A.9030709@redback.com> Date: Thu, 28 Nov 2002 23:38:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Updated 55th IETF OSPF WG Meeting Minutes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------050109070102030205000008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've incorporated comments and made some corrections and edits. Thanks, -- Acee --------------050109070102030205000008 Content-Type: text/plain; name="ietf55-ospf-wg-minutes.txt" Content-Disposition: inline; filename="ietf55-ospf-wg-minutes.txt" Content-Transfer-Encoding: 7bit OSPF WG meeting - Thursday 22nd of november - 15:00-17:00 ========================================================= Document status (Acee Lindem and Rohit Dube): --------------- - RFC 3101 (Not-So-Stubby-Area) currently in final RFC editorship - Traffic engineering extensions to OSPF v2 (a.k.a. OSPF-TE) passed the working group last call (completed) - IETF wide last call to be issued soon. - Hitless restart - 04 version to be issued soon. Expect to have WG last call on this version. - Detecting Inactive Neighbors over OSPF Demand Circuits (draft-ietf-ospf-dc-05.txt) is pending and is pending wg chair comments. - OSPF Refresh and flooding reduction in stable topologies (draft-pillay-esnault-ospf-flooding-04.txt) needs a couple of edits but no significant changes. - Alternative OSPF ABR Implementations (draft-ietf-ospf-abr- alt-05.txt) in the comment cycle, it is pretty much done and the last call will be issued pretty quickly - mib-update-05.txt - May want to add the graceful restart capabilities Agenda bashing -------------- - Acee Lindem: Propose to move hitless restart after Kireeti presentation. - Kireeti Kompella: Agrees On the Agenda: ------------- 1) Rahul Aggarwal (10 Mins): Extensions to IS-IS and OSPF for Advertising Optional Router Capabilities http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt Summary: -------- Several changes to this i-d since the last meeting. 1. Review of the motivation and benefits - MPLS-TE (and related) capability discovery mechanism - Network management and trouble shooting options are not extensible thus something generic needed 2. OSPF router information LSA - Optional router information LSA of type 4 and opaque ID 0 - Format of the TLV's in the body of the router info information lsa is the same as the TLV format used for the TE LSA's - Optional TLV must be included as the router capability sub-TLV (flags representing the capabilities), sub-TLV allows for adding additional information flags in the future depending on the needs 3. Router capability bits - see i-d 4. Conclusion - Application through router local policy - Flooding scope dependent on application Discussion: ----------- Acee Lindem: LSA option bits limited thus to be extended with the sub-TLV Rohit Dube: No mailing list comments so far. How will this fit into the charter? Right now there is not a specific item. Rahul Aggarwal: Proposal is made here to pass some information through the use of opaque LSA. Alex Zinin: Which part of this work is within the charter? Thus confrontation of this work wrt to the charter needs to be covered in addition to an IANA consideration section. Rahul Aggarwal: Agrees Alex Zinin: FIFO allocation better std based with expert review before the codepoint allocation by the iana (no arbitrary stuff) experimental values to be also considered here. Tom Petch: Negotiation before exchange these opaque LSAs? as a first step? Rahul Aggarwal: Usage is a local matter, and also avoids the use of negotiation. Dimitri Papadimitriou: What are the TE mesh groups mentioned in this i-d? What is behind traffic-engineering? Are we sure that the underlying concepts are well cooked? What are the relation with TEWG, the current i-d covers one of the application of TE, but generic mechanism can also be considered that overlaps with GMPLS-OSPF. Rahul Aggarwal: Troubleshooting and specific application such as path computation server, may need additional work. Alex Zinin: Refers to the previous comments made during the previous meeting it seems that other WG participants prefers the usage of other mechanism to deliver such capability. Kireeti Kompella: Agrees Rohit Dube: People that oppose may not necessarily be here Rahul Aggarwal: Will send another mail for discussion in order to see where in which direction this i-d has to go after this meeting. ========================================================== 2) Kunihiro Ishiguro (15 Mins): OSPFv3 Traffic Engineering Extensions http://www.ietf.org/internet-drafts/draft-ishiguro-ospf-ospfv3-traffic-01.txt Summary: - Using the proposed framework, proposes an intra-area TE LSA with function code 10, flooding scope is area wide scope, u bit set to 1, thus if the router does not understand LSA it must be flooded anyway. - OSPFv3 TE TLV, katz i-d used as a base. TLV thus the router address and the link TLV are considered here for the OSPFv3 router LSA. Acee Lindem: There is an alternate proposal to be discussed thus comments to come after. Alex Zinin: Router id related question - reachable address because it can be signalled thus what are the signalling implication related to the proposed change? Kunihiro Ishiguro: Not sure at this moment and depends upon the implementation. Kireeti Kompella: Does IPv6 provide a addressable and/or reachable address? Kunihiro Ishiguro: Depends upon the implementation Kireeti Kompella: Take for instance, BGP over ipv6 what do you advertize as the next hop? Acee Lindem: It can be the router-id in IPv4. Kireeti Kompella: Router address TLV has been proposed to sync up ISIS and OSPF topologies, and as used in BGP today (to connect BGP with an incoming LSP request), the missing thing here is that links can be unnumbered and thus the point of the router id (the router address that it identifies) is that it needs to be globally unique or defined as unique wide address or sometimes it may be routable thus the same thing is needed with v6. Kunihiro Ishiguro: This comes from the traffic engineering implementation and or BGP, here a "stable IP address is not needed" but for traffic engineering purposes it seems to be. Alex Zinin: WRT to OSPFv3 it seems that we change the semantic of the protocol, in OSPFv2, this address is a reachable IP address, in ipv6 this is not the case, thus if things are different they should be kept separate in order to maintain the consistency and the semantic of the ospfv3 protocol. Acee Lindem: Questions about the semantic of the router-id. Kireeti Kompella: This is the router address TLV. ========================================================== 3) Acee Lindem (5 Mins): OSPF Hitless Restart Update http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-03.txt note: version -04.txt posted to list Summary: ------- - Hitless restart i-d of J. Moy, Acee Lindem acts as editor for this document and has an implementation for the interoperability testing. Padma Pillary-Ensault is also an author with an implementation. - Changes from 03->04 . Grace period restricted to the LSA refresh time . Alternative to saving crypto seq numbers in non-volatile storage . Alternate help mode termination (ignore LSA changes under configuration control) . Always flood to 224.0.0.5 in the case of unplanned restart which is important since a router loses the knwoledge of being previsouly elected as a designated router . Remove mospf, from future work and add less conservative helper termination - Proposed change: Add alternative to apply the grace LSA to all neighbor adjacencies for orinating router (Padma Pillay-Esnault). This only applies to the case where there are parallel adjacenncies - appears to be fully compatible as long as the grace LSA is flooded on all interfaces. Discussion: ---------- Acee Lindem: Thus ready for last call? Will re-issue the draft for comments and wait a couple weeks. Alex Zinin: Interoperability tests available? Acee Lindem: Redback is interoperable with Juniper (not tried the Moy's implementation), Force10 also has an implementation. Padma: Implementation between Juniper and Force10 tested. ========================================================== 4) Kireeti Kompella (10 Mins): OSPFv2 Opaques in OSPFv3 http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt Summary: -------- 1. OSPFv2 compared to the OSPFv3 opaque LSA format 2. Proposal to migrate OSPFv2 opaque to OSPFv3, Use new OSPFv3 LSA type, everything else remains the same; the LSA ID is the same and the opaque LSA info is the same. 3. Issue with the backdoor problem - yes this is a backdoor but why it is a problem? 4. Related question? Is OSPFv3 for IPv6 (only) or an improvment of OSPFv2? Thus we should be able to run an IPv4 network with OSPFv3? - If so OSPFv3 is a superset of OSPFv2 - If not remove all the IPv4 prefix infromation from v3 Consider OSPFv3 as superset of OSPFv2 - Then we can migrate properly from v2 to v3 - If not all sorts of functions will break during the migration Alternative: - Define a new lsa function for each of the opaque LSA type: one for TE LSA, one for the grace LSA, etc. - What's the length of the opaque id? 24 or 32 bits? But this would break the migration 5. Conclusion Pros and cons for v2 opaque lsa in v3 - Pros: Code reuse v3 includes v2, migration - Cons: Theoritcal backdoor issue Pros and cons for translating opaque lsa one-by-one - Pro:? - Con: Would make the migration less pragmatic Next steps: We need to understand what's this backdoor problem is weight, the pro and cons and make a pragmatic decision (to have an opaque LSA ready code) Discussion: ---------- Alex Zinin: Questions about OSPFv3 for IPv4? Acee Lindem: Not described in the current RFC Alex Zinin: Thus not to be used for the arguments? since this is an orthogonal problem: announce IPv4 information using OSPFv3 does not make sense Kireeti Kompella: The inverse is done today Alex Zinin: Do we agree? Kireeti Kompella: Yes Alex Zinin: Opaque type? Kireeti Kompella: Opaque LSA, this is a v2 opaque LSA Alex Zinin: Have a single level of numbering Kireeti Kompella: This implies to change the code - do you know how long it takes? Alex Zinin: Yes and i try to simplyify the code we use Kireeti Kompella: The code to use is very simple, look at the opaque type... Alex Zinin: What's problem we try to solve? Kireeti Kompella: New opaque type in OSPFv3 and useful for OSPFv2 as well since I do not want to change my code for interoperability reasons Alex Zinin: No difference between the two proposals, thus which one to select Kireeti Kompella: Want to do it once (for all) Alex Zinin: With the proposal you grab the function code in OSPFv3, the only difference here is, v2 in v3, by doing that you create an overlap specification space and please think about the implication Rohit Dube: OSPFv3 for IPv6 is a different protocol from v2 in terms of a model it should be considered as different protocols. Kireeti Kompella: Thus OSPFv3 not used for IPv4 Alex Zinin: Thus we don't use it for discussion Kireeti Kompella: Make a statement, if the protocols are different then state this in the corrresponding document Rohit Dube: Could you clarify your point Kireeti Kompella: Since IPv4 in OSPFv3 is not specified, I will make the clarification in order to allow for that; by analogy, RSVP can use IPv6 identification over IPv4 everything is ready except the OSPFv2 document while people ask this from my side, thus this is a real problem and not a theoretical problem as the backdoor one. Alex Zinin: The working group should decide what to do, but Alex's concerns with this approach is that it will create potential problem while not solving the intended problem - thus a cleaner approach should be provided. Acee Lindem: This is not a brand new application thus I agree with Alex. Alex Zinin: Things must always be specificed Kunihiro Ishiguro: type 9 is already used by v2, Kireeti Kompella: Types 9, 10, and 11 map in the value 22 in v3, meaning it is a v2 opaque LSA, but the backdoor problem is there anyway Rohit Dube: This problem will be further discussed on the mailing lists as well the respective merits of the two approaches. ========================================================== 5) Jerry Ash (10 Mins): Congestion Avoidance & Control for OSPF Networks http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt Summary: -------- 1. Introduction: Draft addresses the problem of scalability; Evidence is failure experience, vendors analyzing their own OSPF implementations, and analysis of the LSA storms 2. Background and motivation 3. Failure experience: failure experience in 4/13/98 in the ATT frame relay network. 4. Proposed protocol mechanism: Signal a congestion state, to become to a specific OSPF protocol processing during the congestion detection, the neighbors will be notified about the slowdown and adjust the flooding rate. 5. Lot's of discussion on the list - is there a problem? We feel there is a problem. Initiate a debate on how to solve the problem, the protocol is complete as it is, and these problems will be resolved by having better implementations but operators asks for interoperable implementations this is the reason for these i-d's. Thus proposal to go beyond this and go to a procedure for that purpose? The proposed congestion response is analogous to the helper router response to a 'grace LSA' from a congested router in hitless restart. Concerning the approach of better coding? does it solves the problem but in the mean time we think that the better standard between vendors would be to solve these issues Discussion: ---------- Padma: Concerning the protocol extensions, grace LSA is not necessarily applicable since a restarting router is not a (necessarily) a congested router; are these to be considered as real protocol extensions (like for instance the throttling) or just more fine tuned implementations? Jerry Ash: The congested router would signal its congestion state before it saturates, this would reduce congestion by slowing down the neighbor LSAs sent to the congested router. These mechanisms are considered as protocol extensions: the neighbor response to the congestion notification is analogous to the helper router response to the 'grace LSA' from a congested router in hitless restart. Rohit Dube: Move discussions after the second presentation Acee Lindem: But keep track of the charter concerning the hello and ack prioritization. ========================================================== 6) Gagan L. Choudhury (10 Mins): Explicit Marking and Prioritized Treatment of Specific OSPF Packets for Faster Convergence and Improved Network Scalability and Stability http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-02.txt Summary: ------- 1. Basic issue: failures in the network generating sustained CPU usage, LSA storms, and positive feedback loops. 2. Proposal: Priority for the hello and the ack's the question is how to deliver it, ask for having this as BCP, for instance diffserv codepoints for high priority and another for low priority. 3. Simulation study: Three priority scenarios, and two network scenarios, tested with 2 LSA scenaros. Show graphic(s) on the non converged LSA's vs the LSA storm (in seconds) to represent the strenght of the LSA storm (the actual curves) Show graphic(s) illustrating that priority allows for pacing the storm but until a certain threshold only and if the usage of priority for acks is also provided this theshold is higher. In all cases, the usage of priorities there is an improvement for the sustainted cpu usage. 4. Proposal: Use of special marking (at least a to become a BCP) and use of it for the prioritization of hellos. Discussion: ---------- Gagan Choudhury: Should we move to the next one? Acee Lindem: yes ========================================================== 7) Gagan L. Choudhury (10 Mins) LSA Flooding Optimization Algorithms and their Simulation Study http://www.ietf.org/internet-drafts/draft-choudhury-manral-flooding-simulation-00.txt Summary: ------- 1. How to improve this threshold significantly? 2. Basic issue: in very large networks an LSA storm a sustained cpu congestion may appear. 3. Flooding algos to be considered: - algo1: LSA flooding over all interfaces - algo2: LSA flooding over only one interface for parallel adjecencies - algo3: full flooding at mp relays to the immediate neighbors Alex Zinin: algo3 does not guarantee the reliability of the flooding - algo4: flooding only along a minimum spanning tree - algo5: algo2 for non-te (topological) LSA's and algo4 for the te LSA's Alex Zinin: We can't use all of them or a selection 4. Simulation results: . Presentation of the five different cases each analyzed with the allowed LSA storm size . Observations on the flooding algorithms 5. Conclusion: algo2, algo5 and modified algo5 should be pursued further Discussion: ---------- Alex Zinin (as WG member): algo5 doesn't appear to be robust, can you explain in which context you propose it? Gagan Choudhury:? Alex Zinin (as WG member): An ATM switch fails, while the IP router is unaware of the routing topology, how does it work? Gagan Choudhury: Network watches for any link and node failure but here we speak about the flooding link (...) Alex Zinin: Referring to previous mailing list discussion, flooding trees generates problem when a single link fail, there is a lot of topology activity here, raising potential multiple trees Gagan Choudhury: During the failure, basic LSA's can carry the needed information Alex Zinin: Which LSA's are flooded? Gagan Choudhury: Only the ones that are strictly needed Alex Zinin: It is not always safe to say there is no topology info exchange with more efficient flooding algo's, resyncing neighbors may be heavy... something equivalent to ISIS Acee Lindem: Basic flooding paradigm with proposed techniques seems reasonable but anything beyond this is questionable? Gagan Choudhury: Agrees Acee Lindem: Explicit marking, as specified in RFC 1812, says all OSPF packets should be sent at Internet Control level. If something new is proposed, it must be precisely specified. Gagan Choudhury: Agrees, BCP and explicit marking needs more details Rohit Dube: To be a bit stronger, priority of hellos, acks, use of other packet for the reset timer; all of these can be done without any protocol changes, to be abstracted and added as a WG i-d; everything else should be included in a separate document, Gagan Choudhury: Agrees Jerry Ash: Not only a BCP but also needs for an explicit notification mechanism. Rohit Dube: BCP talks about hellos and acks, and this seems to be agreed, everything requiring protocol changes (such as flooding) should be discussed separately. Jerry Ash: Proposed to start with the ECN (Explicit Congestion Notification) Rohit Dube: Propose a vote concering the ECN Acee Lindem: (describing the consensus) Clearly more people against. Padma Pillay-Esnault: Understand the congestion problems but most of these are related to bugs and implementation issues, the extensions are not really implementation-based solution since they can generate other problems; thus proposes to take them in offline discussions to be tackled by the implementation. Alex Zinin: EC notification and EC detection also needs mailing list discussion, people are afraid of specifying the implementation details, and believe that we don't have to go to these two extremes, (bits on the wire only versus implementation details), Alex would like to open the discussion concerning these very dynamic behaviors. ========================================================== Rohit Dube: charter update =========================== Summary: ------- Charter update has been sent out on the list Selection criteria are as follows: - Rough consensus on the list - Technical quality of these i-ds - Urgency of the item - Charter proposal pending for a bit (queue up) Done things: ----------- - OSPF for IPv6 - NSSA update - OSPF-TE extensions To do list: ---------- - See proposal Dropped: ------- - MOSPF - OSPF flooding reduction Note: To be reconsidered in case of strong need Discussion: ---------- Alex Zinin: IPv6 meeting today on "site local" issues. Site border work not needed for now. Rohit Dube: Will submmit the chrter to these i-ds Acee Lindem: New items will be added or removed per evaluation criteria. ** end of the meeting ** --------------050109070102030205000008-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 28 23:41:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10982 for ; Thu, 28 Nov 2002 23:41:33 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.008030BD@cherry.ease.lsoft.com>; Thu, 28 Nov 2002 23:44:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 414644 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 28 Nov 2002 23:44:18 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 28 Nov 2002 23:44:18 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 13ABE1B8EFC for ; Thu, 28 Nov 2002 20:37:19 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010506040701080301090306" Message-ID: <3DE6EFBF.9040001@redback.com> Date: Thu, 28 Nov 2002 23:40:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Updated 55th IETF OSPF WG Minutes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------010506040701080301090306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've incorporated comments as well as made some corrections and edits. -- Acee --------------010506040701080301090306 Content-Type: text/plain; name="ietf55-ospf-wg-minutes.txt" Content-Disposition: inline; filename="ietf55-ospf-wg-minutes.txt" Content-Transfer-Encoding: 7bit OSPF WG meeting - Thursday 22nd of november - 15:00-17:00 ========================================================= Document status (Acee Lindem and Rohit Dube): --------------- - RFC 3101 (Not-So-Stubby-Area) currently in final RFC editorship - Traffic engineering extensions to OSPF v2 (a.k.a. OSPF-TE) passed the working group last call (completed) - IETF wide last call to be issued soon. - Hitless restart - 04 version to be issued soon. Expect to have WG last call on this version. - Detecting Inactive Neighbors over OSPF Demand Circuits (draft-ietf-ospf-dc-05.txt) is pending and is pending wg chair comments. - OSPF Refresh and flooding reduction in stable topologies (draft-pillay-esnault-ospf-flooding-04.txt) needs a couple of edits but no significant changes. - Alternative OSPF ABR Implementations (draft-ietf-ospf-abr- alt-05.txt) in the comment cycle, it is pretty much done and the last call will be issued pretty quickly - mib-update-05.txt - May want to add the graceful restart capabilities Agenda bashing -------------- - Acee Lindem: Propose to move hitless restart after Kireeti presentation. - Kireeti Kompella: Agrees On the Agenda: ------------- 1) Rahul Aggarwal (10 Mins): Extensions to IS-IS and OSPF for Advertising Optional Router Capabilities http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt Summary: -------- Several changes to this i-d since the last meeting. 1. Review of the motivation and benefits - MPLS-TE (and related) capability discovery mechanism - Network management and trouble shooting options are not extensible thus something generic needed 2. OSPF router information LSA - Optional router information LSA of type 4 and opaque ID 0 - Format of the TLV's in the body of the router info information lsa is the same as the TLV format used for the TE LSA's - Optional TLV must be included as the router capability sub-TLV (flags representing the capabilities), sub-TLV allows for adding additional information flags in the future depending on the needs 3. Router capability bits - see i-d 4. Conclusion - Application through router local policy - Flooding scope dependent on application Discussion: ----------- Acee Lindem: LSA option bits limited thus to be extended with the sub-TLV Rohit Dube: No mailing list comments so far. How will this fit into the charter? Right now there is not a specific item. Rahul Aggarwal: Proposal is made here to pass some information through the use of opaque LSA. Alex Zinin: Which part of this work is within the charter? Thus confrontation of this work wrt to the charter needs to be covered in addition to an IANA consideration section. Rahul Aggarwal: Agrees Alex Zinin: FIFO allocation better std based with expert review before the codepoint allocation by the iana (no arbitrary stuff) experimental values to be also considered here. Tom Petch: Negotiation before exchange these opaque LSAs? as a first step? Rahul Aggarwal: Usage is a local matter, and also avoids the use of negotiation. Dimitri Papadimitriou: What are the TE mesh groups mentioned in this i-d? What is behind traffic-engineering? Are we sure that the underlying concepts are well cooked? What are the relation with TEWG, the current i-d covers one of the application of TE, but generic mechanism can also be considered that overlaps with GMPLS-OSPF. Rahul Aggarwal: Troubleshooting and specific application such as path computation server, may need additional work. Alex Zinin: Refers to the previous comments made during the previous meeting it seems that other WG participants prefers the usage of other mechanism to deliver such capability. Kireeti Kompella: Agrees Rohit Dube: People that oppose may not necessarily be here Rahul Aggarwal: Will send another mail for discussion in order to see where in which direction this i-d has to go after this meeting. ========================================================== 2) Kunihiro Ishiguro (15 Mins): OSPFv3 Traffic Engineering Extensions http://www.ietf.org/internet-drafts/draft-ishiguro-ospf-ospfv3-traffic-01.txt Summary: - Using the proposed framework, proposes an intra-area TE LSA with function code 10, flooding scope is area wide scope, u bit set to 1, thus if the router does not understand LSA it must be flooded anyway. - OSPFv3 TE TLV, katz i-d used as a base. TLV thus the router address and the link TLV are considered here for the OSPFv3 router LSA. Acee Lindem: There is an alternate proposal to be discussed thus comments to come after. Alex Zinin: Router id related question - reachable address because it can be signalled thus what are the signalling implication related to the proposed change? Kunihiro Ishiguro: Not sure at this moment and depends upon the implementation. Kireeti Kompella: Does IPv6 provide a addressable and/or reachable address? Kunihiro Ishiguro: Depends upon the implementation Kireeti Kompella: Take for instance, BGP over ipv6 what do you advertize as the next hop? Acee Lindem: It can be the router-id in IPv4. Kireeti Kompella: Router address TLV has been proposed to sync up ISIS and OSPF topologies, and as used in BGP today (to connect BGP with an incoming LSP request), the missing thing here is that links can be unnumbered and thus the point of the router id (the router address that it identifies) is that it needs to be globally unique or defined as unique wide address or sometimes it may be routable thus the same thing is needed with v6. Kunihiro Ishiguro: This comes from the traffic engineering implementation and or BGP, here a "stable IP address is not needed" but for traffic engineering purposes it seems to be. Alex Zinin: WRT to OSPFv3 it seems that we change the semantic of the protocol, in OSPFv2, this address is a reachable IP address, in ipv6 this is not the case, thus if things are different they should be kept separate in order to maintain the consistency and the semantic of the ospfv3 protocol. Acee Lindem: Questions about the semantic of the router-id. Kireeti Kompella: This is the router address TLV. ========================================================== 3) Acee Lindem (5 Mins): OSPF Hitless Restart Update http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-03.txt note: version -04.txt posted to list Summary: ------- - Hitless restart i-d of J. Moy, Acee Lindem acts as editor for this document and has an implementation for the interoperability testing. Padma Pillary-Ensault is also an author with an implementation. - Changes from 03->04 . Grace period restricted to the LSA refresh time . Alternative to saving crypto seq numbers in non-volatile storage . Alternate help mode termination (ignore LSA changes under configuration control) . Always flood to 224.0.0.5 in the case of unplanned restart which is important since a router loses the knwoledge of being previsouly elected as a designated router . Remove mospf, from future work and add less conservative helper termination - Proposed change: Add alternative to apply the grace LSA to all neighbor adjacencies for orinating router (Padma Pillay-Esnault). This only applies to the case where there are parallel adjacenncies - appears to be fully compatible as long as the grace LSA is flooded on all interfaces. Discussion: ---------- Acee Lindem: Thus ready for last call? Will re-issue the draft for comments and wait a couple weeks. Alex Zinin: Interoperability tests available? Acee Lindem: Redback is interoperable with Juniper (not tried the Moy's implementation), Force10 also has an implementation. Padma: Implementation between Juniper and Force10 tested. ========================================================== 4) Kireeti Kompella (10 Mins): OSPFv2 Opaques in OSPFv3 http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt Summary: -------- 1. OSPFv2 compared to the OSPFv3 opaque LSA format 2. Proposal to migrate OSPFv2 opaque to OSPFv3, Use new OSPFv3 LSA type, everything else remains the same; the LSA ID is the same and the opaque LSA info is the same. 3. Issue with the backdoor problem - yes this is a backdoor but why it is a problem? 4. Related question? Is OSPFv3 for IPv6 (only) or an improvment of OSPFv2? Thus we should be able to run an IPv4 network with OSPFv3? - If so OSPFv3 is a superset of OSPFv2 - If not remove all the IPv4 prefix infromation from v3 Consider OSPFv3 as superset of OSPFv2 - Then we can migrate properly from v2 to v3 - If not all sorts of functions will break during the migration Alternative: - Define a new lsa function for each of the opaque LSA type: one for TE LSA, one for the grace LSA, etc. - What's the length of the opaque id? 24 or 32 bits? But this would break the migration 5. Conclusion Pros and cons for v2 opaque lsa in v3 - Pros: Code reuse v3 includes v2, migration - Cons: Theoritcal backdoor issue Pros and cons for translating opaque lsa one-by-one - Pro:? - Con: Would make the migration less pragmatic Next steps: We need to understand what's this backdoor problem is weight, the pro and cons and make a pragmatic decision (to have an opaque LSA ready code) Discussion: ---------- Alex Zinin: Questions about OSPFv3 for IPv4? Acee Lindem: Not described in the current RFC Alex Zinin: Thus not to be used for the arguments? since this is an orthogonal problem: announce IPv4 information using OSPFv3 does not make sense Kireeti Kompella: The inverse is done today Alex Zinin: Do we agree? Kireeti Kompella: Yes Alex Zinin: Opaque type? Kireeti Kompella: Opaque LSA, this is a v2 opaque LSA Alex Zinin: Have a single level of numbering Kireeti Kompella: This implies to change the code - do you know how long it takes? Alex Zinin: Yes and i try to simplyify the code we use Kireeti Kompella: The code to use is very simple, look at the opaque type... Alex Zinin: What's problem we try to solve? Kireeti Kompella: New opaque type in OSPFv3 and useful for OSPFv2 as well since I do not want to change my code for interoperability reasons Alex Zinin: No difference between the two proposals, thus which one to select Kireeti Kompella: Want to do it once (for all) Alex Zinin: With the proposal you grab the function code in OSPFv3, the only difference here is, v2 in v3, by doing that you create an overlap specification space and please think about the implication Rohit Dube: OSPFv3 for IPv6 is a different protocol from v2 in terms of a model it should be considered as different protocols. Kireeti Kompella: Thus OSPFv3 not used for IPv4 Alex Zinin: Thus we don't use it for discussion Kireeti Kompella: Make a statement, if the protocols are different then state this in the corrresponding document Rohit Dube: Could you clarify your point Kireeti Kompella: Since IPv4 in OSPFv3 is not specified, I will make the clarification in order to allow for that; by analogy, RSVP can use IPv6 identification over IPv4 everything is ready except the OSPFv2 document while people ask this from my side, thus this is a real problem and not a theoretical problem as the backdoor one. Alex Zinin: The working group should decide what to do, but Alex's concerns with this approach is that it will create potential problem while not solving the intended problem - thus a cleaner approach should be provided. Acee Lindem: This is not a brand new application thus I agree with Alex. Alex Zinin: Things must always be specificed Kunihiro Ishiguro: type 9 is already used by v2, Kireeti Kompella: Types 9, 10, and 11 map in the value 22 in v3, meaning it is a v2 opaque LSA, but the backdoor problem is there anyway Rohit Dube: This problem will be further discussed on the mailing lists as well the respective merits of the two approaches. ========================================================== 5) Jerry Ash (10 Mins): Congestion Avoidance & Control for OSPF Networks http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt Summary: -------- 1. Introduction: Draft addresses the problem of scalability; Evidence is failure experience, vendors analyzing their own OSPF implementations, and analysis of the LSA storms 2. Background and motivation 3. Failure experience: failure experience in 4/13/98 in the ATT frame relay network. 4. Proposed protocol mechanism: Signal a congestion state, to become to a specific OSPF protocol processing during the congestion detection, the neighbors will be notified about the slowdown and adjust the flooding rate. 5. Lot's of discussion on the list - is there a problem? We feel there is a problem. Initiate a debate on how to solve the problem, the protocol is complete as it is, and these problems will be resolved by having better implementations but operators asks for interoperable implementations this is the reason for these i-d's. Thus proposal to go beyond this and go to a procedure for that purpose? The proposed congestion response is analogous to the helper router response to a 'grace LSA' from a congested router in hitless restart. Concerning the approach of better coding? does it solves the problem but in the mean time we think that the better standard between vendors would be to solve these issues Discussion: ---------- Padma: Concerning the protocol extensions, grace LSA is not necessarily applicable since a restarting router is not a (necessarily) a congested router; are these to be considered as real protocol extensions (like for instance the throttling) or just more fine tuned implementations? Jerry Ash: The congested router would signal its congestion state before it saturates, this would reduce congestion by slowing down the neighbor LSAs sent to the congested router. These mechanisms are considered as protocol extensions: the neighbor response to the congestion notification is analogous to the helper router response to the 'grace LSA' from a congested router in hitless restart. Rohit Dube: Move discussions after the second presentation Acee Lindem: But keep track of the charter concerning the hello and ack prioritization. ========================================================== 6) Gagan L. Choudhury (10 Mins): Explicit Marking and Prioritized Treatment of Specific OSPF Packets for Faster Convergence and Improved Network Scalability and Stability http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-02.txt Summary: ------- 1. Basic issue: failures in the network generating sustained CPU usage, LSA storms, and positive feedback loops. 2. Proposal: Priority for the hello and the ack's the question is how to deliver it, ask for having this as BCP, for instance diffserv codepoints for high priority and another for low priority. 3. Simulation study: Three priority scenarios, and two network scenarios, tested with 2 LSA scenaros. Show graphic(s) on the non converged LSA's vs the LSA storm (in seconds) to represent the strenght of the LSA storm (the actual curves) Show graphic(s) illustrating that priority allows for pacing the storm but until a certain threshold only and if the usage of priority for acks is also provided this theshold is higher. In all cases, the usage of priorities there is an improvement for the sustainted cpu usage. 4. Proposal: Use of special marking (at least a to become a BCP) and use of it for the prioritization of hellos. Discussion: ---------- Gagan Choudhury: Should we move to the next one? Acee Lindem: yes ========================================================== 7) Gagan L. Choudhury (10 Mins) LSA Flooding Optimization Algorithms and their Simulation Study http://www.ietf.org/internet-drafts/draft-choudhury-manral-flooding-simulation-00.txt Summary: ------- 1. How to improve this threshold significantly? 2. Basic issue: in very large networks an LSA storm a sustained cpu congestion may appear. 3. Flooding algos to be considered: - algo1: LSA flooding over all interfaces - algo2: LSA flooding over only one interface for parallel adjecencies - algo3: full flooding at mp relays to the immediate neighbors Alex Zinin: algo3 does not guarantee the reliability of the flooding - algo4: flooding only along a minimum spanning tree - algo5: algo2 for non-te (topological) LSA's and algo4 for the te LSA's Alex Zinin: We can't use all of them or a selection 4. Simulation results: . Presentation of the five different cases each analyzed with the allowed LSA storm size . Observations on the flooding algorithms 5. Conclusion: algo2, algo5 and modified algo5 should be pursued further Discussion: ---------- Alex Zinin (as WG member): algo5 doesn't appear to be robust, can you explain in which context you propose it? Gagan Choudhury:? Alex Zinin (as WG member): An ATM switch fails, while the IP router is unaware of the routing topology, how does it work? Gagan Choudhury: Network watches for any link and node failure but here we speak about the flooding link (...) Alex Zinin: Referring to previous mailing list discussion, flooding trees generates problem when a single link fail, there is a lot of topology activity here, raising potential multiple trees Gagan Choudhury: During the failure, basic LSA's can carry the needed information Alex Zinin: Which LSA's are flooded? Gagan Choudhury: Only the ones that are strictly needed Alex Zinin: It is not always safe to say there is no topology info exchange with more efficient flooding algo's, resyncing neighbors may be heavy... something equivalent to ISIS Acee Lindem: Basic flooding paradigm with proposed techniques seems reasonable but anything beyond this is questionable? Gagan Choudhury: Agrees Acee Lindem: Explicit marking, as specified in RFC 1812, says all OSPF packets should be sent at Internet Control level. If something new is proposed, it must be precisely specified. Gagan Choudhury: Agrees, BCP and explicit marking needs more details Rohit Dube: To be a bit stronger, priority of hellos, acks, use of other packet for the reset timer; all of these can be done without any protocol changes, to be abstracted and added as a WG i-d; everything else should be included in a separate document, Gagan Choudhury: Agrees Jerry Ash: Not only a BCP but also needs for an explicit notification mechanism. Rohit Dube: BCP talks about hellos and acks, and this seems to be agreed, everything requiring protocol changes (such as flooding) should be discussed separately. Jerry Ash: Proposed to start with the ECN (Explicit Congestion Notification) Rohit Dube: Propose a vote concering the ECN Acee Lindem: (describing the consensus) Clearly more people against. Padma Pillay-Esnault: Understand the congestion problems but most of these are related to bugs and implementation issues, the extensions are not really implementation-based solution since they can generate other problems; thus proposes to take them in offline discussions to be tackled by the implementation. Alex Zinin: EC notification and EC detection also needs mailing list discussion, people are afraid of specifying the implementation details, and believe that we don't have to go to these two extremes, (bits on the wire only versus implementation details), Alex would like to open the discussion concerning these very dynamic behaviors. ========================================================== Rohit Dube: charter update =========================== Summary: ------- Charter update has been sent out on the list Selection criteria are as follows: - Rough consensus on the list - Technical quality of these i-ds - Urgency of the item - Charter proposal pending for a bit (queue up) Done things: ----------- - OSPF for IPv6 - NSSA update - OSPF-TE extensions To do list: ---------- - See proposal Dropped: ------- - MOSPF - OSPF flooding reduction Note: To be reconsidered in case of strong need Discussion: ---------- Alex Zinin: IPv6 meeting today on "site local" issues. Site border work not needed for now. Rohit Dube: Will submmit the chrter to these i-ds Acee Lindem: New items will be added or removed per evaluation criteria. ** end of the meeting ** --------------010506040701080301090306-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 28 23:47:56 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11146 for ; Thu, 28 Nov 2002 23:47:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00802F3C@cherry.ease.lsoft.com>; Thu, 28 Nov 2002 23:50:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 414663 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 28 Nov 2002 23:50:40 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 28 Nov 2002 23:50:40 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id A3B371B77A5 for ; Thu, 28 Nov 2002 20:50:36 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DE6F2DD.30002@redback.com> Date: Thu, 28 Nov 2002 23:53:49 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Vishwas, Manral, Vishwas wrote: > Hi folks, > > I was going thru the OSPFv3 RFC which in section it states that > > "In IPv6, the calculation of the next hop's IPv6 address (which will be a > link-local address) proceeds along the same lines as the IPv4 next hop > calculation (see Section 16.1.1 of [Ref1])." > I think this is not correct. After carefully reading the RFC I figured out > that Link-LSA's can have global scope IPv6 addresses too. I see no reason > why we cannot have global addresses as next hop. You are guarenteed to have a link local address on all OSPFv3 interfaces while there is no guarentee that you have a global address. I believe this is the rationale for using the link local. > Besides for some conditions > of redistribution we may require global scope addresses for nexthop. Are you trying determine whether a third party next hop can be advertised by matching global subnets? > Any opinions? > Thanks, > Vishwas > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Nov 28 23:52:45 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11234 for ; Thu, 28 Nov 2002 23:52:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00802FC6@cherry.ease.lsoft.com>; Thu, 28 Nov 2002 23:55:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 414681 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 28 Nov 2002 23:55:29 -0500 Received: from 192.25.42.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 28 Nov 2002 23:55:29 -0500 Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233]) by msgbas1.sgp.agilent.com (Postfix) with ESMTP id 6302B4AB for ; Fri, 29 Nov 2002 12:55:27 +0800 (SGP) Received: from apbrg1.sgp.agilent.com (apbrg1.sgp.agilent.com [141.183.6.40]) by msgrel1.sgp.agilent.com (Postfix) with SMTP id 3FFC66DA for ; Fri, 29 Nov 2002 12:55:02 +0800 (SGP) Received: from 141.183.6.40 by apbrg1.sgp.agilent.com (InterScan E-Mail VirusWall NT); Fri, 29 Nov 2002 12:55:26 +0800 Received: by apbrg1.sgp.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Nov 2002 12:55:26 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <89D04169635E024E8FD2174A852D788B890D2C@apmail16.ind.agilent.com> Date: Fri, 29 Nov 2002 12:55:25 +0800 Reply-To: Mailing List Sender: Mailing List From: Joseph Placid Subject: DD packet exchange To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I noticed that when two OSPF routers are forming an adjacency, both of them send their first DD packets claiming to be Master (ie, with master bit set). According to the OSPF Protocol, this will be resolved based on the router priority. But both of them already know each other's router priority from the hello packets they have received earlier. So why should BOTH of them send DD packets claiming to be Master? The setup I used is three computers running zebra in the same area connected to each other via ethernet. - Joseph Placid From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 29 00:54:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12092 for ; Fri, 29 Nov 2002 00:54:19 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00803210@cherry.ease.lsoft.com>; Fri, 29 Nov 2002 0:57:01 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 414864 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 29 Nov 2002 00:57:01 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 29 Nov 2002 00:57:00 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 26E4B26281B for ; Thu, 28 Nov 2002 21:56:15 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <89D04169635E024E8FD2174A852D788B890D2C@apmail16.ind.agilent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DE7023E.8000205@redback.com> Date: Fri, 29 Nov 2002 00:59:26 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: DD packet exchange To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Joseph Placid wrote: > Hi, > I noticed that when two OSPF routers are forming an adjacency, both of them send their first DD packets claiming to be Master (ie, with master bit set). According to the OSPF Protocol, this will be resolved based on the router priority. But both of them already know each other's router priority from the hello packets they have received earlier. So why should BOTH of them send DD packets claiming to be Master? > Hi Joseph, This is correct as per section 10 in RFC 2328. In ExStart state, the DD packets serve as a sync point for the database exchange process. This state is necessary to assure that both neighbors are starting the exchange from scratch and agree upon both their respective roles and the initial sequence number. Possibly this could have been done solely with the Initialize (I) bit in the OSPF database exchange packet. However, it seems more natural for the master/slave negotiation to be done in ExStart state (given that you need the initial DD packets anyway). One correction - it is the OSPF router ID (not the router priority) that is used to determine who is master (the neighbor with the numerically higher router ID will be the master in the database exchange). > The setup I used is three computers running zebra in the same area connected to each other via ethernet. > > > - Joseph Placid > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 29 02:29:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23267 for ; Fri, 29 Nov 2002 02:29:53 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.008036EC@cherry.ease.lsoft.com>; Fri, 29 Nov 2002 2:32:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 415103 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 29 Nov 2002 02:32:37 -0500 Received: from 192.25.42.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 29 Nov 2002 02:22:37 -0500 Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233]) by msgbas1.sgp.agilent.com (Postfix) with ESMTP id 8DE6A721 for ; Fri, 29 Nov 2002 15:22:34 +0800 (SGP) Received: from apbrg1.sgp.agilent.com (apbrg1.sgp.agilent.com [141.183.6.40]) by msgrel1.sgp.agilent.com (Postfix) with SMTP id C0471A0A for ; Fri, 29 Nov 2002 15:22:08 +0800 (SGP) Received: from 141.183.6.40 by apbrg1.sgp.agilent.com (InterScan E-Mail VirusWall NT); Fri, 29 Nov 2002 15:22:32 +0800 Received: by apbrg1.sgp.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Nov 2002 15:22:32 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <89D04169635E024E8FD2174A852D788B0162A735@apmail16.ind.agilent.com> Date: Fri, 29 Nov 2002 15:22:31 +0800 Reply-To: Mailing List Sender: Mailing List From: "M.Umamaheshwara Rao" Subject: Zebra Ospfv3 Question: To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I have zebra version 0.92a for ospf6d installed on freebsd machine. Does it supports ABR, ASBR features? Does this version of zebra supports generating inter area prefix and inter area router lsa by ABR and ASBR into backbone area? If yes, how do we configure the router to be ABR, ASBR in ospf6d.conf file or/and zebra.conf file? If No, which version of zebra supports? Can anybody have any information regarding these issues, Please let me know. Thanx in advance Rao From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 29 08:06:28 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28564 for ; Fri, 29 Nov 2002 08:06:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.008040F5@cherry.ease.lsoft.com>; Fri, 29 Nov 2002 8:09:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 416671 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 29 Nov 2002 08:09:13 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 29 Nov 2002 08:09:12 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRCGB>; Fri, 29 Nov 2002 08:09:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 29 Nov 2002 08:11:21 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Acee, >> I was going thru the OSPFv3 RFC which in section it states that >> >> "In IPv6, the calculation of the next hop's IPv6 address (which >> will be a link-local address) proceeds along the same lines as >> the IPv4 next hop calculation (see Section 16.1.1 of [Ref1])." >> I think this is not correct. After carefully reading the RFC I >> figured out that Link-LSA's can have global scope IPv6 addresses >> too. I see no reason why we cannot have global addresses as next >> hop. > You are guarenteed to have a link local address on all OSPFv3 > interfaces while there is no guarentee that you have a global > address. I believe this is the rationale for using the > link local. I agree to the fact that all IPv6(not OSPFv3 in context of the IPv4 discussion;-)) interfaces will have link-local addresses, besides I am ok with the fact of using Link-local addresses for nexthop. However I think saying that nexthops "will" be link-local addresses would be wrong, we can have global addresses in Link-LSA's and as nexthop(also the reason below) >> Besides for some conditions >> of redistribution we may require global scope addresses for nexthop. > Are you trying determine whether a third party next hop can be > advertised by matching global subnets? When redistributing OSPF routes into BGP, BGP may use the nexthop learned from the OSPF to advertize in its route. I guess, we cannot send link-local address as nexthop in that case. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Nov 29 08:33:52 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29298 for ; Fri, 29 Nov 2002 08:33:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.008041A7@cherry.ease.lsoft.com>; Fri, 29 Nov 2002 8:36:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 416741 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 29 Nov 2002 08:36:37 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 29 Nov 2002 08:36:37 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRCGS>; Fri, 29 Nov 2002 08:36:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 29 Nov 2002 08:38:28 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 MIB To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list One more point: - Need an object in the neighbor table which allows helper to disable, graceful restart helper termination when the link-state database changes. Besides would we want enhanced TE support from the OSPFv2 MIB, if so what level would we want to do it? Thanks, Vishwas -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: Thursday, November 28, 2002 5:01 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPFv2 MIB Hi, I was reading thru the minutes which talked about mib-update-05. While discussing the v3-MIB with Dan, we had some more issues along with the hitless for the OSPFv2 MIB. I thought it may be helpful to put them on list here. 1. We may want to deprecate the ospfExtLsdbTable and instead have a new ospfAsLsdbTable table like in the V3-MIB. There is no table for type-11's rite now. 2. We would want a counter for ExtLSACount besides the ASLSACount for the DBOverflow purposes. 3. The draft http://www.ietf.org/internet-drafts/draft-ietf-ospf-nssa-update-11.txt talks about configuring "external route tag" we would want to add that to the AreaAggregateTable. 4. Besides that for hitless restart we could want objects in the neighbor table a) hitless restart interval - got in the grace LSA b) hitless restart state - whether helper or not c) hitless restart exit reason - restart complete - topology change - indication from restarting router - timer expiry(restart not completed in given time). d) hitless restart time remaining - if the neighbor is acting as a helper 5. Besides that in the general group we could want a configureable hitless restart interval - to be used when we r going hitless restart 6. I did try to reach Spencer G. but the mails to the address specified seem to bounce off, any idea of how we could get to him? These are all I could dig out, I will check if I have missed out anything. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Thursday, November 28, 2002 2:26 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: 55th IETF OSPF WG Minutes Thanks to Dimitri Papadimitriou for taking the minutes. I've done some slight editting. Please send corrections directly to me (e.g., if you feel you were misquoted). In the coming weeks, Rohit and I will follow up on unfinished items. The Web page should be updated with the new charter shortly. Thanks, --- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat Nov 30 10:30:18 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06680 for ; Sat, 30 Nov 2002 10:30:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.008068B0@cherry.ease.lsoft.com>; Sat, 30 Nov 2002 10:32:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 419924 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 30 Nov 2002 10:32:56 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 30 Nov 2002 10:32:56 -0500 Received: from smirtoraw2k01 (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAUFWpO21194 for ; Sat, 30 Nov 2002 07:32:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <005f01c29885$c0cdcba0$5938fe90@amer.cisco.com> Date: Sat, 30 Nov 2002 07:32:50 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas, Vishwas> >> why we cannot have global addresses as next hop. Acee> > You are guarenteed to have a link local address on all OSPFv3 Acee> > interfaces while there is no guarentee that you have a Acee> global address. Acee> > I believe this is the rationale for using the link local. Vishwas> I agree to the fact that all IPv6(not OSPFv3 in context of the IPv4 Vishwas> discussion;-)) interfaces will have link-local addresses, Vishwas> besides I am ok with the fact of using Link-local addresses Vishwas> for nexthop. However I think saying that nexthops "will" be Vishwas> link-local addresses would be wrong, we can have global Vishwas> addresses in Link-LSA's and as nexthop(also the reason below) having global address in Link-LSA is irrelevant to next hop calculation, the fact of carrying global IPv6 address in Link-LSA is just related to announcing all global Ipv6 address of a multi-access link to DR so that it will announce them in its intra-area-prefix LSA Link-local address is the only address to be always available ( as Acee said ) therefore this address can always be used to reach your nexthop and you should not need any other address even a node can have multiple IPv6 address Vishwas> >> Besides for some conditions Vishwas> >> of redistribution we may require global scope addresses Vishwas> for nexthop. If you are referring to FA setting, although if it is necessary to have a global Ipv6 address for FA setting this address is only used to forward a packet to, but this does Not mean that the nexthop is the FA. A router while trying to install a route to the external with FA set needs to just know its nexthop which would be a link-local address ( even if the ASBR setting the FA is directly connected to this router ) Sina From owner-ospf@DISCUSS.MICROSOFT.COM Sat Nov 30 13:37:28 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09871 for ; Sat, 30 Nov 2002 13:37:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00806A76@cherry.ease.lsoft.com>; Sat, 30 Nov 2002 13:40:13 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 420285 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 30 Nov 2002 13:40:13 -0500 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 30 Nov 2002 13:40:13 -0500 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 139246C3AB; Sun, 1 Dec 2002 03:40:12 +0900 (JST) References: <005f01c29885$c0cdcba0$5938fe90@amer.cisco.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021201.034009.123556283.yasu@sfc.wide.ad.jp> Date: Sun, 1 Dec 2002 03:40:09 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: OSPFv3 nexthop Comments: To: sina@CISCO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <005f01c29885$c0cdcba0$5938fe90@amer.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit sina> having global address in Link-LSA is irrelevant to next hop calculation, sina> the fact of carrying global IPv6 address in Link-LSA is just related to sina> announcing all global Ipv6 address of a multi-access link to DR so that sina> it will announce them in its intra-area-prefix LSA sina> sina> Link-local address is the only address to be always available ( as Acee sina> said ) therefore this address can always be used to reach your nexthop sina> and you should not need any other address even a node can have multiple sina> IPv6 address Having a global address in Link-LSA (specifically in 'Link-local Interface Address' field) is *not* irrelevant. It will be used as the actual nexthop in SPF calculation. It is possible for an implementation to recognize a Link-LSA which has a global-address in 'Link-local Interface Address' field as an invalid Link-LSA. It is just because RFC2740 describes that way (or the field name indicates that way). I agree that if OSPFv3 implementation allows, having global address as nexthop will not be a problem. Route table lookup may ensue further to find link-local address for it, or NDP(or some other L2-L3 address mapping mechanism) will work directly on the global address to derive its corresponding L2 address. sina> If you are referring to FA setting, although if it is necessary to have sina> a global Ipv6 address for FA setting this address is only used to sina> forward a packet to, but this does Not mean that the nexthop is the FA. sina> A router while trying to install a route to the external with FA set sina> needs to just know its nexthop which would be a link-local address ( sina> even if the ASBR setting the FA is directly connected to this router ) Agree, FA will be used to derive actual nexthop, which will be a link-local address in most cases. regards, yasu