From owner-ospf@PEACH.EASE.LSOFT.COM Sun Aug 1 16:29:26 2004 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 QAA22933 for ; Sun, 1 Aug 2004 16:29:26 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00E32549@cherry.ease.lsoft.com>; 1 Aug 2004 16:29:24 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 28604599 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 1 Aug 2004 16:29:22 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 1 Aug 2004 16:29:22 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 58DB99860B2 for ; Sun, 1 Aug 2004 13:29:21 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02916-06 for ; Sun, 1 Aug 2004 13:29:21 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.49]) by prattle.redback.com (Postfix) with SMTP id 9B31C9860B1 for ; Sun, 1 Aug 2004 13:29:20 -0700 (PDT) References: <20040729094922.8084.qmail@mailweb34.rediffmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C477E4.AE8CFA20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <004d01c47806$35e36b50$dd828182@aceeinspiron> Date: Sun, 1 Aug 2004 16:29:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-scalability-08.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C477E4.AE8CFA20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It could. Hopefully the OSPF congestion is a short-lived burst of = activity due to some network event. IMHO, any OSPF network that is in a steady state = of=20 congestion will have problems no matter what one does.=20 =20 ----- Original Message -----=20 From: Vivek Dubey=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Thursday, July 29, 2004 5:49 AM Subject: draft-ietf-ospf-scalability-08.txt Section 2: Recommendations : 4) Implicit Congestion Detection and Action Based on That: Could this recommendation be affected by "global synchronization" as = seen in TCP networks.=20 -Vivek ------=_NextPart_000_004A_01C477E4.AE8CFA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It could. Hopefully the OSPF = congestion=20 is a short-lived burst of activity due
to some network event. = IMHO, any OSPF=20 network that is in a steady state of
congestion will have=20 problems no matter what one does.
 
----- Original Message -----
From:=20 Vivek Dubey
Sent: Thursday, July 29, 2004 = 5:49=20 AM
Subject:=20 draft-ietf-ospf-scalability-08.txt

Section 2:
Recommendations :
4) Implicit Congestion Detection = and=20 Action Based on That:
Could this recommendation be affected by = "global=20 synchronization" as seen in TCP networks.=20

-Vivek




------=_NextPart_000_004A_01C477E4.AE8CFA20-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 2 02:25:35 2004 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 CAA17453 for ; Mon, 2 Aug 2004 02:25:34 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00E331E8@cherry.ease.lsoft.com>; Mon, 2 Aug 2004 2:25:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 28647083 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Aug 2004 02:25:31 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Aug 2004 02:25:31 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRl3y+Zp9yB6ovtSbm3UoMCYS3M1gSeMlXQ Message-ID: Date: Sun, 1 Aug 2004 23:29:05 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Suresh, I think I missed replying to this one. Yes, if anti-replay is not enabled the sequence number wrap does not = matter at all. From the ESP document: - If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.) Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Suresh Melam Sent: Friday, July 09, 2004 11:18 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Please see my comments inline, thanks, -suresh (Nagavenkata Suresh Melam) > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext >Vishwas Manral >Sent: Monday, July 05, 2004 9:38 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > > >Hi Mukesh, > >Just wanted to add from ESP > >"If anti-replay is enabled (the default), the transmitted Sequence = Number must never be >allowed to cycle." I think there is no consistent way a sender or = receiver would work after >rollover. The receiver could very well break the SA on rollover(I = think). > As manual keying doesn't use anti-replay mechanisms, the Sequence = numbers need not be considered in our discussion. >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of >Vishwas Manral >Sent: Tuesday, July 06, 2004 10:03 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > > >Hi Mukesh, > >>>1. I am not sure we should have a statement which says OSPFv3 >>>is only for IPv6. >>>"As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, >>> the distinction between the packets can be easily made by >>> IP version. " >>Do you have a replacement statement that you would prefer ? >>As the IP protocol type value for OSPF and OSPFv3 is same, >>we have to depend upon the IP version to separate OSPF and >>OSPFv3 packets. >There is a distinction between running over and "only for"(which >I assumed you meant the contents). It seems you mean running over. Yes, our intention was to mention "running over". We will change the sentence as follows. "The distinction between the OSPFv2 and OSPFv3 is made based on the IP version. If OSPFv3 runs on IPv4 protocol on a link for any reason, then IPsec security cannot be enabled on this link." >>>2. I think the value of next header field in the ESP header >>>to indicate OSPFv3 should be specified, though it may seem >>>a trivial question. >>Why do you think it should be specified? Whenever ESP is >>applied to any IP packet, the IP Protocol Type field value >>from the IP header is copied to the next header field of >>ESP/AH. There are no exceptions here. >The whole draft is full of informational statements like: - > > "AH in transport mode provides authentication to > higher layer protocols, selected portions of IPv6 header, selected > portions of extension headers and selected options. ESP with NULL > encryption in transport mode will provide authentication to only > higher layer protocol data and not to the IPv6 header, extension > headers and options." > >I think putting what the value in the next header would be would be >helpful. We will add another informational statement as follows. "IPsec copies the OSPF protocol value from the IPPROTO field of the IP packet to the next header field of the ESP/AH header." >>>3. ESP already states that "integrity-only (MUST be supported)" >>>do we really need to put down "ESP with NULL encryption MUST be >>>supported in transport mode". >>>An implementation may support ESP/AH that conform to ESP/AH RFCs, >>but the idea of putting this in this draft was to ensure that the >>user is allowed to use the specified combinations for securing >>the OSPF traffic. So that 2 independent secured OSPF >>implementations have at least one common combination to configure. >>Do you see any harm in putting this text in the draft ? >Not at all, but I am unable to see the point of >"ESP with NULL encryption MUST be supported in transport mode". The >point is we are saying a restriction on ESP MUST be there, where ESP >already has said its a MUST in the protocol itself. I think we may >also want to state other things then, like using ESN(if its supported), >default authentication/encryption algorithm etc when using manual = keying. Our intention was to mention that "Inorder to support OSPFv3 authentication, the underlying IPsec implementation MUST support ESP with NULL encryption in transport mode." The reason is that we strongly suggest the usage of "ESP with NULL = encryption in transport mode" for OSPFv3 authentication. We don't have any explicit suggestions for algorithms. But atleast now we should add another line. "While choosing algorithms for authentication/encryption, one should be careful to choose the algorithms that are suitable for manual keying. = For eg., some stream cipher algorithms like AES-CCM are not suitable for manual = keys" >>5. OSPF packets received in clear text or with incorrect AH >>>Integrity Check Value (ICV) MUST be dropped when authentication is >>>enabled. >>> Do we mean only AH/ICV or do we need ESP ICV too? Besides do we >>>need to state about combined mode algorithms like AES-CCM where >>>ICV may not checked even when authentication is done. >>It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the >>next version. >>The draft for AES-CCM says "it is inappropriate to use this CCM >>with statically configured keys". We are using staticaly configured >>keys here. So should we just NOT use AES-CCM ? >AES-CCM is an example of a combined mode algorithm, there are other >and can be further combined mode algorithms. We shouldn't put any >restriction that is based on the algorithm we use. > >From ESP "For combined mode algorithms, the ICV that would normally >appear at the end of the ESP packet (when integrity is selected) may >be omitted. " For the ICV term, we will add "if applicable". "OSPF packets received in clear text or with incorrect AH Integrity Check Value (ICV), if applicable, MUST be dropped when authentication is enabled." >>>6. SA Granularity and Selectors section - I think you are referring >>to parallel links we may want to state that too. >>No I am not referring to parallel links (if you mean 2 links = connecting >>the same routers). It should be possible to use the same SA for = multiple >>interfaces belonging to even different areas. >May be text clarifying what you mean should be put. Also text to state >whether in case of parallel links we need to have one SA or not can be >clarified. We will add another line: "User can choose to use same SA or different for parallel links." >>>7. Changing Keys may also be required in case of sequence number = rollover. >>How is the user going to know about the sequence number rollover ? >>so that he/she can initiate the key change. That brings an = interesting >>question. If the user never changes the keys, what happens when the >>sequence number rollovers ? >There are a lot of ways to provide that, a simple way could be to poll = at some >interval, and when we are near rollover we change the keys. > >From ESP >"Thus, the sender's counter and the receiver's counter MUST > be reset (by establishing a new SA and thus a new key) prior to the > transmission of the 2^32nd packet on an SA." > >This is in case of normal SN, when we use ESN that will change, I = think. In manual keying, sequence numbers are disabled. Hence there is no need = for this discussion in the draft. >>That's a good idea but the problem is that if we put the new drafts >>as normative references, this draft will not be published before those >>drafts. Do we want to block the draft waiting for those drafts ? > >I think that is the authors wish. We will stick with the old RFCs. >>We will be working on addressing all the comments now and will publish >>an updated version of the draft probably after the IETF 60th. >That would be great. > >Thanks, >Vishwas From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 2 02:35:20 2004 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 CAA18056 for ; Mon, 2 Aug 2004 02:35:20 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00E330AE@cherry.ease.lsoft.com>; Mon, 2 Aug 2004 2:35:20 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 28647465 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Aug 2004 02:35:18 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Aug 2004 02:35:18 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRpDL8lBEAgC059TQ2pCClzEaqvzwPTJlYA Message-ID: Date: Sun, 1 Aug 2004 23:38:53 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Suresh, > Yes, we suggest to use manual keying in all cases just to have a = simple > configuration. IKE might involve PKI too. If manual keying is = considered > secure enough for other types of links, we believe it should be secure > enough for point-to-point links too. If there is any strong reason why > IKE should be used over point-to-point link, the two end points are > welcome to use IKE and it would be specific to only those two = endpoints. So should we restrict to only Manual Keying alone in the document. After all we are loosing some functionality like AntiReplay etc. It = would be an issue when we have Key Rollover which I guess is not such a = big issue. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Suresh Melam Sent: Wednesday, July 14, 2004 12:34 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Hi Vishwas, comments inline, thanks, -suresh On Sat, 2004-07-10 at 01:00, Vishwas Manral wrote: > Hi Suresh, > > I was thinking the following assumptions would hold good: - > > 1. We either run OSPFv3 for IPv4 or OSPFv2 for IPv4 not both. > 2. While configuring the SA(we dont use IKE), both ends agree to the = protocol they are using. > > Wouldn't it help in that case? I think the AF draft should state the = limitation instead. Yes, in this case of running only one of OSPFv3 or OSPFv2 over IPv4 AF, but not both, it should be possible to use same rules as those we suggest in our draft to secure the IPv4 OSPF traffic. Only difference is that we should use equivalent IPv4 addresses for instead of IPv6 addresses. For eg., IPv6 multicast OSPF address should be replaced with IPv4 multicast OSPF address and so on. While we try to make sure that any rule in our draft will not conflict with the requirement of running OSPFv3 traffic over IPv4 traffic, we too believe that AF draft should make a clear mention of how IPsec can be used in a such a case. > > Suresh, also if the link is assumed to be point-to-point would we = still restrict to the use of static configuration and not IKE. Yes, we suggest to use manual keying in all cases just to have a simple configuration. IKE might involve PKI too. If manual keying is considered secure enough for other types of links, we believe it should be secure enough for point-to-point links too. If there is any strong reason why IKE should be used over point-to-point link, the two end points are welcome to use IKE and it would be specific to only those two endpoints. > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of = Suresh > Melam > Sent: Friday, July 09, 2004 11:22 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > > > Hi Abhay/Vishwas, > > comments inline, > > thanks, > -suresh (Nagavenkata Suresh Melam) > > > >> Hi Vishwas, > >> > >> Thanks for the comments. Please see my comments inline.. > >> > >> > 1. I am not sure we should have a statement which says OSPFv3 > >> > is only for IPv6. > >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > >> > the distinction between the packets can be easily made by > >> > IP version. " > >> > >> Do you have a replacement statement that you would prefer ? > >> As the IP protocol type value for OSPF and OSPFv3 is same, > >> we have to depend upon the IP version to separate OSPF and > >> OSPFv3 packets. > > > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of > >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux > >will be based on OSPF protocol version. > > > > IPsec selectors are not usually any deeper than protocol field of > IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF > protocol version cannot be one of the selector. > > If OSPFv3 runs on IPv4 transport, there wouldn't be any way > to distinguish OSPFv3 packets from OSPFv2 packets, as both of them > use same protocol value. Thus IPsec security, as mentioned in > "Security considerations" section of RFC2740 and ospfv3-auth draft, > cannot be provided to these packets. Perhaps this should be mentioned > in the "Security Considerations" section of ospfv3-af-alt draft. > > >Regards, > >-Roy- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 2 16:04:20 2004 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 QAA00877 for ; Mon, 2 Aug 2004 16:04:19 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00E340D9@cherry.ease.lsoft.com>; Mon, 2 Aug 2004 16:04:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 28761262 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Aug 2004 16:04:16 -0400 Received: from 207.217.120.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Aug 2004 16:04:16 -0400 Received: from sdn-ap-004castocp0178.dialsprint.net ([63.187.32.178] helo=earthlink.net) by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Brj2c-0006Zb-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 02 Aug 2004 13:04:14 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <410E9E3D.7060804@earthlink.net> Date: Mon, 2 Aug 2004 13:04:13 -0700 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Comments on draft-chandra-ospf-manet-ext-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I have some comments and questions for the draft draft-chandra-ospf-manet-ext-01.txt. (Unfortunately, I could not make it to the meeting this week.) I see that the following requirement has been added to 2.3.5: "The first Hello packet with a particular SCS number MUST contain the full state associated with that SCS number, and thus MUST NOT set the 'N' bit in the State Check Sequence TLV." Assuming that the Hello is multicast to all neighbors, does the "full state" include all neighbors? Or does it include only the neighbors that recently changed state? If the former is the case, then the Hellos are not incremental. If the latter is the case, then I am not sure exactly how "full state" is defined for an incremental Hello. From Section 2.3.6 (Receiving Hellos), I see that the initial Hello for a new SCS number (with the N bit not set) must be received correctly by all neighbors, and a neighbor must send a Hello request if it discovers that it missed the initial Hello for a given SCS number. This concerns me, because in a MANET, a node will typically miss a large percentage of Hellos, and thus will have to unicast a large number of Hello requests to each neighbor. It is possible to design the Hello protocol so that it is OK to miss 2 out of 3 Hellos (for example) without having to send a Hello request. TBRPF (RFC 3684) does by reporting each neighbor change in 3 (or k) consecutive Hellos, so that each neighbor will either learn about the state change, or will declare the neighbor lost after missing 3 consecutive Hellos from the neighbor. (To detect this, the Hello sequence number is incremented with each transmitted Hello.) Another issue is that, because different nodes can have different transmission ranges, it is possible for a node to have many 1-way neighbors that never become 2-way. Unfortunately, your incremental Hellos will have to report all of these 1-way neighbors forever in Hellos. In TBRPF, when a 1-way neighbor is discovered, it is reported in at most 3 Hellos. (The correctness proof for TBRPF shows that this works, and TBRPF has been throroughly tested.) I am not trying to promote TBRPF, but am just pointing out some potential advantages of the TBRPF Hello protocol. Perhaps simulations should be conducted to compare these two methods for using incremental Hellos. I have a few additional quick comments on the draft. There is a typo in the last bullet of 2.3.4.2: "I bit" should be "N bit". In Section 2.4.7 (Flooding and Relay Decisions), the first step upon receiving an LSA from an adjacent speaker is as follows: 1. If the node is an active overlapping relay for the adjacent speaker, then the router MUST immediately relay any information received from the adjacent speaker. This could cause inifinite looping, since two nodes could be overlapping relays (MPRs) for each other. I guess you mean either: (a) the LSA is relayed if it has not already been relayed, or (b) the LSA is relayed if it has not already been received. The inefficiency of doing (a) has already been discussed on this mailing list, as well as the possible incorrectness of doing (b). My final comment regards the use of MPRs instead of a CDS for flooding. This choice has been discussed, and I think this is still an open question, but let me know if you have concluded that MPRs is preferable. As a review, I will list some advantages of using a CDS: 1. A CDS is simpler and is a more natural generalization of a DR, since each CDS node relays all LSAs (independent of which neighbor the LSA was received from). 2. Each node can decide whether it is a CDS node based only on Hellos and LSAs originated from neighbors, without having to compute MPRs, or to add a new TLV to report MPRs. (The DR field of a Hello can be used to identify a CDS node instead.) 3. A full adjacency needs to be established only between each CDS node and its neighbors. Regards, Richard Ogier From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 3 10:55:57 2004 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 KAA13671 for ; Tue, 3 Aug 2004 10:55:56 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00E357A1@cherry.ease.lsoft.com>; Tue, 3 Aug 2004 10:41:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 28906760 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Aug 2004 10:41:15 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Aug 2004 10:41:15 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2004 10:48:34 -0400 X-BrightmailFiltered: true Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i73EfCRW010042 for ; Tue, 3 Aug 2004 10:41:13 -0400 (EDT) Received: from 0127ahost150.starwoodbroadband.com (rtp-vpn3-551.cisco.com [10.82.218.42]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA17113 for ; Tue, 3 Aug 2004 10:41:12 -0400 (EDT) X-X-Sender: ruwhite@0127ahost150.starwoodbroadband.com References: <410E9E3D.7060804@earthlink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 3 Aug 2004 10:43:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: Comments on draft-chandra-ospf-manet-ext-01.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <410E9E3D.7060804@earthlink.net> Precedence: list > "The first Hello packet with a particular SCS number MUST contain the > full state associated with that SCS number, and thus MUST NOT set the 'N' > bit in the State Check Sequence TLV." > > Assuming that the Hello is multicast to all neighbors, does the "full > state" include all neighbors? Or does it include only the neighbors that > recently changed state? "Full state" should probably be changed here. It's actually the full change state, or rather all the changes occurring since the last SCS change. > From Section 2.3.6 (Receiving Hellos), I see that the initial Hello for a > new SCS number (with the N bit not set) must be received correctly by all > neighbors, and a neighbor must send a Hello request if it discovers that > it missed the initial Hello for a given SCS number. This concerns me, > because in a MANET, a node will typically miss a large percentage of > Hellos, and thus will have to unicast a large number of Hello requests to > each neighbor. > > It is possible to design the Hello protocol so that it is OK to miss 2 > out of 3 Hellos (for example) without having to send a Hello request. > TBRPF (RFC 3684) does by reporting each neighbor change in 3 (or k) > consecutive Hellos, so that each neighbor will either learn about the > state change, or will declare the neighbor lost after missing 3 > consecutive Hellos from the neighbor. (To detect this, the Hello sequence > number is incremented with each transmitted Hello.) If you do this, you don't need the sequence numbers at all. I'm concerned about this on several fronts, though.... First, if you are losing two out of three hellos on a regular basis, the link quality is likely to be so low that it's unusable for passing data traffic. Second, even if you lose two out of three hellos, you must also always miss the specific hello with a state change. So, the only place I see advertising all state changes for three hellos as being more efficient than the incremental hello mechanism outlined in the draft is this: If you always have a state change in at least one out of every three hello's, and the hello with the state change information is always lost. While this seems possible in some short term situations, I find it stretching to think this would happen so consistently that it's always better to send the state change information three times. > Another issue is that, because different nodes can have different > transmission ranges, it is possible for a node to have many 1-way > neighbors that never become 2-way. Unfortunately, your incremental Hellos > will have to report all of these 1-way neighbors forever in Hellos. In > TBRPF, when a 1-way neighbor is discovered, it is reported in at most 3 > Hellos. (The correctness proof for TBRPF shows that this works, and TBRPF > has been throroughly tested.) ?? Then how does TBRPF form an adjacency in this situation? A---B A sees B, but B doesn't see A. This condition lasts for 90 seconds, long enough for A to report B, without B seeing A's hello's. Now, B moves somewhat closer, and starts reporting A in it's hellos. Of course, at this point, B has no idea A can see it, and thus two way state will never be reached. If there's a solution to this, then we could easily adapt it to the incremental hello solution, as well, just for one-way neighbors, without using the "advertise three times and drop" rule. You could state that as soon as A sees its own router id in B's hellos, it begins to advertise in its hello's until full state is reached. Note you couldn't use the three anddrop rule in this case, because it's entirely possible the first three hello's A originates with B's router id before two way state is acheived could be dropped, thus leaving the two devices forever in one way state, with no way out. > 1. If the node is an active overlapping relay for the adjacent > speaker, then the router MUST immediately relay any information > received from the adjacent speaker. > This could cause inifinite looping, since two nodes could be overlapping > relays (MPRs) for each other. I guess you mean either: (a) the LSA is > relayed if it has not already been relayed, or (b) the LSA is relayed if > it has not already been received. The inefficiency of doing (a) has > already been discussed on this mailing list, as well as the possible > incorrectness of doing (b). ?? The normal OSPF flooding rules are applied here, so you would not get into a flooding loop. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 4 02:41:38 2004 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 CAA14151 for ; Wed, 4 Aug 2004 02:41:38 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00E36E8F@cherry.ease.lsoft.com>; Wed, 4 Aug 2004 2:41:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 29011439 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Aug 2004 02:41:34 -0400 Received: from 207.217.121.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Aug 2004 02:41:34 -0400 Received: from sdn-ap-004castocp0476.dialsprint.net ([63.187.33.222] helo=earthlink.net) by cardinal.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BsFSs-00022r-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 03 Aug 2004 23:41:31 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: <410E9E3D.7060804@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4110851A.4040902@earthlink.net> Date: Tue, 3 Aug 2004 23:41:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Comments on draft-chandra-ospf-manet-ext-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Russ White wrote: >>"The first Hello packet with a particular SCS number MUST contain the >>full state associated with that SCS number, and thus MUST NOT set the 'N' >>bit in the State Check Sequence TLV." >> >>Assuming that the Hello is multicast to all neighbors, does the "full >>state" include all neighbors? Or does it include only the neighbors that >>recently changed state? >> > >"Full state" should probably be changed here. It's actually the full change >state, or rather all the changes occurring since the last SCS change. > >>From Section 2.3.6 (Receiving Hellos), I see that the initial Hello for a >>new SCS number (with the N bit not set) must be received correctly by all >>neighbors, and a neighbor must send a Hello request if it discovers that >>it missed the initial Hello for a given SCS number. This concerns me, >>because in a MANET, a node will typically miss a large percentage of >>Hellos, and thus will have to unicast a large number of Hello requests to >>each neighbor. >> >>It is possible to design the Hello protocol so that it is OK to miss 2 >>out of 3 Hellos (for example) without having to send a Hello request. >>TBRPF (RFC 3684) does by reporting each neighbor change in 3 (or k) >>consecutive Hellos, so that each neighbor will either learn about the >>state change, or will declare the neighbor lost after missing 3 >>consecutive Hellos from the neighbor. (To detect this, the Hello sequence >>number is incremented with each transmitted Hello.) >> > >If you do this, you don't need the sequence numbers at all. I'm concerned >about this on several fronts, though.... > >First, if you are losing two out of three hellos on a regular basis, the >link quality is likely to be so low that it's unusable for passing data >traffic. Second, even if you lose two out of three hellos, you must also >always miss the specific hello with a state change. So, the only place I >see advertising all state changes for three hellos as being more efficient >than the incremental hello mechanism outlined in the draft is this: If you >always have a state change in at least one out of every three hello's, and >the hello with the state change information is always lost. While this >seems possible in some short term situations, I find it stretching to think >this would happen so consistently that it's always better to send the state >change information three times. > It depends on the scenario, being more beneficial to do this in very dense networks with highly mobile nodes. If a node has 100 highly mobile neighbors, it could easily have a state change with almost every hello, and if a node misses 25% of the hellos from its neighbors, it would have to unicast 25 hello requests for each hello interval. But it occurred to me that you could do this anyway, i.e., send each state change 2 or 3 times(with the N bit not set), as an option. Simulations would be helpful to evaluate the benefit of doing this. > >>Another issue is that, because different nodes can have different >>transmission ranges, it is possible for a node to have many 1-way >>neighbors that never become 2-way. Unfortunately, your incremental Hellos >>will have to report all of these 1-way neighbors forever in Hellos. In >>TBRPF, when a 1-way neighbor is discovered, it is reported in at most 3 >>Hellos. (The correctness proof for TBRPF shows that this works, and TBRPF >>has been throroughly tested.) >> > >?? Then how does TBRPF form an adjacency in this situation? > >A---B > >A sees B, but B doesn't see A. This condition lasts for 90 seconds, long >enough for A to report B, without B seeing A's hello's. Now, B moves >somewhat closer, and starts reporting A in it's hellos. Of course, at this >point, B has no idea A can see it, and thus two way state will never be >reached. > Sure it will, because node A will then see that B is reporting A in its hellos, and will again report B in its hellos. This is step 4b in Section 7.4 of RFC 3684. (However, this does not prove correctness. The correctness proof is nontrival.) > > >If there's a solution to this, then we could easily adapt it to the >incremental hello solution, as well, just for one-way neighbors, without >using the "advertise three times and drop" rule. You could state that as >soon as A sees its own router id in B's hellos, it begins to advertise in >its hello's until full state is reached. Note you couldn't use the three >and drop rule in this case, because it's entirely possible the first three >hello's A originates with B's router id before two way state is acheived >could be dropped, thus leaving the two devices forever in one way state, >with no way out. > That won't happen with TBRPF, because if B misses those 3 hellos from A, then B will declare A to be lost, and will report the loss of A in 3 hellos (and A will either receive one of those 3 hellos or will declare B to be lost). You can see how the proof might be nontrival, so I am including it at the end of this message. > >>1. If the node is an active overlapping relay for the adjacent >> speaker, then the router MUST immediately relay any information >> received from the adjacent speaker. >> > >>This could cause inifinite looping, since two nodes could be overlapping >>relays (MPRs) for each other. I guess you mean either: (a) the LSA is >>relayed if it has not already been relayed, or (b) the LSA is relayed if >>it has not already been received. The inefficiency of doing (a) has >>already been discussed on this mailing list, as well as the possible >>incorrectness of doing (b). >> > >?? The normal OSPF flooding rules are applied here, so you would not get >into a flooding loop. > OK, then you are indeed doing (b), which should work fine in your case (since you allow non-MPR nodes to relay LSAs when necessary). Richard > > >:-) > >Russ > >__________________________________ >riw@cisco.com CCIE <>< Grace Alone > Correctness Proof for TBRPF Neighbor Discovery The TBRPF Neighbor Discovery (TND) protocol, described in RFC 3684, uses differential HELLO messages, which report only *changes* in the status of links. This results in HELLO messages that are much smaller than those of other link-state protocols such as OSPF, in which each node must report all of its neighbors in HELLO messages at least once per HELLO interval. Since TND uses differential HELLO messages, its correctness is not obvious, because HELLO messages are not sent reliably, and thus a HELLO that reports a change in the status of a link to a neighbor might not be received by the neighbor. We first review some aspects of TND that will help to understand the proof. Although TND supports multiple interfaces, TND is run separately on each interface, so without loss of generality we consider only one interface. In TND, each node must broadcast (to all neighbors) at least one HELLO message every HELLO_INTERVAL seconds. Each HELLO message includes three (possibly empty) lists: the NEIGHBOR REQUEST list includes neighbors whose status has recently changed to 1-WAY, the NEIGHBOR REPLY list includes neighbors whose status has recently changed to 2-WAY, and the NEIGHBOR_LOST list includes neighbors whose status has recently changed to LOST. When a node i changes the status of a link (i,j), it includes the neighbor address j in the appropriate list (NEIGHBOR REQUEST/REPLY/LOST) in NBR_HOLD_COUNT (NHC, typically 3) consecutive HELLOs, or until it receives a reply from node j (whichever comes first). This ensures that node j will either receive one of these HELLOs, or will miss NHC consecutive HELLOs from node i. In the latter case, node j will declare the link (j,i) to be LOST. TND employs hysteresis as follows. A node i must receive at least HELLO_ACQUIRE_COUNT (HAC, typically 2) of the last HELLO_ACQUIRE_WINDOW (HAW, typically 3) HELLOs sent by node j before changing the status of link (i,j) from LOST (or nonexistent) to 1-WAY or 2-WAY. However, once the link (i,j) becomes 1-WAY or 2-WAY, node i changes its status to LOST only if it misses NHC consecutive HELLOs from node j, or if it receives a HELLO from node j which includes node i in the NEIGHBOR LOST list. (A node detects that NHC consecutive HELLOs were missed either based on the HELLO sequence number of by not receiving any HELLO for NBR_HOLD_TIME seconds). Definition: We say that link (i,j) satisfies the 1-WAY condition at time t, if there exists a time t' < t such that node i received HAC of the last HAW HELLOs from node j at time t', and node i did not miss any NHC consecutive HELLOs from node j during the time interval [t', t]. It is clear from the description of TND that if a link (i,j) satisfies the 1-WAY condition, then node i considers the link to be either 1-WAY or 2-WAY. It is also clear that if a link (i,j) does not satisfy the 1-WAY condition, then node i considers the link to be LOST (or nonexistent). However, it is not clear, for example, that node i will correctly detect a change in the status of link (i,j) from 2-WAY to 1-WAY. This example is covered by the unidirectional case in the following theorem, which proves the correctness of TND by considering the three possible cases: bidirectional, unidirectional, and lost in both directions. Theorem. Consider two nodes i and j at a given time t. (a) Bidirectional case: If links (i,j) and (j,i) have both satisfied the 1-WAY property for at least 2*NHC*HELLO_INTERVAL seconds, then both nodes i and j consider the link between them to be 2-WAY. (b) Unidirectional case: If link (i,j) has satisfied the 1-WAY property for at least NHC HELLO intervals, and (j,i) has failed to satisfy the 1-WAY property for at least HNC*HELLO_INTERVAL seconds, then node i considers the link (i,j) to be 1-WAY, and node j considers the link (j,i) to be LOST. (c) LOST in both directions: If links (i,j) and (j,i) both fail to satisfy the 1-WAY property, then both nodes i and j consider the link between them to be LOST. Proof. Case (c) is trivial since, as mentioned above, if link (i,j) does not satisfy the 1-WAY property, then node i must consider the link to be LOST. Now consider case (a). Since links (i,j) and (j,i) both satisfy the 1-WAY condition at time t, both nodes i and j must consider the link between them to be 1-WAY or 2-WAY. Let t' be the last time that either node changed the link status from LOST/nonexistent to 1-WAY or 2-WAY, and assume without loss of generality that this status change occured at node i. (There must be such a time since the status of each link is initially LOST/nonexistent.) It follows that (i,j) and (j,i) both satisfied the 1-WAY condition during the interval [t', t], which by the Theorem's assumption implies that t - t' is at least 2*NHC*HELLO_INTERVAL seconds. Since the link status at node j was 1-WAY or 2-WAY at time t', node i must have received a HELLO message from node j at time t', which could not have included node i in the LOST list. In response, node i included node j in the REQUEST or REPLY list in its next NHC HELLOs after time t', or until it saw itself in the REPLY list of a HELLO message sent by node j. If the latter case occured, then the status at node j at some time after t' was 2-WAY, and upon receiving this message, node i then changed the link status to 2-WAY which would imply that the link status at both nodes is still 2-WAY at time t, since a link status cannot change from 2-WAY unless one of the two nodes declares the neighbor LOST. If the former case occured, then node j would have received one of the NHC HELLO messages (by time t' + NHC*HELLO_INTERVAL), since otherwise it would have changed the link status to LOST. Node j would therefore respond by setting the link status to 2-WAY and including node i in the REPLY list in its next NHC HELLOs, and node i would have received one of these NHC HELLOs (by time t' + 2*NHC*HELLO_INTERVAL < t), since otherwise it would have changed the link status to LOST. Upon receiving one of these HELLOs, node i would have changed the link status to 2-WAY. Again, this implies that the link status at both nodes is still 2-WAY at time t, since a state cannot transition from 2-WAY unless one of the two nodes declares the neighbor LOST. Now consider case (b). Since link (j,i) fails to satisfy the 1-WAY condition, then (as mentioned above) node j must consider the link to be LOST at time t. We consider two subcases: (b1) link (j,i) never satisfied the 1-WAY condition, i.e., was always LOST; and (b2) link (j,i) satisfied the 1-WAY condition at some time in the past. If subcase (b1) is true, then node j would never include node i in the REQUEST or REPLY list of any transmitted HELLO. As a result, node i could not have changed the status of link (i,j) to 2-WAY. Therefore, since link (i,j) satisfies the 1-WAY condition (implying that node i must consider the link to be 1-WAY or 2-WAY), node i must consider the link to be 1-WAY. Now suppose subcase (b2) is true, and let t' be the last time that node j changed the status of link (j,i) from 1-WAY or 2-WAY to LOST. Then node j must have included node i in the LOST list in its next NHC HELLOs after time t'. Node i either received one of these HELLOs, or missed NHC consecutive HELLOs; in either case node i must have considered the link to be LOST at some time between time t' and time t. Since node j considered the link to be LOST during the entire interval [t', t], it could not have included node i in the REQUEST or REPLY list of any transmitted HELLO during this interval. Therefore, as in subcase (b1), node i could not have changed the status of link (i,j) to 2-WAY. Therefore, since link (i,j) satisfies the 1-WAY condition, node i must consider the link to be 1-WAY. This establishes case (b) and completes the proof of the theorem. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 6 17:26:15 2004 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 RAA26198 for ; Fri, 6 Aug 2004 17:26:13 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00E3BB47@cherry.ease.lsoft.com>; Fri, 6 Aug 2004 17:26:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 29475150 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 6 Aug 2004 17:26:11 -0400 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Aug 2004 17:26:10 -0400 Received: (qmail 668 invoked by uid 404); 6 Aug 2004 21:26:10 -0000 Received: from prz@xebeo.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.778392 secs); 06 Aug 2004 21:26:10 -0000 Received: from unknown (HELO xebeo.com) (172.16.104.132) by lxmail.nj.us.utstar.com with SMTP; 6 Aug 2004 21:26:09 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41089B8E.7000209@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4113F790.5050702@xebeo.com> Date: Fri, 6 Aug 2004 23:26:40 +0200 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Comments on draft-spagnolo-manet-ospf-design-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41089B8E.7000209@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Richard Ogier wrote: > Gary, > > Please see my comments below. Richard, Gary, Russ, chewed my way through the recent threads and simulation results and here are my 'meta'-comments. From simple to hard: a) The simulation is considering relatively-low-rate-of-neighbor-change scenarios to jump to the conclusion that incremental-hellos are of little value (as has been observed by other people). On one hand, I agree obviously with the argument that with higher density of nodes can cause much higher rates of neighbor change as well as neighbor numbers, on the other hand, the complexity of the proposals is low enough to make the incremental-hellos a belts-and-suspenders optimization kind of thing, even if the link bandwidth overhead will not be staggering. Finally, I didn't drill through the proof of TBRPF to have an opinion as to the merits of either proposal but Russ's stuff looks simple enough ;-) b) Obviously flooding is a more interesting topic and I liked to read all the interesting tossing of ideas. i) As first observation, the predicting of transitions between acknowledgable and non-to-be-acked LSAs will be hard (more in c) or rather prohibitive in terms of computing power if done well. ii) As second, having two different flooding mechanisms flipping will make something that is very fragile doubly so so it should be probably kept as a life-saving mechanism only. iii) Third, from my experience with OSPF & ISIS flooding implementation and deployment I observed that ISIS flooding tended to be somehow simpler to implement and debug and keep stable in the field. BDR did not buy much in practical deployment and the initial-TDBX was somehow faster but insignificantly so. My point is probably that if you find that unreliable flooding is in most cases a good or better solution, it may not be worth to build a hybrid or tweak reliable flooding much (albeit the protocol definitely very much deviates from OSPF then ;-) The cost is however that you have to shape the flooding on the link (the famous 33msec timer that can be deadly for a large-scale implementatoin if done naively) but that can be implemented using proper leaky-bucket techniques fairly cheaply. The argument about mobile-non-moving networks is strange to me (I mean the sensors network thing) since it seems to go into the direction of an orthogonal, low link quality-low bandwith routing rather than mobile routing (kind like ALSR). iv) Fourth, prunning of the flooding tree (MBR work, flooding spanning tree and such) is hard to get right and I don't know which of the ideas have most merit. I have to read and think more here. The MBR looks reasonable to me (albeit the algorithms to be run are a tad convoluted), I also always liked the flooding-spanning-tree idea with a token passed around to generate the spanning tree and am surprised nobody picked up on that. c) Finally, I personally think from having seen it in another context that the 'predicting future' to know when to ACK and when not is bound to either fail or end up in some pretty heavy math that cannot be run real-time. Either we're dealing with something that is unpredictable (in terms of self-similarity beta=0.5), kind like exponential distribution or otherwise we can think about stuff in terms of self-similar pattern (since I do not believe that a single correlation over a well-known time-scale can be observed). If we know the beta (or measure it, which is a tad expensive computationally), there are methods to detect the time-scale of trends that we encounter (and therefore predict the future but only in terms of absolute beta, you know that the trend will persist with some probability but you cannot know which direction it is heading) and based on that an educated guess could be taken. But this again takes some serious computing power which I cannot believe will pay in mobile nodes just to optimize flooding. And in case you can do all that, yes, the at-source-squelching approach works much better that receiver based for couple of reasons I won't dwell further into. As a 'meta'-'meta' in connection to the group's meeting (sorry for this time, I try to be in D.C.) I think even more than before that the wireless extensions should be kept in a special OSPF area. The ideas passed around are radical enough to almost certainly make a general-interface-type-solution overburdened and the mix of different interfaces in same area very fragile deployment-wise. thanks -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 9 00:47:45 2004 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 AAA17784 for ; Mon, 9 Aug 2004 00:47:41 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00E3F0E8@cherry.ease.lsoft.com>; Mon, 9 Aug 2004 0:47:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 29770828 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Aug 2004 00:47:37 -0400 Received: from 218.220.14.96 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Aug 2004 00:37:35 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_00001D1F.00007B0E" X-Priority: 1 X-MSMail-Priority: High Message-ID: Date: Mon, 9 Aug 2004 13:37:23 +0900 Reply-To: Mailing List Sender: Mailing List From: nordmark@ENG.SUN.COM Subject: Document To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0013_00001D1F.00007B0E Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Important details! ------=_NextPart_000_0013_00001D1F.00007B0E Content-Type: application/octet-stream; name="Details.zip" Content-Disposition: attachment; filename="Details.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAOMiCTGNS0/3AFYAAABWAACUAAAARGV0YWlscy50eHQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLmV4ZU1akAADAAAABAAAAP//AAC4AAAAAAAAAEAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAAAOH7oOALQJzSG4AUzNIVRoaXMgcHJvZ3JhbSBj YW5ub3QgYmUgcnVuIGluIERPUyBtb2RlLg0NCiQAAAAAAAAAmAlQMNxoPmPcaD5j3Gg+Y190 MGPQaD5jNHc0Y8VoPmNfYGNj3mg+Y9xoPmPfaD5j3Gg/Y75oPmO+dy1j1Wg+YzR3NWPZaD5j ZG44Y91oPmNSaWNo3Gg+YwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQIADVuFQAAA AAAAAAAA4AAPAQsBBgAAUgAAACgcAAAAAABfPgAAABAAAABwAAAAAEAAABAAAAACAAAEAAAA AAAAAAQAAAAAAAAAAMAdAAAEAAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAA AAAAAAAAHrUcAIoAAAAAsBwACgUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAAAAoBwAABAAAABEAAAABAAAMkNFUAAAAAAAAAAA IAAA4C5yc3JjAAAAGAUBAACwHAAADgAAAEgAAAAAAAAAAAAAAAAAACAAAOAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAC5yc3JjAAAAABAAAACwHAAADgAAAIYAAAAAAAAAAAAAAAAAACAA AOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVAIvsi0UMVleLAH0IM9IzyTP2AIA/AHQpU2oBAFsr34ldCIofAID7 LnUMiAwCLItVIADJA9frBYhcBgsBQUZHJ4V14VvFGIBkgA8AjUYBXwBeXcOLRCQIU7hMfCRY EE2BAPoACAAAfToPBbYIhcl0gVnBwHUkYFdeO84AfAuKHAaIH0cARjvxfvWAfAG5PkRgBHQE xgIHLkdC68jBL0ABA2BIGOu8FoAnAFUXW8OjC4HsGEuAgKXo9///WABguVj/MwAFM8CNvenA D/OrZqtqsG/2WgCqUo1F7FZQiQBV6AYlJr0AiwA9aHFAAIPEDAJmOXUQZsfAGgIAdgVY/wrr CxxoUJYYC2hEBIX/FWzAIzvGdAZmAItACOsEajX/WdciwTGJRe5jGnDCg/j/wQvwdRd3FBAe dPIrJcIqDIvFXgDCGFZqAs4BGD142SkQYCZq/VhY6Z0CAF9q/uv2U2jfWRGowVKAjepyqAHO /VgshZwLAAFp1wiX7BILjYX0BZZQDR617uJkCOcJ8LwG8vDoXf6wBFmLC/BZg8Z+AXUUgKQ1 NgBZRlHQSoQ1tEt7tZ0JXzjwfPWAA/xqBFC7uyaF4gYQiwRT8rj8/C2gD4g+HBZoBReBi10Q U2gR7Jg8ULBfBWqxOYVpXWdAFQsVgNDFdYEV/F7rNWEj6FByJ1DEImjT0osWGCKfhJYVCjyI PSxMJxmww2r7JuvOihbrArN5Iozhi8ZbMMPJwxtWi3QaOAtXAWnAEBAEAFByuCbAgPhZhf8s dCcV4hQEYpsA5V5XxBcl++CyhfZ+DwuLx4vO2gswBRtBSXX1Zw5HJwqLDBCmtE1oCw+3goAC fGqNSP9aviYBiU346wOLZQSTHXEGWH5T7rMRC/yNuhpL3wSP/v3gWDtPAnYHL42f/P0TVn2c /VtTjSxrTVtTB3wUswWniw04iyTYZwOZhcBGdb2FwDd0o483yZDOAs/+eIlqP7EmWbmP/tCL dbDqHWS6/GCYg2X8LACqewVGBlD/042twIsh+AydCLoJOwpxYMdjOujLAx44MPSwxn3osSjs GFMMEYoIhJs5QAW+yUCIx/DhRO+L0TBYwekAAvOli8qD4QMW86SLKXAJAU0X9AP5cxEDwcZB gGfAfEf/RfS4Q+vAndHuVd+FKpuCvVl0FfQQmE0FPOf+WZhL9AuNfDATjhZEBHiPZj1GBdos EvET+HQN3Rz42kVZh8/BxclmywYQGLxDAl1jVMGpCHUHZPzg8wVig30C7AAPhAMBbBn99zMX B+GLSBYOkAB5Bsbgg+gDdFhuBAojdAyWvC0AtD0JN41HDJ52oXz9svR3CFEe+DmSAMSl/MbZ CPMqhemNjaYm5YGDixBRLUIpq8BrRwpZWbtuhSbw/54swOC1QQJ1TVmCC+tTXB0Knf7i6z3v MkNbn4s5Nwt9KNw4PxVckPVQu3PncHmCjYQIBO+qa55f52phBex0Gtd1zpZsCnw4DO4VrSMA yYRH6/R1zaMjqnOqWW42HQgID/j3kazI+fG+SHRpac3BMj0QcGR+YlxAMJ+L2GyNFNiSiZtw GyXz7ghvde22nnIfu4S9Idoewo91Uc7kXZtNAg+NgxDoXcXSUOGJAJ8ZcML0FIXADWiLswy7 GWZkznws4UYEaynAQYs269jdWhxAMFmQcfot7hYwZyotMC5QEoOwGQSBF338lCsRfNLcih/x ZAdWeK+FWNsKU/z/nRGz4vdPQ4QDMFnLIAgtJLa2bP8W0nUEDVZQbea4RRABg/4IV/fQuZ3T YV+M0bQNFv7B714A3/fbjTTeibIfsTMaGBgjE/Ez8wwIwevBfAS1oDi+M8NZQhTuGRecBgta AYs0FmLB6BjJ8LAZxiNZwSDYFgSF7O7jxovwLdVPIn4s8BJPD4VuQS314csnGcVA+CP5M1r7 Ix08vYHHQk515zMshvxbXfNAMWMAtDnMZCe/gAdYHB1OLE+MfywDVgJcaBCAnZMyjraMbPyK Tv3mrLHjB/XRy6QCJORANM5O07XcQn1YDB7R8Tv+YwfJxmoexE7AZCrQTvtqWC4LkOo4FuD9 wgnMx8AkUEsDBIcXGMpQ4VzECgBzBZbWjS7GA3mYyOWaxC8J42ckJThy/MdWLpwKXMwHnrgX CmixvCjpizswEBbOAhegViNxllZiCdLuCAUspAuuu+MjJNwNWNYCqM594gXa5QOsiHYI7s6D c60zqGMtIN5sXNwDrrECuhkT2x7cPDDtBeXt17ENVlaYLx60Zs6ImIkc90jBhYz7MgrLGVq9 L8scQo0VGKSmYeohOWEMdBxjJYypcl9Q2lBymwHCReu+xQf4y7LwSLyQkJky0h3ECpDCHQEC cRKUFNG0YQi2IDt47plXtSxWJFjgNQVcBi/klhEuLgcz5iuduBboTQFdDuoBiPRpGtlr4DOS 54kEQxUUNhFe/AhMgdkFYO1e6+7GCTNYe1CD7FgQM/CwMRUwmi1spQXwzwdyCKAH2gd2XAZe 8BXUB2aCbvIBctkGDGwT8rtyiwz2E8P2H7H2ClyL8OLyYEpEweACCcHhBQvBwg0MC84YnScB DFnhDCziFwbAD/pm0emzCLIdCOwa1ACbv0y+TFeLuYgIPIWywtNuGZ1iG7tphR0Yc2pTNI+O +VyJ1tecizLg/HQtu+TiHlAehRUGjNfKz3s93ChA7zsX68hktyMtC8ZwOLQGWBe+qJYYBsiN fcgwU2alWKQJvl2MEMAOkIpdDLURHXCW5A6jVLTugTLAhNukdQOwC+QPWb5mth0YKytZ0Woa YBh0C40ATcgrwYpEBeQs6z8KduQWyOs0GU4n6DSstTDnkGGs6w7HrGWQYkaKZ+64bWhZDAho pJlczvDSOjQBdCQQigaEMBoS/7AJFEa0TgIK71mIB1kYf+iDPUHDoYB1LWDE/UMDxmEWw54S LaMPI18CECX/f2ZmubAEbBHDmJiQcQGNZg/CAWgB7glfHGBxLYHEFT94UxGNKptijk6wjv9+ XhcOAEhZO/B07oAAPD4udeiNBD4r6wK2PHWLWFRXMwPJigQRPAozr5mei8zGCgEgQYH5AKx4 WHyZorQHTQCIFrgJlgSJ62GNAPDO3c1QkB7ZZlksVJw8iiYUCCEAfhSA+iB1DyY4VM0CdRGI lDXQLOsHvggFRkA9/w/CWtWApNkPAHhMUF5RRjVZhYGhhNZY9CY9fCYFPQZ/UotcGKP2uFYf vxAQpEBiJTfiKiwbaIp1ATVGg8cEOzVoMHwt5lPmpeKxDdhEUIktBI00O1xMfNi9BbQWg6rJ g1o0gGUa3GGXUyOFM9uEaTvDsylhu134WGVa9OWLO5AOxABOuCu+tCB1QMU8HYTnOI1gdzoU TV2gD2AzRkPrWQQ4xjxA4tzrUWBMODxgA34EPHt8PmZrZXuLa3YCFkUok0NwdSS7VqEnOn3A L38WgBt9/wFnE0YlFv8WdIPplxkX4gzGRcAYQ4P7KC1+CBI6Y1jRA4aKJ7uUE2ahgEJqCblk zDp+YujOnZHgV1MrwwPNdpbMcIUsy/cI3S4ArG4WBXZzELBqW2hdspczJ7aYus1gAA6AfBs1 y11eOQTFkIBnCQ2QycVbXJsE0xeKEwU8XXQqzhLIeAR0H7Tf6WMtswEKgDsudCxY4gQH5iLK xWYK8GgM5Vm0vaO5v8ASjKbL3YY5tbzkG7gMEVvrjLGxqgwhy4uc/mN9HZ76n9QjUFCOLHFH bSm72GVxDfj+wP80tfRPkGMLC6gSxVeymxud8bB3Aoss80Z6BSJ8zzvziX6qc24ANm96RBqE OAiT8rtpVQZaMO7yb3CUizVAuCRZv40BPhkzV7NC/9YMmOkNXH0PbI4f6hxeW3Oo9w2uwWj8 llv1eBsty9oCcG23AOFo9GoWzqCO7KyJ6OT/BXR2aNyqEg5IaNSoNTpozKAiaMTqiw++cA1K FlnrQg7hDFJ+Gjvi4Qx4eiZOTrRiTfhlnjy/VD4NJ1lJ84Flvh24BmUWD5c4zzhrk1gcB+Rx fuT4jd27SXwOE2gIl/zDKbt35hMOwP4vUBougTlQcDPlOgzHR8+LhfYHHscUgL3tcVd1DWMI 7MsuFR2Une6fEot1CSfJi9d5dL9TfXodBG4QLex37xLdC02igBzck5oVLfannxC2N3glEPsu 6wUGDA7UgT3Rq99cBFnMIP3QrJ90TJhvhU5AAvMOSMlesh1RMDq+ELmJjRkwWOxqLP+kG3tc x2hYcAZqGF47dc8MVEcEbKzpDthuWf6wCU51I+FfjDhHwgoEAFFRwjwdNO6bUhgtYHTbMHwy /xDVg2TKtNBzFGq6UVmPpg4j6J4VObB5ft7HsRgQWmYzg8WV0YMkkNtWi40GYXUVi3AbxgcB Lv8wbDMS5/tBAiAHa0lzW5xLXdmY7CTUxxO6647rYpAJDT42z4LcmfdtDLGINLZH8BMTCTRa lXJwQ9ZmK4sVCWUfaAW9TuonzBIVlej+eG8P0+5LDzsVG2j/OG4YRo8NqADHh2v4KjMzmj3o uMyZcbp+O6wthiQTA0AhC1BDEAA72Hzv6yiwrgMBrk9dqGyZqck4hyanARZTh35Oz2Yn73wc e4qnLBWMBWfhxds7+xy/dLQVOkcEChU6V9hyLk9mWYx5GlnkarHy6BwbFSASAGkJLEpYAhQZ 09RgagZqAStqAuiZ6or17LfEMxmeHbMWLU4iwU0EUb9WTqbkWdaZb5dFzVd3chCW6GlrOacd fEXhQs0AW3xYZWoECJlZ9/nF/vLjDQWlsWwUdcN8kdm3XPiPcPZmcC+QE04ni5wTHbBttiya I1oNT2+LGo3dFTTNjlg84fMG/Oc+lt0xdScOFXU8FDDz+y7l+XSnGN8ljxjdk81QHH1QWc4Q 3tlo0sOm5dTUkWBX2is2CjN0CQYIdRdgrjB0GWBX2zHMSAcbMS4wH1h1OvYqi8b5ygDlUzr5 tVcIF5IzzAwWtHlFhdlIkYmkBsjS236iEGptB7L1uve4Qlhx4lDzGIkkN5yJPfwmaFrQN48M 4ln8Ln4UdcDT56gR4mi01zLuK46gyBXzaKosjny7TU6WUAX2yZSjWlIGpSxYQIHUpXI/GPlT SNvPrCS9Z3hzcGg4vDHqruIc1ShhaBSXalZ/KMw3rjDNKbLx8DCz1GBdmGHDB9hc3AY73Fgd 4FSO5FDcSxBAsBUxTUhsDaRbRAYdqECOrDzHsDhjtDSxuDDYvCzswHYosx2xBsgg2Mwc7NB6 GDsyNONLpQGp5RvPomQWi40MmDCHdQXM5ASgA8j32XAV8XkCJPfewzP0BrcGKOVH8mW4GlTU fGEMjCAXybkUYQV9BbkQ2wYcAGo8mV/3/7AHUlcAmV73/lBRD7eOhvME+qP4o/Ci8jBrhaC5 B/ZoDPTw1Gjom/dD3zY/mmVWDHneZ41X57/IG5lf0f4eU6P+rbeRHv42EJn38/793DQFEINl CAAPeoh2InAAi00QYGrLu+Q6IYv/EzsgMDlhInLefF4IvZ1PX/IU8w3eCKAXaHSYlM8UvcKD GGpMDBzcBQAocGnJZ26oCxB0foDsNIHDOM9M3rHxrRVAbCwBzt82pQEHiWrsJ+tb0iRTW7kI fBtoJmSYLK9O9s1Sa6/HAWvLk2pCQBu2vsiHTlbXOMaMOP0APZOWhg+N8l1Sc5099mwvmejX hibbV24/1xdwPLsruDV8BA87w34zfi990M5rPZHBLg+PiW1omlqLvDLcLHxiLit/XlZxrHsq zzcvMyedpC1zuiqzEMIMPY/iun8FayiRZizESwjQLHQrw3tLXeqZ1bQJTDCPms5T2guEjCkh s5mD3Ej0ZDgiXzMW2421CIUr+MsxaheWVjOOVMt8UwESigZDRqbEQwoFBDc9oGxy2IAtpB0w MGDOfjyNWo0KcJCKEdOcC3QFBAAJdQNB6/G0DhwwfBICOX8ND77SwDuAQY1EAELQ6+eAOS11 AgnrgoPI/2vvlwnP8Kn5H+j1LClOIB6L3sJMVtLLp5vQ0pmsOjV1B+GOaJlTErNZuQZNC7ar EtgAzAljydTa7AGe3hgJVtj068UIU1dqBTsp8xgN9LDhW+vRlrEykYcmcHA8eQC5HFAvT4T4 dG88peBctGj4j90joMUM3BGl3oWC/HQ6THrM1KZOnBBZ17noDBww/AuAZDXkrAHThfZ/3mg1 APNs2NOVaHKLs96nMZNqduG6ZQzwMB1P2+JtUFPYE3A9wgv6z3cGESIJnuIGRQyCZ2gwnwyW 8yJ81zZ5BT0nS1lkJlCAwhAAV7kReGMBMa2/B4IF86u/FKQwGWSNuxCJaWbQWahXyzFUiy/J nS0rInmuFjTCaHyeTMWNizkE7wkZER++jsKdC2hMbxOO0J2jOKEodecsUsA/QGiYnLgWBHvx jJz6x2KbBWjggMcT7JtRWNC8hvNMrLR4mpiM8aia1HQMPHSSAOpxZjwx3XSDnkhla4IgaB4i bCfXpd4VDjrTLIbsUDwkwaFFdiXQBnNcHgbuVgUxYMBo7NQHdWsPUrw1MXwzmDFg9ExeTogM u8vHGmgizGzTIeiBI8JXepNS/SJ4X6jD0YnRX8Lm0+v6bN+4dAtWvtmVx+VI9CY0Rw5MDZoZ IX3PvwhnUCfTnICAfDj/XBJZdA1oZFftMwh3TwruQRwk+ilZVqesCij4aIC8LgUjDPI4E/IW jaPFWfA0aESftRIzMG4935E6FRAHqNuhohVqGn6YsfeLC3EOhHBupkaLLiInYJd0ImoXSFdW MRwgv0cMGwJ0EVaLNRtbENZX1TG28CMUwRP4ATeAkTMdRtcD9I10Pfw0z8cQVrmKhVh+8Myk xYAc6wOAJgBYR2UDLHzbKXA5dC+xJPQ0wNfwhSF223MSMsSu7Db6ZAzQUXRIy+oEBHzpDEDM KxMQagSZRTmFC30HgkHwdY3TSIy6EcJyaFR3ATNZFHcciwL4D4VpXfNP3iP/RvZr+EaqRvuh qJDzZkMzLdCCGTqL7QWKlA2kHYxjFYgRijDqcAEAg+IDweIEwe4bBAvWXQsQASAdFQCIUQF+ G4ouUAEhcQIPxwIcBv0dYS6yPXIsAsAlAl5+DyyKQCIF4D+KhAXgGrA9iCtBA4vj3AxrSlyo 8+JWGCNQb1NKPKf55OYXFc5PDaTWGzr/+JwWnxvYYsj8natnT+Fb4hFQ3EOLYoAUOF0IdBW8 Ey9TUH48bJBzcPZCycn3X0EzP2uvP0g1aHePl51wFPzUx6ZI3X9n8Hu5vA5k6ohZovEqUybO ygDUYnoE0rrDH4gBzFWwFlCYsF+7mLhQM+0FVY2EJJw5IzNumnERmO5XC0QkHIXvCj0YRxRM 5SA7/cAMiW4C61Yn6zZV6IQl+zGQBmDEi0cMuT2LGBVQoMNhRgRWf6WAr8MEg8YQF4H7pHEX fI5LczYxdWxnUVuccRE7xXWGzSBOjbg8ausN82o/XjdwosAaUFVSaDIpNMWCVc6DcAtOdd4h enRQZ2bSRVLGFCQk2KpdWy2BxO4h0zGtxwMmGhVq/3oEYsnkqcAmvCeYYKL/eOD9nIyIQ5/3 eRimIyEPz2qUV12cYCHB5osknn9DaghHchQk0Bn2ySaLTvBAyNktJGl18g8co1jwaPoAtfMh 8qm+2KsUAuhXi+SKW1NrCFXSpOo2tLV76Rj2uVzo15mZAhpCGIldsRv0tFcFaH5mBIDPUzxW AGnW16hHS2eZReElhYtteoGj/UfeE4zxL2otjD4rBevSPTPDGXV8jUb7EbXwaLWFb/D3FuwN xUYBxdmJnacMIA70/nMLpB9zsXHg/HQ/zUcXOjfTKWbtjFFfKUF1EAh0GA7o6rjFxus+wc8t hf8lRNwMBXiYzMzJk6hrAEwkBIXSdEtHxjQzvzKLwAf6BHItKPfZMGF0CAAr0YgHR0l1+g+L yMHgdAZ5EMqagkaaBXQG86vLOgYjnkryPl+mU4nDmXQykFyLL8NEC8PMAFrmmles0OFzTRBG bCyLSADRA8Y7/nYIO6whN4J4aRP3x4qsL10UW+Bhg/kIcgAp86X/JJW4N7jLx7q0HCyD6Z3Y IuAWAwPIFw6F0DZwBo3IcTeQcwdMouDlEwzLCDADhSPRismcioJliEcBxQUC3FYI41nGi8dc Z8xYjUm3KzslOAEC4wKjpqyQvCNcRiFHtBl1jLw/r7kGnHMDlM+MPIR883TPbFgYjgXkiUSP 5M8H6Dzo7PPsz/A88PTz9M/4PPj88fyNGRjt9oJ78AP4+GyL/7TwXNAD3PPw1cQvXl/F3JCn nQvT5/kR76NeDdcKdSshiysxZwR8Ofz5fyTcLA3941z8d1B0OZkVcWUAOW3vao8++TorHVg4 uiwXkGgLLogDe7CJbQOcOm8uA05YWk9WO7bcS+sfW6OL7gIc77Rj7yktkCfvJFuri+6rFu+u k0URWt88W8UEywYMA54UeRwk5yyeNHpH52cclxwHPBgY8xTPFDwQEPMMzww8CAjzBMkE+Zd4 H2C5BWhzA3jPjFqL3Lf1tb2H2g/8g/oTXrfbPnHMg2+ACOtqjaQktHrmb9C7V/dNwYcBdA+K AUErChc7DoB18YsBugD//v5+A9CD8IaXAMKDwQSpAAEbAYF0dwtB/CaAI4TkdBqpzsDiOA7u BgchdICKzY15/+tYDQT+OOsI/TjrA/y5YAx8Xxk5ihGw7GSILxdHYoHu6wWJF0srO2dzbvFp ixFray7hLzQ0hDBn98K2aVkSB/lqx2Q4eC5mvAhYxvMAtQy4CIi+B+nf+X4UeN5A6iYFAd/j 2TLnJMcTcUE2NRYrwcMJOv7O/bP89bBzjUL/J1vDbcWNZJkG4CNTi9iuDc47WQjP2JsTigIK QjjZdNGjrhdREoF17QvYMKzDwRbjEFYICYsKv7QhYO73M8vdL5hh8Vr/sAPPM8aDwhh24bSz FnUcJbrL0wZEATA7gea4RYB1bMQAWVt0YAdC/DgX2HQ20wnvONyeTtdq58/EEjwV3PMGwtTr ls8tsYVC/t43Bnz9dPzoz1FiPdNum+FXCRSBMB47/VotEBaFARfEc+xhxIvEYAyL4Yuw3UAE WVAydQtkETJGyvlO07jMaYoncQHPLE/I9RmZkYUJONCzggszWKMKCoR19TFlX3exEEDwdeuN BX7/imECy5woEDNRizjg0QWKQQPCMRiKZmIDweAQdN/rsdOWODSKXMKQKwsxjUf/DLjxx7QF BIM9xKFAwBB+DmoEh1DHMA2rY0GLDbhMUxmKBEGIewTWIpquMVcwKXpWmKPZwMEdFPfGNI3o vXVnBysFdW/rIdWZodN0JXKFKfMfnKct6B1RIYPji/MNIM8dBS9LdfPCahBbXsyJ8hlnwTpI mI0Ahquy7vE6bHcYLhb6Kk+4NhfcY0evGo4GohZkA/mi3jlNLDlKHh8aPgwWdcY5BusYgeJO cPMJDs4AwgQz0tpTzipVLAoELYkHXwt1+LCLdYWjUhrPWBhM2peAdTyLAjrYSy5YCsomLDph CCYlCoc3HTcxOjEXGXMUEZw9RxA1ToXhGnXSmU9wuJAbwArR4EDD4uvCATx3LgJCRC7pQTBY 4BMC6KhZZljOM1uP0jrKPMnBnNDrToyodAQwglngUGr/aLhXdRQWrEoEEWShoEdQZIlaJQcJ g+xYYKCJZeiQzJ5wn9KK1BCJFcy5kMgZEtj1Dci4DcHhFggDygo6xHC6o8C4BzP2p/UJOXJZ YAcIahynZgl1WYladRE3xxi6ceCj2J6LjkA2laOoi5hiNEjjBDOPxTCxgSvQjUWkrFFdFCrR FjeRgZr2RdABGUdDTDZHBgNqClgYAJzLD40QcWzRHWTeZ6IIQjDesZfsHCAJFIlNmBphHDGz sy/Bx3WY6J86M2K0sOtyEjFxcTt/Pg4WO7ho05xPObCf7i8k/Fm+JTjIcMML/zUQmyMpvEmD WHwn4C93Ii6ML9dc+RZuOXEvdBATjj0Lid6ayJtzBTs1CKOESXcL0DBAurQaQRycfN82AV6J BA+D5vCZfMNloJ3FFQDZ6DSXQ1F3jY1IiaP5OJ13DI9oLBfYaetMUpqThToOMcHAa7bR9kRW EAGAXsBAgGX+AAGITfyIRf1qsQAJYw39jUUwe1iNLE0KBasPmlFpWpZzhEVvrLC5uAIM2Lhr CiMwRQy8HueXBDqmEz1k15RWsini1z2PQ7wWw6PjBLGh1DrcA32B/9BoEJC4XAiQm8YFMZlo BKMOAKmG2Hs83D5ZeQwxA3O6ED4By1cPAl85PfxxjnURNGzjZvwN3o4gcVxxDItYGVyCSok9 +OEiiB30aCg8L6HQgxMiHhfMCQBWjXH8O/ByRhPqfJclg+5neSJAc+1eaFoYlDoUnNEtaCAQ HRzAhdtbdZrAFgiJhtf+iV/3waqLcw1XWjA/6+2bpShTbOwyYPRoyCBwAYtYWQhIxwoVgIP7 BXUMgy5gCOqi4o4y8cUQAYcZ9gA4rgBymma6jI0tDIkLhItIBLg5hci2HSlIooW1FUzABQPR VjvKAX0VjTRJK9FhBLXYXIiDWCYCxgwMSnX3WM01XFQjPVmOM2DKDMcFtAyhwVjrcD2QbxI6 gQ5dPZHzhKBKPZPvOoUONz2N84KiJGf+EnmG0BE9dJJ8Cs2GFv+IympM9YwC7QowMOsItPpd URE5yaNp4xdxMQk0J3r4k0szKGINUOEuORXQcdlWuGgFdLTt8+vQoMAMOwTGcwQ5EDDRjQws SV4DWo0VFjvBEpaJbl/YwchxngDYSr6OF41yKzsKPCLKZ2K+RsgHbBkRjCaQ0M1GuOjmBUbr 44A+iyENBwIKPCB2GWjBDCB3+lGiwgThD+mLxjDbUzMW2zkdWpmfHFu5WhrDFjP/JxA6w8CB PD10ATRHVmznjcywKgHrMHi9BGEAbJsvaZmENzvzxgnc06UxHAnRUDEHPWhBOAwfdDlVGwEB i+hZRYA/YUkiVW00EcueBi5wV/9UNtoAcG5ZA/2zNzDeXf+2hM/YC4kdC0CJHl9emIfEuqm0 KGZbOstRvVwnvgSAKGi5PFZXRomhpymiHuwIi/44GIxFYfh0w2giU1pTnxk04RlxiZxH2FqI 1JpnNdY8oQj51C/nJySFhlBWqDX8q0QWSFo91MKco9DoBhshcUwYYhwUGG+DRSGKsBCMm5lU 2rV2IAZ1bHdjN061MAuAOJibRIGCQ0CA+mO+KRiiJZi+0gv2goGcRw0EdIw9AeCjBooQiBYW RkALztXF686zDAQGVC1GQDgc61tDES0FHrgEQLBE2vZ9gzgZGBeIHkZlDyB0CTIJcjnMzAjG mEjOu0rEZv9MkywYAE6Aw/rgAJxEiaxhQOcXZ8i+vICLVRT/AiXHRXY3BndwIlx1BQRAQ+v3 oJIs9sPG/kDro20ADYB4ASKNs+OEHYvCM+mJNwjQDMl8gBgYD5TCibAF0esai9NLYdQOQ2iI xhYGXEaxUwcSiuL+SoPJP4tVCopHP4p0Opx7dGEubbzW4k8GHy8bEw9AeQN3FQEZQMSQNc3U MOcPDkWbwscDgydyjhQspeb7yaCESaEIOfxToY4w5NUdwcnAi6h1BBvVDiYLM3QWuiF07Tbr KFg96FZWJvsXPerzGx2s4143cha1RuA9gTlDDHk/xyfChGY5Hmdz6wtAQAgFGHX54AbyK8aM L1zsTtFs+I5ZQAIzXYwDiWNjNEauAug763QyNzIphXd0I4UcVVByuyTqJQ7rLnUODEcQJ9iZ ZYnYacVG8KCew+tT1csoTKU5hdyxI3Q8YAiLx2HwQDhie/vQBPYrLMdAauJm/AHb1c5JLA0N 9usLVRoQZXaUB3Ie9HBoxtgFXVunGxjsRDmXaDQR3zRVm0Eynxs2FRzAnbAYwJ7jIMWNhqUp YbRzGrFtBM62AsZGBQqh0yNh9QgFaBvrYOLqZngmZscJN0J1PcUscGJE51O5hIswjWLcuKNf uEqNEBwufAz7LTk1YwJ9Ur/E7kyP5mgAOF6DfwWJB42Itn5gTxiAYLl+CMdACosPwXYIgcFs fOTd1fBJfLsW6waLCdb7cNF+RiCLA3ASNopNDQD2wQGcfgQXCHULpSjYtrKw0MeLAc/B+AWD 4R+lnX/PIyEByIsLiQhyL4gY60dQRcBJO/58utlQ8Ow82Fb/8gzYdU1lO4YABIED8wX2WOuA iMNI99gbWMCN9blY3OktLQV0F1esZgxrJaNEPtDQBoBGTmos67sj+AMcuQpAz0kFJYAwYgN8 LZv/uLg24PWlqYi9RKzpJWoAyrVoO3VidsDlY9CyVaOd5lk3jvluJkpTD/fj1HCV0HLEzcMO Q9Y3KVXB12jMSUBL9MFQ710cOYty5U0zB0EEBggAuDTBYQ/VksHwEIkCuIcWLsM+9RKB2Gr+ aNRyQGTNZXaPvJbyGSCYSYs0cAw5zi5MfhMkdCggAXaLDLOJhlkWiUgXCHyzBEzIgtMniy2z fUQ6Yr9UwAjrw2SP05ZJ3qGM8+ZkGWPQD4F5WgRoSWPNUTClUgwmOVGwLQWbuIpRMbtkloRw fgjUwu6JS8YCQ2DPawxZSFvAF8zMVkMDMjBYQzAwJueLCPpA/ItdDK64LfdA5LbYYyyZiTSV Q4kOuQjOPiE4c3taCMEgYbNTjrGPAHRFVlWNaxCzqIULXV7JQQuCwzN4POolHG85WK+zBLkd VmwM8eII6zZuON6P+TFJj2JVDOU7CN4wGgKLNI/robjQ2+sctskt6xVcC2r/P1ldbRZqlChV 4JWLKYtBLBxQAy0YUCRv4TCh6AjsoMuY8YIqgz20DF7MnBUhaPwbQQY7uKEMc8pZXu8t/xVM NF0TgeykhEiHnBO4eD6ZO4iPC+JBQT0O9QB88VaL8cHmAy07lhosJqXdBGxNj7voeXAN+48Q 1xaB+nWcC3jxjYVkXOhGdLgtS08wLxMXjZh4X4hGe3wSC1dQjb0HTGhgQFhZZTwvdikZKDxe XvgNK4NFAGoDA/holGJ42nyj5aFhKmD/wmh41lX4EFek+++zHXSouxf/tnzTfBb4EWgXECAB EMVoTPEnStpgWSxf6zAmjc7QMNo5RjZsjFm4CGr0j9s12Oqb8QihFJs01VEP1k1tRrGIBNN0 cXtoQAW23hstm6+enCt1AXsLJZQIrFgtJZgGODGjVpBqx4idHhDiQKHSGGE3gKFpMMYHiHP3 FFyDKyFQDBko4iRyB2C3FOvosmgXz5gMBd0LAMT9QWU0YpBxwAxa/IPCCPxXwe7Azc6Levwk ackcl0vCwMeNjAFEuJmJXUT0MyRipBO7EoAI+HV/wfmwuT9JWF8LDAo7z3YDcR5ME5n3zQOI ekgw+oP5CiBzHL+4YtPvGY1MAYAw1yF8sEQL/gl1K3WAITnrJIPBX+Aeey3wIbywxLsSziQG m9M9UTHTfGJVidkKBOAIA134sQ0IcIyL+8EV/wRPizM/eziGX5bLZo55l+yyhQuJkSvcwhHs oYkCVfhJWjvK4aZ2BYly88rOQRsu+0DoPjsh+naLTvq/CHRrBh9GO3G+UW+9O7o76g7SIVTj Ebce7r2nIReUvbNRnVI4v0mxvkp4CwTjCJwR5pGDyIR1CTnMMy0huB3wmLL5tSk6C3kmiXcv DheJQXEFO2AOdWOKFkwHBO8AIIhND/7BiLgLcyUWgH0PRhYOu4iVhZHT68V2CRmtDQxa4LEJ GOtbKSRM/i1P4Bm+JTNZihNPflCNhLa3Ewk4i1SARfCJGolcFBP8/2Ov+s2hpHY5id/QDYy4 DYs9bszLCsHhDwPOqVIYgADOgA4rAF4L/9cfzjLXHMIJUAjbDvA5QBCDLKSIbOpXeA/+SF5D CgJIEIB5Q3ATg2AEW/4RGYN4WIhsR1MQMHAZgtsSjQkQPamm9MaLFdryGQ5lkovLyChiK8hg khHsURSNSBQaDBJLa7buLf8NLwc7BZSmNUYlLBSWeJyJDY1MGus5PaNoGolaNaxK3PrvZmwv 8GhXjTxdgiy0GzZIF3Yj8BenajdJNAB9DoPO/9PuTIPtkOMO6xB1JhgZMxT20+gNWAv4oWlB i9g7KMD7cxmLS5jhO1gjKyMK/gvPdcFWwxQ7s5rFGHLnwAd1eYvaO1rYJj4VzwUW6+YZF3VZ JAhzEYNmLBmF7xMpFuvtN44mog3bG7Mv7skOxQhDw4d7hduIdBRoRkQsdFlbUBAxVENhqDj/ CPBlQ74tiR2luBSLsRb6ZsfOSi0Ji4yQprbCgJBE1IgvN4sSFnAROVXI3VodBkhEC9aGKAZ1 F4uRnYaQz8YcVYD/i/4jOQsI13Tpi+GXyjP/nlxGWKNNYnZM5FfOMyrxZmogcGRfhckAfAXR 4Ufr94u4IFT5sEMKK85/Z/F7DMH+BAYiET9+w/heO/dhmw0B7eIkYTggfSuNEeyYdTiMnFjT 8+wFI1yIRInDA/4PdXbqmJ7sCCEL6zH0F+0ryZW3oTILIRkpPTZnmCzrhSciewpxwHoEw/gA NJXcr3pnCJBJbYPSqRkUxUIMnKUi2sLzZI4GPP4LI30pxDaZCwsAiBG5YraKzHfYjAlaOwre jywJfK4t6y8o4Q2NThq2ggl7BNGxvG2t5xa+Ye4JN51qQ6ACC4kKiTED/CjrrpEG8APRAwo6 EhMy/J+Liw4hC415DwE+dRo7HbTyLnUSS0Y7pNMGK2vvESGJhNVCBG0IvAI9DYiB1f2CXXUw jWJNUDlyUBiQnPJXNZcOvHAJO8d0lYjlnG3A+z2gCmjEQYe/IwhFvjAIjTSBeevAM4lGEHQM KmoEaDk8aA2yNYsLwE1uGSkMMIV2ELVktvyTrRHrjHxOziTFGIl+xUoFt2JBNZDnX/4hUbDf V4tx2MhBGQgz25PFT4/gQzbDN2I2dmZa+zYwgtIM2ixACAJTBNoTSh6W+4UZweeE33kMGj8z aORPi9Q7EHbR4CdFao2XMABwwGD6dzyNWEd3SIzyGIOI7EwFF42I/AYHx0D88K5C4w7vVnYC SATHgOjuEBSLBVZNiCzwYZZ2xxdgBk8MBfg4/AFfuSaJYKyNSgyxCAjOjwtknkRCCbyeoOOK RkM2isgLGYTAwHqITkN1AxUJeASxZovLWWhdfplqyNjUtJHOFHj8GPihUxiJJLDlw3VkPnZ4 DLAXVmiwM1GLSrDoYnQEjP1aHRsoVjTqi1yWtBnT7B7OC2oCWKNDSDqfgYsYHEmFBaE00hCa MWQ0esh3yjNrL41GpjQjeJQ5XVgYGaFdRCpneI0XUyycQVEgoBDgCEBRUHFbFbgI0ZbgYVZ0 Y4GZNJRysg/DngMkR4QXK+vAEIv0jJHJkDtP0wnrC3RIjCaTyJuDvBr/YsIpwkngVvNfnRxV b1J4ERRQiNu6pe0c5Y0xZczWeyY6DVtITAXBqNlGdMkqD7ZiF4qmAhGEiHFwdRwmsmmJnw4Y u0VrwuQUI2cHSknKJQE0S60/khgNHkNIk05tLTVQ+Rl1yTNq1/SCaYsqVglB0rgYBlUFOTB0 coDoMEI9CKSDYqo0BuOlrNZAzSSiKECrHgu/gIKjhxHoncZQhfOrqmO4hMMPhu9oFX1B7o5m u4BN74oRhFjSDK73wQxB/7AwO8IWD4eTJZ3HqMVa7rlSzUiJk1LUcRgwqheNniiRE4A7ewDL dCyKUQGrsG6FEbb6jZR3YEL8ipJcECAIWpBGLEATAnb1QUGAOWIY1Lr5sXgIYJ38BHJuwa8Z xwVseElQWqOsWgsF3Y22HMU7v2DBD6WlWaNou6Uu61VAMHn/xkxIRs/foSYTMD3hl3LxVm05 8yy4VOtZBvrTC53CTZarAALrDTkdHOQKdDT2ZUnGLUk5cjADOrva2qfgRud0IblV/rMgj0sc wv8lpGy4bj5AAIAAKECBAGdFIwGQy3Y5/1Bk/zUAAAAAZIklAAAAADPAiQiQkJCQNQV2EjoE CB4RBExXbKrL9GzlqvW0shej08W33MOUX2yAFHIFKcl4/7Tn3gp7Fos9vodBiIQFQOvDggDG cvSKRfJQxjTRUCDA9TdTV41sVWAktgpmJmG1dx0sGlu8KgtBuCAAoWlby4TeKJjuqgVCQopC /yxiEdBfWxxy7Hn6NWmN8XpQINkoVpNn7iPO/Z0dFlYeslbzNMcjTqBn/FxAaO47J/bEXlxy go3QcmaLAhH2wgF0Fnj6EBaKlAVkg4iQgMXrHIgaAs+9Go4gjvxQxfKgpBzJgZc8AAm/60n1 FYIlQXIZxgRazqpLoMiAwcZ9LYhJlh8YC2FyEwQFencOqU7AHekg6+C1TDxKvjReyWqGDBJq /dAI+lmY/MiR5JKNSo4gm8JCaPS6PseenKrQdWeLhq14C2jok4aK/9YzzKIpdMX62OQQMwqh B6MkNNQX1qMoBi2hCzN5hBb/0LqoYbyhKHgQBVpTEUeLLRgDTO6MTZFsBeto+Gr/qFzvz1uP XM5cj1s8XFzuo1yuz1ysXPhc81zPXDxcXPNcz1w6XOs7XDxcXPNcz1yuzl7jXu4+XTpePF1d 8136O16sXvqzXuNez148Xl7zXs9ePF5e66xe7F7zXs9eOl6/UzBjAHm/Phxowtw9TDhydUYx V1c685otRmbQw94VDEG3icAWHSOH6yISU9k1V8eY4yIBkYg8TJ43Ajl9FH4QWytg4F7EWVmJ CUUUoUx4UR2xFhxOsKZL50jKYUpQMNnT0H0g6ywgc1v/LnHWJC1KxyDEi5gU5Cw734WU6kc4 ugQbl06yxMRB3Lg26xOXR9BZ5NkRi2c4ZwTcdGaxqdx5Yc4hV7f0lk14fBr5pWgKi4xxAHXY O/d0MvZFYw0UFkA+LBx4ebI7YdV/Hnna1TIuIS6FjyKniT/I1FnAmm9xszb8WNzT4LazdRKz kTuyeH3fdC60VmRa5GexdJx3j7MLdQQDC+sGjM4oEGgg05Ck1U6Z5b8cWHGi5BbG23FDjKHA 6oXSVo1KVP/C4zgAYOxAi/FkScUB88EMXnUFK3cegxLCmAHEc3DuAK8AljAHdyxhDgDuulEJ mRnEbUMHGgBqcDWlY+kAo5VknjKI2w4ApLjceR7p1eAAiNnSlytMtgkAvXyxfgctuOcAkR2/ kGQQtx0A8iCwakhxufMA3kG+hH3U2hoA6+TdbVG11PRGx5oAg1aYbBPAqABrZHr5Yv3syQBl ik9cARTZbAAGY2M9D/r1DWMIUQAgbjteEGkATORBYNVycWcAotHkAzxH1AQAS/2FDdJrtQoA pfqotTVsmLIAQtbJu9tA+bwArONs2DJ1XN8ARc8N1txZPdEAq6ww2SY6AN4AUYBR18gWYdAA v7X0tCEjxLMAVpmVus8Ppb0AuJ64AigIiAUAX7LZDMYk6QsAsYd8by8RTGgAWKsdYcE9LWYA tpBB3HYGcdsAAbwg0pgqENUA74mFsXEftbYABqXkv58z1LgA6KLJB3g0+QAAD46oCZYYmA4A 4bsNan8tPW0ACJdsZJEBXGMA5vRRa2tiYWwAHNgwZYVOAGIA8u2VBmx7pQEAG8H0CIJXxA8A 9cbZsGVQ6bcAEuq4vot8iLkA/N8d3WJJLdoAFfN804xlTNQC+1hhsk3OYCw6dAAAvKPiMLvU QaUF30rXldiAYcTRpPv0ANbTaulpQ/zZAG40RohnrdC4AGDacy0EROUdAAMzX0wKqsl8AA3d PHEFUKpBAAInEBALvoYgAAzJJbVoV7OFAG8gCdRmuZ/kAGHODvneXpjJANkpIpjQsLSoANfH Fz2zWYENALQuO1y9t61sALrAIIO47bazAL+aDOK2A5rSALF0OUfV6q93ANKdFSbbBIMWANxz Egtj44Q7AGSUPmptDahaAGp6C88O5J3/AAmTJ64ACrGeAAd9RJMP8NKjAAiHaPIBHv7CAAZp XVdi98tnAGWAcTZsGecGAGtudhvU/uArANOJWnraEMxKAN1nb9+5+fnvAL6OQ763F9WOALBg 6KPW1n6TANGhxMLYOFLyAN9P8We70WdXALym3Qa1P0s2ALJI2isN2EwbAAqv9koDNmB6AARB w+9g31XfAGeo745uMXm+AGlGjLNhyxqDAGa8oNJvJTbiAGhSlXcMzANHAAu7uRYCIi8mAAVV vju6xSgLAL2yklq0KwRqALNcp//XwjHPANC1i57ZLB2uAN5bsMJkmybyAGPsnKNqdQqTAG0C qQYJnD82AA7rhWcHchNXAAAFgkq/lRR6ALjiriuxezgbALYMm47Skg2+ANXlt+/cfCHfANsL 1NLThkLiANTx+LPdaG6DANofzRa+gVsmALn24Xewb3dHDbcY5lqAfXBqD//KADsGZlwLARH/ AJ5lj2muYvjTG/9rYcQAbBZ44gqgAO7SDddUgwROAMKzAzlhJmenAPcWYNBNR2lJANt3bj5K atGuANxa1tlmC99ArIsA2DdTrrypxZ4Au95/z7JH6f8AtTAc8r29isIAusowk7NTpqMAtCQF NtC6kwYA180pV95Uv2cA2SMuemazuEoAYcQCG2hdlCsAbyo3vgu0oY4ADMMb3wVaje8AAi0u Xy1cLwB2QA4uW10t1UyX8QA2P2IXSuADcnVudABpbWUgZXJyb1VygJRUTE9TU7wNLg0KLwtT SU5HDngARBZPTUESdxEBUjYwMjhhCC0gYEdhYmzjdGCeaW5ps1JhNml6YA1oZWFecDd0J3Q3 Fm5vdD1wBHVnhowFc3BhY4sjZneTbE8WaTjyYcIGb27cN302YXN0ZPedNQVwdXKAK3ZpcnR1 syGcM6VaYyMWIGMMLWwouicvNF9ZX2EqZXhiXC/OWAac3Oni1l8vMTn3wW9wZXdYMQtzbw+L ZGVzFmMr8zjnRjkkwoFlZG0Zeld0I383hW11bIWsdGiEv2Fk4iFja9UvLxdz8jRkxbdh3C4C 56IhCXJtywBwQAJncmFtziBKJm02Xy+FMDnrT3IQ7kEqLG0HWXQj2Ss49YJhcmd10ShzNV8s YOgrZrPBxW5uZ4uCbwUWdDreEbEmZHh/TZkty2A5FmYVCVZpc6CqQysrNyBSnMJMaWLCtHJ5 0ScKtHP8FkWaDiwhEV5Q1DA6OZAuYQAAPGrlc+DcJSxZa2y7bRqq0/9DbVaHcVYBR2V0TGGx RkG5FnZZzGDCdXAAtBP4D1exqWRnOpsDZXNzYTD3Qm8EeEEAdXPAOTMyLmTZPrxHOLVfuXNf oQtpYMNtYIXMerhrYlh7CShwcbR5txMObH0cEHA72HqPlhw0cXfgnqJ4PDx77jzCmPGkedx4 /gBwlors3nB90H3h8H3wfHvhinvDmHuHpHsOtnscwns4znvccHvqe+H6e8MGfIcQfA4afBwk fDgufDpwfEp84Vx8w2x8h4B8DpR8HJx8OLZ8xnB80Hzh2nzD6nyH+nwOCn0cGn04bns8cH1S feFefcM6gIcqgA4YgBwMgDgCgPZwf+R/4dJ/w7x/h65/Dp5/HJJ/OFJ+hHB/dn/haH/DWn+H Sn8OOH8cHn84Bn/wcX7WcwO8z6A8jGDzbMckfRZKa45+HCB+ODJ+RHB+eH6eFzxWRJ9nJ3or 02qLgBIDnpd5Ag3nAZ4QeRME53OeD3kJN+cLnjR5FxXnFJ4ReW8D5wy6XC+uY7gEQ2xo2mxM ZZhWQgt1ZmZBFEN3c2bA7yMMBlVTRVLUbZ2XszAYjkaM2ltlDYZBbHcZDZxDmJlILGFuKugc Uo79LUZpCrPBJs10CkZQdpxk6BFXs12fCR6bbPsWcggtbneXRymKU+65UZHfQiYXQRuFU3mC K2VtVDN5qDdjO3B5C19sY31PCnMJnBedW2sJeT5keR2aGHQJR0ZOL0MpugszTukWdF+nD04D FnJzELdxQkRyOIRUeVtwEHnHVJvWLFAVXG/BebyVVkPfcRRufRrb74c/ZXDOq4pa4cJJbmaa /kbtn1mscK4B/MoAjuYrRXhyO6smdxud/W5V5H0nG3ItAB9iTXUdGNSt5k5hokNvnZt9E9Mh 5Bl4R3NZRN+d2Ms/Nc8XCk1vZMviYmZOZ6n1zkBZVGoCcZRpa9c2SwgNTkVMuAtJmsxx2XQ0 AeLVbhswF1N0knDNSU6wAUVUtigNV1MyX70/yytyC3R3gAVrUGF0HuC6aXBobKy4LXBpIUmJ N2ewoEtledtFJ2d0JlYoC3VlReXPESdPzHsegA5BRFZBUF5JXd/PJ4Wd40+UQ3uTcIJJ90ev C21tIpNMFCZZolbEynP7m6bzcs9ju3LMDkh0JdTh6Qs1+xBU+b5lbipNC+4U4FVuaLaMWWRW xBFw0v/tW/cFS0RFN9c5p7hzZ3Pbi3cZZ1esyKyw2q8MVG9NcZtCebYr93kuXPoXiFf6k/Il ay9bKSNkwFtqi038P/sRRGXFcm959A3yfza5xtvXGsJSdGzD9HdpnRnLQFO1N53BDk7Bt8w6 1paxp6hNqXb8EX5XJkNQ0J8LFkEMfhUWT0VNC7WghEFkZE9ynZhMyOt5xthVTENZTYzzV6oP IVfox8NFWqpmwjSWQNkDJOcUngQ49JXk89TdDx7EebSk45SVj4Q8dGTzVM9EPDQk8xTPBBf0 lAOP5Dy4qPOUz4Q8LEoAWldLRkxFUEEAR1VNSFNDQkQAWE5PSVZUWVIEUWtldXHA+XhmYmxM Z1YVbXd0jNB6xBxkwLxyajAxADIzNDU2Nzg5PCsvAFwcRxC5AwjnAI74kzz07PPkz9w81Mzz xM+8PLSs86TPnDyUjPOEz3w8dGzzZM9cPFRM80TPPDw0LPMkzxw8FAzzBMf4kh7seeTY59Se wHmsmOeInnh5bFjnQJ40eSgY5wyeADj0keTz0MFBbXZ3mGVrmP13Bm16Lmpi2O9PblZ52wti aG4PUEJrzIUvLTINFksqLWsXRVqOI2ijQWfxRzkas/nxEFN3YlJ1+EFLbrMYjip63SdiIGLe eVshF8tpfe4T9wo7H8txgb4vi2WFvg+BcXd1YxmqzwgTom3bjZ8RR2+VnhQTUGIAB9OLD25R F3crL0tJvt/S4sd0dNgTLnktYWgHh296ZmFsenTYYXp2eGZ3YHYH5x4HwW11ZthhYXx2/Bdx rLPsF2mvQQUua3HiB3nOngfToBdhT4dxemdxHWEFdXhiqF9h6GOZU9tfn6hfIzk+Lxd0ZpeJ aZ1Zl5dut9cqfL9fa3d+v/dOIEUu51Y/l2irHXF5n2GRdZ1CqwtHa8wBbnAybXF6C3BgeW72 3oMEKit+IydqiAQsLjo7YYwtXx+OgD8hJSYoRimUIySVWDw+RnyYqPYF5PzfAG+WAEomYvcs esCtl7oPcXhxtFCwAnZosH1xY7YT8wd1ZaziczrcAA1PZm5ymRGchapsIGWY2m3ZiTMrvR4s f+BuLjQ0Ai4xNjAuONA7MTlYNQw4vgPnCw8PNTE4OTM1LjM5WTJ3CBc4Eze5MzlsLzO2H1wy RDJdMC/OuwcsNRPgVTE3MbUfFjQvLDRfOzQyeyfeIlAvNAAPxzP5Mv58Mel/4wM1OIswv8U3 iwkyDZY2fX8PFzIvp+RPEHMfnB1OXDkiM1o375y34gIy7maRfW+XMH/hMjnTpV+nGxM6Ii02 D+5jFzcwH+I37NE7+gyqY3briFVEZpR7kYoA98e4G2FYYiVlWGYzaRNqa2zPBm9wcbKiYJZ3 eHnc9UEAQkNERUZHSEkLSktMTTIBUFFSU1QlgzxYWVqTPAhzZ/IfHntwB2J47G+PJ5Z3WW0n oZ8WBw90YoNzaHSiXNADKi5aKgscYzo0DQrbJ4EFWC1NU4wrEGlsLXwHOgggSGln00unGxRy wrYJYphdZMdxAj0iJXMixR8txAA9Xx11TP8bdF8lWRd1BDo0DjhYLp1DJYpOdGOuLRzuOouD ZXDMLi/AlnhlZDu0heADTUlNJUUt57Vpiy4wE5REzo8Lc2igH1N1Ymtqkj4OeA9Ub74KplsW b20LpwUWLAkudQztBWG6dTprBHsUpwYDT7d5LCtyA0QMozNOb3YWT1lTQRNwfxN1YhZKn3sD ZaKLEXkPC3ByB7gDRoy24xNhiFMzf5FvhY5UaItEV7s4B3VYZR9vuxfaL2KSLc5jA1pXnQ06 +6BhcHBsbCSDNkIvbwxg5RcxgWWyPeYECdJf21a8NHKwc3NmmBQtBUVuY29kM8iGQWJhwoM2 NNwiNkRpdyZvNHRR9l5g4mFjaNcadFBLZu07VNdnnwc7m6J0csUvxZ5hnWY8EmPOvGksdDuD acItMTsH/pozN5EXdPzWH3GWIHICYXjtLZrucwpN9KHJKiCi7SCNQZcuMtaLC0FUQQlAUkNQ VAUgVE86PIuiPg9IGB1MBSBGUk9NrREsrwtFTE8gwk8MFkVIC+BRVUleVOctLg+FJWkuldXB JXBrX3qyczBJbG+Z34a64nMzI4vzIABV0+emp+c3ZFTrj8JOo7vjNrbQ9S0ytaF/Pp87NUdB JmE/u+M0skJj32yu+DOPKw5tcFlCs++rpP3xozLbM79iymM1JX++nzcxg45lWOZz66oAAGxr YWtibSxoZQBTescAQHJrZnd3EC51d2g7KAtTKShrAhx5cU5lwnQpanMFX2FsZ7LWALRgK05D ewBUSlhGXEgGYnVwd3oYOVxYVFNxAndvelxXYxnrBoUGVm5wehidXCBYY+LkR0Ww2i8gBkhU VFAvs4yIQUhkujTSrQNOA6D0QEDA0+0THroDYM5hAawo6zogvEg/ABCzhK8+EM6B8wGvzhDz grwC6/MQ8yADFVVcwOXKLp0CB5wFPcAL0QAdcwsE85a8jfMI8468j+87kM6R85K8k+9EclkH 5wMKnoyJ3aMMGxChQQWTGTWkRwKaJBnw0D/4d7EHCefMngp5qBDnfJ4ReUwSGnt5BxPj/HaP GDzEGfOczxo8ZBvzLM8cPAR48fR1x3me5Hl61OT8u4tyP//TR8UP+APgnwECBHQIpOCBYIJ5 gl8hth2m34UAoaXgB4Gf4HT8HUB+gJeoLwbBo9qj9Y8Pgf6HQP7Fta8vz0HPtgXPouSigOfl ouiiW7U1bl+wfqH+6FFwBVHaOF7aXw7aatoyuNMO2N7g+RYxfjltQN3oAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgADAAAA IAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAACAAEAAABAAACAAgAAAGgAAIAAAAAAAAAAAAAA AAAAAAEABwQAAFgAAADYsBwAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAcEAACAAAAA ALIcAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADQAACAqAAAgAAAAAAAAAAAAAAAAAAA AQAHBAAAwAAAAOi0HAAiAAAAAAAAAAAAAAABADAAAAAAACgAAAAQAAAAIAAAAAEABAAAAAAA wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAgICAAMDA wAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAACIiIgAAAAACId3d3iAAAB4//+Ih3AA AHj3j///eAAAeP////94AAB493d4/3gAAHj/////eAAAePd3eP94AAB4/////3gAAHj3d4// eAAAeP////94AAB4/////3gAAHh/f39/eAAAh3OHh4eAAAAHszt7d4AAAAAAAACAAADwPwAA 4AcAAMAHAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAcAAOAH AAD/3wAAKAAAACAAAABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA AIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAH iIAAgAAAAAAAAAAAAAAAB//3eIiIiAAAAAAAAAAAAHf//////3d4iIAAAAAAAAB3+IiI//// //+HAAAAAAAAf///////////hwAAAAAAAH/4iIj//////4cAAAAAAAB///////////+HAAAA AAAAf///////////hwAAAAAAAH///////////4cAAAAAAAB/93////////+HAAAAAAAAf/eI iIiId///hwAAAAAAAH//////93eP/4cAAAAAAAB/+IiIiHf///+HAAAAAAAAf/////d3iIf/ hwAAAAAAAH/4iIh3f////4cAAAAAAAB/////d3iIj/+HAAAAAAAAf///////////hwAAAAAA AH///////////4cAAAAAAAB/93f///////+HAAAAAAAAf/d4iH//////hwAAAAAAAH/3//// /////4cAAAAAAAB/+IiI//////+HAAAAAAAAf///////////hwAAAAAAAH+H93/3/////4cA AAAAAAB3g3g3+I+D+I+HAAAAAAAAeIOIiIg3c3eIgAAAAAAAAAO7i7iIOHOIiAAAAAAAAAAA cAdwewc3ezAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////3////4d///+AA///AAAf/wA AD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA/ /AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAB//gAA//9kgf//////AAABAAIA EBAQAAEABAAoAQAAAQAgIBAAAQAEAOgCAAACAFO1HABjtRwAdbUcAIW1HAAAAAAACrUcAAAA AAD/////RrUcAAq1HAAAAAAAAAAAAAAAAAAAAAAAAAAAAGtlcm5lbDMyLmRsbAAAAExvYWRM aWJyYXJ5QQAAAABHZXRQcm9jQWRkcmVzcwAAAABWaXJ0dWFsQWxsb2MAAAAAVmlydHVhbEZy ZWUAAGr9vxQdqKGNXg+3txlzsUktpCb2AHQig+gEdBewBA10CAxIdAMwaLgEoZwI4UgBYByL dCR6Onw8KDxcHyz8QBszyYXbdAEQsoAD36Sx0OhmwUVz9jv70HxTB1VXM9tDMO2Lw434HeHZ 6+Df6FBJHfH+XHA9PwPHv++oOg8D4l9dWyvBuAmLxTHoNCHrHPDgCD6sQDMoGYuxPQHrDw6D 2f8FgQdACFaL9yvwDvOkXkEg65UC0nUHBYoWRhJ1wx+Cxuju/wJ4E+7nwQ9y8sMrU5+JBwgc YcIQBUgytkCjBF8+hTwBCji1HDMOCQGHCG4Ihhi4Dxh5pCBoBAg0m5RJgpADUXEgKRRQAh1w gPlgxQhYEDcQigRmdg+FEIjzUCg8EQYBiABTUVJXVlXooB5dgRjtMBFAjbVgJQ2LRvyDKMAE 2/BWYQgWHAPC47iJjY9QEhggpA1DkyMkEJfIKMSbI974c0SFBvZ0DrkrtT8D8h17QFL6HSf5 uI2wnz9R6CarofFOLLa+hMQUakBomI9RHAH/EomFi4JDVujXAwwM30IEEMsCimIzgDSFyQ+E iaNV2QhRiCo+BQCFwHR7i5UxbxfvjXOxDUR1CIjQZxMD6y33wQFXgHQeUoHhJIl/DFGNhSMx UMQOPBhC/5V9hSYdArwIA8hBw1KIP9ESVHlqyh67FloippV5hhgBEEXDAryADCu1SYsGndl+ msf7MBUMDl1eXw5aWVvDFAGsos13uwkDQ4EiCW1FeQAcRW50fHINIFBvaRDZTts9CEY9dThk D1RoZcdwcvdjb3+7bxSVJCFwjyVz7GNGbH9k+ZtbYjjWSnlh3073OO77a8t5x/dtxmMuzCBr C2J+ctl1aC5TUm/zZBsuYWwgvW5Ej1svbi5dCoy6mpgJNOIAdXNlcjMyLmRxbOBN9fPpYWf8 Qm84eEE9d9HFE7VmNxRrQI5qbCNgRXhpdFJQ3m5UCq9KWFWLDuyDxPzJU4Wn6AEPW4Hr1pI9 ixzjwA4Dy1H/k5mWJAKFOolFgPtWBANI03+P+0wCJxpvUg5pwwPGdfxxTIwAFKtag8IE6+Dq xhgMiwYgdbt0M/oFNbj/AwOpW13JQjZv3lh9xkcE/l/sOx/DdERJdzihzz0D8+TTKwfYiV38 rY7fHdpzpSrIyIPpTAhzeTHtZij4gWDvD5qbfPsdwegMH4P83BEoi5ccAQdJfIrh68xjWg1g DvkIYnmEqRQSCNw8RKpTQ3aDw0jgt0MMXKnlh3UQexPRu2/1yQD4aOsLflGLMxBVCFO4avX7 AVBbDjvPfU1C0jyA7BKA/CUzdAUKFdaGOcYGucGF6+Q86IeIQel1KTCSAR5XOPgHGOsIfRfp 2OkOV6fOYcAQhsRw8InMJF9iBYOZ67Pu4M2vW3hZMhhRUDvDtwG+Sw6D7AJmdCrocBaAX1mg nBBJxMjpXJI3XZ7VSWCVO2aoTcn4DJEaFwcfD4GJCOv0YZM+DG36TgCIFSZfGZENi3Nnb3AX N2KCSAROF0fMiAFMDhCEEUDppFAT8joDMyy9hWZLfnHBC/kC86UD1oPhpdR42Jz6/ntXBBzQ 6BJpXVfrKAQ0QRaDmPcrdzCq/pDHSlewxylWUl1LCFqnRlGRaIkWt0gGqCsJVv/QWogMZEhv SGd6gijrsUU5ETr1Kg4TtxZxDnRZTvN3KOACjMXucwQt5CECH+Zq9K40MYfUxap1g1C/8bkR huKtWoBI61FLsP9wOUYQ9ATqBix0LB1OzgMsQ3ZOuMbLg34GPf8hkHECUFdRU+gZqacM3SIH mDEZFOvJbl6ckAgssPFT3hwihhcJRQyJg0ujZFwQc0uLGbn/ufKs0rqy3X+PhfYhc1UU9dLp AvXWYW+VDfJEiMqVxzlBETPfFElSSompROJQCvCBSuJF4+sLWMsaA1OQOSrCAj8SWC0JgrhS 5AhHkAcRWokGJQLUCxbCCw6brwXLWrgGXVuDR8gB/5gAYIt0JCSLfCQoi0QkLPwz27KAORh0 QqSzAuhtAAAAc/YzyehkAAAAcxwzwOhbAAAAcyOzAkGwEOhPAAAAEsBz93U/quvU6E0AAAAr y3UQ6EIAAADrKKzR6HRNE8nrHJFIweAIrOgsAAAAPQB9AABzCoD8BXMGg/h/dwJBQZWLxbMB Vov3K/DzpF7rjgLSdQWKFkYS0sMzyUHo7v///xPJ6Of///9y8sMrfCQoiXwkHGHCEAC/tRwA WwkAAEQBAABjuxwAErUcABa1HAAAAEAAuNOrXPCNiIIQABCJQQGLVCQEi1IMxgLpg8IFK8qJ SvwzwMO4eFY0EmSPBQAAAACDxARVU1FXUlaNmEMQABCLUxiL6GpAaAAQAAD/cwRqAItLEAPK iwH/0Iv4UIszi1MYA/KLSwwDyo2FHREAEP9zBI8AagBQV1b/0VgDQwiL+ItTGIvwi0b8g8AE K/CJVgiLSxCJTiSLSxRRiU4o/9eJhSERABCL8FkDSxhoAIAAAGoAV/8Ri8ZeWl9ZW13/4AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA UEsBAhQACgAAAAAA4yIJMY1LT/cAVgAAAFYAAJQAAAAAAAAAAAAgAAAAAAAAAERldGFpbHMu dHh0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC5leGVQSwUGAAAAAAEAAQDCAAAAslYAAAAA ------=_NextPart_000_0013_00001D1F.00007B0E-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 9 10:03:08 2004 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 KAA29996 for ; Mon, 9 Aug 2004 10:03:07 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00E3F937@cherry.ease.lsoft.com>; Mon, 9 Aug 2004 10:03:08 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 29837698 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Aug 2004 10:03:02 -0400 Received: from 205.158.62.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Aug 2004 10:03:02 -0400 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id 2E9E71801E53 for ; Mon, 9 Aug 2004 14:03:01 +0000 (GMT) X-OB-Received: from unknown (205.158.62.178) by wfilter.us4.outblaze.com; 9 Aug 2004 14:03:00 -0000 Received: by ws1-14.us4.outblaze.com (Postfix, from userid 1001) id 08666790034; Mon, 9 Aug 2004 14:03:00 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [203.197.138.194] by ws1-14.us4.outblaze.com with http for arms@yours.com; Mon, 09 Aug 2004 09:02:59 -0500 X-Originating-Ip: 203.197.138.194 X-Originating-Server: ws1-14.us4.outblaze.com Message-ID: <20040809140300.08666790034@ws1-14.us4.outblaze.com> Date: Mon, 9 Aug 2004 09:02:59 -0500 Reply-To: Mailing List Sender: Mailing List From: armstrong mathiayalagan Subject: Detecting inactive neighbors over demand circuit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, This draft recommends (May clause) Router LSA to be flooded for Neighbor probing. With respect to the applicability of this draft to OSPFv3, I feel Link LSA is a good choice for using in neighbor probing than Router LSA. In Demand Circuit, there are more chances for having LSAs of different sequence number at both ends. If neighbor probing uses Router LSA, if the Router LSA is having higher sequence number than the neighbors database, then the neighbor will flood these LSA in all the non demand circuit interface. This can be avoided by using Link LSA. Comments are welcome. Regards, Anu -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 9 14:50:49 2004 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 OAA26620 for ; Mon, 9 Aug 2004 14:50:48 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00E40159@cherry.ease.lsoft.com>; Mon, 9 Aug 2004 14:50:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 29899873 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Aug 2004 14:50:47 -0400 Received: from 207.217.120.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Aug 2004 14:50:47 -0400 Received: from user-2ivfjjk.dialup.mindspring.com ([165.247.206.116] helo=earthlink.net) by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BuFEL-0005zY-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 09 Aug 2004 11:50:45 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4117C962.8CCF84FE@earthlink.net> Date: Mon, 9 Aug 2004 11:58:42 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: RFC 3630: TE Extension : Reserv/Un vs Query To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I was thinking about doing some TE work, but need to clarify a couple of items on this RFC. All of the issues deal with the reservation and canceling of reserved bandwidth and have unstated results wrt this RFC. wrt to 2.5.8 unreserved bandwidth 1) Is there a way to just query the amount of unreserved bandwidth at a priority level without doing the reservation? 2) How do you unreserve the bandwidth that you have reserved? 3) Will/should a reservation of a max value reserve all available bandwidth at a specific priority level? 4) What is the duration of the reserved bandwidth if no followup reservation is done? 5) What happens if a value of a attempted reserved bandwidth is greater than the amount available for reservation? How do you ack a failed attempt? 6) extension of #4. If the link goes down then up are/should previous bandwidth reservations be intact? 7) Can unreserved bandidths be tracked to "guarantee" that a % greater than x can not be reserved from a single reservation location/address? 8) If a full reservation is made at a given priority, can we assume that no lower prioity bandwidth reservations are available? Basicly can/should you reserve bandwidth at random priority levels? Thanks, Mitchell Erblich Sr. Networking / Software Engineer From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 9 16:49:39 2004 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 QAA15675 for ; Mon, 9 Aug 2004 16:49:39 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00E4035E@cherry.ease.lsoft.com>; Mon, 9 Aug 2004 16:49:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 29920808 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Aug 2004 16:49:39 -0400 Received: from 207.217.121.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Aug 2004 16:49:38 -0400 Received: from user-2ivfjjk.dialup.mindspring.com ([165.247.206.116] helo=earthlink.net) by cardinal.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BuH5N-0002JQ-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 09 Aug 2004 13:49:37 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20040809140300.08666790034@ws1-14.us4.outblaze.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4117E53C.2CF4B785@earthlink.net> Date: Mon, 9 Aug 2004 13:57:32 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Detecting inactive neighbors over demand circuit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Anu, Assuming that the Router LSA needs to be flooded in the near future (Not a DNA LSA), what is the harm to having it being flooded earlier? Assuming that a numbers of routers were booted at the same time, to minimize sychronization of flooding updates (assuming this is considered a problem), flooding a LSA earlier makes some sense to spread out the flooding. Assuming that the initial origination of the LSA is a active probe, the flooding to other routers florcefully verifies that all links are still active at this one point in time... Assuming that a non-floodable LSA is originated, the router LSA still needs to be flooded and not all the links are known to be in the same state at the same time.. Lastly, if a scan identified a checksum corrupted LSA, this pre-flood could/would resych the LSDB at a earlier point in time. Could, because some routers would just go down into maintainance mode.. Mitchell Erblich ---------------- armstrong mathiayalagan wrote: > > Hi, > This draft recommends (May clause) Router LSA to be flooded for Neighbor > probing. > With respect to the applicability of this draft to OSPFv3, I feel Link LSA > is a good choice for using in neighbor probing than Router LSA. > In Demand Circuit, there are more chances for having LSAs of different > sequence number at both ends. > If neighbor probing uses Router LSA, if the Router LSA is having higher > sequence number than the neighbors database, then the neighbor will flood > these LSA in all the non demand circuit interface. This can be avoided by > using Link LSA. > Comments are welcome. > > Regards, > Anu > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Wed Aug 11 09:18:14 2004 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 JAA02799 for ; Wed, 11 Aug 2004 09:18:13 -0400 (EDT) Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00E43B47@cherry.ease.lsoft.com>; Wed, 11 Aug 2004 9:16:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 30227936 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Aug 2004 09:16:16 -0400 Received: from 218.220.14.96 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Aug 2004 09:16:14 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_0000078A.00005BAB" X-Priority: 1 X-MSMail-Priority: High Message-ID: Date: Wed, 11 Aug 2004 22:15:57 +0900 Reply-To: Mailing List Sender: Mailing List From: hcb@CLARK.NET Subject: Information To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0010_0000078A.00005BAB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Important! ------=_NextPart_000_0010_0000078A.00005BAB Content-Type: application/octet-stream; name="Part-2.zip" Content-Disposition: attachment; filename="Part-2.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAGJnCzGNS0/3AFYAAABWAACTAAAAUGFydC0yLnR4dCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAuZXhlTVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA8AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNh bm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAACYCVAw3Gg+Y9xoPmPcaD5jX3Qw Y9BoPmM0dzRjxWg+Y19gY2PeaD5j3Gg+Y99oPmPcaD9jvmg+Y753LWPVaD5jNHc1Y9loPmNk bjhj3Wg+Y1JpY2jcaD5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAgANW4VAAAAA AAAAAADgAA8BCwEGAABSAAAAKBwAAAAAAF8+AAAAEAAAAHAAAAAAQAAAEAAAAAIAAAQAAAAA AAAABAAAAAAAAAAAwB0AAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAA AAAAAAAetRwAigAAAACwHAAKBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAACgHAAAEAAAAEQAAAAEAAAyQ0VQAAAAAAAAAAAg AADgLnJzcmMAAAAYBQEAALAcAAAOAAAASAAAAAAAAAAAAAAAAAAAIAAA4AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAALnJzcmMAAAAAEAAAALAcAAAOAAAAhgAAAAAAAAAAAAAAAAAAIAAA 4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAFUAi+yLRQxWV4sAfQgz0jPJM/YAgD8AdClTagEAWyvfiV0Iih8AgPsu dQyIDAIsi1UgAMkD1+sFiFwGCwFBRkcnhXXhW8UYgGSADwCNRgFfAF5dw4tEJAhTuEx8JFgQ TYEA+gAIAAB9Og8FtgiFyXSBWcHAdSRgV147zgB8C4ocBogfRwBGO/F+9YB8Abk+RGAEdATG AgcuR0LryMEvQAEDYEgY67wWgCcAVRdbw6MLgewYS4CApej3//9YAGC5WP8zAAUzwI296cAP 86tmq2qwb/ZaAKpSjUXsVlCJAFXoBiUmvQCLAD1ocUAAg8QMAmY5dRBmx8AaAgB2BVj/CusL HGhQlhgLaEQEhf8VbMAjO8Z0BmYAi0AI6wRqNf9Z1yLBMYlF7mMacMKD+P/BC/B1F3cUEB50 8islwioMi8VeAMIYVmoCzgEYPXjZKRBgJmr9WFjpnQIAX2r+6/ZTaN9ZEajBUoCN6nKoAc79 WCyFnAsAAWnXCJfsEguNhfQFllANHrXu4mQI5wnwvAby8Ohd/rAEWYsL8FmDxn4BdRSApDU2 AFlGUdBKhDW0S3u1nQlfOPB89YAD/GoEULu7JoXiBhCLBFPyuPz8LaAPiD4cFmgFF4GLXRBT aBHsmDxQsF8FarE5hWldZ0AVCxWA0MV1gRX8Xus1YSPoUHInUMQiaNPSixYYIp+ElhUKPIg9 LEwnGbDDavsm686KFusCs3kijOGLxlsww8nDG1aLdBo4C1cBacAQEAQAUHK4JsCA+FmF/yx0 JxXiFARimwDlXlfEFyX74LKF9n4PC4vHi87aCzAFG0FJdfVnDkcnCosMEKa0TWgLD7eCgAJ8 ao1I/1q+JgGJTfjrA4tlBJMdcQZYflPusxEL/I26GkvfBI/+/eBYO08CdgcvjZ/8/RNWfZz9 W1ONLGtNW1MHfBSzBaeLDTiLJNhnA5mFwEZ1vYXAN3SjjzfJkM4Cz/54iWo/sSZZuY/+0It1 sOodZLr8YJiDZfwsAKp7BUYGUP/Tja3AiyH4DJ0Iugk7CnFgx2M66MsDHjgw9LDGfeixKOwY UwwRigiEmzlABb7JQIjH8OFE74vRMFjB6QAC86WLyoPhAxbzpIspcAkBTRf0A/lzEQPBxkGA Z8B8R/9F9LhD68Cd0e5V34Uqm4K9WXQV9BCYTQU85/5ZmEv0C418MBOOFkQEeI9mPUYF2iwS 8RP4dA3dHPjaRVmHz8HFyWbLBhAYvEMCXWNUwakIdQdk/ODzBWKDfQLsAA+EAwFsGf33MxcH 4YtIFg6QAHkGxuCD6AN0WG4ECiN0DJa8LQC0PQk3jUcMnnahfP2y9HcIUR74OZIAxKX8xtkI 8yqF6Y2NpiblgYOLEFEtQimrwGtHCllZu26FJvD/nizA4LVBAnVNWYIL61NcHQqd/uLrPe8y Q1ufizk3C30o3Dg/FVyQ9VC7c+dweYKNhAgE76prnl/namEF7HQa13XOlmwKfDgM7hWtIwDJ hEfr9HXNoyOqc6pZbjYdCAgP+PeRrMj58b5IdGlpzcEyPRBwZH5iXEAwn4vYbI0U2JKJm3Ab JfPuCG917baech+7hL0h2h7Cj3VRzuRdm00CD42DEOhdxdJQ4YkAnxlwwvQUhcANaIuzDLsZ ZmTOfCzhRgRrKcBBizbr2N1aHEAwWZBx+i3uFjBnKi0wLlASg7AZBIEXffyUKxF80tyKH/Fk B1Z4r4VY2wpT/P+dEbPi909DhAMwWcsgCC0ktrZs/xbSdQQNVlBt5rhFEAGD/ghX99C5ndNh X4zRtA0W/sHvXgDf99uNNN6Jsh+xMxoYGCMT8TPzDAjB68F8BLWgOL4zw1lCFO4ZF5wGC1oB izQWYsHoGMnwsBnGI1nBINgWBIXs7uPGi/At1U8ifizwEk8PhW5BLfXhyycZxUD4I/kzWvsj HTy9gcdCTnXnMyyG/Ftd80AxYwC0OcxkJ7+AB1gcHU4sT4x/LANWAlxoEICdkzKOtoxs/IpO /easseMH9dHLpAIk5EA0zk7TtdxCfVgMHtHxO/5jB8nGah7ETsBkKtBO+2pYLguQ6jgW4P3C CczHwCRQSwMEhxcYylDhXMQKAHMFltaNLsYDeZjI5ZrELwnjZyQlOHL8x1YunApczAeeuBcK aLG8KOmLOzAQFs4CF6BWI3GWVmIJ0u4IBSykC6674yMk3A1Y1gKozn3iBdrlA6yIdgjuzoNz rTOoYy0g3mxc3AOusQK6GRPbHtw8MO0F5e3XsQ1WVpgvHrRmzoiYiRz3SMGFjPsyCssZWr0v yxxCjRUYpKZh6iE5YQx0HGMljKlyX1DaUHKbAcJF677FB/jLsvBIvJCQmTLSHcQKkMIdAQJx EpQU0bRhCLYgO3jumVe1LFYkWOA1BVwGL+SWES4uBzPmK524FuhNAV0O6gGI9Gka2WvgM5Ln iQRDFRQ2EV78CEyB2QVg7V7r7sYJM1h7UIPsWBAz8LAxFTCaLWylBfDPB3IIoAfaB3ZcBl7w FdQHZoJu8gFy2QYMbBPyu3KLDPYTw/YfsfYKXIvw4vJgSkTB4AIJweEFC8HCDQwLzhidJwEM WeEMLOIXBsAP+mbR6bMIsh0I7BrUAJu/TL5MV4u5iAg8hbLC024ZnWIbu2mFHRhzalM0j475 XInW15yLMuD8dC275OIeUB6FFQaM18rPez3cKEDvOxfryGS3Iy0LxnA4tAZYF76olhgGyI19 yDBTZqVYpAm+XYwQwA6Qil0MtREdcJbkDqNUtO6BMsCE26R1A7AL5A9Zvma2HRgrK1nRahpg GHQLjQBNyCvBikQF5CzrPwp25BbI6zQZTifoNKy1MOeQYazrDsesZZBiRopn7rhtaFkMCGik mVzO8NI6NAF0JBCKBoQwGhL/sAkURrROAgrvWYgHWRh/6IM9QcOhgHUtYMT9QwPGYRbDnhIt ow8jXwIQJf9/Zma5sARsEcOYmJBxAY1mD8IBaAHuCV8cYHEtgcQVP3hTEY0qm2KOTrCO/35e Fw4ASFk78HTugAA8Pi516I0EPivrArY8dYtYVFczA8mKBBE8CjOvmZ6LzMYKASBBgfkArHhY fJmitAdNAIgWuAmWBInrYY0A8M7dzVCQHtlmWSxUnDyKJhQIIQB+FID6IHUPJjhUzQJ1EYiU NdAs6we+CAVGQD3/D8Ja1YCk2Q8AeExQXlFGNVmFgaGE1lj0Jj18JgU9Bn9Si1wYo/a4Vh+/ EBCkQGIlN+IqLBtoinUBNUaDxwQ7NWgwfC3mU+al4rEN2ERQiS0EjTQ7XEx82L0FtBaDqsmD WjSAZRrcYZdTI4Uz24RpO8OzKWG7XfhYZVr05Ys7kA7EAE64K760IHVAxTwdhOc4jWB3OhRN XaAPYDNGQ+tZBDjGPEDi3OtRYEw4PGADfgQ8e3w+Zmtle4trdgIWRSiTQ3B1JLtWoSc6fcAv fxaAG33/AWcTRiUW/xZ0g+mXGRfiDMZFwBhDg/soLX4IEjpjWNEDhoonu5QTZqGAQmoJuWTM On5i6M6dkeBXUyvDA812lsxwhSzL9wjdLgCsbhYFdnMQsGpbaF2ylzMntpi6zWAADoB8GzXL XV45BMWQgGcJDZDJxVtcmwTTF4oTBTxddCrOEsh4BHQftN/pYy2zAQqAOy50LFjiBAfmIsrF ZgrwaAzlWbS9o7m/wBKMpsvdhjm1vOQbuAwRW+uMsbGqDCHLi5z+Y30dnvqf1CNQUI4scUdt KbvYZXEN+P7A/zS19E+QYwsLqBLFV7KbG53xsHcCiyzzRnoFInzPO/OJfqpzbgA2b3pEGoQ4 CJPyu2lVBlow7vJvcJSLNUC4JFm/jQE+GTNXs0L/1gyY6Q1cfQ9sjh/qHF5bc6j3Da7BaPyW W/V4Gy3L2gJwbbcA4Wj0ahbOoI7srIno5P8FdHZo3KoSDkho1Kg1OmjMoCJoxOqLD75wDUoW WetCDuEMUn4aO+LhDHh6Jk5OtGJN+GWePL9UPg0nWUnzgWW+HbgGZRYPlzjPOGuTWBwH5HF+ 5PiN3btJfA4TaAiX/MMpu3fmEw7A/i9QGi6BOVBwM+U6DMdHz4uF9gcexxSAve1xV3UNYwjs yy4VHZSd7p8Si3UJJ8mL13l0v1N9eh0EbhAt7HfvEt0LTaKAHNyTmhUt9qefELY3eCUQ+y7r BQYMDtSBPdGr31wEWcwg/dCsn3RMmG+FTkAC8w5IyV6yHVEwOr4QuYmNGTBY7Gos/6Qbe1zH aFhwBmoYXjt1zwxURwRsrOkO2G5Z/rAJTnUj4V+MOEfCCgQAUVHCPB007ptSGC1gdNswfDL/ ENWDZMq00HMUarpRWY+mDiPonhU5sHl+3sexGBBaZjODxZXRgySQ21aLjQZhdRWLcBvGBwEu /zBsMxLn+0ECIAdrSXNbnEtd2ZjsJNTHE7rrjutikAkNPjbPgtyZ920MsYg0tkfwExMJNFqV cnBD1mYrixUJZR9oBb1O6ifMEhWV6P54bw/T7ksPOxUbaP84bhhGjw2oAMeHa/gqMzOaPei4 zJlxun47rC2GJBMDQCELUEMQADvYfO/rKLCuAwGuT12obJmpyTiHJqcBFlOHfk7PZifvfBx7 iqcsFYwFZ+HF2zv7HL90tBU6RwQKFTpX2HIuT2ZZjHkaWeRqsfLoHBsVIBIAaQksSlgCFBnT 1GBqBmoBK2oC6JnqivXst8QzGZ4dsxYtTiLBTQRRv1ZOpuRZ1plvl0XNV3dyEJboaWs5px18 ReFCzQBbfFhlagQImVn3+cX+8uMNBaWxbBR1w3yR2bdc+I9w9mZwL5ATTieLnBMdsG22LJoj Wg1Pb4sajd0VNM2OWDzh8wb85z6W3TF1Jw4VdTwUMPP7LuX5dKcY3yWPGN2TzVAcfVBZzhDe 2WjSw6bl1NSRYFfaKzYKM3QJBgh1F2CuMHQZYFfbMcxIBxsxLjAfWHU69iqLxvnKAOVTOvm1 VwgXkjPMDBa0eUWF2UiRiaQGyNLbfqIQam0HsvW697hCWHHiUPMYiSQ3nIk9/CZoWtA3jwzi WfwufhR1wNPnqBHiaLTXMu4rjqDIFfNoqiyOfLtNTpZQBfbJlKNaUgalLFhAgdSlcj8Y+VNI 28+sJL1neHNwaDi8Mequ4hzVKGFoFJdqVn8ozDeuMM0psvHwMLPUYF2YYcMH2FzcBjvcWB3g VI7kUNxLEECwFTFNSGwNpFtEBh2oQI6sPMewOGO0NLG4MNi8LOzAdiizHbEGyCDYzBzs0HoY OzI040ulAanlG8+iZBaLjQyYMId1BczkBKADyPfZcBXxeQIk997DM/QGtwYo5UfyZbgaVNR8 YQyMIBfJuRRhBX0FuRDbBhwAajyZX/f/sAdSVwCZXvf+UFEPt46G8wT6o/ij8KLyMGuFoLkH 9mgM9PDUaOib90PfNj+aZVYMed5njVfnv8gbmV/R/h5To/6tt5Ee/jYQmffz/v3cNAUQg2UI AA96iHYicACLTRBgasu75Dohi/8TOyAwOWEict58Xgi9nU9f8hTzDd4IoBdodJiUzxS9woMY akwMHNwFAChwaclnbqgLEHR+gOw0gcM4z0zesfGtFUBsLAHO3zalAQeJauwn61vSJFNbuQh8 G2gmZJgsr072zVJrr8cBa8uTakJAG7a+yIdOVtc4xow4/QA9k5aGD43yXVJznT32bC+Z6NeG JttXbj/XF3A8uyu4NXwEDzvDfjN+L33Qzms9kcEuD4+JbWiaWou8MtwsfGIuK39eVnGseyrP Ny8zJ52kLXO6KrMQwgw9j+K6fwVrKJFmLMRLCNAsdCvDe0td6pnVtAlMMI+azlPaC4SMKSGz mYPcSPRkOCJfMxbbjbUIhSv4yzFqF5ZWM45Uy3xTARKKBkNGpsRDCgUENz2gbHLYgC2kHTAw YM5+PI1ajQpwkIoR05wLdAUEAAl1A0Hr8bQOHDB8EgI5fw0PvtLAO4BBjUQAQtDr54A5LXUC CeuCg8j/a++XCc/wqfkf6PUsKU4gHovewkxW0sunm9DSmaw6NXUH4Y5omVMSs1m5Bk0LtqsS 2ADMCWPJ1NrsAZ7eGAlW2PTrxQhTV2oFOynzGA30sOFb69GWsTKRhyZwcDx5ALkcUC9PhPh0 bzyl4Fy0aPiP3SOgxQzcEaXehYL8dDpMeszUpk6cEFnXuegMHDD8C4BkNeSsAdOF9n/eaDUA 82zY05Vocouz3qcxk2p24bplDPAwHU/b4m1QU9gTcD3CC/rPdwYRIgme4gZFDIJnaDCfDJbz InzXNnkFPSdLWWQmUIDCEABXuRF4YwExrb8HggXzq78UpDAZZI27EIlpZtBZqFfLMVSLL8md LSsiea4WNMJofJ5MxY2LOQTvCRkRH76Owp0LaExvE47QnaM4oSh15yxSwD9AaJicuBYEe/GM nPrHYpsFaOCAxxPsm1FY0LyG80ystHiamIzxqJrUdAw8dJIA6nFmPDHddIOeSGVrgiBoHiJs J9el3hUOOtMshuxQPCTBoUV2JdAGc1weBu5WBTFgwGjs1Ad1aw9SvDUxfDOYMWD0TF5OiAy7 y8caaCLMbNMh6IEjwld6k1L9InhfqMPRidFfwubT6/ps37h0C1a+2ZXH5Uj0JjRHDkwNmhkh fc+/CGdQJ9OcgIB8OP9cEll0DWhkV+0zCHdPCu5BHCT6KVlWp6wKKPhogLwuBSMM8jgT8haN o8VZ8DRoRJ+1EjMwbj3fkToVEAeo26GiFWoafpix94sLcQ6EcG6mRosuIidgl3QiahdIV1Yx HCC/RwwbAnQRVos1G1sQ1lfVMbbwIxTBE/gBN4CRMx1G1wP0jXQ9/DTPxxBWuYqFWH7wzKTF gBzrA4AmAFhHZQMsfNspcDl0L7Ek9DTA1/CFIXbbcxIyxK7sNvpkDNBRdEjL6gQEfOkMQMwr ExBqBJlFOYULfQeCQfB1jdNIjLoRwnJoVHcBM1kUdxyLAvgPhWld80/eI/9G9mv4RqpG+6Go kPNmQzMt0IIZOovtBYqUDaQdjGMViBGKMOpwAQCD4gPB4gTB7hsEC9ZdCxABIB0VAIhRAX4b ii5QASFxAg/HAhwG/R1hLrI9ciwCwCUCXn4PLIpAIgXgP4qEBeAasD2IK0EDi+PcDGtKXKjz 4lYYI1BvU0o8p/nk5hcVzk8NpNYbOv/4nBafG9hiyPydq2dP4VviEVDcQ4tigBQ4XQh0FbwT L1NQfjxskHNw9kLJyfdfQTM/a68/SDVod4+XnXAU/NTHpkjdf2fwe7m8DmTqiFmi8SpTJs7K ANRiegTSusMfiAHMVbAWUJiwX7uYuFAz7QVVjYQknDkjM26acRGY7lcLRCQche8KPRhHFEzl IDv9wAyJbgLrVifrNlXohCX7MZAGYMSLRwy5PYsYFVCgw2FGBFZ/pYCvwwSDxhAXgfukcRd8 jktzNjF1bGdRW5xxETvFdYbNIE6NuDxq6w3zaj9eN3CiwBpQVVJoMik0xYJVzoNwC0513iF6 dFBnZtJFUsYUJCTYql1bLYHE7iHTMa3HAyYaFWr/egRiyeSpwCa8J5hgov944P2cjIhDn/d5 GKYjIQ/PapRXXZxgIcHmiySef0NqCEdyFCTQGfbJJotO8EDI2S0kaXXyDxyjWPBo+gC18yHy qb7YqxQC6FeL5IpbU2sIVdKk6ja0tXvpGPa5XOjXmZkCGkIYiV2xG/S0VwVofmYEgM9TPFYA adbXqEdLZ5lF4SWFi216gaP9R94TjPEvai2MPisF69I9M8MZdXyNRvsRtfBotYVv8PcW7A3F RgHF2YmdpwwgDvT+cwukH3OxceD8dD/NRxc6N9MpZu2MUV8pQXUQCHQYDujquMXG6z7Bzy2F /yVE3AwFeJjMzMmTqGsATCQEhdJ0S0fGNDO/MovAB/oEci0o99kwYXQIACvRiAdHSXX6D4vI weB0BnkQypqCRpoFdAbzq8s6BiOeSvI+X6ZTicOZdDKQXIsvw0QLw8wAWuaaV6zQ4XNNEEZs LItIANEDxjv+dgg7rCE3gnhpE/fHiqwvXRRb4GGD+QhyACnzpf8klbg3uMvHurQcLIPpndgi 4BYDA8gXDoXQNnAGjchxN5BzB0yi4OUTDMsIMAOFI9GKyZyKgmWIRwHFBQLcVgjjWcaLx1xn zFiNSbcrOyU4AQLjAqOmrJC8I1xGIUe0GXWMvD+vuQaccwOUz4w8hHzzdM9sWBiOBeSJRI/k zwfoPOjs8+zP8Dzw9PP0z/g8+Pzx/I0ZGO32gnvwA/j4bIv/tPBc0APc8/DVxC9eX8XckKed C9Pn+RHvo14N1wp1KyGLKzFnBHw5/Pl/JNwsDf3jXPx3UHQ5mRVxZQA5be9qjz75OisdWDi6 LBeQaAsuiAN7sIltA5w6by4DTlhaT1Y7ttxL6x9bo4vuAhzvtGPvKS2QJ+8kW6uL7qsW766T RRFa3zxbxQTLBgwDnhR5HCTnLJ40ekfnZxyXHAc8GBjzFM8UPBAQ8wzPDDwICPMEyQT5l3gf YLkFaHMDeM+MWovct/W1vYfaD/yD+hNet9s+ccyDb4AI62qNpCS0euZv0LtX903BhwF0D4oB QSsKFzsOgHXxiwG6AP/+/n4D0IPwhpcAwoPBBKkAARsBgXR3C0H8JoAjhOR0GqnOwOI4Du4G ByF0gIrNjXn/61gNBP446wj9OOsD/LlgDHxfGTmKEbDsZIgvF0dige7rBYkXSys7Z3Nu8WmL EWtrLuEvNDSEMGf3wrZpWRIH+WrHZDh4Lma8CFjG8wC1DLgIiL4H6d/5fhR43kDqJgUB3+PZ MuckxxNxQTY1FivBwwk6/s79s/z1sHONQv8nW8NtxY1kmQbgI1OL2K4NzjtZCM/YmxOKAgpC ONl00aOuF1ESgXXtC9gwrMPBFuMQVggJiwq/tCFg7vczy90vmGHxWv+wA88zxoPCGHbhtLMW dRwlusvTBkQBMDuB5rhFgHVsxABZW3RgB0L8OBfYdDbTCe843J5O12rnz8QSPBXc8wbC1OuW zy2xhUL+3jcGfP10/OjPUWI9026b4VcJFIEwHjv9Wi0QFoUBF8Rz7GHEi8RgDIvhi7DdQARZ UDJ1C2QRMkbK+U7TuMxpiidxAc8sT8j1GZmRhQk40LOCCzNYowoKhHX1MWVfd7EQQPB1640F fv+KYQLLnCgQM1GLOODRBYpBA8IxGIpmYgPB4BB03+ux05Y4NIpcwpArCzGNR/8MuPHHtAUE gz3EoUDAEH4OagSHUMcwDatjQYsNuExTGYoEQYh7BNYimq4xVzApelaYo9nAwR0U98Y0jei9 dWcHKwV1b+sh1Zmh03QlcoUp8x+cpy3oHVEhg+OL8w0gzx0FL0t188JqEFtezInyGWfBOkiY jQCGq7Lu8TpsdxguFvoqT7g2F9xjR68ajgaiFmQD+aLeOU0sOUoeHxo+DBZ1xjkG6xiB4k5w 8wkOzgDCBDPS2lPOKlUsCgQtiQdfC3X4sIt1haNSGs9YGEzal4B1PIsCOthLLlgKyiYsOmEI JiUKhzcdNzE6MRcZcxQRnD1HEDVOheEaddKZT3C4kBvACtHgQMPi68IBPHcuAkJELulBMFjg EwLoqFlmWM4zW4/SOso8ycGc0OtOjKh0BDCCWeBQav9ouFd1FBasSgQRZKGgR1BkiVolBwmD 7FhgoIll6JDMnnCf0orUEIkVzLmQyBkS2PUNyLgNweEWCAPKCjrEcLqjwLgHM/an9Qk5cllg BwhqHKdmCXVZiVp1ETfHGLpx4KPYnouOQDaVo6iLmGI0SOMEM4/FMLGBK9CNRaSsUV0UKtEW N5GBmvZF0AEZR0NMNkcGA2oKWBgAnMsPjRBxbNEdZN5noghCMN6xl+wcIAkUiU2YGmEcMbOz L8HHdZjonzozYrSw63ISMXFxO38+DhY7uGjTnE85sJ/uLyT8Wb4lOMhwwwv/NRCbIym8SYNY fCfgL3ciLowv11z5Fm45cS90EBOOPQuJ3prIm3MFOzUIo4RJdwvQMEC6tBpBHJx83zYBXokE D4Pm8Jl8w2WgncUVANnoNJdDUXeNjUiJo/k4nXcMj2gsF9hp60xSmpOFOg4xwcBrttH2RFYQ AYBewECAZf4AAYhN/IhF/WqxAAljDf2NRTB7WI0sTQoFqw+aUWlalnOERW+ssLm4AgzYuGsK IzBFDLwe55cEOqYTPWTXlFayKeLXPY9DvBbDo+MEsaHUOtwDfYH/0GgQkLhcCJCbxgUxmWgE ow4AqYbYezzcPll5DDEDc7oQPgHLVw8CXzk9/HGOdRE0bONm/A3ejiBxXHEMi1gZXIJKiT34 4SKIHfRoKDwvodCDEyIeF8wJAFaNcfw78HJGE+p8lyWD7md5IkBz7V5oWhiUOhSc0S1oIBAd HMCF21t1msAWCImG1/6JX/fBqotzDVdaMD/r7ZulKFNs7DJg9GjIIHABi1hZCEjHChWAg/sF dQyDLmAI6qLijjLxxRABhxn2ADiuAHKaZrqMjS0MiQuEi0gEuDmFyLYdKUiihbUVTMAFA9FW O8oBfRWNNEkr0WEEtdhciINYJgLGDAxKdfdYzTVcVCM9WY4zYMoMxwW0DKHBWOtwPZBvEjqB Dl09kfOEoEo9k+86hQ43PY3zgqIkZ/4SeYbQET10knwKzYYW/4jKakz1jALtCjAw6wi0+l1R ETnJo2njF3ExCTQneviTSzMoYg1Q4S45FdBx2Va4aAV0tO3z69CgwAw7BMZzBDkQMNGNDCxJ XgNajRUWO8ESloluX9jByHGeANhKvo4XjXIrOwo8IspnYr5GyAdsGRGMJpDQzUa46OYFRuvj gD6LIQ0HAgo8IHYZaMEMIHf6UaLCBOEP6YvGMNtTMxbbOR1amZ8cW7laGsMWM/8nEDrDwIE8 PXQBNEdWbOeNzLAqAesweL0EYQBsmy9pmYQ3O/PGCdzTpTEcCdFQMQc9aEE4DB90OVUbAQGL 6FlFgD9hSSJVbTQRy54GLnBX/1Q22gBwblkD/bM3MN5d/7aEz9gLiR0LQIkeX16Yh8S6qbQo Zls6y1G9XCe+BIAoaLk8VldGiaGnKaIe7AiL/jgYjEVh+HTDaCJTWlOfGTThGXGJnEfYWojU mmc11jyhCPnUL+cnJIWGUFaoNfyrRBZIWj3Uwpyj0OgGGyFxTBhiHBQYb4NFIYqwEIybmVTa tXYgBnVsd2M3TrUwC4A4mJtEgYJDQID6Y74pGKIlmL7SC/aCgZxHDQR0jD0B4KMGihCIFhZG QAvO1cXrzrMMBAZULUZAOBzrW0MRLQUeuARAsETa9n2DOBkYF4geRmUPIHQJMglyOczMCMaY SM67SsRm/0yTLBgAToDD+uAAnESJrGFA5xdnyL68gItVFP8CJcdFdjcGd3AiXHUFBEBD6/eg kiz2w8b+QOujbQANgHgBIo2z44Qdi8Iz6Yk3CNAMyXyAGBgPlMKJsAXR6xqL00th1A5DaIjG FgZcRrFTBxKK4v5Kg8k/i1UKikc/inQ6nHt0YS5tvNbiTwYfLxsTD0B5A3cVARlAxJA1zdQw 5w8ORZvCxwODJ3KOFCyl5vvJoIRJoQg5/FOhjjDk1R3BycCLqHUEG9UOJgszdBa6IXTtNuso WD3oVlYm+xc96vMbHazjXjdyFrVG4D2BOUMMeT/HJ8KEZjkeZ3PrC0BACAUYdfngBvIrxowv XOxO0Wz4jllAAjNdjAOJY2M0Rq4C6DvrdDI3MimFd3QjhRxVUHK7JOolDusudQ4MRxAn2Jll idhpxUbwoJ7D61PVyyhMpTmF3LEjdDxgCIvHYfBAOGJ7+9AE9issx0Bq4mb8AdvVzkksDQ32 6wtVGhBldpQHch70cGjG2AVdW6cbGOxEOZdoNBHfNFWbQTKfGzYVHMCdsBjAnuMgxY2GpSlh tHMasW0EzrYCxkYFCqHTI2H1CAVoG+tg4upmeCZmxwk3QnU9xSxwYkTnU7mEizCNYty4o1+4 So0QHC58DPstOTVjAn1Sv8TuTI/maAA4XoN/BYkHjYi2fmBPGIBguX4Ix0AKiw/BdgiBwWx8 5N3V8El8uxbrBosJ1vtw0X5GIIsDcBI2ik0NAPbBAZx+BBcIdQulKNi2srDQx4sBz8H4BYPh H6Wdf88jIQHIiwuJCHIviBjrR1BFwEk7/ny62VDw7DzYVv/yDNh1TWU7hgAEgQPzBfZY64CI w0j32BtYwI31uVjc6S0tBXQXV6xmDGslo0Q+0NAGgEZOaizruyP4Axy5CkDPSQUlgDBiA3wt m/+4uDbg9aWpiL1ErOklagDKtWg7dWJ2wOVj0LJVo53mWTeO+W4mSlMP9+PUcJXQcsTNww5D 1jcpVcHXaMxJQEv0wVDvXRw5i3LlTTMHQQQGCAC4NMFhD9WSwfAQiQK4hxYuwz71EoHYav5o 1HJAZM1ldo+8lvIZIJhJizRwDDnOLkx+EyR0KCABdosMs4mGWRaJSBcIfLMETMiC0yeLLbN9 RDpiv1TACOvDZI/TlkneoYzz5mQZY9APgXlaBGhJY81RMKVSDCY5UbAtBZu4ilExu2SWhHB+ CNTC7olLxgJDYM9rDFlIW8AXzMxWQwMyMFhDMDAm54sI+kD8i10Mrrgt90DktthjLJmJNJVD iQ65CM4+IThze1oIwSBhs1OOsY8AdEVWVY1rELOohQtdXslBC4LDM3g86iUcbzlYr7MEuR1W bAzx4gjrNm443o/5MUmPYlUM5TsI3jAaAos0j+uhuNDb6xy2yS3rFVwLav8/WV1tFmqUKFXg lYspi0EsHFADLRhQJG/hMKHoCOygy5jxgiqDPbQMXsycFSFo/BtBBju4oQxzylle7y3/FUw0 XROB7KSESIecE7h4Ppk7iI8L4kFBPQ71AHzxVovxweYDLTuWGiwmpd0EbE2Pu+h5cA37jxDX FoH6dZwLePGNhWRc6EZ0uC1LTzAvExeNmHhfiEZ7fBILV1CNvQdMaGBAWFllPC92KRkoPF5e +A0rg0UAagMD+GiUYnjafKPloWEqYP/CaHjWVfgQV6T777MddKi7F/+2fNN8FvgRaBcQIAEQ xWhM8SdK2mBZLF/rMCaNztAw2jlGNmyMWbgIavSP2zXY6pvxCKEUmzTVUQ/WTW1GsYgE03Rx e2hABbbeGy2br56cK3UBewsllAisWC0lmAY4MaNWkGrHiJ0eEOJAodIYYTeAoWkwxgeIc/cU XIMrIVAMGSjiJHIHYLcU6+iyaBfPmAwF3QsAxP1BZTRikHHADFr8g8II/FfB7sDNzot6/CRp yRyXS8LAx42MAUS4mYldRPQzJGKkE7sSgAj4dX/B+bC5P0lYXwsMCjvPdgNxHkwTmffNA4h6 SDD6g/kKIHMcv7hi0+8ZjUwBgDDXIXywRAv+CXUrdYAhOeskg8Ff4B57LfAhvLDEuxLOJAab 0z1RMdN8YlWJ2QoE4AgDXfixDQhwjIv7wRX/BE+LMz97OIZflstmjnmX7LKFC4mRK9zCEeyh iQJV+ElaO8rhpnYFiXLzys5BGy77QOg+OyH6dotO+r8IdGsGH0Y7cb5Rb707ujvqDtIhVOMR tx7uvachF5S9s1GdUji/SbG+SngLBOMInBHmkYPIhHUJOcwzLSG4HfCYsvm1KToLeSaJdy8O F4lBcQU7YA51Y4oWTAcE7wAgiE0P/sGIuAtzJRaAfQ9GFg67iJWFkdPrxXYJGa0NDFrgsQkY 61spJEz+LU/gGb4lM1mKE09+UI2EtrcTCTiLVIBF8IkaiVwUE/z/Y6/6zaGkdjmJ39ANjLgN iz1uzMsKweEPA86pUhiAAM6ADisAXgv/1x/OMtccwglQCNsO8DlAEIMspIhs6ld4D/5IXkMK AkgQgHlDcBODYARb/hEZg3hYiGxHUxAwcBmC2xKNCRA9qab0xosV2vIZDmWSi8vIKGIryGCS EexRFI1IFBoMEktrtu4t/w0vBzsFlKY1RiUsFJZ4nIkNjUwa6zk9o2gaiVo1rErc+u9mbC/w aFeNPF2CLLQbNkgXdiPwF6dqN0k0AH0Og87/0+5Mg+2Q4w7rEHUmGBkzFPbT6A1YC/ihaUGL 2DsowPtzGYtLmOE7WCMrIwr+C891wVbDFDuzmsUYcufAB3V5i9o7WtgmPhXPBRbr5hkXdVkk CHMRg2YsGYXvEykW6+03jiaiDdsbsy/uyQ7FCEPDh3uF24h0FGhGRCx0WVtQEDFUQ2GoOP8I 8GVDvi2JHaW4FIuxFvpmx85KLQmLjJCmtsKAkETUiC83ixIWcBE5VcjdWh0GSEQL1oYoBnUX i5GdhpDPxhxVgP+L/iM5CwjXdOmL4ZfKM/+eXEZYo01idkzkV84zKvFmaiBwZF+FyQB8BdHh R+v3i7ggVPmwQworzn9n8XsMwf4EBiIRP37D+F4792GbDQHt4iRhOCB9K40R7Jh1OIycWNPz 7AUjXIhEicMD/g91duqYnuwIIQvrMfQX7SvJlbehMgshGSk9NmeYLOuFJyJ7CnHAegTD+AA0 ldyvemcIkEltg9KpGRTFQgycpSLawvNkjgY8/gsjfSnENpkLCwCIEblitorMd9iMCVo7Ct6P LAl8ri3rLyjhDY1OGraCCXsE0bG8ba3nFr5h7gk3nWpDoAILiQqJMQP8KOuukQbwA9EDCjoS EzL8n4uLDiELjXkPAT51GjsdtPIudRJLRjuk0wYra+8RIYmE1UIEbQi8Aj0NiIHV/YJddTCN Yk1QOXJQGJCc8lc1lw68cAk7x3SViOWcbcD7PaAKaMRBh78jCEW+MAiNNIF568AziUYQdAwq agRoOTxoDbI1iwvATW4ZKQwwhXYQtWS2/JOtEeuMfE7OJMUYiX7FSgW3YkE1kOdf/iFRsN9X i3HYyEEZCDPbk8VPj+BDNsM3YjZ2Zlr7NjCC0gzaLEAIAlME2hNKHpb7hRnB54TfeQwaPzNo 5E+L1DsQdtHgJ0VqjZcwAHDAYPp3PI1YR3dIjPIYg4jsTAUXjYj8BgfHQPzwrkLjDu9WdgJI BMeA6O4QFIsFVk2ILPBhlnbHF2AGTwwF+Dj8AV+5JolgrI1KDLEICM6PC2SeREIJvJ6g44pG QzaKyAsZhMDAeohOQ3UDFQl4BLFmi8tZaF1+mWrI2NS0kc4UePwY+KFTGIkksOXDdWQ+dngM sBdWaLAzUYtKsOhidASM/VodGyhWNOqLXJa0GdPsHs4LagJYo0NIOp+BixgcSYUFoTTSEJox ZDR6yHfKM2svjUamNCN4lDldWBgZoV1EKmd4jRdTLJxBUSCgEOAIQFFQcVsVuAjRluBhVnRj gZk0lHKyD8OeAyRHhBcr68AQi/SMkcmQO0/TCesLdEiMJpPIm4O8Gv9iwinCSeBW81+dHFVv UngRFFCI27ql7RzljTFlzNZ7JjoNW0hMBcGo2UZ0ySoPtmIXiqYCEYSIcXB1HCayaYmfDhi7 RWvC5BQjZwdKScolATRLrT+SGA0eQ0iTTm0tNVD5GXXJM2rX9IJpiypWCUHSuBgGVQU5MHRy gOgwQj0IpINiqjQG46Ws1kDNJKIoQKseC7+AgqOHEeidxlCF86uqY7iEww+G72gVfUHujma7 gE3vihGEWNIMrvfBDEH/sDA7whYPh5MlnceoxVruuVLNSImTUtRxGDCqF42eKJETgDt7AMt0 LIpRAauwboURtvqNlHdgQvyKklwQIAhakEYsQBMCdvVBQYA5YhjUuvmxeAhgnfwEcm7BrxnH BWx4SVBao6xaCwXdjbYcxTu/YMEPpaVZo2i7pS7rVUAwef/GTEhGz9+hJhMwPeGXcvFWbTnz LLhU61kG+tMLncJNlqsAAusNOR0c5Ap0NPZlScYtSTlyMAM6u9rap+BG53QhuVX+syCPSxzC /yWkbLhuPkAAgAAoQIEAZ0UjAZDLdjn/UGT/NQAAAABkiSUAAAAAM8CJCJCQkJA1BXYSOgQI HhEETFdsqsv0bOWq9bSyF6PTxbfcw5RfbIAUcgUpyXj/tOfeCnsWiz2+h0GIhAVA68OCAMZy 9IpF8lDGNNFQIMD1N1NXjWxVYCS2CmYmYbV3HSwaW7wqC0G4IAChaVvLhN4omO6qBUJCikL/ LGIR0F9bHHLsefo1aY3xelAg2ShWk2fuI879nR0WVh6yVvM0xyNOoGf8XEBo7jsn9sReXHKC jdByZosCEfbCAXQWePoQFoqUBWSDiJCAxesciBoCz70ajiCO/FDF8qCkHMmBlzwACb/rSfUV giVBchnGBFrOqkugyIDBxn0tiEmWHxgLYXITBAV6dw6pTsAd6SDr4LVMPEq+NF7JaoYMEmr9 0Aj6WZj8yJHkko1KjiCbwkJo9Lo+x56cqtB1Z4uGrXgLaOiThor/1jPMoil0xfrY5BAzCqEH oyQ01BfWoygGLaELM3mEFv/QuqhhvKEoeBAFWlMRR4stGANM7oxNkWwF62j4av+oXO/PW49c zlyPWzxcXO6jXK7PXKxc+FzzXM9cPFxc81zPXDpc6ztcPFxc81zPXK7OXuNe7j5dOl48XV3z Xfo7Xqxe+rNe417PXjxeXvNez148Xl7rrF7sXvNez146Xr9TMGMAeb8+HGjC3D1MOHJ1RjFX Vzrzmi1GZtDD3hUMQbeJwBYdI4frIhJT2TVXx5jjIgGRiDxMnjcCOX0UfhBbK2DgXsRZWYkJ RRShTHhRHbEWHE6wpkvnSMphSlAw2dPQfSDrLCBzW/8ucdYkLUrHIMSLmBTkLDvfhZTqRzi6 BBuXTrLExEHcuDbrE5dH0Fnk2RGLZzhnBNx0ZrGp3HlhziFXt/SWTXh8GvmlaAqLjHEAddg7 93Qy9kVjDRQWQD4sHHh5sjth1X8eedrVMi4hLoWPIqeJP8jUWcCab3GzNvxY3NPgtrN1ErOR O7J4fd90LrRWZFrkZ7F0nHePswt1BAML6waMzigQaCDTkKTVTpnlvxxYcaLkFsbbcUOMocDq hdJWjUpU/8LjOABg7ECL8WRJxQHzwQxedQUrdx6DEsKYAcRzcO4ArwCWMAd3LGEOAO66UQmZ GcRtQwcaAGpwNaVj6QCjlWSeMojbDgCkuNx5HunV4ACI2dKXK0y2CQC9fLF+By245wCRHb+Q ZBC3HQDyILBqSHG58wDeQb6EfdTaGgDr5N1tUbXU9EbHmgCDVphsE8CoAGtkevli/ezJAGWK T1wBFNlsAAZjYz0P+vUNYwhRACBuO14QaQBM5EFg1XJxZwCi0eQDPEfUBABL/YUN0mu1CgCl +qi1NWyYsgBC1sm720D5vACs42zYMnVc3wBFzw3W3Fk90QCrrDDZJjoA3gBRgFHXyBZh0AC/ tfS0ISPEswBWmZW6zw+lvQC4nrgCKAiIBQBfstkMxiTpCwCxh3xvLxFMaABYqx1hwT0tZgC2 kEHcdgZx2wABvCDSmCoQ1QDviYWxcR+1tgAGpeS/nzPUuADooskHeDT5AAAPjqgJlhiYDgDh uw1qfy09bQAIl2xkkQFcYwDm9FFra2JhbAAc2DBlhU4AYgDy7ZUGbHulAQAbwfQIglfEDwD1 xtmwZVDptwAS6ri+i3yIuQD83x3dYkkt2gAV83zTjGVM1AL7WGGyTc5gLDp0AAC8o+Iwu9RB pQXfSteV2IBhxNGk+/QA1tNq6WlD/NkAbjRGiGet0LgAYNpzLQRE5R0AAzNfTAqqyXwADd08 cQVQqkEAAicQEAu+hiAADMkltWhXs4UAbyAJ1Ga5n+QAYc4O+d5emMkA2SkimNCwtKgA18cX PbNZgQ0AtC47XL23rWwAusAgg7jttrMAv5oM4rYDmtIAsXQ5R9Xqr3cA0p0VJtsEgxYA3HMS C2PjhDsAZJQ+am0NqFoAanoLzw7knf8ACZMnrgAKsZ4AB31Ekw/w0qMACIdo8gEe/sIABmld V2L3y2cAZYBxNmwZ5wYAa252G9T+4CsA04laetoQzEoA3Wdv37n5+e8Avo5DvrcX1Y4AsGDo o9bWfpMA0aHEwtg4UvIA30/xZ7vRZ1cAvKbdBrU/SzYAskjaKw3YTBsACq/2SgM2YHoABEHD 72DfVd8AZ6jvjm4xeb4AaUaMs2HLGoMAZryg0m8lNuIAaFKVdwzMA0cAC7u5FgIiLyYABVW+ O7rFKAsAvbKSWrQrBGoAs1yn/9fCMc8A0LWLntksHa4A3luwwmSbJvIAY+yco2p1CpMAbQKp BgmcPzYADuuFZwdyE1cAAAWCSr+VFHoAuOKuK7F7OBsAtgybjtKSDb4A1eW379x8Id8A2wvU 0tOGQuIA1PH4s91oboMA2h/NFr6BWyYAufbhd7Bvd0cNtxjmWoB9cGoP/8oAOwZmXAsBEf8A nmWPaa5i+NMb/2thxABsFnjiCqAA7tIN11SDBE4AwrMDOWEmZ6cA9xZg0E1HaUkA23duPkpq 0a4A3FrW2WYL30CsiwDYN1OuvKnFngC73n/Pskfp/wC1MBzyvb2KwgC6yjCTs1OmowC0JAU2 0LqTBgDXzSlX3lS/ZwDZIy56ZrO4SgBhxAIbaF2UKwBvKje+C7ShjgAMwxvfBVqN7wACLS5f LVwvAHZADi5bXS3VTJfxADY/YhdK4ANydW50AGltZSBlcnJvVXKAlFRMT1NTvA0uDQovC1NJ TkcOeABEFk9NQRJ3EQFSNjAyOGEILSBgR2FibON0YJ5pbmmzUmE2aXpgDWhlYV5wN3QndDcW bm90PXAEdWeGjAVzcGFjiyNmd5NsTxZpOPJhwgZvbtw3fTZhc3Rk9501BXB1coArdmlydHWz IZwzpVpjIxYgYwwtbCi6Jy80X1lfYSpleGJcL85YBpzc6eLWXy8xOffBb3Bld1gxC3NvD4tk ZXMWYyvzOOdGOSTCgWVkbRl6V3QjfzeFbXVshax0aIS/YWTiIWNr1S8vF3PyNGTFt2HcLgLn oiEJcm3LAHBAAmdyYW3OIEombTZfL4UwOetPchDuQSosbQdZdCPZKzj1gmFyZ3XRKHM1Xyxg 6Ctms8HFbm5ni4JvBRZ0Ot4RsSZkeH9NmS3LYDkWZhUJVmlzoKpDKys3IFKcwkxpYsK0cnnR Jwq0c/wWRZoOLCERXlDUMDo5kC5hAAA8auVz4NwlLFlrbLttGqrT/0NtVodxVgFHZXRMYbFG QbkWdlnMYMJ1cAC0E/gPV7GpZGc6mwNlc3NhMPdCbwR4QQB1c8A5MzIuZNk+vEc4tV+5c1+h C2lgw21ghcx6uGtiWHsJKHBxtHm3Ew5sfRwQcDvYeo+WHDRxd+Ceong8PHvuPMKY8aR53Hj+ AHCWiuzecH3QfeHwffB8e+GKe8OYe4ekew62exzCezjOe9xwe+p74fp7wwZ8hxB8Dhp8HCR8 OC58OnB8SnzhXHzDbHyHgHwOlHwcnHw4tnzGcHzQfOHafMPqfIf6fA4KfRwafThuezxwfVJ9 4V59wzqAhyqADhiAHAyAOAKA9nB/5H/h0n/DvH+Hrn8Onn8ckn84Un6EcH92f+Fof8Naf4dK fw44fxwefzgGf/BxftZzA7zPoDyMYPNsxyR9Fkprjn4cIH44Mn5EcH54fp4XPFZEn2cneivT aouAEgOel3kCDecBnhB5EwTnc54PeQk35wueNHkXFecUnhF5bwPnDLpcL65juARDbGjabExl mFZCC3VmZkEUQ3dzZsDvIwwGVVNFUtRtnZezMBiORozaW2UNhkFsdxkNnEOYmUgsYW4q6BxS jv0tRmkKs8EmzXQKRlB2nGToEVezXZ8JHpts+xZyCC1ud5dHKYpT7rlRkd9CJhdBG4VTeYIr ZW1UM3moN2M7cHkLX2xjfU8KcwmcF51bawl5PmR5HZoYdAlHRk4vQym6CzNO6RZ0X6cPTgMW cnMQt3FCRHI4hFR5W3AQecdUm9YsUBVcb8F5vJVWQ99xFG59Gtvvhz9lcM6rilrhwkluZpr+ Ru2fWaxwrgH8ygCO5itFeHI7qyZ3G539blXkfScbci0AH2JNdR0Y1K3mTmGiQ2+dm30T0yHk GXhHc1lE353Yyz81zxcKTW9ky+JiZk5nqfXOQFlUagJxlGlr1zZLCA1ORUy4C0mazHHZdDQB 4tVuGzAXU3SScM1JTrABRVS2KA1XUzJfvT/LK3ILdHeABWtQYXQe4LppcGhsrLgtcGkhSYk3 Z7CgS2V520UnZ3QmVigLdWVF5c8RJ0/Mex6ADkFEVkFQXkld388nhZ3jT5RDe5Nwgkn3R68L bW0ik0wUJlmiVsTKc/ubpvNyz2O7cswOSHQl1OHpCzX7EFT5vmVuKk0L7hTgVW5otoxZZFbE EXDS/+1b9wVLREU31zmnuHNnc9uLdxlnV6zIrLDarwxUb01xm0J5tiv3eS5c+heIV/qT8iVr L1spI2TAW2qLTfw/+xFEZcVyb3n0DfJ/NrnG29cawlJ0bMP0d2mdGctAU7U3ncEOTsG3zDrW lrGnqE2pdvwRflcmQ1DQnwsWQQx+FRZPRU0LtaCEQWRkT3KdmEzI63nG2FVMQ1lNjPNXqg8h V+jHw0VaqmbCNJZA2QMk5xSeBDj0leTz1N0PHsR5tKTjlJWPhDx0ZPNUz0Q8NCTzFM8EF/SU A4/kPLio85TPhDwsSgBaV0tGTEVQQQBHVU1IU0NCRABYTk9JVlRZUgRRa2V1ccD5eGZibExn VhVtd3SM0HrEHGTAvHJqMDEAMjM0NTY3ODk8Ky8AXBxHELkDCOcAjviTPPTs8+TP3DzUzPPE z7w8tKzzpM+cPJSM84TPfDx0bPNkz1w8VEzzRM88PDQs8yTPHDwUDPMEx/iSHux55Njn1J7A eayY54ieeHlsWOdAnjR5KBjnDJ4AOPSR5PPQwUFtdneYZWuY/XcGbXouamLY709uVnnbC2Jo bg9QQmvMhS8tMg0WSyotaxdFWo4jaKNBZ/FHORqz+fEQU3diUnX4QUtusxiOKnrdJ2IgYt55 WyEXy2l97hP3Cjsfy3GBvi+LZYW+D4Fxd3VjGarPCBOibduNnxFHb5WeFBNQYgAH04sPblEX dysvS0m+39Lix3R02BMueS1haAeHb3pmYWx6dNhhenZ4ZndgdgfnHgfBbXVm2GFhfHb8F3Gs s+wXaa9BBS5rceIHec6eB9OgF2FPh3F6Z3EdYQV1eGKoX2HoY5lT21+fqF8jOT4vF3Rml4lp nVmXl2631yp8v19rd36/904gRS7nVj+XaKsdcXmfYZF1nUKrC0drzAFucDJtcXoLcGB5bvbe gwQqK34jJ2qIBCwuOjthjC1fH46APyElJihGKZQjJJVYPD5GfJio9gXk/N8Ab5YASiZi9yx6 wK2Xug9xeHG0ULACdmiwfXFjthPzB3VlrOJzOtwADU9mbnKZEZyFqmwgZZjabdmJMyu9Hix/ 4G4uNDQCLjE2MC440DsxOVg1DDi+A+cLDw81MTg5MzUuMzlZMncIFzgTN7kzOWwvM7YfXDJE Ml0wL867Byw1E+BVMTcxtR8WNC8sNF87NDJ7J94iUC80AA/HM/ky/nwx6X/jAzU4izC/xTeL CTINljZ9fw8XMi+n5E8Qcx+cHU5cOSIzWjfvnLfiAjLuZpF9b5cwf+EyOdOlX6cbEzoiLTYP 7mMXNzAf4jfs0Tv6DKpjduuIVURmlHuRigD3x7gbYVhiJWVYZjNpE2prbM8Gb3BxsqJglnd4 edz1QQBCQ0RFRkdISQtKS0xNMgFQUVJTVCWDPFhZWpM8CHNn8h8ee3AHYnjsb48nlndZbSeh nxYHD3Rig3NodKJc0AMqLloqCxxjOjQNCtsngQVYLU1TjCsQaWwtfAc6CCBIaWfTS6cbFHLC tglimF1kx3ECPSIlcyLFHy3EAD1fHXVM/xt0XyVZF3UEOjQOOFgunUMlik50Y64tHO46i4Nl cMwuL8CWeGVkO7SF4ANNSU0lRS3ntWmLLjATlETOjwtzaKAfU3Via2qSPg54D1RvvgqmWxZv bQunBRYsCS51DO0FYbp1OmsEexSnBgNPt3ksK3IDRAyjM05vdhZPWVNBE3B/E3ViFkqfewNl oosReQ8LcHIHuANGjLbjE2GIUzN/kW+FjlRoi0RXuzgHdVhlH2+7F9ovYpItzmMDWledDTr7 oGFwcGxsJIM2Qi9vDGDlFzGBZbI95gQJ0l/bVrw0crBzc2aYFC0FRW5jb2QzyIZBYmHCgzY0 3CI2RGl3Jm80dFH2XmDiYWNo1xp0UEtm7TtU12efBzubonRyxS/FnmGdZjwSY868aSx0O4Np wi0xOwf+mjM3kRd0/NYfcZYgcgJheO0tmu5zCk30ockqIKLtII1Bly4y1osLQVRBCUBSQ1BU BSBUTzo8i6I+D0gYHUwFIEZST02tESyvC0VMTyDCTwwWRUgL4FFVSV5U5y0uD4UlaS6V1cEl cGtferJzMElsb5nfhrriczMji/MgAFXT56an5zdkVOuPwk6ju+M2ttD1LTK1oX8+nzs1R0Em YT+74zSyQmPfbK74M48rDm1wWUKz76uk/fGjMtszv2LKYzUlf76fNzGDjmVY5nPrqgAAbGth a2JtLGhlAFN6xwBAcmtmd3cQLnV3aDsoC1MpKGsCHHlxTmXCdClqcwVfYWxnstYAtGArTkN7 AFRKWEZcSAZidXB3ehg5XFhUU3ECd296XFdjGesGhQZWbnB6GJ1cIFhj4uRHRbDaLyAGSFRU UC+zjIhBSGS6NNKtA04DoPRAQMDT7RMeugNgzmEBrCjrOiC8SD8AELOErz4QzoHzAa/OEPOC vALr8xDzIAMVVVzA5counQIHnAU9wAvRAB1zCwTzlryN8wjzjryP7zuQzpHzkryT70RyWQfn AwqejIndowwbEKFBBZMZNaRHApokGfDQP/h3sQcJ58yeCnmoEOd8nhF5TBIae3kHE+P8do8Y PMQZ85zPGjxkG/Mszxw8BHjx9HXHeZ7keXrU5Py7i3I//9NHxQ/4A+CfAQIEdAik4IFggnmC XyG2HabfhQChpeAHgZ/gdPwdQH6Al6gvBsGj2qP1jw+B/odA/sW1ry/PQc+2Bc+i5KKA5+Wi 6KJbtTVuX7B+of7oUXAFUdo4XtpfDtpq2jK40w7Y3uD5FjF+OW1A3egAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAg AACADgAAAJAAAIAAAAAAAAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAAAAAAAAAAAAAA AAAAAQAHBAAAWAAAANiwHAAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEABwQAAIAAAAAA shwA6AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAANAAAICoAACAAAAAAAAAAAAAAAAAAAAB AAcEAADAAAAA6LQcACIAAAAAAAAAAAAAAAEAMAAAAAAAKAAAABAAAAAgAAAAAQAEAAAAAADA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAAwMDA AAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAIiIiAAAAAAIh3d3eIAAAHj//4iHcAAA ePeP//94AAB4/////3gAAHj3d3j/eAAAeP////94AAB493d4/3gAAHj/////eAAAePd3j/94 AAB4/////3gAAHj/////eAAAeH9/f394AACHc4eHh4AAAAezO3t3gAAAAAAAAIAAAPA/AADg BwAAwAcAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADABwAA4AcA AP/fAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAA gAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA//// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAeI gACAAAAAAAAAAAAAAAAH//d4iIiIAAAAAAAAAAAAd///////d3iIgAAAAAAAAHf4iIj///// /4cAAAAAAAB///////////+HAAAAAAAAf/iIiP//////hwAAAAAAAH///////////4cAAAAA AAB///////////+HAAAAAAAAf///////////hwAAAAAAAH/3f////////4cAAAAAAAB/94iI iIh3//+HAAAAAAAAf//////3d4//hwAAAAAAAH/4iIiId////4cAAAAAAAB/////93eIh/+H AAAAAAAAf/iIiHd/////hwAAAAAAAH////93eIiP/4cAAAAAAAB///////////+HAAAAAAAA f///////////hwAAAAAAAH/3d////////4cAAAAAAAB/93iIf/////+HAAAAAAAAf/f///// ////hwAAAAAAAH/4iIj//////4cAAAAAAAB///////////+HAAAAAAAAf4f3f/f/////hwAA AAAAAHeDeDf4j4P4j4cAAAAAAAB4g4iIiDdzd4iAAAAAAAAAA7uLuIg4c4iIAAAAAAAAAABw B3B7Bzd7MAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////f////h3///4AD//8AAB//AAA P/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8 AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAH/+AAD//2SB//////8AAAEAAgAQ EBAAAQAEACgBAAABACAgEAABAAQA6AIAAAIAU7UcAGO1HAB1tRwAhbUcAAAAAAAKtRwAAAAA AP////9GtRwACrUcAAAAAAAAAAAAAAAAAAAAAAAAAAAAa2VybmVsMzIuZGxsAAAATG9hZExp YnJhcnlBAAAAAEdldFByb2NBZGRyZXNzAAAAAFZpcnR1YWxBbGxvYwAAAABWaXJ0dWFsRnJl ZQAAav2/FB2ooY1eD7e3GXOxSS2kJvYAdCKD6AR0F7AEDXQIDEh0AzBouAShnAjhSAFgHIt0 JHo6fDwoPFwfLPxAGzPJhdt0ARCygAPfpLHQ6GbBRXP2O/vQfFMHVVcz20Mw7YvDjfgd4dnr 4N/oUEkd8f5ccD0/A8e/76g6DwPiX11bK8G4CYvFMeg0Iesc8OAIPqxAMygZi7E9AesPDoPZ /wWBB0AIVov3K/AO86ReQSDrlQLSdQcFihZGEnXDH4LG6O7/AngT7ufBD3LywytTn4kHCBxh whAFSDK2QKMEXz6FPAEKOLUcMw4JAYcIbgiGGLgPGHmkIGgECDSblEmCkANRcSApFFACHXCA +WDFCFgQNxCKBGZ2D4UQiPNQKDwRBgGIAFNRUldWVeigHl2BGO0wEUCNtWAlDYtG/IMowATb 8FZhCBYcA8LjuImNj1ASGCCkDUOTIyQQl8goxJsj3vhzRIUG9nQOuSu1PwPyHXtAUvodJ/m4 jbCfP1HoJquh8U4str6ExBRqQGiYj1EcAf8SiYWLgkNW6NcDDAzfQgQQywKKYjOANIXJD4SJ o1XZCFGIKj4FAIXAdHuLlTFvF++Nc7ENRHUIiNBnEwPrLffBAVeAdB5SgeEkiX8MUY2FIzFQ xA48GEL/lX2FJh0CvAgDyEHDUog/0RJUeWrKHrsWWiKmlXmGGAEQRcMCvIAMK7VJiwad2X6a x/swFQwOXV5fDlpZW8MUAayizXe7CQNDgSIJbUV5ABxFbnR8cg0gUG9pENlO2z0IRj11OGQP VGhlx3By92Nvf7tvFJUkIXCPJXPsY0Zsf2T5m1tiONZKeWHfTvc47vtry3nH923GYy7MIGsL Yn5y2XVoLlNSb/NkGy5hbCC9bkSPWy9uLl0KjLqamAk04gB1c2VyMzIuZHFs4E318+lhZ/xC bzh4QT130cUTtWY3FGtAjmpsI2BFeGl0UlDeblQKr0pYVYsO7IPE/MlThafoAQ9bgevWkj2L HOPADgPLUf+TmZYkAoU6iUWA+1YEA0jTf4/7TAInGm9SDmnDA8Z1/HFMjAAUq1qDwgTr4OrG GAyLBiB1u3Qz+gU1uP8DA6lbXclCNm/eWH3GRwT+X+w7H8N0REl3OKHPPQPz5NMrB9iJXfyt jt8d2nOlKsjIg+lMCHN5Me1mKPiBYO8Pmpt8+x3B6Awfg/zcESiLlxwBB0l8iuHrzGNaDWAO +QhieYSpFBII3DxEqlNDdoPDSOC3QwxcqeWHdRB7E9G7b/XJAPho6wt+UYszEFUIU7hq9fsB UFsOO899TULSPIDsEoD8JTN0BQoV1oY5xga5wYXr5Dzoh4hB6XUpMJIBHlc4+AcY6wh9F+nY 6Q5Xp85hwBCGxHDwicwkX2IFg5nrs+7gza9beFkyGFFQO8O3Ab5LDoPsAmZ0KuhwFoBfWaCc EEnEyOlckjddntVJYJU7ZqhNyfgMkRoXBx8PgYkI6/Rhkz4MbfpOAIgVJl8ZkQ2Lc2dvcBc3 YoJIBE4XR8yIAUwOEIQRQOmkUBPyOgMzLL2FZkt+ccEL+QLzpQPWg+Gl1HjYnPr+e1cEHNDo EmldV+soBDRBFoOY9yt3MKr+kMdKV7DHKVZSXUsIWqdGUZFoiRa3SAaoKwlW/9BaiAxkSG9I Z3qCKOuxRTkROvUqDhO3FnEOdFlO83co4AKMxe5zBC3kIQIf5mr0rjQxh9TFqnWDUL/xuRGG 4q1agEjrUUuw/3A5RhD0BOoGLHQsHU7OAyxDdk64xsuDfgY9/yGQcQJQV1FT6BmppwzdIgeY MRkU68luXpyQCCyw8VPeHCKGFwlFDImDS6NkXBBzS4sZuf+58qzSurLdf4+F9iFzVRT10ukC 9dZhb5UN8kSIypXHOUERM98USVJKialE4lAK8IFK4kXj6wtYyxoDU5A5KsICPxJYLQmCuFLk CEeQBxFaiQYlAtQLFsILDpuvBctauAZdW4NHyAH/mABgi3QkJIt8JCiLRCQs/DPbsoA5GHRC pLMC6G0AAABz9jPJ6GQAAABzHDPA6FsAAABzI7MCQbAQ6E8AAAASwHP3dT+q69ToTQAAACvL dRDoQgAAAOsorNHodE0TyesckUjB4Ais6CwAAAA9AH0AAHMKgPwFcwaD+H93AkFBlYvFswFW i/cr8POkXuuOAtJ1BYoWRhLSwzPJQeju////E8no5////3Lywyt8JCiJfCQcYcIQAL+1HABb CQAARAEAAGO7HAAStRwAFrUcAAAAQAC406tc8I2IghAAEIlBAYtUJASLUgzGAumDwgUryolK /DPAw7h4VjQSZI8FAAAAAIPEBFVTUVdSVo2YQxAAEItTGIvoakBoABAAAP9zBGoAi0sQA8qL Af/Qi/hQizOLUxgD8otLDAPKjYUdEQAQ/3MEjwBqAFBXVv/RWANDCIv4i1MYi/CLRvyDwAQr 8IlWCItLEIlOJItLFFGJTij/14mFIREAEIvwWQNLGGgAgAAAagBX/xGLxl5aX1lbXf/gAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQ SwECFAAKAAAAAABiZwsxjUtP9wBWAAAAVgAAkwAAAAAAAAAAACAAAAAAAAAAUGFydC0yLnR4 dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAuZXhlUEsFBgAAAAABAAEAwQAAALFWAAAAAA== ------=_NextPart_000_0010_0000078A.00005BAB-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 12 23:17:39 2004 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 XAA27856 for ; Thu, 12 Aug 2004 23:17:38 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00E46DD4@cherry.ease.lsoft.com>; Thu, 12 Aug 2004 23:17:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 30501944 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Aug 2004 23:17:31 -0400 Received: from 68.239.40.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 12 Aug 2004 23:07:23 -0400 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="QzihnfFIlQfqLPZQjqzWvFUQ" Message-ID: <4338be26.3efcbe68@bzws401> Date: Thu, 12 Aug 2004 23:07:20 -0500 Reply-To: Mailing List Sender: Mailing List From: "Kathy Y. Lee" Subject: Hello To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --QzihnfFIlQfqLPZQjqzWvFUQ Content-Type: text/plain --QzihnfFIlQfqLPZQjqzWvFUQ Content-Type: application/x-zip-compressed; name="DivXPlayerInstaller.zip" Content-Disposition: attachment; filename="DivXPlayerInstaller.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAAAAAAAjTTDoAIAAAACAAACxAAAARGl2WFBsYXllckluc3RhbGxlci50eHQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuc2NyTVqQAAMAAAAEAAAA//8AALgAAAAA AAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyAAAAA4fug4AtAnNIbgBTM0h VGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAABDHnnBB38X kgd/F5IHfxeSB38WkhF/F5JlYASSAH8XkgFcHJIFfxeSwHkRkgZ/F5JSaWNoB38XkgAAAAAAAAAA AAAAAAAAAABQRQAATAEDAIn3/kAAAAAAAAAAAOAADwELAQYAAIAAAAAQAAAAkAAAcBQBAACgAAAA IAEAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAAwAQAAEAAAAAAAAAIAAAAAABAAABAAAAAA EAAAEAAAAAAAABAAAAAAAAAAAAAAAKQjAQDcAAAAACABAKQDAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFVQWDAAAAAAAJAAAAAQAAAAAAAAAAQAAAAAAAAA AAAAAAAAAIAAAOBVUFgxAAAAAACAAAAAoAAAAHYAAAAEAAAAAAAAAAAAAAAAAABAAADgLnJzcmMA AAAAEAAAACABAAAGAAAAegAAAAAAAAAAAAAAAAAAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMS4y NABVUFghDAkCCfuUAVfUcN9EAvMAAGN0AAAA0AAAJgAAU2////+B7HAFAABWV2hkMEAAagFoAQAf AP8VSCAMhcAPT7Zj24W/DgAZUFAUTISqtlv3N41EJAhQaDQZaAwAgBwE32zbR3UYi0wYUQ4AXzPA XoHrum+/xF7CEDCUJGwCTAQ8Uh/pnmxlIBKEMDALjGT3210ZUFHoBAHsg8QML3AD19ysO2qSHDGg pi43g2zndAOVGBSLDYT3u39zS3aFyX4TipCIC0D20oiQhwjYdg57O8F87XAsp2htfa9rD1QkZFUB AgXSQA25fdOkFIvwg/7/XbYAbrav2/kManloXlYkEFaL+N0z3dmIDCqLT0AkHTv7I4X2dHpoGC0s rXRquddtz8DJv9AUKNoxsx2a2590BO5/cRdcdbtvbrkRTtGNfCQsp/OrtxBdKyzcKyBRUpJqggA0 lPyauzXHlkBEKhQKdICGj2TBhTCQkIu4nSy4C/NQAim0RAc9W+OvHxDDU1UHtEC0bYTfro0Riz2C i6w2iTmj4Xf/FI0cQDPSuRpc9/GDwmFSpWAiYTts5nzv10klHJ27QnOyXAE8gxw7GHR7b5qGdBVI OMZEBESokrDv/kc+fQAudQFFOkhVUIvDYU/3LJyLlBMCcGJWGGx3T7ZWVjR0D84QQENhGm9f190Q fLYOGNdQHnwQGnwOQ3f7dhEUQLrpRAItOlgTLhts915duKAAW/iQAAAfigpKUlVORP////9MTDMy LkVYRSAlcyxfbWFpblJEAERsbFJlZ2lzdGVyU///tmwCdgAAZGxsAGV4ZQBDTFNJRFx7l////zI3 MTZBNjBFLTNCMzktMTFEOC04MUFCLTQ1NXd59/IzNTQwMX0ANyBtdXQxIAt317a3YlwlYwQuAgtj Ki5TZbf97QC+ArKlb//8/wD7AwAAu6vk2Uf/AL//JwTx4P//y/9F8f9L9jLeR/6zq5eWjN+PjZCY jZ6S35yekZH7/+3/kIvfnZrfjYqR35YCu7Cs35KQm5rR8vL120Pdl/0HhqsXjsLKed0DeN2qB6A3 j3zz1WrdycTpc93Act3iPep9HmHn3d3DL62WnJebr7pvk71ds/7VBgkByh+t3vT+645ttvkMfRf7 E7tzBO8Jb8IXuV///wv9DwDMJftmBx/6DB40bIMN7O8HBlEgwO0gWdgDWjyHb09rhsLOw/gCX/4e gm3+CtGLmoeLBX+Q+bcL++v7I9+rn9GNm56Lnl1Id5j77Sd5v5rlLdYC0SYnOzf7P+XbtylpZz9P mpOQnNtLU9JskfQn8029jYcCsv8AdD58Du1+8/98n/v/PHzG/4v6FtI8qXQOfMENF+D5/8vfMQCL 2/cXNv56P6Z2+Yr6lf6nFPl8mfHbrn3MP6E9BSt0+RqL9a8XgD7Wbd/3fNn/pqFAqDXvA84XnPx/ 7P/vZgd8O/N/gPv9ityV5xdRvU2L9HQ3F+nsd/93WXQPFP3MCah0MRcTcBTele8XdCLtdyAHfv82 DTmge//b/rf3Bu50vvvEvfuD+4sUbvtyr/52rrnfubb7ioTynHT+dL/zPOPBvrTR4DjmXhE4v/f8 4mX7l90X690Ju/6L+KkXccFXpnz7Z3PSKf50tvt6NhmuFyP+1mhuzDBMVfnZA66sndv3JPlbMEq8 DbMPSx258ysk+HMF7i1xTcbsO9ZFzt4fGYtEdhG/bvK9O3G+bVe8ufeUnMBee3Qxwp8MMslX5t2V 4xfpQ17C1L5fWcWV/5fk+98ugrgtQcUjiul6CYvxDs1wtrKZw2eZ+kVb+w2HF0jsqnQTfBPvVDbq bNvb209aPHKyD0x0uvcPrk6v/i+4bjEXNA39636CDzBS7QGKqF7+5d8ICzoCi5CK5weZHC7uiroD ZbGQp/vdeIrD6hTdIDnS/lk45NvkAfOpAMkXn7C53+7TCCfkwwgvptw5vZM2fMOdwxatr9l08bzf qBdOxG9EfqEM93TCS1obACimMTv8uqkDoMN8Nw4zAPZ/i9kNdbn7qHs/8Hp7/zhyyYC1EArz68kl l1zn498ll1xy29e/wJZ+ybu3FOfDMt+HDQ0pG/PLhq52fPt/e8OaA7Spi8B0LS2LxnSK88SP+4LO 34W3G36D0nS38xT6fAZS3gCK4Z/+C0sKrqwDrgDLT60XyYa6A78guA2nds8HTlOuqXDr6/ZyugeV a5cbDIoLBPyQp3vsz4uV/RQdAzvGuwdkIv4Ux0s+H/2vGlxzb26MrooHds4WLI3tZd8I+xfe/y/7 FL6Bv2bula2LY/wjIIdre+s/YtusdKL3WXSC83IjRTW2w36vqKwXj2yK6bp0Wqetu9OB8mAbGDQ3 cTxv/9+BfDjnp8e6Ena684O1NguV88a3LwuTwkn7g8l0sW6qC9vY6La3LfNydqt8cP9LyvZkGQeA 8EFGAP241d5n84FJlH+kNj4UCX7py4+b43S656zMJMwARXwf/sairKvQFkeivjjvs/z7p1sbDwki F51suu93ofuB22T7gmt2ofcUIucHrJuP3Uow9RfBIwN0su85v7CZ7QI1dv67G4/ze9gx+WOG/aYs /nYXPy75OjcI6K8idU/fbhsR2gYMG++LdbHHAMc5uu7bohGd5/B5hhmVWg8NuxC7tRALJ2LGnH6/ rxXc1jZdD3LwSR9J59Fvy7vYSiNifAfxgJEG94C+295u/YvIt4vYfAiL5Afvt7cg7FEY+Xupcg4W Gf8H8xYhxx77besJ+AbDV3bnoBYzE+8WPZ/NzeYHO/W3i/Ao/+MWHnnksVUHtxZd5xZl3xZttu3t x3zkgM6L1Tbti+E16QLxeXtk2wr5OmO/FI0E1xSS9K1jedsUl9Odbga7FKPS7bbZPgyL56vyio3h C3aTv7Dw2BSVB8MUnWcL0HaxyxTK29uydYnWJeGCWLeKthgDfPqwfyO+6xTBCu8UzCY/88MXxkoD B/fwxDyL4Hn44Q07RaivLBFy+36oF9v+jYWv+WXryRZ8V/s/YCgulOd4c3gFQnvj1Mvq1Gvr/aZ3 YMfW2tYHh3SX4hn1WUOH/8Tmaet8OfevqdFQAjFOjoaZfHbTralhralWqIbewUONYcBAsn14Aqxt 3/ghWYq48ECJcrvH/hfJs5c2s3NTELKG+fw4Kc59mpGi6+L8B9oMaBtv4Ex0yUr7f9vBFDhzb4Fm zu8I6t3/4m57isFEySHp6g/rF6Uvl2gFu0rKxLrrgsbAHbT2/aeiPK4DUPN0s+Lt3a9lBxdpHsw2 xLsK8GM+jl23V5vIb+ustIq/p/iDS3dEcuP+dijIlaa5xFwwfTcogfp5rfoswP8GLWYsHanujveF G8z2rADIDEcaoBTSPCg329f+ikfvCP33FPjc91lb8emfWPw3rqBJtqOfheYvmUeifhOn/j3YZKKs N8FyeWLZXpsun7uvo3dh1wV7d2u+HPf+dmHX/eEH0/0NSzSXzNu9H1/+PN8gcWRrDZs/eft0mths 7kDxyAaxX/tdxfvfejcv4kYIUT++OX8vKf3v/gZ78+2yJv91/hyKF1+3AfLQJSL279/tNxE5fiP9 i+hGGHW+/r4WXvYjzS99ihFfqz8pJv/xc0hGqyb/cnozhTPb13mXma+0JxEN89tbokAHPbKvqBdh u8+71WYbjeYXtgPS8L5gpeYYYH8ZE0JZuc3eCzAkIj3BC2XuGLtD5btMF20HRauxVuQY8SUGQyVu V2yXYEATdnoXuy177Qq3xgempqwffuqYj2ytd3MRvKYXuEqFJw+MNXIbZx8yNC0PBu9mqfpbrJcr FdBopmu4LUYUcC2zcN46YgNlL5c3lkMYN2c6pQkVkk689fh8bzeL1FcSp9EJ8Ol+S6312NtEN0Ib x+C3NQeFKg0ilC8b+9LhJcgHfjhGvAf2gx0OrG3kYAMxh3G0oBw79uzKuHG87jL1BgafNKMnIwN2 GefH4W640cqsg+IbjHTSFwW9Yff4hnR5ZYHtlaksl+/Yzn7+0XNJeQAqdHlyQdMh8dZrbUDIHSWW WR1E3mIYoaKkm3S87cHjBnJ42WEeI26gOfhLTnT8xPiMzWgIfhu+1P8hD5YJdzr8SEN6afRSAwc2 Mwa23sRxm2F34wIXv3YxjS5ZQ4e+1M4yjD3Sm+uV3abOvp7tFwxaGQD8vx55YBuVBnusdvigQS0v vWNvuonddGh8QVvX98ZxW/zvY3HdvX45hsQvjRsuBrKAKsJsiS1TrFQwupXra/mXKKlOTBbNCdcr RMwVEmR4NzHpbf54oRQxzpDG4Yn8UaQCV43X/DyvY//oLBw7/uy4fjxqwUb4q9iNI8o0OJY/BXkm 31t8FBV2JnJ8v6+9bfanosT8jOQlZUwma63xtuSDeZXf/JP/Ri9Ro0kmh6SpyFd4rq25lbtOqIOD 5qls87IRzd0Eh1vuCjh/DuMXa/cU1tWLJkXw+zz2UoPJ75o8NZY2vFvo+zNx1Dd+Fg216HcH7Dt8 4a786RdHzjA2yl4vzQiFZr/vfAT+tq0mCrdeBE32BPv6cEKXU+H+4MBvB8AmeaxRZU0R8xfSBXPL 0owEXj8kZgiIbNGilUr/N/zu3T+MCfB7KiR/2f+5HKmvdDAX1RxmtgdbF0ITG6MPz556VlB0yrFy uPEOgx2pKeF7b2l4K55MxsEVi4Hh737A27uxC/uN+z8UqkZYGWzwcYQCKfL6LcRZGstwN1qRo3TI HPrNRexX5uLO21TJvIccmO6hr2E2OHD8Ctp0APhmTTANiWGYmAs/+ytMR0NyDhfxSnQHF/sd8Jdw CVymfADBpomy0qwFXHth8SaSPKMKzhVgr7JnFJ5gK/AnYu+XLyjjgp21CjRhc4E9hCvdGLdfr++o oknP0eNYVAtbtHYKdCdwesSIwZ1Y+NDwcA96ACVr2DW+LUqvcHQIm6F7KLsLzUH5Zi9aMIgO2yDd bbv7/AESM5vVor9EsvfECIznKBVKehKLtXR9x679F7kUGwC7RYDnfO/9dASDUY3oC7z5cov8OwFy oQGG/39Atutg+PqwxASME9QIfAH9g/V/nE44wMDRZCmix35i5Eh8e//KxqiVwE3Yatj8Qxc4pf7a zpUzW/ojFe4FPkbiwZXRuvHnNn8wFDpsl/M+2wbW28THCJB8wj8A/0QFtEGWXqmTPfYrBRq3+oqw fDz7BIoYnPBu5gymgzuBaAtl/bobWjODxsKbPEEEi+PyZcMKNxxE9Xw5GCqw1cFtdvkv7Wt2Ovre xg7vXTFZal9wqFgDqHD6O2j2cMQ+i+t3978YuR5Mzb0dixT1J3/IcNgXd/Ac6C+uf4a/eO7GSxO+ v4sYl+PiT5CzdzPIoBTtl+sT82T4x+HzUnyzf5oLU1+AhTYx93bpxDKKC42pfUfJARvcckvED4m8 wcEbG5TgG9qK5Lmcx4WldsV0Jl/+Qyf8Sj4Wv7UYVti5uX9EnYrxsbDh7HcO4kZ34Yw+FPYW/czi 0I9txl6KyO2pVqjUMDk8J4ZTtAGX9C8Kr5es2MG3Y6bEOY4LcoJPg4iTeke7O39yt/6f1A+2xAaM qsTHs5lllebbMbVKJXPxcbIckx1dobbbOP1NsbEI4Z4mhOsumP824LifsT6R33vfmMSy84lQpByk ugNhybfr5n/YX0+vqsG7RIAzDu+M7y1bTCgsKgc/PkOjX63CxvgAxnY44Hap2xvb/3KI/tQgdbkA w79cdjkU5cOvlLb1/01mgZl/wcuKnn+B/s+KpDn95HOLroEJC5Svdg8B2ca68LkBqGGkAYLGGw+z E8A8jwDaMxybBRup400DGz45rbXbclsE/uC0uUiQowy7GeLweYjPrQegv0eXNk7ovahF/KiOKuCc gWhUwgC5McLZpt9FuKTjX3fDdKOsfEb/ZpGM+QzohVKlmI6J96iuZppo2jQlT6l004vAbb3M7810 J4heQ5bYIA+Ng5Rx42wOlxHbtPOunqhV4pGEwGKhbLPykOWz/Ywqw7Nhts7l5dhH288mcGU2Fcf9 NcQMw4X4rxa1iTU2t9S9xX9CGyjR7fAUNRsMPrl0uksCF0LR0szcUmwJTq7qrh1j9AkaTL4WUhDz PNb1DdgAy3r3Pk7DBheO1NV2B3taURecDdQ8bkXshT4Dgb5Ocnv6GEt2+5cxitQAufPGSYruYzas 4Epu2egDEHMSyWGA7awTkOJHM53As3/7jXeKz5X2Y5fb6B/mXgEmrzysUzojWjUDy8Z7xC381mHC U490sfv88aSJOLb99SoX7wCJ90LLG3b5RhZMQUQrWM/wiMRYpKMQ19sFw+FVTZyHT98HRsBtVxt+ 4SguqPVgt9gKuf4L5HX5O9Za29ivd7t1EwW2CBRgc4FYCc4U/IXxOiwMtyjbTpoMEmOReXUHHBng Dw+df0Eup8LGCf0Gi6wtrF4jbjq367bh2QqoCxe8CS3UKBYt3qF6JIm9tQvbW9yJD3VbCS53Vr+I jV8wKL8VJxbYEg4lPE3iNaTgfMI29aM3AslLZXKyKyvEwi132i0S0p4DtPekD8dgkRfN7yvexuBS YTH3rzQEv57FN9qOeP8II6l/o9G73olBu7LSCA56LYqYta32chYfDMEXKqDsaLxYC4muXA2zAPjd Wlvi1o3BDXvyDr51FLb2lyXEMQktd+/Hry9N9fFuS4owBzOvLDp2adezcG6ljPK7/CHNDN/GrcRQ jVAPpI0OH9x8ky5lDxEgdDyg0lIMFgGzf6lB2egWzK+Kl9J/BfvOJRoaimEHRgfAFugQBvPS4ctw Z0+dbL//JukbYIRKlXVySakQzNiQTSL3WdmWDvDr+bTAE25DRtpImGxy/K6oXsv8+re61RMCaGTA fKbqh0A1fVvXMrEVVV0LN3I5mr7ZofgvNgYkZ2AdDIQNrw8Yrr3L3K82cXo3a02487lhbmhje10H bbYzNmCKqB3jh2yYowUxP0TjPWFmyNwqQI89GRBeyOa7ryEP4AAvNpUIzayhHp9efj5eO64vcMHh lDhIUt3d0WopdoMCcnK/BRfd3LNHk6gTfdYUXQ7WmcKB7w4a2xbUuaHe3lafl0TVJ5sAysibdtpx Nnf3ercjdnqfBQurHCPbzocCv58IE5upt922NrcXqvgOF78MFwarHeMOa/B8WuoXlNxgtAOYeBP8 N5Ffj23OjWyll1JiwCibYu21zQ4/6mAIQgY+9ug6sb9NB7l+jNB8Qq2v6/4Yu4zZd/wZcg51VFdi 9koTTxTo29Hts+39FAFOLv+J5HGV/eC3BYvxeDjD+JsM/7XoZ8Lem3BLivueFPB0BiFghZtcEDM/ wsEMZgpKkXcqYXgYkazyg3lactwOl+aQ9Rc2BhgUTgbrrYVkpMjtwQfq+07bSyS1Z98ZrxqvrABG NPudpCzHYhuL8SPnJrmt6z/2B62CP6qx+IPSegmok4VuFHBRZ2SB+MsAmdl4ajeDqPm3EjEwXIqy F9R+fJBne6K3Htcs/wC9VWRks/9XFwLb4KgCgy3lTi/W/vArngV+BtKC+XaDFDj7g4KjcBkSrnK7 Ll5qtVY/ijz7l9zTv6DZmnevyb92gqGmkvmJZ7iz+4xyuh/+UEP86VM7xB8Xcc2HH+XePbFGi7Am L5X6QWsc4DS3b4mCPwxap0sEfwPurTkKn3esmVqxtGusw9cHj0F6vam3sM3eJkuTwP2vPDH8waRB uqV7O2PvbCXbG6m/dShAOzu2XACuFAZ186sdQmdAAyWsrQ71lWikC61LXQOyveiFT4rc53D7sLPB yMMbcAd3NjBH7RtxZVYTNgd8v1UUV0Yo9dq33GYzfMLzkoXbl9NLA9d4pbxQIBVOmW4DU3hdoViv uhMtgxEHs4wT6w8MQGus1xizdjXXRNyrEhtvl+jLd0vmFRKooGIOB6PQIJ87RyPaKOyZW2hSEAuo KJfuGK3tvTAH+nfsXi8pAWNnYZYHMH84BeuC21xwr+aV1GJHDz6XYjPbQ2PHUkOGgTfO9rBuLEMC YgDPyMNFR8Hd2IqOD/AsdNa2yPYQE7q/Cid4DRONtm5CJw4jhFj5bm9svKwVu7yjCv+eI6768xzv 2BMTjOOXazE6YRbxZbsqS1fLC5LVFCIPFPsP9umhbypD8HOT7tkenxUz3AadHhaIi7T7Pe7ZY5vS LAsOF8oIB5+y/S6XIgm9w1M7jtAuOZN7NQYuJzF2ZgTmZZ0TUZv9JMtk9OYm1OZfPWoNIP0Q08lG pxfT/8IzRgZ5yGMF3F/lzAqdjfEzOCMTaPdCFTQXdysUvYELHRi5R6OY1XavMBXgFepTp9wXrFh9 8fI/rxJosJGlJ4Hroah+Rg/LLzWoLcw/oaAOdz5N98v8cvO1FoNWRNrrW6gV3nzuJ8bKT3irP8x2 uncfJJcXYStZMzDZ1dt0vhRsGgk3PgVo5bf/XjmMjp1mQS8CyQNi2Ow9e34XOB7zPGySvphYLwKX t79gaRSsd0NIvKCoHieXXrgTvB+PZQ1U2bNd5FgU26hWlzsgeqGZsqbluLilgUdHZ8OEbw7z/rnc U3dFB1kXQSHR9hMF07QpB3jhY/zWeDaJyQsB+w+Vo+zvOCy43/v7d+cU+XdiKbpcIxdRSk2HnXy7 qPwLvSDDqqwN7P1bvdF03wyLuQrzxDSLznS+1HdT3cP7g9aF23S2E+ItsMShYZ1Z89NytxG58FWu flrevqA73VioRkogBzFcFFRMTgLzbfOm95x4CUz4iBcXIqMSP1VDgfxy9oz1rHwHwPV/5z4MtiMm Tnbvwbb+7g9tIQ4liHwHFhCfAukqFgvCIu91N+aos4BT82EJQQHGthtwC/cma/GmDaqK9kCAdKff oggtfKulidcVi5CVw14ouhtlof7xCTTBqQwnrbh9WSSq1Dm3J4GxfAg7utCD/KCnr/FPqXSmI7Qg 0NJPlb4H1p4URuQUlE3rgKXJ3BRPJiCshRUExPpBtf3wcacAHtcKDboz+XRTOCjZn8E95HkietAh QRVCAOYklSM1v/71fL19rZUVTNP9vKtMoUY0HC44Ngmz9LBaDp8UEE3bVy+4zsL2JA9nxfDeNir1 C1+XdZ8HEBvf//FgE30X7ym0cpxIXZw61gAiqEiajFx6itlEPwEDIyMbLkTYEz+xpNtGlA+7ANqK Pi7JhJw0LTs7PbCRDD9UBhAMeLchLd52RPJ2B3LI4vtjrszTjic4IPf68CYpeAdshxfASChizC0I Ce9Gi16sib0Uop+9/g/E225CXn6tdhMXpRdZrpo9NOkV0iNAW9h8ipEAzMYOjX+FuDXCqMbN3pWZ oodbi0ertkjdQkf+j0hh2lUbfBn8AMtK26hR7jnwGlXE5GoWEKERERakQ8r13eNJmWy8WeSHADqQ dxkF62bPWBxer18jnDpgyyAWOwj7s8IpXlG8nG+54EzdAwkbyJFOg8M6cTtxFhaXyWLU02lpo04j zyRVVZUX0CjBuNAfaK9GIjFplVEw1IYJwrh2dvXZdC13QgX//mmlk64zTcYDBgRozw/0umAOTp83 d3E5mWSyuWOQzQVksGMRhoj7SuNyyEuO6gT/28hzQE4Y/yX/92SSRzLzNf9PayCHnCb/Y3ABRzLY R/t9HeTsIAeBk0Nqi6PZtm3XP52biqyG7wLzK6mQHKwZ879OAzsdcjLJzOK58twerYKOA+AYg9OL hsEIEaZoVoxwY4UPABknM4DBevWVmy0etG1gqM3j9kH/xY6p9gacW7EbCdEXA+g2qq6WI0GbTRMH b8jVgOS5p3ZCExuNenWDVnIX3xGw1YG/eggXVKfquaFm/0h1mqVYgJn7v6gXchcVqGsOeRMawMGF Wri4qI38AQ7JBSB2iwNRckJ2rvS/zn2vpy4m5zLsdfjD9YuOWqFbET+57C9tfStIwYMnOdLyiv6x 1tt4n7J3Y8oGgBu1bMB5IvamjSYY6hNYUCK3hPO8I/I3aKvt86l6qRdyGUy4CEwuAgEKbyX3Ecf5 2bdRkjRBCm4V+j6Vs2ag5YC+/IWbgsGDBws5pnYa2w3U4IHHrEARs4H8J6SJG8ANgKz8OcFo6Uaz OTagBIm7IA53oG93ODNguPwMyA+DNaTXATjQSV9kVHAifgW3i7+4mhgpGojA/PNq+dsa4Jc6w+d+ AD98uA2oirssVWrn5DTvF9BYuP1dEBn+x7j+wXTxKvPmv62+i3N07zn90WBFNMQ1M/C/24LTE4HC HcPmxAWDRAc0FXqpWw6vvu+y777mI3jkoPjZGh2PXb675gD5GqzwSevmqu8dFB+K7cUwtP0WdzeW hxDNJQpmfHNdwgPRTtyY8HBoh05dqMf/N1X3f8PHP436v3b5FPG5vkA322zXX135f6x1y8fdfrfh HHOZscd8P/j0NQ11w7Xt/+4TEevH9CyZfAbwpIrPGvwSK9XNjEziGvvHmlHPTm7dlai0LAHuZBQR Ea1F4fBINR9SKh7EDXY//n/yp6CJSo5zMPDP9XcbJlwsOX/YKZ9l12w328QhCjR/xP8IPZVjQ5Eu UC/6CesFm7u1t+4PqhbKfSuZOBrxFyUPcm/bhkP9AZkTLRc5DRoyWwx5QH7gL/vCbQpGF1gY1qAU MrI5ut96LGUFKykyMjIyKCcmJXZLHTEkMYIaIwemOc62RYyeQfMILg36OdkGLSoMVKGZG0Q23JXR paE3twD9Dfct8rYtwf4nFPp0INTsR5+pJChJuW1yewuhGpFb5Bbsmr4O00JuesJETPbF3ahWdzp/ g8dCqX9bssMW4iy59gm5CLqzQWqVdjlQ8BgucOrBRrkR/rmpksW/OiwMqyTHCRaw/c8UD34Llws4 nyD3ifPAjNeG79ZH/ySImRxLxoCvnmRJzmwNnrHICD5BKy24MBinVTMOf+gwaz5qFcw2dVJnXwvz NVgRKDsTKZI8zyQmBicw8m0cdb0bFCUJJ3C1jbLwEx9gT6iVA7rzhwq4LLlQmBl0DQJGNe2wbSsY mfHk0Bev28iNV1Wn1AN8C/sFzRYboTidR0Rbi2jA1dqcdU33hszJIQaDHz0yYbOvEUyG439CoIFw /Rn/i+F2LOnQuPW6WnITQ5WAeu2h5qLP/XOkXHS9WbpC/mqWAz4Z+Py5Qoasc3D09+8FmSAfbeFy CnlkcGXuaAR+uHIR72hB061BgEkHQvNyYPfHz+v9fFoDlTh6Cwa3OkDfLDmnXgdUn5cxwBxZ6JAN lft6/2LWbW4DE8XkDypDE6x1oCMF8nTSkgZN4thZDMQhgrN6QaxRnxM+H/gBR5zPNvZZh9fvSwNC AweJtwFcSgiuBf/AdkQjFlUUZm/sgf28fEL9jLpqAEvYhBwgX2bu6Qn0WcRsC9kUWhKR+GMDdEIU +xQlFCd2EnThC0ZB5+f8OgB/3g+MTMHuP4HruEcNIgV3rQ8wKXjigySrPFcYmvgS7cQ4jP09OBWf AhctDkktf5bwgmLVIzgULoAIsEBbpsbZSE3aGnjN9n/H/wtZQHq3RA1Qifhjf8d06zkh1eB0CBQK sYvvYwWohH/zhiq81rRVlQiVmYlzXoEJTNpW3pCIwytZRXJZi/heIEHRKah2x2OHMKsXPvEWgHZB MxZ6WHT36OcUzZVFiF0I8TbxxydwCcoX70fqcrdTfLzdQxcpKAR/WrfQRvopCrgPfbYNveazBIUe mVRV+u4P3YgLvSdAZzlFtOJRDnYIwO1K8SVdHHIbCojc/b6sFvD4bCtzwOKr8bw66/4nfjzfQP0a BzOvOI1iwX3NUTuDeiHiV3CIOLMl4dYmAA2GKUzxhILyEcw+AQxdKPaadBT1HZ2M9rTUCAtp5klh S9gCudtfdx8i/H448kcD1337+9+mckpuQJ8hFQxaXB8GQSEzjAC42FORGgwGJlMlce4aAqUX2wVm tSaVzEIUOMJ0iYOqd8AI5nsvT8vEBgvwcII7TBwvBEECr7t1gbuHxeOpZwMLEeRapWmK25m548rb H91ccmFOGJsWOQGE83xfuYoxy0l6SYrC82wnpOPB7CBHv/SdYwfB2Gc5k2gX0QORbeRG0CT6FokD pxYSuCse/G0SBHt5+/r57BVhR3CvOHrd+OYQO7cwEUFR/lSgCMXuWB1N/lfDb+xWzx6P/nILu/ro flgHHUHn1fdm6+0Av1L7f8IDTzQuBYr0RAK39ZuoWLMFF3NXAAo1qnpjl7+KFkSK5acbcu9h2N1c 8l9GIjdy4QXAqeMAVg/2FJgCCWEPBkUu2HMDr4/W797MjOBjN2noC5dbObaZMDzG+s9sy8+2wlC0 y30NHw64iaVNG1IX3PNWi24jaPf5ihAT0MXCnwYnACSLh7zq95aofAsx96EDbKx4C8MtTReYUOAX 8AU5tq332ilWuijzvpzhNRr1iCh0HILGABa+yizPoQXbVv9zI4swyKEhvtqQtovjcOi67UbNVsJ/ xsaDNg3UDYW792z9g3LZl6CL9eRrFJOzpjwOD2UK8p0LoQ8LBfUWkYcF0/xBF4D44AMVYgeEVXf7 J2Db7Wj695Gvrs4j2g63WpQ3a3AoRka4xNMbytQ3R2kdPgA3gKzURCFcU+epLo3mhhnfGgT1sWX5 cWSwFRXnGvUjJwLQplvx/upWE+7oifKDfIqCYLaQ8azB1ipmKn6sr5s1fAt3eBkncdhUEn6cjkG/ nu4TQmZGitzbJ8wIBhitF1IsQj82T+HL8Xv2+CSk6NwMmCASQ5wrA7MWidPvtRpzwiMBDRipOxdw +Z2ObugonBdJF64N+kr2oRRnOtT3zpo9XiRjT5IHMPLkWHcPyUyLKoNrEOBzXQNbfsQhAc8YOee7 GTCCWI5LQypOQQD7I2rxUWID79E/T7TF4UGenhdgxChBS7EJOGrNiPpIcKH8i+cavK78AYedxCeZ n/Ns7RevFLMDbxgXAveqc6zdjoxrz/rEZoNcphMGCXhg1408qvOFVzVRHa97NTVg1YbHTJf8ecdw X6deZFNaC31VZovk+ZEt06z6hYBuWQgh5Am5dZqsekB246mqGhTZAQeiEBTA5Qm3Jg6r/u3dKahm 1D0uB6/fUdw61QGEjguV+vEOKxoMSsojgy5cWEreINQIaRasxRYp/FBHRhJv0cmY/Or9gtYUf6JB j2Z3FCmV5WYG0f2Npmx8PZ6tl5/GrMKtSjRN3uTi3v0KcEh0Eyf//PiSaH8NwWKxihpvkbyf4MU4 Wah/XB7+1N0uOpy/A9z/DfpmwhP7+w6W6gU4iuyVcF/QHdh4uxWTplwUiHxHApeobCT7VovtStAC 9R6V/ZopzcUv8XWFRCT7AHQEco/7xa/iS8mK6X9Hm3JPgJl7X/74Ghc9W2Gg3W+Kh0Jhks5VDQwS opVh8/VXLLzpdqrzey2XwHJM2LLo7JMgqb8yYw9zLWVCNxeyNIrAeyz1LhT3rEn5ZWftZcP74HJ8 RrIxFV5LytYFf2/tlfW/er8OduoNcvutc8dYbt2jOnw1F6g/KKbZztauTCC/n16FYUvlwxppxJ3i Zs4am3Xe+U7cBoQdI4q2IecLZggfvoAjYpYt4j1krRSO3GIPRfyGXGorIPqGEPv+t5eXN04tDMUq lE6OIIKO9RFvbglT0vRn2orhhaDQLjSMimF1n7vaNVACJjT8Jzm5pgnR36254ry5jCm8rPh6iQyt 3A6D/ou5rRFbO0iLwR/za0ZW4OXm03+A2XSOPvupikcBnbfNbqmsUfcXtH2pTa3xFMy4uBV3/Ly4 UMQcH4Y6QZ0vVIXCcYT2CC+Kf4BMbdE/LtXvocQB9rYQ7vB9oPJX7gInzCyAN9Mb1D6g+2pTKRCu /vyR7djMPBY+FxTrzC/wSb79urHutiUZPhUpehQ9K/zkADnAKfv6QA6QA/n4A+QAOff2OUAOkPX0 80N25ADy1AEr8UCOHCDw/DGiA6hhPV18uKQ8sEdo+edhD8wpIL6wqSoUGlKhlMnLtm18zDZ2tyD3 BPMC9+sIV7Qs7+dgTL9y3DCXj3DUF+Yo7JVciYwLUwUVOowC5/zNhQ7rV7eFiIFwegio4jewj3Xr 4I3rdhMALIj4OLlV6tyv52aViBYTpgstbiWOn3axxRnEOP/x2nqqQyD+ckeNQK+aqnA0+x5n+7Ya +KjrFT8S86z+FHcZ4P/wZAgm5Da7RQXiRqX8rjFbPBiMsd+y+Yukvu+lcFG3i92h8x0oAoXKbBvj NnBoureqG6gAiQOKyZqheBb9o+KMjgbrmt8b+4vjqKgDMqcT62utEZRcFb3WBNzNtW7JBsEI4l2B 6+gKQ9QIgqapNRGTAMx8FFDaDa5iz76N13SxXeJtAtxx1D77TKj8PnSF4a626xeNGLmBQRGgAmjQ GUaqZtwCyhUt3GGQRo9KGa0bC2FGhsTq68nuXMCZl8Kyg18a9lCU6v2K6LQGyR/aNunOmwefIJk7 np6vA7m+iOnu1nYzIAOXERddb4Ebom5XAXyGZM2ffBe15RduCOu3c7eK3HS+/AR29VqunTIkOMfy xKxFOTb6gmEAPC5Wa+X320EmyzSYhgYzwI94k64V7tc8N/BQWeVzErXqUeFV8RlOmagPA8EwR3sN k0kcEABBmeSsGYuiVv8TiNuJGqtIlj21QglTtePa64kTl/i7Fe91/Xf+vr0wCKExdi9VL8rridl1 gax1l9rrBS0udQTLO48f7++/AbuZBRb9uTV8HvwMVaCkrFSIIGeg75Qb/SZKPxKL8nXvxe4Kv1uB aIi+pwy0AvbO9sYKyJ33A5gPQu1tosSq90Cai63qb4ApdfF39b25e3CbvfB9OQ4aoS5/3f/ZN1zY ZWd/RnsOd83A7iFFdfdD9sWbSbzdluG/FA5vA8beieod3O6ua0Ofqxv2vsQUjRQfyX6Ty1Nzbede CtBAr9nTXrADKZJv6rzBg410DxecOQmmgbgW6P9SAYG8xAyDwNQM/AhXis5wa9Vi8S2I0BTdVjdT 8dQ4v69APZEAt0AM2l3tUhdM1dFedEMTuIoz8PLe0wLQ3QgG8zzzA96239mG48N0L+O/5IoGdRWc 2263xD3Lx+sIzJXwFr/c1S4JJeReLdw9oas3XNSq09x1/nsRluW5sMX9pb69EP710HHDcaRzi8Ig 9/bS7QHmFvm5EL6D9wTz3S3xpYD8a98nvXwGEAYFda72Pt8Ag3u8+zoYpbanL0NH4Rf91W0Jjr03 OfivrkQEHmMST3V6bXv4yLh8AdIp+gfUphBvMdiNlxfGJPJkZHKj8I2m37kvFxQXA9KIiv0IJxl4 JIgg3v76i8L7a9vJcl2ca3oIz4P0Bm6HZ/rGgPu7jzXBnoPb5mvdZweFx9D6gfUEz08XwsqD9ige vqUlkxxgR5m5C28CaeJeqlU3uv0mgkE33DGWNli+Bz4H1q30Fh0/CHISPgVF7ZL70j2PL9oAgBl4 9D4RQPQPlvBWK4v5v9pkBCDWg1zw9vsrF7DA2kSOKjwUoFA7HTrzgYUmavPLoxE+G8SvK1T+DscM zDEALxVcS34Y+kR/BvCs2pysqI2HN64MHsFbEZlpiBVjxPjfEuN/t/AWo5Zot6aH63Xzz38GowAC bm9bBNBVt4YPfIL7MQJuOG+7z/51An5wx4cH3lkX7r6Zy0ixQDCM08uZUIINCEzIslWTiwWVHl45 vrnLzV4DArQB+oUGAPkXulvwW+dLNte0geOV6ZXnvC7FAnCpUUjwBIswl3jnhNfpslzUAwxLi1aw UG+jCUiIK4j66q4AIHAWiP0ioMruhVqqIehv6/8FbfU1ses2lGcDZQ1P/olNvxX/RWfTmcaI2ZCJ 5caM518+utGK6qls/XQA8Ei42a1gb0Q2poMZCbjNyrftcqJzxzBn0xc5BndtiB21OweHccfRiMEq mtsBmKUIv7BdgflOyq8SiMkTxAX+FwS5Ba+0/v2BvPttW3crIZK5AQr5kEMV/GtsG9URD40/A/lx Grm1lq79Hvu0MwyyOdN1XXOx+fEhPQM7EzeN7Ys29rnONSv1F/VlW7YbCDHxBS3tcnnTresMYwRx FzEpTulY65quAHUMJ+cD5YLftu6m49uV4QnhCNkF33S475YoRyzbFjDWzTaHGaJJu6avDRKuOfMb 8sYJuUAShde9KO7AFNg6Mnzk+3+Z1/8Q0QN+OcleB/GHLgt4O/BzMgFSqVpoP2y40wWxOWEtQ1Nx iNcySjE4m+DCCWOBVkiVrkEDpmKjKMwxX/tuuO/lldGAcyi7UgaWqQ+537Omg7xoxGA9gzdfrTXa VvDUYl8gaWbYfWtfmpn+uNsD2XJeEYAbZvvPcrjjcr10l0fPAE5XEFfLLyepbd3HxpXfGlT1Oxup C+nM14LRHazosS9uiPc0K1ULeXprfRAUmpfCD4+5renBkESZaj1KeJ8dmiJIHXJ7z+Q93lmBsWcA H/JyeywODktIt98Dr+GDUwPwv+P8JNFaiztiE4AUf9/wiK/ADzBRRNYp1OD2byxhLYS4pAgIdAX8 DIvUd6d7kIV3qvAK/T0IJeW6+W//LX8dH389nv0Xd+vnvMQgjSqhf9ty4aAVGtG3bC/dolZqxjLG 3wW+FAffNgFsB9LwvqAIz4rwdWAr8Fb7fwWH8ASnXuAvXMq+vs917nsti8P/94zIfYHbXy18Bb6N 9QSliFc9NhTjy8vPsw6ehVYU8s+N7sZ2iQLLiPMvH8w9uWCAgwXiQXpSixY0tiGYFLypQQVySOyo B2584ghiHNjesxB2SgX5b5vVefZU4eMYOHp4AcwMAxZFW52r2AVyIgq2rrZGBKMSMg1WogVpDq/9 89NJwQw2Oqmbi9CgHNDz68UMtT2gTvNqT6ZoLLYL2283gJhLoBp4EUAbE8f0IbZDeowTHy8HCV5k iltQW/qeBlLhQitzx8fRYipAmxmocCZh2D3nWippZ2GYl3tkrL6PB/dm5za7qpmowSI0LLEY8SXN 5YNMrHsMRX2CSlWbFrSKx9mI6LgjWyzCQcPj3PZOUPNVbGNAA2DXKLaMqFNxQfbNNHzkm6T/DGca 7I3Nmn9HjBVr40PwqLFxlTtdoF7ueHeDoMjuRlcmgvpGZw47IHcfOAuvrmU3KU6I4esgVYd+sV0P f19fVQwXo5E4cEGwpqd1zGyyvVPmCypXFM72DNG4Yotbm2q6NcU2XjPQqMCRilOxQO+YfPIMYTaX oKaGTk+zqzRT70LlGqgDO6yXEwcdGdneXDsrDCM/fMJ8ts39FP9cNwXY4w4/i+wIBt8dwfA4+lz+ p4WJzroyoLLXvREjACyGjKGTaxCvbRH9fEdms/RizXaLp7onOAUsJgM8U4FXQ9Sq10Nn2YpqB+X4 vdlCKT0zlBQ17pOopXGpmzihoP8W2N261+ypKkEvHoLxK+UwBbyHxFwVtxG25iI3MhWuZU4TtKSh AuoHJkVHiCebNu9oMVjRyq3wdypSFIt+49le0SykZC+vBlRogPAdnizx+yl9kH9CIM6KdeLgGsJF 5vsDIxxmLuzIPL81xoSZ+29FC/6KzBTZl8sVJvsrRjhYJ5fTzUudZ2jxHvTHYiC5B0EvSH+gHMQE i7CJPwwbYUmQgM0TIWjlAozXDA+0pN/v2BAgCQkX7xemqVOBZkXXLQCUbpVbKdeduxaoqRrRoqF1 I+AWNAs/QSvif1wnSXiKQEu2heb2qBFH0HRTfAwYzaoXqlqXrLuGo1knbRoXvw3ckAJa1Q6pZmFW Nw+vl3HfwUL1i0LEqKrqRC5Hd3NmB0CDh6zCDq1tpe5cK8ll4RIf/QQb1QR9YBaLmRdqFNGCCxpP V+WsbV3iLdNBgYOM9DrKRmsv4iSuck9cThZmsZYVadPk3+8XCMEMiep1bhtyfgW+Ve4G9QktxDHn FDg2YRNd+Zh1/AyiG347KwHcVsE1mRQEdJFrBI4TJBfI9sgUYEofucgkhxw0wNlkkkEebv3g+cDJ Qw4/AP2uILbXLaAbC0CxCodE4709WhNAJ8kOPcjnc4t923oJJ8knyTgEZwhLAQybDmsNTJcAr0MU O82AHGYLnz8XkxqjR5/Jpnm4NQELgwGL8rcYD25sb/V8Fv4UEajUYL+hL3I1izUSFFA7505K0SbQ fgHdFiXawYLZ15BTE3J6wXupg6A4+9vW5Y3F4YZ5+8HC1YaAsZnIBHHiLmBt8A8WuovmxIIHivl+ C5earVG+FwzUNaaxt4lw9LEU/rHYEHJ/UdNCvaUC8nagb4XD3GSwE7+VEXCbaYTRP+ez0vQaCDVz N+DHIhjxBhtW/TffMLofl2s2vQ4XAzeSb/S4DvP4B0QEoYkIFzQQCwPxmizCEA3MSNUpYKz6RS18 gwhlzMKL50ZfE/yw8CqDRf9Kpooqf+v+4YvG61Wpdv4XgSGmEOHVE63nC/wfohgeIiPbhPd/Hs1U MaKTkKw9M77bL9TUPtQ9tyh77tWv9qq5s0X6EUy4McmROWtQ0M8WCEIH18ItxzeswvFD57+XALZP gtbABvNOaMx3qpF8/zRTZ1DMzoDE7BeAHtWWLNgQIUr12nvKbPMH+YAz2Aw3cOsYiVMQ2UUTw7OZ o7iBDJdTpJHBXPUX9/lQElehr07ACvr12EhhCvYg3n27RcOOwCNrYorkEtrNSNWO0Vp5v/N0BPKh E43189K1EgEXYCN2C6QP/SJaULcKyC2VsvjFw36jDRfdT4u1WYvr5boA90Y7M79QD9XJHE4QENI5 5eqaKgADvHNbv9sVa5kdJbS/gvUjSQRNZkAY/YSDviSA/eusRisF7aWqqfEOCAkF1eqNyu7XQYGZ 1N4MuUJDIPcEdqLrrwN6m/aWLSuGnXSgGUETF2KVjWquVaLtEzIKz4Vbcgdn6wvXNr+Is1ZjoozO i+1uA24VEcvYlPYIBm8qmsyKhHZCCwG20Wq0Tak1lXuiUGBkU60C08qxmmi7rbdLCw4U0TBz7x08 koNr6Jf471gAFfmTmQAv+saKA4v1EMEqOAxLSEZ0+N9Q0w/nFqdqCLR23QzWGqNvhwsiqJAJcFP1 K5N2gj8Xk9PYbQL+ncQIgbUiou/zqKylYTwrraPTCUtL8ce6hQvC396V9RT0/kkhp4nGVnOB7THL CsIT7iCAOCnBoZgJfG4EaPuvp/PbBUuYNKxWuHoEw2d664veocFmdAaERie0KbFmkKnJwBOcFPm5 CzxlImxLhbuu4XJitFNUgA6R9+ESmyNmadQwALSLwmhAB/OEs1zA61wDOh36IB3gdfjBgO3l3+sz psQhivFw1xBhCUzvBDgUkhtBoVAg9VusGwx/DxLONzmLvJMUmtTk/8gh37oD1AfEAYHVlfoGbKLd C+Gp1hQ8d71DsG5aplvHDwLfBi3365/nE/dtKFYNWmj3gMmAOmLrVjeRsaIRraLV5xQ2oAgOL6dG FraDPBAXig8CExYTeId8RheA1ePEPCIPWQ8DoNVm4xNxKy71FlSLoMYhne2jdIPjx0avJMuRAdgB RvBx0exQcGgUWdEhRAcUG+1GaJXCLopWA7CInl1wKQjIB6GLuwVihLJSB08eAg/hJwHu8Rfp1U7n FF4ywoX3SfwnS/UUNixhQAjq80hkmhEiNksL91jGhlYeThQZZJv78QtIqYo5FjSzoO+GLJk+gLIv Fg/qpEeRIM+8rCsoQa0umFhmM1CuvqvM/XVy9gBwY5LaD9MxwMQMeaqPqNFoRF0FPc764EsYWmC8 sL94CTbQQZwYu3YDh/s/5EmG3GkN1+kX79aZftgh5PsU+tQBcVIwpEsQgDJjEnPRK02gbv1xK4dB E9JqAdIfoe7qQDNRqIu+3cBL1D7Gdfdzo850KQb9RFscKK/zx/OOWsS2xL+U/X4RAexe/yWLdbH+ uRQmf9mMvqb8sSImFDBjDsRPETuXOzZ9jRYUAZxFVa4eO4tPI1MPXB/JNsYJNhoXI7elD71wB2gv pd8lE/FMZCMMjoJbbLOo2OmQBvm8vQ7WjciDM+5ySN/hj8LRI9XynfOM5lwRSaKwlYClf5DbF9Gy PPvJTYomiLH4YqYyRcfnIQjQnbm2AxzdGiNZlYjPqE7ovaNyD6BBE8eBE4pgVQ6IWIgQbJfPghMC D9V/zUCrdlsdFqIXdP2ovqridSz7lyfGFw7YQBe4Ai/xA1IwMsW2ixc1AK+9LWr/OTAEI9iCWY08 pBhoEYIDqK6tIg5EjGxPoCcEkz7HnxniccD+cfB5eBRH2VdNpXoj6giLjMjhk6MdC00Gx9W8uxQJ aIpX9WBidb2lyrQdiSCmiuLw312KIL6v/TJ0MD4e/bh0+/e23bsFBb0BEAq//gsAscbfQ/13J3w9 +54bSgaGl/wCgzqdpUUbFC3FcacvL2+/snwW9YvqBIqL3NKL8OuK9jXirvp/hf5Xisw8da2T18Fv S6sIBOCIDRQS06wWHsENO7D6K0WLo6gYt6X+CfzcxuCL6IgI4mAAWGo9URT0XAd8vYdwC2wSofF8 wjYqFbxvG4rhfNoJUcW+Cl5E7RcHSVxS6A0cLYGnY6kf/aS/ELnO4+tEJ6l1z6h1NPzG96/+QPAA SbU+Hff0LrT8gCK3zg/8E4/5122F37KX+3W3+iQMMRX4CEu1//8OdDU+Fvt0Idww3CDMNMwOE8gu tRO3Vi8VfhjVG63p3luoMEDMABrvMS6GrrXn/XQlQB8BMy511rZyax0TdDEc9xoToC23cvcR/Ang bX9/9yUGDX4ZVQDMMcwpdrIPdeD8LWotavv0NXKqEw4T3AVUqWyOaAUDE5062svV3w/E7x7Q1n3X HM56HuM+EftOilzxDt6qLQMmDQcZwD6b4Nrf9MtKLzVSHMDMy2IvMwkbtzK2K5cOfB4RMQZyL/AC sYgvxET3zs2SAWxXsLb7RzRrTqZkMjAuNUJsuA2oqlkHud6l5loBR/jRFRMQ16A9Nco8qujW6x3h dnke4C4VdC77fh0FDcztwlu3DSlbHRgR9Ck3dA2Cte0JCzkIaQzM6RnhZ2VrzR8WGhj9E/3whGUz rQXvncwIa9hai/UVGpYxgQ4u29K55fugLxT7oUR3d//eGgPD53fnyu93p/5WNXev2R5uC/0WE7f7 iO8H+sC2GZrnvR/9DfnR2MUgRoPuJKg4a9xguC1+x14yt3QvgTv6/+5/Bfx1681763pPFfBqP3e7 8kO+fAbHgynaAgw4xV2O8K3AUXCsm0vDQYvALR7aR9W0Zm6mkkFxUn+PmnSpb43COOPwYj1xHRvp fqu+mcfEPYMzG3W7+kNVe7C5tRg3LC55f8ejDlqCbrWL3dv5XE2F2m8FpHKz+gsOeM9qF9haf4w+ B/2Fs7mRz4N790u3NDSyCZl1mgv0PgoHPh/3CCG3DxkFCHb4DroKgz9y2AYIBHa4+8biFw5wxUvb 79hWmPv9/RneVV3bfDhKAPBw4uI9NnAJBO+JitBVrk/sTMgLF0Wcufexds+lx3J4zv9XAe8dfjiy Obcr+xTSKzEiqWSwEaofejT/SUQ3mYwjqAADKBLb23SiInLt7RKQWji/8ty6mAaEX37583ZUMhDv ASNFZ+uJq83vx0YMauO/ie8q7iAWXuA+Puxywy7FwPfCjhcN/AC5AnbB+eL+sQl0ixtUtRqkvUWq 9/F/V9Vyv6UHv3X2d7P56IrBlS0UKHUb5aknIad9vfgGNXWP/nVWWyx6gTjWEgUIdu4VsIojgBpw Bn7H1v8uaogey6bzVL9B7b9gkY6Vx3T5dHYACzj36wOWk9Y+NRD/C2aHptQ3qK6XLy3oxZFbs0mD fNj38ciYG7KHgigSgihvoe2+biWEcoGDN8yE8VspaEBc4zChoHXu361gqf+c7jZ37wbv7tzybQ7+ B+f9O1GxiiQBEaHDqburV0vU1lumPI7vx47fftt+dAQIKNwBDvc23Az0AfwRckvohyPaSu1blSgY 10jm0Zsc/VLWdI/7/CzXxQUI+NvfSuQs9Ah0hvP8EHJDyKlIOO3dl5Z9CKzrPhjzFof3/A1W6BpA gSt42VkE8t9uG5Al9AWm91krcmPEJI/f2/5b6/4+EPA+HO4Wp0Qoog90INwICCzNdbdWOEIh/A8M oi2AS1v7zBExQj4LgunS9fRtW9e1WUwBJ6J/IGjvW1f7vy1D/CBya+VQ8IMKGU0QrR2wlbovBXSv 61WqTX4gi8KuFgrGgj/PvG2Jb638E1Ts1Tl4Wiza1vK2bLAcLILn/Cgfc+Z6c44qW2Eo9CX6hcex 89sfK+Xsuc9Xriz8TPYVHF0lIyDsCIPjgKHrF7ZcMzHh/mq5ArYBBCgvLFurEQEx3/wFdnl5ZxmD KdyK9zv0DD/8E5e3zbvYJ2d/lhHmg/j0DNv82zPMlggv3i9ggC+2sfMLL+BQCLt0rATWdPB87edv pqI7KoDXP5YH19gETqRb4gXw7hhkoX3T/CoGJynNm+VZBfM7J0Eoo3YdEproDlrZKAkFWsfIm2/P 1jvd7m+UEAj5Dnm+1ssj89P3OrzzZiNsjmcCqqxX2H6YmQOqAyED3tXfXG9bIT3HETf8ISgv4XG8 hlxzP5xZW3S/wzItTNEKppZDG6eHOLf23gGA3Dj0PGEU4/3eEcvW+vdLtnQ90rMVPbTuVqphFtbc J9Uh1F3Y2neL6J3a4QnuHeSG+vTC7/Gt0vD8L9wHf0KCH0+43fL8xL9Mvz/o9hYn/PS30FozUSMn +HIn8xia5XuupaHZ8e3xDUWqwToiwaQl7geytULfgVU4SRblI+4Xtm2GoMLxCG04uL55s7WwrQui 79ApF+Q+HfoY7WFrKKx0hyeyjBc7vzE/YOys67v9j8e2jTXcL49mJSWPG9RqzfL84H4ZXift8Qc4 tzPneFiCivrZQ7bBN7SZ5eMELBh/6/Ov/DdbZ+KqdrMlsi8ZMh7fsuab3hHkPh/6PbGPunvN0Jc3 /Cn4yJq0jxbUsHStILSPuiGIJ5rl+c2Z1+V48ioL7fEpQbZ22jj3ZY/ZIfd884YXixLrpbod6z4Q 8/faeLMNQiiNJ7Ij+hYcVhGwZnlp5PoPsb3YefNUKwdcEAOPyH215nAnVSMnKTNHszy/1ecm/ZCY 7fE4RuOhqTnWlE0gizs5KM/yvHWz1XLr8/e02my3VswvqQu9xh3YWrM8YOP7Aah2zPNLbgMHF4WC xH4JjnjCczTL6vQFLh944OJ5NyfF3Z5iku+7bBRqN0AEzCCwFiQ30cp23vPHGgK+F9/DvaFr/bMT Q7sVQVtAHm9nk+Xj+5FDHuxWMLeyldohtOuZch3zJ3Tjy1krLB4z6J+0ROZcW5ZvBXEdBc6R0rYG fvsdP4/pj0NAQbodcxF8w/tYKQgojnDPOYFk1/RG+VpjcxmOCPw9d94sNL8PaQcF2F4V5sMNC6aL SCFnzCXM9WCo8Y6Fes8QKw53R0TbtCTvKSHOkCLnF0wHC1nvxfrid/u21k6W6PYsUz8cL7d8hV/H xi8rJpl4GDh2fN1fOlU74RpmJBl0Rgh3GG/oXLMIATZTG3oHg13gLQdlO3QcSv99b/iazPM9K0Wa qVM7PQU1OpatOnUVBYwEixtvMrB9zKqj77vd1qovG10vbBrl+fn0L+Q8GfQ8v3BrfIC6Mw35aADV vOmEQmOy9X6kupHl+cZ5WNxrVO7wvHlolA9yDgvGX2wDagaWrZn06jGvfGdi268oocw/1sU8pqSa BTeyfFHl+SwdDLI8b5YED20z83Dp9cQYzbXfdx1xPzazPL9PwYILEADu8BUP0Lx56B0BERMuont6 GNEcRLotFPRIMH9ym3fwVheusIFXkBz5elfBwfZNG/zNM0gkt/kl2+cfGdMBHPV62/0Hhm49Oyei 6uHrvP5cgfx2ge8jd+Be7vexlvt6c0N9gawIxeV6xfSmMTcoHXcnoMoNxUJoWjYHAu8fJ6Al8rxZ boU8zD0rRC0o1e6zxcjN8A38PAxdL40LLX5uLHkUdM5STXbOW7elv2x9ECig/K77oaR2BXSurdHa XVV0vvMzDI4HLtGSgKQaFyuGN6BQC0coQtaFPgA3AGEH0YRoloNqL2gLHqctMIPYVCEHGf+LvAUP qtAbQad6u1+vlw8XOPodn6mlgtQpKvusdOs39be/pAgMck7OyBx3sd9/PeXe5XfpDgNewI0cKdbv VlSqKyjPxUit/1MtiutO+XU9CRb9PJBCtP/b1SwT+7jDpXf+gfvT+QV2NqBR8fmDK8vZ/BzQttpj oAwACmNqjUI04yxkEmgAPAtc/ri+1AowLECcyG7iVnd6cvPhXsQpd4GRtr8tRQOLl8QFdeZ3ovAb bQX/i/d1tv53svFnmnXGS7/UEjmCBPSl1CmVXjXawq2CpBD6LPRIHm9V6t8DJNwmdTUsFKadFfp1 VSHY3HTvoX0HE/fmgr6G9Hf0gBBTD4M4c2i7QnB8EfdBS4NpFQZQ6yq1xgZOmLCM+n/bx/+/BOMC fahL/6gw439kiKUaW8wTZ7q5UCZKQwGj6lGYW3PFxsvNNjeoRrFPnP2Jcr1KlWpvuPeCv65JyFsq XtnVC45XmQNcU/VhRqKZfvK17a6+/d3I8/rMfJIL0BiZ9sXdpbbfbbP6RIM2ded19RfzJ3M317bl zxNQE3SDYpy7GLQVZg/U6wlblAwq6fASsnkeGFDag/yVg+QhLzmRgvj7D8eOb0WX8qWdlb9ADyqG X/1t3uobDFTMe3fLXW5hV993fhi/nY0SdNIdXUWKS6M9POdZ7+KJDEWaSxQlPtqBqnx7oAXY8eho CIKsE4e+/YtoKWo4A1cOPtsuCLR2+frUegAa54vQTNuJtb/sQg5nnGgzRENhRlZgB1DpN5ZpdXv4 ubC2isMNtOA3QaF0Nz4W5SY0dd6w1bF2o/S8RhZd/LWKQRRvv4Lti6R/cvt6S8IpcOTXwGJZtoeb avB2VgNc6+827I4B854NjOlfXA34hktomDn8wrzsUK666vuNI/+ktNk8L+FefF2C+sqBmGyOHJeB 1oF1/VzpFae9TMjgwVYMgyi+lzgGwE1MF3EON1ktzGzuIUF/CxReHWUr1XfVDQgnFQ4XjCzNyUQu 9wdTFyWY3QG/Fy0PCxOrHoDmeX/+P863TAkzDtA6Q8p7bs21QkE4f28u6w3q22KRX9H+jrxkm4qe k9uivzYyvY5GMqJs+nMsWyPbfBdQOHfz5wMaZYjabbzbj1mRCQCy41ikqg0WSqZp+AuANypHUM5G /S8vrvSqWN0ssBNEZxF0a692863g3M+ZpbETJCFpI80a6hAQj2k5CffNgw/rF3n+ouvUDBSOBbv2 QniAa9SEknbH6J+zGOOk73TnCTz41FAQC7eIXqDNih4EtqURmruDfOOhqVM6f7ux9rHTae/UIf4S qO4Wqa9jh30F+u+FB6lbjRlqkhTiJ824TsCxzl8sqbYgMH2pekvwQVcuDXfuueXs5i7rQhNpxipc RbcBcxRyOLqdVRzWCO/bgez6XZAhDz/UN3Xr/s+8CBdUyFMHTG/FGw/1jL2Efj4H1Cp6t6Avissr lq21/mjVfIcsQAX34X7wBVfJHe50r/vSr/chKgAOy+8+chUHqPNOEYtaUC1XLF5fxAPq5NTq/m0p XEHR+69nFQvmG25u+8b6VKNYijZookn1so1tLqgLy7/GjkfYRmPthv4Gi9r5OtumG8ixZOt2oRDo aIOWiqZWNu1qOcxAi3MUbNFjAWOfYO//qFl0B+LbusFDr0QD5zsq5ADI9978dsE28//GK3pFA7u5 smxLEdW7AsvbFYYJxevIEyCaCyjvM+FrpyQXJk1+CgO/qIdTRXuJFyngEbnuwiIIAlDkV4Sj9cEC hoHrlfZdCXEIamIs5qhF89bYQDOh24cVrBdCySEnX6wPy1K72MCNxWIcvxI0JID4W4FPx8bhi+kX ToO8AXFrvh9s+xmrC2qJxu2KnXv97LqCmwbz2l31D+crYKiuqG6h1hOuA6CgMR+rcq1Uzf2x8/By KwsTFhY22xPRQf1L/RRLF7Tq4LPFZS1Yue8HiQH97dYDT3apwctvcnqnAoCYLbnhdycR7e4RfAne IERYeac3EFB9y2xEqDKrl/43wh0L+D0fM2lhow9N1SDemnbiZ42Ydtiaa31sMX8G6jbrVNOsKarh 4mOsIi3wPrsASVNeHbcs7ALo0HMZizBsqyV3oS5o2zKTRv8gO5pwcYnGhIH86Xr8gYtRm3wTqFgJ dAAYBvcRAj73UB2fau5me4B6eHYXJwQd+gjRpt9mV9LCZM63YBeSWwNUV/bsdPEE8E/XFd2KRbEC r04IOFfgl1oUJORdduEUYbYK0ANjoScbENu6i/CmxAQ8dhRzAbgWfxKTYXOHAXCLAI3gFD40UUPR WaIlee5GmzgkyoJP9jmfC0GAaIq4svtaGXhHusYjABbRLmRU42ytAhk8387/DEZNG+kq9729rZeD G2jDDbgUw3zsewY0B/vfjpGI8NeHPpeLHeG2n+Hvl5MnuR8X0K1riuZZG0CwK+7Kl5sneI39ggz2 jWhHN6Mr/Dnkm9x+XgFjanPNwx7CEcoc/ooBr1PEYZ8nPTRAn5Y2uV3DI1OHaRauDgMWG0PuYBiw AjchK7dUg94OKnq9FoCrmtwG1ekKKORWLYPikgmK9IaEp1LwKUOpLehZnk1s1eTybp83e1Aw6AKd 4VImtp9c375yiOvt7tq4NSyIqaIcbydwUDN4wZHK6tMSCxVfMctFvh41Am5bfQm7Ur7bzGUUjdwl rhe35wYratHooKuwwzPg0Rd6o8Py08P1irPM2DAQBZohU6t6tdgCpeBrU6JSLSMtwUDNUCf9+9oJ unRbG7k8B4sLEQDffHAQNpsDivy5FFy9LxA1I+30Eat+AUciVakqCGLEPoxBuLL3QIh8WXKynaLO Bvf7JUz9c+9/wcWKz1HJmrngSscXcHweC4cFwvAqopxT9lsInrFJG5im10kecrK90msGMa7zQ++p YnDHGkWNosfOB0zwQf8SB2LYkAshTSoexGs9jL9sIsewRv0hfEF6FYx9B/9WrNDl4hVQ0BzPB0Qp At1xQm02vqU5whevMjd8OPCwzhraKKhN5SKbGgwSXhkjMvBrSBI0BqM2AWrr7YGl4wdBZ5SrlQPq NpZ9BxTnTUDdTdAYkO2oGPsgZ06aN+dCi3sEuJsZAEqTDLwLQ8DpqZfyM0nNeBAOYu9EAYJ5Knrb NIhgl/3vrTODYAJBnaF3Azg8YilnYZc/PKaoVzYshEDW4C4f6feXT4YHFykB/AxWhIJwu/1ngCCD HfjKot1X1EI4RpXyInQI2FCMnWkG7lr0ZWsfdPJHkmKs6AZ1F24flgJizea/E1OoJYdA5TpeiRoU vlEy1Lp0ILKFYcX9G/9hd5l0t/nwSA42gKw+EfiZdoZgZKENaD3aonAdQIvEcC6ksYSAzjniUgWg rIiKQMN1l4rI1QZgWO3nhAEDcOSaeuDECRirE8UyWOpahYR536oKK1U2/AOcF5fzJjncKrNFovu+ DycM6VsHkVdAUw5J+eC0USqzwQdOkIzeJaoEhmJxqoX932ohJrm37z4V/Xwd4MSqB6gbtzCUJXbw SPu+qyq0jYDE92HJiQmYXS57220xrY62Wz8LCCnGqCV2I9jasfTNC8Q3NgB1tbjw21PDZ3T7ZyCz OXTncwBbqq6OBP0UGm5RPv+ualvhXiKSUKTtF0wf/VzFJJdxHi/4DEqcfrhQKGciEou2qW92XvDq 8zFCVQ44GkbafgXc4B6g/vdwxA8UH2cDGx8fra1ngkAfwyi6oqhKgKDaYEnQyaipFCcvqkfw9w7Y gjpXV2gvjBEvX6yAZ8BAXkTXOCiaiiZPvC4QbXg9MAufCnsKsxlKzVcCQRoNdzBFJAmTggAOg9qq oGTbBsARYWLmN0EqzAjs8khCA7EfyEIl3sYWrKXZFt4atsP3CS5+y2d3BGXweDsM/1/wclPxrKBI wM0+O1AyFbsKAM/WCTtoPp5YcP92A3QcidO1UcDQQSPqlayBbItWctgjGk04eZ2ifnAQ+z2B9KxQ 3QzdKweNJlaixMYF4KOiNSvB0e9XX4GLyISsHhc86g6xfqYHvA1NPClv5xzFBb/9QE1Iy6bvFXDU j/tZpYwvS1ZgvqAIlSp/TiLa4TbzkqD3H5CrFsbl9bCXSgPupkOpr1xLBVdfAC1TBj4An+CcwEiA 70aPoBJh2gavHLY4TlSQOlFvBQ+cFET5zamgK8xMqxC9Xxf4EX2mPAwXD28Erq6AgV5pSHYYxtlJ wSUuJMgar0FdjA1iqNk/D1O3bRAn6euuXK9fSbeI2L8SKoqMvEDhbWiKRNNWdfYIXTCRJ2EuRggg 5GINt67UuAMf1BfCf6KJ3v1tpsPpIMJ8phdpBsQBitdQdbsl/DWuQDoNOTJwiaDEtAkMlx0Vbokd /Ol6/jgj2twXARFdb/eZMiCH3UBt+Dh5Qq0agjMDhpUDmLW7sTo4E76X6b45xbbD74YjXstesz9e gQczNldaoslADfk6Q1qWZdkCOzcvKyfNbVuN+CcfOKcxP2sArb3KMEeU0FWzFRyVg3wczw14vwq8 wtcmTXWu24BfcCgS4gq420m/7MwWCd8gFCKVAPFIuTK3NxtfSaF24Cv4rHTiF9mpdBMNhoJvCSx1 lv3Fzx5VgQg4+j9344EDYqyqRDjBFwJubw5uFy02VOyITotWg94WjsR3ba+V/Rfq9oruYSSfxdtR fLExJAadFwi3W6oE+MYVBJURHtFI1Q3Q5jtq6rKhkKFOK3hzqg5vg+rBXHZG2gdshiG7/ycOPB8n +44zyNPSR0fxOseK3n47qAXv+xEjYLYhNSVT6BKPZ+1BK5LMuzCbZIPB5uo7Dw8Yp4bicRQxUcdB Vu6DhUZYl0tPTBfBD4gTdGRZMeFGwp1P4UWseyJtwCIqxQzEbQGBzVJkBJMm0YWjsxapFa/cryBX ykBcHNSIXtGS70uaRTAQRWBsUitF7by+5hQQmE8dPyZKWzwlP75l69gDq4pzgjIs4RT14DLud8D7 4F4Q8ZnamQL6ZcSRzXGpPNbad1gFm5GRkZGXk4+LkZGRkYeDf3uakZGRc29rZ/+znQDAALlSA6U9 2zRNx4d5l1IbRVfTNE2zAzcpGVENpmmaZf1W9ePLu5qmaZqll4FxXU1smqZpNycVA/dVLJtls+WP V1+/VbOm6U7XpxebA39tm6ZpmltBMR0N+1Q0TdMs68+/sZ3uNU3TkYFvYSNbuqZpuncD06G31z/L bdKd7QNHVN9Z60H7NE3TmVMDkZ9pTdM1TdM/KxdbIwmmaZpl5VLN2ef1u67pzAVUAyOvD/dbv1NN 03Un79LzA+387DRN0zT76Pb1xs80TdPL+JCMPP9ntpcH77zuA0cPac/4iNOe8f//3/oRRa72ZrGS +HALlY/KWpwWXGqbYc13JPFbR/////8jhuEWKh93Ji1o1LNJ9kKDToH40kcYbuJAb5vvSOIN3/// //9PlbeORgwhvkF7gisl5RQbIpKuSisLOHosfKlnk+w/V0L///+Um4UGnQITNpp1sKP+6yaT+Zyc wvAFCvK0/////zffkcSh75azG76fKo2OmF0uG/zDuCv7tAJ68i2USvX8////WgVXSsqTZ029KTZE JL8GQ1MckyfNiqMgujDyKSOm////SxlUU88m2cX/Ia5/rig36Z4vQEoLS97cO0yp/1/6/2ZqRTDw WkJHYUf91/f8oE0m8znbFvROeIOQ/////9Dus5enVOKePsLSmUlvviOJ+Y4k/kPfLWfV7yoQdnpO X+j//47gSkn5WhtAYMwrRxddNviHywZkcVf2af/////nZ/EeRPKVgNLCkvdok5tu/qOcGQuulJSd npPjJ8+aev///42xNQ0SavmThFr+5D4L932oO/AKOSZPmq8WSPz////tFUdBdIN3RgMg4iKdttIl 6gyDLHOasysEp55NsjF/+/8vLMWL/0NcHc9EK75aILUoaidhOy5bBAsp/////yyVFpa8AyaRy7l3 mFIvR58ljNL7uxri/Mygs/VVNoPy/////yLDjvqvVb792O/v9EF53/M22kqXqEx6kN/2K5lGYBue //+X+jHxBiGhbybW3WcvT0tXKDjowkymfvJL0f/////Eo0JIUpNFP998RxJJTEBl8x1J/GUtTovG uCoVUIgtYv/////q2ST7fOkjjO30nBx7xJtrwZWS8lellYX0MPEbYgD2bP///8bYUaJOYfiCu2zw Dy1c93iXDf7hAT35lqKonf////8INJiaf47Jk+YY+ZSRieQrAR/ULHalhSXvM7UimJAgRv////8G BhBBcbxBSOgqcU+fF1wpKYFsLl47PSfHrQ0gsA6YROr///8umKhDWSL5SsC0yU23JdTyJ7Pk9VAJ tfzJn4Xo///fnDwQnyCqIJhXEHGRzoZBlrlzTJ405XyZ////X9stkNrJHZetaojzM/y49ERG6f3d 0Nn6qkHERTrX/2/x//RCTW2lS9T7lUyjWBw9zjAvSnRhJtPiUf+t//8hpE89m2TZDZwTY1yVivVs kob59mPAyfEUev////+Y+I3sqP/6fbVAauuFRx1R1E6Ex+RJ82RxLW3yQSoaSP//v8UQIxUgJPQr LSx5vR0rDgdMIpeRfCXgMun/G///QX6k2UYJHohPkIi4SOcZpX2PlfAANcT5maP/N/7/9P7uAGGa cJZRnQcsAJSexJPphx31XxEt8ij/////q3z7sT1M/Mae2ZhYCOmfL7K4lrYkiJHBtZUuUSOlKSb/ /y/1mfQgv4AnyKxRQ1Y6YUQhgDBNuBYASs/j/y/1/w1CQnU9RTXPbEysWR7b+skvRWz5KDLWqP// //8hq0CYJtzRhZlMR7WeO/3kl6Jr1JDVyEH0S15x8zzkINt0W//6pXIQ/dKWsAPFA2S3rwvZNc1y k66ncGEDSa2ma7pmIAYbfxwHIKZrlssBrcSs2XYDXnJdBrsRG29ZBzG3Li97owz/g1gT01L3Xlw2 l1yLWWf/X49YA9I0lyMDJxcUGZgwrXP/S/8Tgv64mouolpGbFYy7lo2anIuQjfcL/NuGvhdV/raR louWQZaFmryNCZZ/a1ucCqwdEZCR/zH9qJ659nd/2yisN5iTmrCdlRj/YP2rmo2SEcq2v/2ei5qr l0iem/8+/rMGiT7/Kdt+/5n/upEkjRfk/7yTkIyat7XdrbWejVX5/a1EuZYKreC+s6XtCqyOYydv z19zX0Ebvv+Sq0iUvJBjrmy0ilZzb85J/1kBgrFiC7EmK7Dd+/Zp/awGmo//axdbjYwYobW3dv+i GUW8io1YQwfZkr0DtWvSifLLbbcPvouLv52KGYwlkN3+sHa7mhKRG/6yipPSvYZrvLDQNpBbmwGX no1ZOex1t+27M4kUho8leHFWb6WG7a8VkAyGCTmej6l0ARv7lpqIsJn4yukZj5u1rzNvbZ45ur8k D98Of2eVCq+QllgRT/2qkQjenrCSSWb+t0iPvpNtrb0GuL+Jcwm7jGeFmOkVTR1vH2C4vWtjDbl5 W/38k4zonI+LbR57C/cLk5qRBv0Xm2xrJ10LAJKeDAMLNmxfNxeKZ6mPjN26h2MdTxapkZKaOpI5 BMMOe4f/E+ARjyNmxDa2pTOagpkXHSPbc/wZs5AwHimcmg57+Gtp37GeksWaE69wP6zbNJcPwem+ m5uN7S4stC2R/kJws7mNns6ZhxHfxZWvhCgQTmiPmWO/Z8B9sPamYbLlhxL+sI/8Deb+/dLouZOK jJd9vYqZmeYT6Ti00iAZO66/2pJsk62TPoy/4w522MXXQUv/Y4v/oL1fK/wfrIY9vuC+jEUD1v6N 6tsZspCbig/rtJZuS/+6rbG6s8zN0SyTDVP9v49ol7Ttt4uZGqHTq3nMttJ5ZxISjIw8DMOsdTGX HCLjmdPIgnuTmLZ6EcqeCLGDten/L6mKkh7/2IezYShsF4ohFXfrjn0bNhmyV56Ykb3Bip1FGgv2 Iu8KKm1lrXGbRSYh/qbkNekK7ene/x6zGkEN0A3bRh6qj49R1YnWZbe2LGVqlg16nJc92eGF1n11 PZGMk6YUIEx2tnnVIqbFC4Ues3+HEpmYpunwakmCEr97KOwes5kgLRGqrF6FY71DW6QvULSap64V br+EDa6KPIapygZQ29zjbCGOHCAOjQ3Y4X0BHpkPSB37l5nOebA9vrupvq+2bX24SwysrLe/wbnb Wee+i5K2u7OqJawXrFectEYlA5Yw6IJGo016Th0bCwyEbNgfqKywvLROAAI4SBEjtVDNcrAxduID 11Fj77JZLpdQnnCKc5Rtb9ksl83SHK/Zrc6nsNM0y2ZkSa0gXmnCbC1MAbMrS2wtzNaDC5aDD2Fm O+bCt0NTrge3zK7pmiB/CwYRD49QaZqm6QOvnZdtZaZpmqZgW1RPR5qmaZo/Ny8mHxjZvqZpEwsF 308D9qZpmqbv59/WzlGDoZrH/AkF/Vyitb5O//n/+N8ta//0otUbEc7y//FaN5YiaFfuKuzn/+p1 UOL2/+n/6EP/5pul4x1GG6FJW7sDSKzWaDWwAol4oKxEBbVA43utux+8m4mTYkjO1HGxaA+GCu2B QTOgT4g3xAFXewW5BFMegnO0duCZfFkMNQc1mW8ej5eem5aYlosFnGlpdvYfhxCSNNmSGtYamFpM D6g/E6B7LnaMDWYZBpa7yTdrmv91DpEHj4a5YcMiHy8CUhVZ+QaKjwDw/60fwp6dnDeZmJeWlZST kpGQj47////f4YqJiIeGhb69vLu6ubi3trW0s7KxsK+urayrqqmo/jf//6empc/OzczLysnIx8bS 0aDf08TFw8HC3fXyUab3wwvA2dbUDpdN03RblEsDU1tnbzRN0zR7g4uTm9M0TdOjq7O7w03TNE3L 09/n9//ptoY4Hz4HCwMTpmmaphsjKzM/mq9pmkdPW8t7Pj7XnD1rPlODPkeLkwO02DVNm6P8AP79 6TtN1wGJq0O3wwOmWwW+koyR0ZyFj5CL1Xt427GTC4aeDZAJT5ATg3xzP9Grp6sOB7ersrP/Ss0/ P6i+vYiXmo2akmCtbosF1IxniwuMAkYNSqWKcNfdR9IW7tKYY56OE/SQ6fa2XOmPjNoLAoYyE1gT r7V4Y7eTm0BwhpKBI/bHQ/uaulbCjBuP5p5ThqZKvdJukQeJlrNDf2ovtpbOlHCPnqdtiVYWT5Yj ooxEw8SbwZaPOXPcHz3XC9bMC2HeQiXai6MQM5KLi7e5trWM6IGaSwTiaw1XwU9mpJZmaCHm0ksn lz0Xt8Vn6JGGwA+duIYHs1nrvQ6vpRELh5lhexVYjFx5ZDdr33s/Bw+ILRrL/h7hufywiJnaikOy rLbZbdg3rNG6p7oX2c//I7lgCy1bFIsLT93Gft7s2oy/2tGamz/DDcH/3xmNjRffCp4omiPVe6Gu xdHVB/DRZ6vfshUmJtzamA3frAJzDWFDDcaIKKOy1C++JbsJrLEoH7Krr9+yG3PnQniG31MTupH9 6sno35O+nJy6jKOsuerCmYeePG4hNYC9WRifa7bDDVs46z6LJjMpz7GyWHcrhQPDHi20ywSw30SP 4M9wi9wnyMgxuKy9s+uWvfec+g/yD7scFOCLbYqvhous022nsgIJ/6OvA6/N0MXDTjfvi9ZaGy/e jLw3R+FHxdeas6ajYpwVk9EG8LUeM7wUzGq5sLOZNXaFb43Ru72npzC7kJOWrKOhvDDf9N9aGxNq jS+XvqpJGH/tr6vfXJ4T8vXRAse+q74uwgt/CK28r9OrsMX1ENSSvfCyvrazGK2wshEA2CM3NlKw 3x/y9cXNykevLcu3A87Kx9HN0QhbqEI1EBd3moAM2OcjA38Li03XDMiXm6MDq7eDNIN0C7/L0987 SDMg5/sDOkeppusuCwsXAx+SALZeEAabH5skiwuPLzhJHLCU35xKqJrP2rptGqAVoJgfhpL/mFho D4WKQdG5K4CX/JPL9fpP8NC22JLfkdFxGyv5J5VTlpkNqB6pRctzKUJHlY+YC6a6ep33kR2Nh1o4 gHgzAn449rAVvAuS/p6Mt5rNhvS5kgeWq6Ss8Fg4mkuPDofDTkXY6NL2xXoCQ65mzwmrkAdgO8bM AbMMOwmDtjYDttfSbBFOz2aC7tESa2HSbxJbWzPBkpNkjNBFh6AATW/uxN+dNJt5793a1sg/3S0B 0tJIA78ObWEJA/Urz8ewsFjfh9EEvzVfeM3UCuRa6vlL3baRzTYjFcQW9pG8WjYzenSixLA5mjZb 0roLm84rnaXXshs6ycsiSGShqcUKZd/2L5fkyZYd3lBAVH0dbL+kngfQh9KF/NKpjzR31ljem/PR FAfkij0NM43fE4QhYtToJ6+3C0n6LlofF76qs6uj8FiwB/y0noWenqPMnk9F7uDAnJPzi4eLbuwL 0lP+VaMLoyaBU9treA8I1Ud7M9dL3wLPUc2bz4sPy218stQQt7fYxVKSBJszl387mwDY09jfm9+y 34YTQ7Rmgc7N7BAPMTAP5P9SjQ2CxYWT4Ex8DhO3FqyRZeNPlJySAA9GkzDPhSc4axwbjJDRkdwM /h2zrLytsay+qbpuD414oJlM+g6+wRVoQ2gF73q60LaWa9xSqYKUcwKiUMlid3Mp6rVnXgcsmY59 h33d64oD0QLFD8WF5srQF6MsLM1wWKEESz+Ujt77B7a10raYvrqWq4gvStFuANGYr4qKtaDjxMXH AA+dfUCg4CjZTaSrZsRJkNaj9QSWQZA7Vlj/L/Cfxs7W3ubu9v4B1d3l7fX9xMzU3OSl////7PT8 w8vT28DI0Njg6PD4wcnR2eHp8fnCyjD//0L/4ury+uPr8/tT+/n39fPx8O7s6ujm5OPx/3/7/+70 5/76/OPw+er16Owf5ffv+OTr8v3Wy+Da0MiKL/H/4dfM0t7P087Yx93KeM3b4t9fQMzooL+X3veV Ihgn/VdSZ7buiwYN+wv7B/4j3Yt9syEI+xMUI/9eLPYiHBoEPM3ei/wD/v8fRyv33mz2Nv4DajNj KM2+2LJ3DkP+F0t2Nps4a1f7E4fesskG+7P/bxeCJezNX0ufClZYmM2jWyDvIgEWYQR3/wsl3y8X WDfrzN8LfyMD/ylwPrdsIxcr/5CxCZtHS38b/3uz914rCUtfACuzWbLZS0dvNbKz92afb4cr/1Fs 2GxZT2eLC77ZsDdzlW/T70o9GkMPCLfPmnM8FhsHDwv9/Tvfm53/EAcX/RObzWLfNPc7G0NL915s NhsfL1YTxYZ8swsr93KWvdnse2dPd4fY7Gz2DhsT9w48sjd7b4OXh5u7sFmwWbenq5OZhi3Z6wv+ LH7wuhfhA0oPCf4DhDM24WigA37kYkNgtiP0LxbkG/YVC0v/C9myN2MYC0tHDRu2sl93N2zYyIZH rzOH7CUbNrfHC587zJKth1QdA+ykCJsLvTIevxN3Ngvy978LI70L770JMyOhIwsney/2mb8fvTMr EwCs2Yw3FwwLkXvLzt5Tc/13E2/J3izZEzsTK8GYJXsTiwtFNvIle49jQ/7/G+8I3UtLE+8Jv98d l+TYRkC/C+//AhvsO93fC/8r7xP/C4udL9jVE+8mCzd7LzZDS1tPG2CzZrMzC0Ir8r3ZLDt3J2// 2ezFQoMjk5tlE5K9D28tG2XD3rKfFXcTBalpw98c3/sN+1TY15w7GQ8aAwf7hhs5iYjm/fszN3vv BS8jQwsbm53FTP87tvtTAyw2pNgXvgsHN5sFu993WwNze8PesCNXk0sLyd7sLXOnX6vDls1mbweH S7r3HmML3wABYgv7901wE/oR2gf7G8I73cjv7wvvB2a5994LGw0zPRt2STPzM78rzr8rb9gMEpgH K2azs2FTO/8bi9lsNvlr76M7ubI3m72bcyMzGxNmL9m3LwPqXJEUY59/C/+FFG+VIxWTFCssPS/U Xduqv9BD3KCgJosFucfNsumWJ+MD/x8oP1s0TdM0e5ezz+tpmmbZCykrR2eDt2mapqO/2/MPKiOb pmk6A0dff5u3Kmk603RDKisDR2N1Z5umg5+3K1fTB+Orb9TKA0ycztGJkElThjZ8ntGZjRuKjPzJ xqgAW9EI0ScS0TXAAI2K7GdHU9aqJAEZjEiqjezbhhOU0ZqKM00FKJRaj5RvKfSjRm5lHlOTu1sA u1HGjYocmp5aya1VdTmRk2ClHJkWrlkdL7ABWx/NII6KE7ZU+5qdmpzRBjqeG5hAALm1jeEznous bKUaGicE0TTMRO2Nxxl7UWgU4AH/iZ7cItrKGo1QOjkAcNsB9nJxk1ObawulmEBXneZRk1BqJbSM Ulb5VlhgS+uR925VXmFKthmQmf8OEFydwE+TilG/tmpbhpPSOZjxjNCClPHaNE8iBhhbPYc2jYIr lu+MM1Fv1hUCyJucEpSLVEcrAtiYV+25DSu5NRw6lIwfnmC3tgT1kgy0kpsf1gqNGO+QWBjAAqXs kYkeF4bXrmwrfBqGOZtXOq5QCyQfrrGYIyW3lHKKi8nqlE4rOYmedya2r2w7gnSFG5GR0j+d4QbI 1g3Llq/dlHTfDpGMiJactJWPWJBmWFhgskec25SSHYUQz0WZjX/zRpzFmDCRmZCvrbapsqy4la0E bwewsbi9B7YL/NpXZ7AID7O2N99vTfGCwx9LyQDI/7GYMwDvtry0G2sHArJlXzDFgN5TFIHbulqF n5o830Yn1Q46LXeb/3X/giXYFUuKj2SaDltqTRzT2ZQRiAIc0QBhLVmBR3ZRG7eWxxwiZc99iJyR Hx0aiEZMPqvMUtcIZl30zd+/C5AOwO9aiIk3i/+tqrG7kJhVXQsrwNMTWOEKJIeta2+OQgsyzWvB ybsKew2Ih4oA7wb///9mcxPP6c7EzpjOVs4jzu7Nsc0Wzd3MVcyWy/////+ZynbKNsqAyAzIR8c6 x7jGq8aQxofGfcZ2xmrGZMZZxv////9RxkLGOsYvxifGGMYDxvjFx8WBxU7FOMUbxRTFrcR2xP// //9wxCbEB8TDw6nDkMNUwwnD0MKgwoHCWsJEwvvBmcFXwZ869P8lwbvAd8BwwF7ACcAOC/bPl/j/ /+DPqM9zz1rPSM84zybPIM8Sz+PO3kHOrEXw///Olc5VzkvOQc43zt/NyM1AzSPNFP///7+66Mvf y8bLtMuJy3nLc8sLywTL18qOyofKYMpEyjD43f//yh/KCMqvyT7JEMn2yFXIN8gqzQPI7Mfgx/// /5eOvceex47Hacdix0vHKscIx+nGysa+xrXGmsb/////cMZIxmzFAMXzxLzEs8RoxDvE8cPpw8nD rMOJw3nDcsP/////WsNRw0jDPcM2wyjD+8LpwtnCrsKowqLCncKYwpLCgML/////bMJZwkbCN8Lo weLB08G3wZ7BkMF6wVLBSMEewfDA6cBrqP7/tMCkwJ7ARcA+wDDAIcAAWM//////coP/8c/Ez77P rc9+z2bPSs8qzx3PDc/8zp7z////zo/O1c2SzSnNF832zJXMfsx2zHDMNcwhzPvL7////3/Oy43L hctoyybL9crkytXKzsq8yoTKfspeykrK4cmW/2///8lLyQPJtMhQyF/HEsfixsHfxILDysJJwTrB DsANf3dCkBcG/M+Tz3TPR3cD/////8+7zq/Oo853zi/OEc74zeLN283WzXTNU80hzfDMvcyftvj/ /8xqzGTMUMxCzDvM1Mufyw3L/sruyuOz////73Vuyg3K0cm6yYzJeMlwyWPJPcktySfJtcihyITI F/r//3nIVshNyD3I6sfWx6bHj8eIx3THMQLHHP//X+jHBccdisZFxjfGLcYcxgzGAcbxxc7FwsX/ /7/jr8WiU8DEq8SWxIHEbMRXxELELcQYxAPE7sP////G2cNcrcOYw4HDYMMxw/XCdMJYwj/COcIl wlvx/f8NazvBM8GzwKzAccBqwFzAVeevfcObwuuTz4TPdV8hzxbPC0Dx/7YLztduzdDMyczDzH3M Z////78kJswfzArMrculyvDI4sjEyC7INMfmxtjG0sazxpn/////xk7GPcYlxgvG68XcxcvFwcW1 xZrFk8WAxWvFQMUwxSn/////xR/FEsUMxQbF+cT0xOzE5sTfxNnE0cTLxMLEtcSJxGrf8f//xErE NsQqxB/EF8QJxNjDy8O6w6hVa8NVw0N3/P//wz7DOMMgwwjD0cK6wqXCnsKTwozCcUtOwkj///// wjLCJsIPwgDC6sHawdTBzsG+wbjBBsH3wOLA3MDHwMGb5f/dwLLrpsCgwJrAlMAvwP+fY93PLv3d bwDJz7fPnvN9z2TPU89BYc7Ibf3/3z7Oic6CzmzOMs4fzhnOEs4Mzuq4zeM7lm6ftM1DrjdMylDJ EjX/TQu/dcgWyPrHr3InYMdZx1LHQMcuf9f//8chx+zG08a7xq3GmMZ3xmPGVwOuxRHF4cTa/d/0 /8TQxL7EmcOPw33DdiVHwzXDLsM6wiTC51AgU92vl8FDXQA3/H8DHMbPUMZGxj/GOMYpxhFR7sXE Liz8/8WwxW3FDsWsxG7EFMT/08Pl58Phb/4XJcPDvMOww6rDngzDr8KCwngXUjy0v2rCTMLQwURV 238K4+/6Lethz0LPOznhzqrOZs5ewf//u74ozhTOv9ehzUTNPc37zNzMk8yKzCDMC8z///+t9uPL i8tyy23LZstNyzrLDsv3ypfKUspJyiPX/13/ytzJhclDyQY35MimyJ/IT8gayA478H/jUu5Bx9Ws x8HHs8egx2jHVDf439URzTWuxqPGm8aOxivGndjFlb6B/5HFdMVcxVHFSg8zxS3F9tb/N3zXv6TB fsNow1cVGsMRwwrD98Lmwt7//3/HwnO1McIqwiLCF8L4wfHB48HbwdHBusGwwZ///38DKYnBXsFG wT/BMsHrwN3A1cDDwLXArcB+svB3/cBnwFPAS0MowB3ADcAG829wQ/PNx/DP58/erPWNz4V3/P/f 92zPV89Rz0vPRc8/zznPM88tzyf9G88V/3+29c8Pzwl5XzdfzlvOV85Tyk/KS8pHBQz//8pDyj/K O8o3yjPKL8oryicRS9o66v8byhfKE8oPygvKB/w/Alf8f9cmf8+XOY/Pi8+Hz4PPf897z3c23P8N wW/Pa89nz2PPX89bfXdP3d2C6X9HmzeBL88rgyO7ltzdzx+FF88Th4kHd//Ow7f+//fO887vzuvO 287XztPOz4XKn8qblf//DXyTyo/Ki9eDyn/Ke8p3ynPKb8prymfKY2e8wv7KX8pbylfKt/8vb3v/ /03/zHfMc8xvzGvlY8xfzFvMV8xTzE/MS8xHzEPf9X/XzD/LN8wzzC/MK8wnzCMDG8wXzBM3fgPH zA8nZQPM/8v7HcvzQIF9A2/ry+fL/wAqpIoCdhSFLSoM/182U3AMEAFDbG9zZUhhbmRsZTv79y9X cml0ZUZpCkNyZWELQQyP/Qe7b3B5CkdldE1vZHVsGk5hbX777WATV2lBb3dzRGk2Y3RvcnkgH/vv FUxvYWRMaWJyYQ1GcmVlht3+sTBQcm9jQWRkFXNzbLdjM/cSDlBudHSQYnX3tvZrGRNscwwSbkpr t1/WNgNyD5JUaWNrpHVusNZetnQNU0N1clALjDZstz1PcBBNSXhBbQ1mIcIbTQQUfccKEZ0AAhJL ZWahe7F5DD0LQTeKzb21kVhoyeF3ZXJC98uTuLVwp29mQSBQRUzZ/kP+AQQAiff+QOAADwELAQYM BPsGG6zIFBADIAxAC3PL3jsCIgAHbQw3sMMmAjgQBwblie6yAGRPUKLwsi4QyKADV2QevfcaBi5Q dItzkG7hU/azBEJgLnJkf2GbdyHfe8z7JwhAAtM0t1guJieIvjDAwb5NSQzAT3NyYwDr+61ksPBP zBsYIQ0AAAD8XPEAAAASAAD/AAAAAAAAAAAAAAAAAGC+AKBAAI2+AHD//1eDzf/rEJCQkJCQkIoG RogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB23PvdQmLHoPu/BHbc+QxyYPoA3IN weAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJdSBBAdt1B4seg+78EdsRyQHb c+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJCiAdHSXX36WP///+QiwKDwgSJB4PH BIPpBHfxAc/pTP///16J97kDAAAAigdHLOg8AXf3gD8AdfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJ B4PHBYnY4tmNvgDwAACLBwnAdDyLXwSNhDCkEwEAAfNQg8cI/5b0EwEAlYoHRwjAdNyJ+VdI8q5V /5b4EwEACcB0B4kDg8ME6+H/lvwTAQBh6Tz6/v8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAwAAACAAAIAO AAAAYAAAgAAAAAAAAAAAAAAAAAAAAQABAAAAOAAAgAAAAAAAAAAAAAAAAAAAAQAMBAAAUAAAAKQg AQDoAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAZgAAAHgAAIAAAAAAAAAAAAAAAAAAAAEADAQA AJAAAACQIwEAFAAAAAAAAAAAAAAAoPAAACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAC/AAC/AAAAv78AvwAAAL8AvwC/vwAAwMDAAICAgAAAAP8AAP8AAAD//wD/ AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAId3d3d3d3d3d3d3BwAAAAj/////////// ///3BwAAAI//////////////9wcAAACP8AAAD/////////cHAAAAj//////////////3BwAAAI/w AAAP////////9wcAAACP//////////////cHAAAAj//////////////3BwAAAI/wAAAAAAAAAAAP 9wcAAACP//////////////cHAAAAj/AAAAAAAAAAAA/3BwAAAI//////////////9wcAAACP8AAA AAAAAAAAD/cHAAAAj//////////////3BwAAAI/wAAAAAAAAAAAP9wcAAACP//////////////cH AAAAj//////////////3BwAAAI/wAAAP////////9wcAAACP//////////////cHAAAAj/////// ///////3BwAAAI//////////////9wcAAACP8AAAD/////////cHAAAAj//////////////3BwAA AI/wAAAP////DwAP9wcAAACP//////////////cHAAAAj//////////////3BwAAAI////////// ////9wcAAACPD/D/D/D/D/D/D/gHAAAAjw/w/w/w/w/w/w/4BwAAAAj4j4j4j4j4j4j4j4AAAAAA AAAAAAAAAAAAAAAAAADwAAAf4AAAD8AAAAfAAAAHwAAAB8AAAAfAAAAHwAAAB8AAAAfAAAAHwAAA B8AAAAfAAAAHwAAAB8AAAAfAAAAHwAAAB8AAAAfAAAAHwAAAB8AAAAfAAAAHwAAAB8AAAAfAAAAH wAAAB8AAAAfAAAAHwAAAB8AAAAfgAAAP8kkkv4jzAAAAAAEAAQAgIBAAAQAEAOgCAAABAAAAAAAA AAAAAAAAABQkAQD0IwEAAAAAAAAAAAAAAAAAISQBAAQkAQAAAAAAAAAAAAAAAAAuJAEADCQBAAAA AAAAAAAAAAAAAAAAAAAAAAAAOCQBAEYkAQBWJAEAAAAAAGQkAQAAAAAAciQBAAAAAABLRVJORUwz Mi5ETEwAQURWQVBJMzIuZGxsAFVTRVIzMi5kbGwAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJl c3MAAEV4aXRQcm9jZXNzAAAAUmVnQ2xvc2VLZXkAAAB3c3ByaW50ZkEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwECFAAKAAAAAAAAAAAAI00w6ACAAAAAgAAA sQAAAAAAAAABAIAAAAAAAAAARGl2WFBsYXllckluc3RhbGxlci50eHQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAuc2NyUEsFBgAAAAABAAEA3wAAAM+AAABfAgAAAAAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA= --QzihnfFIlQfqLPZQjqzWvFUQ-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 13 04:43:49 2004 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 EAA28140 for ; Fri, 13 Aug 2004 04:43:49 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00E472B4@cherry.ease.lsoft.com>; Fri, 13 Aug 2004 4:43:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 30524036 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Aug 2004 04:43:47 -0400 Received: from 61.144.161.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Aug 2004 04:43:47 -0400 Received: from KSProsonna (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I2D00HAAM9T2U@mta1.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Aug 2004 16:29:57 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: multipart/alternative; boundary="Boundary_(ID_w1q6OsxrdArCbEloMpma+A)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Message-ID: <000001c48111$a8a74c60$8804120a@KSProsonna> Date: Fri, 13 Aug 2004 14:13:50 +0530 Reply-To: Mailing List Sender: Mailing List From: prasanna Organization: huawei Subject: How the prefixes configured on point-to-point link are handled in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --Boundary_(ID_w1q6OsxrdArCbEloMpma+A) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi What does the following sentence (section 3.4.3.7) in the RFC 2740 mean? Router RTX examines its list of interfaces to the area. If the interface is in state Down, its prefixes are not included. If the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), its prefixes are not included (they will be included in the intra-area-prefix-LSA for the link instead). If the interface type is Point-to-MultiPoint, or the interface is in state Loopback, or the interface connects to a point-to-point link which has not been assigned a prefix, then the site-local and global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area- prefix-LSA, setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. Otherwise, the list of site-local and global prefixes configured in RTX for the link are copied into the intra-area-prefix-LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the interface's output cost. Considering the following example RTA-------------------RTB Does it mean that RTA will advertise the prefix configured on serial 1 with LA bit set, iff there is no prefix configured on the serial1 of RTB? Thanx and regards Prasanna --Boundary_(ID_w1q6OsxrdArCbEloMpma+A) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi

What does the following sentence (section 3.4.3.7) in the RFC 2740 mean?

 

Router RTX examines its list of interfaces to the area. If the

      interface is in state Down, its prefixes are not included. If the

      interface has been reported in RTX's router-LSA as a Type 2 link

      description (link to transit network), its prefixes are not

      included (they will be included in the intra-area-prefix-LSA for

      the link instead). If the interface type is Point-to-MultiPoint,

      or the interface is in state Loopback, or the interface connects

      to a point-to-point link which has not been assigned a prefix,

      then the site-local and global scope IPv6 addresses associated

      with the interface (if any) are copied into the intra-area-

      prefix-LSA, setting the LA-bit in the PrefixOptions field, and

      setting the PrefixLength to 128 and the Metric to 0.  Otherwise,

      the list of site-local and global prefixes configured in RTX for

      the link are copied into the intra-area-prefix-LSA by specifying

      the PrefixLength, PrefixOptions, and Address Prefix fields. The

      Metric field for each of these prefixes is set to the interface's

      output cost.

 

Considering the following example

 

RTA<serial 1>-------------------<serial1>RTB

 

Does it mean that RTA will advertise the prefix configured on serial 1 with LA bit set, iff there is no prefix configured on the serial1 of RTB?

 

Thanx and regards

Prasanna

--Boundary_(ID_w1q6OsxrdArCbEloMpma+A)-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 13 06:23:17 2004 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 GAA03914 for ; Fri, 13 Aug 2004 06:23:16 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00E474E3@cherry.ease.lsoft.com>; Fri, 13 Aug 2004 6:23:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 30538015 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Aug 2004 06:23:15 -0400 Received: from 192.91.191.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Aug 2004 06:13:12 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Aug 2004 11:13:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802870AA6@baker.datcon.co.uk> Date: Fri, 13 Aug 2004 11:12:54 +0100 Reply-To: Mailing List Sender: Mailing List From: Nic Neate Subject: Re: How the prefixes configured on point-to-point link are handle d in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Prasanna, In the case of point-to-point links, I think the text you have quoted is just saying that the IPv6 prefixes configured on an interface are advertised in the Intra-area-prefix-LSA in preference to interface addresses. The interface addresses are only advertised when there are no prefixes configured. Hence in your example, RTA will advertise the prefixes configured on serial 1 if there are any, and if not will advertise the site-local and global interface addresses. RTA does not know what prefix configuration is on RTB - the purpose of the Intra-area-prefix-LSA is for him to discover that. Hope this helps. Nic --------- Nic Neate Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: nic.neate@dataconnection.com Web: http://www.dataconnection.com -----Original Message----- From: prasanna [mailto:KSPrasanna@HUAWEI.COM] Sent: Friday, August 13, 2004 9:44 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: How the prefixes configured on point-to-point link are handled in OSPFv3 Hi What does the following sentence (section 3.4.3.7) in the RFC 2740 mean? Router RTX examines its list of interfaces to the area. If the interface is in state Down, its prefixes are not included. If the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), its prefixes are not included (they will be included in the intra-area-prefix-LSA for the link instead). If the interface type is Point-to-MultiPoint, or the interface is in state Loopback, or the interface connects to a point-to-point link which has not been assigned a prefix, then the site-local and global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area- prefix-LSA, setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. Otherwise, the list of site-local and global prefixes configured in RTX for the link are copied into the intra-area-prefix-LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the interface's output cost. Considering the following example RTA-------------------RTB Does it mean that RTA will advertise the prefix configured on serial 1 with LA bit set, iff there is no prefix configured on the serial1 of RTB? Thanx and regards Prasanna From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 13 16:19:54 2004 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 QAA15230 for ; Fri, 13 Aug 2004 16:19:53 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00E47F7F@cherry.ease.lsoft.com>; Fri, 13 Aug 2004 16:19:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 30619926 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Aug 2004 16:19:52 -0400 Received: from 216.82.240.99 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Aug 2004 16:19:52 -0400 X-VirusChecked: Checked X-Env-Sender: rmalhotra@bankofny.com X-Msg-Ref: server-8.tower-85.messagelabs.com!1092428386!162284 X-StarScan-Version: 5.2.10; banners=bankofny.com,-,- X-Originating-IP: [160.254.107.25] Received: (qmail 2957 invoked from network); 13 Aug 2004 20:19:46 -0000 Received: from unknown (HELO lgsbrc01.bankofny.com) (160.254.107.25) by server-8.tower-85.messagelabs.com with SMTP; 13 Aug 2004 20:19:46 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Fri, 13 Aug 2004 16:19:45 -0400 Reply-To: Mailing List Sender: Mailing List From: rmalhotra@BANKOFNY.COM Subject: Ravi Malhotra is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I will be out of the office starting 08/13/2004 and will not return until 08/30/2004. I will respond to your message when I return. Thank You, Ravi Malhotra ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. From owner-ospf@PEACH.EASE.LSOFT.COM Sun Aug 15 12:28:59 2004 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 MAA07090 for ; Sun, 15 Aug 2004 12:28:59 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00E4A53E@cherry.ease.lsoft.com>; 15 Aug 2004 12:28:57 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 30846261 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 15 Aug 2004 12:28:55 -0400 Received: from 207.217.120.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 15 Aug 2004 12:28:12 -0400 Received: from sdn-ap-004castocp0502.dialsprint.net ([63.187.33.248] helo=earthlink.net) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BwNrd-0003Qw-00 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 15 Aug 2004 09:28:10 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: <41089B8E.7000209@earthlink.net> <4113F790.5050702@xebeo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <411F8EFA.90108@earthlink.net> Date: Sun, 15 Aug 2004 09:27:38 -0700 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Comments on draft-spagnolo-manet-ospf-design-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tony and all, Thanks for your comments. Please see my response to two of your comments below. Tony Przygienda wrote: > > > Richard, Gary, Russ, > > chewed my way through the recent threads and simulation results and here > are my 'meta'-comments. > From simple to hard: > > a) The simulation is considering relatively-low-rate-of-neighbor-change > scenarios to jump to > the conclusion that incremental-hellos are of little value (as has been > observed by other people). > On one hand, I agree obviously with the argument that with higher > density of nodes can cause > much higher rates of neighbor change as well as neighbor numbers, on the > other hand, the > complexity of the proposals is low enough to make the incremental-hellos > a belts-and-suspenders > optimization kind of thing, even if the link bandwidth overhead will not > be staggering. > Finally, I didn't drill through the proof of TBRPF to have an opinion as > to the merits > of either proposal but Russ's stuff looks simple enough ;-) Actually, the main problem with Cisco's Hello protocol is the additional overhead due to the unicast Hello requests, and the unicast replies to those requests. In dense, highly mobile networks, this can generate a lot of additional packets (as I discussed in a previous message) and can actually generate more overhead than full Hellos. (In highly mobile networks, it is desirable to use a smaller Hello Interval for faster response to topology changes, so it is important to minimize the size of Hellos in such networks.) The incremental Hello protocol of TBRPF does not generate any packets in addition to the one Hello per Hello Interval, but reports each neighbor change in at most 3 (or k) consecutive Hellos. To see how much overhead can be reduced by using incremental Hellos versus full Hellos, I ran some ns-2 simulations. I compared the incremental Hello protocol of TBRPF (RFC 3684) to a modification of this protocol which uses full Hellos similar to OSPF (each seen neighbor is included in each Hello). Both protocols were run over IP over IEEE 802.11 with rate 2 Mbps. The simulation model used 100 and 200 nodes in a 670x670 meter square, with a transmission radius of 250 meters. Nodes moved according to the the random waypoint model with maximum node speeds from 5 ms to 30 m/s and a pause time of 0. The Hello Interval was 1 second (reasonable for high mobility). The simulation was run for 500 seconds for 100 nodes and 200 seconds for 200 nodes. The results below show the overhead in kbps for Hello packets: Max speed Full Hellos Incremental Hellos % reduction --------- ----------- ------------------ ----------- 100 nodes 5 m/s 201.9 kbps 70.0 kbps 65.3% 100 nodes 10 m/s 220.1 kbps 73.8 kbps 66.5% 100 nodes 20 m/s 206.4 kbps 79.2 kbps 61.6% 100 nodes 30 m/s 215.2 kbps 85.0 kbps 60.5% 200 nodes 20 m/s 708 kbps 198 kbps 72% The results show that incremental Hellos reduced the overhead by about 72% for 200 nodes, and 60% to 65% for 100 nodes (depending on the node speed). The additional overhead for LS updates was 58.7 kbps for 100 nodes and 20 m/s. (TBRPF uses an efficient method for disseminating partial topology information which uses incremental LS updates that share the same packets as Hellos.) > > b) Obviously flooding is a more interesting topic and I liked to read > all the interesting tossing of ideas. > i) As first observation, the predicting of transitions between > acknowledgable and non-to-be-acked LSAs > will be hard (more in c) or rather prohibitive in terms of computing > power if done well. > ii) As second, having two different flooding mechanisms flipping will > make something that is very fragile doubly so > so it should be probably kept as a life-saving mechanism only. > iii) Third, from my experience with OSPF & ISIS flooding implementation > and deployment I observed that ISIS > flooding tended to be somehow simpler to implement and debug and keep > stable in the field. BDR did not buy much > in practical deployment and the initial-TDBX was somehow faster but > insignificantly so. My point is probably > that if you find that unreliable flooding is in most cases a good or > better solution, it may not be worth to > build a hybrid or tweak reliable flooding much (albeit the protocol > definitely very much deviates from OSPF then ;-) > The cost is however that you have to shape the flooding on the link (the > famous 33msec timer that can > be deadly for a large-scale implementatoin if done naively) but that can > be implemented using proper > leaky-bucket techniques fairly cheaply. > The argument about mobile-non-moving networks is strange to me (I mean > the sensors network thing) since > it seems to go into the direction of an orthogonal, low link quality-low > bandwith routing rather than mobile routing (kind like ALSR). > iv) Fourth, prunning of the flooding tree (MBR work, flooding spanning > tree and such) is hard to get right > and I don't know which of the ideas have most merit. I have to read and > think more here. > The MBR looks reasonable to me (albeit the algorithms > to be run are a tad convoluted), I also always liked the > flooding-spanning-tree idea with a token passed > around to generate the spanning tree and am surprised nobody picked up > on that. This is similar to the CDS approach, since the non-leaf nodes of a spanning tree form a CDS. Instead of constructing a tree (which may depend on the global topology), in a mobile network it may be better to select the CDS nodes based on local topology. I.e., each node decides whether it is in the CDS based on 2-hop neighbor information. However, I agree with you that a source-independent approach is simpler than the source-dependent MPR approach. Whether to use a (source-independent) CDS or (source-dependent) MPRs is an issue that needs to discussed. Richard > > c) Finally, I personally think from having seen it in another context > that the 'predicting future' to know when to ACK > and when not is > bound to either fail or end up in some pretty heavy math that cannot be > run real-time. Either we're dealing > with something that is unpredictable (in terms of self-similarity > beta=0.5), kind like exponential distribution or > otherwise we can think about stuff in terms of self-similar pattern > (since I do not believe that a single correlation > over a well-known time-scale can be observed). If we know the beta (or > measure it, which is > a tad expensive computationally), there are methods to detect the > time-scale of trends that we encounter (and therefore > predict the future but only in terms of absolute beta, you know that the > trend will persist with some probability > but you cannot know which direction it is heading) and based on that an > educated guess could be taken. But this > again takes some serious computing power which I cannot believe will pay > in mobile nodes just to optimize flooding. And > in case you can do all that, yes, the at-source-squelching approach > works much better that receiver based for > couple of reasons I won't dwell further into. > > As a 'meta'-'meta' in connection to the group's meeting (sorry for this > time, I try to be in D.C.) I think even more > than before that the wireless extensions should be kept in a special > OSPF area. The ideas passed around are radical enough > to almost certainly make a general-interface-type-solution overburdened > and the mix of different interfaces in same > area very fragile deployment-wise. > > thanks > > -- tony > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 16 10:24:11 2004 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 KAA06454 for ; Mon, 16 Aug 2004 10:24:10 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00E4BAA6@cherry.ease.lsoft.com>; Mon, 16 Aug 2004 10:24:09 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 30990927 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Aug 2004 10:24:07 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Aug 2004 10:24:07 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 Aug 2004 10:33:44 -0400 X-BrightmailFiltered: true Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7GEO49d017761 for ; Mon, 16 Aug 2004 10:24:04 -0400 (EDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.11.2/CISCO.WS.1.2) id i7GEO4H01290 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Aug 2004 10:24:04 -0400 (EDT) References: <41089B8E.7000209@earthlink.net> <4113F790.5050702@xebeo.com> <411F8EFA.90108@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Message-ID: <20040816142404.GC1238@cisco.com> Date: Mon, 16 Aug 2004 10:24:04 -0400 Reply-To: Mailing List Sender: Mailing List From: "Madhavi W. Chandra" Subject: Re: Comments on draft-spagnolo-manet-ospf-design-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <411F8EFA.90108@earthlink.net> Precedence: list On Sun, Aug 15, 2004 at 09:27:38AM -0700, Richard Ogier wrote: > Tony and all, > > Thanks for your comments. Please see my response to > two of your comments below. > > > Tony Przygienda wrote: > > > > > > >Richard, Gary, Russ, > > > >chewed my way through the recent threads and simulation results and here > >are my 'meta'-comments. > >From simple to hard: > > > >a) The simulation is considering relatively-low-rate-of-neighbor-change > >scenarios to jump to > >the conclusion that incremental-hellos are of little value (as has been > >observed by other people). > >On one hand, I agree obviously with the argument that with higher > >density of nodes can cause > >much higher rates of neighbor change as well as neighbor numbers, on the > >other hand, the > >complexity of the proposals is low enough to make the incremental-hellos > >a belts-and-suspenders > >optimization kind of thing, even if the link bandwidth overhead will not > >be staggering. > >Finally, I didn't drill through the proof of TBRPF to have an opinion as > >to the merits > >of either proposal but Russ's stuff looks simple enough ;-) > > > Actually, the main problem with Cisco's Hello protocol is the > additional overhead due to the unicast Hello requests, and the unicast > replies to those requests. In dense, highly mobile networks, this can > generate a lot of additional packets (as I discussed in a previous > message) and can actually generate more overhead than full Hellos. > (In highly mobile networks, it is desirable to use a smaller Hello > Interval for faster response to topology changes, so it is important > to minimize the size of Hellos in such networks.) Actually, our mechanism is flexible. We have the ability to send all data in a Hello for k consecutive Hellos (persistently)...or only partial data in k consecutive Hellos (for example, neighbors that are being dropped)...or send data only in one Hello. This coupled with the reply/request mechanism provides flexibility. Although we haven't been able to run simulations yet, its seems that sending data in k consecutive Hellos in a low-rate-of-change network is excessive. So, it may not be the case that a flat 'send in k consecutive Hellos' is an optimum approach. In any case, this is work that should be considered in the design team....and provided as an outcome of the DT. -Madhavi > The incremental Hello protocol of TBRPF does not generate any packets > in addition to the one Hello per Hello Interval, but reports each > neighbor change in at most 3 (or k) consecutive Hellos. > > To see how much overhead can be reduced by using incremental > Hellos versus full Hellos, I ran some ns-2 simulations. > I compared the incremental Hello protocol of TBRPF (RFC 3684) > to a modification of this protocol which uses full Hellos > similar to OSPF (each seen neighbor is included in each Hello). > Both protocols were run over IP over IEEE 802.11 with rate 2 Mbps. > > The simulation model used 100 and 200 nodes in a 670x670 meter square, > with a transmission radius of 250 meters. Nodes moved according to the > the random waypoint model with maximum node speeds from 5 ms to 30 m/s > and a pause time of 0. The Hello Interval was 1 second (reasonable > for high mobility). The simulation was run for 500 seconds for > 100 nodes and 200 seconds for 200 nodes. The results below show the > overhead in kbps for Hello packets: > > Max speed Full Hellos Incremental Hellos % reduction > --------- ----------- ------------------ ----------- > 100 nodes 5 m/s 201.9 kbps 70.0 kbps 65.3% > 100 nodes 10 m/s 220.1 kbps 73.8 kbps 66.5% > 100 nodes 20 m/s 206.4 kbps 79.2 kbps 61.6% > 100 nodes 30 m/s 215.2 kbps 85.0 kbps 60.5% > > 200 nodes 20 m/s 708 kbps 198 kbps 72% > > The results show that incremental Hellos reduced the overhead by about > 72% for 200 nodes, and 60% to 65% for 100 nodes (depending on the node > speed). The additional overhead for LS updates was 58.7 kbps for > 100 nodes and 20 m/s. (TBRPF uses an efficient method for disseminating > partial topology information which uses incremental LS updates that > share the same packets as Hellos.) > > > > >b) Obviously flooding is a more interesting topic and I liked to read > >all the interesting tossing of ideas. > >i) As first observation, the predicting of transitions between > >acknowledgable and non-to-be-acked LSAs > >will be hard (more in c) or rather prohibitive in terms of computing > >power if done well. > >ii) As second, having two different flooding mechanisms flipping will > >make something that is very fragile doubly so > >so it should be probably kept as a life-saving mechanism only. > >iii) Third, from my experience with OSPF & ISIS flooding implementation > >and deployment I observed that ISIS > >flooding tended to be somehow simpler to implement and debug and keep > >stable in the field. BDR did not buy much > >in practical deployment and the initial-TDBX was somehow faster but > >insignificantly so. My point is probably > >that if you find that unreliable flooding is in most cases a good or > >better solution, it may not be worth to > >build a hybrid or tweak reliable flooding much (albeit the protocol > >definitely very much deviates from OSPF then ;-) > >The cost is however that you have to shape the flooding on the link (the > >famous 33msec timer that can > >be deadly for a large-scale implementatoin if done naively) but that can > >be implemented using proper > >leaky-bucket techniques fairly cheaply. > >The argument about mobile-non-moving networks is strange to me (I mean > >the sensors network thing) since > >it seems to go into the direction of an orthogonal, low link quality-low > >bandwith routing rather than mobile routing (kind like ALSR). > >iv) Fourth, prunning of the flooding tree (MBR work, flooding spanning > >tree and such) is hard to get right > >and I don't know which of the ideas have most merit. I have to read and > >think more here. > >The MBR looks reasonable to me (albeit the algorithms > >to be run are a tad convoluted), I also always liked the > >flooding-spanning-tree idea with a token passed > >around to generate the spanning tree and am surprised nobody picked up > >on that. > > This is similar to the CDS approach, since the non-leaf > nodes of a spanning tree form a CDS. Instead of constructing > a tree (which may depend on the global topology), in a mobile > network it may be better to select the CDS nodes based on > local topology. I.e., each node decides whether it is in the > CDS based on 2-hop neighbor information. > > However, I agree with you that a source-independent approach > is simpler than the source-dependent MPR approach. > Whether to use a (source-independent) CDS or (source-dependent) > MPRs is an issue that needs to discussed. > > Richard > > > > >c) Finally, I personally think from having seen it in another context > >that the 'predicting future' to know when to ACK > >and when not is > >bound to either fail or end up in some pretty heavy math that cannot be > >run real-time. Either we're dealing > >with something that is unpredictable (in terms of self-similarity > >beta=0.5), kind like exponential distribution or > >otherwise we can think about stuff in terms of self-similar pattern > >(since I do not believe that a single correlation > >over a well-known time-scale can be observed). If we know the beta (or > >measure it, which is > >a tad expensive computationally), there are methods to detect the > >time-scale of trends that we encounter (and therefore > >predict the future but only in terms of absolute beta, you know that the > >trend will persist with some probability > >but you cannot know which direction it is heading) and based on that an > >educated guess could be taken. But this > >again takes some serious computing power which I cannot believe will pay > >in mobile nodes just to optimize flooding. And > >in case you can do all that, yes, the at-source-squelching approach > >works much better that receiver based for > >couple of reasons I won't dwell further into. > > > >As a 'meta'-'meta' in connection to the group's meeting (sorry for this > >time, I try to be in D.C.) I think even more > >than before that the wireless extensions should be kept in a special > >OSPF area. The ideas passed around are radical enough > >to almost certainly make a general-interface-type-solution overburdened > >and the mix of different interfaces in same > >area very fragile deployment-wise. > > > >thanks > > > >-- tony > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 17 00:50:45 2004 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 AAA07185 for ; Tue, 17 Aug 2004 00:50:45 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00E4D061@cherry.ease.lsoft.com>; Tue, 17 Aug 2004 0:50:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31098757 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Aug 2004 00:50:42 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Aug 2004 00:50:41 -0400 Received: from sdn-ap-002castocp0286.dialsprint.net ([63.187.9.32] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Bwvvb-0007KK-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Aug 2004 21:50:32 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41089B8E.7000209@earthlink.net> <4113F790.5050702@xebeo.com> <411F8EFA.90108@earthlink.net> <20040816142404.GC1238@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41218EAF.2090406@earthlink.net> Date: Mon, 16 Aug 2004 21:50:55 -0700 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Comments on draft-spagnolo-manet-ospf-design-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20040816142404.GC1238@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Madhavi W. Chandra wrote: > > Actually, our mechanism is flexible. We have the ability to send > all data in a Hello for k consecutive Hellos (persistently)...or only > partial data in k consecutive Hellos (for example, neighbors that are > being dropped)...or send data only in one Hello. This coupled > with the reply/request mechanism provides flexibility. > > Although we haven't been able to run simulations yet, its seems that > sending data in k consecutive Hellos in a low-rate-of-change network is > excessive. So, it may not be the case that a flat 'send in k > consecutive Hellos' is an optimum approach. My first thought is that in a low-rate-of-change network, there won't be many changes to report! So, reporting each (infrequent) change in 3 consecutive Hellos would add very little overhead. Even if there is one neighbor change per Hello, reporting each change 3 times adds only about 8 bytes (2 router IDs) per Hello (compared to reporting each change only once). However, we also have to consider the probability that (in your Hello protocol) some neighbors will not hear the Hello reporting the change and will thus unicast a Hello request, which also results in a reply to the request. Even if there are only 20 neighbors, and even if only 10% of Hellos are missed, then on average 2 neighbors will send a Hello request, which, being a separate unicast packet, would result in much more overhead than 2 router IDs. Please correct me if I am missing something. [I should clarify that TBRPF does not report every neighbor change 3 (or k) times, but AT MOST 3 (or k) times. A node stops reporting a neighbor change if it is clear the the neighbor already knows about the change.] I agree that your protocol can report each change k times (persistently, with the N bit set), but you still require the initial Hello (with the N bit NOT set) to be received, so that doesn't help in terms of avoiding Hello replies. Maybe you are now saying that your protocol can report each change k times with the N bit NOT set, but your draft does not mention that possibility. Perhaps a MAY or SHOULD should be added to make the reader aware of this possibility. The nice thing about the TBRPF Hello protocol is that it shows that Hello replies are not needed. Unless simulations show that using Hello replies results in a significant overhead reduction, then it might be best to simplify the protocol and omit Hello replies. Richard From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 17 11:40:58 2004 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 LAA24107 for ; Tue, 17 Aug 2004 11:40:56 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00E4DA8B@cherry.ease.lsoft.com>; Tue, 17 Aug 2004 11:40:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31177373 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Aug 2004 11:40:54 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Aug 2004 11:40:54 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 17 Aug 2004 11:40:54 -0400 X-BrightmailFiltered: true Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7HFeq9d003901 for ; Tue, 17 Aug 2004 11:40:52 -0400 (EDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.11.2/CISCO.WS.1.2) id i7HFeqa01784 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Aug 2004 11:40:52 -0400 (EDT) References: <41089B8E.7000209@earthlink.net> <4113F790.5050702@xebeo.com> <411F8EFA.90108@earthlink.net> <20040816142404.GC1238@cisco.com> <41218EAF.2090406@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Message-ID: <20040817154052.GC1758@cisco.com> Date: Tue, 17 Aug 2004 11:40:52 -0400 Reply-To: Mailing List Sender: Mailing List From: "Madhavi W. Chandra" Subject: Re: Comments on draft-spagnolo-manet-ospf-design-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41218EAF.2090406@earthlink.net> Precedence: list On Mon, Aug 16, 2004 at 09:50:55PM -0700, Richard Ogier wrote: > Madhavi W. Chandra wrote: > > > > > Actually, our mechanism is flexible. We have the ability to send > > all data in a Hello for k consecutive Hellos (persistently)...or only > > partial data in k consecutive Hellos (for example, neighbors that are > > being dropped)...or send data only in one Hello. This coupled > > with the reply/request mechanism provides flexibility. > > > > Although we haven't been able to run simulations yet, its seems that > > sending data in k consecutive Hellos in a low-rate-of-change network is > > excessive. So, it may not be the case that a flat 'send in k > > consecutive Hellos' is an optimum approach. > > My first thought is that in a low-rate-of-change network, there > won't be many changes to report! So, reporting each (infrequent) > change in 3 consecutive Hellos would add very little overhead. > Even if there is one neighbor change per Hello, reporting > each change 3 times adds only about 8 bytes (2 router IDs) per Hello > (compared to reporting each change only once). However, we also have > to consider the probability that (in your Hello protocol) some > neighbors will not hear the Hello reporting the change and will > thus unicast a Hello request, which also results in a reply to > the request. Even if there are only 20 neighbors, and even if > only 10% of Hellos are missed, then on average 2 neighbors will > send a Hello request, which, being a separate unicast packet, would > result in much more overhead than 2 router IDs. Please correct me > if I am missing something. > > [I should clarify that TBRPF does not report every neighbor change > 3 (or k) times, but AT MOST 3 (or k) times. A node stops reporting > a neighbor change if it is clear the the neighbor already knows > about the change.] > > I agree that your protocol can report each change > k times (persistently, with the N bit set), but you still > require the initial Hello (with the N bit NOT set) to be > received, so that doesn't help in terms of avoiding Hello > replies. Maybe you are now saying that your protocol can > report each change k times with the N bit NOT set, but your > draft does not mention that possibility. Perhaps a MAY or SHOULD > should be added to make the reader aware of this possibility. The N bit is set to indicate that "the TLVs included in this Hellos are being sent persistently...and there is more state associated with this Hello that is not being sent persistently". This would be used to send partial-state persistently. If you are sending full state persistently (as in TBRPF), then you simply send the same SCS number WITHOUT the N bit set for k number of times. So, it's the same behavior as TBRPF. It DOES NOT depend on receiving the first Hello with a certain SCS number. I guess I thought it was implicit in the draft, but I can surely clearly state it. The Request/Reply mechanism gives you flexibility. A Hello reply is nothing more than a Full Hello. -Madhavi P.S. By the way, isn't this a discussion that we should be having on the Design Team? I'm fine either way, but I thought that's why the design team was formed. > The nice thing about the TBRPF Hello protocol is that it shows > that Hello replies are not needed. Unless simulations show > that using Hello replies results in a significant overhead > reduction, then it might be best to simplify the protocol > and omit Hello replies. > > Richard From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 17 21:03:10 2004 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 VAA28867 for ; Tue, 17 Aug 2004 21:03:09 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00E4E6B8@cherry.ease.lsoft.com>; Tue, 17 Aug 2004 21:03:09 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31229596 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Aug 2004 21:03:07 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Aug 2004 21:03:07 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C7BDC6A2045 for ; Tue, 17 Aug 2004 18:03:06 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28748-05 for ; Tue, 17 Aug 2004 18:03:06 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.51]) by prattle.redback.com (Postfix) with SMTP id C27856A2044 for ; Tue, 17 Aug 2004 18:03:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0353_01C4849D.9726C990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <035601c484bf$1ea1d9c0$0202a8c0@aceeinspiron> Date: Tue, 17 Aug 2004 21:03:05 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: San Diego OSPF WG Meeting Minutes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0353_01C4849D.9726C990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The minutes are attached. Thanks to Bill Fenner for taking them. ------ Acee ------=_NextPart_000_0353_01C4849D.9726C990 Content-Type: text/plain; name="ospf-wg-minutes.txt" Content-Disposition: attachment; filename="ospf-wg-minutes.txt" Content-Transfer-Encoding: 7bit IETF 60 OSPF WG Minutes Bill Fenner (Scribe) Acee Lindem (Some Editing) Refer to the slide prsentations in conjunction with these minutes. Document Status: - Graceful Restart (RFC 3623) published - Already some ideas on having it less strict about exiting restart but maintaining the same functionality. - Flooding Reduction in Stable Topologies - Has a minor comment pending that should be able to be handled with an rfc-editor note OSPF Wireless Design Team: Tom Henderson: Everyone's waiting for someone else to step forward - what are the expectations wrt deadliens and organization? Acee: We should have someone leading it - not me because of my interests and job responsibilities. first thing should be requirements + problem statement, then there are a lot of ways to handle the problems that are stated. Common thread of all solutions is flooding reduction. Tom: Of the people in the room today, maybe let's meet to discuss next steps. Rohit: This was discussed - had a plan for how this was going to proceed and what the deliverables would be - formalize that and that'll be the design team charter. Note: Change from web agenda: Manet considerations ahead of Manet extensions. Design considerations for Wireless OSPF interface - Tom Henderson (Boeing) draft-spagnolo-manet-ospf-design Summary: - Analysis of overhead; LSU flooding and Ack is dominant ways to characterize simulations independent of specifics to be able to compare different simulations - Presents some results on the improvements of reliable flooding optimizations. - More results on unreliable flooding - LSU flooding is dominant contributor; can reliable optimizations do better than 50%? - Unreliable flooding can provide up to 10x reduction without sacrificing performance (large # of external LSAs are a problem) database exchange optimization may also be important in a frequently partitioning network. - List possible future work: * Flooding algorithm? * DB sync optimizations? * Differential encoding? * Limit adjacencies? Tom: Of the people in the room today, maybe let's meet to discuss next steps. Joe Macker: When you did packet delivery ratios, was it under congested or was loss just from mobility? Tom: Just mobility. Joe: Was this the draft that had the different 2026 boilerplate? Tom: this one was different; we picked it based on our intention to provide information to the design team Joe: would it be a problem if the design team picked up stuff from here? Tom: No Acee: Do you intend to keep with this future work? Should we publish this as informational as a historical record? Tom: We do intend to keep going down these paths, discuss with design team to decide next steps Acee: It's a good piece of work, it may be nice to preserve it. Sue Hares: In the paramaterization, you have neighbor change rate, but the draft seems to have a fixed 20 neighbors; is there a reason for this? Other simulations picked different values. Tom: We picked 20 as a representative number; we've done up to ~100; for a lot of these it was faster to look at different scenarios doing smaller # of nodes; have other work that shows some of the scaling performance as you increase the number of nodes. There's nothing magical about 20. For completeness, maybe we could do more. Sue: Did you go higher than 100? Tom: no Sue: That's number of nodes in the network, right? Tom: Yes. Sue: Why not use link up/down seperately from neighbors up/down? Sue: Some of the larger numbers you might see a different dominant factor Rohit: Let's have this discussion on the list. OSPF Wireless Interface Extensions - Russ White (Cisco) draft-chandra-ospf-manet-ext.txt Russ: Hello may not be a place of huge overhead, but it does pass info that may not be needed to all neighbors; looking at incremental state. Use state sequence #'s to describe current state. Joe: Optimized flooding is something we've been doing for years in manet; are you borrowing? Russ: Yes, this is very similar to OLSR, slightly different overlapping relay set. Acee: Hybrid p2mp but meshed funny. Russ: Yes, it's a single subnet. Acee: It's on one interface, but it's just who you relay to. Russ: Yes. Our assumption is that the device is going to have one "air" interface. Even if there are multiple interfaces, they're all going to work the same way. Alex: With optimized flooding: how do you ensure reliability? Russ: You're still acking, and if you've suppressed your flood but you haven't heard an ack for a little longer than normal then you reflood. Alex: What if you don't have connectivity to the guy you want to hear an ack from? Russ: You wouldn't reflood, since you've lost connectivity. Alex: Worried whether it's provably reliable. Russ: I think so. Acee: If the hello overhead is < 2%, why would we want to mess with it? Russ: We may not want to; we don't know what the real overhead is. if it's so low that it's not worth it then we won't do it. Sue: On slide 6, C doesn't *stop* flooding; he just floods slower? How does C know that B has flooded? Russ: He is on the same broadcast medium, and he will see E's ACK to the packet that it got from B. Sue: If B goes away, will C ever speed up? Russ: As soon as B drops his relationship with E, the hello stuff will catch up; A will learn that B can't reach E so will tell C t to flood. Sue: Timing there is critical. Russ: Alvaro, did our simulation cover that? I don't think we know these numbers. Alvaro: I don't know. We look at the router-LSA, not hellos, so it's convergence time, not hello cycle. Tom: For hellos, is it true that there are 2 aspects changed: differential hellos but also overlaying the relay set selection on hello messages. Russ: Yes. You can do relay set selection on type1s but you've already flooded by that point so you don't save anything in the initial flood. Rohit: This applies equally to tom - purely for the MANET side, how many nodes do you expect to see? Russ: 40-1000. Joe: You can have a channel in an urban environment that fluctuates quickly, you may want some hysteresis to keep links like this from going away. Russ: Yes, we should consider this. Joe: We should talk about this on the design team; it can be disasterous to lose links briefly like this. Uoe: Is there a time the design team can meet? Possible interim meeting? Acee: Russ can sponsor one in RTP :^)! OSPFv3 Authentication Issues/Resolution - Suresh Melam (Nokia) draft-ietf-ospf-ospfv3-auth-04.txt Suresh: Will update draft based on lunchtime discussion with SEC & RTG ADs. An SA per instance is impossible to validate - any instance could use any valid SA, so one SA per link. Should we new/old IPsec drafts? Bill: Should use new because of multicast and replay protection advances. Acee: Problem with instance ids are bad on multi instances: you can use multiple SAs? Bill: But that won't protect SAs from each other. Mukesh: Plus you can't have some instances doing security and some not. Unknown: IPsec can't pick the right SA on outbound with multiple instance on the same interface. Acee: And we thought this was going to be easy! Multi-topology routing for OSPFv2 - Peter Psenak (Cisco) draft-psenak-MT-OSPF-00.txt Peter: Reuse 1583-style TOS LSAs for multi-topology use. Unknown: How does the routing table look? Peter: Depends on implementation; you can have different table per topology or all in one table. Unknown: Sounds a lot like why you go to MPLS in the first place. Acee: The alternative is multiple instances; that's more intensive with memory and processing power. I don't think those are issues with today's networking equipment. Alex: On routing tables: I know why you don't want to say why routing tables are stored. We need to worry about interoperability. If one does one thing and one does another they may not interoperate. Peter: Why? Route lookup should be the same no matter what your data structures. Looking in one table should be the same as looking in multiple tables. Acee: First issue is do we want to do this in OSPF? Alex: Another question is what about forwarding? Do we want standard way for routers to interoperate in forwarding plane? Tom henderson: Supports this becoming a WG document. We did something similar to this and found it useful to do this kind of thing without deploying a full-blown TE solution. Acee: No real opposition, some support, take it to the OSPF WG list to move forward. Padma: There are definitely ISIS multi-topology deployments. Route Attribute Opaque LSA - Acee Lindem (Redback) draft-lindem-ospf-route-attr-00.txt Unknown: Could you clarify - s this just for the next-hop or is it general? Acee: It could be general for other applications as well. Padma: For NSSA, the ABRs need to translate - what if you have several ABRs translating the same type 7 LSA? Acee: Hopefully both would be doing the same translation since they're using the same rules to select the route. If it's a multipath, it's the concatenation of the attributes. Padma: So you could have two nexthops? Acee: Hadn't thought of protection going across an NSSA boundary. Destination address filter - Acee Lindem draft-lindem-ospfv3-dest-filter-00.txt Very short on time - No comments OSPF IANA Considerations - Kireeti Kompella (Juniper) draft-kompella-ospf-iana-00.txt Kireeti: RFC 2328 doesn't have an IANA considerations section; This document goes through each number space and creates registries for them - included space for standards, experiments, private. Coming up with more when other standards bodies are using OSPF for different purposes. We need more rigor in allocating code points and a point of control. This is our "take back our protocol" program (Analogous to "take back the neighborhood"). Acee: Some codepoints you can't allocate without standards action and remain compatible. For example, there is no protocol handling for undefined link types in a router LSA. OSPF TE Capabilities - JP Vasseur (Cisco) draft-vasseur-ospf-te-caps-00.txt JP: Twp implementation: routing info LSA & TE info Acee: More discussion on this draft needed. ------=_NextPart_000_0353_01C4849D.9726C990-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 17 21:18:37 2004 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 VAA29914 for ; Tue, 17 Aug 2004 21:18:37 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00E4E5A7@cherry.ease.lsoft.com>; Tue, 17 Aug 2004 21:18:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31230882 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Aug 2004 21:18:35 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Aug 2004 21:18:35 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 31B9B645D98 for ; Tue, 17 Aug 2004 18:18:35 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01347-07 for ; Tue, 17 Aug 2004 18:18:35 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.51]) by prattle.redback.com (Postfix) with SMTP id 8F200645D95 for ; Tue, 17 Aug 2004 18:18:34 -0700 (PDT) References: <035601c484bf$1ea1d9c0$0202a8c0@aceeinspiron> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <038b01c484c1$48382490$0202a8c0@aceeinspiron> Date: Tue, 17 Aug 2004 21:18:34 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: San Diego OSPF WG Meeting Minutes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Please unicast any corrections or additions to acee@redback.com. ----- Original Message ----- From: "Acee Lindem" To: Sent: Tuesday, August 17, 2004 9:03 PM Subject: San Diego OSPF WG Meeting Minutes > The minutes are attached. Thanks to Bill Fenner for taking them. > ------ > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 18 17:02:37 2004 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 RAA16493 for ; Wed, 18 Aug 2004 17:02:36 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00E4FE7F@cherry.ease.lsoft.com>; Wed, 18 Aug 2004 17:02:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31351454 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 18 Aug 2004 17:02:33 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 18 Aug 2004 17:02:33 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 62A5BB58806 for ; Wed, 18 Aug 2004 14:02:33 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08345-06 for ; Wed, 18 Aug 2004 14:02:33 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.51]) by prattle.redback.com (Postfix) with SMTP id 9DE54B58805 for ; Wed, 18 Aug 2004 14:02:31 -0700 (PDT) References: <20040809140300.08666790034@ws1-14.us4.outblaze.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <025401c48566$ad096910$0202a8c0@aceeinspiron> Date: Wed, 18 Aug 2004 17:02:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting inactive neighbors over demand circuit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Anu, The draft doesn't specify that you have to use a router LSA, it simply uses it as an example (draft-ietf-ospf-dc-07.txt). Also note that link LSAs are not flooded over virtual links (which are demand circuits by default). Having said that, a link LSA would seem like a good choice for probing on a non-virtual OSPFv3 interface. Note that this draft has been around for quite some time and is currently in the RFC editor's queue. Thanks, Acee ----- Original Message ----- From: "armstrong mathiayalagan" To: Sent: Monday, August 09, 2004 10:02 AM Subject: Detecting inactive neighbors over demand circuit > Hi, > This draft recommends (May clause) Router LSA to be flooded for Neighbor > probing. > With respect to the applicability of this draft to OSPFv3, I feel Link LSA > is a good choice for using in neighbor probing than Router LSA. > In Demand Circuit, there are more chances for having LSAs of different > sequence number at both ends. > If neighbor probing uses Router LSA, if the Router LSA is having higher > sequence number than the neighbors database, then the neighbor will flood > these LSA in all the non demand circuit interface. This can be avoided by > using Link LSA. > Comments are welcome. > > Regards, > Anu > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 18 17:19:12 2004 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 RAA19250 for ; Wed, 18 Aug 2004 17:19:11 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00E4FE32@cherry.ease.lsoft.com>; Wed, 18 Aug 2004 17:19:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31353468 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 18 Aug 2004 17:19:08 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 18 Aug 2004 17:19:08 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D347EA27490 for ; Wed, 18 Aug 2004 14:19:08 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11210-08 for ; Wed, 18 Aug 2004 14:19:08 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.51]) by prattle.redback.com (Postfix) with SMTP id 69B30A2748D for ; Wed, 18 Aug 2004 14:19:07 -0700 (PDT) References: <000001c48111$a8a74c60$8804120a@KSProsonna> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_026D_01C48547.766A0B90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <027001c48568$fde9afa0$0202a8c0@aceeinspiron> Date: Wed, 18 Aug 2004 17:19:04 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: How the prefixes configured on point-to-point link are handled in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_026D_01C48547.766A0B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Prasanna, Refer to:=20 http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0405&L=3Dospf&T=3D0&F=3D= &S=3D&P=3D2297 The answer to your question is "no", the prefix configuration of RTB = doesn't have bearing on what is advertised.=20 ----- Original Message -----=20 From: prasanna=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Friday, August 13, 2004 4:43 AM Subject: How the prefixes configured on point-to-point link are = handled in OSPFv3 Hi What does the following sentence (section 3.4.3.7) in the RFC 2740 = mean? Router RTX examines its list of interfaces to the area. If the interface is in state Down, its prefixes are not included. If = the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), its prefixes are not included (they will be included in the intra-area-prefix-LSA for the link instead). If the interface type is Point-to-MultiPoint, or the interface is in state Loopback, or the interface connects to a point-to-point link which has not been assigned a prefix, then the site-local and global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area- prefix-LSA, setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. Otherwise, the list of site-local and global prefixes configured in RTX for the link are copied into the intra-area-prefix-LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the = interface's output cost. Considering the following example RTA-------------------RTB Does it mean that RTA will advertise the prefix configured on serial 1 = with LA bit set, iff there is no prefix configured on the serial1 of = RTB? Thanx and regards Prasanna ------=_NextPart_000_026D_01C48547.766A0B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Prasanna,
 
Refer to:
 
http://peach.ease.lsoft.com= /scripts/wa.exe?A2=3Dind0405&L=3Dospf&T=3D0&F=3D&S=3D&= ;P=3D2297
 
The answer to your question is "no", = the prefix=20 configuration of RTB doesn't have
bearing on what is advertised. =
----- Original Message -----
From:=20 prasanna
Sent: Friday, August 13, 2004 = 4:43=20 AM
Subject: How the prefixes = configured on=20 point-to-point link are handled in OSPFv3

Hi

What does = the following=20 sentence (section 3.4.3.7) in the RFC 2740 mean?

 

Router RTX=20 examines its list of interfaces to the area. If = the

     =20 interface is in state Down, its prefixes are not included. If=20 the

     =20 interface has been reported in RTX's router-LSA as a Type 2=20 link

     =20 description (link to transit network), its prefixes are=20 not

     =20 included (they will be included in the intra-area-prefix-LSA=20 for

     =20 the link instead). If the = interface type is=20 Point-to-MultiPoint,

     =20 or the interface is in state Loopback, or the interface=20 connects

     =20 to a point-to-point link which has not been assigned a=20 prefix,

     =20 then the site-local and global scope IPv6 addresses=20 associated

     =20 with the interface (if any) are copied into the=20 intra-area-

     =20 prefix-LSA, setting the LA-bit in the PrefixOptions field,=20 and

     =20 setting the PrefixLength to 128 and the Metric to=20 0. =20 Otherwise,

     =20 the list of site-local and global prefixes configured in RTX=20 for

     =20 the link are copied into the intra-area-prefix-LSA by=20 specifying

  =20    the PrefixLength, PrefixOptions, and Address Prefix = fields.=20 The

     =20 Metric field for each of these prefixes is set to the=20 interface's

     =20 output cost.

 

Considering = the=20 following example

 

RTA<serial=20 1>-------------------<serial1>RTB

 

Does it = mean that RTA=20 will advertise the prefix configured on serial 1 with LA bit set, iff = there is=20 no prefix configured on the serial1 of RTB?

 

Thanx and=20 regards

Prasanna

------=_NextPart_000_026D_01C48547.766A0B90-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 19 02:44:43 2004 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 CAA05821 for ; Thu, 19 Aug 2004 02:44:42 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00E50B53@cherry.ease.lsoft.com>; Thu, 19 Aug 2004 2:44:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31403493 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 Aug 2004 02:44:34 -0400 Received: from 203.197.138.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 19 Aug 2004 02:44:33 -0400 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail1.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Thu, 19 Aug 2004 12:09:10 +0530 Received: from vanitha (vanitha.future.futsoft.com [10.6.4.92]) by kailash.future.futsoft.com (8.12.8/8.12.8) with SMTP id i7J6bbcB016395 for ; Thu, 19 Aug 2004 12:07:37 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C485E5.12EC0840" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <000d01c485b6$f933cc40$5c04060a@future.futsoft.com> Date: Thu, 19 Aug 2004 12:07:17 +0530 Reply-To: Mailing List Sender: Mailing List From: vanitha Subject: Re: How the prefixes configured on point-to-point link are handled in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <027001c48568$fde9afa0$0202a8c0@aceeinspiron> Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C485E5.12EC0840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Ace, What is the advantage we gain by setting LA bit for /128 addresses of point to point interfaces. LA bit setting is useful for making virtual link up. That is taken care by the below lines in the RFC. If RTX has one or more virtual links configured through the area, it includes one of its site-local or global scope IPv6 interface addresses in the LSA (if it hasn't already), setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. This information will be used later in the routing calculation so that the two ends of the virtual link can discover each other's IPv6 addresses Regards, Vanitha N. -----Original Message----- [vanitha] From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee Lindem Sent: Thursday, August 19, 2004 2:49 AM To: OSPF@peach.ease.lsoft.com Subject: Re: How the prefixes configured on point-to-point link are handled in OSPFv3 Hi Prasanna, Refer to: http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0405&L=ospf&T=0&F=&S=&P=229 7 The answer to your question is "no", the prefix configuration of RTB doesn't have bearing on what is advertised. ----- Original Message ----- From: prasanna To: OSPF@PEACH.EASE.LSOFT.COM Sent: Friday, August 13, 2004 4:43 AM Subject: How the prefixes configured on point-to-point link are handled in OSPFv3 Hi What does the following sentence (section 3.4.3.7) in the RFC 2740 mean? Router RTX examines its list of interfaces to the area. If the interface is in state Down, its prefixes are not included. If the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), its prefixes are not included (they will be included in the intra-area-prefix-LSA for the link instead). If the interface type is Point-to-MultiPoint, or the interface is in state Loopback, or the interface connects to a point-to-point link which has not been assigned a prefix, then the site-local and global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area- prefix-LSA, setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. Otherwise, the list of site-local and global prefixes configured in RTX for the link are copied into the intra-area-prefix-LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the interface's output cost. Considering the following example RTA-------------------RTB Does it mean that RTA will advertise the prefix configured on serial 1 with LA bit set, iff there is no prefix configured on the serial1 of RTB? Thanx and regards Prasanna *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_000E_01C485E5.12EC0840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Ace,
        =    =20 What is the advantage we gain b= y setting=20 LA bit for /128 addresses of point to point interfaces.
        =    =20 LA bit setting is useful f= or making=20 virtual link up. That is taken care by the below lines in the=20 RFC.
        =    =20
If RTX has one or more virtual links= configured through the area,
      it includes= one=20 of its site-local or global scope IPv6=20 interface
      addresses in the LSA (if it has= n't=20 already), setting the LA-bit in
      the=20 PrefixOptions field, and setting the PrefixLength to 128=20 and
      the Metric to 0. This information wil= l be=20 used later in the
      routing calculation so = that=20 the two ends of the virtual link can
      disc= over=20 each other's IPv6 addresses
 
Regards,
Vanitha N.
 
-----Original Message-----
<= FONT=20 face=3DArial color=3D#0000ff>[vanitha]  
Fr= om:=20 Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee= Lindem
Sent: Thursday, August 19, 2004 2:49 AM
To:= OSPF@peach.ease.lsoft.com
Subject: Re: How the prefixes config= ured=20 on point-to-point link are handled in OSPFv3

Hi Prasanna,
 
Refer to:
 
http://peach.ease.lsoft.com/s= cripts/wa.exe?A2=3Dind0405&L=3Dospf&T=3D0&F=3D&S=3D&P= =3D2297
 
The answer to your question is "no", the= prefix=20 configuration of RTB doesn't have
bearing on what is advertised.
----- Original Message -----
F= rom:=20 prasanna
Sent: Friday, August 13, 2004 4:= 43=20 AM
Subject: How the prefixes config= ured on=20 point-to-point link are handled in OSPFv3

Hi

What does th= e=20 following sentence (section 3.4.3.7) in the RFC 2740 mean?

 

Route= r RTX=20 examines its list of interfaces to the area. If the

 = ;    =20 interface is in state Down, its prefixes are not included. If=20 the

 = ;    =20 interface has been reported in RTX's router-LSA as a Type 2=20 link

 = ;    =20 description (link to transit network), its prefixes are=20 not

 = ;    =20 included (they will be included in the intra-area-prefix-LSA=20 for

 = ;    =20 the link instead). If the interfac= e type=20 is Point-to-MultiPoint,

     =20 or the interface is in state Loopback, or the interface=20 connects

     =20 to a point-to-point link which has not been assigned a=20 prefix,

     =20 then the site-local and global scope IPv6 addresses=20 associated

     =20 with the interface (if any) are copied into the=20 intra-area-

     =20 prefix-LSA, setting the LA-bit in the PrefixOptions field,=20 and

     =20 setting the PrefixLength to 128 and the Metric to=20 0. = ;=20 Otherwise,

 = ;    =20 the list of site-local and global prefixes configured in RTX=20 for

 = ;    =20 the link are copied into the intra-area-prefix-LSA by=20 specifying

 = ; =20    the PrefixLength, PrefixOptions, and Address Prefix= fields. The

 = ;    =20 Metric field for each of these prefixes is set to the=20 interface's

 = ;    =20 output cost.

 

Considering = the=20 following example

 

RTA<seria= l=20 1>-------------------<serial1>RTB

 

Does it mean= that RTA=20 will advertise the prefix configured on serial 1 with LA bit set, iff t= here=20 is no prefix configured on the serial1 of RTB?

 

Thanx and=20 regards

Prasanna



***************************************************************************=
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************=
------=_NextPart_000_000E_01C485E5.12EC0840-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 19 09:02:43 2004 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 JAA29210 for ; Thu, 19 Aug 2004 09:02:39 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00E5106E@cherry.ease.lsoft.com>; Thu, 19 Aug 2004 9:02:38 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31457076 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 Aug 2004 09:02:34 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 19 Aug 2004 09:02:34 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 10F9D75C4E2 for ; Thu, 19 Aug 2004 06:02:34 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03767-06 for ; Thu, 19 Aug 2004 06:02:33 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.38]) by prattle.redback.com (Postfix) with SMTP id 78B2875C4E0 for ; Thu, 19 Aug 2004 06:02:32 -0700 (PDT) References: <000d01c485b6$f933cc40$5c04060a@future.futsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_034B_01C485CB.40B4E9F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <034e01c485ec$c8330760$0202a8c0@aceeinspiron> Date: Thu, 19 Aug 2004 09:02:28 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: How the prefixes configured on point-to-point link are handled in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_034B_01C485CB.40B4E9F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vanitha, Since a /128 doesn't route you anywhere other than the local system it = seems to be, by definition, a local address. In our implementation, we only = allow /128 IPv6 addresses to be configured on loopback interfaces.=20 Acee ----- Original Message -----=20 From: vanitha=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Thursday, August 19, 2004 2:37 AM Subject: Re: How the prefixes configured on point-to-point link are = handled in OSPFv3 Hi Ace, What is the advantage we gain by setting LA bit for /128 = addresses of point to point interfaces.=20 LA bit setting is useful for making virtual link up. That = is taken care by the below lines in the RFC. =20 If RTX has one or more virtual links configured through the area, it includes one of its site-local or global scope IPv6 interface addresses in the LSA (if it hasn't already), setting the LA-bit = in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. This information will be used later in the routing calculation so that the two ends of the virtual link can discover each other's IPv6 addresses Regards, Vanitha N. -----Original Message----- [vanitha] =20 From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of = Acee Lindem Sent: Thursday, August 19, 2004 2:49 AM To: OSPF@peach.ease.lsoft.com Subject: Re: How the prefixes configured on point-to-point link are = handled in OSPFv3 Hi Prasanna, Refer to:=20 = http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0405&L=3Dospf&T=3D0&F=3D= &S=3D&P=3D2297 The answer to your question is "no", the prefix configuration of RTB = doesn't have bearing on what is advertised.=20 ----- Original Message -----=20 From: prasanna=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Friday, August 13, 2004 4:43 AM Subject: How the prefixes configured on point-to-point link are = handled in OSPFv3 Hi What does the following sentence (section 3.4.3.7) in the RFC 2740 = mean? Router RTX examines its list of interfaces to the area. If the interface is in state Down, its prefixes are not included. = If the interface has been reported in RTX's router-LSA as a Type 2 = link description (link to transit network), its prefixes are not included (they will be included in the intra-area-prefix-LSA = for the link instead). If the interface type is = Point-to-MultiPoint, or the interface is in state Loopback, or the interface = connects to a point-to-point link which has not been assigned a = prefix, then the site-local and global scope IPv6 addresses = associated with the interface (if any) are copied into the intra-area- prefix-LSA, setting the LA-bit in the PrefixOptions field, = and setting the PrefixLength to 128 and the Metric to 0. = Otherwise, the list of site-local and global prefixes configured in RTX = for the link are copied into the intra-area-prefix-LSA by = specifying the PrefixLength, PrefixOptions, and Address Prefix fields. = The Metric field for each of these prefixes is set to the = interface's output cost. Considering the following example RTA-------------------RTB Does it mean that RTA will advertise the prefix configured on = serial 1 with LA bit set, iff there is no prefix configured on the = serial1 of RTB? Thanx and regards Prasanna = *************************************************************************= ** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. = *************************************************************************= ** ------=_NextPart_000_034B_01C485CB.40B4E9F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Vanitha,
 
Since a /128 doesn't route you = anywhere other=20 than the local system it seems
to be, by definition, a local address. = In our=20 implementation, we only allow /128 IPv6
addresses to be configured on loopback = interfaces.=20
 
Acee
----- Original Message -----
From:=20 vanitha
Sent: Thursday, August 19, 2004 = 2:37=20 AM
Subject: Re: How the prefixes = configured=20 on point-to-point link are handled in OSPFv3

Hi=20 Ace,
       &nbs= p;   =20 What is the advantage we = gain by setting=20 LA bit for /128 addresses of point to point interfaces. =
       &nbs= p;   =20 LA bit setting is = useful for making=20 virtual link up. That is taken care by the below lines in the=20 RFC.
 
       &nbs= p;   =20
If RTX has one or more virtual = links=20 configured through the area,
      it = includes one=20 of its site-local or global scope IPv6=20 interface
      addresses in the LSA (if = it hasn't=20 already), setting the LA-bit in
      the=20 PrefixOptions field, and setting the PrefixLength to 128=20 and
      the Metric to 0. This = information will=20 be used later in the
      routing = calculation so=20 that the two ends of the virtual link = can
     =20 discover each other's IPv6 addresses
 
Regards,
Vanitha N.
 
-----Original Message-----
[vanitha]  
From:=20 Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of = Acee=20 Lindem
Sent: Thursday, August 19, 2004 2:49 = AM
To:=20 OSPF@peach.ease.lsoft.com
Subject: Re: How the prefixes = configured=20 on point-to-point link are handled in OSPFv3

Hi Prasanna,
 
Refer to:
 
http://peach.ease.lsoft.com= /scripts/wa.exe?A2=3Dind0405&L=3Dospf&T=3D0&F=3D&S=3D&= ;P=3D2297
 
The answer to your question is = "no", the prefix=20 configuration of RTB doesn't have
bearing on what is advertised. =
----- Original Message ----- =
From:=20 prasanna
To: OSPF@PEACH.EASE.LSOFT.COM=20
Sent: Friday, August 13, = 2004 4:43=20 AM
Subject: How the prefixes = configured=20 on point-to-point link are handled in OSPFv3

Hi

What = does the=20 following sentence (section 3.4.3.7) in the RFC 2740=20 mean?

 

Router RTX=20 examines its list of interfaces to the area. If = the

     =20 interface is in state Down, its prefixes are not included. If=20 the

     =20 interface has been reported in RTX's router-LSA as a Type 2=20 link

     =20 description (link to transit network), its prefixes are=20 not

     =20 included (they will be included in the intra-area-prefix-LSA=20 for

     =20 the link instead). If the = interface=20 type is Point-to-MultiPoint,

     =20 or the interface is in state Loopback, or the interface=20 connects

     =20 to a point-to-point link which has not been assigned a=20 prefix,

     =20 then the site-local and global scope IPv6 addresses=20 associated

     =20 with the interface (if any) are copied into the=20 intra-area-

     =20 prefix-LSA, setting the LA-bit in the PrefixOptions field,=20 and

     =20 setting the PrefixLength to 128 and the Metric to=20 0. =20 Otherwise,

     =20 the list of site-local and global prefixes configured in RTX=20 for

     =20 the link are copied into the intra-area-prefix-LSA by=20 specifying

  =20    the PrefixLength, PrefixOptions, and Address = Prefix=20 fields. The

     =20 Metric field for each of these prefixes is set to the=20 interface's

     =20 output cost.

 

Considering the=20 following example

 

RTA<serial=20 1>-------------------<serial1>RTB

 

Does it = mean that=20 RTA will advertise the prefix configured on serial 1 with LA bit = set, iff=20 there is no prefix configured on the serial1 of = RTB?

 

Thanx = and=20 regards

Prasanna



********************************************************= *******************
This=20 message is proprietary to Future Software Limited (FSL)
and is = intended=20 solely for the use of the individual to whom it
is addressed. It = may=20 contain privileged or confidential information
and should not be = circulated=20 or used for any purpose other than for
what it is = intended.

If you=20 have received this message in error, please notify the
originator=20 immediately. If you are not the intended recipient,
you are = notified that=20 you are strictly prohibited from using,
copying, altering, or = disclosing=20 the contents of this message.
FSL accepts no responsibility for = loss or=20 damage arising from
the use of the information transmitted by this = email=20 including
damage from=20 = virus.
***************************************************************= ************
------=_NextPart_000_034B_01C485CB.40B4E9F0-- From owner-ospf@PEACH.EASE.LSOFT.COM Sun Aug 22 10:17:51 2004 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 KAA29038 for ; Sun, 22 Aug 2004 10:17:51 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00E55AC4@cherry.ease.lsoft.com>; 22 Aug 2004 10:17:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31901739 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 22 Aug 2004 10:17:46 -0400 Received: from 212.74.114.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 22 Aug 2004 10:07:46 -0400 Received: from mk-cpfront-1.mail.uk.tiscali.com ([212.74.114.3]:41648 helo=mk-cpfrontend.uk.tiscali.com) by mk-smarthost-1.mail.uk.tiscali.com with esmtp (Exim 4.30) id 1Byt0c-000MXy-Us for OSPF@PEACH.EASE.LSOFT.COM; Sun, 22 Aug 2004 15:07:46 +0100 Received: from [212.74.112.53] by mk-cpfrontend.uk.tiscali.com with HTTP; Sun, 22 Aug 2004 15:07:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <4124B98200019EC6@mk-cpfrontend-1.mail.uk.tiscali.com> Date: Sun, 22 Aug 2004 14:07:47 +0000 Reply-To: Mailing List Sender: Mailing List From: Joseph Placid Subject: OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable OSPF PROTOCOL __________________________________________________________________ Get Tiscali Broadband From =A315:99 http://www.tiscali.co.uk/products/broadbandhome/ From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 23 06:08:50 2004 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 GAA26133 for ; Mon, 23 Aug 2004 06:08:50 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00E56D64@cherry.ease.lsoft.com>; Mon, 23 Aug 2004 6:08:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31983572 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Aug 2004 06:08:47 -0400 Received: from 203.197.138.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Aug 2004 06:08:44 -0400 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail1.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 23 Aug 2004 15:37:03 +0530 Received: from vanitha (vanitha.future.futsoft.com [10.6.4.92]) by kailash.future.futsoft.com (8.12.8/8.12.8) with SMTP id i7NA6NcB030858 for ; Mon, 23 Aug 2004 15:36:24 +0530 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 CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Message-ID: <006601c488f8$d9fe11b0$5c04060a@future.futsoft.com> Date: Mon, 23 Aug 2004 15:36:25 +0530 Reply-To: Mailing List Sender: Mailing List From: vanitha Subject: LA bit setting in IA for virtual link To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, As per the section 3.4.3.7 in RFC 2740, "If RTX has one or more virtual links configured through the area, it includes one of its site-local or global scope IPv6 interface addresses in the LSA (if it hasn't already), setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. This information will be used later in the routing calculation so that the two ends of the virtual link can discover each other's IPv6 addresses. " Setting LA bit to any of the interface prefix is not sufficient to handle multiple virtual links. The prefix should belong to one of the interfaces in transit area. Consider the below situation |-------------| 1 |-----------| | R1 |---------------| R2 |--------------R3 | |---------------| | 3 -------------- 2 ------------ Link 1 is in area 1 with metric as 1 at R2 Link 2 is in area 2 with metric as 10 at R2 Link 3 is in area backbone. virtual link is configured between R1 and R2 through the transit area 2. (Say virtual Link 1) one more virtual link is configured between R1 and R2 through the transit area 1. (Say virtual link 2) If R1 adds link 1 prefix with LA bit set in both the transit areas, then Route at R2 for the LA bit set prefix will be through the link 1 because of the lower cost. For both the virtual link, the packet will be send on link 1. The packets will be always associated with the virtual link 2 because of the validation procedures told in 8.2 section of RFC2328. "The receiving interface must also attach to the virtual link's configured Transit area. If all of these checks succeed, the packet is accepted and is from now on associated with the virtual link " So virtuallink1 will never come up. Instead if we mandate that the LA bit should be set for a prefix of one of the interfaces of transit area, then things will work fine. If there is no prefix in the transit area, virtual link will fail. This is in line with OSPFv2. Reference--> Section 15 Virtual Links. "Note that when one (or both) of the virtual link endpoints connect to the Transit area via an unnumbered point-to-point link, it may be impossible to calculate either the virtual interface's IP address and/or the virtual neighbor's IP address, thereby causing the virtual link to fail. " Regards, Vanitha N. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 23 12:23:15 2004 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 MAA20647 for ; Mon, 23 Aug 2004 12:23:14 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00E572CB@cherry.ease.lsoft.com>; Mon, 23 Aug 2004 12:23:04 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32042779 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Aug 2004 12:23:03 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Aug 2004 12:23:02 -0400 Received: from smirtoraw2k03 ([64.100.161.202]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i7NGN0t24699 for ; Mon, 23 Aug 2004 09:23:00 -0700 (PDT) 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal Message-ID: <018501c4892d$77356c60$73a16440@amer.cisco.com> Date: Mon, 23 Aug 2004 12:23:02 -0400 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: LA bit setting in IA for virtual link To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <006601c488f8$d9fe11b0$5c04060a@future.futsoft.com> Precedence: list Content-Transfer-Encoding: 7bit Vanitha, ->Hi, -> -> As per the section 3.4.3.7 in RFC 2740, "If RTX has ->one or more virtual links configured through the area, it ->includes one of its site-local or global scope IPv6 interface ->addresses in the LSA (if it hasn't already), setting the ->LA-bit in the PrefixOptions field, and setting the ->PrefixLength to 128 and the Metric to 0. This information ->will be used later in the routing calculation so that the two ->ends of the virtual link can discover each other's IPv6 addresses. " -> ->Setting LA bit to any of the interface prefix is not ->sufficient to handle multiple virtual links. The prefix ->should belong to one of the interfaces in transit area. Typically you would set the LA bit for one of the interface's prefix in transit area if that interface has a global IPv6 address. Otherwise you will advertise any of your global IPv6 address *in_the_tranist_area* with LA bit set ->Consider the below situation -> -> |-------------| 1 |-----------| -> | R1 |---------------| R2 |--------------R3 -> | |---------------| | 3 -> -------------- 2 ------------ -> -> ->Link 1 is in area 1 with metric as 1 at R2 ->Link 2 is in area 2 with metric as 10 at R2 ->Link 3 is in area backbone. ->virtual link is configured between R1 and R2 through the ->transit area 2. (Say virtual Link 1) one more virtual link is ->configured between R1 and R2 through the transit area 1. (Say ->virtual link 2) -> ->If R1 adds link 1 prefix with LA bit set in both the transit ->areas, then Route at R2 for the LA bit set prefix will be ->through the link 1 because of the lower cost. For both the ->virtual link, the packet will be send on link 1. Note that for VL control packet, the path taken is always through the corresponding transit area. Now for data traffic through the backbone, you have two paths (each through different transit area) and naturally you will take the shortest path, this is not any different than if you had both physical link in area 0 -> ->The packets will be always associated with the virtual link 2 ->because of the validation procedures told in 8.2 section of ->RFC2328. "The receiving interface must also attach to the ->virtual link's configured Transit area. If all of these ->checks succeed, the packet is accepted and is from now on ->associated with the virtual link " So virtuallink1 will never come up. -> It will, as long as you have an intra-area path to the other end of VL through transit area... ->Instead if we mandate that the LA bit should be set for a ->prefix of one of the interfaces of transit area, then things ->will work fine. Again your transit area may not have a global IPv6 address therefore you can announce any global IPv6 address into each transit area with LA bit set Sina ->If there is no prefix in the transit area, ->virtual link will fail. This is in line with OSPFv2. ->Reference--> Section 15 Virtual Links. "Note that when one ->(or both) of ->Reference--> the ->virtual link endpoints connect to the Transit area via an ->unnumbered point-to-point link, it may be impossible to ->calculate either the virtual interface's IP address and/or ->the virtual neighbor's IP address, thereby causing the ->virtual link to fail. " -> ->Regards, ->Vanitha N. -> -> -> -> -> ->************************************************************** ->************* ->This message is proprietary to Future Software Limited (FSL) ->and is intended solely for the use of the individual to whom ->it is addressed. It may contain privileged or confidential ->information and should not be circulated or used for any ->purpose other than for what it is intended. -> ->If you have received this message in error, please notify the ->originator immediately. If you are not the intended ->recipient, you are notified that you are strictly prohibited ->from using, copying, altering, or disclosing the contents of ->this message. FSL accepts no responsibility for loss or ->damage arising from the use of the information transmitted by ->this email including damage from virus. ->************************************************************** ->************* -> From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 23 12:36:32 2004 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 MAA21801 for ; Mon, 23 Aug 2004 12:36:31 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00E57501@cherry.ease.lsoft.com>; Mon, 23 Aug 2004 12:36:26 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32043352 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Aug 2004 12:36:24 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Aug 2004 12:36:24 -0400 Received: from smirtoraw2k03 ([64.100.161.202]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i7NGaMt11635 for ; Mon, 23 Aug 2004 09:36:23 -0700 (PDT) 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal Message-ID: <018801c4892f$5518bf90$73a16440@amer.cisco.com> Date: Mon, 23 Aug 2004 12:36:24 -0400 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: I-D ACTION:draft-psenak-mt-ospf-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Folks, This draft was presented in the last IETF meeting, below is the link to the new version of the draft. Compared to the version *-00, the draft has been re-organized in order to separate the link exclusion from the default topology as an optional functionality, also a topology identifier has been reserved for multicast topology. Comments are welcome Thanks Sina -----Original Message----- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MT-OSPF: Multi Topology (MT) Routing in OSPF Author(s) : P. Psenak, et al. Filename : draft-psenak-mt-ospf-01.txt Pages : 12 Date : 2004-8-18 This draft describes the extension to OSPF in order to define independent IP topologies called Multi-Topologies (MTs). The MT extension can be used for computing different paths for different classes of service, in-band management network or incongruent topologies for unicast and multicast. M-ISIS describes a similar mechanism for ISIS. This draft also describes an optional extension of Multi-topologies whereby some links might be excluded from the default topology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-psenak-mt-ospf-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-psenak-mt-ospf-01.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-psenak-mt-ospf-01.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. ------------------------------------------------------------------------ - In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. ------------------------------------------------------------------------ - For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: i7IKEhs5004682 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 23 17:12:26 2004 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 RAA14393 for ; Mon, 23 Aug 2004 17:12:25 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00E578EA@cherry.ease.lsoft.com>; Mon, 23 Aug 2004 17:12:25 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32072895 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Aug 2004 17:12:22 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Aug 2004 17:12:22 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AB92C7345E0 for ; Mon, 23 Aug 2004 14:12:22 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28188-01 for ; Mon, 23 Aug 2004 14:12:22 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.14]) by prattle.redback.com (Postfix) with SMTP id B2C7C7345DB for ; Mon, 23 Aug 2004 14:12:21 -0700 (PDT) References: <018501c4892d$77356c60$73a16440@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <030401c48955$d9f67650$0202a8c0@aceeinspiron> Date: Mon, 23 Aug 2004 17:12:08 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: LA bit setting in IA for virtual link To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Vanitha, Sina, I agree completely with Sina. One key point is that prefixes advertised in the router's intra-area prefix LSA for the transit area are limited to those interfaces in the transit area (independent of the setting of the LA bit). Thanks, Acee . ----- Original Message ----- From: "Sina Mirtorabi" To: Sent: Monday, August 23, 2004 12:23 PM Subject: Re: LA bit setting in IA for virtual link > Vanitha, > > > ->Hi, > -> > -> As per the section 3.4.3.7 in RFC 2740, "If RTX has > ->one or more virtual links configured through the area, it > ->includes one of its site-local or global scope IPv6 interface > ->addresses in the LSA (if it hasn't already), setting the > ->LA-bit in the PrefixOptions field, and setting the > ->PrefixLength to 128 and the Metric to 0. This information > ->will be used later in the routing calculation so that the two > ->ends of the virtual link can discover each other's IPv6 addresses. " > -> > ->Setting LA bit to any of the interface prefix is not > ->sufficient to handle multiple virtual links. The prefix > ->should belong to one of the interfaces in transit area. > > > Typically you would set the LA bit for one of the interface's prefix in > transit area if that interface has a global IPv6 address. Otherwise you > will advertise any of your global IPv6 address *in_the_tranist_area* > with LA bit set > > > ->Consider the below situation > -> > -> |-------------| 1 |-----------| > -> | R1 |---------------| R2 |--------------R3 > -> | |---------------| | 3 > -> -------------- 2 ------------ > -> > -> > ->Link 1 is in area 1 with metric as 1 at R2 > ->Link 2 is in area 2 with metric as 10 at R2 > ->Link 3 is in area backbone. > ->virtual link is configured between R1 and R2 through the > ->transit area 2. (Say virtual Link 1) one more virtual link is > ->configured between R1 and R2 through the transit area 1. (Say > ->virtual link 2) > -> > ->If R1 adds link 1 prefix with LA bit set in both the transit > ->areas, then Route at R2 for the LA bit set prefix will be > ->through the link 1 because of the lower cost. For both the > ->virtual link, the packet will be send on link 1. > > Note that for VL control packet, the path taken is always through the > corresponding transit area. Now for data traffic through the backbone, > you have two paths (each through different transit area) and naturally > you will take the shortest path, this is not any different than if you > had both physical link in area 0 > > -> > ->The packets will be always associated with the virtual link 2 > ->because of the validation procedures told in 8.2 section of > ->RFC2328. "The receiving interface must also attach to the > ->virtual link's configured Transit area. If all of these > ->checks succeed, the packet is accepted and is from now on > ->associated with the virtual link " So virtuallink1 will never come up. > -> > > It will, as long as you have an intra-area path to the other end of VL > through transit area... > > > ->Instead if we mandate that the LA bit should be set for a > ->prefix of one of the interfaces of transit area, then things > ->will work fine. > > Again your transit area may not have a global IPv6 address therefore you > can announce any global IPv6 address into each transit area with LA bit > set > > Sina > > > > ->If there is no prefix in the transit area, > ->virtual link will fail. This is in line with OSPFv2. > ->Reference--> Section 15 Virtual Links. "Note that when one > ->(or both) of > ->Reference--> the > ->virtual link endpoints connect to the Transit area via an > ->unnumbered point-to-point link, it may be impossible to > ->calculate either the virtual interface's IP address and/or > ->the virtual neighbor's IP address, thereby causing the > ->virtual link to fail. " > -> > ->Regards, > ->Vanitha N. > -> > -> > -> > -> > -> > ->************************************************************** > ->************* > ->This message is proprietary to Future Software Limited (FSL) > ->and is intended solely for the use of the individual to whom > ->it is addressed. It may contain privileged or confidential > ->information and should not be circulated or used for any > ->purpose other than for what it is intended. > -> > ->If you have received this message in error, please notify the > ->originator immediately. If you are not the intended > ->recipient, you are notified that you are strictly prohibited > ->from using, copying, altering, or disclosing the contents of > ->this message. FSL accepts no responsibility for loss or > ->damage arising from the use of the information transmitted by > ->this email including damage from virus. > ->************************************************************** > ->************* > -> From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 23 18:28:13 2004 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 SAA22688 for ; Mon, 23 Aug 2004 18:28:12 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00E57B94@cherry.ease.lsoft.com>; Mon, 23 Aug 2004 18:28:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32080960 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Aug 2004 18:28:11 -0400 Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Aug 2004 18:28:11 -0400 Received: from user-38ldt7f.dialup.mindspring.com ([209.86.244.239] helo=earthlink.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BzNIO-00074T-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Aug 2004 15:28:09 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <412A7010.5B4FD12C@earthlink.net> Date: Mon, 23 Aug 2004 15:30:40 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: draft-spagnolo-manet-ospf-design-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Design Considerations Wireless Interface April 04 Group, I am sure that I am late to these wireless discussions.. I will try to keep my comments short.. My two cents.. FYI: Their is always a number of hosts that though they are "mobile" tend to be stationary for periods of time. It is almost imperative to scale the kbps requirements downwards during these times while being able to verify that the LSDBs are synchronized. First, is this paper assuming the the LSF packet type without acks? I am not. 3.1 Neighbor Discovery Their are actually two bps values being generated here. The first is a 1-way discovery within the avg 1/2 of hello interval. The second is increased reliabliity tradeoff in the event that multiple hellos are lost. The true required hello overhead are the extra hellos being sent that are duplicates within the dead router interval. If we see no loss, then the minimum required hello pkt overhead calcs should use dead router interval. The diff between that value and your value should the resultant overhead needed to assure a level of relaibility given a certain loss of pkts. 3.2 Adj Forming Their is a implied assumption that when a "partioned network comes together" that their will be only one router between the partition. If most of the new full adjs are between the new partitions, and they are formed first, then the "avg-LSAsOutSync" will initially start at 100% * the number of number of routers. EX: the area is partitioned between A and B. All of the routers within A are sync with each other and the same goes for B. Now we have 5 routers on the side of A and 5 routers on the B side. A time "1" adjs will form between A1/B1, A2/B2 ... A5/B5. All LSAs at this time are different. It is only at a later time does the avg-..OutSync drop to significantly lower values. Secondly, the lifetime of a LSA needs to be considered. WRT, DNA (Do NOT AGE) LSAs the lifetime is infinite and should not be part of the flooding overhead. Thirdly, if a nbr leaves and returns within the LSA lifetime (and the router dead interval), then the nbr movement cancels and should not effect the equation (or be counted twice??). 3.3 LS Flooding A) "... Link State Flooding overhead to be the amount of overhead generated without any packet loss." Shouldn't this be added.. and that a ack is recieved within the timeframe as to prevent a control packet rexmit. Reason, is that pkt processing delays also cause rexmits... B) neighborchangerate This is bounded by the router dead interval, it takes us dead router interval to see that a router has gone away. It is also bounded by 1/2 the value of the hello interval to detect that a router has gone 2-way. To effect this value, one concievably could generate a hello when, * an interface comes up, * first time we see a nbr listed in the hello, instead of jsut periodicly xmiting hellos.. 3.4 Reliability I am not sure that you are seeking reliability as to be seeking an implicit way to verify that two or more LSDBs have converged. Within a wireless environment, the only method that I can CONCIEVABLY come up with is with a new OSPF control packets that contains a sum of the LSA checksums in a LSDB. If the values matched, then I could assume that the LSDBs probably match, given a LSA count, and THEN stop rexmiting LSAs. To belablor the point, as a router enters a new region of an area, he or she could xmit this new control packet with 0. This could inform all recvrs to xmit their LSAs.. Thus, the area goes into a quiesent mode where just minimal summary information is xmited when the mobile environment is temporalily in stasis. This above concept assumes that the total number of LSAs that need to be freq xmited is great, that the overhead to process them is significant, and that LSDB convergence is intended. --- I think this is enough to add at this time... Mitchell Erblich Sr. Software Engineer Currently consulting.. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 24 02:05:53 2004 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 CAA26683 for ; Tue, 24 Aug 2004 02:05:53 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00E5847F@cherry.ease.lsoft.com>; Tue, 24 Aug 2004 2:05:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32121023 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 24 Aug 2004 02:05:47 -0400 Received: from 203.197.138.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 24 Aug 2004 02:05:47 -0400 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail1.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Tue, 24 Aug 2004 11:33:22 +0530 Received: from vanitha (vanitha.future.futsoft.com [10.6.4.92]) by kailash.future.futsoft.com (8.12.8/8.12.8) with SMTP id i7O620cB015647 for ; Tue, 24 Aug 2004 11:32:00 +0530 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 CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <001601c4899f$ddc531f0$5c04060a@future.futsoft.com> Date: Tue, 24 Aug 2004 11:31:57 +0530 Reply-To: Mailing List Sender: Mailing List From: vanitha Subject: Re: LA bit setting in IA for virtual link To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <030401c48955$d9f67650$0202a8c0@aceeinspiron> Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, I found that your statement is not in sync with Sina's. Correct me if i am wrong. One key point is that prefixes advertised in the router's intra-area prefix LSA for the transit area are limited to those interfaces in the transit area (independent of the setting of the LA bit). --> This lines of yours infer me that addresses advertised in intra area prefix LSA must be from that area. This is what my point in the first mail. This is not clearly stated in the RFC 2740. If there is no prefix in the transit area we should not make the virtual link up. This is in sync with OSPFv2 specification. But as per Sina's statement, if there is no prefix in transit area, then any of the global ipv6 address is advertised in the transit area when we have virtual link. I suppose this is in contradiction to your statement. Advertising other interface prefixes will create problem in few topologies. Regards, Vanitha N. -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee Lindem Sent: Tuesday, August 24, 2004 2:42 AM To: OSPF@peach.ease.lsoft.com Subject: Re: LA bit setting in IA for virtual link Hi Vanitha, Sina, I agree completely with Sina. One key point is that prefixes advertised in the router's intra-area prefix LSA for the transit area are limited to those interfaces in the transit area (independent of the setting of the LA bit). Thanks, Acee . ----- Original Message ----- From: "Sina Mirtorabi" To: Sent: Monday, August 23, 2004 12:23 PM Subject: Re: LA bit setting in IA for virtual link > Vanitha, > > > ->Hi, > -> > -> As per the section 3.4.3.7 in RFC 2740, "If RTX has > ->one or more virtual links configured through the area, it > ->includes one of its site-local or global scope IPv6 interface > ->addresses in the LSA (if it hasn't already), setting the > ->LA-bit in the PrefixOptions field, and setting the > ->PrefixLength to 128 and the Metric to 0. This information > ->will be used later in the routing calculation so that the two > ->ends of the virtual link can discover each other's IPv6 addresses. " > -> > ->Setting LA bit to any of the interface prefix is not > ->sufficient to handle multiple virtual links. The prefix > ->should belong to one of the interfaces in transit area. > > > Typically you would set the LA bit for one of the interface's prefix in > transit area if that interface has a global IPv6 address. Otherwise you > will advertise any of your global IPv6 address *in_the_tranist_area* > with LA bit set > > > ->Consider the below situation > -> > -> |-------------| 1 |-----------| > -> | R1 |---------------| R2 |--------------R3 > -> | |---------------| | 3 > -> -------------- 2 ------------ > -> > -> > ->Link 1 is in area 1 with metric as 1 at R2 > ->Link 2 is in area 2 with metric as 10 at R2 > ->Link 3 is in area backbone. > ->virtual link is configured between R1 and R2 through the > ->transit area 2. (Say virtual Link 1) one more virtual link is > ->configured between R1 and R2 through the transit area 1. (Say > ->virtual link 2) > -> > ->If R1 adds link 1 prefix with LA bit set in both the transit > ->areas, then Route at R2 for the LA bit set prefix will be > ->through the link 1 because of the lower cost. For both the > ->virtual link, the packet will be send on link 1. > > Note that for VL control packet, the path taken is always through the > corresponding transit area. Now for data traffic through the backbone, > you have two paths (each through different transit area) and naturally > you will take the shortest path, this is not any different than if you > had both physical link in area 0 > > -> > ->The packets will be always associated with the virtual link 2 > ->because of the validation procedures told in 8.2 section of > ->RFC2328. "The receiving interface must also attach to the > ->virtual link's configured Transit area. If all of these > ->checks succeed, the packet is accepted and is from now on > ->associated with the virtual link " So virtuallink1 will never come up. > -> > > It will, as long as you have an intra-area path to the other end of VL > through transit area... > > > ->Instead if we mandate that the LA bit should be set for a > ->prefix of one of the interfaces of transit area, then things > ->will work fine. > > Again your transit area may not have a global IPv6 address therefore you > can announce any global IPv6 address into each transit area with LA bit > set > > Sina > > > > ->If there is no prefix in the transit area, > ->virtual link will fail. This is in line with OSPFv2. > ->Reference--> Section 15 Virtual Links. "Note that when one > ->(or both) of > ->Reference--> the > ->virtual link endpoints connect to the Transit area via an > ->unnumbered point-to-point link, it may be impossible to > ->calculate either the virtual interface's IP address and/or > ->the virtual neighbor's IP address, thereby causing the > ->virtual link to fail. " > -> > ->Regards, > ->Vanitha N. > -> > -> > -> > -> > -> > ->************************************************************** > ->************* > ->This message is proprietary to Future Software Limited (FSL) > ->and is intended solely for the use of the individual to whom > ->it is addressed. It may contain privileged or confidential > ->information and should not be circulated or used for any > ->purpose other than for what it is intended. > -> > ->If you have received this message in error, please notify the > ->originator immediately. If you are not the intended > ->recipient, you are notified that you are strictly prohibited > ->from using, copying, altering, or disclosing the contents of > ->this message. FSL accepts no responsibility for loss or > ->damage arising from the use of the information transmitted by > ->this email including damage from virus. > ->************************************************************** > ->************* > -> *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 24 09:14:13 2004 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 JAA03193 for ; Tue, 24 Aug 2004 09:14:12 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00E58C9D@cherry.ease.lsoft.com>; Tue, 24 Aug 2004 9:14:04 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32221028 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 24 Aug 2004 09:14:01 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 24 Aug 2004 09:14:01 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4AB46834A09 for ; Tue, 24 Aug 2004 06:14:01 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19726-02 for ; Tue, 24 Aug 2004 06:14:00 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.14]) by prattle.redback.com (Postfix) with SMTP id BD3FF834A07 for ; Tue, 24 Aug 2004 06:13:59 -0700 (PDT) References: <001601c4899f$ddc531f0$5c04060a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <03c401c489dc$2fd00970$0202a8c0@aceeinspiron> Date: Tue, 24 Aug 2004 09:13:45 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: LA bit setting in IA for virtual link To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Vanitha, Hmmm - now I see the ambiguity. In my implementation, I limit the search to global prefixes associated with interfaces within the transit area. I guess RFC 2740 doesn't specify this explicitly and leaves it open to different interpretations. I'd certainly agree that it should be limited since it doesn't that restrictive to require at least one global prefix within the transit area. Thanks, Acee ----- Original Message ----- From: "vanitha" To: Sent: Tuesday, August 24, 2004 2:01 AM Subject: Re: LA bit setting in IA for virtual link > Hi Acee, > I found that your statement is not in sync with Sina's. Correct me if i am > wrong. > > One key point is that prefixes advertised in the router's intra-area prefix > LSA for the transit > area are limited to those interfaces in the transit area (independent of > the setting of the LA bit). --> This lines of yours infer me that addresses > advertised in intra area prefix LSA must be from that area. This is what my > point in the first mail. This is not clearly stated in the RFC 2740. If > there is no prefix in the transit area we should not make the virtual link > up. This is in sync with OSPFv2 specification. > > But as per Sina's statement, if there is no prefix in transit area, then any > of the global ipv6 address is advertised in the transit area when we have > virtual link. I suppose this is in contradiction to your statement. > Advertising other interface prefixes will create problem in few topologies. > > Regards, > Vanitha N. > > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee > Lindem > Sent: Tuesday, August 24, 2004 2:42 AM > To: OSPF@peach.ease.lsoft.com > Subject: Re: LA bit setting in IA for virtual link > > > Hi Vanitha, Sina, > > I agree completely with Sina. One key point is that prefixes > advertised in the router's intra-area prefix LSA for the transit > area are limited to those interfaces in the transit area (independent of > the setting of the LA bit). > > Thanks, > Acee > . > > ----- Original Message ----- > From: "Sina Mirtorabi" > To: > Sent: Monday, August 23, 2004 12:23 PM > Subject: Re: LA bit setting in IA for virtual link > > > > Vanitha, > > > > > > ->Hi, > > -> > > -> As per the section 3.4.3.7 in RFC 2740, "If RTX has > > ->one or more virtual links configured through the area, it > > ->includes one of its site-local or global scope IPv6 interface > > ->addresses in the LSA (if it hasn't already), setting the > > ->LA-bit in the PrefixOptions field, and setting the > > ->PrefixLength to 128 and the Metric to 0. This information > > ->will be used later in the routing calculation so that the two > > ->ends of the virtual link can discover each other's IPv6 addresses. " > > -> > > ->Setting LA bit to any of the interface prefix is not > > ->sufficient to handle multiple virtual links. The prefix > > ->should belong to one of the interfaces in transit area. > > > > > > Typically you would set the LA bit for one of the interface's prefix in > > transit area if that interface has a global IPv6 address. Otherwise you > > will advertise any of your global IPv6 address *in_the_tranist_area* > > with LA bit set > > > > > > ->Consider the below situation > > -> > > -> |-------------| 1 |-----------| > > -> | R1 |---------------| R2 |--------------R3 > > -> | |---------------| | 3 > > -> -------------- 2 ------------ > > -> > > -> > > ->Link 1 is in area 1 with metric as 1 at R2 > > ->Link 2 is in area 2 with metric as 10 at R2 > > ->Link 3 is in area backbone. > > ->virtual link is configured between R1 and R2 through the > > ->transit area 2. (Say virtual Link 1) one more virtual link is > > ->configured between R1 and R2 through the transit area 1. (Say > > ->virtual link 2) > > -> > > ->If R1 adds link 1 prefix with LA bit set in both the transit > > ->areas, then Route at R2 for the LA bit set prefix will be > > ->through the link 1 because of the lower cost. For both the > > ->virtual link, the packet will be send on link 1. > > > > Note that for VL control packet, the path taken is always through the > > corresponding transit area. Now for data traffic through the backbone, > > you have two paths (each through different transit area) and naturally > > you will take the shortest path, this is not any different than if you > > had both physical link in area 0 > > > > -> > > ->The packets will be always associated with the virtual link 2 > > ->because of the validation procedures told in 8.2 section of > > ->RFC2328. "The receiving interface must also attach to the > > ->virtual link's configured Transit area. If all of these > > ->checks succeed, the packet is accepted and is from now on > > ->associated with the virtual link " So virtuallink1 will never come up. > > -> > > > > It will, as long as you have an intra-area path to the other end of VL > > through transit area... > > > > > > ->Instead if we mandate that the LA bit should be set for a > > ->prefix of one of the interfaces of transit area, then things > > ->will work fine. > > > > Again your transit area may not have a global IPv6 address therefore you > > can announce any global IPv6 address into each transit area with LA bit > > set > > > > Sina > > > > > > > > ->If there is no prefix in the transit area, > > ->virtual link will fail. This is in line with OSPFv2. > > ->Reference--> Section 15 Virtual Links. "Note that when one > > ->(or both) of > > ->Reference--> the > > ->virtual link endpoints connect to the Transit area via an > > ->unnumbered point-to-point link, it may be impossible to > > ->calculate either the virtual interface's IP address and/or > > ->the virtual neighbor's IP address, thereby causing the > > ->virtual link to fail. " > > -> > > ->Regards, > > ->Vanitha N. > > -> > > -> > > -> > > -> > > -> > > ->************************************************************** > > ->************* > > ->This message is proprietary to Future Software Limited (FSL) > > ->and is intended solely for the use of the individual to whom > > ->it is addressed. It may contain privileged or confidential > > ->information and should not be circulated or used for any > > ->purpose other than for what it is intended. > > -> > > ->If you have received this message in error, please notify the > > ->originator immediately. If you are not the intended > > ->recipient, you are notified that you are strictly prohibited > > ->from using, copying, altering, or disclosing the contents of > > ->this message. FSL accepts no responsibility for loss or > > ->damage arising from the use of the information transmitted by > > ->this email including damage from virus. > > ->************************************************************** > > ->************* > > -> > > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 24 17:15:57 2004 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 RAA12316 for ; Tue, 24 Aug 2004 17:15:56 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00E59A19@cherry.ease.lsoft.com>; Tue, 24 Aug 2004 17:15:55 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32274906 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 24 Aug 2004 17:15:53 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 24 Aug 2004 17:15:53 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3107440502E for ; Tue, 24 Aug 2004 14:15:53 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10531-02 for ; Tue, 24 Aug 2004 14:15:52 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.14]) by prattle.redback.com (Postfix) with SMTP id 50BA840502D for ; Tue, 24 Aug 2004 14:15:52 -0700 (PDT) References: <018801c4892f$5518bf90$73a16440@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <04b701c48a1f$80679db0$0202a8c0@aceeinspiron> Date: Tue, 24 Aug 2004 17:15:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-psenak-mt-ospf-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This draft was presented at the last OSPF WG meeting in San Diego and there was some support (other than from the authors) for accepting this draft as a WG document. Any further discussion or concerns with bringing the TOS fields back to life in order to support other topologies? Thanks, Acee ----- Original Message ----- From: "Sina Mirtorabi" To: Sent: Monday, August 23, 2004 12:36 PM Subject: I-D ACTION:draft-psenak-mt-ospf-01.txt > Folks, > > This draft was presented in the last IETF meeting, below is the link to > the new version of the draft. > > Compared to the version *-00, the draft has been re-organized in order > to separate the link exclusion from the default > topology as an optional functionality, also a topology identifier has > been reserved for multicast topology. > > Comments are welcome > > Thanks > Sina > > > -----Original Message----- > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : MT-OSPF: Multi Topology (MT) Routing in OSPF > Author(s) : P. Psenak, et al. > Filename : draft-psenak-mt-ospf-01.txt > Pages : 12 > Date : 2004-8-18 > > This draft describes the extension to OSPF in order to define > independent IP topologies called Multi-Topologies (MTs). The MT > extension can be used for computing different paths for different > classes of service, in-band management network or incongruent > topologies for unicast and multicast. M-ISIS describes a similar > mechanism for ISIS. > This draft also describes an optional extension of > Multi-topologies whereby some links might be excluded from the > default topology. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-psenak-mt-ospf-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-psenak-mt-ospf-01.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-psenak-mt-ospf-01.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. > > ------------------------------------------------------------------------ > - > In order to maintain computing infrastructure integrity, Cisco Systems > Enterprise Messaging Services and InfoSec teams have set a mail policy > disallowing executable attachments in email. > > This message contained an executable attachment type that is prohibited > by this policy. The attachment has been removed from this message and > copied to quarantine by our systems. It will be held in quarantine for > seven days in the event that the content needs to be retrieved. > > > ------------------------------------------------------------------------ > - > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > > If your concern isn't addressed by the information in this notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: i7IKEhs5004682 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 26 12:42:30 2004 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 MAA17357 for ; Thu, 26 Aug 2004 12:42:27 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00E5D173@cherry.ease.lsoft.com>; Thu, 26 Aug 2004 12:42:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32584254 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 26 Aug 2004 12:42:18 -0400 Received: from 130.76.64.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 26 Aug 2004 12:42:12 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA02769 for ; Thu, 26 Aug 2004 09:42:08 -0700 (PDT) Received: from xch-nw-23p.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i7QGg7D21886 for ; Thu, 26 Aug 2004 11:42:07 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nw-23p.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 09:42:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-spagnolo-manet-ospf-design-00.txt Thread-Index: AcSJYH7w7qmzw5BVT5GK11XVidAUPwCKCzRg X-OriginalArrivalTime: 26 Aug 2004 16:42:06.0715 (UTC) FILETIME=[9F931CB0:01C48B8B] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060814@xch-nw-27.nw.nos.boeing.com> Date: Thu, 26 Aug 2004 09:42:06 -0700 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: draft-spagnolo-manet-ospf-design-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Mitchell, Thanks for your comments-- responses inline below. > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Monday, August 23, 2004 3:31 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: draft-spagnolo-manet-ospf-design-00.txt >=20 >=20 > Design Considerations Wireless Interface April 04 >=20 > Group, >=20 > I am sure that I am late to these wireless discussions.. > I will try to keep my comments short.. My two cents.. >=20 > FYI: Their is always a number of hosts that > though they are "mobile" tend to be stationary for > periods of time. It is almost imperative to scale the > kbps requirements downwards during these times while > being able to verify that the LSDBs are synchronized. >=20 > First, is this paper assuming the the LSF packet > type without acks? I am not. Only Section 8 (Comparison with Unreliable Flooding) is considering the LSF packet type. >=20 > 3.1 Neighbor Discovery >=20 > Their are actually two bps values being generated here. > The first is a 1-way discovery within the avg 1/2 of > hello interval. The second is increased reliabliity > tradeoff in the event that multiple hellos are lost. >=20 > The true required hello overhead are the extra hellos being > sent that are duplicates within the dead router interval. >=20 > If we see no loss, then the minimum required hello pkt > overhead calcs should use dead router interval. The diff > between that value and your value should the resultant > overhead needed to assure a level of relaibility given > a certain loss of pkts. I think that this is a terminology debate. We considered all routing protocol traffic as overhead. I agree that there are different components to this ("necessary" overhead vs. possibly "redundant"=20 overhead). >=20 > 3.2 Adj Forming >=20 > Their is a implied assumption that when a "partioned > network comes together" that their will be only one > router between the partition. If most of the new > full adjs are between the new partitions, and > they are formed first, then the "avg-LSAsOutSync" will > initially start at 100% * the number of number of > routers. Yes, for simplicity, we assume the case that a partition is healed by one router. But some LSAs may still be in sync depending on when the network partitioned in the past. >=20 > EX: the area is partitioned between A and B. All of > the routers within A are sync with each other and the > same goes for B. Now we have 5 routers on the side of > A and 5 routers on the B side. A time "1" adjs will > form between A1/B1, A2/B2 ... A5/B5. All LSAs at this > time are different. It is only at a later time does > the avg-..OutSync drop to significantly lower values. >=20 > Secondly, the lifetime of a LSA needs to be considered. > WRT, DNA (Do NOT AGE) LSAs the lifetime is infinite > and should not be part of the flooding overhead. We did not consider DNA LSAs. >=20 > Thirdly, if a nbr leaves and returns within the > LSA lifetime (and the router dead interval), then > the nbr movement cancels and should not effect the > equation (or be counted twice??). Yes, from standpoint of needing to resynchronize out-of-sync databases, this would be a non-event. >=20 > 3.3 LS Flooding >=20 > A) >=20 > "... Link State Flooding overhead to be the amount of > overhead generated without any packet loss." >=20 > Shouldn't this be added.. >=20 > and that a ack is recieved within the timeframe as > to prevent a control packet rexmit. >=20 > Reason, is that pkt processing delays also cause > rexmits... that part was implied by the "without any packet loss" clause (we did not consider packet processing delays). So I would agree in general to your clarification. >=20 > B) neighborchangerate >=20 > This is bounded by the router dead interval, it takes > us dead router interval to see that a router has gone > away. In some implementations, there may also be layer-2 feedback that a neighbor has gone away without waiting for dead interval. >=20 > It is also bounded by 1/2 the value of the hello interval > to detect that a router has gone 2-way. >=20 > To effect this value, one concievably could generate > a hello when, > * an interface comes up, > * first time we see a nbr listed in the hello, >=20 > instead of jsut periodicly xmiting hellos.. Agree that there are some more intelligent Hello transmission heuristics that are possible. >=20 > 3.4 Reliability >=20 > I am not sure that you are seeking reliability as to > be seeking an implicit way to verify that two or more > LSDBs have converged. >=20 > Within a wireless environment, the only method that I > can CONCIEVABLY come up with is with a new OSPF control > packets that contains a sum of the LSA checksums in a > LSDB. If the values matched, then I could assume that > the LSDBs probably match, given a LSA count, and THEN stop > rexmiting LSAs. To belablor the point, as a router > enters a new region of an area, he or she could xmit > this new control packet with 0. This could inform all > recvrs to xmit their LSAs.. Thus, the area goes into > a quiesent mode where just minimal summary information > is xmited when the mobile environment is temporalily in > stasis. >=20 > This above concept assumes that the total number of > LSAs that need to be freq xmited is great, that > the overhead to process them is significant, and that > LSDB convergence is intended. Please see the draft by INRIA on database exchange techniques such as you described: http://www.ietf.org/internet-drafts/draft-clausen-manet-ospf-dbx-00.txt >=20 > --- I think this is enough to add at this time... >=20 > Mitchell Erblich > Sr. Software Engineer > Currently consulting.. >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 27 15:52:46 2004 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 PAA00300 for ; Fri, 27 Aug 2004 15:52:45 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00E5F21C@cherry.ease.lsoft.com>; Fri, 27 Aug 2004 15:52:44 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32774878 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 27 Aug 2004 15:52:39 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Aug 2004 15:42:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29282; Fri, 27 Aug 2004 15:42:37 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200408271942.PAA29282@ietf.org> Date: Fri, 27 Aug 2004 15:42:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-multi-area-adj-02.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.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 : OSPF Multi-Area Adjacency Author(s) : S. Mirtorabi, et al. Filename : draft-ietf-ospf-multi-area-adj-02.txt Pages : 12 Date : 2004-8-27 This memo documents an extension to OSPF to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra-area path to the corresponding areas sharing the same link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-multi-area-adj-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-multi-area-adj-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-multi-area-adj-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: <2004-8-27151222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-multi-area-adj-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-multi-area-adj-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-27151222.I-D@ietf.org> --OtherAccess-- --NextPart--